Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition
On 2021-09-25 14:55:23 +0100, Simon McVittie wrote: > On Sat, 25 Sep 2021 at 15:01:46 +0200, Sebastian Ramacher wrote: > > Regardless of future transitions of libffi, if glib and the > > introspection ecosystems are closely tied to the the libffi ABI, the > > affected packages need to express that with the proper dependencies. > > It's not that they are closely tied to any specific libffi ABI - to the > best of my knowledge, they're all fine with any reasonable version of > libffi, old or new. The problem is that gobject-introspection and all > users of girffi.h[1] (gjs, pygobject, etc.) all need to be using the > *same* libffi, because girffi.h has functions that return pointers to ffi > types or take pointers to ffi types as parameters. Sorry, that's not what I meant. they are tightly coupled in the sense that the whole gobject-introspection ecosystem needs to use the same libffi version. It's the same as boost and icu where also icu's ABI leaks into boost's ABI (via some icu structs that are passed around). Hence everything that uses Boost.Regex needs also be tracked in icu transitions. To track that, libboost-regexX provides libboost-regexX-icuY and reverse dependencies have dependencies on libboost-regexX-icuY. For libgirepository1.0-1 that would mean that libgirepository1.0-1 provides libgirepository1.0-1-ffiX and symbols from girffi that depend on the specific libffi ABI then declare in the symbols files that dependencies on libgirepository1.0-1-ffiX need to be generated. Cheers > > I don't know whether it is important that glib2.0 and gobject-introspection > are *also* using the same libffi; in the past we assumed that they should, > but it is probably not critical. > > [1] https://codesearch.debian.net/search?q=girffi.h=1 > > smcv -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition
On Sat, 25 Sep 2021 at 15:01:46 +0200, Sebastian Ramacher wrote: > Regardless of future transitions of libffi, if glib and the > introspection ecosystems are closely tied to the the libffi ABI, the > affected packages need to express that with the proper dependencies. It's not that they are closely tied to any specific libffi ABI - to the best of my knowledge, they're all fine with any reasonable version of libffi, old or new. The problem is that gobject-introspection and all users of girffi.h[1] (gjs, pygobject, etc.) all need to be using the *same* libffi, because girffi.h has functions that return pointers to ffi types or take pointers to ffi types as parameters. I don't know whether it is important that glib2.0 and gobject-introspection are *also* using the same libffi; in the past we assumed that they should, but it is probably not critical. [1] https://codesearch.debian.net/search?q=girffi.h=1 smcv
Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition
On 2021-09-25 11:49:39 +0100, Simon McVittie wrote: > Control: retitle 995032 GNOME components segfault as a result of libffi > transition > > On Sat, 25 Sep 2021 at 03:48:20 -0400, Jeremy Bicha wrote: > > On Sat, Sep 25, 2021 at 12:30 AM Michael Ott wrote: > > > The problem is not gnome-shell. It is the gobject-introspection. > > > After downgrade this packages from 1.70.0-1+b1 to 1.70.0-1 it works > > > again. > > > > gobject-introspection was rebuilt as part of the libffi transition. > > (That's where the +b1 part of the version name comes from.) The > > transition is still in progress. Maybe the problem is that you didn't > > have the rebuilt gjs installed? > > > > The rebuilt gjs is version 1.68.4-1+b1 > > > > Here's the list of other packages involved in the transition: > > https://release.debian.org/transitions/html/auto-libffi.html > > Last time we had a libffi transition, in early 2020, we ended up > sprinkling versioned Breaks throughout GNOME to force the whole system > to be either "old libffi" or "new libffi". This is because some GNOME > components, notably gobject-introspection, have libffi data structures > in their public API, so in partial upgrades we get one library passing an > old-libffi data structure to another library that expects a new-libffi > data structure, and crashes. > > See the gobject-introspection 1.62.0-4 and -5 changelogs for part of what > we had to do to fix this. > > If libffi is going to continue to break ABI somewhat regularly, then I > think we are going to need a more systematic way to prevent broken partial > upgrades, and it would be very helpful for the libffi maintainer and the > release team to keep this failure mode in mind when allocating transition > slots (for example doing libffi transitions when there is not a new major > version of GLib trying to migrate, as there is at the moment). Regardless of future transitions of libffi, if glib and the introspection ecosystems are closely tied to the the libffi ABI, the affected packages need to express that with the proper dependencies. We have the same situation with boost and icu and boost and python3.X. If you implement a similar solution to that in boost, this would also allows us to track this via ben in a future libffi transition. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#994560: Bug#995032: GNOME components segfault as a result of libffi transition
Control: retitle 995032 GNOME components segfault as a result of libffi transition On Sat, 25 Sep 2021 at 03:48:20 -0400, Jeremy Bicha wrote: > On Sat, Sep 25, 2021 at 12:30 AM Michael Ott wrote: > > The problem is not gnome-shell. It is the gobject-introspection. > > After downgrade this packages from 1.70.0-1+b1 to 1.70.0-1 it works > > again. > > gobject-introspection was rebuilt as part of the libffi transition. > (That's where the +b1 part of the version name comes from.) The > transition is still in progress. Maybe the problem is that you didn't > have the rebuilt gjs installed? > > The rebuilt gjs is version 1.68.4-1+b1 > > Here's the list of other packages involved in the transition: > https://release.debian.org/transitions/html/auto-libffi.html Last time we had a libffi transition, in early 2020, we ended up sprinkling versioned Breaks throughout GNOME to force the whole system to be either "old libffi" or "new libffi". This is because some GNOME components, notably gobject-introspection, have libffi data structures in their public API, so in partial upgrades we get one library passing an old-libffi data structure to another library that expects a new-libffi data structure, and crashes. See the gobject-introspection 1.62.0-4 and -5 changelogs for part of what we had to do to fix this. If libffi is going to continue to break ABI somewhat regularly, then I think we are going to need a more systematic way to prevent broken partial upgrades, and it would be very helpful for the libffi maintainer and the release team to keep this failure mode in mind when allocating transition slots (for example doing libffi transitions when there is not a new major version of GLib trying to migrate, as there is at the moment). smcv
