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 <abe@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
Attachment:
signature.asc
Description: PGP signature