Bug#906016: transition: gjs built with mozjs60

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 10/10/2018 12:41, Simon McVittie wrote:
> On Wed, 10 Oct 2018 at 10:13:32 +0200, Emilio Pozuelo Monfort wrote:
>> On 05/10/2018 10:10, Simon McVittie wrote:
>>> The new mozjs version does not work on s390x, so to make gjs migrate,
>>> we will need to do architecture-specific removals (I'm not sure whether
>>> this should be from testing or unstable) of binaries from at least
>>> [some] source packages
> 
> I assume these removals will need to be requested *after* we have uploaded
> gjs 1.54.x (the branch that uses mozjs60) to unstable, otherwise they
> will just get rebuilt on s390x at their next upload. Is that correct?

Yes.

> When it's time to do those removals, should we be asking the ftp team
> to remove s390x binaries from unstable, or asking the release team to
> remove s390x binaries from testing?

>From unstable against the ftp.debian.org metapackage.

>>> Is there a better way we can deal with packages like gdm3 (which require
>>> gnome-shell at runtime) [...] Perhaps a (slightly spurious) Build-Depends
>>> on gjs?
>>
>> A build-dep would be preferred, either on gjs or gnome-shell or whatever you
>> deem appropriate.
> 
> We've been adding build-dependencies on gjs as our way to stop non-working
> s390x binaries from coming back. Jeremy says he'll NMU the various
> Architecture: any GNOME Shell extensions to add this, if necessary.
> 
>> My only question: is cjs moving to mozjs60 too, so that we can remove mozjs52?
> 
> Not in the short term. Moving to a new mozjs version is a major change
> that needs to be coordinated with cjs upstream. Unfortunately, cjs
> upstream seem to be refusing to consider any request coming from Debian
> until unrelated (?) bugs are fixed in NetworkManager in stable (if I'm
> understanding correctly). See <https://github.com/linuxmint/cjs/issues/69>
> (trigger warning: hostility towards Debian as a project, and Debian
> maintainers as representatives of Debian).
> 
> libproxy1-plugin-mozjs (a proxy-auto-configuration backend for libproxy)
> was recently reintroduced and also uses mozjs52, although meta-gnome3
> still depends on libproxy1-plugin-webkit instead, for its better security
> support. Laurent, was there a particular reason for reintroducing the
> mozjs plugin while we are discussing a move from mozjs52 to mozjs60,
> and would its addition be OK to revert? It seems that it tends to make
> libproxy crash whenever run by a gjs app in a non-GNOME environment:
> <https://bugzilla.redhat.com/show_bug.cgi?id=1524507>. As with cjs,
> porting libproxy to mozjs60 should happen upstream or not at all.
> 
> policykit-1 in experimental also uses mozjs52, so even if gjs, cjs and
> libproxy are all dealt with somehow (ported or removed, as appropriate),
> I would like to keep mozjs52 in unstable until policykit-1 moves to
> mozjs60 (which, again, should happen upstream or not at all). If gjs,
> cjs and libproxy all stop using mozjs52, then it would be OK to remove
> it from testing, and leave it unstable-only for policykit-1's benefit,
> with an artificial RC bug to stop it from migrating.

Ok. We no longer have mozjs or mozjs24 in sid so I can leave with keeping
mozjs52 if necessary. Obviously if those rdeps can be ported for buster, then
all the better.

Please go ahead.

Emilio