Control: reopen -1
Control: found -1 2.1.7-3
fwupd (2.1.7-3) unstable; urgency=medium
.
* debian: move .gir files from libfwupd-dev to gir1.2-fwupd-2.0
(Closes: #1143623)
This is not the right solution to the bug reported as #1143623.
gir1.2-fwupd-2.0 is Multi-Arch: same, just like libfwupd-dev, so it's an
equally serious bug to be unable to co-install different architectures
of gir1.2-fwupd-2.0 (for example the :amd64 and :i386 or :s390x
versions of that package).
Moving the GIR XML to gir1.2-fwupd-2.0 also made gir1.2-fwupd-2.0
considerably larger, and gave it extra dependencies that are appropriate
for a -dev package but not for a runtime library package:
Depends: gir1.2-gio-2.0, gir1.2-gio-2.0-dev, gir1.2-gobject-2.0,
gir1.2-gobject-2.0-dev, libfwupd3 (>= 2.1.7)
^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^
The right solution to #1143623 would be one of these three:
1. (Probably the best short term fix)
Put the .gir files back in libfwupd-dev, but change the Debian packaging
so that they're installed to
/usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0 instead of /usr/share/gir-1.0,
similar to
https://salsa.debian.org/gstreamer-team/gstreamer1.0/-/merge_requests/25
in gstreamer1.0. This way, each architecture will load its own
architecture-specific version of the GIR XML. This is a
Debian-specific change: upstream libfwupd would still have to install
into /usr/share/gir-1.0 by default.
2. (Requires NEW queue)
Separate the .gir files into a new gir1.2-fwupd-2.0-dev binary
package. Either install them into
/usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0, or as a workaround, don't make
the new binary package Multi-Arch: same.
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).
Sorry to be bringing bad news,
smcv
