Bug#1093859: release.debian.org: mips64el vs. librsvg needs resolving for trixie

Hi,

On 23/01/2025 15:32, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> Tags: trixie
> X-Debbugs-Cc: [email protected], [email protected], [email protected]
> 
> 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.

This sounds like a blocker for trixie. I don't think removing librsvg because of 
a kernel bug is sensible, especially when this affects other core packages such 
as git. A solution needs to be found, otherwise we may have to reconsider the 
mips64el situation. I'd appreciate if porters could give an update.

Cheers,
Emilio