Re: Bug#906016: transition: gjs built with mozjs60

[Emilio Pozuelo Monfort]

On 08/03/2019 10:07, Simon McVittie wrote:
> Control: block -1 by 923694
> 
> On Sat, 02 Mar 2019 at 22:21:31 +, Simon McVittie wrote:
>> On Tue, 05 Feb 2019 at 10:16:56 +, Simon McVittie wrote:
> * 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
>>
>> 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.

I unblocked and aged gnome-{documents,books}, my britney test run has gjs
migrating now, so it should happen in the next few hours.

Cheers,
Emilio

Re: Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

Control: block -1 by 923694

On Sat, 02 Mar 2019 at 22:21:31 +, Simon McVittie wrote:
> On Tue, 05 Feb 2019 at 10:16:56 +, Simon McVittie wrote:
> > > > * 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
> 
> 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

Re: Bug#906016: transition: gjs built with mozjs60

[Cyril Brulebois]

Hi,

Simon McVittie  (2019-03-02):
> On Tue, 05 Feb 2019 at 10:16:56 +, Simon McVittie wrote:
> > > > * 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
> 
> 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).
> 
> On Fri, 08 Feb 2019 at 18:10:01 +0100, Emilio Pozuelo Monfort wrote:
> > 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.)

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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

On Tue, 05 Feb 2019 at 10:16:56 +, Simon McVittie wrote:
> > > * 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

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

On Fri, 08 Feb 2019 at 18:10:01 +0100, Emilio Pozuelo Monfort wrote:
> 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

Re: Bug#906016: transition: gjs built with mozjs60

[Emilio Pozuelo Monfort]

Hi,

On 05/02/2019 11:16, Simon McVittie wrote:
> 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.

Yes, it is my intention to finish this.

> On Thu, 17 Jan 2019 at 10:25:01 +0100, Emilio Pozuelo Monfort wrote:
>> On 17/12/2018 15:56, Simon McVittie wrote:
>>> 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?
> 
> 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?

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

Alternatively, this is probably the way to go.

Cheers,
Emilio

Re: Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

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.

On Thu, 17 Jan 2019 at 10:25:01 +0100, Emilio Pozuelo Monfort wrote:
> On 17/12/2018 15:56, Simon McVittie wrote:
> > 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?

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.

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

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

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

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

Re: Bug#906016: transition: gjs built with mozjs60

[Emilio Pozuelo Monfort]

Hi Cyril,

On 17/12/2018 15:56, Simon McVittie wrote:
> On Thu, 13 Dec 2018 at 17:00:21 +0100, Emilio Pozuelo Monfort wrote:
>> On 13/12/2018 16:58, Emilio Pozuelo Monfort wrote:
>>> 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!

Any thoughts on the proposed solutions for this 

Re: Bug#906016: transition: gjs built with mozjs60

[Jeremy Bicha]

On Sun, Dec 23, 2018 at 10:30 AM John Paul Adrian Glaubitz
 wrote:
> 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

Re: Bug#906016: transition: gjs built with mozjs60

[Ben Hutchings]

On Mon, 2018-12-24 at 12:01 +, Simon McVittie wrote:
> On Sun, 23 Dec 2018 at 16:29:31 +0100, John Paul Adrian Glaubitz wrote:
> > 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.




signature.asc
Description: This is a digitally signed message part

Re: Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

On Sun, 23 Dec 2018 at 16:29:31 +0100, John Paul Adrian Glaubitz wrote:
> 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

Re: Bug#906016: transition: gjs built with mozjs60

[John Paul Adrian Glaubitz]

Hi!

On 12/17/18 4:11 PM, Julien Cristau wrote:
>> We might have a patch for s390x in openSUSE/SLE, I'll have a look. There
>> also might be one in Fedora we could pick for Debian.
>>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1488552 is what I was
> hitting last time around.  That got resolved as fixed a few days ago,
> although it depends on a refactoring that's not in 60.  Still, might be
> worth trying to run SpiderMonkey tests on trunk on 64bit BE and see if
> and how much better it is now.

Interesting, thanks for the link. I would give it a go over the holidays,
I have already put it on my TODO list for the holidays.

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

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#906016: transition: gjs built with mozjs60

[Julien Cristau]

On 12/17/18 4:08 PM, John Paul Adrian Glaubitz wrote:
> On 12/17/18 3:56 PM, Simon McVittie wrote:
>> 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).
> 
> This sounds suspicious and more like a single bug that breaks mozjs60 on
> s390x, maybe similar to the issues we have on SPARC due to the tagged pointers
> conflicting with the extended virtual address on SPARC.
> 
> We might have a patch for s390x in openSUSE/SLE, I'll have a look. There
> also might be one in Fedora we could pick for Debian.
> 
https://bugzilla.mozilla.org/show_bug.cgi?id=1488552 is what I was
hitting last time around.  That got resolved as fixed a few days ago,
although it depends on a refactoring that's not in 60.  Still, might be
worth trying to run SpiderMonkey tests on trunk on 64bit BE and see if
and how much better it is now.

Cheers,
Julien

Re: Bug#906016: transition: gjs built with mozjs60

[John Paul Adrian Glaubitz]

On 12/17/18 3:56 PM, Simon McVittie wrote:
> 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).

This sounds suspicious and more like a single bug that breaks mozjs60 on
s390x, maybe similar to the issues we have on SPARC due to the tagged pointers
conflicting with the extended virtual address on SPARC.

We might have a patch for s390x in openSUSE/SLE, I'll have a look. There
also might be one in Fedora we could pick for Debian.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

On Thu, 13 Dec 2018 at 17:00:21 +0100, Emilio Pozuelo Monfort wrote:
> On 13/12/2018 16:58, Emilio Pozuelo Monfort wrote:
> > 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