reassign 979970 src:glibc,src:libselinux,src:apt,src:openssh thanks On 2021-01-25 11:59, Laurent Bigonville wrote: > reassign 979970 src:glibc 2.30-1 > affects 979970 + libselinux1 > thanks > > On Tue, 12 Jan 2021 13:31:19 +0100 Charlemagne Lasse > <charlemagnela...@gmail.com> wrote: > > > Right now, an update from buster to bullseye on amd64 completely > > bricks the system because libselinux1 is requiring a libc6 which is > > not yet installed on the system: > > > > Preparing to unpack .../0-libselinux1_3.1-2+b2_amd64.deb ... > > De-configuring libselinux1:i386 (2.8-1+b1) ... > > Unpacking libselinux1:amd64 (3.1-2+b2) over (2.8-1+b1) ... > > tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not > > found (required by /lib/x86_64-linux-gnu/libselinux.so.1) > > dpkg-deb: error: tar subprocess returned error exit status 1 > > > > It is then not possible anymore to recover the system because dpkg > > (mv, ...) is no longer working. > > > > There is most likely some kind dependency missing to let aptitude > > known that it must first update libc6 before it can update > > libselinux1. At least on this system, the installed version of libc6 > > for amd64 and i386 was still 2.28-10 when this happened > > After some discussion on IRC it looks like the problem is apparently coming > from the breaks added to the libc6 package.
The break hasn't been added randomly, but in response to upstream release notes and bug #965932. In short the openssh seccomp filters in buster are too narrow, and do not allow the new 64-bit syscalls needed for 64-bit time_t compatibility to be used. So we definitely can't drop this break. For me this is not a libc6 bug. Or if it is, it is as much the fault of libc6 (for using new syscalls) than libselinux1 (for starting using symbol versioning). I am therefore reassigning the bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
