libfwupd-dev is declared Multi-Arch: same, but fails to coinstall.

The file /usr/share/gir-1.0/Fwupd-2.0.gir is shared by libfwupd-dev
version 2.1.7-2 as present in forky|unstable with varying content.

Please ensure that shared files have bit-identical content across
architectures, move architecture-dependent files to
architecture-dependent paths or remove the Multi-Arch: same field.

Kind regards

Helmut Grohne

We believe that the bug you reported is fixed in the latest version of
fwupd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1143623@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mario Limonciello <superm1@debian.org> (supplier of updated fwupd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 09 Aug 2026 17:35:51 -0500
Source: fwupd
Built-For-Profiles: derivative.ubuntu noudeb
Architecture: source
Version: 2.1.7-3
Distribution: unstable
Urgency: medium
Maintainer: Debian EFI <debian-efi@lists.debian.org>
Changed-By: Mario Limonciello <superm1@debian.org>
Closes: 1143623
Changes:
 fwupd (2.1.7-3) unstable; urgency=medium
 .
   * debian: move .gir files from libfwupd-dev to gir1.2-fwupd-2.0
     (Closes: #1143623)
Checksums-Sha1:
 7bfd220c5ff111476817675af07ac50b70174b22 3557 fwupd_2.1.7-3.dsc
 6120164cc625bbbb581ac4a470372fc258c41e4c 30584 fwupd_2.1.7-3.debian.tar.xz
 3fccfb83be35c52275d1081952e8cc3ada1fda70 17712 fwupd_2.1.7-3_source.buildinfo
Checksums-Sha256:
 4228bfe655d6a19d861a9b56ed9e1ecdbb4ec810df9c3c9952154645b3dafb43 3557 fwupd_2.1.7-3.dsc
 c51fd2d94fd8b0c407cd52a75eaef061fce5c54e997dcbfa37fa8e9dca06d472 30584 fwupd_2.1.7-3.debian.tar.xz
 b6aeab49c4ef0b8c46bcefe5a2937b16e4b80219e51050df2687dde3a5830fd4 17712 fwupd_2.1.7-3_source.buildinfo
Files:
 328f3641d2394dca8d6911ef1666a45a 3557 admin optional fwupd_2.1.7-3.dsc
 757ce0c0b3c6b9c9fb91e0dfe4477e68 30584 admin optional fwupd_2.1.7-3.debian.tar.xz
 bc5958f7c39c7a9bd526771f98d5b709 17712 admin optional fwupd_2.1.7-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEECwtuSU6dXvs5GA2aLRkspiR3AnYFAmp5BUQTHHN1cGVybTFA
ZGViaWFuLm9yZwAKCRAtGSymJHcCdjZ7EADBeyVtdF82TdVtSVFvQpN2vLo3J7F8
OiHRMyok4EC4KdSO1Flqb3hlvSlWV47ecbYNNhTc69b3FdNt2JJsDXdFhOzbwIp+
UIWiSYOVBI5x4FTCKqsj+Vj1e/5tbY6H9xAX2X4UsU5T5B+qp4XKMiJyGzOddPXY
g+GCLXLFDHHA/S7neskT61cwwQQoU2uSubpjHHdSZxvvpo4ikdwMmljj9FYgHxZ4
jUMsnX9GQcr5URPDkdA+QDj8AknnqQUU892FMR/ylTCy1pKXZXgWR/NgqyvfZ/ad
csZx4FbdMKwnFLAWziQ+kEqxM7Qt3lxWHXmD/a3kg8SB/zkhRR/O3Q/zMlTIzxhT
egNcSrJZeyAIAhwYp+rkktNFmjCYOI5esSymV4sJXNHv5iJ0zyEcz4Yglza7smm+
pihxlyXYCF33z+DIXwVhz6peKSIaFnvums779embLP5DCODNbjwbM1pIY9xFB6pj
RStIpBmDgtPB3n5OXxAY3hcDGzNnghZhMXKzYLo3ILXWrcSM2OMxaMZa/MfYpgrX
cZvqIfaZqHJtWS1ftXPak7NtEq2lJGB3g0qkU1uxgcsSEjxhNECl1SaDCJw/KBbJ
mwmet7mTtwTowqH7Ow7cYr2/Kdg/k/FHi3VRruoP5KDvk35t0iW+ul4FlkUh2ArO
Fprlb1/JY/hfWw==
=5y4S
-----END PGP SIGNATURE-----

Control: reopen -1
Control: found -1 2.1.7-3

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:

Hi Simon,

clearly I have no idea about gobject-introspection, and I'm not into
this bug per se, but I was wondering...

... 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

(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.)

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

We believe that the bug you reported is fixed in the latest version of
fwupd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1143623@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mario Limonciello <superm1@debian.org> (supplier of updated fwupd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 10 Aug 2026 21:27:10 -0500
Source: fwupd
Built-For-Profiles: derivative.ubuntu noudeb
Architecture: source
Version: 2.1.7-4
Distribution: unstable
Urgency: medium
Maintainer: Debian EFI <debian-efi@lists.debian.org>
Changed-By: Mario Limonciello <superm1@debian.org>
Closes: 1143623
Changes:
 fwupd (2.1.7-4) unstable; urgency=medium
 .
   * Revert "debian: move .gir files from libfwupd-dev to gir1.2-fwupd-2.0"
   * Move .gir files from /usr/share/gir-1.0 to multiarch path in
     libfwupd-dev so each architecture loads its own copy (Closes: #1143623)
Checksums-Sha1:
 f41fb9921982b3844e5532bcd42769302d217eb2 3557 fwupd_2.1.7-4.dsc
 9a4d9b5d4fc0171ab695371e3900e01eb3acae07 30736 fwupd_2.1.7-4.debian.tar.xz
 a06c4b16797490b7ad9a0e8d763969603118b176 17712 fwupd_2.1.7-4_source.buildinfo
Checksums-Sha256:
 ddf44e29c050c77a7317c0b1fb41a8410e125a9de815251651d0265971c02b29 3557 fwupd_2.1.7-4.dsc
 bd84170f3be76dfc02cbe8442dba6ab83326d4292247e19ec173c5d062a3b709 30736 fwupd_2.1.7-4.debian.tar.xz
 f6c777a03950bb9b279c4dbecf08d2587b3894c70f9d4771bdd0dde07a529b15 17712 fwupd_2.1.7-4_source.buildinfo
Files:
 8a98468b14c6ab9794d7e95b47650e5a 3557 admin optional fwupd_2.1.7-4.dsc
 6da9cdfe7f0f944a0e905e69b7955e46 30736 admin optional fwupd_2.1.7-4.debian.tar.xz
 3b156849a8e831971199cdc812ed6ac3 17712 admin optional fwupd_2.1.7-4_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEECwtuSU6dXvs5GA2aLRkspiR3AnYFAmp6mmITHHN1cGVybTFA
ZGViaWFuLm9yZwAKCRAtGSymJHcCdsqhD/9SVoczTQGlO9aQ/AGnsgRzFtegcxaE
iRTW1vf7VlqH0xvCT+fCw8UTfQ7mVBBw6699SWYK81kffpCg1AYJHAX6GPSS/SZs
QG+fVTptgOfeFQXbRSzcLJlCkdNqIDY2rq5UyOIZcnDVWdbtxNdJVaXEMtE28k/X
sfHmzYJhZzOezsOunzCdCNmO6W92b6ObBGbcJKJbT+2j61/SBqSm0pCUbIITLhzK
9fc9nbxEgZz/zS+DAIDcFjyiln184FhW+Gd2ILQ1pBM8PPq1B3goUmjInnytqeFk
JXWSp1Zj4Z3iPlrzVav7Ndzd6dHTdE4KUSLghZfj2a9SNafip+mF3u3aGGXS2/nS
nDzGjCA9S+llSJRLh6+XKa4TSJg5V8KdRm1+werG4nwCjfvrmUltImrgsFSTHMHp
Q5H/El0qAVG7jtpgm4EX+qkHYAUgafbj4lG60lgUUO6JG77niQlNWH5d9kVBxNiw
g9hc5UCdSkfRdY8LWizzrPRAyn4TIdJir6ga2pBtNvxff2Vtt0Z072XGZMy7ZDZ5
0fGymD1++B7uaJRBIsFGV8OgG+Im7h5VXCLraRnKnGYLSgKNiACP/V+tldSTyszA
UBjbIgugWD8AofAUWBp/0AjePp9XxCcNWqkygHZraLHfhys5S0TQHObCSL0N4tof
PWS8wx6qZDljQw==
=vYpa
-----END PGP SIGNATURE-----