Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

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?

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?

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

    smcv