Hi,

I'm moving here the discussion that started on #debian-qa.

I wrote a CGI script¹ that exports lintian results per source package,
as YAML.

¹ https://salsa.debian.org/qa/udd/-/blob/master/web/cgi-bin/lintian-britney.cgi?ref_type=heads
http://udd.debian.org/cgi-bin/lintian-britney.cgi?tags=unstripped-binary-or-object,source-nmu-has-incorrect-version-number

The output looks like:
-------------------------------------------------->8
# package that has none of the tags listed
a2jmidid/9-3.1:
  # architectures for which lintian was run
  architectures: amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x source
  tags:
[...]
# package with one of the tags listed
a52dec/0.7.4-20:
  architectures: amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x source
  tags:
  - source-nmu-has-incorrect-version-number
[...]
# package that failedGG
latex-cjk-chinese-arphic/2.2:
  architectures:
  status: lintian failed
-------------------------------------------------->8

The pseudo code to block packages would look like:
1. find stanza for source/version, if it cannot be found, we probably
   want to wait until the package is processed.
2. if it contains 'status'='lintian failed', either block the package,
   or ignore lintian alltogether
3. examine the architectures field.  does it contain enough
   architectures, compared to those we want to migrate? (we might not
   want to wait for all architectures, but it's probably a good idea to
   wait for a few ...)
4. examine the list of tags

The output could link to e.g. https://udd.debian.org/lintian/?a52dec
(The default display only lists errors and warnings, but I suppose we
are not going to block on anything else)

Let me know if that works for you.

I saw the discussion about the number of tag occurences for a given
source package, that should be used to identify regressions. Tags are
currently only listed once per source. It would be possible to add the
number of occurences for each tag (with distinct "information"). Let me
know.

Lucas

Hi Lucas,

Thanks for the interface.


Have the 4 failures been reported to the src:lintian? All 4 packages are
in testing and I don't want to block them on new uploads for a failure
of lintian to run. Skipping the lintian check doesn't sound great.


For reproducible builds and autopkgtests we have a retry button. How
much sense do you think that makes for lintian? If we expect to have
failures like above, I think it would be good for maintainers to have
the option to retry. How often does udd retry by itself?


Currently I'm only thinking of aliased-location, which we really want to
prevent altogether, but in the future we might want to add things that
shouldn't regress. But maybe we can delay that to when we get there
unless you already have a good idea for that?

Paul

I don't think a regression approach makes sense for lintian tags,
especially not for warnings.

When a package has a new binary that does not have a manpage,
there is a new lintian warning.

A missing manpage is a problem in a package that should be visible,
but I don't see how this could warrant blocking testing migration.

If you block testing migration on that, you are forcing the maintainer
to hide the problem by adding a lintian override.

A regression approach also means that a manual hint is needed when a
package that got removed from testing (sometimes by a release team
member to help a transition) wants to reenter - it already happens in
rare cases with binary-all packages not installable on arm64, but
lintian warnings are not rare.

It would make more sense to block unconditionally (regression or not)
on a whitelist of lintian errors the release team does not want to have
in the next release.

Or announce that migration will be blocked on all lintian errors after
the release of forky, only displaying the information in excuses until
then (similar to reproducible).

Regarding the implementation, instead of waiting on another external
service that runs lintian it might be an option that britney
automatically adds an superficial autopkgtest to every package
running something line "lintian --fail-on error".

cu
Adrian

Hi Adrian,


This is what we envision at the moment, we'll be in control of which
lintian tags we want to block on.


We already depend on udd, so that's not new. And even if we would
pursue, how do you envision interaction of britney2 with autopkgtest to
add that test? That's not supported on any of the levels, so that's
quite a big change. And again, we only want to block on particular tags,
not everything that lintian thinks it's wise to report.

Paul

I understand that the plan is to block on a small subset of tags (which
probably wouldn't include missing manpages).

Lucas

I thought I filed the bugs already, but it does not look like it. Done
now:

#1110968: lintian: fails to process qps_2.10.0-1_amd64.deb, angband-data_4.2.5+dfsg1-3_all.deb, gedit-plugin-smart-spaces_48.1-2_amd64.deb: YAML::XS::Load Error: The problem: mapping keys are not allowed in this context
#1110969: lintian: fails to process latex-cjk-chinese-arphic-gbsn00lp_2.2_all.deb

Lintian results look very stable. The UDD runner currently does not
retry (refresh) packages that were tested successfully (= lintian exits
with 0, but might have identified errors, warnings, etc.).
It retries frequently (several times per day) the few packages where
lintian failed, so temporary failures should not stay for long.

Ah, I thought the plan was to phase out the lintian runs on ftp-master
and replace them by lintian runs on testing migration

I added the count of distinct "information" for each tag, which is
probably enough to identify if something changed in the wrong direction.

tinc/1.1~pre18-1:
  architectures: amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x source
  tags:
    aliased-location: 5

Lucas

Hi Paul,

udd is not new, but the service running lintian would be a new dependency.

At what point is debian/control parsed to detect lines like
  Testsuite: autopkgtest-pkg-go
?

At that point it should be possible to inject a test into every package
that does something like
  Test-Command: lintian --fail-on error -T aliased-location /path/to/*.deb
  Restrictions: superficial

cu
Adrian

Hi


That's done in britney2.


No, because the reading of the test suite is done on ci.d.n by
/usr/bin/autopkgtest. So what would be needed is autopkgtest to get an
interface to add tests from the outside, debci to grow an interface to
accept the same information and pass it on to autopkgtest and britney2
to use that new debci interface.

What would you use as Test-Depends? I would naively say, all binaries,
but what if not all binaries from one source are co-installable? Even if
we'd solve that, /path/to/*.deb would be /var/cache/apt/archives/*.deb
(but only those of the source under test). Can we rely on /var/cache? As
an alternative, the test could download all the binaries *in* the test,
but that feels clumsy for the 99% of the cases where we have just done
so to install the Test-Depends of the other tests.

Oh, and autopkgtest uses autodep8 automatically. So packages in
supported classes that haven't opted in to using that (e.g. because it
doesn't work on their package) suddenly see themselves being tested and
might fail.

Paul

Probably the above doesn't work because of how thunderbird breaks lines
and the bts reads those, but humans can still read it.


My current implementation doesn't use that yet, but I've based my work
on the current format. Please consider that interface now to have users.

Paul

Hi,


This now is active,
seehttps://qa.debian.org/excuses.php?package=gitlab-ci-multi-runner

Thanks for your work on this and the idea.

Paul

Hi Lucas,


I'm reopening this bug to discuss extension of the output. On #d-ftp I
informed ftp-master of this work and informed them we could take over
tags that work only on binaries. I should have realized before, but for
some of the tags they allow the maintainers to lintian-override the tag.
I think it would be useful if we had that too. I guess we somehow need
to add the information if a tag was overridden (for all instances) or not.

Paul

[1] https://paste.ganneff.de/2025-08-23-kX7HU26RXQs/lintian.tags

How about something like this:

gcc-15/15.2.0-1:
  architectures: all amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x source
  tags:
    binary-from-other-architecture:
      count: 66
      overridden: 164

'count' is the number of non-overriden matches.

https://udd.debian.org/lintian/?email1=&email2=&email3=&packages=gcc-15&ignpackages=&format=html<_error=on<_overridden=on&lintian_tag=binary-from-other-architecture#all


For reference, the UDD query to find interesting cases:
select tag, source, count(distinct tag_type)
from lintian_results
where tag_type in ('error', 'overridden')
group by tag, source
having count(distinct tag_type) = 2;

Lucas

Hi,


Looks fine to me :).

Paul

OK, should I push the changes? (I guess that will break the parsing on
your side)

Lucas

Hi,


I just checked in the test-suite, but it doesn't seem to brake it as I'm
not yet using the information in the tag.

Paul

ACK, change deployed.

Lucas