Package: rele...@debian.org
Severity: normal
User: release.debian....@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-arm@lists.debian.org, debian-gtk-gn...@lists.debian.org
The plan is for Debian 12 to release with GNOME 43, which is currently in
beta upstream. Beta versions of individual GNOME 43 packages are gradually
making their way into either unstable if they are not disruptive, or
experimental if they are. One of the new packages we need is an update
to gjs, GNOME's JavaScript environment, which depends on mozjs102
(Spidermonkey), the latest stable-branch of Mozilla's JavaScript engine.
mozjs102 makes more use of atomic operations, which are available on
all architectures except for armel (because armel is ARMv5, and useful
atomics are ARMv6 or ARMv7 instructions). This has led to a few different
failure modes when building mozjs102 on armel (#1017979, #1017961).
Even if we can solve them eventually, I think delaying GNOME 43 for the
benefit of machines that are not powerful enough to run GNOME would be
doing a disservice to our users.
So I think we need to be looking at the possibility of doing
architecture-specific removals of gjs and dependent packages from armel.
Based on prior experience of similar architecture-specific removals from
s390x when mozjs was compiling-but-broken on that architecture, I think
this would involve:
- removing gjs
- removing gnome-shell (and its extensions)
- removing gdm3
- either hacking gnome-panel to be able to compile without gdm3, or
removing it
- either hacking meta-gnome3 to install a non-GNOME display manager and
the GNOME Flashback desktop environment (basically a GNOME 2 fork)
instead of real GNOME, or leaving it unmodified but accepting that
gnome-core and therefore task-gnome-desktop are uninstallable on armel
- disabling a subset of unit tests in src:ostree (which want gjs)
- removing leaf apps written in JavaScript, such as polari
Obviously that's quite a bit of churn, mostly in packages that, in
practice, have never been useful to run on the 2009-2010 plug computers
that seem to be the main use-case for armel.
Is armel a realistic candidate for being a Debian 12 release
architecture? It's already lacking other important packages like Firefox,
and if it ceased to be treated as a release architecture very soon,
then we wouldn't have to do all this work to coax GNOME into testing
despite armel.
Or, failing that, is it still the release team's position that all task
packages are required to be installable on all architectures, and that it
is preferable to have a task install the wrong things rather than have
it be uninstallable? If we could have task-gnome-desktop and gnome-core
just be uninstallable on armel, and have the testing machinery accept
and ignore that, then that would seem more honest than having to modify
them like we did for s390x[1].
As with my previous work on mozjs + s390x, it is worth noting that I
am not an ARM porter or an ARM desktop user, my only armel machine is
no longer supported as of Debian 11 and was never able to run GNOME
in any case, and I have no special knowledge of mozjs. However, the
release-architecture constraints demand that someone sorts this out
before we can have a new GNOME release in testing, and I am someone, so
I'm doing my best. Anyone with useful knowledge of these architectures
and packages is very welcome to help!
Thanks,
smcv
[1] https://lists.debian.org/debian-release/2018/12/msg00287.html
