XPost: linux.debian.bugs.dist, linux.debian.devel.release 
 From: smcv@debian.org 
  
 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 
 > 
 > 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 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)