Re: Accepted lintian 2.118.0 (source) into unstable
When you do these kind of uploads, I recommend you use the `-v` option of dpkg-buildpackage (actually a dpkg-genchanges option) to include the previous changelog in the .changes file. That's because now all the bugs that you added in the previous changelog were not part of the .changes files, and so there weren't automatically closed, as well as having to direct reference to an upload. Also, people following along reading the .changes as sent via email can't get the whole picture :) I noticed that you closed (hopefully all?) bugs manually with a mail to control@ - but that's also not the best experience for bug reporters. That said, thank you for doing these uploads!! On Tue, Jul 30, 2024 at 12:50:30PM +, Debian FTP Masters wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Format: 1.8 > Date: Tue, 30 Jul 2024 09:21:17 + > Source: lintian > Architecture: source > Version: 2.118.0 > Distribution: unstable > Urgency: medium > Maintainer: Debian Lintian Maintainers > Changed-By: Bastien Roucariès > Closes: 1077557 > Changes: > lintian (2.118.0) unstable; urgency=medium > . >* Retroactively add missing entry to the 2.117.1 changelog entry > (Closes: #1077557) >* Bump version due to tag added in 2.117.1 >* Use C.UTF8 locale for building documentation (fix a FTBFS) > Checksums-Sha1: > c206caf3513c7977e06a51bae5409a59f9117d6b 3983 lintian_2.118.0.dsc > e030a56801c3f37f0180e18f91e8ba5f557e276c 2259336 lintian_2.118.0.tar.xz > 01766ba8616a8f172a954547dff17565a3443437 20897 > lintian_2.118.0_amd64.buildinfo > Checksums-Sha256: > e3ae51e952d4bd2398bc9d895da9e451ddead7867fe32e1e8b47b18c725e9721 3983 > lintian_2.118.0.dsc > 9090f8c5256896381edc7dfaf01f47e6c0be2c848a58824e5b656bc794756410 2259336 > lintian_2.118.0.tar.xz > e82984b104bfaf4ae51f051866d5ed8e00fe07618e851713e324278a13827d8d 20897 > lintian_2.118.0_amd64.buildinfo > Files: > a07988d6b24b36545539123b82f416f3 3983 devel optional lintian_2.118.0.dsc > 822a02039af9207abcd7b4698a1aa897 2259336 devel optional > lintian_2.118.0.tar.xz > d9d7dacc15d769049f2b3fa799946381 20897 devel optional > lintian_2.118.0_amd64.buildinfo > > -BEGIN PGP SIGNATURE- > > iQJFBAEBCgAvFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmao27wRHHJvdWNhQGRl > Ymlhbi5vcmcACgkQADoaLapBCF97yg/9GW4jPW57Rqj2TZbtZVsauZvYbHaJfT2z > T70aB+HuLwZYMHg1jOPwA5kPp3Y5J3FG+3fMSLZ4uXYzGOctOjLc9o+IRYsUSVWx > tu8SQ4ZFE7AAbdWPkyUKrbq2fuSlQIR8iQfWrRN5vQruaggHn0YYY/Ff8U1jM0Ix > so/VejcuqxiuQyOYjaN89g5l/+JVNsoREy8lQTDDqjXAvYOcFlqdMjR7fDjpNvsA > CwWgALVEMWnKPV84+3KM7niO6QTltui4RktvwGBM7nj1Ij+ifGrMWKQjhxtP6/ea > Z8XXM6siowMHBM4KFznGQkCI0YI0Vg0cpsRenWZiLlZgPLr+sPvAQwRF96JShcPp > 8+ZBMr/uplybAoZiXZwhaDmOYmH3UlPr1Z3wUaEa95YnTfYUdRRnECAJwQpxEdLD > Z9DxV45O/mqpKVWgwSopr3ngEouqbuPNUo9ZAGLC3T3xd306N7FRsv1X0L3sDnA0 > Gh+TKFbQBhgOvmC1GobE2gX+eZHE3uqu+edYxl5J0hoWsFQGE7uDYCs3jG0MZrml > CNLCNdLioRUo8Q+x8c0BEaQ24x9tam3Qf6zr6imW3l9DfI0W9LLLcxsFRbHBnBMM > BRn/jch23kXTrzaQ3a0IQCJWmPzXqoxsWz4Qc+E8ftUDwo2RPBIuVwl/UHzdFXzB > A+t0B9GmEZk= > =/22D > -END PGP SIGNATURE- > -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1077467: lintian: report my email address m...@eipi.fun as bogus-mail-host
Control: reassign -1 libdata-validate-domain-perl 0.10-1.1
On Mon, Jul 29, 2024 at 03:51:58PM +0900, EiPi Fun wrote:
> I am a packager trying to package orphaned tty-clock, you can check here:
> https://mentors.debian.net/package/tty-clock/
>
> It just report my email address m...@eipi.fun as bogus-mail-host, I
> understand cause it's personal domain name but I need to report a but of it.
>
> This email address works anyway.
> Please fix it, I want to upload more packages later.
This is actually a bug in the validation library (that looking at it now
I see it's quite outdated compared to upstream version).
See for example:
perl -M'Data::Valizdate::Domain' -e 'is_domain("m...@eipi.fun") ||
print("domain invalid");'
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1024610: lintian: fpos runtime-test-file-uses-supported-python-versions-without-test-depends
Package: lintian
Version: 2.115.1
Running on limnoria/2022.11.10, I'm getting:
W: limnoria source:
runtime-test-file-uses-supported-python-versions-without-test-depends
py3versions --supported [debian/tests/upstream-tests:14]
d/tests/control looks like this:
|Tests: upstream-tests
|Depends:
| @,
| @builddeps@,
|Restrictions: allow-stderr
And python3-all is part of @builddeps@.
I reckon that lintian is perhaps not expanding @builddeps@ correctly for
this check?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Bug#1014537: unnamed packaging files in a multibinary package should be an error
Hi Niels, Thank you for this work. Personally I have only one point I'd like to raise: On Sat, Oct 29, 2022 at 08:55:38PM +0200, Niels Thykier wrote: > * debian/README.Debian > * debian/TODO > > These have historically been installed into the main package and a note in > debhelper (dh_installdocs) suggests these (or at least README.Debian) is a > name standardized by Policy. I am open to not installing them by default if > one of you are willing to drive the discussion on debian-devel to assert > there is consensus for that. In all my QA work around the archive (admittedly, not much in the last few years), I don't think I ever saw *one* d/TODO file that was up-to-date; they always felt remnants from the last century or so. Also, IIRC most of the time those files contained TODO items for the maintainer, something that is hardly interesting for the final user. Do you have any number about this file? As such, I'd like to propose to instead not ship this file by default if present in the source package. BTW, is d/TODO documented anywhere? I know it's an historic file, but I don't think I saw it mentioned in any formal document. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1016364: lintian: spelling-error-in-binary should be more precise
On Sat, Jul 30, 2022 at 08:30:13AM +0300, Martin-Éric Racine wrote: > When building dhcpcd5 version 9.4.1-4 against Stable, Lintian 2.104.0 reports > the following: > > I: dhcpcd-base: spelling-error-in-binary usr/sbin/dhcpcd addres address > > $ grep -rw addres > $ > > i.e. not found. > > Lintian really needs to quote the whole stanza where typos are spotted, > otherwise, it's like looking for a needle in a hay stack. Those "spelling error in binary" checks use `strings` on the final binary, so there isn't really much to see often. % strings dhcpcd|grep -E 'addres\b' Duplicate addres In your case at most you could get this much. Note that strings can also "leak" from statically linked/inlined functions. I tried a quick codesearch.d.n lookup, but I couldn't spot a string like that. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1014859: lintian: coloured background can be horrible depending on the colour scheme
Package: lintian Version: 2.115.2 Severity: minor Starting with… 2.115 I believe, lintian emits tag names with a white font and coloured background. The resulting rendering is very dependent on the terminal and colour palette the user is using, and for me the yellow and green background renders with a very poor contrast making them unreadable. See the attached screenshot for an example. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1014584: lintian: False positive binary-nmu-debian-revision-in-source and source-nmu-has-incorrect-version-number with Ubuntu version
On Fri, Jul 08, 2022 at 01:34:49PM +0200, Axel Beckert wrote: > Hi, > > Alberto Contreras wrote: > > When I invoke `lintian` over a package with a version like > > `22.2-64-g1fcd55d6-0ubuntu1~22.10.1` it emits > > `binary-nmu-debian-revision-in-source` and > > `source-nmu-has-incorrect-version-number` source warnings. This looks like ISTR that source-nmu-* just wasn't issued under ubuntu (i.e. with --profile=ubutnu), did it start to be issued now? I don't have any recollection about binary-nmu-* If I dreamt the whole thing, then perhaps it should be done, because the concept of NMU doesn't exist in Ubuntu, so the tag as a whole doesn't make sense. That said, AFAIK -0ubuntu1~22.10.1 is not a formally documented version anywhere, though I have seen it a few times. Alberto: what kind of upload is this? 22.10 is the current dev version, so it's not some kind of backport. With such context, I can guess that this is some kind of package that your team is maintianing for multiple ubuntu branches, in which case I'd expect you to follow the SRU versioning, which prescribe -0ubuntu0.22.10.1 instead. https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging I must also add that using . instead of ~ is fraught with catches, as documented by, for example, https://lintian.debian.org/tags/dfsg-version-with-period So I'd advocate a change in that policy, which hasn't been touched for at least a decade (when I started contributing to ubuntu packages…) > Note to myself: There's a similar albeit not identical issue reported > in https://bugs.debian.org/1001399. ♥ Axel :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1009967: lintian: improbable-bug-number-in-closes produces incorrect results
On Fri, Apr 22, 2022 at 09:59:50PM +0300, Martin-Éric Racine wrote: > On Fri, Apr 22, 2022 at 3:57 PM Mattia Rizzolo wrote: > > > > Control: notfound -1 2.114.163 > > Control: found -1 2.111.0 > > Control: close -1 2.113.0 > > > > On Thu, Apr 21, 2022 at 03:38:32PM +0300, Martin-Éric Racine wrote: > > > Package: lintian > > > Version: 2.114.163 > > > > What version is this?! ... > > The one reported when someone clicks on the line below. Ah, now I found the number.. That's the version that is used on lintian.debian.org, which is unrelated to what mentors.d.n reports. > > This bug has long long been fixed, but lintian is not migrating and as > > such no backport to bullseye can be done. > > (plus I notice lintian hasn't been uploaded _at all_ for many months…) > > Something tells me that the Lintian version found on Mentors is > unrelated to Testing migrations. It is very relevant instead, as on mentors we run whatever is on bullseye-backports. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1009967: lintian: improbable-bug-number-in-closes produces incorrect results
Control: notfound -1 2.114.163 Control: found -1 2.111.0 Control: close -1 2.113.0 On Thu, Apr 21, 2022 at 03:38:32PM +0300, Martin-Éric Racine wrote: > Package: lintian > Version: 2.114.163 What version is this?! ... > The Lintian on mentors.debian.net incorrectly reports: > > W: improbable-bug-number-in-closes 1008784 > > The relevant changelog entry: > > Replaces part of the cron job that we used to provide (Closes: #1008784). > > That bug report very much exists. This bug has long long been fixed, but lintian is not migrating and as such no backport to bullseye can be done. (plus I notice lintian hasn't been uploaded _at all_ for many months…) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1005200: lintian: prefer-uscan-symlink should to single maintainer packages at most
On Tue, Feb 08, 2022 at 04:31:43PM -0500, Scott Kitterman wrote:
> As a general case, correct package updating should not depend on
> non-default local setups.
About the "non-default": while working on version=5 of d/watch, I plan
on changing defaults in a way that having no filenamemangle will save
the file using the format package_version.orig.tar.xz
Just FYI.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1001399: lintian: adjust backports-upload-has-incorrect-version-number for ubuntu
Sorry, this topic seems to have slipped my mind. On Thu, Dec 09, 2021 at 08:59:33AM -0800, Felix Lechner wrote: > On Thu, Dec 9, 2021 at 8:37 AM Mattia Rizzolo wrote: > > > > I believe we shouldn't concern > > ourselves too much with UNRELEASED (what's the current behaviour here > > anyway?) > > For the majority of tags, the release is not considered but having > less concern for UNRELEASED would negatively affect the quality of > hints issued on Salsa. [1] I expect that to be the primary Lintian > platform for contributors in the future. That might even be so, but I don't think it's an interesting concern when we are talking about the final version string of a package. I also had a look at the current Distribution.pm which is what is doing the current check, and that's already skipping UNRELEASED for everything, special casing squeeze, wheezy and jessie, and doing all sorts of very target-specific checks. I think what lintian is currently doing in this check is perfectly fine, and it should keep doing that. Different distributions have different version requirements, so tying the two together only makes sense, and I see no reason why you shouldn't do that. You talk about running lintian in CI, which is fine, but then when run in CI (with UNRELEASED) it's also true that there is no reason for contributors to bother about the version string, as that's something for the maintainer/uploader to check, so I think it's kind of out of scope. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1003817: lintian: fpos for update-debian-copyright
On Sun, 16 Jan 2022, 2:58 pm Felix Lechner, wrote: > I cannot reproduce the behavior with hexchat_2.16.0-3.dsc (although > there are probably others) because it lacks the second paragraph. [2] > Are you uploading your new version to the archive? It would help me > fix the bug. I'm not uploading the new version so soon because it still needs some testing. However you can get it from the "apparmor" branch of its git repository. >
Bug#1003817: lintian: fpos for update-debian-copyright
Package: lintian
Version: 2.114.0
My d/copyright has:
|Files: debian/*
|Copyright: 2014 Jesse Rhodes
| 2016-2022 Mattia Rizzolo
|License: GPL-2+
|
|Files: debian/apparmor/*
|Copyright: 2014 troubadour
| 2014-2021 ENCRYPTED SUPPORT LP
|License: GPL-3+-with-additional-terms-1
Regardless, I get:
P: hexchat source: update-debian-copyright 2021 vs 2022 [debian/copyright:17]
I guess it's taking the 2021 from the second paragraph?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1003530: lintian: Hangs when checking some .dsc file
On Tue, Jan 11, 2022 at 07:29:32AM -0500, Boyuan Yang wrote: > I just notice that lintian will never finish when checking some specific That's not correct. > https://mentors.debian.net/package/fcitx5-table-extra/ shows the lintian check > result to be " lintian took too much time to run ". I actually never saw lintian *hang*. It just got quite slow. Specifically, on mentors.d.n we set a timeout for lintian of 30 minutes. We really don't want the whole site to spend hours processing an incoming packages... Notably, in mentors we don't use `-X cruft` to bypass the slowest codepath in lintian, that can easily go over the 30 minutes time. > I am not 100% sure about the severity, but endless hang could be serious. Feel > free to let me know if you have any questions. IMHO, this could just be merged with that other bug (that I'm not looking up) about the cruft check being slow. Did you try running lintian yourself to actually verify it hangs somewhere? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#1003340: qa.debian.org: Please agree with salsa on the lintian version to use
On Sat, Jan 08, 2022 at 05:39:04PM +0100, Samuel Thibault wrote:
> With lintian's current tendency of changing its output, we have to adapt
> the suppression rules. But it appears that qa.debian.org and salsa's CI
> rules are not using the same version of lintian, so we are stuck with
> either having lintian errors showing up on the qa.debian.org page, or
> having the CI jobs on salsa fail on the lintian step.
Well, you should probably check what the salsa CI are running.
QA is showing data that comes from lintian.debian.org, that AFAIK mostly
runs either the very latest release, or even a current git checkout of
lintian.
I don't think this is a problem for qa.debian.org.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1002451: lintian: False positive file-references-package-build-path
On Wed, Dec 22, 2021 at 09:58:01AM +, Jose Luis Blanco Claraco wrote:
> to something more specific capturing names like real build paths, for
> example:
> `build/mrpt-mtM7nO/` => `build/[:alpha:]*-[:alpha:]{6}` or alike?
FWIW, that would be a sbuild-specific solution, and even in sbuild it's
a configurable parameter, so it wouldn't be an appropriate solution.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts
Hi Julian, On Tue, Dec 14, 2021 at 06:49:12AM +, Julian Gilbey wrote: > I discovered that in several of my autopkgtest scripts, and in various > other packages in the archive, the following pattern appears: I think (although I'm not an authoritative voice of any kind here) that you you are using the wrong option altogether actually. > cd somewhere > ... > for py in $(py3versions -r 2>/dev/null) > ... > > Unfortunately, this silently fails, Of course it's silent. you are asking something and then ignoring the output… > is given. The "2>/dev/null" is nevertheless usually required even > when run from the correct directory to silence the warning: > > py3versions: no X-Python3-Version in control file, using supported versions that's because you are using the wrong option. You should use `-s` instead of `-r` in those cases, and drop the 2>/dev/null. Besides, even if you keep the -r it wouldn't be much of a problem: $() only captures stdout, stderr just gets printed and doesn't interfere with the for loop or such, so why are you doing this? -r is used by dh_python and other build scripts because they have to support all packages, but IMHO you really should be using -s if you know you don't have X-Python3-Version in your package and you *really* want to just suppose whatever are the current supported python3 versions. > The corrected script should read something like: > > ... > for py in $(py3versions -r 2>/dev/null); do > cd somewhere > ... And then, `py3versions -s` will "just work" wherever you are, no need to do this fairly complicated check. > A regex such as /\bcd\b.*py3versions\s+-r/s applied to the entire > content of debian/tests/control and every other file in debian/tests > should catch this issue. Yeah sure, and then what about pushd ? Doing this kind of check in lintian is fraught with false positives, so I recommend the lintian maintainers don't try to do this. However, instead, I'd suggest that, after checking with the debian-python@ lists, we could tell people to use -s if and only if X-Python3-Version is not defined (conversely, we should warn if packages use -s if X-Python3-Version *is* defined, probably). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1001399: lintian: adjust backports-upload-has-incorrect-version-number for ubuntu
On Thu, Dec 09, 2021 at 07:41:44AM -0800, Felix Lechner wrote: > Right now, Lintian's profiles just enable or disable tags. I am not > opposed to expanding their capabilities, but is it the right approach? So, that's one approach, but considering your other proposals first. > Should the version string for a Ubuntu package also be acceptable even > if Lintian ran on Debian? I wouldn't be opposed to this, however I'd like to generally be warned if I'm obviously running lintian on my debian systems against an ubuntu packages. Is there already a tag for this? If this is already covered by a different tag, then backports-upload-has-incorrect-version-number could just accept both variants. > Can Lintian tell the target OS without looking at the version string? > Maybe the changelog (except that would not work for UNRELEASED)? Proposal: with the data from distro-info-data you can easily figure from what distribution is a given release. I believe we shouldn't concern ourselves too much with UNRELEASED (what's the current behaviour here anyway?) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1001399: lintian: adjust backports-upload-has-incorrect-version-number for ubuntu
Package: lintian Version: 2.114 X-Debbugs-Cc: ubuntu-backpo...@lists.ubuntu.com Hi, So, I have this: E: debhelper changes: backports-upload-has-incorrect-version-number 13.5.2ubuntu1~bpo20.04.1 However, in Ubuntu we just started up again the process, and the new policy says to append ~bpo$UBU_VERSION.1, with $UBU_VERSION 20.04, 18.04, 20.10, etc. See https://wiki.ubuntu.com/UbuntuBackports#Preparing_the_Backported_Package Do you think you could adjust the value of this tag when run under ubuntu (so, I suppose, run with the ubuntu profile)? TIA! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1001112: lintian: fpos for bash-term-in-posix-shell
Package: lintian
Version: 2.114.0
Hi,
I got these two fpos today:
I: eclipse-titan: bash-term-in-posix-shell '. "The following'
[usr/bin/titanver:124]
I: eclipse-titan: bash-term-in-posix-shell 'd{4,}' [usr/bin/titanver:99]
The incriminated file is attached.
Those are fpos because those lines are within a (crazy is you ask me,
but well) `eval 'exec ${perlexe} -x $0 ${1+"$@"} ;'`.
o/
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
#!/bin/sh
###
# Copyright (c) 2000-2021 Ericsson Telecom AB
# All rights reserved. This program and the accompanying materials
# are made available under the terms of the Eclipse Public License v2.0
# which accompanies this distribution, and is available at
# https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html
###
# Find Perl in the path
# Can't use `perl -e 'print $^X'` because that may print just "perl"
perlexe=`which perl 2>/dev/null | sed -n 's/[^\/]*\(\/.*perl\)/\1/p'`
# Do it the hard way if not found
if [ -z "${perlexe}" ] ; then
GCCVER=`strings -a -10 ${1+"$@"} | sed -n '
s/.*TITAN: [0-9][0-9]* PLATFORM: [A-Z0-9][A-Z0-9]* //
/GCC: (GNU)/ {
p
}
s/.*TITAN: [0-9][0-9]* PLATFORM: [A-Z0-9][A-Z0-9]* //
/Clang: (GNU)/ {
p
}
/Sun C++/ {
s/.*\(Sun C++ *[0-9]\.[0-9]\).*/\1/g
p
}
' | sort -u`;
if [ `echo "${GCCVER}" | wc -l` != 1 ]; then
echo -e "Error! Object files compiled with different compilers were
detected:
${GCCVER}
Please clean and rebuild your project.";
exit 1;
else
: ; # no news is good news
fi
exit 0; # avoid flowing into Perl
fi
#! Here begins the real -*- perl -*- -ws
#line 34
# The above directive should be adjusted to the line number of ** this ** line
eval 'exec ${perlexe} -x $0 ${1+"$@"} ;'
if 0;
use strict;
use vars qw($r $v);
my $compiler = 'Compiler';
my %versions;
my $objdump = `/bin/sh -c "which objdump" 2>/dev/null`;
chomp $objdump;
exit 0 if ($objdump !~ m!^/! or !@ARGV); # go quiet if no objdump or @ARGV is
empty
my $comment = '';
my @sections = qw( .titan .comment );
my $found_ver;
my $cmdline;
open (PIPE, $cmdline = "$objdump -s -j " . join(' -j ', @sections) . " @ARGV
|") or die "open failed: $!";
my $obj = '?';
sub match_comment() {
if (length($comment)) {
($found_ver) = $comment =~ /((GCC|Clang): \([^)]*\) \d\.\d+(?:\.\d+)?)/;
$found_ver =~ s/ \([^)]*\)//;
if ($found_ver) {
print "$compiler version was $found_ver for $obj\n" if $v;
push @{$versions{$found_ver}}, $obj;
if (defined $r and $r ne $found_ver) {
if (!$v) { # found version was not written, do it now
warn "$compiler was $found_ver for $obj\n";
}
die "$r was expected\n";
}
}
}
}
while ()
{
chomp;
next unless length;
if (/^([^:]+):\s+file format/) {
match_comment();
$obj = $1;
$comment = '';
}
elsif (my ($text) =
m/^ \s*
\d{4,} # offset
\s
[0-9a-fA-F ]{8} # first group of hex digits
\s
[0-9a-fA-F ]{8} # these should be [[:xdigit:] ] but rhea's perl is ancient :(
\s
[0-9a-fA-F ]{8}
\s
[0-9a-fA-F ]{8}
\s\s
(.+) # up to 16 characters of "plain" text
$/x) {
$comment .= $text;
}
}
match_comment();
close (PIPE) or die "close failed: $!";
if ( scalar keys %versions > 1 ) {
while ( my ($ver, $ref) = each %versions ) {
warn "Compiled with $compiler $ver: ", join(', ', @$ref), "\n";
}
die "Error! All object files should be compiled with the same compiler
version.\n"
. "The following $compiler versions were detected: ", join(', ', keys
%versions),
"\nRun make clean and make to recompile the project if the version of the
compiler changed recently.";
}
__END__
Parse the output of objdump, which looks like this:
core/XmlReader.o: file format elf64-x86-64
Contents of section .comment:
00474343 3a202847 4e552920 342e342e .GCC: (GNU) 4.4.
0010 30203230 30393032 31332028 65787065 0 20090213 (expe
0020 72696d65 6e74616c 2900 rimental).
Options:
-r=x.x.xexpected GCC version
-v verbose
Error conditions:
** -r=XXX supplied and one of the objects fail to match
** more than one GCC version detected
signature.asc
Description: PGP signature
Bug#996270: false positive custom-library-search-path
On 19.11.21 01:24, Felix Lechner wrote: > Control: reopen -1 > > Hi, > > On Thu, Nov 18, 2021 at 3:51 PM Michael Biebl wrote: > > > > E custom-library-search-path RUNPATH /usr/lib/x86_64-linux- > > gnu/NetworkManager/1.32.12 [usr/lib/x86_64-linux- > > gnu/NetworkManager/1.32.12/libnm-device-plugin-bluetooth.so] > > The subfolder is not named after the package name (due to camel case). > Should I allow all subfolders? If it's just the camel case (and not the - in the middle as well that is lacking in the folder name), perhaps allow for case-insensitive matches? I think that would be fair here. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1000148: lintian: improbable-bug-number-in-closes needs updating
On Thu, Nov 18, 2021 at 10:37:51AM -0800, Felix Lechner wrote:
> Unfortunately, that would make Lintian's output variable over time. Do
> we really need the upper bound (or the whole tag)?
I don't care about the moving output, but I do find the tag useful.
It saved me several times when I obviously typoed a bug number, so
please do keep it.
If I had to suggest a new static upper bound I'd recommend 1.5M though,
not 2M ^^
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#998115: lintian: false positive: "unknown-field Description" in source package
On Sat, Oct 30, 2021 at 04:41:11PM +0200, Hannah Rittich wrote:
> >> Furthermore, deb-substvars allows to reference the description
> >> field of the source package, using the variables ${source:Synopsis}
> >> and ${source:Extended-Description} [2].
> >
> > Uh. TIL. However I find that odd. Regardless, that's dpkg's choice,
> > and not Policy.
> >
> > I asked to the dpkg maintainers whether they had an intention to
> > propose a corresponding Policy change for it, since TTBOMK,
> > Description was never used in the source paragarph.
FTR, the dpkg maintainers pointed me to #555743 - so I think this "just"
needs some Policy massaging.
I filed #998165 on that regard, I guess you can follow that (but be
aware it will likely take a while).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#998115: lintian: false positive: "unknown-field Description" in source package
Control: tag -1 moreinfo
Hi.
On Sat, Oct 30, 2021 at 04:01:30PM +0200, Hannah Rittich wrote:
> Adding a "Description" field in the source section of a control file
> will cause lintian to issue the error "source: unknown-field Description".
I think you misunderstood the Policy here.
> The Debian Policy Manual [1] states that "in a source or binary control
> file, the Description field contains a description of the binary package
> [...]".
expanding the sentence above, that's "source control file" or "binary
control file".
The former is your debian/control, the letter is DEBIAN/control inside a
.deb.
That line is just saying "this field is used in these kind of files",
not actually describing where in those files that field can be used.
For that, you need to go to
file:///usr/share/doc/debian-policy/policy.html/ch-controlfields.html#source-package-control-files-debian-control
that clearly says that Description is only allowed the binary
paragraphs.
> This field can be used to avoid
> repetitions in the control file, as done by the abseil package [3],
> which displays the said error message [4].
You should use a non-standard field for that, meaning those fields that
start with X-. Those are documented in deb-src-control(5) and not in
Policy (since they are non-standard after all).
For example, use X-Synopsis in the source paragarph, and refer to it
with a ${S:X-Synopsis} substvar or such.
> Furthermore, deb-substvars allows to reference the description
> field of the source package, using the variables ${source:Synopsis} and
> ${source:Extended-Description} [2].
Uh. TIL. However I find that odd.
Regardless, that's dpkg's choice, and not Policy.
I asked to the dpkg maintainers whether they had an intention to propose
a corresponding Policy change for it, since TTBOMK, Description was
never used in the source paragarph.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#994987: lintian: inform about useless build-dep on dh-autoreconf when b-d on dh>=10
Control: close -1
On Fri, Sep 24, 2021 at 01:01:08PM +0200, Mattia Rizzolo wrote:
> SSIA.
nvm, it's there (useless-autoreconf-build-depends) and I was blind :3
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#994987: lintian: inform about useless build-dep on dh-autoreconf when b-d on dh>=10
Package: lintian Severity: wishlist Hi! SSIA. Of course please exclude the cases where dh-autoreconf has some version/arch/profile restriction, as that might be a good reason for it to be explicitly listed.) Please also remember to check in B-D-A/B-D-I. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#994577: lintian: node-* arch:all package should depends on nodejs:any and b-d on nodejs:native
(this reply is not related to lintian directly)
On Fri, Sep 17, 2021 at 09:34:43PM +, Bastien Roucariès wrote:
> In order to improve cross build of nodejs ecosystem, node-* arch:all package
> should depends on nodejs:any and b-d on nodejs:native
IMHO, you should make your tooling produce this "nodejs:any" binary
dependency, instead of having each package have it manually listed in
d/control (see ${perl:Depends} as an example, since, it's actually the
very same thing, producing perl:any dependencies).
> Maybe this test should be restricted to ma: foreign package
It shouldn't be IMHO.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#991242: lintian: fpos python3-depends-but-no-python3-helper
Package: lintian
Version: 2.104.0
See src:libxml2, version 2.9.10+dfsg-6 onwards.
I use:
8 Build-Depends:
9 debhelper-compat (= 13),
10 Build-Depends-Indep:
11 pkg-config,
12 Build-Depends-Arch:
13 dh-sequence-python3 ,
But apparently lintian is not happy with it, and keeps emitting
python3-depends-but-no-python3-helper.
I see a changelog entry in lintian mentioning dh-sequence-python3
associated to this tag, so I suspect lintian should already know how to
handle it.
Dropping the build profile, makes the tag go away.
As a bonus, I suspect that lintian could also be clever, and double
check that if dh-sequence-python3 is annotated with , then
also the binary packages using ${python3:Depends} should also have a
"Build-Profiles: " in it.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#960154: Feed UDD with just-in-time packaging hints from Lintian
On Tue, Apr 13, 2021 at 11:03:12AM -0700, Felix Lechner wrote: > On Tue, Apr 13, 2021 at 9:46 AM Mattia Rizzolo wrote: > > full import of everything > > I do not believe that is practicable. There are other ideas below. > > > * Figure out a way for UDD to know it needs to check the status of a > > package. > > Such a polling technique seems likewise like a so-so solution. These two points (and noting that the second also takes care of the first) are still needed, for whenever UDD misses a notification or similar, or for bootstrapping the tables (else we'd need a complete re-run of all lintian, which I understand that with the new setup is going to be somewhat rarer than it used to be as well, so…). > > * perhaps have the lintian website *push* new data to udd.d.o. > > I love this idea (from Jelmer), if you can make it work. We will > publish the files you consume now in real time. You can subscribe via > RabbitMQ and collect them, if that is helpful to you. Mh, as myself I never used RabbitMQ, but I suppose it's a one way. probably more "contemporary" than you providing SSH triggers or so. However I'd have no clues how to incorporate a long-running process in the current UDD setup, I'll have to leave that to Lucas. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#960154: Feed UDD with just-in-time packaging hints from Lintian
[ Adding lucas@ to CC since he is the main person behind UDD after all ]
On Sun, Apr 11, 2021 at 12:45:14PM -0700, Felix Lechner wrote:
> On Sat, May 9, 2020 at 5:33 PM Mattia Rizzolo wrote:
> > have lintian decide on a nice machine-parsable (text!) format
> > then udd will adapt its importer.
>
> As you know, both of these already happened several months ago.
Indeed, I consider that done by now.
> I have
> not commented here because I am still chewing on a related, but much
> harder problem:
I'd have probably used a different bug, but guess we'll cope.
> Lintian will soon cease to run blindly across the archive and instead
> produce packaging hints on demand, as uploads are received by the
> archive. There is no batch process anymore that will produce files for
> the entire archive the way you expect. Instead, Lintian's new website
> https://lintian.debian.*net* offers a JSON interface [1] to get up to
> date information similar to DAKweb. [2]
So, if we really go down this route, I think we need to:
* Have the importer able to run a full import of everything, which means
looping through all sources (which means running some ~30k HTTP GETs)
and storing them.
* Figure out a way for UDD to know it needs to check the status of a
package. This likely means a job that compares the set of known
(package, version, suite) (is the tuple right?) with what is available
in the lintian table: if something is missing query the lintian
website for new data.
* perhaps have the lintian website *push* new data to udd.d.o. I'm
conflicted if this should be just a trigger ("hey I've just processed
this, check it out yourself") or if it should carry the actual data as
well. I'm sure you'd like a HTTP post or such, but I can tell you
that we'd likely prefer something through SSH.
Since after all you did look at udd several times, I believe you should
already be able to implement the first 2?
All this said, I still don't understand why you wouldn't be able to
provide a view of everything. Since you set up that API, couldn't you
have a endpoint with *all* packages and everything, like the current
dump? That sounds much more trivial than what you are proposing…
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#977554: lintian: fpos alternates-not-allowed
Package: lintian Version: 2.104.0 Severity: important against dehydrated 0.7.0-1 (which is about to be uploaded): + su -c lintian -EIi --pedantic --color always --no-tag-display-limit --suppress-tags upstream-metadata-file-is-missing /build/*.changes; : - pbuilder su: warning: cannot change directory to /nonexistent: No such file or directory Warning in group dehydrated/0.7.0-1: Use of uninitialized value in string eq at /usr/share/lintian/checks/fields/package-relations.pm line 129. [... many lines like that ...] E: dehydrated-apache2: alternates-not-allowed Recommends N: E: alternates-not-allowed N: N: Only the "Depends", "Recommends", "Suggests" and "Pre-Depends" fields N: may specify alternate dependencies using the "|" symbol. N: N: Refer to Debian Policy Manual section 7.1 (Syntax of relationship N: fields) for details. N: N: Severity: error N: N: Check: fields/package-relations N: N: 1 hint overridden (1 warning) The binary has this: dehydrated-apache2_0.7.0-1_all.deb -- Package: dehydrated-apache2 Source: dehydrated Version: 0.7.0-1 Architecture: all Maintainer: Debian Let's Encrypt Team Installed-Size: 25 Recommends: dehydrated, apache2 (>= 2.4.6-4~) | httpd Section: misc Priority: optional It's my understanding that "apache2 (>= 2.4.6-4~) | httpd" is legal in Recommends, and the extended tag description also seems to say so. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#973637: flag debian/watch files that use older versions of the format
On Mon, Nov 02, 2020 at 10:54:11PM +0100, Xavier wrote: > But version 2 is really deprecated and it's > not easy to maintain uscan with 4 versions (It took me a lot of hours to > rewrite old uscan to modern Perl-OO). > That's why I'd like to see a "error" tag for version ≤ 2. Right, but currently version=2 is not explicitly marked as "deprecated" anywhere. Could you please send a MR updating the docs doing so? I also think ds_warn() its usage would be good (then tracker.d.o and others would rely the warning, etc). > 3. After bullseye release, I'd like to propose to remove version=2 > support from uscan. +1 For context of d-devel@, version=2 is currently used by a total of 350 packages in the whole archive, I reckon dropping support for it is totally doable. I think we can easily: 1) mark the thing as deprecated in the manpage and warning at runtime 2) add a note for the next DevNews 3) wait a few months after the bullseye release 4) MBF the remaining version=2 packages 5) wait a few more months 6) drop the support ~1/~1.5 years from now -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#970743: marked as pending in lintian
On Wed, Sep 23, 2020 at 04:53:00PM +, Chris Lamb wrote:
> Control: tag -1 pending
>
> https://salsa.debian.org/lintian/lintian/-/commit/5080c0068ffc4a9ddee92022a91d0c2ff53e56d1
>
>
> Update the expected Vcs-{Browser,Git} location of modules and applications
> maintained by the Python module team. (Closes: #970743)
>
However it has to be noted that together with the VCS location, also the
email and maintainer address changed.
That now should be
Debian Python Team
So I wonder if instead those 2 tags should be replaced by a bunch of
old-papt-maintainer/old-papt-vcs/old-dpmt-vcs/old-dpmt-maintainer that
should all point toward the new name and new VCS location.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#969170: lintian: fpos for override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS
Package: lintian Version: 2.91.0 Hi, When using debhelper compat 13 there is no need to explicitly check DEB_BUILD_OPTIONS=nocheck, so this tag override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS should not be emitted in dh compat 13. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#964539: qa.debian.org: man-pages.wml uses lintian.log that went away
Package: qa.debian.org
X-Debbugs-Cc: lint...@packages.debian.org
This seems to be the only service under qa.d.o that used
lintian.log.
lintian.log hasn't existed for several months, and now I went and
removed our copy on quantz.
We should move this service to the replacement facility the lintian
maintainers will provide in the future (the voices mention some json
file…).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#963765: lintian: please flag this typo of override
On Fri, Jun 26, 2020 at 10:55:03PM -, Chris Lamb wrote: > > Please also flag [oeverride_dh_missing]. > > Hm, are we sure we are likely to see this typo again soon? The "e" key > is not near the "o" or "v" keys in QWERTY, only in Dvorak. I assure you I'm not using Dvorak here!! In fact I have no idea how that typo happened! 🙃 I can only try a guess that I pressed the "e" key twice in a row accidentally, while also pressing the "v" key… If you think this is too improbable or anything, clearly feel free to drop this bug away. In fact, if one were to try to list all possible typos it would be a never-ending effort, I acknowledge that. I reckon the one and true way forward would be to do pattern-matching, but then it would perhaps starts to go a tad outside the scope of lintian. :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#963765: lintian: please flag this typo of override
Package: lintian
Version: 2.80.0
This MR was sent to me
https://salsa.debian.org/multimedia-team/inkscape/-/merge_requests/2
it's doing this:
-oeverride_dh_missing:
+override_dh_missing:
ISTR there is already a tag flagging possibly wrong rules target that
are likely a typo of a dh override. Please also flag these.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#950052: please warn for files installed into /
Noted. Let's see what it'll yield. However, please do try to judge the proposals, instead of very blindly implement them. Arguing might be unproductive but, as I mentioned in the past, generally annoying and likely inactionable tags are likewise very unproductive for us! :) On Mon, 22 Jun 2020, 6:24 pm Felix Lechner, wrote: > Hi Mattia, > > On Mon, Jun 22, 2020 at 8:58 AM Mattia Rizzolo wrote: > > > > I don't think I have much voice here, but tbh I feel like this is > totally artificially adding > > restraints that have no real reason to exist. > > That sweeping statement does not cover either (1) the accidental > installation errors that can occur when people use cp(1) instead of > install(1) to copy files, or (2) the degradation of style and > placement logic that happens with repetitive paths. > > > It's alright to think that at times this might be hiding a packaging > error, but honestly most of > > those case are usually self-evident and IME very rarely are a real > problem. > > Please remember I am closing bugs for requested features. I do not > argue much because I find it unproductive. Instead, I implement > everything that is remotely reasonable. > > I, too, have found repetitive paths annoying in the past, and have > seen installation errors in which a destination folder was > accidentally duplicated. > > Let's reserve judgment until we see how the check performs in the > wild. In the end, you may well be right. But we don't know that yet. > > Kind regards > Felix Lechner >
Bug#950052: please warn for files installed into /
I don't think I have much voice here, but tbh I feel like this is totally artificially adding restraints that have no real reason to exist. It's alright to think that at times this might be hiding a packaging error, but honestly most of those case are usually self-evident and IME very rarely are a real problem. On Mon, 22 Jun 2020, 5:39 pm Felix Lechner, wrote: > Hi Chris, > > On Mon, Jun 22, 2020 at 7:57 AM Chris Lamb wrote: > > > > P: lintian: repeated-path-segment usr usr/share/lintian/checks/usr/ > lib.pm > > Also solved by renaming, in commit 68b72cd0. > > Kind regards > Felix Lechner > >
Bug#926409: lintian: autopkgtest takes very long to finish
On Wed, 3 Jun 2020, 1:09 am Felix Lechner, wrote: > Hi Chris, > > On Fri, Apr 5, 2019 at 4:33 AM Iain Lane wrote: > > > > We do similar in some pkg-gnome packages, for example glib2.0 ships a > > -tests package that contains "installed tests" which are compiled as > > part of the package build and then executed during the autopkgtests. > > Should we ship all built test packages as part of our releases? I > can't think of a better way to close this bug. Now lintian autopkgtests take approximately 1 hour everywhere I checked. Honestly, I believe 1 hour to be acceptable. >
Bug#960154: UDD table no longer populated
clone 960154 -1
retitle 960154 lintian: please provide a stable, parsable output
reassign -1 qa.debian.org
user qa.debian@packages.debian.org
usertags -1 udd
block -1 by 960154
retitle -1 udd.debian.org: change the lintian importer to use the new export
file
thanks
On Sat, May 09, 2020 at 11:37:52PM +, Jelmer Vernooij wrote:
> Not sure whether to file this against UDD or lintian or detagtive; filing it
> against lintian since it changed more recently and I suspect that's related.
It was caused by a change in lintian, but it will have to be fixed in
both lintian and udd.
> For a while now, the UDD tables for lintian have been empty. They were
> previously populated with lintian data.
This was discussed recently in #-qa.
The frontend rewrite lechner did, completely removed the logs.gz that
was used by udd (and not only udd, I fear…)
I believe the first step is going to have lintian decide on a nice
machine-parsable (text!) format and publish that; then udd will adopt
its importer.
(PS, lechner: I went looking in lindsay to see if there was already a
replacement for the logs.gz file, and I noticed that the files under
/srv/lintian.debian.org/ are all with mixed ownership lintian:lintian
and lechner:lintian that might not be a issue right now since you
are the only one working on that part of lintian, but it's not quite
nice to any other team member in the future, even if the umask seems to
allow all team members to edit those files; I recommend you take on the
habit to deploy that stuff entirely under the role account.)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#959696: debian-rules-uses-as-needed-linker-flag and backports
Experimental and lowering to pedantic are orthogonal flags. I think both should be done, as removing --as-needed has very marginal relevance so it can't possibly be labeled as "warning". But due to what Christian said (which matches my thoughts) I likewise believe the tag should be hidden for the time being. I agree that marking the tag as experimental should be enough. I reckon not many display experimental tags, since those are hidden behind a flag that kind of discourage its usage. Perhaps also consider adding a note in the description that suitability of the change needs to be considerated if the package will be subject of backporting (whilst it's true that there is a risk of overlinking, many of those are not that severe: think of a Qt application that links a a bunch of Qt library just because upstream cargo-culted a list in a qmake file, even when not using all of it. An extra link to a QtSvg that is not used won't bother anybody. But there are more severe cases.). Such note should clearly mention that this is safe only if the package won't target anything lower than bullseye, so that it can stay also during the bookwork cycle for people considering oldstable-bpo uploads. Lastly, I am not sure if this works for your development workflow, place a code comment todo to drop the experimental flag once bullseye is out. Thank you for your tireless work on lintian! On Tue, 5 May 2020, 2:50 pm Christian Kastner, wrote: > On 2020-05-05 13:58, Chris Lamb wrote: > > I would like to do a Lintian release today, so given that a) I was led > > to believe skipping the tag for backports uploads would be sufficient > > and b) that I would not like to leave the resolution of this bug for > > another release, I would like to make the concrete proposal that we > > remove this tag (or possibly, mark it as pedantic, experimental, and > > add a suitable note to the long description). Would you concur? > > By my gut, either marking it as experimental, or removing it and > re-adding it once bullseye becomes stable, are superior approaches to > marking it pedantic. Pedantic might still motivate, well, a pedant, to > change something. > > Generally speaking, I found the tag informative, because I wasn't aware > of this new default setting in bullseye until lintian pointed this out > to me. It's just that a warning is a strong call to action. > > Christian >
Bug#959696: debian-rules-uses-as-needed-linker-flag and backports
On Mon, May 04, 2020 at 10:58:03PM -, Chris Lamb wrote: > It was sad to read that you do not consider that Lintian itself could > be updated to prevent all of these wasted brain cycles on a question > that you have seen raised multiple times. I consider that, and I think I tried to contribute in a bunch of similar discussions in the past, as well as filing reports whenever I thought there were possible improvements around. I'm just somewhat bothered because it feels that recent times (... 1/2/3 years maybe?) it started to be much more common for me to find unactionable or inapplicable tags, even if they could later be "tuned down" in a subsequent update. > Once a tag has been added we can always refine, replace or remove it > and the maintainers of Lintian have done so on a number of occasions > once they were made aware of it. What I'm getting at, is that as soon as a tag is added, it will immediately affects at least dozens but most likely hundreds of people in likely a single day, and if it stays around more than a day it'll soon touch the thousands. I'm convinced that tag additions should be pondered much more before adding them, rather than considering that they will be improved further on. By the time somebody is annoyed enough to file a bug (because, after all, a person will ponder if it's easier to just ignore something rather than writing a report about it) it will have already caused enough lost brain cycles. > This is even more of an unfortunate stance to take given that a simple > one-line improvement (such as to not emit this new tag in the case of > backporting) would appear to be sufficient. That is simply not true for this particular case: the problem of this tag is that it is emitted *for unstable* builds. It doesn't make sense for it to be hidden during backports, as by then its "harm" will be already done when the developer removed the --as-needed flag during the unstable upload. You'd have to know if that particular package *will be* *in the future* backported, to understand whether it's appropriate or not to drop that flag. > It is regrettable that so many Debian Developers hold such pessimistic > and fatalistic views regarding change in our project. Our collective > sense of fulfilment and enjoyment would no doubt improve if we were to > take small steps in reframing how we view these matters of this nature. I'm sure you know that I hold anything but fatalistic views when thinking of changes within the Project :) Just know that I'm regularly amongst the first to bump the debhelper compat level, and I've been asked by multiple parties multiple time to wait before doing so! But, however fast you want to change something, I agree proper and careful steps always need to be taken. In this particular case, there is not improvement whatsoever in removing that flag, except removing possible cruft from d/rules. Surely that cruft can stay there another year or two, when opposed to the risk of overlinking binaries and accidentally creating possibly heavy dependencies in stable systems (because that's where backports are). In other cases, there is a need to balance the view of thousands of maintainers and their needs. In this, my personal thought is that you, not you lamby but the Lintian maintainers as a whole, need to take more care about what you are including within the lintian checks, because whilst it's true that anything can be better tuned later after the release, as the end user of the tool being repeatedly irked by overzealous tags that need to be first ignored for a while, then reported, discussed and finally days/weeks later see in production can easily turn tiresome. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#959696: debian-rules-uses-as-needed-linker-flag and backports
[ not a lintian maintainer ] On Mon, May 04, 2020 at 09:53:45AM +0200, Christian Kastner wrote: > lintian understandably reports about a no longer required > -Wl,--as-needed in bullseye. However, unless I'm mistaken, it's still > needed for building for buster-backports, so removing it has a side effect. IMHO, this is typical example of a tag that shouldn't have existed until bullseye was stable. Having -Wl,--as-needed specified in d/rules AND as internal default from ld brings no downsides whatsoever, bearing one "extra" line in d/rules. Instead, I can see how many man-minutes and precious brain cycles were lost in bugs like this, since you are not the first person to raise this question. > The cleanest solution would probably be to remove it, and to simply > re-add this flag during backporting, at the cost of manual intervention > (beyond dch --bpo, that is). > > The pragmatic solution would be to just override the tag for packages > where a backport might be expected. I recommend you just either simply ignore the tag for those packages, or please an override if it bothers you. No need to overcomplicate a simple matter by removing and-readding flags when they can simply just stay there. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#959037: lintian: FPOS? for executable-in-usr-lib
On Tue, Apr 28, 2020 at 11:38:44PM +0100, Steve McIntyre wrote:
> ACK. d-i won't be looking in /usr/libexec. Please leave things where
> they are...
Good, then @lintian-maint: please exclude udebs from this check :)
(as I think used to be in the past, since I don't think I saw this tag
years ago in this package, but I know it has been there for a while…)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#959037: lintian: FPOS? for executable-in-usr-lib
On Tue, Apr 28, 2020 at 02:39:49PM -0700, Felix Lechner wrote: > On Tue, Apr 28, 2020 at 4:27 AM Mattia Rizzolo wrote: > > I'm CCing d-boot@ for confirmation, since I'm not sure if maybe I'm > > doing something wrong. > > > > Today I notices these tags: > > > > P: eatmydata-udeb udeb: executable-in-usr-lib > > usr/lib/finish-install.d/13eatmydata-udeb > > N: > > I expanded that odd tag description with some text from the original > bug report. I also adjusted the references. Perhaps the remark > regarding /usr/libexec is helpful: > > The package ships an executable file in /usr/lib. > > Please move the file to /usr/libexec. Not quite, as I'm positive those directories is where d-i go look for hooks, and I doubt just moving them to libexec is useful. I'm re-instating the CC on d-boot@ to see if it sparks some comment... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#959037: lintian: FPOS? for executable-in-usr-lib
Package: lintian
Version: 2.68.0
X-Debbugs-Cc: debian-b...@lists.debian.org
Hi,
I'm CCing d-boot@ for confirmation, since I'm not sure if maybe I'm
doing something wrong.
Today I notices these tags:
P: eatmydata-udeb udeb: executable-in-usr-lib
usr/lib/finish-install.d/13eatmydata-udeb
N:
N:policy, 9.1.1,
N:https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
N:
N:Severity: pedantic
N:
N:Check: usr/lib
N:
P: eatmydata-udeb udeb: executable-in-usr-lib
usr/lib/post-base-installer.d/01eatmydata-udeb
P: eatmydata-udeb udeb: executable-in-usr-lib
usr/lib/pre-pkgsel.d/10eatmydata-udeb
That being an udeb I know many things don't apply to it, but I'm not
sure if maybe I hsould place those d-i hooks elsewhere.
If, as I think, they are in the right place, please teach lintian to
ignore that in udebs.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#958932: lintian: debhelper compat level 13 is no longer experimental
On Sun, Apr 26, 2020 at 04:17:34PM -0700, Felix Lechner wrote:
> > I do not follow how
> > making this minor change would affect the rest of Lintian in the
> > dramatic way you describe.
>
> Following a conversation on IRC with mapreri last week I made the
> changes below. They caused build failures in almost all test artifacts
> on stable. The debian-compat (= 13) facility is not available.
debhelper/13 just migrated to bullseye, I reckon a buster-bpo will
follow soon.
I'm sure we can all wait a few more days...
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#958410: lintian: please warn about about duplicated debhelper build-deps
On Tue, Apr 21, 2020 at 11:49:09PM +0100, Chris Lamb wrote: > > Build-Depends: autoconf-archive, > > - debhelper (>= 11), > > + debhelper (>= 12), > > + debhelper-compat (= 12), > > libbz2-dev, > > libtar-dev, > > Interesting, I would have thought debhelper would FTBFS this with: > > dh: warning: Please specify the debhelper compat level exactly once. > dh: warning: * debian/compat requests compat 12. > dh: warning: * debian/control requests compat 12 via "debhelper-compat > (= 12)" > dh: warning: > dh: warning: Hint: If you just added a build-dependency on > debhelper-compat, then please remember to remove debian/compat > dh: warning: > dh: error: debhelper compat level specified both in debian/compat and via > build-dependency on debhelper-compat That only happens if you ship d/compat AND have debhelper-compat in the build-deps. It is not related to having debhelper in the build-deps. If fact, there are documented use cases where you *need* have have both debhelper and debhelper-compat (an example, if you rely on the udeb auto-detection from dh_makeshlibs 12.3, you need "debhelper-compat (= 12)" AND "debhelper (>= 12.3)" (or just d-copat=13 now…)). > Alternatively, if the build-profile means that the *debhelper-compat* > dependency is ignored and there is no debian/compat, would it not mean > that it would FTBFS with a "no debian/compat file"? The "extra restrictions (build profiles, etc)" I was referring to is related to the "debhelper" build-dep, not "debhelper-compat", sorry for not being precise. However now, thinking again, I can't think of a good reason to have a version of debhelper <= of that of debhelper-compat even with a build profile, I'm not sure what I was thinking about. :3 -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#958410: lintian: nag about duplicated debhelper build-deps
Package: lintian
Severity: wishlist
please consider tagging these cases:
Build-Depends: autoconf-archive,
- debhelper (>= 11),
+ debhelper (>= 12),
+ debhelper-compat (= 12),
libbz2-dev,
libtar-dev,
Having both debhelper and debhelper-compat there is only needed when the
version of debhelper is >> the version of debhelper-compat, not when
it's ==. Or when it has extra restrictions (build profiles, etc).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl
On Tue, Apr 14, 2020 at 08:41:01AM -0400, Scott Kitterman wrote: > The package python-pip-whl is a special case of a Python package built > to work with either python or python3. Currently python3-vertualenv > gets the following lintian warning: > > W: python3-virtualenv: > python-package-depends-on-package-from-other-python-variant Depends: > python-pip-whl > > While this is a great warning in general, in this case it's wrong. > Would it be OK to special case python-pip-whl and have it not trigger > this check? I would wager that this is the exact use case for an override? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Bug#956368: lintian: fneg: package-has-a-duplicate-build-relation
Package: lintian
Version: 2.64.0
While experimenting, I noticed:
% head -n 30 debian/control
Source: libxml2
Priority: optional
Section: libs
Maintainer: Debian XML/SGML Group
Uploaders:
Aron Xu ,
YunQiang Su ,
Build-Depends:
debhelper-compat (= 12),
dh-python,
Build-Depends-Indep:
pkg-config,
Build-Depends-Arch:
dh-python ,
libicu-dev,
liblzma-dev,
libpython-all-dbg ,
libpython-all-dev ,
libpython3-all-dbg ,
libpython3-all-dev ,
pkg-config,
python-all-dbg:any ,
python-all-dev:any (>= 2.7.5-5~) ,
python3-all-dbg:any ,
python3-all-dev:any (>= 3.5) ,
rename,
zlib1g-dev | libz-dev,
Standards-Version: 4.5.0
Rules-Requires-Root: no
Homepage: http://xmlsoft.org
%
this doesn't warn me about the duplicated dh-python that is both in B-D
and B-D-A.
The long description of the package-has-a-duplicate-build-relation tag
is:
N:The package declares the given build relations on the same package in
N:either Build-Depends or Build-Depends-Indep, but the build relations
N:imply each other and are therefore redundant.
I notice that description doesn't mention B-D-A, please consider adding
that.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#956357: lintian: fpos: package-has-a-duplicate-build-relation
Package: lintian
Version: 2.64.0
% head -n 30 debian/control
Source: libxml2
Priority: optional
Section: libs
Maintainer: Debian XML/SGML Group
Uploaders:
Aron Xu ,
YunQiang Su ,
Build-Depends:
debhelper-compat (= 12),
Build-Depends-Indep:
pkg-config,
Build-Depends-Arch:
dh-python ,
libicu-dev,
liblzma-dev,
libpython-all-dbg ,
libpython-all-dev ,
libpython3-all-dbg ,
libpython3-all-dev ,
pkg-config,
python-all-dbg:any ,
python-all-dev:any (>= 2.7.5-5~) ,
python3-all-dbg:any ,
python3-all-dev:any (>= 3.5) ,
rename,
zlib1g-dev | libz-dev,
Standards-Version: 4.5.0
Rules-Requires-Root: no
Homepage: http://xmlsoft.org
Vcs-Git: https://salsa.debian.org/xml-sgml-team/libxml2.git
%
that yields:
W: libxml2 source: package-has-a-duplicate-build-relation pkg-config, pkg-config
N:
N:The package declares the given build relations on the same package in
N:either Build-Depends or Build-Depends-Indep, but the build relations
N:imply each other and are therefore redundant.
N:
N:Severity: warning
N:
N:Check: fields/package-relations
N:
that's not true: pkg-configs is in both B-D-I and B-D-A, but one doesn't
imply the other.
(note that this version of libxml2 is not uploaded anywhere yet.)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#779228: Service may require more disk space
On Sun, Mar 29, 2020 at 08:14:51PM -0700, Felix Lechner wrote: > > Lintian will process all packages built from the same source/version > > together. This currently implies that all related packages must be > > unpacked fully at the same time. Unfortunately, for some package > > groups this can become extremely excessive. > > Based on the size of processing groups in the archive (please have a > look at kicad-packages3d, for example) I could not detect excessive > disk consumption. While my scheduler is totally different from > lintian.d.o (which may or may not run in parallel), I believe there > was sufficient evidence to retitle the bug. > > According to information obtained from DSA, the lintian.d.o service > recently had 32 GB of disk space, of which 12 GB appeared taken. (This > is from IRC; I do not have access to that service.) The available > space is probably insufficient. FTR, currently lindsay has: /dev/vda1 9.1G 3.1G 5.5G 37% / /dev/mapper/vg_lindsay-srv 32G 7.4G 23G 25% /srv So in fact you only have those 20ish free GB to do your stuff (as I believe you storing the temp stuff there). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#954743: lintian: orig-tarball-missing-upstream-signature does not say how to add it to uploaded tarballs
On Wed, Mar 25, 2020 at 02:58:15PM +0100, Andreas Beckmann wrote:
> I haven't tried removing components (or .asc), yet ;-)
That would just work as well. A source is tied to whatever is listed in
the .dsc, and you can replace bits of the sources in a subsequent debian
revision. I've seen a series of uploads that would, for example:
* upload -1 without .asc
* upload -2 with .asc
* upload -3 (that was done by another team member) without .asc
That works. What's horrible about dak, is that at this point, you could
upload a -4 with a *different* .asc, as long as the -2 upload is already
gone from the archive (i.e., not in stable). This is beacuse dak
doesn't record all files that he ever knew in the past, allowing for
overwriting sometimes…
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#954743: lintian: orig-tarball-missing-upstream-signature does not say how to add it to uploaded tarballs
On Sun, Mar 22, 2020 at 09:42:32PM +, Chris Lamb wrote: > > Should use the '-sa' option to force both the *.orig.tar.gz and *.asc > > into .*.changes? I think that such an upload will be rejected by DAK, as > > the *.tar.gz is already in the archive. But to be honest this is based > > on my past experiences, but maybe something has changed since then. Is > > re-uploading upstream tarballs permitted now? > > AIUI -sa by itself will not be rejected but I am unclear whether the > inclusion of the signature will cause a rejection. You could just try > it? :) I can tell you both that such an upload won't be rejected by dak as long as the .orig.tar.gz is the very same as the one that was previously uploaded. Honestly, I'm somewhat partial on putting such archive-dependant information in lintian is alright (dak is only one of the many debian archive software out there…). Also, to put the .tar.gz.asc in the git repository you'll need to ask pristine-tar to do a new "commit" (see man pristine-tar for "commit"); that said if I were you I'd just manually checkout to the pristine-tar branch and git commit the .asc file… (you'll see if that worked if `pristine-tar list` list the file once you go back to the master branch). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#954763: lintian: Lintian should warn about use of py3versions -i in autopkgtests
Control: clone -1 -2
Control: retitle -2 lintian: warn about py3versions -s but no python3-all
test-dependency
On Sun, Mar 22, 2020 at 11:57:08PM -0400, Scott Kitterman wrote:
> Preferably these packages should run their tests with all supported
> python3 versions. This is ensured by including python3-all in the test
> dependencies and using py3versions -s (instead of -i). Tests should run
> deterministically, not just based on whatever happens to be installed.
more than once I tripped on this, using `py3versions -s` but having only
python3 (or, not even that and rely on it being pulled by the testing
package), without python3-all. That causes only the default version to
be installed, and then the test would fail when trying to run the other
non-default supported version.
Please check for this as well ♥
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#954798: lintian: field-too-long checksums-sha256 error
On Tue, Mar 24, 2020 at 09:04:52AM -0700, Felix Lechner wrote: > I will disable this check for buildinfo files later today. (and .changes please :)) > On a larger scale, the high number of complaints we received about > this check from the broader community (and from our own team members, > i.e. mattia) raise the question whether Lintian should be concerned > about output generated by dpkg and friends. It probably should, as IMHO dpkg should stay as dumb as possible and trust what the maintainer asks it to do. Also, not everything dpkg can do is acceptable for the Debian archive, but there are also other targets out there. > I agree with all of you (and have stated numerous times in the record) > that Lintian provides friendly packaging advice for the benefit of > maintainers. We are not dpkg's test suite. For that reason, I am happy > to remove this check from Lintian as long as an equivalent restriction > finds its way into dpkg. Such check will never appear in dpkg, that's totally out of its scope. dpkg and apt work just fine with incredibly huge amount of data, this restriction is really artificial. The fact that a field is overblown can only work as a red herring in some cases, like the past Provides field that was way too long and turned out to be mostly unnecessary. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#954798: lintian: field-too-long checksums-sha256 error
On Mon, Mar 23, 2020 at 04:06:20PM +, David Mohammed wrote:
> E: budgie-extras changes: field-too-long Checksums-Sha256 (5432 chars > 5000)
> E: budgie-extras buildinfo: field-too-long Checksums-Sha256 (5321 chars >
> 5000)
now Chris whitelisted this field from the check. But really the whole
file should be.
If you are going to whitelist stuff, this would also mean:
Description
Changes
Files
Checksums-Sha1
Checksums-Md5
Environment
and whatever things might appear in the future. Really nothing cares
about the lenght of .changes and .buildinfo fields, and those fields are
thought that way to be however long they need to be.
I'll admit that IMHO the whole check is silly (saying that a random
field can't be over 5k char, very arbitraly?). There was *one* thing
that broke (reprepro) that was fixed already… I totally don't
understand what this tag is trying to accomplish.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#954341: lintian: What's going on with "field-too-long Installed-Build-Depends"?
Totally lintian is wrong here, imho. field-too-long was added to prevent silliness in the archive. As such, it only makes sense for binary control fields and .dsc, nothing else. On Fri, 20 Mar 2020, 3:21 pm gregor herrmann, wrote: > Package: lintian > Version: 2.58.0 > Severity: minor > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > With lintian 2.58.0 I got, for the first time, this error: > > E: pkg-perl-tools buildinfo: field-too-long Installed-Build-Depends (11190 > chars > 5000) > > I have no idea what to do with this information, and I've never seen > this tag before. Either lintian has changed and is right, then Some > Other Tool™ needs a fix, or lintian has changed and is wrong, or > something else :) > > > Cheers, > gregor > > > For reference, the .buildinfo file has: > > Installed-Build-Depends: > autoconf (= 2.69-11.1), > automake (= 1:1.16.1-4), > autopoint (= 0.19.8.1-10), > autotools-dev (= 20180224.1), > base-files (= 11), > base-passwd (= 3.5.47), > bash (= 5.0-6), > binutils (= 2.34-5), > binutils-common (= 2.34-5), > binutils-x86-64-linux-gnu (= 2.34-5), > bsdmainutils (= 11.1.2+b1), > bsdutils (= 1:2.34-0.1), > build-essential (= 12.8), > bzip2 (= 1.0.8-2), > ca-certificates (= 20190110), > coreutils (= 8.30-3+b1), > cpp (= 4:9.2.1-3.1), > cpp-9 (= 9.3.0-3), > dash (= 0.5.10.2-6), > debconf (= 1.5.73), > debhelper (= 12.9), > debianutils (= 4.9.1), > dh-autoreconf (= 19), > dh-strip-nondeterminism (= 1.6.3-2), > dictionaries-common (= 1.28.1), > diffstat (= 1.63-1), > diffutils (= 1:3.7-3), > dpkg (= 1.19.7), > dpkg-dev (= 1.19.7), > dwz (= 0.13-5), > emacsen-common (= 3.0.4), > fdisk (= 2.34-0.1), > file (= 1:5.38-4), > findutils (= 4.7.0-1), > g++ (= 4:9.2.1-3.1), > g++-9 (= 9.3.0-3), > gcc (= 4:9.2.1-3.1), > gcc-10-base (= 10-20200312-2), > gcc-9 (= 9.3.0-3), > gcc-9-base (= 9.3.0-3), > gettext (= 0.19.8.1-10), > gettext-base (= 0.19.8.1-10), > git (= 1:2.26.0~rc2-1), > git-man (= 1:2.26.0~rc2-1), > gpg (= 2.2.19-3), > gpgconf (= 2.2.19-3), > grep (= 3.4-1), > groff-base (= 1.22.4-4), > gzip (= 1.10-2), > hostname (= 3.23), > iamerican (= 3.4.00-8), > ienglish-common (= 3.4.00-8), > init-system-helpers (= 1.57), > intltool-debian (= 0.35.0+20060710.5), > ispell (= 3.4.00-8), > libacl1 (= 2.2.53-6), > libalgorithm-c3-perl (= 0.10-1), > libalgorithm-diff-perl (= 1.19.03-2), > libapt-pkg-perl (= 0.1.36+b3), > libapt-pkg6.0 (= 2.0.0), > libarchive-zip-perl (= 1.68-1), > libasan5 (= 9.3.0-3), > libassuan0 (= 2.5.3-7), > libatomic1 (= 10-20200312-2), > libattr1 (= 1:2.4.48-5), > libaudit-common (= 1:2.8.5-2), > libaudit1 (= 1:2.8.5-2+b1), > libb-hooks-endofscope-perl (= 0.24-1), > libb-hooks-op-check-perl (= 0.22-1+b2), > libbinutils (= 2.34-5), > libblkid1 (= 2.34-0.1), > libboolean-perl (= 0.46-1), > libbrotli1 (= 1.0.7-6), > libbsd0 (= 0.10.0-1), > libbz2-1.0 (= 1.0.8-2), > libc-bin (= 2.30-2), > libc-dev-bin (= 2.30-2), > libc6 (= 2.30-2), > libc6-dev (= 2.30-2), > libcache-lru-perl (= 0.04-1), > libcap-ng0 (= 0.7.9-2.1+b2), > libcapture-tiny-perl (= 0.48-1), > libcarp-assert-more-perl (= 1.20-1), > libcarp-assert-perl (= 0.21-1), > libcc1-0 (= 10-20200312-2), > libcgi-pm-perl (= 4.46-1), > libclass-c3-perl (= 0.34-1), > libclass-data-inheritable-perl (= 0.08-3), > libclass-inspector-perl (= 1.36-1), > libclass-method-modifiers-perl (= 2.13-1), > libclass-singleton-perl (= 1.5-1), > libclass-tiny-perl (= 1.006-1), > libclass-xsaccessor-perl (= 1.19-3+b3), > libclone-choose-perl (= 0.010-1), > libclone-perl (= 0.43-2), > libcom-err2 (= 1.45.5-2), > libcommon-sense-perl (= 3.74-2+b8), > libconfig-model-perl (= 2.138-2), > libconst-fast-perl (= 0.014-1), > libcontextual-return-perl (= 0.004014-2), > libconvert-binhex-perl (= 1.125-1), > libcroco3 (= 0.6.13-1), > libcrypt-dev (= 1:4.4.15-1), > libcrypt1 (= 1:4.4.15-1), > libctf-nobfd0 (= 2.34-5), > libctf0 (= 2.34-5), > libcurl3-gnutls (= 7.68.0-1), > libdata-optlist-perl (= 0.110-1), > libdatetime-format-dateparse-perl (= 0.05-2), > libdatetime-locale-perl (= 1:1.25-1), > libdatetime-perl (= 2:1.52-1), > libdatetime-timezone-perl (= 1:2.38-1+2019c), > libdb5.3 (= 5.3.28+dfsg1-0.6), > libdebconfclient0 (= 0.251), > libdebhelper-perl (= 12.9), > libdevel-callchecker-perl (= 0.008-1+b1), > libdevel-size-perl (= 0.83-1+b1), > libdevel-stacktrace-perl (= 2.0400-1), > libdigest-hmac-perl (= 1.03+dfsg-2), > libdpkg-perl (= 1.19.7), > libdynaloader-functions-perl (= 0.003-1), > libelf1 (= 0.176-1.1), > libemail-date-format-perl (= 1.005-1), > libemail-valid-perl (= 1.202-1), > libencode-locale-perl (= 1.05-1), > liberror-perl (= 0.17029-1), > libeval-closure-perl (= 0.14-1), > libexception-class-perl (= 1.44-1), > libexpat1 (= 2.2.9-1), > libexporter-tiny-perl (= 1.002001-1), > libfcgi-perl (= 0.79-1), > libfdisk1 (= 2.34-0.1), > libffi7 (= 3.3-3), > libfile-basedir-perl (= 0.08-1), > libfile-find-rul
Bug#953811: lintian: handle ADTTMP fallback code
On Sat, Mar 14, 2020 at 01:09:48AM +, Thorsten Glaser wrote:
> >Debian tool that is within our locus of control, so I would very much
> >prefer that src:devscripts is fixed instead of preventing Lintian
>
> Oh… looking at it now, it appears that the sid version is indeed fixed.
>
> I’ll be keeping this though, for now… I may need it for backports.
AUTOPKGTEST_TMP is set by sadt since version 2.18.2, which is older than
the version in buster, and available even in stretch-backports…
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#953554: Please permit Debian revisions with 1.0 native packages
On Tue, Mar 10, 2020 at 10:19:39PM +0100, Guillem Jover wrote: > > E: chiark-tcl-applet source: malformed-debian-changelog-version 1.0-1~ > > (for native) > > > > For the reasons above I disagree with calling this an error. > > Previously it was a warning. (Full disclosure: I know the dpkg > > maintainer disagrees with my position here.) > > …would you be amenable to instead change the way you version these > kind of packages, and use some other marker instead of «-»? Say «+» or > a word like «rev» like in «1.0rev1» or similar construct? > > Which would give you the properties you look for, while not messing > with the semantics of the source and version formats, so that we can > keep them consistent? I'm with this. doing 1.0+1, 1.0+2, etc would trigger my versioning OCD much less than 1.0-1, 1.0-2 for native packages. Ian: how does this proposal sound to you? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#953554: Please permit Debian revisions with 1.0 native packages
On Tue, 10 Mar 2020, 3:51 pm Ian Jackson, wrote: > Package: lintian > Version: 2.55.0 > > I am packaging a small program for which I am the upstream. It does > not make sense to use a complicated source format; 1.0 native is > perfect. > There is no such thing about "1.0 native". I'm sure you know that very well! ;) What separates a "native" and "not native" in 1.0 is the presence of a .diff.gz file besides the upstream tarball, and afaik lintian checks that to decide on this. E: chiark-tcl-applet source: malformed-debian-changelog-version 1.0-1~ > (for native) > > For the reasons above I disagree with calling this an error. > Previously it was a warning. In my opinion your statements here doesn't make any sense: using a Debian revision when you are not relying on a single upstream tarball (i.e., non-native) really is going against the implied meaning of a Debian revision: something that is not supposed to change the upstream part. If you want to separate the Debian and upstream parts please go and use a non-native source format, be it 1.0 or 3.0... saying that you want to use a native source format but still separate the upstream part it's just plain odd. >
Bug#953099: lintian: FPOS for pkg-config-references-unknown-shared-library
On Wed, Mar 04, 2020 at 09:14:40AM -0800, Felix Lechner wrote: > On Wed, Mar 4, 2020 at 5:33 AM Mattia Rizzolo wrote: > > xml2 is clearly a direct dependency of libxslt1-dev, and 'libxml2.so' is > > shipped by libxml2-dev which is a direct dependency of libxslt1-dev > > The way I understand pkg-config, the libraries listed do not have to > be direct prerequisites (i.e. the extra math library of old, -lm). I don't know what "direct prerequisites" means in your sentence above, but I feel like I agree with you :) > Lintian cannot test for all prerequisites without unpacking all build > requirements and, in effect, attempting a build. > > I would like to remove this tag from Lintian. Indeed, https://bugs.debian.org/920699 doesn't show much thought for this fact. It feels to me that just removing this is kind of a waste… But yes, lintian has no access to anything external from the single package, and it can't know the contents of the dependencies. So indeed perhaps this tag might just be impossible to implement correctly with lintian's limitations. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#953099: lintian: FPOS for pkg-config-references-unknown-shared-library
Package: lintian Version: 2.55.0 Hi, in src:libxslt, I get this: W: libxslt1-dev: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/libexslt.pc -lxml2 (line 12) N: N:The specified pkg-config(1) file references a shared object via, for N:example, Libs: -lfoo but this package appears to not ship the associated N:"libfoo.so" shared library. N: N:This will result in a linker error and was likely caused by a missing N:installation step. N: N:Please ensure that your package ships the corresponding libfoo.so shared N:object file. N: N:Refer to the pkg-config(1) manual page and N:https://bugs.debian.org/919180 for details. N: N:Severity: normal, Certainty: possible N: N:Check: shared-libs, Type: binary, udeb N: W: libxslt1-dev: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/libxslt.pc -lxml2 (line 12) of course it doesn't '"hip the associated "libfoo.so" shared library'… xml2 is clearly a direct dependency of libxslt1-dev, and 'libxml2.so' is shipped by libxml2-dev which is a direct dependency of libxslt1-dev, as well as being installed while this lintian was running. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#949715: lintian: add check that ${python3:Versions} should not be used in Depends
On Thu, Jan 23, 2020 at 05:55:04PM -0500, Daniel Kahn Gillmor wrote:
> dpkg-gencontrol: warning: package python3-gpg: substitution variable
> ${python3:Versions} unused, but is defined
>
> Thinking i knew what i was doing, i added ${python3:Versions} to the
> Depends: line of python3-gpg in debian/control.
>
> It turns out i actually have no idea where the ${python3:Versions}
> substvar *should* be used in debian/control, but it should certainly
> never be used in Depends:.
That's the historical remains of a previous implementation of something
I don't even recall anymore. It's meant to contain the list of python
versions the package is built for.
If you notice, some package have a `XB-Python-Version` field, and that's
the field ${Python3:Versions} is supposed to go into.
> I'm assuming that this substvar came from dh_python3 from the dh-python
> package, so i'm marking this bug as affecting dh-python.
I'm not sure how the "affect" is meaningful or indeed useful here, but
whatever :)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#949063: lintian: manpage-without-executable doesn't consider anymore other binaries from the same source
Package: lintian Version: 2.45.0 manpage-without-executable says: N:Each manpage in /usr/share/man should have a reason to be there. This N:manpage does not appear to have a valid reason to be shipped. N: N:For manpages in sections 1 and 8, an executable (or a link to one) N:should exist. This check currently considers all installation packages N:created by the same sources, as long as they are present. but I have it triggered here: I: scribus-data: manpage-without-executable usr/share/man/de/man1/scribus.1.gz I: scribus-data: manpage-without-executable usr/share/man/man1/scribus.1.gz I: scribus-data: manpage-without-executable usr/share/man/pl/man1/scribus.1.gz Clearly, the scribus binary exists, but it lives in the scribus package. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#947671: lintian: please warn if orphaned package is maintained in a private space
Package: lintian
Version: 2.42.0
There is orphaned-package-not-maintained-in-debian-infrastructure that
is somewhat similar, but I'd like if you can also check for package
maintained in private spaces, i.e. anything that is not
https://salsa.debian.org/debian/
https://git.dgit.debian.org/
as at that point is most likely not accessible to those doing QA
uploads.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#944260: lintian: Add a detection/tag for when compat is >> 10 and cdbs in build-depends
On Wed, Nov 06, 2019 at 06:08:15PM -0500, Thomas Ward wrote:
> Possibly. Perhaps I should go the Policy route and inquire whether we
> should consider CDBS obsolete by later versions of Debian policy...
"Obviously" the Policy has nothing at all to do with things such as
debhelper and cdbs, since it's describing the lower-level side of those
tools.
That said, I also agree that lintian has nothing to do at this time,
packages using cdbs will just FTBFS and that's it. And you can just
move from cdbs to dh and most likely everybody else will only be
happier :)
https://trends.debian.net/#build-systems
You also should not bother with people not test building their packages
before uploading (personal suggestion).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#944462: lintian: Check for debhelper and the use of misc:Pre-Depends missing
On Sun, Nov 10, 2019 at 01:43:22PM +0100, Sven Geuer wrote:
> since v12 debhelper requires the use of misc:Pre-Depends. The manpage [1]
> says:
>
> [...]
> This change makes dh_installinit inject a misc:Pre-
> Depends for init-system-helpers (>= 1.54~). Please ensure
> that the package lists ${misc:Pre-Depends} in its Pre-
> Depends field before upgrading to compat 12.
> [...]
>
> It seems to me this requirement is not honored well by recent debian packages.
> A new check and tag debhelper-but-no-pre-depends should be introduced
> therefore.
May I suggest instead that debhelper itself checks for this, and errors
out if Pre-Depends is missing?
That looks like the easy kind of check, and it's terribly easy to miss.
Also, it's only relevant for some of the packages running
dh_installinit, it would only be noise in the other majority of the
packages not using such helper.
Indeed, I'd suggest to debhelper to just start erroring out if they want
to add a substvars, but said substavar is missing in d/control. Either
that, or hack it in dh_gencontrol, so it forcibly push the missing
fields with `dpkg-gencontrol -D` (this would also help clearing out the
"empty" 'Depends: ${misc:Depends}' a few packages have).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#934322: Split reporting code from Lintian proper
On Sun, Aug 11, 2019 at 01:30:51PM +0100, Chris Lamb wrote: > > > How would this work? We don't install the lintian binary package on > > > lindsay.debian.org so this wouldn't bring in extra dependencies > > > automatically. > > > > I slowly figured that out with help from olasd and adsb. Why are we > > not limiting ourselves to backports on lindsay? > > I do not know the historical reason. Perhaps it makes sense I cannot > install packages but also it might make sense that we can deploy misc/ > random changes from Git. It definitely happened more than once in history that lindsay was running on a commit that was slighly different than the released one. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#930679: Please add overridable tag for not using dh sequencer
On Sun, Aug 04, 2019 at 11:05:23PM +0100, Chris Lamb wrote: > Somewhat related, but if we introduce this mooted "package-does-not- > use- dh-sequencer" we need to work out what to do with: > > https://lintian.debian.org/tags/package-does-not-use-debhelper-or-cdbs.html > > One thing we can probably all agree with is that the severity of > package-does-not-use-debhelper-or-cdbs should be equal to or exceed > the severity of package-does-not-use-dh-sequencer as one is a logical > subset of another. I just reported 3 bugs (#933901, #933902, #933903) with false positives of that tag. I just looked a bunch of them and couldn't find a single true positive, so I think that tag should be reviewed before bumping its severity. I think those bugs should be squashed, reviewed, and then bumped to W. Only once there are very few packages with that should package-goes-not-use-dh-sequencer be bumped to W as well. (note that package-does-not-)se-debhelper-or-cdbs does not emit for classic-style debhelper rules files.) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#933903: lintian: false positives for package-does-not-use-debhelper-or-cdbs
Package: lintian Version: 2.16.0 A couple more false positives: python-pbcommand/1.1.1-1 this actually uses dh steptalk/0.10.0-6 this really usese cdbs -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#933902: lintian: false positive for package-does-not-use-debhelper-or-cdbs
Package: lintian
Version: 2.16.0
Similarly to the last bug, java packages using javahelper (see for
example src:jesd, version 0.0.7-4) use cdbs as their "backend".
See /usr/share/cdbs/1/class/javahelper.mk
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#933901: lintian: false positive for package-does-not-use-debhelper-or-cdbs
Package: lintian
Version: 2.16.0
I went looking to the tag page of this after your message in #930679,
and I noticed a number of qt-kde packages, like akonadi-calendar version
418.08.3-1.
Those packages using
/usr/share/pkg-kde-tools/qt-kde-team/3/debian-qt-kde.mk are false
positives, as they (eventually) call `dh` I'm not sure how to properly
categorize them, if using `dh` or their own buildsystem, but they
shouldn't emit this tag.
In particular, I didn't check what classification tag they emit.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#930679: Please add overridable tag for not using dh sequencer
On Sat, 3 Aug 2019, 5:57 pm Chris Lamb, wrote: > So, Haskell packages use cdbs calling into a > Haskell-specific hlibrary.mk. > > I mean we could certainly just whitelist all of src:haskell-*, but > isn't the entire point of this tag to ask people to move to the dh > sequencer? Or is it "actually fine" for them to use hlibrary.mk and > this will just save the Haskell team whole bunch of boilerplate > overrides with an identical explanation? > I think in the long run, haskell should move to dh as well. ISTR in the past somebody actually started writing a dh-haskell "buildsystem" as well, but it had some shortcomings and the thing was abandoned before it got good enough to be used. I think you should whitelist all Haskell packages for now: once a dh tool/buildsystem to deal with Haskell packages is ready, most likely *all* Haskell packages will move at once, at which point that exception can be lifted. Anyway, CCing d-haskell@ for input as well. > > > c) The severity (ie. E/W/I/P) > > > > I'd recommend starting out with warning. Some day it might move to > > error, but I think starting out there would be overly aggressive. > > My experience of Lintian suggests that W: would be too strong to start > with. Sam, would you be okay with "I:" to begin with? > Yes I sounds much better than W.
Bug#932729: lintian: please start uploading to buster-bpo
Source: lintian Dear lintian maintainers, Could you please upload the latest release also to buster-bpo, together with stretch-bpo that you already did? TIA! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#930109: lintian: fpos for source-contains-prebuilt-doxygen-documentation
Package: lintian
Version: 2.15.0
Hi,
I notice lintian flags src:pencil2d with
source-contains-prebuilt-doxygen-documentation, however to the best of
my knowledge the file marked as such is is a custom header, and not a
built doxygen doc.
The file in question can be found on recent (0.6.2+) versions of
pencil2d in the archive, as util/docs/header.html. Lintian seems to
detect this line within the file:
which matches this expression from cruft.pm:
if($blocknumber == 0) {
if(index($block,' -1) {
if($block =~ m,http://www.doxygen.nl/manual/config.html#cfg_html_header which would
mark this file as a template for doxygen, rather than a built doxygen
doc.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#929577: lintian: Please keep the version in buster up to date
On Sun, May 26, 2019 at 08:40:29PM +0100, Chris Lamb wrote:
> Beyond using the version number mathematics
> work, were you thinking of anything else here?
nope, just the usual lower-than/greathr-than relationship.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Bug#929577: lintian: please keep buster up2date
Source: lintian
Version: 2.9.1
Hi,
I'm not sure what happened, but the backports master decided to grant an
exception to lintian so the version in stretch-bpo is higher than the
version in buster. I don't really buy their reasoning, but even so, I'd
appreciate if you lintian maintainers could properly file unblock
requests and get the version in buster updated as well.
I know that most of your changes don't respect the freeze policy, but
given that on February the release team granted an exception, maybe they
will again.
My position here comes mainly as a mentors.debian.net maintainer, where
we are now running buster, and apparently we now have a 3-months old
lintian due to this, whereas stretch-bpo would have been more updated…
Also, regardless of whatever the backports master grant, please do try
to end up with a proper upgrade path from stretch-bpo to the final
buster.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables
On Sat, May 25, 2019 at 09:56:15AM +0200, Graham Inggs wrote:
> How about emitting an info level tag when one of the less common
> dpkg-architecture variables is used, and proving some hints regarding
> the correct usage?
No, please don't.
tags of kind "this is unusual, are you really sure you want to do just
that?" are god only if the rate of false positives is really low. This
is not the case.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#928809: lintian: suggest adding gitlab-ci file
On Wed, 22 May 2019, 11:30 pm Chris Lamb, wrote: > (Personally, I doubt someone would fork Lintian, more likely its > output would become less and less "trusted". But both outcomes suck.) > Rather, people who until at some point diligently read the whole lintian output for every single upload they do, may just decide that it is too bothersome to do it anymore, and STO reading it.
Bug#928809: lintian: suggest adding gitlab-ci file
On Fri, May 17, 2019 at 08:58:03AM +0100, Chris Lamb wrote: > Wwat would you say this only triggered if the package had a testsuite > or autopkgtests? As Dmitry mentioned in a later mail, that would be wrong. > > I don't think test-building the whole package every commit is useful > > Can you elaborate why? I find this a somewhat curious statement > in 2019. Maybe I'm just too old-fashioned despite being in the youngest generation of DDs.. :D I usually try to think of the archive itself a QA staging point, where things are tested, that's why I don't really want to bother nor be bothered about testing more often. If I'm doing a change that I know can effects on autopkgtests, piuparts or stuff I just test that single change myself, otherwise I'll rely on the automatic checks that are performed after the upload to unstable, without checking twice that every and each commit also conforms to the standards expected of a package in the testing suite. > (This kind of conversation always makes me wonder if we need another > level of "extra pendatic" that people need to opt into... *g*) Nah. I just think that lintian should be less pro-active at adding checks for things that are far from accepted. And as usual I'd love of somebody else could chime in, somebody else other than me disagreeing, the OP, and the maintainer… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#928809: lintian: suggest adding gitlab-ci file
On Sun, May 12, 2019 at 02:27:51PM -0400, Chris Lamb wrote: > Mattia, just to gauge your opinion, what would you hypothethically say > to a "P:" check for this and, separately, the current "I:" autopkgtest > check? I only say that, out of 24 packages listed in my ddpo, 4 already have gitlab-ci enabled to run their own tests (and they are all native or pseudo-native packages). Of the remaining perhaps only 1 or 2 more packages would make sense to have a CI for, but I have no interest whatsoever to test the remaining at every commit, and for quite a few of them it wouldn't even make sense since they lack a testsuite (and no, I don't think test-building the whole package every commit is useful, the only case where I find a full test build useful is when that is run on architectures I don't usually use, which is not the case here; also, for that we have the buildds). So, an hypothetical P check for a .gitlab-ci.yml file would just be another check that ends up in my ignore list… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#928809: lintian: suggest adding gitlab-ci file
Hi,
On Sat, May 11, 2019 at 02:49:02PM +, Dmitry Bogatov wrote:
> please add suggestion that if Vcs-Git points to salsa.debian.org,
> CI should be used.
Please, don't.
For most of my packages, I don't want to bother with setting up a CI,
neither I see any use for it, and I don't think lintian should bother me
more with that (there already is the tag about autopkgtest that way too
often is just causing noise for me).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#922557: lintian: Please check whether there's an expected orig tarball signature
On Mon, Feb 18, 2019 at 02:30:05AM +0100, Guillem Jover wrote:
> It would be nice to get a warning to avoid this. I imagine a tag
> could be emitted whenever there is no «*.orig.tar.*.asc» (for each
> «*.orig.tar.*») and either of the following holds:
>
> - there is a debian/upstream/signing-key.asc file.
> - there is pgpmode or pgpsigurlmangle in opts in debian/watch.
There is already such a tag, orig-tarball-missing-upstream-signature.
That's a .changes checks, not a .dsc one, so it would be emitted only
for -1.
Indeed it probably makes sense to turn this into a .dsc tag, that would
also have the added benefit of being emitted in lintian.d.o as well
(where there are no .changes files to check).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#921573: lintian: binary-from-other-architecture only works sometimes
On Thu, Feb 07, 2019 at 04:52:26PM +0100, Chris Lamb wrote:
> You don't still have it, so no worries. I don't get what the big
> deal is. :)
For the advantage of everybody, here are links to the cross-builds from
amd64 to mips64el and arm64 of procmail.
just dget this url (which is more convenint than attachment to the BTS…)
https://volatile.mapreri.org/2019-02-17/4cd8a58f48ab2d24e9b9387df580de93/procmail_3.22-26_arm64.changes
https://volatile.mapreri.org/2019-02-17/130da1c8cbfd405daeb1a7d0a51f536d/procmail_3.22-26_mips64el.changes
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#920314: lintian: vcs-field-has-unexpected-spaces has false positives
On Wed, Jan 23, 2019 at 08:55:34PM -0500, Jeremy Bicha wrote: > I think all of these are false positives except for rust-num-cpus. > > https://lintian.debian.org/tags/vcs-field-has-unexpected-spaces.html Really none of them are: * vcs-git git://git.debian.org/mirrorer/inoticoming.git --branch debian -> s/--branch/-b/ * vcs-git -b dpkg https://anonscm.debian.org/git/pkg-request-tracker/libmodule-install-rtx-perl.git -> move the `-b dpkg` to the end, policy says it needs to be there * vcs-hg http://youpibouh.thefreecat.org/loadlin/loadlin.hg/ -b debian -> -b is not valid for vcs-hg according to policy * vcs-git https://salsa.debian.org/rust-team/debcargo-conf.git src/num-cpus -> this one probably wanted to wrap "src/nom-cpus" in square brakets, as that's a syntax understood by vcswatch to say "inside this subdirectory". Not sure if lintian already knows of that, and last I checked policy had yet to integrate that change. So I think the only reasonable things to do here are only: * if you think -b is needed in vcs-hg, open a bug in policy * check if the "[subdirectory]" syntax is understood by lintian and check the progress status in policy -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#919162: lintian.d.o apears to report many failures twice
On Wed, Jan 16, 2019 at 11:03:25PM +, Chris Lamb wrote:
> TIL we check both x86 architectures. Why do we do this out of
> interest? Are there examples of tags we would only find on one but
> not the other...?
At the very least, the tag checking for LFS (large file support) is
emitted only on i386 binaries. I expect there can easily be some other
similar cases.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#918306: wrong-section-according-to-package-name is wrong about hyphen-en-us
Control: forcemerge 913723 -1
Hi dkg,
On Fri, Jan 04, 2019 at 05:05:27PM -0500, Daniel Kahn Gillmor wrote:
> when checking the hyphen source package, lintian claims:
>
> I: hyphen-en-us: wrong-section-according-to-package-name hyphen-en-us =>
> localization
>
> but all hyphen-* packages are Section: text, as hyphen-en-us is. (see
> the source for libreoffice-dictionaries, which supplies most of the
> other hyphenation packages).
See #880701 - followed by #913723
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#915384: lintian: check that debian/copyright has an entry for each component
On Mon, Dec 03, 2018 at 02:27:05PM +0100, Xavier wrote: > Le 03/12/2018 à 14:22, Chris Lamb a écrit : > > Xavier wrote: > > > >> # debian/watch > >> https://main/ main-(\d[\d\.]+)\.tar\.gz > >> opts="component=comp1" \ > >>https://comp/ comp-(\d[\d\.]+)\.tar\.gz > >> > >> In this example, a debian tool like gbp will unpack comp_1.0.orig.tar.gz > >> into "comp1/" directory > > ^ > > And this comes from parsing the `opts="component=comp1"` bit, not from > > anywhere else? > > ~Yes, for gdb DD must either add some "--component" in command-line *or* > set it in gbp.conf: > > [DEFAULT] > component = [ 'bson', 'mongodb-core', 'requireoptional' ] > > So only debian/watch is reliable. There are no other files that rely on > this except debian/rules but in many ways... You are missing that this feature comes from dpkg-source, so the list of components can be naturally gathered from the .dsc. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#505857: debian-watch-file-should-mangle-version doesn't detect dversionmangle=auto
Control: found -1 2.5.112
Control: notfound -1 2.5.113
Control: close -1 2.5.113
On Sun, Nov 25, 2018 at 10:46:19AM +0100, Bertrand Marc wrote:
> Indeed, this is fixed with lintian 2.5.113.
Then please try to pay attention to the bug metadata you write while
filing bugs, you explicitly wrote "Version: 2.5.113".
I'm closing this bug as fixed in 2.5.113. I see it was open ten years
ago, and many things changed since then. I believe the original report
was also taken care of, and if there are still false positives for this
specific tag I recommend people to open new bugs clarifying what syntax
they are using.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version
On Thu, Nov 22, 2018 at 02:14:13PM +0100, Guillem Jover wrote:
> Having an explicit check for the symbols stuff would be nice, but I
> think it's besides the point. In the same way epochs in upstream
> version are problematic, dashes in upstream versions are too IMO.
Since a few Policy revisions epochs (well, colons actually) are
forbidden in the upstream part of a version string.
And IIRC the reasoning was very similar to the dashes you are talking
about in this bug: confusion for human, and easy for programs to get
them wrong (think about people .split(':') or version string forgetting
to limit the split to 1, same for the dashes...).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#913761: lintian: debian-watch-file-should-mangle-version does not recognize @DEB_EXT@
On Wed, Nov 14, 2018 at 10:30:22PM +0100, Sebastian Ramacher wrote: > From man uscan: > >@DEB_EXT@ >This is substituted by the typical Debian extension regexp > (capturing). > > [\+~](debian|dfsg|ds|deb)(\.)?(\d+)?$ > > > lintian however does not recognize @DEB_EXT@. For a debian/watch file > including > dversinmangle=s/@DEB_EXT@// lintian incorrectly reports > debian-watch-file-should-mangle-version. Example debian/watch that exhibits > this > issue: > > version=4 > opts="uversionmangle=s/.pre/~pre/,dversionmangle=s/@DEB_EXT@//,repacksuffix=+ds1" > \ >https://github.com/intel/gmmlib/tags \ >(?:.*?/)intel-gmmlib@ANY_VERSION@\.tar\.gz Just a note, please also make sure lintian understands dversionmangle=auto (which is the same as dversionmangle=s/@DEB_EXT@// atm). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#912912: lintian: please detect for loops without set -e
Package: lintian
Severity: wishlist
See #912910 - I think these situations could easily be detected by
lintian, and marked with an E-tag when d/rules doesn't.
Reference: Policy §4.6
bad bad bad:
for var in $(things_to_to_loop_on); do \
$(whatever); \
done
"good":
set -e ; for var in $(things_to_to_loop_on); do \
$(whatever); \
done
Note however that the set -e could be omitted if one has
SHELL=sh -e
or
.SHELLFLAGS=-ec
or similar (even if *personally* I find using such means somewhat
obscure).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: scripting automated lintian fixes
Hi, On Tue, Oct 16, 2018 at 07:38:05PM +0200, Ondrej Novy wrote: > út 16. 10. 2018 v 15:47 odesílatel Chris Lamb napsal: > > > > * Build-Depends: debhelper (>= 11~?) → Build-Depends: debhelper- > > > >compat (= 11) and rm debian/compat. > > > > > > please don't (yet). > > > > Don't what yet, exactly? It's not as if committing it to some Git repo > > will magically change the archive contents! > > > > don't do proposed change in globally (mass commiting), because it have some > compatibility issues. Ask Mattia for details, he told me :) The debhelper documantion now actually mention that feature, in debhelper(7), section COMPATIBILITY LEVELS. I am basically doing that change pretty much in every package I touch, but the limits are mostly on backport costriction (Ubuntu xenial(-backports) doesn't have a new enough debhelper, but Debian stretch-backports does), and in case of very odd packages as it doesn't support architecture and build profiles restrictions. But I'm also worried about people not knowing of this very new feature and being surprised to see d/compat gone… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#910334: lintian: Please warn about redundant entries in Files-Excluded
On Thu, Oct 04, 2018 at 10:40:53PM +0100, Chris Lamb wrote:
> I am, of course, an idiot.
Please, I really appreciate the huge work you are throwing at lintian
nearly every day, including the openess to constantly looking for more
things to check! :)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#910334: lintian: Please warn about redundant entries in Files-Excluded
On Thu, Oct 04, 2018 at 09:55:31PM +0100, Chris Lamb wrote: > https://lintian.debian.org/tags/source-includes-file-in-files-excluded.html > > … which triggers when a file specified in the Files-Excluded field in > debian/copyright exists in the source tree, we could also check for > seemingly-redundant entries such as: > > Files-Excluded: ./file-does-not-exist > > This would catch typos and strange things such as #910330. I'm concerned as to how you would go about checking for this. You can't quite check for non-existent files that shouldn't be existing anyway... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#910210: lintian: false positive for testsuite-dependency-has-unparsable-elements "\n @"
Package: lintian
Version: 2.5.107
I just got
W: devscripts source: testsuite-dependency-has-unparsable-elements "\n @" (in
paragraph starting at line 1)
When using:
mattia@warren ~/devel/debian/devscripts/devscripts (git)-[master] % cat
debian/tests/control
Tests: shunit2
Depends:
@,
build-essential,
debhelper,
faketime,
git,
gnupg,
libdistro-info-perl,
libipc-run-perl,
libmoo-perl,
libwww-perl,
mozilla-devscripts,
python3-debian,
python3-pyftpdlib,
shunit2,
wdiff,
zip,
Restrictions: allow-stderr
mattia@warren ~/devel/debian/devscripts/devscripts (git)-[master] %
But as far as I can see both dpkg-source and autopkgtest parse that just
fine, and
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst
doesn't really say anything against starting with \n, it just says "This
supports all features of dpkg dependencies" which I suppose includes
also starting with \n.
Therefore, I think that this is a false positive from lintian.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#909510: please add a lintian note to inform/warn about python in the shebang (instead of python2/python2.7)
On Mon, Sep 24, 2018 at 07:23:43PM +0100, Chris Lamb wrote: > > please add a lintian note to inform/warn about python in the shebang > > (instead of > > python2/python2.7). > > Thanks for this. Can you draft a very rough tag description for this? > Your following paragraph (re. easy and safe) seems to be a fairly good > place to start. Just noting here that the tag description should also say that if the package uses dh_python2 (and it is throughly applied to all the python files…) just rebuilding the package will fix the situation, starting with dh-python 3.20180313 (from the changelog "dh_python2: rewrite /usr/bin/python shebangs to /usr/bin/python2"). > In addition, just checking that you mean "#!/usr/bin/python" vs "#!/ > usr/bin/python2.7" (not "!#python" or somesuch). TBH, I'd hope lintian already complains (laudly) about #!python ... at a quite high severity even... > Finally, linking to some good/bad packages in Debian would help us > prioritise this effectively. looking at current sid: BAD: mattia@warren ~ % rgrep 'usr/bin/python$' /usr/bin|head /usr/bin/scons:#! /usr/bin/python /usr/bin/cssparse_py2:#!/usr/bin/python /usr/bin/pygmentize:#! /usr/bin/python /usr/bin/dh_python2:#! /usr/bin/python /usr/bin/csscombine_py2:#!/usr/bin/python /usr/bin/pyflakes:#!/usr/bin/python /usr/bin/sconsign:#! /usr/bin/python Binary file /usr/bin/svtplay-dl matches /usr/bin/bzr.bzr:#! /usr/bin/python /usr/bin/markdown_py:#!/usr/bin/python GOOD: mattia@warren ~ % rgrep -E 'usr/bin/python2(\.7)?$' /usr/bin|head /usr/bin/ubuntu-build:#! /usr/bin/python2 /usr/bin/seeded-in-ubuntu:#! /usr/bin/python2 /usr/bin/calibredb:#!/usr/bin/python2.7 /usr/bin/ubuntu-upload-permission:#! /usr/bin/python2 /usr/bin/pyclean:#! /usr/bin/python2 /usr/bin/tkconch:#! /usr/bin/python2 /usr/bin/mailmail:#! /usr/bin/python2 /usr/bin/pbuilder-dist:#! /usr/bin/python2 /usr/bin/backportpackage:#! /usr/bin/python2 /usr/bin/sponsor-patch:#! /usr/bin/python2 -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
