Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Simon McVittie]

Package: ***@debian.org
Severity: normal
User: ***@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-***@lists.debian.org, debian-gtk-***@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

[Simon McVittie]

Control: retitle -1 mini-transition: gjs built against mozjs102
Control: unblock -1 by 1018819
Control: tags -1 = pending

Post by Simon McVittie
I think we need to be looking at the possibility of doing
architecture-specific removals of gjs and dependent packages from armel.

We were able to get mozjs102_102.3.0-1 compiling and passing most of
its test suite on armel and all other release architectures (thanks
to Adrian Bunk and Mike Hommey for providing the necessary patches),
and gjs_1.74.0-2 has built successfully against it on all release
architectures and is also passing tests, so I'm now hoping we can keep
the full GNOME 43 family of packages on armel for Debian 12.

If these versions reach testing without incident, which should happen
next week if all goes well, then no release team action will be required,
and the only remaining cleanup before closing this bug will be to remove
mozjs91 from unstable (which I'm intentionally not doing until after
mozjs102 migrates).

I would still consider armel (among other architectures) to be "at risk"
for subsequent GNOME releases, but the next GNOME release (GNOME 44) will
be halfway through the Debian 12 freeze, so it isn't a concern for Debian
12 and will be something for the Debian 13 release process to deal with.

smcv

[John Paul Adrian Glaubitz]

Hello!

Post by Simon McVittie
Control: retitle -1 mini-transition: gjs built against mozjs102
Control: unblock -1 by 1018819
Control: tags -1 = pending

Post by Simon McVittie
I think we need to be looking at the possibility of doing
architecture-specific removals of gjs and dependent packages from armel.

We were able to get mozjs102_102.3.0-1 compiling and passing most of
its test suite on armel and all other release architectures (thanks
to Adrian Bunk and Mike Hommey for providing the necessary patches),
and gjs_1.74.0-2 has built successfully against it on all release
architectures and is also passing tests, so I'm now hoping we can keep
the full GNOME 43 family of packages on armel for Debian 12.

Could you blacklist the test

“ large-arraybuffers/basic.js”

on all affected big-endian targets (powerpc, ppc64, sparc64)?

The test is blacklist on s390x and fails on powerpc and ppc64 as well.

Thanks,
Adrian