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 <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
