Re: Status of build-arch coverage
On 2014-02-20 18:21, Steve Langasek wrote: > On Thu, Feb 20, 2014 at 12:31:28PM +, Colin Watson wrote: >> On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote: >>> Ok. The statistics still seem awfully low to me; but I guess >>> http://people.debian.org/~cjwatson/dhstats.png shows there hasn't actually >>> been a huge uptick in dh(1) adoption over the past year, as a percentage of >>> all packages. > >> Um, that's because the graph stops at the end of 2012. :-) I ran into >> some change of behaviour in the Lintian lab I was using and haven't had >> a chance to figure out what's going on there ... > > Oh, right. Apparently I don't know what year it is, ignore me! > I am not quite sure what happened at "the end of 2012" that affected your code. It was around the release of 2.5.11, but I see nothing in the changelog of lintian that should have broken your code. That said, we no longer store the "debian/" dir unpacked on lintian.d.o, since lintian.d.o kept running out of inodes. I think this change was made around June 2013 (in 2.5.14). ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53064a95.8060...@thykier.net
Re: Status of build-arch coverage
On Thu, Feb 20, 2014 at 12:31:28PM +, Colin Watson wrote: > On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote: > > Ok. The statistics still seem awfully low to me; but I guess > > http://people.debian.org/~cjwatson/dhstats.png shows there hasn't actually > > been a huge uptick in dh(1) adoption over the past year, as a percentage of > > all packages. > Um, that's because the graph stops at the end of 2012. :-) I ran into > some change of behaviour in the Lintian lab I was using and haven't had > a chance to figure out what's going on there ... Oh, right. Apparently I don't know what year it is, ignore me! -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Status of build-arch coverage
On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote: > Ok. The statistics still seem awfully low to me; but I guess > http://people.debian.org/~cjwatson/dhstats.png shows there hasn't actually > been a huge uptick in dh(1) adoption over the past year, as a percentage of > all packages. Um, that's because the graph stops at the end of 2012. :-) I ran into some change of behaviour in the Lintian lab I was using and haven't had a chance to figure out what's going on there ... -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140220123128.ga28...@riva.ucam.org
Re: Status of build-arch coverage
On Wed, Feb 19, 2014 at 09:28:48PM +, Roger Leigh wrote: > Current unstable dpkg building openldap: > > Starting test048-syncrepl-multiproxy for mdb... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to create the context prefix entry in the master... > Starting P1 slave slapd on TCP/IP port 9012... > Using ldapsearch to check that P1 slave slapd is running... > Starting R1 slave slapd on TCP/IP port 9013... > Using ldapsearch to check that R1 slave slapd is running... > 1 > Using ldapadd to populate the master directory... > Waiting 7 seconds for syncrepl to receive changes... > 1 < Comparing retrieved entries from master and P1 slave... > 1 < Comparing retrieved entries from master and R1 slave... > test failed - master and R1 slave databases differ > > test048-syncrepl-multiproxy failed for mdb > (exit 1) > make[3]: *** [mdb-mod] Error 1 > make[3]: Leaving directory `/«PKGBUILDDIR»/debian/build/tests' > make[2]: *** [test] Error 2 > Maybe the 7 seconds wasn't enough if the system was heavily > loaded? Must be awfully loaded, considering this test passes reliably on buildds of all archs (including the really slow ones). > samba failed due to timing out while linking. I'll identify and > reschedule the jobs which timed out. It's about 30 per run, which > isn't going to affect the statistics, but obviously there are a few > false positives as a result, which I'll rectify. I'll increase the > timeout for the next runs. Ok. The statistics still seem awfully low to me; but I guess http://people.debian.org/~cjwatson/dhstats.png shows there hasn't actually been a huge uptick in dh(1) adoption over the past year, as a percentage of all packages. Maybe it's time for a MBF on non-dh packages. ;-) -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Status of build-arch coverage
On Wed, Feb 19, 2014 at 01:02:55PM -0800, Steve Langasek wrote:
> On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> > Thanks for doing the rebuilds!
>
> > * Roger Leigh , 2014-02-18, 22:58:
> > >┌┬┬───┐
> > >│ current │ buildarch │ count │
> > >├┼┼───┤
> > >│ attempted │ attempted │ 317 │
> > >│ attempted │ successful │26 │
> > >│ failed │ failed │35 │
> > >│ failed │ successful │ 3 │
> > >│ successful │ attempted │ 1483 │
> > >│ successful │ failed │ 3 │
> > >│ successful │ successful │ 8650 │
> > >└┴┴───┘
>
> > >Raw data:
> > >http://www.codelibre.net/~rleigh/rebuild-buildarch-20140218.sql.xz
>
> > Do I understand correctly that your rebuilds were with -B, and
> > therefore packages that build only arch:all package were not tested
> > at all?
>
> > It would be interesting to see how packages that builds arch:all
> > packages behave when rebuilt with -A.
>
> > >I hope the above is useful for measuring progress on this front.
> > >Do we have any plans for enforcing build-arch for jessie at this
> > >point? If we haven't already, stronger warnings when running
> > >dpkg-buildpackage and stronger lintian warnings (errors?) would be
> > >useful to add.
> >
> > If build-{arch,indep} is missing, Lintian currently emits
> > debian-rules-missing-recommended-target[0]. I think we should go
> > ahead and make it emit debian-rules-missing-required-target[1],
> > which is on ftp-masters' auto-reject list.
>
> > I attached dd-list of packages that were is non-successful state in
> > the "buildarch" rebuild. Packages marked with "*" were also in
> > non-successful state in the "current" build.
>
> > [0]
> > http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html
> > [1] http://lintian.debian.org/tags/debian-rules-missing-required-target.html
>
>
> > Steve Langasek
> > * openldap (U)
> >samba (U)
>
> This is not useful without build logs. Both of these packages use dh(1),
> which is perfectly build-arch-compatible; there's bug #738641 reported on
> openldap about the libdb5.1 transition, but that doesn't actually cause a
> build failure yet.
>
> So I think this build environment is suspect, and such a summary report is
> not useful without substantial details.
I took a complete amd64+source debmirror archive snapshot on 20140212 at 0253.
>From this, I debootstrapped a fresh build chroot from the NFS mount of the
mirror, and set it up to use the file:// apt source of the bind mounted
mirror inside the chroot, which is fast and saves needing to download the
debs before unpacking.
I would suspect that most failures which weren't due to transient lack of
buildability in unstable, and not due to lacking build-arch support are
due to timeouts (see below) or timing issues due to the system load.
Current unstable dpkg building openldap:
> Starting test048-syncrepl-multiproxy for mdb...
running defines.sh
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd is running...
Using ldapadd to create the context prefix entry in the master...
Starting P1 slave slapd on TCP/IP port 9012...
Using ldapsearch to check that P1 slave slapd is running...
Starting R1 slave slapd on TCP/IP port 9013...
Using ldapsearch to check that R1 slave slapd is running...
1 > Using ldapadd to populate the master directory...
Waiting 7 seconds for syncrepl to receive changes...
1 < Comparing retrieved entries from master and P1 slave...
1 < Comparing retrieved entries from master and R1 slave...
test failed - master and R1 slave databases differ
> test048-syncrepl-multiproxy failed for mdb
(exit 1)
make[3]: *** [mdb-mod] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/debian/build/tests'
make[2]: *** [test] Error 2
Maybe the 7 seconds wasn't enough if the system was heavily
loaded?
samba failed due to timing out while linking. I'll identify and
reschedule the jobs which timed out. It's about 30 per run, which
isn't going to affect the statistics, but obviously there are a few
false positives as a result, which I'll rectify. I'll increase the
timeout for the next runs.
I can make the collection of build logs available if needed. I'll
get the rebuilds done first though.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140219212848.gc11...@codelibre.net
Re: Status of build-arch coverage
On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> Thanks for doing the rebuilds!
> * Roger Leigh , 2014-02-18, 22:58:
> >┌┬┬───┐
> >│ current │ buildarch │ count │
> >├┼┼───┤
> >│ attempted │ attempted │ 317 │
> >│ attempted │ successful │26 │
> >│ failed │ failed │35 │
> >│ failed │ successful │ 3 │
> >│ successful │ attempted │ 1483 │
> >│ successful │ failed │ 3 │
> >│ successful │ successful │ 8650 │
> >└┴┴───┘
> >Raw data:
> >http://www.codelibre.net/~rleigh/rebuild-buildarch-20140218.sql.xz
> Do I understand correctly that your rebuilds were with -B, and
> therefore packages that build only arch:all package were not tested
> at all?
> It would be interesting to see how packages that builds arch:all
> packages behave when rebuilt with -A.
> >I hope the above is useful for measuring progress on this front.
> >Do we have any plans for enforcing build-arch for jessie at this
> >point? If we haven't already, stronger warnings when running
> >dpkg-buildpackage and stronger lintian warnings (errors?) would be
> >useful to add.
>
> If build-{arch,indep} is missing, Lintian currently emits
> debian-rules-missing-recommended-target[0]. I think we should go
> ahead and make it emit debian-rules-missing-required-target[1],
> which is on ftp-masters' auto-reject list.
> I attached dd-list of packages that were is non-successful state in
> the "buildarch" rebuild. Packages marked with "*" were also in
> non-successful state in the "current" build.
> [0]
> http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html
> [1] http://lintian.debian.org/tags/debian-rules-missing-required-target.html
> Steve Langasek
> * openldap (U)
>samba (U)
This is not useful without build logs. Both of these packages use dh(1),
which is perfectly build-arch-compatible; there's bug #738641 reported on
openldap about the libdb5.1 transition, but that doesn't actually cause a
build failure yet.
So I think this build environment is suspect, and such a summary report is
not useful without substantial details.
--
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: Status of build-arch coverage
On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> Thanks for doing the rebuilds!
>
> * Roger Leigh , 2014-02-18, 22:58:
> >┌┬┬───┐
> >│ current │ buildarch │ count │
> >├┼┼───┤
> >│ attempted │ attempted │ 317 │
> >│ attempted │ successful │26 │
> >│ failed │ failed │35 │
> >│ failed │ successful │ 3 │
> >│ successful │ attempted │ 1483 │
> >│ successful │ failed │ 3 │
> >│ successful │ successful │ 8650 │
> >└┴┴───┘
> >
> >Raw data:
> >http://www.codelibre.net/~rleigh/rebuild-buildarch-20140218.sql.xz
>
> Do I understand correctly that your rebuilds were with -B, and
> therefore packages that build only arch:all package were not tested
> at all?
This is correct. I can repeat to test this. However, I would
suspect that the results will not be as good in general--these
codepaths are not currently tested by building for upload unless
special action is taken, or by our autobuilders. While most
packages using dh/cdbs should work correctly, it's quite likely
that we'll see regressions here.
> It would be interesting to see how packages that builds arch:all
> packages behave when rebuilt with -A.
Definitely. I would also be interested to see what the coverage
looks like here. I'll repeat and we'll see how things look like.
I'll probably be another week to do another two full sets of
builds. I'll set it going later on today.
> >I hope the above is useful for measuring progress on this front.
> >Do we have any plans for enforcing build-arch for jessie at this
> >point? If we haven't already, stronger warnings when running
> >dpkg-buildpackage and stronger lintian warnings (errors?) would be
> >useful to add.
>
> If build-{arch,indep} is missing, Lintian currently emits
> debian-rules-missing-recommended-target[0]. I think we should go
> ahead and make it emit debian-rules-missing-required-target[1],
> which is on ftp-masters' auto-reject list.
That sounds good. When we do this, a clear announcement on d-d-a would
be good. If we can reduce the failing count much further prior to
jessie freezing, what would be considered an acceptable threshold for
disabling the autodetection? (Zero is unlikely to be attainable.)
> I attached dd-list of packages that were is non-successful state in
> the "buildarch" rebuild. Packages marked with "*" were also in
> non-successful state in the "current" build.
Thanks, that's much appreciated.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140219133443.gb11...@codelibre.net
Re: Status of build-arch coverage
On Tue, Feb 18, 2014 at 10:58:50PM +, Roger Leigh wrote: > I hope the above is useful for measuring progress on this front. Do > we have any plans for enforcing build-arch for jessie at this point? > If we haven't already, stronger warnings when running dpkg-buildpackage > and stronger lintian warnings (errors?) would be useful to add. I should have added here, if any additional information would be helpful, I have all the build logs on hand for the moment, and can obtain any additional information if needed. And if any additional testing needs doing, e.g with different dpkg patches, I can repeat the exercise given a little notice. The testing was done on an 8-core 4GHz AMD FX-8350 system with 16GiB RAM and a 200GiB btrfs volume for the build snapshots, with the Debian archive mirror and build products accessed and stored, respectively, using NFSv4 with a FreeBSD 10.0 ZFS fileserver. Each run took just over 2.5 days, using GNU parallel to drive 8 concurrent sbuild/schroot builds; a little more optimisation could reduce this time further. The system is quite thoroughly burned in now; it made a nice "cooking electronics" smell for the first hour, and other than that went smoothly until Btrfs toasted itself with lots of kernel BUGs when it unbalanced itself to the point of unusability after 5 days of being thrashed mercilessly, around build 19500; a btrfs filesystem rebalance made it go again--but something to watch out for if you're a btrfs user! (Glad I'm no longer using it except for build snapshots! Using a filesystem shouldn't reduce your system to requiring a hard reset! At least it was recoverable this time…) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 signature.asc Description: Digital signature
Status of build-arch coverage
Over the last few days, I have done two full rebuilds of all any/amd64
packages in the archive using:
· the current unstable dpkg ("current")
· the current unstable dpkg with the build-arch autodetection removed
("buildarch")
The summary is this:
┌┬┬───┐
│ current │ buildarch │ count │
├┼┼───┤
│ attempted │ attempted │ 317 │
│ attempted │ successful │26 │
│ failed │ failed │35 │
│ failed │ successful │ 3 │
│ successful │ attempted │ 1483 │
│ successful │ failed │ 3 │
│ successful │ successful │ 8650 │
└┴┴───┘
Raw data:
http://www.codelibre.net/~rleigh/rebuild-buildarch-20140218.sql.xz
So the good news is that the great majority of the archive does support
build-arch directly (8650 packages) without the need for autodetection.
However, nearly 1500 packages still do not have build-arch/build-indep
targets (or they do, but they are broken). This is about 14% of the
total. (I'm discounting the attempted, failed etc. packages for which
we can't make any judgement without manual inspection.)
I hope the above is useful for measuring progress on this front. Do
we have any plans for enforcing build-arch for jessie at this point?
If we haven't already, stronger warnings when running dpkg-buildpackage
and stronger lintian warnings (errors?) would be useful to add.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
signature.asc
Description: Digital signature
