> 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 Desktop 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 To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1836100/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
