Hi Roger, On Sat, Jun 11, 2011 at 02:02:52AM +0100, Roger Leigh wrote: > On Tue, Jun 07, 2011 at 11:14:14AM +0200, Tollef Fog Heen wrote: > > ]] Steve Langasek > > | 4) Turn on direct use of 'debian/rules build-arch' on the autobuilders for > > | all packages in unstable and experimental immediately, with no fallback > > | if the target does not exist; requires a corresponding update to Policy > > | and mass updates to fix packages that fail to build as a result. > > I'd be happy to provide hardware to do a full scale rebuild test of the > > archive if somebody does the actual work of doing the rebuilds. rleigh > > did it for his sbuild resolver test so I've Cc-ed him to see if he's > > interested in doing a test for this too. > This has been completed now, and the summarised results follow. > All of the build logs, scripts and datafiles are available from > http://people.debian.org/~rleigh/dpkg-rebuild/ Thanks for this analysis! There are a few questions that I don't readily find answers to in your mail: > Summarised: > - autodetection with "make -qn" breaks few, if any packages. This is one of the key questions, but without a very clear answer. Which of the rows in your output correspond to packages that *may* have been broken by autodetection? I'm not sure how to aggregate the rows in the first query to get this answer, and the rows in the second query all seem to be keyed on build status when building with build-arch unconditionally. What is interesting to know when evaluating the autodetection solution is if there are any regressions in package buildability when comparing *only* to the current use of 'debian/rules build', and I don't get that from these tables. > - unconditional use of build-arch breaks approximately 45% of > arch-any packages (the fraction not providing a build-arch > target). That's pretty substantial, and persuades me that it's not a good idea. > Because unstable was changing between the rebuilds, some of the > failures are likely due to churn, including multiarch work, so a > failure does not necessarily implicate the patch being tested. I'm surprised that the build environment was continuing to track updates to unstable at this time, as opposed to using a static mirror. That's an unfortunate source of noise in the data; how can we get the list of packages that failed to build with autodetection that didn't fail with 'debian/rules build', to determine if they are indeed false positives? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature