Bug#866692: stretch-pu: package linux-latest/80+deb9u1
Control: tags -1 + confirmed
Hi,
On Sat, 2017-07-01 at 06:07 +0200, Cyril Brulebois wrote:
> Hi Ben,
>
> Ben Hutchings <ben@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
Reply to: