--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: transition: Removing gjs and GNOME Shell from armel
- From: Simon McVittie <smcv@debian.org>
- Date: Thu, 5 Sep 2024 11:44:31 +0100
- Message-id: <ZtmLj3BwCzarO2FX@remnant.pseudorandom.co.uk>
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-gtk-gnome@lists.debian.org, debian-arm@lists.debian.org
Control: affects -1 + src:gjs
User: release.debian.org@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
--- End Message ---
--- Begin Message ---
On Thu, 17 Oct 2024 at 15:12:31 +0200, Paul Gevers wrote:
> On 05-09-2024 12:44, Simon McVittie wrote:
> > 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?
Yes, closing the bug.
smcv
--- End Message ---