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 <rleigh@codelibre.net>, 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 <vorlon@debian.org>
> > * 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/Linux http://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
Reply to: