Bug#954422: transition: GNOME 3.36

On 2020-04-08 11:46:59 +0100, Simon McVittie wrote:
> On 21/03/2020 13:17, Simon McVittie wrote:
> > > It would probably make most sense to treat gnome-desktop3 and mutter as
> > > a single transition, as we have often done in the past: upstream will
> > > not have tested arbitrary mixtures of 3.34 and 3.36.
> 
> Progress on this:
> 
> After chasing regressions for the last few days, I think we have Shell
> in a good state to consider doing this transition. This would involve
> uploading the following experimental GNOME packages to unstable as a batch:
> 
> * gnome-desktop3
> * gjs
> * mutter
> * gnome-shell
> * gnome-shell-extensions
> 
> Ubuntu have already done this transition for 20.04 'focal', so I hope
> the Ubuntu people in the GNOME team can give us an idea of the level of
> breakage without us having to do our own test-rebuild in Debian.
> I'm told the only significant porting work needed in Ubuntu was in Unity.
> 
> gnome-desktop3 ABI breaks have mostly been handled via binNMUs in the
> past, without being particularly problematic.
> 
> budgie will need rebuilding against the new mutter, but seems to have
> already been patched to cope with either the old or new API/ABI.
> 
> gnome-shell-xrdesktop (a "friendly fork" of gnome-shell with an
> experimental 3D UI for VR headsets) will need either updating to 3.36.x
> to match (#956147) or removing from testing for a while. I am not able
> to test this, and I suspect the rest of the GNOME team are in the same
> situation; I don't think we should let gnome-shell-xrdesktop (popcon: 0)
> hold back gnome-shell (popcon: 37K votes).

The xrdesktop stack is currently doing its own transition
(libgulkan-0.13-0 -> libgulkan-0.14-0, libgxr-0.13-0 -> libgxr-0.14-0,
and soon the same for libxrdesktop). It's currently blocked on xrdesktop
in NEW.

Cheers

> Third-party GNOME Shell extensions are likely to regress (they do that
> a lot, because they work by monkey-patching GNOME Shell internals). I
> think we should remove any problematic extensions from testing rather
> than let them hold up Shell. Of the three I maintain myself, I have
> uploaded a fixed version of one to experimental, and confirmed that
> the other two work acceptably as-is. Hopefully that's a reasonably
> representative sample.
> 
> My next upload of gnome-shell will hopefully add a workaround for
> one major source of regressions in extensions, which is that the way
> older extensions invoke a preferences dialog is no longer supported
> (#956172 and similar bugs). Extensions will still need fixing for this
> before 3.38 or for use on other distros, but the workaround removes the
> immediate urgency.
> 
>     smcv
> 

-- 
Sebastian Ramacher

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE94y6B4F7sUmhHTOQafL8UW6nGZMFAl6NwgwACgkQafL8UW6n
GZO0Jg//dQu+/WZ4E0D02Wvq2M7lBoKQK6mPejVeLyLsVHBztL8OdAQY3Nwp5+/w
ufCfRVULpKZm2/UUWd8hBRrDWKQLrgOfghlgcuO0HxqsNBXKUbuCQhEAcl4zAEd/
DLMysEXQJTArCGS8N2wmZkS0VnTNrm1amfHSE/nLu9oie9N0+7TaCnedFbatpQVp
+tGnJ82RFq1bdsvr8rn43KOFolOvxBHbY6gmkYZOBRaJS1DlkwqN9bv1vwh1kd7j
xzmAbK/rruHN+oSfy7iaI95pLIRrKSfG/D7xs95OqippXhSE+y1+kelTSaaFv7y0
al4vNkB4B4EDUHVFEjTiZeZaaC9DOy0xH0T8kt/+XXSRNSuIBjUi+rWg0VA6y6kb
iqZwCkRxbrkXMnER1bbqM8b+d8ygvf1zq1yJWUch1D1jb4ic1X6zcB6VbeYCzuQF
ydXL65RzdVNfvkBZaAI1tpvihl9dVwuSpeRb1fWd2wkH1HbaxnQoutj5P1/qdCyl
MR7yiJmcnq7wiysQyY9Hl2qJO76Utj2ot9otkeZkCtwku5tf40XpMQXOlvGQGBme
lmHq8QRzjk107bI4bZ5ruEP/FbLfHw720pruzlOjSwE1FZ2VEvQIbI9BpN+34E57
fqjDGzzcovgG1gjUBy8nhEvoLhQ0HKL5EphY0jTN7ghgR59cmWU=
=lDSB
-----END PGP SIGNATURE-----