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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

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

Julien Cristau-6
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

Reply | Threaded
Open this post in threaded view
|

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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

Ben Hutchings-3
On Mon, 2018-12-24 at 12:01 +0000, 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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Bicha-5
In reply to this post by John Paul Adrian Glaubitz
On Sun, Dec 23, 2018 at 10:30 AM John Paul Adrian Glaubitz
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Emilio Pozuelo Monfort-4
In reply to this post by Simon McVittie-7
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 task-gnome-desktop
installability issue on s390x now that mozjs is not working there?

Thanks,
Emilio

Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

Emilio Pozuelo Monfort-4
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

Reply | Threaded
Open this post in threaded view
|

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

Cyril Brulebois-4
Hi,

Emilio Pozuelo Monfort <[hidden email]> (2019-02-08):

> > 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?
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 ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
On Fri, 08 Feb 2019 at 16:48:52 +0100, Cyril Brulebois wrote:
> 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

Reply | Threaded
Open this post in threaded view
|

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

Emilio Pozuelo Monfort-4
On 08/02/2019 17:21, Simon McVittie wrote:

> On Fri, 08 Feb 2019 at 16:48:52 +0100, Cyril Brulebois wrote:
>> 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.

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.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

Cyril Brulebois-4
Hi,

Simon McVittie <[hidden email]> (2019-03-02):

> On Tue, 05 Feb 2019 at 10:16:56 +0000, 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 ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
In reply to this post by Simon McVittie-7
Control: block -1 by 923694

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

Reply | Threaded
Open this post in threaded view
|

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

Emilio Pozuelo Monfort-4
On 08/03/2019 10:07, Simon McVittie wrote:

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