Control: severity -1 serious [Raising the severity to serious so that it appears on our radar.]
Dear mips64el porters, On 2025-01-27 20:32:20 +0100, Emilio Pozuelo Monfort wrote: > On 23/01/2025 15:32, Simon McVittie wrote: > > Package: release.debian.org > > Severity: normal > > Tags: trixie > > X-Debbugs-Cc: debian-m...@lists.debian.org, > > debian-gtk-gn...@lists.debian.org, debian-b...@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. > > 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. We are having serious concerns regarding the state of mips64el for trixie. Beside this bug report (#1050872), other teams have raised concerns as well. From the arch qualification page [1], the current list of concerns for mips64el: * upstream-support: no: no upstream support in GCC, unaddressed test failures in binutils * concerns-rm: yes: upgrading buildds is impossible due to kernel bugs, kernel bugs are hitting some of the buildds making them unusable, builders are extremely slow (also per kernel team), only one porter has volunteered, lack of autopkgtest infrastructure, future availability of hardware * concerns-dsa: yes: non-server-grade hardware, time sink for DSA and hosters As we are getting closer to the trixie release, we would like to hear from you. What is your take on these concerns? Cheers [1] https://release.debian.org/testing/arch_qualify.html -- Sebastian Ramacher
