Package: release.debian.org
Severity: normal
Tags: trixie
X-Debbugs-Cc: debian-m...@lists.debian.org, debian-gtk-gn...@lists.debian.org,
debian-boot@lists.debian.org
The current version of librsvg is not migrating to testing because it
FTBFS on mips64el. This appears to be caused by a kernel or hardware
issue where otherwise-working code fails with EFAULT in a read() call
on bookworm kernels (see #1093200): this is not librsvg-specific, and
affects other Rust components, as well as git, Erlang and Go.
Presumably something in the Rust and Go ecosystem is making use of a
function-calling pattern that is more likely to trigger this than typical
C/C++ code, but I don't know the full details. buster kernels (as used on
the mips64el porterbox and some older buildds) do not seem to be affected.
Indications from the bug are that bullseye kernels (5.10) might also be
unaffected, at least for git (I don't think the rust packages have
necessarily been tried there).
It is unknown whether trixie/bookworm-backports kernels are affected.
This seems to have been happening for about 6 months (since 2024-08-15),
although until recently it was possible to mitigate it by retrying builds
until they got scheduled on a buildd that happened to be using a buster
kernel.
Is the mips porting team actively looking into this, for example attempting
to reproduce it on similar hardware with bookworm-backports kernels?
Or, is the release team perhaps already considering demoting mips64el to
non-release status?
If there is no prospect of a fix, and if mips64el is still a release
architecture, then we will need to remove librsvg from mips64el so that it
isn't holding all other architectures back. A quick experiment with
`dak rm -R -n` says this would involve architecture-specific removals
of around 250 packages (plus whatever depends on those packages,
recursively). It might also require sourceful changes in some of the
affected packages, to add a Build-Depends on a package from librsvg
(where there is not one already), to ensure they don't get rebuilt on
mips64el until librsvg is buildable again.
In particular removing librsvg would mean we lose a build-dependency of
debian-installer from mips64el (-boot cc'd) which would make mips64el into
another upgradable-but-not-installable architecture with no installer,
like armel and i386.
Other Rust/Erlang/Go packages are likely to be in a similar situation,
but most of them are higher up the dependency stack (less key) than
librsvg, so removing them might be less painful.
smcv
