On Mon, 10 Aug 2026 at 15:25:26 +0200, Chris Hofstaedtler wrote:
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.
(I could be wrong about the specifics here, I don't actually know how
libfwupd works internally - it seems to involve Rust code-generation,
and that isn't a language that I know.)
... 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.
Presumably it'll be some combination of historical reasons, not wanting
to break existing code, wanting to provide language bindings for the 99%
that is usable even if a minority of it is unusable, or bugs,
potentially unfixable ones.
If GObject-Introspection is getting this information from the GType
system, then the top 32 bits have probably been lost altogether by the
time GObject-Introspection sees it, so GObject-Introspection likely
doesn't have the opportunity to know that there was a problem. The 0/-1
difference between architectures could indicate that out-of-range values
are being truncated differently, or stuffed into a `long`-sized field
and read back differently, or something?
Or if GObject-Introspection is getting this information from the C
source code, it could be making assumptions about "normal" enums/flags
that are not easily checkable. Parsing the C source to get enum/flags
values in a fully correct way is unlikely to be feasible without a
complete implementation of the C preprocessor and half of the compiler,
which is not something that's realistically available. But if an
enum/flags value can't be parsed, detecting that situation and refusing
it is just going to make existing software FTBFS, which would certainly
detect problems but would presumably be considered an unacceptable
regression (leading to the improved version of GObject-Introspection
being rejected from inclusion in Debian until all reverse-dependencies
have been made compatible with it, which could require them breaking
API/ABI). So I'm not sure that this really helps us.
If programs that use libfwupd via language bindings happen to not use
these particular constants (which I suspect to be the case in practice,
otherwise they wouldn't work) then those programs could still work. I
know this is not an ideal situation, but imperfect software exists and
is sometimes a necessary part of our OS distribution.
For the GType code path, GLib could probably arrange for some
G_STATIC_ASSERT() to be added to the generated GType registrations, to
make it refuse to register enums/flags types that can't interoperate
with GType/GValue due to being larger than int; but if it did that, that
would just make existing software like libfwupd FTBFS until it breaks
ABI, which again would certainly detect problems but would presumably be
considered an unacceptable regression. So, again, I'm not sure that
really helps us. The least-disruptive way to do this would probably be
to gate it on a minimum GLIB_VERSION_MAX_ALLOWED. If someone wants to
work on that, the place to discuss it would be with GLib upstream,
<https://gitlab.gnome.org/GNOME/glib/>.
I'm aware that the ecosystem is not perfect, and I'm sorry.
Unfortunately, making myself feel more guilty doesn't provide more hours
in a day, and I'm already responsible for more topics than I can meet
community expectations for, so I have to say that some things are
outside my scope.
smcv
