Bug#1080521: transition: Removing gjs and GNOME Shell from armel

[Simon McVittie]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-gtk-***@lists.debian.org, debian-***@lists.debian.org
Control: affects -1 + src:gjs
User: ***@packages.debian.org
Usertags: transition

gjs is a JavaScript language binding for GLib-based libraries, required
by GNOME Shell, as well as several leaf GNOME applications like foliate
and gnome-maps. As part of GNOME 47, which is the GNOME release that
is likely to be shipped in Debian 13, gjs will need to be upgraded from
1.80.x (based on mozjs115) to 1.81.x/1.82.x (based on mozjs128).

However, mozjs128 fails several tests on armel (#1080000) because armel's
lack of atomic integer operations results in the SharedArrayBuffer feature
being disabled. This might have been feasible to work around if it was just
a single high-level feature that most applications don't need, but in fact
it's causing lots of regular-expression-related tests to fail, which seems
like something that tips mozjs/gjs on armel over the line from "works,
with limitations" to "probably not useful in practice".

mozjs is a subset of firefox and firefox-esr, which already FTBFS on
armel, and upstream is unlikely to be interested in keeping their web
browser engine working on CPUs where it is probably not practically
usable. Similarly, I'm pretty sure GNOME Shell is already not practically
usable on the plug computers and similar embedded devices that define
the baseline for armel.

So I think for trixie we are going to need to plan to stop building gjs
on armel, and do architecture-specific removals of gjs itself and all
of its rdeps. Does the release team have any advice or comments on this?

Last time we had to remove gjs from an architecture (last time it was
s390x), we found that the release infrastructure would not allow the
removal of gnome-shell to migrate to testing, because there is a check
that requires all tasksel tasks are installable (I think the internal
term is "faux packages"). Previously we worked around this by making
the gnome-core metapackage not actually install GNOME on the affected
architecture, but instead installing GNOME Flashback; this was a bit of a
lie (GNOME Flashback is not really GNOME, and has its own separate tasksel
task), but probably nobody is intentionally installing GNOME on armel
or s390x anyway. Is a similar workaround going to be necessary for armel?

Thanks,
smcv

[Simon McVittie]

Post by Simon McVittie
mozjs128 fails several tests on armel (#1080000) because armel's
lack of atomic integer operations results in [badness]

Deja vu: we had a very similar situation almost exactly 2 years ago,
when we were integrating the GNOME release that ended up being shipped
in bookworm. (#1018076)

For the 2022 version of this transition, ARM porters were able to get
mozjs102 to work, but I would prefer not to make this a blocker for
getting GNOME 47 into testing, and it seems like a waste of the porters'
valuable time to be putting effort into enabling something that in any
case is unlikely to be practically useful.

Post by Simon McVittie
Last time we had to remove gjs from an architecture (last time it was
s390x), we found that the release infrastructure would not allow the
removal of gnome-shell to migrate to testing

When we discussed this in 2022, Paul Gevers said that the release team
could probably disable this check and allow task-gnome-desktop to be
uninstallable on armel...

Post by Simon McVittie
Previously we worked around this by making
the gnome-core metapackage not actually install GNOME on the affected
architecture, but instead installing GNOME Flashback; this was a bit of a
lie

... which would make this workaround unnecessary.

I believe this means that when gjs 1.81.x/1.82.x is otherwise ready,
the plan will be similar to
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018076#86>:

0. Adapt some packages to stop depending on gjs or gnome-shell on armel:
- gdm3 - GNOME team can do this
- libportal - GNOME team can do this
- libsecret - GNOME team can do this
- ostree - GNOME team can do this
- (glade is already compiled without gjs on armel since 2022)
- (ibus-tests is already not shipped on armel since 2022)
- (libguestfs is already compiled without gjs on armel since 2022)
1. Wait for release team ack
2. Upload gjs/experimental and packages from (0.) to unstable
3. Adapt meta-gnome3 so gnome-core and gnome are only built on
architectures that have a working gjs
4. Remove only these armel *binaries* (as NBS), leaving the rest of their
source packages intact:
- gdm3 (from src:gdm3)
- gnome-core (from src:meta-gnome3)
- gnome (from src:meta-gnome3)
5. Remove all binaries of these source packages from armel:
- eos-sdk
- foliate
- gjs
- gnome-characters
- gnome-maps
- gnome-shell
- gnome-shell-extension-desktop-icons-ng
- gnome-shell-extension-gsconnect
- gnome-shell-extension-manager
- gnome-shell-mailnag
- gnome-shell-pomodoro
- gnome-sound-recorder
- gnome-sushi
- gnome-weather
- gpaste
- polari
6. Release team will need to force through the transition by ignoring the
"all task packages are installable" check on armel, because
task-gnome-desktop will now be uninstallable on armel

Does that sound right?

(I've just uploaded the gjs 1.81.90 release candidate to experimental.)

Thanks,
smcv

[Paul Gevers]

Hi,

Post by Simon McVittie
When we discussed this in 2022, Paul Gevers said that the release team
could probably disable this check and allow task-gnome-desktop to be
uninstallable on armel...

I recall that we currently can't build d-i on armel anymore because
there are not kernel udeb. I think we effectively said we're done with
the installer on armel and hence we don't need to care about
task-gnome-desktop on armel as much.

I also think that the faux-packages list is/can be architecture
specific, so it's probably trivial to fix but adding all architectures
but armel.

Let me do some checking if I got the details above correct. I'm
convinced we should be able to deal with this on the Release Team side
of this.

Paul

[Paul Gevers]

Hi

Post by Paul Gevers
I also think that the faux-packages list is/can be architecture
specific, so it's probably trivial to fix but adding all architectures
but armel.

I have made the constraints arch specific and dropped armel from the
list. Looking at the current britney2 log I see that the
task-pkgs-are-installable-faux is in the list for gwenview/<arch> except
for armel, so that seems to work as intended.

Given [1] we should probably do the same for i386 very soon too.

Paul

[1]
https://lists.debian.org/msgid-search/***@decadent.org.uk

[Jeremy Bícha]

Post by Simon McVittie
[…]
1. Wait for release team ack
2. Upload gjs/experimental and packages from (0.) to unstable
3. Adapt meta-gnome3 so gnome-core and gnome are only built on
architectures that have a working gjs
4. Remove only these armel *binaries* (as NBS), leaving the rest of their
- gdm3 (from src:gdm3)
- gnome-core (from src:meta-gnome3)
- gnome (from src:meta-gnome3)
- eos-sdk
- foliate
- gjs
- gnome-characters
- gnome-maps
- gnome-shell
- gnome-shell-extension-desktop-icons-ng
- gnome-shell-extension-gsconnect
- gnome-shell-extension-manager
- gnome-shell-mailnag
- gnome-shell-pomodoro
- gnome-sound-recorder
- gnome-sushi
- gnome-weather
- gpaste
- polari
6. Release team will need to force through the transition by ignoring the
"all task packages are installable" check on armel, because
task-gnome-desktop will now be uninstallable on armel

I believe we have finished steps 0, 1, and 3. Step 4 is mostly done:
gdm3's removal is only requested not done yet.

Can I proceed with uploading the new gjs to unstable to finish step 2?

I also created https://salsa.debian.org/installer-team/tasksel/-/merge_requests/32
but maybe that's unnecessary since task-gnome-desktop is currently
arch: all.

Thank you,
Jeremy Bícha

[Jeremy Bícha]

A few other false positives since they are arch:all :

foliate
gnome-sound-recorder
gpaste (the gjs dependency is arch: all)
gnome-shell-extension-desktop-icons-ng
gnome-shell-extension-gsconnect

Thank you,
Jeremy Bícha

[Paul Gevers]

Hi,

Post by Simon McVittie
gjs is a JavaScript language binding for GLib-based libraries, required
by GNOME Shell, as well as several leaf GNOME applications like foliate
and gnome-maps. As part of GNOME 47, which is the GNOME release that
is likely to be shipped in Debian 13, gjs will need to be upgraded from
1.80.x (based on mozjs115) to 1.81.x/1.82.x (based on mozjs128).

gjs and gdm3 migrated to testing. Do you consider this transition done now?

Paul