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

Bug#1115340: transition: glib2.0 2.86



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


Reply to: