Re: New lintian release?
Hi Louis,
sorry for lagging the past few weeks (or months 🙄), but I didn't
manage to work on Debian stuff before 1st of January although I hoped
to get to it earlier. Too much real-life these days. (Which was nice,
though. 😇)
Louis-Philippe Véronneau wrote:
> I feel significant changes have been made on the git HEAD and a new lintian
> release would be a good idea.
Definitely. Also because I consider it to be (close to) a toolchain
package. It's though (luckily 😎) not on
https://release.debian.org/testing/essential-and-build-essential.txt
> 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?
Yes? Didn't notice anything recently.
> 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
> /<<PKGBUILDDIR>>/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
That error seems to be a real error when calling
private/generate-tag-summary. So the error is not in
t/scripts/run-private-scripts.t but in private/generate-tag-summary
and t/scripts/run-private-scripts.t found that issue. Which is good! 😎
Not sure which file it can't find, though. On a first glance, only git
commands seem to be executed via IPC::Run3 from
private/generate-tag-summary, so I assume it can't find "git" — which
on the other hand would be very weird.
What output does running "private/generate-tag-summary" shows for you?
Anyway, I've built the package and ran the testsuite several times
today locally as well as on Salsa CI and I didn't see this error.
So if you can get some more details about that issue, I'm happy to
help.
> 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`).
Hmmm, initially many *.t files required $LINTIAN_BASE to be set in the
environments (which private/runtest does), but I thought, I found all
which hadn't this yet.
But "prove t/scripts/run-private-scripts.t" works fine for me as of
now, even without "-l" or after a "git clean -dxf". And running
"private/generate-tag-summary" (which the test argues about) works for
me as well. So, no, I currently have not much of an idea about this.
> 2. BTS #1026920 should probably fixed before we upload
Thanks for the heads up. I today mostly went through the open MRs and
the #1025868 RC bug (failing testsuite/autopkgtests on arm64). I've
also already fixed half of the latter. Was caused by a typo by myself
which no test caught. 😒 So I also wrote a test for it so this kind
of typo should no more stay undetected.
The second half of the #1025868 RC bug is the bin-sbin-mismatch tag
which I so far seldomly saw doing much else than false positives even
unrelated to what it's about. Looks like a reproducibility issue (file
order on disk or so) here, though, on a first glance. Then again such
an issue should not be architecture-specific.
> The version of `file` that breaks the autopkgtest is still in experimental,
> but it should be uploaded to unstable soon.
Ok. I wonder if that will really make it for bookworm. It's not in
https://release.debian.org/testing/essential-and-build-essential.txt
but it would be a transition. But then again, I don't see a transition
request at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org#_0_17_4
yet.
But yeah, we probably should be prepared for both cases.
IMHO neither of them are a blocker for an upload. I'd rather consider
that second half of the RC bug #1025868 to be more of a blocker, even
if not a complete blocker.
Actually I even think we could upload now as the Salsa CI test stage
is green again for a few commits, but I first would like to look at
least through the recently opened bug reports, too, and also do a bit
more local testing. I also assume we will do at least two uploads
before the freeze anyway, a first big one (2.116.0) and then probably
some more minor fixups (2.116.1) or so.
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
Reply to: