Re: Bug#954422: transition: GNOME 3.36

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#954422: transition: GNOME 3.36

Simon McVittie-7
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).

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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#954422: transition: GNOME 3.36

Emilio Pozuelo Monfort-4
Control: tags -1 confirmed

On 08/04/2020 14:22, Sebastian Ramacher wrote:

> 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.

Let's go ahead. The situation looks to be in a good state. Extensions have
always been treated this way, on a best effort basis during the transitions, so
we'll keep as many as we can but if any of them aren't compatible and don't get
updated in time we'll drop them from testing until they are fixed.

The xrdesktop/gulkan transition looks to be almost done now, but even if it
wasn't, the only point of entanglement is gnome-shell-xrdesktop which worst case
can be temporarily removed.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Re: Bug#954422: transition: GNOME 3.36

Simon McVittie-7
On Fri, 10 Apr 2020 at 12:27:04 +0200, Emilio Pozuelo Monfort wrote:
> Let's go ahead. The situation looks to be in a good state. Extensions have
> always been treated this way, on a best effort basis during the transitions, so
> we'll keep as many as we can but if any of them aren't compatible and don't get
> updated in time we'll drop them from testing until they are fixed.

The packages that trigger this transition (gjs, gnome-desktop3, mutter and
gnome-shell) have now built on all release architectures (and apparently
gnome-shell now passes its build-time tests on s390x again, although as
before it's anyone's guess whether it works or is practically useful).

Sub-transitions involved in this:

https://release.debian.org/transitions/html/auto-mutter.html
- budgie-desktop needs sourceful changes (#952639, fixed in experimental) -
  David, please could you upload the changes from experimental into unstable?
- gnome-shell-xrdesktop needs a new upstream release (#956147)

https://release.debian.org/transitions/html/auto-gnome-desktop3.html
- Should be ready to start binNMUs
- Please binNMU xdg-desktop-portal-gtk in experimental too
- No point in binNMUing budgie-desktop due to the mutter transition
- No point in binNMUing gnome-shell-xrdesktop due to the mutter transition

https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
- -appindicator needs sourceful changes (#956451, fixed in experimental)
- -easyscreencast needs sourceful changes (#956166)

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Bug#954422: transition: GNOME 3.36

Simon McVittie-7
Control: tags -1 - moreinfo

On Sat, 11 Apr 2020 at 13:42:46 +0100, Simon McVittie wrote:
> https://release.debian.org/transitions/html/auto-gnome-desktop3.html
> - Should be ready to start binNMUs
> - Please binNMU xdg-desktop-portal-gtk in experimental too
> - No point in binNMUing budgie-desktop due to the mutter transition
> - No point in binNMUing gnome-shell-xrdesktop due to the mutter transition

In case it wasn't clear: please binNMU when convenient.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Bug#954422: transition: GNOME 3.36

Emilio Pozuelo Monfort-4
On 15/04/2020 09:53, Simon McVittie wrote:

> Control: tags -1 - moreinfo
>
> On Sat, 11 Apr 2020 at 13:42:46 +0100, Simon McVittie wrote:
>> https://release.debian.org/transitions/html/auto-gnome-desktop3.html
>> - Should be ready to start binNMUs
>> - Please binNMU xdg-desktop-portal-gtk in experimental too
>> - No point in binNMUing budgie-desktop due to the mutter transition
>> - No point in binNMUing gnome-shell-xrdesktop due to the mutter transition
>
> In case it wasn't clear: please binNMU when convenient.

Sorry for the delay. Scheduled now.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Re: Bug#954422: transition: GNOME 3.36

Simon McVittie-7
In reply to this post by Emilio Pozuelo Monfort-4
On Fri, 10 Apr 2020 at 12:27:04 +0200, Emilio Pozuelo Monfort wrote:
> Let's go ahead.

gnome-desktop3 has migrated, but gnome-shell and mutter have not. We're
now getting reports that GNOME Shell in testing is crashing because it
indirectly loads more than one copy of gnome-desktop3.

Would it be possible to binNMU affected packages *in testing*, so that
everything is using the same version even before they migrate? (I'm
not sure whether that will work - they might FTBFS - but it seems worth
a try.)

Dependent packages that are not in sync between testing and unstable:

- mutter
- gnome-shell
- gnome-weather (for completeness, but probably doesn't matter here)

Or is there something else we should have done to make this transition
go more smoothly, like having gnome-desktop3 3.36.x Breaks older
gnome-shell and mutter?

Giving libgnome-desktop-3-19 a Conflicts on -17 and -18 doesn't seem
great because it defeats part of the purpose of the SONAMEs, but perhaps
that would have been the lesser evil?

Versioned symbols in gnome-desktop3 would not help us here, because the
GObject type system is a flat global namespace.

If you would prefer to solve this by getting GNOME Shell 3.36.x
into testing ASAP: it looks as though gnome-shell 3.36 is ready to
migrate if gnome-shell-xrdesktop, gnome-shell-extension-dashtodock,
gnome-shell-extension-easyscreencast are temporarily removed, and
gnome-shell-extension-appindicator is aged by at least a day.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Bug#954422: transition: GNOME 3.36

Emilio Pozuelo Monfort-4
On 16/04/2020 10:08, Simon McVittie wrote:

> On Fri, 10 Apr 2020 at 12:27:04 +0200, Emilio Pozuelo Monfort wrote:
>> Let's go ahead.
>
> gnome-desktop3 has migrated, but gnome-shell and mutter have not. We're
> now getting reports that GNOME Shell in testing is crashing because it
> indirectly loads more than one copy of gnome-desktop3.
>
> Would it be possible to binNMU affected packages *in testing*, so that
> everything is using the same version even before they migrate? (I'm
> not sure whether that will work - they might FTBFS - but it seems worth
> a try.)
>
> Dependent packages that are not in sync between testing and unstable:
>
> - mutter
> - gnome-shell
> - gnome-weather (for completeness, but probably doesn't matter here)
>
> Or is there something else we should have done to make this transition
> go more smoothly, like having gnome-desktop3 3.36.x Breaks older
> gnome-shell and mutter?
>
> Giving libgnome-desktop-3-19 a Conflicts on -17 and -18 doesn't seem
> great because it defeats part of the purpose of the SONAMEs, but perhaps
> that would have been the lesser evil?
>
> Versioned symbols in gnome-desktop3 would not help us here, because the
> GObject type system is a flat global namespace.
>
> If you would prefer to solve this by getting GNOME Shell 3.36.x
> into testing ASAP: it looks as though gnome-shell 3.36 is ready to
> migrate if gnome-shell-xrdesktop, gnome-shell-extension-dashtodock,
> gnome-shell-extension-easyscreencast are temporarily removed, and
> gnome-shell-extension-appindicator is aged by at least a day.

I've gone that route. If all goes well, gnome-shell/mutter should migrate in the
next britney run at 1600Z.

Cheers,
Emilio