Your message dated Sun, 18 May 2025 10:34:16 +0200
with message-id <bc8e67f9-5dec-4f72-ab56-7814b99ab...@debian.org>
and subject line Re: Bug#1093859: release.debian.org: status of mips64el for
trixie
has caused the Debian Bug report #1093859,
regarding release.debian.org: status of mips64el for trixie
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1093859: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093859
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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.
smcv
--- End Message ---
--- Begin Message ---
Hi,
On 12-04-2025 12:35, Simon McVittie wrote:
While that specific bug did eventually get fixed, it seems concerning
that it had to be maintainers of affected packages who raised the alarm
about this, rather than the porting team noticing that there was a more
general problem. It also seems concerning that #1093200 was eventually
fixed by a maintainer of a different affected package rather than by the
mips64el porting team - it doesn't seem healthy for ports to be kept
alive by individual heroics from someone who doesn't even have the
relevant hardware.
Indeed. The lack of response to several queries and in particular to our
final warning [1] has made us decide that mips64el will not be an
official trixie architecture. This has just been announced on d-d-a [2].
Paul
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100544#89
[2]
https://lists.debian.org/msgid-search/e1ugzlq-00149a...@respighi.debian.org
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
