Hi, On 2023-08-31 00:29, Simon McVittie wrote: > 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.)
This has already been discussed on IRC that you should not worry about debootstrap for buster, provide you leave us ~1 month. Not sure yet what we'll do, it could be your option, stopping the buildds as discussed on IRC, or maybe yet another option. > > > 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? Yes this is correct for mips*el. We still have debian-lts for the arm hosts though. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
