Bug#969321: transition: GNOME 3.38 (mutter, evolution-data-server, etc.)
Control: tags -1 - moreinfo
Control: clone -1 -2
Control: retitle -1 transition: GNOME 3.38, libmutter-7-0
Control: forwarded -1 https://release.debian.org/transitions/html/auto-mutter.html
Control: retitle -2 transition: Evolution 3.38
Control: forwarded -2 https://release.debian.org/transitions/html/auto-evolution-data-server.html
On Mon, 31 Aug 2020 at 12:00:05 +0100, Simon McVittie wrote:
> GNOME 3.38 will be released on 2020-09-16, and beta versions of the
> major packages (versioned 3.37.x) are already making their way into
> experimental and Ubuntu.
The ftp team have now accepted mozjs78 (thanks to whoever did that!) and
3.38.0 releases of the core GNOME packages are in either unstable or
experimental, so I think we're ready to do the GNOME Shell 3.38 transition.
> As usual, there will be a series of entangled small transitions which I
> think would be best handled as a single larger transition
This might actually be better as two separate transitions: mutter and
evolution-data-server, with the core GNOME packages accompanying mutter.
The gnome-shell in experimental was actually compiled against unstable's
evolution-data-server anyway.
> * Core packages like gnome-shell, -session, -settings-daemon and gdm3 rely
> on being at reasonably well-aligned versions and will have Breaks to
> ensure they're upgraded from 3.36.x to 3.37.x/3.38.x as a batch
>
> * gnome-shell needs a new version of mutter with ABI breaks (currently
> in experimental-NEW)
> - budgie-core will need at least binNMUs and maybe sourceful changes
>
> * The new gjs version needs mozjs78 (currently in unstable-NEW).
> mozjs68 will continue to exist at least briefly, so we don't have to
> do a flag-day transition, although we should try to remove some versions
> from bullseye after this transition is over. We currently have:
> - mozjs52 (old, RC-buggy, used by Cinnamon)
> - (mozjs60 became unused and was removed)
> - mozjs68 (used by current gjs, libproxy and experimental policykit-1)
> + for libproxy we are already considering removing the mozjs plugin
> (#959805)
> + for policykit-1 as far as I know there's no intention to ship the
> version that needs mozjs in testing/unstable
> - mozjs78 (in NEW)
>
> * gnome-shell almost certainly breaks the JavaScript API that is presented
> to Shell extensions
> - IMO, extensions that cannot be ported promptly should be removed from
> testing to avoid holding back the desktop
These are the main GNOME 3.38 transition. The only C ABI break is in
libmutter, but we should do -shell, -session, -settings-daemon, gdm3,
-control-center, -desktop and gsettings-desktop-schemas as part of the
same batch.
The version of gjs that uses mozjs78 was (perhaps mistakenly) uploaded
to unstable already, so moving to mozjs78 and gjs 1.66 will be going
ahead whether we want it to or not. IMO this means we should do rest
of this part of the transition quite soon too - upstream will not have
done serious testing on the old Shell with the new gjs. I've reported
a RC bug to stop gjs from migrating before we're ready for it.
budgie-desktop should be the only non-GNOME-team package directly affected
by this, apart from gnome-shell-xrdesktop which is not in testing anyway
(and needs to move to contrib). budgie needs at least a rebuild and maybe
source changes, but there's already a version built against libmutter-7-0
waiting in experimental.
Ubuntu already did this transition.
As I said before, some GNOME Shell extensions will almost certainly break,
but we don't know which ones (I checked the few I maintain personally and
they seem OK). I think we should be fairly trigger-happy about removing
these from testing if they're broken or uninstallable.
> * evolution-data-server has an ABI break, which has already made its way
> through NEW
> - https://release.debian.org/transitions/html/auto-evolution-data-server.html
I think we can perhaps defer this one until after mutter, Shell and
the other core packages have gone through? Or we could entangle them,
whichever you'd prefer. There are more packages involved and I don't know
the status of all of them: Sebastien Bacher would probably know better.
Ubuntu already did this transition too.
Thanks,
smcv
Reply to: