Hi,
Cyril Brulebois (2024-04-26):
> 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
On 27/04/2024 00:14, Sebastian Ramacher wrote:
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
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...
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.
On 2024-04-26 18:35:59 +0200, Cyril Brulebois wrote:
> I'm not sure how we reached this situation but there are a bunch
Cyril Brulebois (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
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
6 matches
Mail list logo
