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 _______________________________________________ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers