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