Hi! On Wed, 2024-03-27 at 17:56:25 +0700, Arnaud Rebillout wrote: > Source: libaio > Version: 0.3.113-7 > Severity: normal > User: de...@kali.org > Usertags: origin-kali
> I noticed that the t64 variant of the package libaio is already in > testing. I did a quick check, and it seems that it's the only t64 package > in testing at the moment, I suppose it wasn't intentional? In theory, compared to the other packages involved in the transition, it should not matter whether it transitioned as it is using a new actual bumped SONAME (instead of only modifying the package name and reusing the old SONAME). But because the udeb did not get renamed that is indeed a problem for d-i. See also the thread at: https://lists.debian.org/debian-boot/2024/03/msg00125.html > $ chdist apt-file trixie search -x '/lib/.*lib[^/]+t64$' > libaio1t64: /usr/lib/x86_64-linux-gnu/libaio.so.1t64 > > The libaio1-udeb package is now also using the t64 lib, and it breaks > the installer ISO that is built from testing. When trying to partition > the disk using LVM, it fails, and we can see this error in the logs: > > partman: pvscan: error while loading shared libraries: libaio.so.1: > cannot open shared object file: No such file or directory > partman: vgscan: error while loading shared libraries: libaio.so.1: > cannot open shared object file: No such file or directory > partman-lvm: vgchange: error while loading shared libraries: libaio.so.1: > cannot open shared object file: No such file or directory > > I must say that this issue was reported in the Kali Linux bugtracker > [1], as Kali is built on top of Debian testing, so our weekly images are > now broken for users who try to use LVM partitioning. > > I didn't check if it _really_ affects the weekly Debian installer ISOs, > but I suppose so. > > I don't know if anything can/should be done at this point, apart from > waiting for the t64 transition to complete? Or should there be a binNMU > for the d-i packages partman-*, would that fix the issue? A binNMU would fix that, but given that no one has apparently asked for that yet, I think instead I'll just add (later today) a compat symlink only for the udeb for the old SONAME, because the new SONAME is ABI compatible, but done to avoid stomping on the upstream SONAME in case they end up merging something else or rejecting the patches, but in d-i we do not care about backwards compatibility as long as it is ABI compatible, then no binNMU will be needed anymore. Thanks, Guillem
