[Bug 1836100] Re: Was able to migrate out of proposed despite breaking dkms

[Steve Langasek]

> No, this is not a gcc thing. But the kernel 5.2 now finally
> getting built in eoan, and not binary copied from disco as
> done for 5.0.

Matthias, I agree with Seb's analysis here.  The actual sequence of
events is:

 - linux 5.0 in eoan was fixed to pass its build tests with the gcc in eoan, as seen in the history at http://autopkgtest.ubuntu.com/packages/l/linux/eoan/amd64 et al.
 - a new gcc-9 was uploaded (https://lists.ubuntu.com/archives/eoan-changes/2019-July/002800.html) which triggered a linux autopkgtest which rebuilt the kernel; however, because gcc-defaults still pointed at gcc-8, this did not actually test that the kernel was buildable with gcc-9.  (e.g.  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/l/linux/20190705_005255_eec9e@/log.gz)
 - a new gcc-defaults was uploaded (https://lists.ubuntu.com/archives/eoan-changes/2019-July/002843.html) which switched the default gcc from gcc-8 to gcc-9, but this did *not* trigger an autopkgtest of the kernel, so the fact that the kernel regressed in buildability went unobserved and did not block the new gcc-defaults from reaching the release pocket.
 - reports began to come in about failing autopkgtests on a variety of dkms packages whose modules would no longer build using the gcc and linux-headers in the release pocket.
 - Dimitri (NOT the kernel team, though they would have been in their rights to have also done so) forward-copied https://launchpad.net/ubuntu/+source/linux/5.0.0-21.22 from disco to eoan-proposed.  Because this was a binary copy, it did not trigger any build failures that would have notified the kernel team that there was a regression, nor did this trigger any autopkgtest rebuild tests (intentionally!) that would have identified the regression.  However, the regression in the release pocket had already happened 2 steps above, because of the lack of gating of gcc-defaults; it was not caused by the sync of linux 5.0.0-21.22.
 - the kernel team uploads https://launchpad.net/ubuntu/+source/linux/5.2.0-8.9 which is compatible with gcc-9, fixing this problem in eoan-proposed
 - we are now waiting for linux to migrate in order for everything to return to normal.

This does not mean that it is the responsibility of the gcc-9 package to
fix this lack of gating.  By design, autopkgtest gating works the other
way around: the package which depends on your package, and which could
regress, should declare its tests and catch any regressions.  So this
was definitely not a bug in gcc-9.  It is *actually* a bug in the
proposed-migration infrastructure, because the kernel and gcc are both
special-cased there, and the special-case in question explicitly fails
to include gcc-defaults in the set of packages triggering linux rebuild
tests.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1836100

Title:
  Was able to migrate out of proposed despite breaking dkms

Status in Auto Package Testing:
  Triaged

Bug description:
  The recent gcc update in eoan migrated out of proposed despite the
  fact that it was breaking dmks/nvidia users, could we have some sort
  of autopkgtest added to make sure that gcc gets blocked in proposed
  the next time we have a such situation?

  (see bug #1830961)

To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/1836100/+subscriptions