Bug#906016: transition: gjs built with mozjs60

Discussion:

(too old to reply)

Simon McVittie

2018-12-17 15:10:04 UTC

task-pkgs-are-installable-faux depends on task-gnome-desktop, which depends on
gnome, which is removed from s390x. I'm not comfortable breaking that, you'd
need an ack from Cyril for that. The alternative would be to keep building
gnome from src:meta-gnome3 on s390x but removing the deps that are not available,
or to apply the proposed mozjs patches from upstream to restore support on s390x
if those are enough.

Another option is to restrict the task-gnome-desktop check to !s390x. But again
I'd like an ack from Cyril before doing that in case d-i needs to be updated to
not offer that on s390x.

For context for those newly Cc'd:

We have this dependency chain:

task-gnome-desktop -> gnome-core -> gnome-shell -> gjs -> mozjs{52,60}

gjs recently switched from mozjs52 to mozjs60, and mozjs60 doesn't work
on s390x (#909536; about 80% of its tests fail, which means I have no
confidence that the resulting binaries would be useful or usable if
we ignored the test failures). As far as I know, the best patches we
have for that are the ones Julien Cristau tested, which might be part
of a solution but are not sufficient on their own to make a reasonable
proportion of the tests pass. (Julien, please correct me if I'm wrong?)

The GNOME team and the release team both seem to be willing to declare
that the "full-fat" GNOME desktop will not be available on s390x
machines, which are very conspicuously not available in a desktop or
laptop form factor :-) I'm fairly sure that GNOME and Mozilla upstream
have no interest in supporting s390x mainframes either. As a result we
have arranged for all the JavaScript-based GNOME packages (most notably
gnome-shell), and the gnome-core and gnome metapackages, to not be built
on s390x. However, this leaves us with an important task package that
isn't installable on a release architecture, causing migration to fail.

I suspect gnome-shell may have never worked acceptably on s390x in any
case, since mainframes are not noted for their 3D graphics hardware,
and s390x is not currently whitelisted to build the llvmpipe software
renderer in mesa's debian/rules (I believe the Mesa maintainers are
willing to enable llvmpipe on new architectures after a porter has tested
it and told them it works, so a s390x porter could usefully try that out).

The options I can see are:

* Accept that task-gnome-desktop is not going to be installable on s390x.
Change the testing migration scripts to skip installability testing for
that package on s390x, or ignore the fact that it fails. Optionally
change tasksel to make task-gnome-desktop Architecture: any, and give it
some Build-Depends-Arch that are not satisfiable on s390x so that it will
not be built there.
- s390x d-i users will not be able to install a GNOME desktop. Hopefully
the menu item would not appear, and task-desktop would pick up the
second-preference desktop instead, which currently seems to be XFCE?
- Risk: is it possible to ignore uninstallability of task-gnome-desktop
without ignoring uninstallability of other task packages?

* Require task-gnome-desktop to be installable on s390x, but modify
meta-gnome3 so that on s390x, gnome-core installs something that is not
the full GNOME 3 desktop used on other architectures, for example
the GNOME-2-derived gnome-session-flashback instead of gnome-session and
gnome-shell, and lightdm instead of gdm3.
- s390x users will not get the same GNOME desktop everyone else does.
- Risk: if GNOME Flashback becomes unsupportable in some future release
(it's a GNOME 2 derivative a bit like MATE, although without using
forks of the apps, and most upstream and downstream GNOME maintainers
don't use or maintain it), we're back where we started.

* Require task-gnome-desktop to be installable on s390x, but modify
meta-gnome3 so that on s390x, gnome-core doesn't install a whole desktop
enviroment at all, just the GNOME applications.
- s390x users will not get a GNOME desktop at all.
- Risk: this is not what the user asked for or expected.

* Require task-gnome-desktop to be installable on s390x, but modify
either tasksel or meta-gnome3 so that on s390x, task-gnome-desktop
installs some GNOME-derived but non-GNOME desktop environment like MATE.
- s390x users will not get the same desktop environment everyone
else does.
- Risk: this is not what the user asked for or expected.

I don't think waiting for someone who understands s390x to fix gjs-on-s390x
is an option, although s390x porters are very welcome to prove me wrong!

How should we proceed?

Thanks,
smcv

Simon McVittie

2018-12-24 12:10:01 UTC

Permalink

Can we postpone the decision until after the holidays? Then I have enough
time for trying to whip up a patch.

That seems fine, but please note that most of the changes necessary to
remove gjs from s390x happened some time ago (in late September and early
October); so if you are able to make mozjs60 work correctly on s390x,
we will likely already need to revert some changes to bring it back.
If the d-i maintainers remove gjs/GNOME Shell on s390x and then you
subsequently get mozjs60 working on s390x, the list of changes to revert
to bring back gjs/s390x just becomes slightly longer.

I'm also not at all sure whether the GNOME Shell environment works
on s390x hardware, which as far as I know doesn't have either a
Mesa-supported GPU or the llvmpipe driver - if it never worked then we
aren't actually losing anything. Presumably s390 porters would have a
better idea of what works and what doesn't.

smcv

Ben Hutchings

2018-12-24 12:30:01 UTC

Permalink

Post by Simon McVittie

Can we postpone the decision until after the holidays? Then I have enough
time for trying to whip up a patch.

That seems fine, but please note that most of the changes necessary to
remove gjs from s390x happened some time ago (in late September and early
October); so if you are able to make mozjs60 work correctly on s390x,
we will likely already need to revert some changes to bring it back.
If the d-i maintainers remove gjs/GNOME Shell on s390x and then you
subsequently get mozjs60 working on s390x, the list of changes to revert
to bring back gjs/s390x just becomes slightly longer.
I'm also not at all sure whether the GNOME Shell environment works
on s390x hardware, which as far as I know doesn't have either a
Mesa-supported GPU or the llvmpipe driver - if it never worked then we
aren't actually losing anything. Presumably s390 porters would have a
better idea of what works and what doesn't.

IBM Z (why do they keep renaming it?) supports PCI Express now, so I
think it's *possible* to install a Mesa-supported GPU, if unlikely.

Ben.

--
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.

Jeremy Bicha

2018-12-31 02:00:02 UTC

Permalink

On Sun, Dec 23, 2018 at 10:30 AM John Paul Adrian Glaubitz

Can we postpone the decision until after the holidays? Then I have enough
time for trying to whip up a patch.

I don't see any value in delaying any longer. It's pretty easy to let
gjs/s390x back in; removing it has been quite a bit harder. As Simon
pointed out, 90% of this work was done 3 months ago; it's the final
hard bits that we need done now.

This bug's history gives you the list of packages to check when
gjs/s390x becomes usable.

Thanks,
Jeremy Bicha

Simon McVittie

2019-02-05 10:30:01 UTC

Permalink

Please could we have a decision on this in plenty of time before the freeze?
Given the upstream GC improvements aimed at mitigating or solving "the memory
leak problem" in gjs 1.54.x, I am not comfortable with releasing buster with
gjs 1.52.x (which has a backport of those changes done by a developer who does
not have in-depth knowledge of gjs, namely me); so I would like to ask for a
freeze exception to complete this transition.

Post by Simon McVittie
* Accept that task-gnome-desktop is not going to be installable on s390x.
Change the testing migration scripts to skip installability testing for
that package on s390x, or ignore the fact that it fails. Optionally
change tasksel to make task-gnome-desktop Architecture: any, and give it
some Build-Depends-Arch that are not satisfiable on s390x so that it will
not be built there.
- s390x d-i users will not be able to install a GNOME desktop. Hopefully
the menu item would not appear, and task-desktop would pick up the
second-preference desktop instead, which currently seems to be XFCE?
- Risk: is it possible to ignore uninstallability of task-gnome-desktop
without ignoring uninstallability of other task packages?

I would prefer this option if possible: the GNOME desktop is clearly not
intended for use on mainframes, and I doubt anyone is seriously trying to use
it there (as opposed to individual GNOME apps in a remote-desktop framework,
which might be something that people do). However, it requires action from the
release team and d-i maintainers.

Post by Simon McVittie
* Require task-gnome-desktop to be installable on s390x, but modify
meta-gnome3 so that on s390x, gnome-core installs something that is not
the full GNOME 3 desktop used on other architectures, for example
the GNOME-2-derived gnome-session-flashback instead of gnome-session and
gnome-shell, and lightdm instead of gdm3.
- s390x users will not get the same GNOME desktop everyone else does.
- Risk: if GNOME Flashback becomes unsupportable in some future release
(it's a GNOME 2 derivative a bit like MATE, although without using
forks of the apps, and most upstream and downstream GNOME maintainers
don't use or maintain it), we're back where we started.

With the freeze approaching fast, if we can't have a solution that requires
action to be taken outside the GNOME team, this is probably the best thing that
the GNOME team can do unilaterally. An untested git branch for this:
https://salsa.debian.org/gnome-team/meta-gnome3/merge_requests/3

However, note that if the resulting s390x flavour of task-gnome-desktop becomes
unsupportable (perhaps in buster+1) and we switch to the first option, we will
need ftp team intervention (again) to remove obsolete binary packages.

Post by Simon McVittie
* Require task-gnome-desktop to be installable on s390x, but modify
meta-gnome3 so that on s390x, gnome-core doesn't install a whole desktop
enviroment at all, just the GNOME applications.
- s390x users will not get a GNOME desktop at all.
- Risk: this is not what the user asked for or expected.

I think having task-gnome-desktop not install a GNOME desktop violates the
principle of least astonishment.

Post by Simon McVittie
* Require task-gnome-desktop to be installable on s390x, but modify
either tasksel or meta-gnome3 so that on s390x, task-gnome-desktop
installs some GNOME-derived but non-GNOME desktop environment like MATE.
- s390x users will not get the same desktop environment everyone
else does.
- Risk: this is not what the user asked for or expected.

Likewise.

Post by Simon McVittie
I don't think waiting for someone who understands s390x to fix gjs-on-s390x
is an option, although s390x porters are very welcome to prove me wrong!

As predicted, this didn't happen in the 7 weeks since I said this. If someone
does fix mozjs60/gjs on s390x at the eleventh hour, all of the options above
would be straightforward to revert, so I don't think we should let waiting for
this delay us even further.

I have investigated the endianness-related crashes some more and tried to
backport patches from upstream that resolve some of them, but there are still
too many test failures for me to consider the resulting package to be
non-RC-buggy (and as far as I can tell, the upstream patches would break mips,
which is 32-bit BE and is also a Debian release architecture). I don't think
it's sustainable to expect the GNOME team to carry out significant s390x
porting work: we already have a small number of people maintaining a lot of
high-visibility packages, and whatever time we put into porting to s390x is
time we are not spending on improvements that affect our users on more
mainstream desktop/laptop architectures like x86 and ARM.

smcv

Cyril Brulebois

2019-02-08 16:00:03 UTC

Permalink

Hi,

Post by Simon McVittie

I would prefer this option if possible: the GNOME desktop is clearly
not intended for use on mainframes, and I doubt anyone is seriously
trying to use it there (as opposed to individual GNOME apps in a
remote-desktop framework, which might be something that people do).
However, it requires action from the release team and d-i
maintainers.

Cyril, can we do something to not offer task-gnome-desktop on s390x?
Does that need changes in d-i or tasksel?

FWIW we already have this in place, regarding the default desktop:
https://salsa.debian.org/installer-team/tasksel/blob/master/default_desktop

I'm not sure how to hide a particular entry on a particular arch; I'm
not a tasksel expert and won't be one in the next 5 minutes. But it
seems to me the immediate concern was about the default desktop anyway,
which shouldn't be an issue in the first place because of this
default_desktop shell function?

Cheers,

--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Simon McVittie

2019-02-08 16:30:01 UTC

Permalink

Post by Cyril Brulebois
I'm not sure how to hide a particular entry on a particular arch; I'm
not a tasksel expert and won't be one in the next 5 minutes. But it
seems to me the immediate concern was about the default desktop anyway,
which shouldn't be an issue in the first place because of this
default_desktop shell function?

The immediate concern is that gjs and friends don't migrate to testing,
because the release team's migration infrastructure asserts that all
task packages remain installable on all release architectures, and that
isn't true any more for task-gnome-desktop on s390x.

Do you consider it to be OK that non-default desktops can be uninstallable
on s390x? If so, hopefully the release team can relax that check.

Thanks,
smcv

Simon McVittie

2019-03-02 22:30:01 UTC

Permalink

In the absence of other progress, I've staged this in git. I'll release
it soon if nobody else in the team gets there first. The resulting
metapackage appears to be installable on a s390x buster qemu VM with only
sid as an apt source (so, only able to see the version of gjs in sid that
we want to migrate, and not the one in buster that we want to supersede).

My worry if I were to do that is that the installer would still offer to install
GNOME on s390x, and I don't know what would happen if one chose that (I suppose
apt would realise it's uninstallable and give a proper error, but maybe things
would explode).
So if we're going to make task-gnome-desktop uninstallable there, maybe the
installer shouldn't offer to install it, and that needs changes somewhere in
tasksel or d-i.

Some questions whose answers I think might be relevant to determining
how much effort is justifiable here:

* Do s390x users install with debian-installer?
* If so, do they install desktop tasks that way?
* Does GNOME (the desktop, as opposed to individual apps) work on s390x
in earlier Debian releases? (If, as I suspect, the answer is "we don't
know, nobody has tried it" then that is itself useful information.)

Regards,
smcv

Cyril Brulebois

2019-03-04 18:20:01 UTC

Permalink

Hi,

Post by Simon McVittie

Some questions whose answers I think might be relevant to determining
* Do s390x users install with debian-installer?
* If so, do they install desktop tasks that way?
* Does GNOME (the desktop, as opposed to individual apps) work on s390x
in earlier Debian releases? (If, as I suspect, the answer is "we don't
know, nobody has tried it" then that is itself useful information.)

I don't have any answers here. My searching debian-boot@ for âs390xâ in
the body and âinstallation-reportâ in the subject returned this small
list of bug reports: #575682, #296930, #608407, #694771, #851790,
#859889, #923524 (which you know aboutâŠ).

Anyway, just to confirm: if one hacks an archive to get gnome-core out
of the amd64's Packages file, tasksel (run from a chroot rather than
from d-i, configured with this hacked repository) still lists the gnome
desktop task as an available optionâŠ

Cheers,

--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Simon McVittie

2019-03-08 09:10:01 UTC

Permalink

Control: block -1 by 923694

Post by Simon McVittie

In the absence of other progress, I've staged this in git. I'll release
it soon if nobody else in the team gets there first.

This has now reached testing, but gjs is blocked by gnome-documents:

trying: polari gjs gnome-shell gdm3 gnome-sushi
skipped: polari gjs gnome-shell gdm3 gnome-sushi (0, 1, 25)
got: 33+0: a-1:a-0:a-0:a-0:i-30:m-0:m-0:m-0:p-0:s-2
* s390x: gnome-documents

gnome-documents already has an unblock request.

If that unblock is rejected or if the release team are not sure about
it yet, the gnome-documents_3.30.0-1_s390x binary could be forcibly
removed from testing, which I think would let the gjs family migrate.
`dak rm -R -n -s testing -a s390x gnome-documents` says nothing else on
s390x depends on gnome-documents any more.

smcv