On 23/02/26 at 20:57 +0100, Paul Gevers wrote: > Hi Lucas, > > On 2/23/26 09:37, Adrian Bunk wrote: > > On Mon, Feb 23, 2026 at 08:27:02AM +0000, Debian Bug Tracking System wrote: > > > ... > > > > But the point here is the > > > > > > > > Lintian crashed and produced no output, please contact debian-release > > > > for a hint - info > > > > > > The message needs to improved as there were not binary packages to test > > > yet. > > > Somehow it seems we got data from udd that confused britney2 to follow the > code path to report that lintian crashed instead of waiting for data (which > means that there were "lintian failed" results for the not-yet-built > version). Do you have any idea what happened?
Hi Paul, I have no idea, sorry. Recently I upgraded to lintian 2.129.0 and am now running it into a forky container (instead of as a backport on stable), but that should not change anything about how results are exposed to britney. Also, source-only sources packages (source packages with no binaries tested yet) are properly reported in https://udd.debian.org/cgi-bin/lintian-britney.cgi: mssstest/3.0-8: architectures: source tags: {} According to UDD's lintian_logs table, it never failed to process textdraw/0.2+ds-2 (see udd> select * from lintian_logs where source='textdraw' order by ts desc; ) However, at the time the bug was reported (06:17:48 +0100), UDD hadn't processed textdraw/0.2+ds-2 yet (it was processed at 06:49:21), but it looks like this wasn't reached: https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/lintian.py#L93 The two packages where lintian is reporting a crash in https://release.debian.org/britney/update_excuses.html are vala-panel and 0xffff, where lintian indeed crashed (due to #1128262) Lucas
