Bug#1115340: transition: glib2.0 2.86

[Simon McVittie]

Control: tags -1 - moreinfo

I think this sort-of-transition is at a point where we can go ahead 
whenever the release team are ready for it. A GNOME team member will 
need to:

- upload experimental's glib2.0 to unstable, starting the transition

- either re-upload unstable's gnome-shell with a Build-Depends on the new
   glib2.0, or ask the release team to binNMU unstable's gnome-shell with
   a Dep-Wait on the new glib2.0
   (the former is probably easier since it means one person can do all
   of these uploads as a batch without immediately needing release-team help)

- upload experimental's gnome-menus to unstable, possibly with a
   Build-Depends on the new glib2.0 to force the desired build order

And then we wait for this batch to migrate before doing any other big 
GNOME changes (#1116394). The release team might have to remove glib-d 
and potentially appstream-generator from testing to let the migration go 
through, but I don't think that will necessarily be needed since their 
incompatibility with the new glib2.0 is only at build-time.

On Thu, 18 Sep 2025 at 18:23:04 +0100, Simon McVittie wrote:
>On Mon, 15 Sep 2025 at 20:01:00 +0100, Simon McVittie wrote:
>>glib2.0 (>= 2.86) in experimental has a couple of issues that need
>>resolving before it can be uploaded to unstable
>
>>* awesome

Fixed in testing

>>* cinnamon

Fixed in testing

>>* gjs

Fixed in testing

>>* pygobject

Fixed in testing

>>* gnome-shell

Fixed in testing, but as discussed earlier will need either a binNMU or 
a sourceful upload.

Marco also found a regression in gnome-menus. It is fixed in 
experimental, and will need uploading to unstable when we are ready to 
go ahead. I'm not sure whether this strictly needs a coordinated upload 
with the new GLib or not, but in any case it should be easy for a GNOME 
team member to do a batch of uploads together.

>>* glib-d #1115332
>
><https://bugs.debian.org/1115352> is a build-time issue (FTBFS) so it 
>won't immediately break end-user systems. If glib-d is removed from 
>testing, the only collateral damage will be appstream-generator.

Not fixed. The new appstream-generator in unstable no longer uses glib-d, 
which makes glib-d a leaf package that could definitely be removed from 
testing; but the new appstream-generator requires inja which is in the 
NEW queue, so it's differently RC-buggy right now.

     smcv