On 12/08/25 at 17:39 +0200, Paul Gevers wrote:
> Hi Lucas,
>
> Thanks for the interface.
>
> On 21-07-2025 22:26, Lucas Nussbaum wrote:
> > 2. if it contains 'status'='lintian failed', either block the package,
> > or ignore lintian alltogether
>
>
> 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.
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
> > 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.
>
>
> 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?
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.
> > 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.
>
>
> Currently I'm only thinking of aliased-location,
Ah, I thought the plan was to phase out the lintian runs on ftp-master
and replace them by lintian runs on testing migration
> 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?
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
Attachment:
signature.asc
Description: PGP signature