Control: tags -1 + confirmed Hi,
On Sat, 2017-07-01 at 06:07 +0200, Cyril Brulebois wrote: > Hi Ben, > > Ben Hutchings <b...@decadent.org.uk> (2017-07-01): > > src:linux-latest builds meta-packages depending on debug info packages > > built from src:linux. During the stretch release cycle, these were > > changed to new-style dbgsym packages and then this change was reverted > > to src:linux. However, the change in src:linux-latest was *not* > > reverted, leaving these meta-packages uninstallable. As a general rule, we don't add binary packages to stable. This seems like an obvious case for an exception, however. (With the timing caveat noted later.) [Note that it's possible that a similar situation could occur in future, both for testing and stable. britney does not perform any installability tests on packages from debian-debug, but simply updates testing-debug to include the packages that correspond to the new state of testing. queue-viewer does perform such tests, but for ease of implementation they pretend that there is no distinction between the main and debug archives, so will fail to spot any issues caused by cross-archive dependencies.] > > The source changes are shown below, not including the files generated by > > deian/bin/gencontrol.py. > > I'm not excessively familiar with the kernel's packaging, and since it's > a bit of an important package, I'd appreciate a second look from someone > else. > > Anyway, I could easily reproduce the issue in a stretch amd64 chroot, > and can confirm this issue goes away once linux-latest rebuilt with this > patch (plus gencontrol.py magic of course). Overall the changes look okay to me, with the note below on unstable taken into account. I was curious about this change though: -Section: debug -Priority: extra Should the -dbg packages not still be in the "debug" section? Is it intentional that there are still some dbgsym packages built by src:linux? Specifically: hyperv-daemons-dbgsym | 4.9.30-2+deb9u2 | stable-new | amd64, i386 libcpupower1-dbgsym | 4.9.30-2+deb9u2 | stable-new | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x linux-cpupower-dbgsym | 4.9.30-2+deb9u2 | stable-new | amd64, i386 linux-kbuild-4.9-dbgsym | 4.9.30-2+deb9u2 | stable-new | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x linux-perf-4.9-dbgsym | 4.9.30-2+deb9u2 | stable-new | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x usbip-dbgsym | 2.0+4.9.30-2+deb9u2 | stable-new | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > (We'll need a higher version in unstable, too, but I see 82 was uploaded > and reached NEW already, so hopefully that'll be sorted out by the time > the point release happens.) Well, it'll need to be. :-) To be entirely honest, I'd prefer to get the unstable situation sorted before we fix stable. Looking at the NEW page for the unstable upload, I can't imagine that there'll be any issues getting it sorted quickly. Regards, Adam