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
