Bug#954422: transition: GNOME 3.36
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
Bug#954422: transition: GNOME 3.36
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
Bug#954422: transition: GNOME 3.36
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
Bug#954422: transition: GNOME 3.36
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
Bug#954422: transition: GNOME 3.36
budgie-desktop has now been transitioned to unstable. thx David On Sat, 11 Apr 2020 at 13:42, Simon McVittie wrote: > > 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
Bug#954422: transition: GNOME 3.36
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
Bug#954422: transition: GNOME 3.36
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
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 signature.asc Description: PGP signature
Bug#954422: transition: GNOME 3.36
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
Bug#954422: transition: GNOME 3.36
On 21/03/2020 13:17, Simon McVittie wrote: > Package: release.debian.org > Severity: normal > Tags: moreinfo > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org > > You've probably seen that parts of GNOME 3.36 (libraries with stable > API/ABI, and leaf applications) are starting to make their way into > unstable, with the rest of GNOME 3.36 staged in experimental. This will > come with the usual libgnome-desktop and mutter transitions: > > https://release.debian.org/transitions/html/auto-gnome-desktop3.html > https://release.debian.org/transitions/html/auto-mutter.html > > 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. Sure. > I've marked this as moreinfo because the gjs/mutter/gnome-shell part > definitely cannot go ahead until mozjs68 has got through NEW. At the moment > their source code is in experimental, but is not buildable. Alright. Let us know when that is sorted out and we'll look for a transition slot. Cheers, Emilio
Bug#954422: transition: GNOME 3.36
Package: release.debian.org Severity: normal Tags: moreinfo User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org You've probably seen that parts of GNOME 3.36 (libraries with stable API/ABI, and leaf applications) are starting to make their way into unstable, with the rest of GNOME 3.36 staged in experimental. This will come with the usual libgnome-desktop and mutter transitions: https://release.debian.org/transitions/html/auto-gnome-desktop3.html https://release.debian.org/transitions/html/auto-mutter.html 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. I've marked this as moreinfo because the gjs/mutter/gnome-shell part definitely cannot go ahead until mozjs68 has got through NEW. At the moment their source code is in experimental, but is not buildable. This transition is already happening (has already happened?) in Ubuntu. title = "GNOME 3.36"; is_affected = .depends ~ "libgnome-desktop-3-18" | .depends ~ "gir1.2-mutter-5" | .depends ~ "libmutter-5-0" | .depends ~ "libmutter-5-dev" | .depends ~ "libgnome-desktop-3-19" | .depends ~ "gir1.2-mutter-6" | .depends ~ "libmutter-6-0" | .depends ~ "libmutter-6-dev"; is_good = .depends ~ "libgnome-desktop-3-19" | .depends ~ "gir1.2-mutter-6" | .depends ~ "libmutter-6-0" | .depends ~ "libmutter-6-dev"; is_bad = .depends ~ "libgnome-desktop-3-18" | .depends ~ "gir1.2-mutter-5" | .depends ~ "libmutter-5-0" | .depends ~ "libmutter-5-dev"; smcv
