Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?
Hi,
On 2023-08-30 16:54, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: debian-mips@lists.debian.org, bluca@debian.org, debian-wb-team@lists.debian.org
>
> 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, and we've been told that (old)stable point releases
> are the preferred way to achieve that.
>
> When Luca asked how many suites we needed this change in, we were hoping
> the answer would be stable only, and maybe oldstable (which is still
> in its 1 year of overlapping support from the security team and DDs
> in general).
>
> However, if I understand correctly, Luca has been told that some official
> mips64el buildds are running mipsel user-space on mips64el hardware which
> only works with the buster kernel, and therefore those official buildds
> are still stuck on buster, meaning we also need to prepare a buster
> version of debootstrap and get it into Debian 10 LTS via buster-security.
>
> Is this true?
This is correct. We have issues running buster 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.
> >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.
That's also our wishes. Unfortunately real life makes things more
difficult, even on x86. And not speaking about buildds, some services
also do not run on newer debian releases.
> Also, from the point of view of continued development of testing/unstable,
> I would have hoped that packages in testing/unstable could safely
> assume that they will run on at least the kernel from stable (or maybe
> oldstable for a short time after a new stable release), following our
> usual "skipping a release is unsupported" rule. Obviously if the buildds
> are running on an oldoldstable kernel, any mips64el package that might
> be used at compile-time or for build-time tests will be unable to make
> that assumption.
Yes, this is definitely problem, and it has already been reported.
> Please could someone with knowledge of the buildds clarify the situation?
>
> If our official buildds for a release architecture are unable to run on
> either the stable or oldstable kernel, I think that raises some important
> questions about suitability for inclusion in future releases.
I don't think this assumption should change, instead we should have a
way to upgrade those hosts. Probably we'll just decommission them
instead.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: