Your message dated Thu, 22 Jan 2026 23:18:35 +0100
with message-id <[email protected]>
and subject line mozjs128: SharedArrayBuffer feature unavailable on armel
has caused the Debian Bug report #1080000,
regarding mozjs128: SharedArrayBuffer feature unavailable on armel
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 [email protected]
immediately.)
--
1080000: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080000
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: mozjs128
Version: 128.1.0-3
Severity: important
Tags: ftbfs
User: [email protected]
Usertags: armel
X-Debbugs-CC: [email protected]
After fixing #1079077, mozjs128 still fails to build on armel, because
the lack of lockless atomic operations results in the SharedArrayBuffer
feature being disabled, and that makes several tests fail.
This feature seems to be used in the implementation of features that don't
obviously require it, for example:
> ## non262/RegExp/split-trace.js: rc = 3, run time = 0.011209
> 887016: Trace RegExp.prototype[@@split] behavior.
> /home/smcv/mozjs/js/src/tests/non262/RegExp/split-trace.js:99:42 TypeError:
> SharedArrayBuffer is disabled
> Stack:
> @/home/smcv/mozjs/js/src/tests/non262/RegExp/split-trace.js:99:42
> TEST-UNEXPECTED-FAIL | non262/RegExp/split-trace.js | (args: "") [0.0 s]
where split-trace.js:99 is:
> var ret = RegExp.prototype[Symbol.split].call(myRegExp, target);
I don't know enough JavaScript to know whether this is likely to be
fixable or ignorable, or whether we will have to remove mozjs128 and
therefore gjs from armel (which would require workarounds similar to
what we did when we removed them from s390x during the buster cycle).
The main reason we need gjs is GNOME Shell, and I suspect nobody is
actually using GNOME Shell on armel: it seems unlikely to work well
with an older CPU emulating floating-point in software using integer
operations. Removing GNOME Shell from armel would be annoying, because
we would either have to ensure that task-gnome-desktop is still installable
(as we did for s390x in buster) or convince the release/d-i teams that it's
OK for it not to be, but is probably more achievable than adding features
to an architecture that mozjs upstream doesn't intend to support.
A secondary reason why we have gjs is that some leaf GNOME applications
(e.g. clapper, foliate, gnome-maps) are written in JavaScript, and those
are somewhat more likely to have real users on armel.
smcv
--- End Message ---
--- Begin Message ---
armel was removed, so I am closing this bug.
--- End Message ---
