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.


Reply via email to