On Wed, 30 Aug 2023 at 21:26:24 +0200, Aurelien Jarno wrote:
> On 2023-08-30 16:54, Simon McVittie wrote:
> > Luca Boccassi and I have been preparing stable and oldstable updates for
> > debootstrap so that the transition described in DEP-17 can continue.
> > Because DEP-17 involves changes to trixie/sid chroots' bootstrap
> > procedures, the updated debootstrap needs to be deployable to every
> > official buildd
>
> We have issues running [bookworm?] and bullseye kernels on
> some arm32 and mips*el buildds. The problem on arm has been solved by
> decommissioning the hardware or by hosts dying. We still have problems
> with a big part of the mips*el hosts.
Would it be possible to make an exception to the usual rule that buildds
get their debootstrap from (old)stable point releases, and manually
install a newer debootstrap (the version proposed for bullseye should
be suitable) onto the affected mips*el machines? I see that they already
have a newer-than-buster version of sbuild, possibly from the
buster-backports suite (which was discontinued when buster was handed over
to the LTS team).
I would prefer not to spend time preparing and testing a special buster
version of debootstrap and negotiating with the Debian 10 LTS team to get
it into buster/updates in the security archive; and it's not clear to
me that there is actually any apt repository that we could put it into
that would be accepted by the affected buildds, because buster is read-only
in the main Debian archive, and debian-security no longer has
dists/buster/updates/main/binary-mips64el at all?
(debian-security does have binary-all, and debootstrap is Architecture:
all, but I'm not sure how much that would help us with buster's apt, since
separate Packages files for binary-all seem to be a relatively new thing.)
> > From the point of view of the project having control over its own future,
> > I would have hoped that official Debian infrastructure would only be using
> > suites that are supported by Debian as a whole, rather than handing over
> > control and responsibility to the Debian-LTS subproject.
Sam Hartman pointed out on #debian-devel that this is worse than I thought,
because Debian-LTS doesn't cover mips*el. So as far as I can see, there is
no channel that gets security updates onto these buildds at all?
smcv
