Re: Bug#1012289: RFH: lintian -- Debian package checker
Hi Bastien, Bastien Roucariès wrote: > I will restep to be a lintian maint. Yay, thanks! Much appreciated. You're still in the "lintian" group of Salsa, so you should be still able to commit to the repo. > Could you please prepare a list of urgent action ? Usually, if I consider a lintian bug to be urgent-ish, I bumped its severity to important. (And you bumped one to serious already, too. :-) So anything RC or "important" on https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lintian;dist=unstable is what we should focus on first, if possible. Those marked confirmed are those I already looked at closer: * #993613 * #1014083 * #1014162 Then there are two other topics I have a focus on, because I think, they're important for all of us, because they're annoying: * False Positives: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=lintian-maint%40debian.org&tag=false-positive * Automatically migrating non-bracketed lintian overrides to bracketed ones. I started here, but it's mostly lacking migration regexp mappings for the hundreds of tags being affected: https://salsa.debian.org/lintian/lintian/-/blob/migrate-overrides/bin/lintian-migrate-overrides-to-pointed-hints Note that this is currently only inside a feature branch which is not yet merged as it is far from helpful yet. This is actually my fix for https://bugs.debian.org/1007002 Oh, and one more thing: I want to adhere to Semantic Versioning — the real one (https://semver.org/), not the one which Felix called "Semantic Versioning" despite it wasn't Semantic Versioning. So the versioning from now on will be BREAK.FEATURE.BUGFIX: * Changing configuration semantic or syntax or exit codes will be a BREAK. * Adding new tags will be a FEATURE. * No functional changes except bug fixes will be a BUGFIX. * Pure documentation or build-system changes will be a BUGFIX, too. And probably also: * Renaming tags will be a BREAK. (Feel free to discuss if you disagree. :-)) Not yet sure about: * Will be removing a tag a BREAK, too? P.S.: Yeah, there was a bit of silence (despite not complete silence) from me on lintian, but that was mostly due to holidays (in which was way less online that I expected), some pre-holiday and some post-holidays stress. And also because of RC bugs in some of my other similarily important packages. Expect some more activity on Lintian towards to next weekend. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Re: Bug#1012289: RFH: lintian -- Debian package checker
Le mardi 16 août 2022, 13:37:39 UTC Axel Beckert a écrit : Hi, I have just reinstanced the sliding windows on master. could you please check why autotest fail BTW I am really supprised that test are not run at build time Bastien > Hi Bastien, > > Bastien Roucariès wrote: > > I will restep to be a lintian maint. > > Yay, thanks! Much appreciated. > > You're still in the "lintian" group of Salsa, so you should be still > able to commit to the repo. > > > Could you please prepare a list of urgent action ? > > Usually, if I consider a lintian bug to be urgent-ish, I bumped its > severity to important. (And you bumped one to serious already, too. > > :-) So anything RC or "important" on > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lintian;dist=unstable > is what we should focus on first, if possible. Those marked confirmed > are those I already looked at closer: > > * #993613 > * #1014083 > * #1014162 > > Then there are two other topics I have a focus on, because I think, > they're important for all of us, because they're annoying: > > * False Positives: > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=lintian-maint%40debian > .org&tag=false-positive > > * Automatically migrating non-bracketed lintian overrides to bracketed > ones. I started here, but it's mostly lacking migration regexp > mappings for the hundreds of tags being affected: > > https://salsa.debian.org/lintian/lintian/-/blob/migrate-overrides/bin/linti > an-migrate-overrides-to-pointed-hints > > Note that this is currently only inside a feature branch which is > not yet merged as it is far from helpful yet. > > This is actually my fix for https://bugs.debian.org/1007002 > > Oh, and one more thing: I want to adhere to Semantic Versioning — the > real one (https://semver.org/), not the one which Felix called > "Semantic Versioning" despite it wasn't Semantic Versioning. > > So the versioning from now on will be BREAK.FEATURE.BUGFIX: > > * Changing configuration semantic or syntax or exit codes will be a BREAK. > * Adding new tags will be a FEATURE. > * No functional changes except bug fixes will be a BUGFIX. > * Pure documentation or build-system changes will be a BUGFIX, too. > > And probably also: > > * Renaming tags will be a BREAK. (Feel free to discuss if you > disagree. :-)) > > Not yet sure about: > > * Will be removing a tag a BREAK, too? > > P.S.: Yeah, there was a bit of silence (despite not complete silence) > from me on lintian, but that was mostly due to holidays (in which was > way less online that I expected), some pre-holiday and some > post-holidays stress. And also because of RC bugs in some of my other > similarily important packages. Expect some more activity on Lintian > towards to next weekend. :-) > > Regards, Axel signature.asc Description: This is a digitally signed message part.
Re: Bug#1012289: RFH: lintian -- Debian package checker
Hi Bastien, Bastien Roucariès wrote: > I have just reinstanced the sliding windows on master. Yay, thanks! > could you please check why autotest fail Will do, but probably not before the weekend. > BTW I am really supprised that test are not run at build time The test suite currently runs around 35-40 minutes on my 6 year old 4-core workstation and even longer on Salsa CI (1h30m to 1h45m). (At least those were the numbers when I last measured it. There are a few commits in there now which probably reduce that time a bit.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Re: Bug#1012289: RFH: lintian -- Debian package checker
Hi Bastien, Bastien Roucariès wrote: > could you please check why autotest fail Done now: Lintian's autopkgtest fails on Salsa for a week now because dpatch has been removed from unstable a week ago: https://bugs.debian.org/1010626 (Cc'ed) It seems as if package removals do not take into account autopkgtest dependencies yet. :-/ dpatch seems to be mentioned in 269 files of the test suite. I assume that at least all dpatch related tags can be removed now as there's no point in arguing about dpatch being used (or even used wrongly) if any package using it will FTBFS anyway. Thanks for notifying me of that issue! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Re: Bug#1012289: RFH: lintian -- Debian package checker
Hi Bill, Bill Allombert wrote: > By the way, what happened to lintian.debian.org ? Seems as if someone (not me, just noticed it today when "private/refresh-data" failed…) pulled the plug on at least the DNS name. Probably because it hasn't been updated since Felix' try to rewrite it, which AFAIK was never finished, but the old thing also no more worked. (There's probably a lot of legacy code in "lib/Lintian/Output" related to one of these two website generations, maybe even both.) IMHO it's generally a good thing, except that it would have been better to redirect it to the according UDD pages instead. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: Bug#1012289: RFH: lintian -- Debian package checker
On Mon, 05 Feb 2024 13:20:07 + Bastien =?ISO-8859-1?Q?Roucari=E8s?= wrote: > Le lundi 5 février 2024, 12:42:04 UTC Bill Allombert a écrit : > > On Mon, Feb 05, 2024 at 12:28:02PM +0100, Axel Beckert wrote: > > > Hi Bill, > > > > > > Bill Allombert wrote: > > > > By the way, what happened to lintian.debian.org ? > > > > > > Seems as if someone (not me, just noticed it today when > > > "private/refresh-data" failed…) pulled the plug on at least the DNS > > > name. Probably because it hasn't been updated since Felix' try to > > > rewrite it, which AFAIK was never finished, but the old thing also no > > > more worked. (There's probably a lot of legacy code in > > > "lib/Lintian/Output" related to one of these two website generations, > > > maybe even both.) > > > > I used to generate my own copy of it because the official one was > > out of date. > > Help here is welcome. I really like the l.d.o site particularly the graph > > > > > IMHO it's generally a good thing, except that it would have been > > > better to redirect it to the according UDD pages instead. > > > > Yes, because there are ton of places still linking to lintian.debian.org > > (e.g. wikipedia). We should ask DSA to redirect to salsa or UDD. I just noticed this RFH. The last Lintian dates back from February 2024. Is there any way I can help? At the very least, we need a new release that tests for standards 4.7.0 compatibility ASAP. Martin-Éric
Some questions about dpatch-related checks inside lintian (was: Re: Bug#1012289: RFH: lintian -- Debian package checker)
Hi again, this mail contains several points. I separated them with markdown-like headlines. Removing dpatch stuff from Lintian? --- Axel Beckert wrote: > Bastien Roucariès wrote: > > could you please check why autotest fail > > Done now: > > Lintian's autopkgtest fails on Salsa for a week now because dpatch has > been removed from unstable a week ago: https://bugs.debian.org/1010626 > (Cc'ed) […] > dpatch seems to be mentioned in 269 files of the test suite. I assume > that at least all dpatch related tags can be removed now as there's no > point in arguing about dpatch being used (or even used wrongly) if any > package using it will FTBFS anyway. Then again most of these cases seem to be the same case which was split up in dozen cases (of which most still use but actually don't seem to require dpatch anymore) when the test suite was changed from running all checks against all test suite packages to running just specific checks against each test suite package. In other words: Code duplication and cruft at its best! :-( But this also means that a) in many cases we can just remove all the dpatch cruft without any impact. It's just not yet clear to me which cases those are were we can't remove the dpatch cruft. b) It's currently unclear to me which test suite packages are just checked for source package checks. Those likely don't need dpatch as it's not needed to build the .dsc source package files. So after a first try with removing all traces of dpatch, I decided otherwise and I tried to just remove dpatch from debian/tests/control and see what happens. I used a feature branch called "dpatch-removal" for that (which I likely will force-push occasionally). New test suite failures after dropping dpatch - But what happened was something completely unexpected and unrelated to dpatch: Errors were encountered while processing: emacs-nox dh-elpa autopkgtest-satdep So this time it was the still very RC-buggy emacs 28.1 upload which broke our test suite. *sigh* I guess in this case we just have to wait until the emacs package is fixed again. At least locally we can still use emacs from testing for testing, but that also makes it a bit more annoying if I later need dpatch again in case I need to convert some test package with quilt2dpatch which actually uses dpatch. (Hmmm, quilt ships that script, but has no package relation with dpatch. Isn't that an RC bug?!? SCNR ;-) What about the tags patch-system and more-than-one-patch-system? Another question which popped up is if we still need that classification tag "patch-system" and the warning "more-than-one-patch-system" since these only new about quilt and dpatch and nothing more. So shall we remove these completely? Or keep the dpatch detection? More test suite failures / How to run the test suite Additionally the test suite now fails due to lib/Lintian/Check/Cruft.pm no more being tidy: Failed test 'Test::Perl::Critic for "lib/Lintian/Check/Cruft.pm"' # at /usr/share/perl5/Test/Perl/Critic.pm line 121. # # lib/Lintian/Check/Cruft.pm:82:1:Use '{' and '}' to delimit multi-line regexps # lib/Lintian/Check/Cruft.pm:107:1:Use '{' and '}' to delimit multi-line regexps # lib/Lintian/Check/Cruft.pm:232:17:Useless use of $_ # lib/Lintian/Check/Cruft.pm:238:1:Subroutine "full_text_check" does not end with "return" # lib/Lintian/Check/Cruft.pm:249:21:Subroutine called with "&" sigil # lib/Lintian/Check/Cruft.pm:263:9:"%matchedkeyword" is declared but not used (And after fixing these, some more return-related issues inside full_text_check popped up.) I've tried to fix these. Will push that commit later today if the test suite run currently running here locally doesn't find anything related. (Usually such a run takes around 40 minutes here and I really should go to bed now.) Hint: The test suite can be run by calling "private/runtests" nowadays. P.S.: I'm generally open to changing what perlcritic considers bad and what not inside lintian. For now I just haven't changed anything, but am not 100% happy with the current settings. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Re: Bug#1012289: Some questions about dpatch-related checks inside lintian (was: Re: Bug#1012289: RFH: lintian -- Debian package checker)
Hi, [Dropping the RFH bug report from Cc, at least for now.] Axel Beckert wrote: > More test suite failures / How to run the test suite > > > Additionally the test suite now fails due to > lib/Lintian/Check/Cruft.pm no more being tidy: > > Failed test 'Test::Perl::Critic for "lib/Lintian/Check/Cruft.pm"' > # at /usr/share/perl5/Test/Perl/Critic.pm line 121. > # > # lib/Lintian/Check/Cruft.pm:82:1:Use '{' and '}' to delimit multi-line > regexps > # lib/Lintian/Check/Cruft.pm:107:1:Use '{' and '}' to delimit multi-line > regexps > # lib/Lintian/Check/Cruft.pm:232:17:Useless use of $_ > # lib/Lintian/Check/Cruft.pm:238:1:Subroutine "full_text_check" does not > end with "return" > # lib/Lintian/Check/Cruft.pm:249:21:Subroutine called with "&" sigil > # lib/Lintian/Check/Cruft.pm:263:9:"%matchedkeyword" is declared but not > used > > (And after fixing these, some more return-related issues inside > full_text_check popped up.) > > I've tried to fix these. Will push that commit later today if the test > suite run currently running here locally doesn't find anything > related. (Usually such a run takes around 40 minutes here and I really > should go to bed now.) There were quite some differences in the test output afterwards: diff --git a/t/recipes/checks/cruft/cruft-autogenerated/eval/hints b/t/recipes/checks/cruft/cruft-autogenerated/eval/hints index 3003675de..4831c9deb 100644 --- a/t/recipes/checks/cruft/cruft-autogenerated/eval/hints +++ b/t/recipes/checks/cruft/cruft-autogenerated/eval/hints @@ -1,4 +1,2 @@ -cruft-autogenerated (source): source-contains-data-from-ieee-data-oui-db [src/oui.db/oui.db] -cruft-autogenerated (source): source-contains-autogenerated-visual-c++-file [src/visualc++/positive.cpp] cruft-autogenerated (source): source-contains-autogenerated-gperf-data [src/gperf/gperf.cpp] cruft-autogenerated (source): source-contains-autogenerated-gperf-data [src/gperf/gperf.c] diff --git a/t/recipes/checks/cruft/cruft-bad-php/eval/hints b/t/recipes/checks/cruft/cruft-bad-php/eval/hints index a674da015..8b1378917 100644 --- a/t/recipes/checks/cruft/cruft-bad-php/eval/hints +++ b/t/recipes/checks/cruft/cruft-bad-php/eval/hints @@ -1,3 +1 @@ -cruft-bad-php (source): license-problem-php-license [src/3_01.txt] -cruft-bad-php (source): license-problem-bad-php-license [src/2_02.txt] -cruft-bad-php (source): license-problem-bad-php-license [src/2_01.txt] + diff --git a/t/recipes/checks/cruft/cruft-cc-by-nc-sa/eval/hints b/t/recipes/checks/cruft/cruft-cc-by-nc-sa/eval/hints index 60ac3e73d..ef28c89a4 100644 --- a/t/recipes/checks/cruft/cruft-cc-by-nc-sa/eval/hints +++ b/t/recipes/checks/cruft/cruft-cc-by-nc-sa/eval/hints @@ -1,4 +1 @@ -cruft-cc-by-nc-sa (source): license-problem-cc-by-nc-sa [src/test.xml] -cruft-cc-by-nc-sa (source): license-problem-cc-by-nc-sa [src/test.svg] cruft-cc-by-nc-sa (source): license-problem-cc-by-nc-sa [src/copyright-header.html] -cruft-cc-by-nc-sa (source): license-problem-cc-by-nc-sa [src/ISI_export_format.html] diff --git a/t/recipes/checks/cruft/cruft-gfdl-invariants/eval/hints b/t/recipes/checks/cruft/cruft-gfdl-invariants/eval/hints index 22e8bd3c1..8b1378917 100644 --- a/t/recipes/checks/cruft/cruft-gfdl-invariants/eval/hints +++ b/t/recipes/checks/cruft/cruft-gfdl-invariants/eval/hints @@ -1,37 +1 @@ -cruft-gfdl-invariants (source): license-problem-gfdl-non-official-text invariant part is: without any invariant sections [src/oldfalsepositive/parsewiki.txt] -cruft-gfdl-invariants (source): license-problem-gfdl-non-official-text invariant part is: with the no invariant sections, with the no front-cover texts, and with no back-cover texts [src/oldfalsepositive/partedvariant.txt] -cruft-gfdl-invariants (source): license-problem-gfdl-non-official-text invariant part is: with the invariant sections being no invariant sections, with the front-cover texts being no front-cover texts, and with the back-cover texts being no back-cover texts [src/oldfalsepositive/oidentd.8] -cruft-gfdl-invariants (source): license-problem-gfdl-non-official-text invariant part is: with the front-cover texts being (none) and with the back-cover texts being (none) [src/oldfalsepositive/tla.txt] -cruft-gfdl-invariants (source): license-problem-gfdl-non-official-text invariant part is: with noinvariant sections , with no front-cover texts , and with no back-cover texts [src/oldfalsepositive/gnashfalsepositive.info] -cruft-gfdl-invariants (source): license-problem-gfdl-non-official-text invariant part is: with no invariant sections, with no front-cover texts, and with no back-cover texts [src/oldfalsepositive/patch-c0.diff] -cruft-gfdl-invariants (source): license-problem-gfdl-non-official-text invariant part is: with no invariant sections, with no front-cover texts, and with no back-cover texts [src/oldfalsepositive/make-stds.texi] -cruft-gfdl-invariants (source): license-problem-gfdl-non-official-text