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 <a...@debian.org>, 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