Debian Bug report logs - #1080521
transition: Removing gjs and GNOME Shell from armel

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: transition: Removing gjs and GNOME Shell from armel

Date: Thu, 5 Sep 2024 11:44:31 +0100

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

Message #12 received at 1080521@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 1080521@bugs.debian.org

Cc: debian-gtk-gnome@lists.debian.org, debian-arm@lists.debian.org

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

Date: Fri, 6 Sep 2024 14:16:01 +0100

On Thu, 05 Sep 2024 at 11:44:31 +0100, Simon McVittie wrote:
> 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.

> 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...

> 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

Message #17 received at 1080521@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: Simon McVittie <smcv@debian.org>, 1080521@bugs.debian.org

Cc: debian-gtk-gnome@lists.debian.org, debian-arm@lists.debian.org

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

Date: Fri, 6 Sep 2024 17:32:37 +0200

[Message part 1 (text/plain, inline)]

Hi,

On 06-09-2024 15:16, Simon McVittie wrote:
> 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

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Message #24 received at 1080521@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: Simon McVittie <smcv@debian.org>, 1080521@bugs.debian.org

Cc: debian-gtk-gnome@lists.debian.org, debian-arm@lists.debian.org

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

Date: Thu, 12 Sep 2024 13:48:22 +0200

[Message part 1 (text/plain, inline)]

Hi

On 06-09-2024 17:32, Paul Gevers wrote:
> 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/918d41dda41dff06c9f14fb3dd4111d85492316c.camel@decadent.org.uk

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Message #31 received at 1080521@bugs.debian.org (full text, mbox, reply):

From: Jeremy Bícha <jeremy.bicha@canonical.com>

To: 1080521@bugs.debian.org

Cc: debian-gtk-gnome@lists.debian.org, debian-arm@lists.debian.org

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

Date: Wed, 18 Sep 2024 13:07:02 -0400

On Fri, Sep 6, 2024 at 9:16 AM Simon McVittie <smcv@debian.org> wrote:
> 0. Adapt some packages to stop depending on gjs or gnome-shell on armel:
> […]
> 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

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

Message #38 received at 1080521@bugs.debian.org (full text, mbox, reply):

From: Jeremy Bícha <jeremy.bicha@canonical.com>

To: 1080521@bugs.debian.org

Cc: debian-gtk-gnome@lists.debian.org

Subject: Re: RM: src:gjs and rdeps [armel] -- RoM/RoQA; #1080521

Date: Fri, 20 Sep 2024 17:04:39 -0400

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

Message #51 received at 1080521@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: Simon McVittie <smcv@debian.org>, 1080521@bugs.debian.org

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

Date: Thu, 17 Oct 2024 15:12:31 +0200

[Message part 1 (text/plain, inline)]

Hi,

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?

Paul

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Message #56 received at 1080521-done@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

Cc: 1080521-done@bugs.debian.org

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

Date: Thu, 17 Oct 2024 14:29:39 +0100

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

Send a report that this bug log contains spam.