Re: Potential MBF: packages failing to build twice in a row
On Sat, Aug 05, 2023 at 08:55:03PM +0200, Lucas Nussbaum wrote:
> On 05/08/23 at 19:20 +0300, Adrian Bunk wrote:
> > On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
> > >...
> > > Packages tested: 29883 (I filtered out those that take a very long time to build)
> > > .. building OK all times: 24835 (83%)
> > > .. failing somehow: 5048 (17%)
> > >...
> > > I wonder what we should do, because 5000+ failing packages is a lot...
> >
> > I doubt these are > 5k packages that need individual fixing.
> >
> > What packages are failing, and why?
>
> Did you see http://qa-logs.debian.net/2023/08/twice/ ?
Yes, after sending my email...
>...
> > > Should we give up on requiring a 'clean' target that works? After all,
> > > when 17% of packages are failing, it means that many maintainers don't
> > > depend on it in their workflow.
> >
> > You are mixing two related but not identical topics.
> >
> > Your subject talks about "failing to build twice in a row",
> > but the contents mostly talks about dpkg-source.
> >
> > Based on my workflows I can say that building twice in a row, defined as
> > dpkg-buildpackage -b --no-sign && dpkg-buildpackage -b --no-sign
> > works for > 99% of all packages in the archive.
>
> That's true. However, if the 'clean' target doesn't work correctly,
> there are chances that the second build might not happen in the same
> conditions as the first one (for example because it will re-use
> left-overs from the first build).
Your test is not sufficient to ensure that the 'clean' target does work
correctly, non-binary changes under debian/ might result in false negatives.
OTOH it is less of a problem for me if a package that does run autoconf
during the build does not remove/restore the generated configure in the
'clean' target even though it might fail your test.
> Lucas
cu
Adrian
Reply to: