Cyril Brulebois <k...@debian.org> (2024-04-26): > Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting > because I'm really not sure this would be the right course of action, more > details below) a new binNMU of coreutils within testing would be > sufficient to make trixie debootstrap-able again, I built a modified > repository, and try debootstrap against it, only to find more problems: > - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone. > - iproute2 depends on libtirpc3, which is gone. > > I guess the reason is similar, the former I tracked down to the same block > of hints as before: > > # 2024-04-23; done 2024-04-25 > # help some t64 packages migrate > […] > force-hint readline/8.2-4 > > The latter I tracked down to thisone: > > # 2024-04-23; done 2024-04-26 > # get t64 unstuck > urgent libtirpc/1.3.4+ds-1.3 > force-hint libtirpc/1.3.4+ds-1.3 > > Again, I have absolutely no clue regarding the best course of action at > this point. I can't even perform clean builds to check what a binNMU in > testing would look like, as I can't debootstrap a clean environment (and > therefore only tested rebuilds in an existing, devel-oriented, unclean > trixie chroot).
Looks like I forgot to mention the final results: with the modified repository stuffed with (unclean) rebuilds of coreutils, iproute2, and util-linux, I'm able to debootstrap trixie again. (I've hacked a repository together from scratch, based on the failed debootstrap's apt cache, adding rebuilt packages, and injecting new dependencies manually; I could redo that cleanly by forking trixie's current Packages instead, but I'm not sure it's really worth the efforts, esp. given rebuilt packages are “tainted” anyway.) Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
