XPost: linux.debian.bugs.dist, linux.debian.devel.release 
 From: smcv@debian.org 
  
 Package: release.debian.org 
 Severity: normal 
 Tags: moreinfo 
 X-Debbugs-Cc: glib2.0@packages.debian.org, debian-gtk-gnome@lists.debian.org 
 Control: affects -1 + src:glib2.0 
 User: release.debian.org@packages.debian.org 
 Usertags: transition 
 Control: block -1 by 1115332 
  
 glib2.0 (>= 2.86) in experimental has a couple of issues that need 
 resolving before it can be uploaded to unstable, so I'm opening this 
 transition-tracking bug to coordinate what still needs to be done before 
 we can have GLib 2.86 in unstable/testing. I don't think we're ready to 
 go ahead with this yet, hence marked moreinfo. Unfortunately there is no 
 straightforward fact about the affected packages that can be used to 
 create a transition tracker. 
  
 The main issue is GObject-Introspection. The new GLib has not broken its 
 C API/ABI, but it includes an introspection API break which affects 
 language bindings: 
  
 * in bookworm, Unix-specific parts of libglib and libgio were part of 
   the GLib-2.0.{gir,typelib} and Gio-2.0.{gir,typelib} introspection 
   modules 
  
 * in trixie (specifically GLib 2.80 and up), the Unix-specific parts were 
   duplicated into GLibUnix-2.0 and GioUnix-2.0; the idea was that the 
   duplicates in GLib-2.0 and Gio-2.0 could be deprecated but remain for 
   compatibility 
  
 * but the duplication, itself, turned out to cause problems for the 
   GObject-Introspection machinery 
  
 * now, in 2.86, the Unix-specific parts have been removed from GLib-2.0 
   and Gio-2.0, and language bindings need to adjust to that 
  
 Windows-specific parts have followed the same path, but obviously we 
 never had those in Debian. 
  
 The route that upstream is mainly using to handle this is teaching 
 language bindings to behave as if the OS-specific parts were still 
 present in GLib-2.0 and Gio-2.0, but automatically look them up in 
 GLibUnix-2.0 and GioUnix-2.0, with appropriate deprecation warnings - in 
 practice it seems that the language bindings are better-placed to do 
 this than GObject-Introspection itself. 
  
 Because GLibUnix-2.0 and GioUnix-2.0 already exist, many of the affected 
 packages can be fixed immediately, even before we are ready to migrate 
 glib2.0. 
  
 Packages known to be affected: 
  
 * awesome: fixed upstream, the change is not yet in Debian or Ubuntu 
 * cinnamon: fixed in 6.4.12-1, currently in unstable, should migrate in 
   a few days; might need a rebuild (binNMU or no-changes sourceful upload) 
   when the new GLib is available, I'm unsure on this particular point 
 * cjs: fixed in Ubuntu (128.0-1ubuntu1) 
 * gjs: fixed in experimental but that's probably for a later transition; 
   in the meantime there are patches that could be backported (the same ones 
   used in cjs 128.0-1ubuntu1) 
 * glib-d #1115332 
 * gnome-shell: fixed in experimental but that's a later transition; 
   there are patches that could be backported, but it will also need a 
   sourceful upload with a build-dependency on the new GLib if I 
   understand correctly 
 * pygobject: fixed in 3.50.0-6, currently in unstable, should migrate soon 
  
 For the packages that are affected at runtime, glib2.0 has been gaining 
 versioned Breaks to make sure they all migrate together. 
  
 We're probably at a point where it would be useful to report bugs in the 
 remaining known-affected packages (perhaps excluding cinnamon and 
 pygobject whose fixes will migrate soon anyway) and make them block this 
 one. 
  
 Additionally there was an autopkgtest regression in lua-lgi, not 
 directly unrelated to the GLibUnix/GioUnix thing, but this has been 
 avoided by a change in glib2.0. 
  
 There might also be regressions seen in other dynamic bindings: 
 libglib-object-introspection-perl, lua-lgi, and the ruby-gir-ffi family. 
 These are only used for individual apps, therefore less critical than 
 cjs/gjs/pygobject which are used for whole desktop environments. 
  
 And there might be regressions in apps that use static bindings (Rust, 
 Haskell, Go, etc.) which would manifest as FTBFS - most likely as FTBFS 
 in the leaf packages that use them, I think? 
  
 See also previous discussion on 
  and 
 . 
  
     smcv 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)