Bug#1070121: nmu: coreutils_9.4-3 (trixie), pam_1.5.2-9.1 (trixie)
On 30/04/2024 21:44, Simon McVittie wrote: coreutils_9.4-3.1 and pam_1.5.3-7 aren't currently migrating to trixie for whatever reason. Because debootstrap doesn't currently know about versioned Provides, I think it would be useful to get versions of these packages in trixie that have been rebuilt against the 64-bit time_t ABIs and package names. If the versions in trixie don't migrate imminently, please consider: nmu coreutils_9.4-3 . ANY . trixie . -m "rebuild against libssl3t64" nmu pam_1.5.2-9.1 . ANY . trixie . -m "rebuild against libdb5.3t64" I tried to rebuild coreutils 9.4-3 in the Kali Linux suite "kali-dev" (based on Debian testing), and for the **armhf** architecture. The thing is, in the build chroot there is coreutils+libssl3 already installed. Then apt needs to install the build depends for coreutils, ie. libssl-dev that depends on libssl3t64. And of course, for armhf and armel, libssl3t64 is not co-installable with libssl3, so the build fails straight there. Can't even install the build deps. I suppose it's not a surprise for those familiar with the matter. And the NMU suggested by Simon would probably work for other architectures, maybe it's better than nothing. Best, -- Arnaud Rebillout / OffSec / Kali Linux Developer
Bug#1070121: nmu: coreutils_9.4-3 (trixie), pam_1.5.2-9.1 (trixie)
On 2024-04-30 15:44:51 +0100, Simon McVittie wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: coreut...@packages.debian.org, p...@packages.debian.org, > debian-b...@lists.debian.org > Control: affects -1 + src:coreutils src:pam > > coreutils_9.4-3.1 and pam_1.5.3-7 aren't currently migrating to trixie > for whatever reason. Because debootstrap doesn't currently know about > versioned Provides, I think it would be useful to get versions of these > packages in trixie that have been rebuilt against the 64-bit time_t ABIs > and package names. > > If the versions in trixie don't migrate imminently, please consider: > > nmu coreutils_9.4-3 . ANY . trixie . -m "rebuild against libssl3t64" > nmu pam_1.5.2-9.1 . ANY . trixie . -m "rebuild against libdb5.3t64" > > In a trixie derivative (a non-public future branch of the Steam Runtime) > I found that local rebuilds of those two source packages were enough to > bring a minbase debootstrap back from repeatably failing to reasonably > reliable. I hope they would have a similar effect in real trixie. > > Based on kibi's thread "Making trixie debootstrap-able again?" on -release > and -boot, binNMUing util-linux and iproute2 might also help for d-i's > use-case, which is larger than minbase and wants fdisk and iproute2: > > nmu util-linux_2.39.3-6 . ANY . trixie . -m "rebuild against libreadline8t64" > nmu iproute2_6.7.0-2 . ANY . trixie . -m "rebuild against libtirpc3t64" > > but I have not independently verified that those two are necessary > or sufficient. The packages would be ready to migrate to trixie, but migrating them makes britney crash. I don't expect that to change when we rebuild the packages in trixie. Cheers -- Sebastian Ramacher
Bug#1070121: nmu: coreutils_9.4-3 (trixie), pam_1.5.2-9.1 (trixie)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: coreut...@packages.debian.org, p...@packages.debian.org, debian-b...@lists.debian.org Control: affects -1 + src:coreutils src:pam coreutils_9.4-3.1 and pam_1.5.3-7 aren't currently migrating to trixie for whatever reason. Because debootstrap doesn't currently know about versioned Provides, I think it would be useful to get versions of these packages in trixie that have been rebuilt against the 64-bit time_t ABIs and package names. If the versions in trixie don't migrate imminently, please consider: nmu coreutils_9.4-3 . ANY . trixie . -m "rebuild against libssl3t64" nmu pam_1.5.2-9.1 . ANY . trixie . -m "rebuild against libdb5.3t64" In a trixie derivative (a non-public future branch of the Steam Runtime) I found that local rebuilds of those two source packages were enough to bring a minbase debootstrap back from repeatably failing to reasonably reliable. I hope they would have a similar effect in real trixie. Based on kibi's thread "Making trixie debootstrap-able again?" on -release and -boot, binNMUing util-linux and iproute2 might also help for d-i's use-case, which is larger than minbase and wants fdisk and iproute2: nmu util-linux_2.39.3-6 . ANY . trixie . -m "rebuild against libreadline8t64" nmu iproute2_6.7.0-2 . ANY . trixie . -m "rebuild against libtirpc3t64" but I have not independently verified that those two are necessary or sufficient. smcv