[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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

Attachment: signature.asc
Description: PGP signature


Reply to: