Bug#1084833: lintian: uses-deprecated-python-stdlib misses indented imports
Package: lintian Severity: normal It seems the uses-deprecated-python-stdlib tag misses indented imports. A good example is the nova package: https://sources.debian.org/src/nova/2%3A30.0.0-1/nova/virt/disk/api.py/#L44-L45 The error spawns from the regex starting with "^". -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1084465: lintian: GNUstep packages and package-contains-documentation-outside-usr-share-doc
Hi, Thanks for the patch. Please open a Merge Request on Salsa, as it's _much_ easier for us to review code this way. https://salsa.debian.org/lintian/lintian -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1082761: lintian: libjs-async no longer exists in unstable; please change embedded-javascript-library please use libjs-async warning
On 2024-09-25 15:20, Julian Gilbey wrote: Package: lintian Version: 2.118.2 Severity: normal With the node-async 3.2.6+dfsg-* upload, libjs-async has disappeared from unstable, and once it migrates to testing, it will be gone from testing too. Please can this lintian warning be updated to refer to node-async instead of libjs-async (and node-async itself should presumably have an override in lintian for this warning). Best wishes, Julian Hi, Thanks for opening this bug. I'm not sure recommending people use node-async is the right thing to do? libjs-async provided /usr/share/javascript/async/async.js and /usr/share/javascript/async/async.min.js, which is not provided by node-async itself. I'm not very familiar with the JS ecosystem, but it seems a package maintainer that would want to replace an embedded copy of async.js thus couldn't use the new package. Maybe we could just drop the recommendation altogether? Happy to make the change you propose if I'm wrong though. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1062775: lintian: watchfile v3 + DEB_EXT in dversionmangle leads to debian-watch-not-mangling-version
Also, something that would be VERY useful for me to add tests, would be a relatively simple watch file (the one you quoted is a tad complex...) that could be ran with version=2 and version=3, where: * version=2 doesn't dversionmangle * version=3 does indeed dversionmangle I tried a few things, with no avail... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1062775: lintian: watchfile v3 + DEB_EXT in dversionmangle leads to debian-watch-not-mangling-version
On Sat, 03 Feb 2024 08:52:07 +0100 Fab Stz wrote: Package: lintian Version: 2.116.3 Severity: normal Tags: patch Dear Maintainer, Consider this watchfile: version=3 # Search the version number on this page https://download.qt.io/development_releases/qt/6.7/ # Then use downloadurlmangle to transform it to the URL to the archive. # # We don't use repacksuffix=+ds because in salsa-ci we want to have the +ds suffix, even if we use --no-exclusion (ie even if we ignore Files-Excluded) # opts="uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/, \ dversionmangle=s/@DEB_EXT@//, \ oversionmangle=s/$/\+ds.1/, \ downloadurlmangle=s/\/([\d\.]*(-((RC|rc|pre|dev|beta|alpha)\d*))?)\/$/\/$1\/ single\/qt- everywhere-src-$1\.tar\.xz/, \ filenamemangle=s/.*\/([\d\.]*(-((RC|rc|pre|dev|beta|alpha)\d*))?)\/$/qt- everywhere-src-$1\.tar\.xz/" \ https://download.qt.io/development_releases/qt/6\.(?:[\d\.]*)/ ([\d\.]*-.*)/ debian bash debian/scripts/repack.sh Lintian will output: debian-watch-not-mangling-version opts="uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/, dversionmangle=s/@DEB_EXT@//, oversionmangle=s/$/\+ds.1/, downloadurlmangle=s/\/([\d\.]*(-((RC|rc|pre|dev|beta|alpha)\d*))?)\/$/\/$1\/ single\/qt- everywhere-src-$1\.tar\.xz/, filenamemangle=s/.*\/([\d\.]*(-((RC|rc|pre|dev|beta|alpha)\d*))?)\/$/qt- everywhere-src-$1\.tar\.xz/" https://download.qt.io/development_releases/qt/6\.(?:[\d\.]*)/ ([\d\.]*-.*)/ debian bash debian/scripts/repack.sh [debian/watch:12] I suspect this is because lintian considers that @DEB_EXT@ is only valid for a watchfile version >= 4 (see $DMANGLES_AUTOMATICALLY variable), but according to source code in uscan, it seems it requires version >= 2. BTW, I noticed that: - if I use version=4 with @DEB_EXT@, the lintian warning is gone - if I use version=3 + dversionmangle=auto, the lintian warning is gone as well. But version=3 with @DEB_EXT@ triggers the warning. I'm attaching a patch without being sure that it is the correct way to fix the issue, but when it is applied lintian doesn't report a warning. Hi, Looking into this bug, this all seems to make sense and the patch does not break the current testsuite. Before I put some work into writing an additional test to merge this properly, can you tell me where in the uscan source code you see that the dmangling is done automaticall in watch files => 2? Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1078706: lintian: report an error when a package installs a file into an aliased location (merged-/usr, /usr-move, DEP17)
On Wed, 14 Aug 2024 16:53:43 +0200 Helmut Grohne wrote: Source: lintian Version: 2.118.0 Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi lintian maintainers, I am proposing the addition of a new lintian-tag "aliased-location" that is to be emitted for the inclusion of any file below one of the locations /bin, /lib* or /sbin as only base-files should carry the relevant aliasing links and all other packages should move their files as part of the /usr-move transition. At this time, we're below 100 offending source package all of which have a bug report at rc severity. We have a pending policy change making this mandatory. Consequently, I am proposing a check for lintian and attaching a patch. I note that I cannot currently test the patch as lintian fails to build from source. I have filed a separate bug about that. Also note that I am removing the subdir-in-bin tag, because any affected file emits aliased-location with my patch and subdirectories are allowed in /usr/bin, so this tag can no longer be emitted. Please let me know if you have any questions regarding the transition or the patch. Helmut Hi, Thanks for your contribution. Would it be possible to open a Merge Request on Salsa instead? It's much less work for us to do code review there, especially since salsa-ci runs the testsuite automatically. https://salsa.debian.org/lintian/lintian Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1014083: Leaves many mldbm files in /tmp without cleanup
Investigating this bug.
The artifacts created all seem related to ELF items.
Lintian::Storage::MLDBM, which defines a `create` and a `DESTROY`
function, is used by Lintian::Index::Elf.
The latter has `elf_storage` and `elf_storage_by_member` functions, that
do call the `create` function, but never the `DESTROY` one.
Those two functions are then used in Lintian::Index::Item, that define
the `elf` and the `elf_by_member` functions.
These two functions (yes, going down the rabbit hole), are then called
directly all over the Lintian code to actually define checks.
My Perl-foo isn't strong enough yet to know where
`Lintian::Storage::MLDBM->DESTROY('foobar')` should be called, but it
currently isn't and it should be.
A good design would have the `DESTROY` function be called automatically
at when that storage isn't needed anymore, instead of people having to
manually call it once they are done in their check.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
Bug#1080352: lintian: Make Java 21 default
On Mon, 02 Sep 2024 19:52:07 +0200 Bas Couwenberg wrote: Source: lintian Version: 2.118.1 Severity: normal Tags: patch Dear Maintainer, Since the java-common transition (#1076496), Java 21 is now the default in unstable. The attached patch updates the constants accordingly. Kind Regards, Bas Hi, Is there a way this information could be updated automatically in Lintian? We already have a tool (private/refresh-data) that runs different tasks in lib/Lintian/Data/ to update data automatically. Writing something for the java versions would be great. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Removing Jenkins Lintian job
On 2024-09-02 10 h 57 a.m., Louis-Philippe Véronneau wrote: Hello! We currently have a Jenkins job called "lintian-tests_sid" [1] that runs each time something is pushed on the master branch, via a webhook. Is anyone using this? I don't find it very useful, since we're already running tests in salsa-ci. Moreover, Jenkins run after something has been pushed to the master branch, making it somewhat unhelpful to detect breakage before the fact. Finally, it seems the Jenkins test has been broken for months... Is anyone against removing this job? [1]: https://jenkins.debian.net/project/lintian-tests_sid/ It's been more than a week, no one replied, I don't think anyone cares :) If you could remove the job Holger, I would appreciate it very much. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1081316: bug 1081316
I confirm this issue is caused by upgrading libdata-validate-domain-perl from 0.10-1.1 to 0.15-1. Downgrading the package fixes the issue. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1081316: bug 1081316
A quick look around: libdata-validate-domain-perl had a huge bump from 0.10 to 0.15. Since it's the library we're using for that tag, I think there's a link there. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1081316: lintian: FTBFS: the "bogus-mail-host" tag is not emitted anymore
at /home/foo/lintian/lib/Test/Lintian/Run.pm line 343. # Looks like you failed 1 test of 1. debian/test-out/eval/checks/fields/mail-address/legacy-foo++/generic.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests debian/test-out/eval/checks/fields/mail-address/right-to-left-override/generic.t ok debian/test-out/eval/checks/fields/mail-address/two-maintainers/generic.t ... ok debian/test-out/eval/checks/fields/mail-address/watch-file-pgpmode-next/generic.t ..debian/test-out/eval/checks/fields/mail-address/watch-file-pgpmode-next/generic.t .. debian/test-out/eval/checks/fields/mail-address/watch-file-pgpmode-next/generic.t ... ok Test Summary Report --- debian/test-out/eval/checks/fields/mail-address/changed-by-localhost/generic.t (Wstat: 256 (exited 1) Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 debian/test-out/eval/checks/fields/mail-address/mismatch-between-changes-and-source/generic.t (Wstat: 256 (exited 1) Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 debian/test-out/eval/checks/fields/mail-address/legacy-foo++/generic.t (Wstat: 256 (exited 1) Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=37, Tests=37, 9 wallclock secs ( 0.98 usr 1.06 sys + 67.09 cusr 11.71 csys = 80.84 CPU) Result: FAIL The test suite ran for 11 seconds. Offering to re-calibrate the hints expected in tests that failed. Failed test: t/recipes/checks/fields/mail-address/changed-by-localhost -changed-by-localhost (changes): bogus-mail-host Changed-By someone@localhost.localdomain Fix test (y), accept all (a), do not fix (n), quit (q/default)? n Failed test: t/recipes/checks/fields/mail-address/mismatch-between-changes-and-source -mismatch-between-changes-and-source (changes): bogus-mail-host Maintainer ne...@heard.of Fix test (y), accept all (a), do not fix (n), quit (q/default)? nn Failed test: t/recipes/checks/fields/mail-address/legacy-foo++ -foo++ (source): bogus-mail-host Uploaders jeroen@localhost.localdomain Fix test (y), accept all (a), do not fix (n), quit (q/default)? n ----- -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: lintian.debian.org off ?
On 2024-09-03 14:05, Lucas Nussbaum wrote: > On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote: >> FYI, I opened an RT ticket asking DSA for a VM to host all of this. > > Hi, > > I still don't understand the long term strategy here. > > UDD provides the same information. I recently did the work so that it is > properly indexed by search engines, see for example > https://www.google.com/search?q=archive-liberty-mismatch > (it will probably take some time to get indexed by other search engines) > > What is the point in duplicating efforts? > > Lucas > I took for granted that when you said DSA wasn't interested in pointing lintian.debian.org to something else you meant they wanted a replacement for lintian.debian.org. I really, really like UDD and I use it all the time, but I feel there is still some value in having a very lightweight, static website that explains all the tags. The current implementation also provides the lintian man page, but could be extended to have an FAQ. I don't think it would be the role of UDD to host that kind of info. Lintian tags on UDD are much more snappy since you've added the 5000 results limit (I like the improved loading time, but I'm afraid it removes a convenient way to access the data, but that's another debate), but for tags with a lot of results, it's still a pretty large page. For example, uses-deprecated-python-stdlib is a 2.31MB page, because of the large number of results. In comparison, the lintian-ssg result (which also points to UDD) is 69KB. The whole SEO thing isn't my cup of tea, I don't really want to debate that. SEO whatever :P In the end, I don't care about this enough to wage a war or to hurt anyone's feelings. I want to help solving issues with Lintian; this looked like one. If you disagree or really want lintian.debian.org to be pointed at UDD, I'll be happy to assist. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: lintian.debian.org off ?
On 2024-09-02 10:45, Nicolas Peugnet wrote: Hi, On 02/09/2024 03:57, Louis-Philippe Véronneau wrote: Thanks for the work you did trying to fix this issue. Apparently I'm a Lintian maintainer now. I had a quick look at Lintian and lintian.debian.org is referenced in multiple places. It seems like actually fixing lintian.debian.org will be faster and more productive than going wack-a-mole and trying to retcon it ever existing. IF I were to do the job of getting DSA to spin a VM and point lintian.debian.org to it, I'd have to be confident you'll be maintaining the code you wrote in the future. Please be honest :) I don't mind it at all if you tell me: "yeah, that was only a proof of concep", or "I'm motivated now, but I don't know if I'll still be in 3 years". I definitely built it with maintenance in mind. I am willing to maintain this code for as long as possible, but I cannot guarantee that I will be able to do it forever! I will be responsive if contacted by email or if an issue is created on the GitHub repository I also took the time to setup a CI with most of the code properly tested. This should allow to minimize future breakages when modifying the code. Great news! As proposed by Otto, one thing we could do would be to move the codebase to https://salsa.debian.org/lintian/lintian-ssg If you're OK with this, I'll create an empty project and give you permissions on it. If you aren't interested in maintaining that codebase for the next few years, I'll just steal some of your templates and rewrite everything in Python :P One problem I forsee is that if that machine is hosted by DSA, we won't be able to call lintian directly, as everything will need to be installed from Debian packages and that machine will be running Debian Stable. A way to fix this issue would be to point the static generator to a .json file instead. Yes this would only imply very minor changes to the program. The question now would be where should be this file located and how/when/by whom would it be updated? Another option I imagined would be to generate the website on another machine/VM that would run on testing/unstable and then rsync it to the production machine (which is what I am currently doing). Anyways, don't hesitate to contact me if you have other specific needs to simplify the deployment of this website. Thank you for your interest and time. I have a few other ideas, but I'll wait to see what issue tracker you want to keep :) FYI, I opened an RT ticket asking DSA for a VM to host all of this. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1031171: lintian: error with continuous-integration/salsa on source:libvcflib_1.0.7+dfsg-2
retitle 1031171 Check/ContinuousIntegration/Salsa.pm crashes on invalid yaml thanks This issue is caused by invalid yaml in the debian/salsa-ci.yml file: = --- include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml # Does not build on i386 variables: SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 1 = That "SALSA_CI..." variable line should star with a - and it does not. Of course, lintian shouldn't just error and skip the test. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1025452: lintian: useless checks of debian/tests datafiles
title 1025452 spurious warnings emitted when parsing broken ELF files
thanks
Hi,
I think that it's totally normal that lintian flags those files: they
are broken ELF files. The fact they are in debian/tests doesn't change
anything IMO.
Looking at upx-ucl 4.2.4, it seems you managed to override the
elf-warning tag, which is the right thing to do.
I'm changing the title of this bug though, as I agree the warning
messages are spurious: Lintian already emits tags, no need to add other,
unoverrideable warning messages.
The warnings are produced by these lines in lib/Lintian/Index/Elf.pm,
introduced in commit 824cc18145967ab2e00cc33dcff6665d453f8f0e:
--
if (@matches != $TOTAL_FIELDS) {
warn "Parse error in readelf section headers [row $row]: $line";
next;
}
--
The next step would be:
1. remove those lines
2. rebuild lintian
3. test against upx-ucl to see if that removed the warnings
4. run the testsuite to see if something broke
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
Bug#1029187: depends-on-obsolete-package: exessive severity, should be Warning
tags 1029187 pending patch thanks See https://salsa.debian.org/lintian/lintian/-/merge_requests/517 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Removing Jenkins Lintian job
Hello! We currently have a Jenkins job called "lintian-tests_sid" [1] that runs each time something is pushed on the master branch, via a webhook. Is anyone using this? I don't find it very useful, since we're already running tests in salsa-ci. Moreover, Jenkins run after something has been pushed to the master branch, making it somewhat unhelpful to detect breakage before the fact. Finally, it seems the Jenkins test has been broken for months... Is anyone against removing this job? [1]: https://jenkins.debian.net/project/lintian-tests_sid/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1014162: lintian's run-time is too long on some packages
On Wed, 7 Sep 2022 20:11:47 +0200 Christoph Berg wrote: Re: To Debian Bug Tracking System > Version: 2.115.2 > Severity: normal > > Lintian now needs about 3 minutes to check the postgresql-15 source > package alone. Current timings: $ time lintian postgresql-15_15~beta4-1.pgdg+1.dsc 2.115.2 2m29,255s 2.115.3 1m24,698s 2.115.4~git 1m23,866s So it became a lot better, but I think 84s is still too slow for checking a .dsc. Christoph Hi, There's been some work with regards to performance since 2.115.2. I don't know what were the specs of the machine you were running lintian on, but here with a recent AMD laptop and 2.188.1, I get: $ time lintian postgresql-15_15.8-0+deb12u1.dsc real0m31.333s user0m29.634s sys 0m2.672s Which seems reasonable. Can this bug be closed? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: lintian.debian.org off ?
rested in the list of all affected packages. Regards Hi, Thanks for the work you did trying to fix this issue. Apparently I'm a Lintian maintainer now. I had a quick look at Lintian and lintian.debian.org is referenced in multiple places. It seems like actually fixing lintian.debian.org will be faster and more productive than going wack-a-mole and trying to retcon it ever existing. IF I were to do the job of getting DSA to spin a VM and point lintian.debian.org to it, I'd have to be confident you'll be maintaining the code you wrote in the future. Please be honest :) I don't mind it at all if you tell me: "yeah, that was only a proof of concep", or "I'm motivated now, but I don't know if I'll still be in 3 years". If you aren't interested in maintaining that codebase for the next few years, I'll just steal some of your templates and rewrite everything in Python :P One problem I forsee is that if that machine is hosted by DSA, we won't be able to call lintian directly, as everything will need to be installed from Debian packages and that machine will be running Debian Stable. A way to fix this issue would be to point the static generator to a .json file instead. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Joining the Lintian maintainers team
On 2024-08-02 1 h 01 a.m., Louis-Philippe Véronneau wrote: Hello! I've decided I wanted to join the Lintian maintainers team :) I've have been contributing on and off for a few years now and I think I can be of help reviewing merge requests and eventually even making releases. My Perl-foo is still weak, but my Camel Book arrived just as I was leaving for DebConf24 :D Cheers, ping. :P -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Joining the Lintian maintainers team
Hello! I've decided I wanted to join the Lintian maintainers team :) I've have been contributing on and off for a few years now and I think I can be of help reviewing merge requests and eventually even making releases. My Perl-foo is still weak, but my Camel Book arrived just as I was leaving for DebConf24 :D Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1077324: lintian: newly introduced uses-deprecated-python-stdlib a bit overzealous
I've published a patch here: https://salsa.debian.org/lintian/lintian/-/merge_requests/514 I scratched my head quite a bit trying to find possible exceptions to these rules, but a review by other people would be very nice :) Happy to make changes as needed. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1077324: lintian: newly introduced uses-deprecated-python-stdlib a bit overzealous
owner 1077324 Louis-Philippe Véronneau thanks Thanks for reporting this bug! I'll try to fix this during DebConf if I find the time :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
On 2024-05-24 01:55, Andrius Merkys wrote: Hi, On 2024-05-23 23:52, Louis-Philippe Véronneau wrote: On 2024-05-22 16:36, Nilesh Patra wrote: Hi Julian! On Sun, May 19, 2024 at 01:48:17PM +0100, Julian Gilbey wrote: But here I'd suggest doing the opposite: checking for valid build options (and note: this is a check for DEB_BUILD_OPTIONS, not for DEB_BUILD_PROFILES). There is a very short list of standard build options: those listed in dpkg-buildpackage(1) (parallel=n, nocheck, noopt, nostrip, terse, hardening=..., reproducible=..., abi=..., future=..., qa=..., optimize=..., sanitize=...) and https://wiki.debian.org/BuildProfileSpec: nodoc I concur. Thanks also to Andrius for +1. If Pollo/Andrius would like to work on I don't really mind the improvements proposed, but I don't have time to implement them. If no one has, I would suggest merging the code I wrote, as I believe it's better than the status quo :) Since your MR performs a subset of the proposed general check for DEB_BUILD_OPTIONS, I think it can be merged right away and later extended to cover all known DEB_BUILD_OPTIONS. One suggestion would be to use a more generic lintian tag (something like 'debian-rules-invalid-build-profile') so as we can extend it later on instead of creating a new one and superseding your 'debian-rules-invalid-build-profile-nodocs'. Sounds like a plan. I made the changed you proposed and also made sure the tag will output the problematic BUILD_OPTION. That way, when/if someone wants to make it more generic, it'll be possible to pass other invalid BUILD_OPTION. The tag outputted currently looks like: foobar (source): debian-rules-invalid-build-option nodocs [debian/rules:2] Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
On 2024-05-22 16:36, Nilesh Patra wrote: Hi Julian! On Sun, May 19, 2024 at 01:48:17PM +0100, Julian Gilbey wrote: But here I'd suggest doing the opposite: checking for valid build options (and note: this is a check for DEB_BUILD_OPTIONS, not for DEB_BUILD_PROFILES). There is a very short list of standard build options: those listed in dpkg-buildpackage(1) (parallel=n, nocheck, noopt, nostrip, terse, hardening=..., reproducible=..., abi=..., future=..., qa=..., optimize=..., sanitize=...) and https://wiki.debian.org/BuildProfileSpec: nodoc I concur. Thanks also to Andrius for +1. If Pollo/Andrius would like to work on I don't really mind the improvements proposed, but I don't have time to implement them. If no one has, I would suggest merging the code I wrote, as I believe it's better than the status quo :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Enhancing lintian performance for large source packages
On 2024-05-23 16:33, Louis-Philippe Véronneau wrote: On 2024-05-23 13:20, Russ Allbery wrote: Andrius Merkys writes: > Personally, I have never found either of those checks useful to me as a packager. They're both a source of constant annoying false positives and have never once alerted me to a problem that I didn't already know about. I have considered, in the past, arguing that Lintian should remove them entirely given how expensive they are and how prone to false positives they are, but if there were some way that I could easily just opt out (and of course assuming that ftp-master never rejects based on those checks), that would relieve a lot of the pressure. I raised a similar issue in the past and since then, "very-long-line-length-in-source-file" has been marked experimental. As far as I understand, this means the vast majority of people using Lintian won't see it at all. I thought this also meant the check wasn't ran at all, but it seems I'm wrong and it only means the tag is hidden. As such, I would certainly support removing it altogether. For the record, here is the discussion we had about the removal of this tag: https://salsa.debian.org/lintian/lintian/-/merge_requests/430 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Enhancing lintian performance for large source packages
On 2024-05-23 13:20, Russ Allbery wrote: Andrius Merkys writes: > Personally, I have never found either of those checks useful to me as a packager. They're both a source of constant annoying false positives and have never once alerted me to a problem that I didn't already know about. I have considered, in the past, arguing that Lintian should remove them entirely given how expensive they are and how prone to false positives they are, but if there were some way that I could easily just opt out (and of course assuming that ftp-master never rejects based on those checks), that would relieve a lot of the pressure. I raised a similar issue in the past and since then, "very-long-line-length-in-source-file" has been marked experimental. As far as I understand, this means the vast majority of people using Lintian won't see it at all. I thought this also meant the check wasn't ran at all, but it seems I'm wrong and it only means the tag is hidden. As such, I would certainly support removing it altogether. As for checks in Lintian::Check::Files::SourceMissing, I've found those useful in the past (especially for missing JS source code) and I would be against removing / making them opt-in. In any case, thanks a lot for the work on profiling, I think it's super useful! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
tags 1070770 patch thanks I've created a patch on Salsa that creates a new Lintian check for this. https://salsa.debian.org/lintian/lintian/-/merge_requests/504 Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: New release for lintian?
On 2023-10-12 10 h 41, Nilesh Patra wrote: Hi Axel/Bastien, Over the past few days I've tried to merge some of the pending MRs and also push minor changes on the lintian repository. To me it feels like a new release is *long* pending and at this point it *really* needs one given that there are multiple fixes done in salsa in the past months, which also includes a fix for RC bug#1042049 (lintian FTBFS in unstable at the moment). Would you consider to do a review and upload a new release to unstable, please? Let me know. Best, Nilesh Hello! Thanks for your work. If you have time, I had identified the following MRs are "it should probably be OK to merge" in another email I sent to this list: * https://salsa.debian.org/lintian/lintian/-/merge_requests/407 * https://salsa.debian.org/lintian/lintian/-/merge_requests/453 * https://salsa.debian.org/lintian/lintian/-/merge_requests/458 * https://salsa.debian.org/lintian/lintian/-/merge_requests/462 * https://salsa.debian.org/lintian/lintian/-/merge_requests/471 * https://salsa.debian.org/lintian/lintian/-/merge_requests/472 * https://salsa.debian.org/lintian/lintian/-/merge_requests/473 It would be a shame if there was a release without some of those, as a few are trivial (yet pretty important for teams like the Python Team) :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Pending merge requests :)
Hello! I was wondering if one of the lintian maintainers would be up to having a look at the current pending MRs on Salsa. There are quite a few, and merging the ones where the testsuite passes is always a good way to encourage further submissions. After a cursory glance, here is a list of the ones I that look like they are in a good enough state to be merged: * https://salsa.debian.org/lintian/lintian/-/merge_requests/407 * https://salsa.debian.org/lintian/lintian/-/merge_requests/453 * https://salsa.debian.org/lintian/lintian/-/merge_requests/458 * https://salsa.debian.org/lintian/lintian/-/merge_requests/462 * https://salsa.debian.org/lintian/lintian/-/merge_requests/471 * https://salsa.debian.org/lintian/lintian/-/merge_requests/472 * https://salsa.debian.org/lintian/lintian/-/merge_requests/473 Cheers and thanks for maintaining Lintian! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1014255: Long lines should also be ignored from non-code text files
On 2023-08-02 15 h 01, Dr. Bas Wijnen wrote: Hi, Axel writes that README.md and LICENSE are likely valid cases. I disagree. While I (and I expect many developers in Debian) are used to using short lines in text files, this is not that common for other people. Many will use the automatic word-wrap feature of text editors and write a whole paragraph on a single line. I don't think I should ask upstream to reformat their non-code text files; it's not a good use of their time, and also they would likely not even do it. Instead, I hope lintian can avoid emitting this tag for non-code text files (in particular: *.txt, *.html, *.md). Although CMakeLists.txt is probably an exception: that is code and it shouldn't contain long lines. I could add overrides, but I don't think this would be an appropriate case for that. But please let me know if it is. Thanks, Bas Note that the 'very-long-line-length-in-source-file' was marked as 'experimental' in this commit [1] exactly for that kind of reason. The default lintian mode doesn't use the 'experimental' tags and I would advise you not to include them if this tag is currently bothering you. [1]: https://salsa.debian.org/lintian/lintian/-/commit/899bd1b683c479e166ebd465ff0ad101fbd04ee2 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1033294: lintian: detect and warn about Python 2 related paths within packages
owner 1033294 po...@debian.org thanks I'm currently working on a fix for this (the patch is in fact ready, but I'm trying to clean some old python2 code in the same MR). Cheers and thanks for reporting, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
New lintian release?
Hello! Once again, thanks to those who have been reviewing and merging MRs for lintian lately :) I feel significant changes have been made on the git HEAD and a new lintian release would be a good idea. I don't think we're exactly there though, as I see two issues that need to be resolved before a release can be made: 1. it seems "t/scripts/run-private-scripts.t" is broken again? Axel kindly fixed the issue we were having with this script in the testsuite, but I just tried building lintian and it fails with this error: # Failed test 'Exit status 0 of generate-tag-summary' # at t/scripts/run-private-scripts.t line 50. # got: '25' # expected: '0' # Failed test 'STDERR of generate-tag-summary matches (?^:^No tags were added or removed$|\A\Z)' # at t/scripts/run-private-scripts.t line 51. # 'No such file or directory at /<>/private/../lib/Lintian/IPC/Run3.pm line 77. # ' # doesn't match '(?^:^No tags were added or removed$|\A\Z)' # Failed test 'Expected output of generate-tag-summary' # at t/scripts/run-private-scripts.t line 53. # '' # doesn't match '(?^:Assuming commit range to be)' # Looks like you failed 3 tests of 3. # Failed test 'generate-tag-summary' # at t/scripts/run-private-scripts.t line 57 Running the testsuite with `private/runtest` works just fine though... From what I understand, the build testbed isn't the same as the one we use when running the testsuite by itself (like we do in the CI, or with `private/runtest`). I feel this script has been somewhat flaky and my perl-foo isn't good enough for me to fix it :( 2. BTS #1026920 should probably fixed before we upload The version of `file` that breaks the autopkgtest is still in experimental, but it should be uploaded to unstable soon. I've tried debugging the issue (see the BTS), but I think I've hit my perl competence level there... I have no idea how to fix the issue and although I tried reading the perl docs wrt octals in regexes [1], I can't seem to understand it :) [1]: https://perldoc.perl.org/perlrebackslash#Octal-escapes -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1026920: New upstream version of file/libmagic breaks autopkgtest
On 2022-12-23 17 h 44, Christoph Biedl wrote: Package: lintian Version: 2.115.3 Severity: important Greeting, my recent upload of file (1:5.43-3) to experiental broke lintian's autopkgtest. Possibly this is the relevant section. # Hints do not match # # --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/documentation/manual/files-general/hints.specified.calibrated # +++ ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/documentation/manual/files-general/hints.actual.parsed # +files-general (binary): wrong-compression-in-manual-page [usr/share/man/man1/é³¥ã®è©©.1.gz] # # Unexpected tags: # wrong-compression-in-manual-page # # Failed test 'Lintian passes for files-general' # at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343. [ https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian/29591169/log.gz ] While I didn't check what precisely went wrong, I reckon it's a slightly changed output on gz-compressed files. Can you please check and adjust your tests? I'd like to upload to unstable in a week or so, and I'd prefer to have no autopkgtest breakage by then. Sorry for the mess, and I'm sorry this will happen again - upstream changes file's output every now and then. The only help I can provide is to add your package to the list of those that should receive a notification when uploading a new upstream version, see https://sources.debian.org/src/file/1%3A5.41-4/debian/README.Maintainer/#L16 If you want lintian to be included, just say the word. Regards, Christoph I can replicate this bug, but I'm currently having trouble understanding why it happens. My current guess is that the perl regex we're using is getting confused because the output of file's new version spits out octal escape values that we're not sanitizing. Lintian runs file (more precisely, `file --no-pad --print0 --print0 --`) to get the "file_type" value of files [1]. Then, for all the files in "/usr/share/man/", it verifies .gz files are indeed gz-compressed with this perl regex match [2]: if ($item->file_type !~ m/gzip compressed data/) I built the test files Lintian uses for the autopkgtest and when I run file 1:5.43-3 on it, I do get an output that should match that regex: - foo@bar:/tmp/foo/usr/share/man/man1# file -v file-5.43 magic file from /etc/magic:/usr/share/misc/magic foo@bar:/tmp/foo/usr/share/man/man1# file "鳥の詩.1.gz" \351\263\245\343\201\256\350\251\251.1.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 145 - I then downgraded file to version 1:5.41-4 and I got a similar output, but this time, with no octal escape? - foo@bar:/tmp/foo/usr/share/man/man1# file -v file-5.41 magic file from /etc/magic:/usr/share/misc/magic foo@bar:/tmp/foo/usr/share/man/man1# file 鳥の詩.1.gz" 鳥の詩.1.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 145 - My perl-foo is pretty bad, but I guess we should be trying to espace or sanitize that value? I also naively tried to install "fonts-noto", but that didn't help :) [1]: https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Index/FileTypes.pm#L75 [2]: https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Documentation/Manual.pm#L140 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1025644: lintian: should not have the update-debian-copyright tag at all
On 2022-12-06 15 h 13, Russ Allbery wrote: Thorsten Glaser writes: The update-debian-copyright tag gives bad advice: N: The most recent copyright year mentioned for files in ./debian lags N: behind the year in the timestamp for the most recent changelog N: entry. This is a fully normal thing to have. You only update the copyright year for something when *you* do something relevant for copyright law (that is passing the threshold of originality) in that year. Having this tag is misleading because it’ll lead to people bumping the year because they don’t know better and just to silence lintian. Yeah, and I'm also dubious that we should be telling people how to manage their copyright notices at all. Berne explicitly doesn't require copyright notices. Some licenses require them, but I'm not aware of a license where one is required to update them with new years. Some projects use the approach of only updating the years when the files are changed; others update all years on all files every year (the FSF does this, for instance, based on legal advice from their lawyers). This doesn't feel like something Lintian should have an opinion about. I also agree with your reasoning and I would personally be for its removal. I think we should note this was a feature requested in #949201. As such, I've proposed a MR to make this tag experimental for now. I guess if people care about it, they can try to improve it? https://salsa.debian.org/lintian/lintian/-/merge_requests/431 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: please do not remove all tags that are no longer emitted!
On 2022-12-05 03 h 20, Lucas Nussbaum wrote: Hi, As there has been discussions about removing tags that are no longer emitted, I wanted to point that it might make sense to keep those tags for at least three use cases: 1) to check old source packages that were removed from Debian, before they are reintroduced in Debian 2) to check unofficial packages 3) to check old packages while tracking history, as in https://trends.debian.net Regarding trends.debian.net, I use the following tags: debian-build-system debhelper-compat-level source-format patch-system direct-changes-in-diff-but-no-patch-system vcs-fields-use-more-than-one-vcs vcs vcs-uri no-dep5-copyright missing-tests-control debian-rules-missing-required-target rules-do-not-require-root silent-on-rules-requiring-root rules-require-root-explicitly rules-silently-require-root package-is-co-maintained package-is-team-maintained package-is-maintained-by-individual Lucas At least on my end, Russ's last email convinced me working on the current pain points wrt tags that seem to emit a lot of false positives might be a better idea than removing "old" tags. I might propose to remove some (especially targeted at the python ecosystem) if I happen to find they don't serve a purpose anymore and it helps clean code I'm working on, but nothing systematic. I feel discussions like the current one on the removal of the 'very-long-line-length-in-source-file' tag [1] are beneficial and will help us make compromises and move forward though. If I happen to propose a change that would remove a tag you care about, I would highly welcome feedback. Cheers, [1]: https://salsa.debian.org/lintian/lintian/-/merge_requests/430 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too
On 2022-12-01 01 h 52, Stuart Prescott wrote: Hi Scott On 01/12/2022 15:16, Scott Kitterman wrote: On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote: Hi Scott, On 01/12/2022 02:16, Scott Kitterman wrote: Package: lintian Version: 2.115.3 Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org The missing-prerequisite-for-pyproject-backend check appears to only look for the prerequisite packages in Build-Depends, but since they aren't needed for clean, they could be in Build-Depends-Indep, leading to false positives. Scott K I contemplated filing a similar the other day but in writing it up, I realised that lintian was correct. Policy requires that the 'clean' target be functional with only the Build-Depends (and Build-Conflicts) satisfied, and pybuild + the build-backend dependencies are involved in the cleaning step. Not always. At least with the package I ran into this on, clean works fine without them. Yes indeed... - the most obvious case where that works is where 'clean' is explicit in d/rules - it would also be possible for it to work in situations where dh-python is (redundantly?) listed in B-D (not B-D-I), since the pyproject plugin's 'clean' operation has no dependency on `build`, `installer`, and the backend. However, this for this second case: - it might result in pybuild picking a different plugin through lack of dependencies like `tomli`. That might just work... but also feels slightly terrifying. - there's not _currently_ any backend-specific cleaning code, but perhaps there should be, which would then need the deps to be in B-D? (Is that in the spec somewhere?) I guess the main thing to be careful of in any rewording of this explanation is that for the most common case of using "%:\n\tdh --buildsystem pybuild", dh-python (or pybuild-plugin-pyproject) is needed in B-D not B-D-I to be policy-compliant. cheers Stuart I've proposed a fix here: https://salsa.debian.org/lintian/lintian/-/merge_requests/426 It's not precise enough to flag packages that would declare everything as a Build-Depends-Indep though. This would be much more complex and I feel this situation is overall pretty rare. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1016147: lintian: false positive missing-build-dependency-for-dh-addon python3 when using dh-sequence-python3
owner 1016147 po...@debian.org tags 1016147 patch thanks Thanks for reporting this false-positive. I've sent an MR with a patch [1] and tested it against flask-appbuilder 4.1.3+ds-1. It seems to fix the issue. Cheers, [1]: https://salsa.debian.org/lintian/lintian/-/merge_requests/405 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#991955: lintian: Check for incorrect Maintainer/Uploader fields for known packaging teams
Package: lintian Version: 2.104.0 Severity: wishlist Dear maintainers, There is currently code in lib/Lintian/Check/Fields/Maintainer/Team.pm to check if a team-maintained package ends up in the wrong team. It would be nice if it were possible to issue another tag when a team-maintained package uses the wrong email contact, or has the right email contact but the wrong name. For example, mathlibtools was recently uploaded to NEW [1] as part of the Python Team, but used the wrong email contact ( instead of the correct ). I'm sure that kind of mistake happens all the time and it would be nice to be able to lint for it. If code is added for this new tag, I'd be happy to scour the archive and provide you with a list of the many teams in Debian. Cheers, [1]: https://ftp-master.debian.org/new/mathlibtools_1.0.0-1.html -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#926409: lintian: autopkgtest takes very long to finish
Felix asked me to report the performance data for the lintian testsuite I'm getting on my new desktop computer. Let me first say I'm a very casual contributor to Lintian and I'm certainly not in a position to judge if the testsuite takes too much time to run or is too extensive by default. Take this as additional data to make informed decisions :) On my previous desktop computer (AMD FX-8530, 8GB DDR3 RAM, SATA SSD), running the testsuite used to take up to 15mins. Now with the new PC (AMD Ryzen 5900x, 64GB DDR4 RAM, M.2 NVME SSD), it takes less than 3 minutes. This is the result of running `private/runtests` from a newly created git clone of the current master branch: --- All tests successful. Files=1306, Tests=59485, 178 wallclock secs ( 6.85 usr 2.34 sys + 3356.34 cusr 422.52 csys = 3788.05 CPU) Result: PASS The test suite ran for 2 minutes and 59 seconds. --- Then again, that's a brand new machine running top of the line consumer-grade hardware, with a beefy cooler :) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#977419: lintian: Use of uninitialized value in string eq at package-relations.pm
On 2020-12-15 01 h 10, Felix Lechner wrote: > Hi, > > On Mon, Dec 14, 2020 at 9:24 PM Louis-Philippe Véronneau > wrote: >> >> I can reproduce this behavior with supysonic 0.6.2+ds-2: > > Alas, I *cannot* reproduce it with either of the two packages. I tried > both 2.104.0 and our development version (on stable). Are you both on > more cutting-edge releases? Specifically, what is your version of > liblist-moreutils-perl, please? Thanks! I am building in Debian unstable in a schroot using sbuild. liblist-moreutils-perl is also at 0.430-1 in my schroot. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#977419: lintian: Use of uninitialized value in string eq at package-relations.pm
I can reproduce this behavior with supysonic 0.6.2+ds-2: Warning in group supysonic/0.6.2+ds-2: Use of uninitialized value in string eq at /usr/share/lintian/checks/fields/package-relations.pm line 129. E: supysonic: 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: E: supysonic: alternates-not-allowed Suggests -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#976889: classpath-contains-relative-path is a false-positive for libX-clojure packages
On 2020-12-08 19 h 26, Felix Lechner wrote: > Hi Louis-Philippe, > > On Tue, Dec 8, 2020 at 3:33 PM Louis-Philippe Véronneau > wrote: >> >> It seems that when packaging a Clojure package that also has a >> d/libX-clojure.classpath file, the "classpath-contains-relative-path" >> tag is emitted. > > In order to investigate your filing, we require a package reference > (or a pointer to temporary build artifacts, for example on Salsa). > Will you please provide additional details to help us? Thank you! You can have a look at src:core-async-clojure 1.3.610-2 (currently in incoming.d.o). Sadly, the Salsa repo [1] doesn't use Salsa-CI. [1]: https://salsa.debian.org/clojure-team/core-async-clojure -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#976889: classpath-contains-relative-path is a false-positive for libX-clojure packages
Package: lintian Version: 2.104.0 Severity: normal Dear maintainers, It seems that when packaging a Clojure package that also has a d/libX-clojure.classpath file, the "classpath-contains-relative-path" tag is emitted. The tag's description says: "Note, Lintian assumes that all (relative) classpaths pointing to /usr/share/java/ (but not subdirs thereof) are satisfied by dependencies as long as there is at least one strong libX-java dependency." Since Clojure packages also push jars in "/usr/share/java" but aren't named "libX-java", I'm assuming this is a false-positive. In my opinion, this check should also take for granted classpaths are satisfied by strong libX-clojure dependencies. I would like to think I'll have time to submit a patch to fix this problem this week, but if someone else wants to have a go, I certainly won't mind. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#923696: lintian: Bad examples in Lintian::Tutorial::TestSuite
Hi, Kindly bump :) It seems this bug was never closed and the way to call tests has changed once again? I was told `private/build-test-packages && private/runtests` is what one should now run, but it would be great if the CONTRIBUTING.md documentation could be updated to make external contributions easier. Thanks for your work on lintian! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#970743: marked as pending in lintian
On Wed, 23 Sep 2020 19:07:27 +0200 Mattia Rizzolo wrote:
> 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.
I've set aside some time to have a look at this today :)
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
signature.asc
Description: OpenPGP digital signature
