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