Making trixie debootstrap-able again?

[Cyril Brulebois]

Hi,

I'm not sure how we reached this situation but there are a bunch of
packages in trixie that are not in a suitable state. To reproduce, a
simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient.

Note: I've limited my exploration to amd64, which kept me busy already


An obvious first problem is coreutils, which picked a Pre-Depends on
libssl3 (not the t64 one), which
 disappeared from testing between the
2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at
Packages.gz for amd64 via snapshot.debian.org).

The coreutils binNMU is hardly new, as it appeared via unstable in
January, and was already in testing by April 1st (I didn't check earlier
than that). Therefore I'm quite baffled to see libssl3 happily disappear
from testing while we still have stuff that Pre-Depends on it?!

Checking britney, I suppose this is a result of the following hint:

# 2024-04-23; done 2024-04-25
# help some t64 packages migrate
[
]
force-hint openssl/3.2.1-3

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).

Seeing how some packages, e.g. coreutils, have DEP-17 changes staged in
unstable (since 1.5+ month), I'm definitely not advocating for pushing
them into testing as a quick or easy fix for those issues.


I'm not sure whether you're keeping track of things that break when
force-hinting but if you were aware of the resulting breakages already,
some kind of heads-up would have been nice



Cheers,

[Cyril Brulebois]

Post by Cyril Brulebois
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
- 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
# 2024-04-23; done 2024-04-25
# help some t64 packages migrate
[
]
force-hint readline/8.2-4
# 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,

[Sebastian Ramacher]

Hi

we've been made aware on #d-release that my hints broke debootstrap. I
am working through the remaining packages that are relevant for
debootstrap, but it takes some time.

Post by Cyril Brulebois
I'm not sure how we reached this situation but there are a bunch of
packages in trixie that are not in a suitable state. To reproduce, a
simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient.
Note: I've limited my exploration to amd64, which kept me busy already…
An obvious first problem is coreutils, which picked a Pre-Depends on
libssl3 (not the t64 one), which… disappeared from testing between the
2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at
Packages.gz for amd64 via snapshot.debian.org).

The core problem is that deboostrap fails to understand versioned
Provides. libssl3t64 on amd64:

Package: libssl3t64
Source: openssl
Version: 3.2.1-3
Installed-Size: 7302
Maintainer: Debian OpenSSL Team <pkg-openssl-***@alioth-lists.debian.net>
Architecture: amd64
Replaces: libssl3
Provides: libssl3 (= 3.2.1-3)
Depends: libc6 (>= 2.34), libzstd1 (>= 1.5.5), zlib1g (>= 1:1.1.4)
Breaks: libssl3 (<< 3.2.1-3), openssh-client (<< 1:9.4p1), openssh-server (<< 1:9.4p1), python3-m2crypto (<< 0.38.0-4)
Description-en: Secure Sockets Layer toolkit - shared libraries
This package is part of the OpenSSL project's implementation of the SSL
and TLS cryptographic protocols for secure communication over the
Internet.
.
It provides the libssl and libcrypto shared libraries.
Description-md5: 88547c6206c7fbc4fcc7d09ce100d210
Multi-Arch: same
Homepage: https://www.openssl.org/
Section: libs
Priority: optional
Filename: pool/main/o/openssl/libssl3t64_3.2.1-3_amd64.deb
Size: 2243528
MD5sum: 8919d70ec8be690308f3970878113b1a
SHA256: 84bf4abab84da9c8a2bdd2b161ae02d4de78657fe77483bf7656d8a368344add

So that britney dropped libssl3 from testing on !armel !armhf is fine in
genaral, but britney does not account for deboostrap not supporting
versioned Provides. That's the same for all the other packages involved
in bootstraping.

Post by Cyril Brulebois
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).

I am currently looking into making coreutils and systemd (which needs
glib2.0) migrate. I hope to have it back in a debootstrapable-step after
the weekend. If you are aware of more apckages that need help, please
let us know.

Cheers

[Holger Levsen]

hi kibi,

fwiw, bootstraping trixie still works using mmdebstrap, while it fails
with debootstrap and cdebootstrap.

I've notified #-release about the debootstrap breakage on the 24th
and added that mmdebstrap was still working on the 25th...

https://jenkins.debian.net/job/reproducible_mmdebstrap_trixie/ etc show
this nicely.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

If it feels like we’re breaking climate records every year, it’s because we are.

[Cyril Brulebois]

Hi,

Post by Cyril Brulebois
I'm not sure how we reached this situation but there are a bunch of
packages in trixie that are not in a suitable state. To reproduce, a
simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient.

That works again, presumably following the configuration changes in
britney made it complete again, finally migrating stuff.

Post by Cyril Brulebois
Note: I've limited my exploration to amd64, which kept me busy
already


That proviso is still true.


Cheers,