Hi Simon, clearly I have no idea about gobject-introspection, and I'm not into this bug per se, but I was wondering...
On Mon, Aug 10, 2026 at 01:21:58PM +0100, Simon McVittie wrote: > 3. (Longer term) Fix whatever upstream issue is causing the header files > to be mis-parsed by GObject-Introspection, so that Fwupd-2.0.gir is > the same on every architecture. Looking at the diff between amd64 and > i386, it seems like the various enums are not being introspected > correctly, with constants showing up as having value -1 on amd64 > but 0 on i386, where their real value is G_MAXUINT64: > > --- gir1.2-fwupd-2.0_2.1.7-3_amd64/usr/share/gir-1.0/Fwupd-2.0.gir > 2026-08-09 23:35:51.000000000 +0100 > +++ gir1.2-fwupd-2.0_2.1.7-3_i386/usr/share/gir-1.0/Fwupd-2.0.gir > 2026-08-09 23:35:51.000000000 +0100 > @@ -14168,7 +14168,7 @@ > line="270">The device doesn't require verification of the > newly installed version.</doc> > </member> > <member name="unknown" > - value="-1" > + value="0" > c:identifier="FWUPD_DEVICE_FLAG_UNKNOWN"> > <doc xml:space="preserve" > filename="libfwupd/fwupd-device-struct.h" > > It looks like libfwupd is doing things that are not compatible with > the assumption made by GLib's GType system: it's setting the UNKNOWN > value for various enums to G_MAXUINT64, but the GFlagsValue data > structure represents members of a set of flags as guint (an alias for > unsigned int, 32 bits on all Debian platforms), so this is simply not > representable in the GType system. If you want these sets of flags to > be representable by the GType system and usable by GObject-Introspection > languages, then they will need to be limited to 32 bits wide (which would > be an ABI break). ... should gobject-introspection fail on such things? It seems to me that such a type violation would be a hard fail in other language ecosystems. Silently producing different results on different archs for something that is not representable in the first place, sounds, excuse me, bad? So - maybe this is all correct and I just lack context/understanding of why. If this is the case, please feel free to disregard my email. Best, Chris
