On Wed, 30 Aug 2023 at 16:54:01 +0100, Simon McVittie wrote:
> 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.
It's been about a year, so it seems like it's time to catch up on this.
According to db.debian.org, we have these mips(64)el machines:
- eberlin (porterbox, LS3A-RS780-1w (Quad Core Loongson 3A), Linux 4.19.249-2)
- mipsel-manda-{04,05} (buildd, Quad Core Loongson 3A3000)
- mipsel-osuosl-{01,02} (buildd, Rhino Labs UTM8)
- mipsel-osuosl-{03,04,05} (buildd, Quad Core Loongson 3A3000)
running these kernels and OSs (directly queried on the porterbox, taken
from a semi-recent buildd log for the others):
- eberlin:
- 4.19.0-21-loongson-3 4.19.249-2 (Debian 10)
- Debian 10 user-space
- mipsel-osuosl-{01,02}:
- 4.19.0-21-octeon 4.19.249-2 (Debian 10)
- Debian 11 user-space (guessed from sbuild version)
- mipsel-osuosl-{03,04}:
- 6.1.0-23-loongson-3 6.1.99-1 (Debian 12)
- presumably Debian 12 user-space (guessed from sbuild version)
- mipsel-osuosl-05:
- 6.1.0-21-loongson-3 6.1.90-1 (Debian 12)
- presumably Debian 12 user-space
- mipsel-manda-{04,05}:
- probably >= 5.10.0-22-loongson-3 (Debian 11)
- probably >= Debian 11 user-space
I was unable to find a recent build on mipsel-manda-{04,05} on
buildd.debian.org: are they perhaps reserved for -security or something?
During the most recent builds with public logs that I could find there
(1-2 years ago), they appear to have been running 5.10.0-22-loongson-3
(Debian 11 kernel) with what appears to be Debian 11 user-space, which
presumably means that these two buildds do not suffer from the kernel
issue that prevented mipsel-osuosl-{01,02} from being upgraded beyond a
buster kernel, so hopefully they are running Debian 12 by now.
However, this means that, 1 year into Debian 12's lifetime as stable, two
of our official buildds for a release architecture are still running a
Debian 10 kernel, with no security fixes beyond 2 years ago. Meanwhile,
the porterbox that is an ordinary Debian developer's only opportunity to
debug problems on this architecture is running the same outdated kernel,
and also Debian 10 user-space. mips64el is not supported by Debian LTS or
ELTS, so there is no channel that I'm aware of from which these machines
could receive security fixes, even outside Debian itself.
This worries me, and I think it should be a factor in decisions made by
the release, security and DSA teams about whether mips64el is a candidate
to be a release architecture in trixie.
If the mips64el porting team and their hardware sponsors would like it
to be treated as a potential release architecture, then I think it would
be a good idea to prioritize either providing a newer kernel that can
run successfully on the hardware that is used for Debian's official
buildds, or replacing mipsel-osuosl-{01,02} with hardware that can run
newer kernels successfully.
Or, if mips64el is not a realistic candidate to be a trixie release
architecture, then I think it would be useful to announce that, so that
the rest of the project isn't expected to spend our limited time and
effort on enabling it.
The issue that prompted me to look at this again is that a change recently
merged into schroot caused a regression for buildds that run on unstable,
and one plausible solution to that regression would involve dropping
support for extremely old kernels (at least Debian 8, posssibly Debian
9 or 10). During discussion of that issue, another developer suggested
that some mips64el buildds are still running on Linux 4.9 (Debian 9),
although I'm hoping that he was misinformed.
smcv
