Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc-dev, gcc, and binutils

[Martin Pitt]

Adam just suggested the following:

infinity pitti: I'd suggest (since things like "try to rebuild the whole archive" would be pointless) they their tests should consist of each one triggering a rebuild test of the other two.
infinity pitti: If upgrading any of those three manages to keep the testsuite of the others passing, that's a win.
infinity: i. e. the test script woudl more or less be "apt-get build-dep binutils; apt-get source -b binutils", right?
infinity pitti: (This came up today after I just spent hours fixing a regression in glibc due to the new gcc, and the inverse happens all the time too)
infinity pitti: Yeahp.
infinity pitti: Oh, and linux-libc-dev (so, the linux source package) should also trigger those three to a rebuild test, same reason.
infinity pitti: If linux-libc-dev's headers survive the GCC and glibc testsuites, they're good enough for regular users. :P
infinity (And if they break regular users but not the toolchain, I'd humbly suggest the users are wrong)
infinity Definitely would have been nice to know when gcc and the kernel were uploaded (so, a couple of weeks ago) that they broke glibc, instead of finding out today while I was uploading for other reasons.
infinity pitti: To cut down on the pain, we could potentially refine the tests to do something like only build a single pass of libc6 and run the tests, only build a single kernel, etc. Most of these things take so effin' long cause they build 4 times.

[Martin Pitt (pitti)]

Andy and I were discussing how we could consolidate this a little bit. Packages like gcc-4.7 and linux could support a DEB_BUILD_OPTIONS=rebuild-test and only build one flavour. We could then set this in those autopkgtests, as well as in our archive rebuild tests to skip some flavours in expensive packages like linux and gcc.

[Andy Whitcroft (apw)]

For the kernel something like the attached patch. This short circuits the build to only make the primary flavour.

[Martin Pitt (pitti)]

Summary from discussion. There are two general approaches how to structure this:

 (1) A package has one "build myself" test; this is more or less a "Restrictions: needs-build" in debian/tests/control and debian/tests/build being "#!/bin/true". The rebuild test group would then be expressed in terms of mutual build/binary/test dependencies.

 (2) A package has debian/tests/build-* tests for all packages in the group except of its own.

(1) is structurally simpler and scales better, but will always waste the "build myself" part, which is not a triviality in case of gcc or linux. But it is a cleaner design and will ensure that the package still builds regardless of which of its build deps changes.

(2) avoids the wasted "self" builds from above, but will trigger the "other" builds several times unnecessarily if you upload two packages in a group at the same time.

My gut feeling is that we should do (1).

[Martin Pitt (pitti)]

Actually, approach (2) would waste even more, as we would still run them unnecessarily through the "test reverse dependencies" stage.

Analysis of current dependencies to see how far our current "test reverse dependencies" logic would get us with the approach from (1):

eglibc has build deps on binutils, gcc-4.7, and linux-libc-dev → complete

binutils has a binary depends on glibc and a build depends on g++ → missing linux-libc-dev, which could become a (redundant) build dependency to be picked up by the reverse depends tests.

linux-source-3.7.0 has a binary depends on binutils → missing libc6-dev and gcc; I think eglibc/libc6-dev probably isn't that critical as it shouldn't break the kernel build directly, but we would need some build dependency on gcc-4.7 on the kernel.

gcc-4.7 build-deps on binutils and libc6-dev; it doesn't have any build or binary dependency on linux-libc-dev, so a new kernel upload currently wouldn't trigger a gcc rebuild test.

[Martin Pitt (pitti)]

In the auto-package-testing scripts we need to do the following:

 * hardcode the (missing) mutual dependencies between these four, so that we do not need to introduce unnecessary direct build dependencies.
 * Run tests with BUILD_PROFILE=autopkgtest

[Matthias Klose (doko)]

GCC does do this with nolang=biarch

[Matthias Klose (doko)]

in GCC; see contrib/test_installed, however this script is outdated and needs some thoughts how to run the tests for all runtime libraries. So better build GCC first ...

[Martin Pitt (pitti)]

For the record, it is "Restrictions: build-needed", not "Restrictions: needs-build", sorry. This needs to be fixed in the eglibc and linux commits.

[Martin Pitt (pitti)]

Tested debdiff for binutils. This adds a rebuild test as well as a simple compile/link/run test as we have for many other libraries, to ensure minimal functionality of the installed binutils.

[Launchpad Janitor (janitor)]

This bug was fixed in the package eglibc - 2.16-0ubuntu6

---------------
eglibc (2.16-0ubuntu6) raring; urgency=low

  * debian/tests/{control,rebuild}: add a stub autopkgtest rebuild
    test and add the XS-Testsuite header to control (LP: #1081500)
  * Rework unsubmitted-cxxheaders-detection3.dif one more time to
    account for more multiarch versus multilib location oddities.
  * Adjust expected results for intermittent tst-mqueue5 failures.
 -- Adam Conrad <email address hidden> Wed, 21 Nov 2012 12:34:25 -0700

[Martin Pitt (pitti)]

Reopening eglibc, as this needs the "needs-build" → "build-needed" fix in debian/tests/control. Sorry about that.

[Martin Pitt (pitti)]

This debdiff adds another autopkgtest which builds a shared library and links against it.

[Launchpad Janitor (janitor)]

This bug was fixed in the package binutils - 2.23.1-0ubuntu3

---------------
binutils (2.23.1-0ubuntu3) raring; urgency=low

  * debian/control.in: Drop Vcs-*, that branch hasn't been updated since
    natty.
  * Add simple rebuild autopkgtest. (LP: #1081500)
  * Add a simple test to compile, link, and run a program against libc6 and
    build/use a shared library with the system-installed binutils, to ensure
    basic binutils functionality.
 -- Martin Pitt <email address hidden> Thu, 22 Nov 2012 07:49:25 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package eglibc - 2.16-0ubuntu7

---------------
eglibc (2.16-0ubuntu7) raring; urgency=low

  * Merge with 2.16-0experimental1 from Debian, bringing in my
    upstream version of the C++ header autodetection patch, some
    packaging and upgrade fixes, and reducing our delta further.
  * Fix debian/tests/control syntax for autopkgtest (LP: #1081500)
  * Add patch ubuntu/local-disable-nscd-netgroup-caching.diff to
    disable netgroup caching in the default config (LP: #1068889)
  * Backport any/cvs-malloc-deadlock.diff from upstream to prevent
    glibc deadlocking in mallock arena retry paths (LP: #1081734)
 -- Adam Conrad <email address hidden> Sun, 25 Nov 2012 19:00:46 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.7.0-4.12

---------------
linux (3.7.0-4.12) raring; urgency=low

  [ Tim Gardner ]

  * Revert "[Config] Use -j1 for headers_install"
  * Revert "[Config] install-arch-headers needs a valid config"
    Strayed into the weeds in search of the root cause of the periodic
    build failure.
    Fixes powerpc FTBS introduced in -4.11.
  * [Config] hmake -j1
    The kernel makefile appears to have parallel dependency
    problems for the install_headers target. This appears to be root
    cause for a periodic build failure on N-way machines.
 -- Leann Ogasawara <email address hidden> Tue, 27 Nov 2012 12:33:06 -0800

[Adam Conrad (adconrad)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Martin Pitt (pitti)]

Uploading gcc already triggers (e)glibc, binutils, linux, and pretty much every single other autopkgtest, so there's nothing to change here. The mutual rebuilding has worked quite well, aside from the fact that glibc's autopkgtest has never succeeded (so it's not taken into account). Ironically the obsolete eglibc autopkgtest still succeeds.