when building an image from a Dockerfile I see the following ``` ... (506/509): pcre2-syntax-10.42-2.fc40.noarch.rpm 3.9 MB/s | 143 kB 00:00 (507/509): pcre2-10.42-2.fc40.x86_64.rpm 5.4 MB/s | 233 kB 00:00 (508/509): sqlite-libs-3.44.2-1.fc40.x86_64.rpm 11 MB/s | 693 kB 00:00 (509/509): util-linux-core-2.39.3-2.fc40.x86_64 8.5 MB/s | 503 kB 00:00 -------------------------------------------------------------------------------- Total 21 MB/s | 618 MB 00:29 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/share/gir-1.0/GLib-2.0.gir conflicts between attempted installs of glib2-devel-2.79.0-5.fc40.i686 and glib2-devel-2.79.0-5.fc40.x86_64 Error: building at STEP "RUN dnf -y install --best --allowerasing binutils.i686 binutils.x86_64 boost-devel.i686 boost-devel.x86_64 boost.i686 boost.x86_64 cairo-devel.i686 cairo-devel.x86_64 cairo.i686 cairo.x86_64 clang.i686 clang-analyzer.noarch clang-tools-extra.i686 clang-tools-extra.x86_64 clang.x86_64 cmake.x86_64 compiler-rt.i686 compiler-rt.x86_64 cppcheck.x86_64 cpp.x86_64 curl.x86_64 diffutils.x86_64 fontconfig-devel.i686 fontconfig-devel.x86_64 fontconfig.i686 fontconfig.x86_64 freetype-devel.i686 freetype-devel.x86_64 freetype.i686 freetype.x86_64 fribidi-devel.i686 fribidi-devel.x86_64 fribidi.i686 fribidi.x86_64 gcc-c++.x86_64 gcc-gdb-plugin.x86_64 gcc.x86_64 gcovr-doc.noarch gcovr.noarch gdb-headless.x86_64 gdb.x86_64 gdk-pixbuf2-devel.i686 gdk-pixbuf2-devel.x86_64 gdk-pixbuf2.i686 gdk-pixbuf2-modules.i686 gdk-pixbuf2-modules.x86_64 gdk-pixbuf2.x86_64 gdk-pixbuf2-xlib.i686 gdk-pixbuf2-xlib.x86_64 git-core-doc.noarch git-core.x86_64 git.x86_64 glib2-devel.i686 glib2-devel.x86_64 glib2.i686 glib2.x86_64 glibc-devel.i686 glibc-devel.x86_64 glibc.i686 glibc.x86_64 gmp-c++.i686 gmp-c++.x86_64 gmp-devel.i686 gmp-devel.x86_64 gmp.i686 gmp.x86_64 google-noto-sans-cjk-fonts.noarch google-noto-sans-fonts.noarch google-roboto-condensed-fonts.noarch google-roboto-fonts.noarch harfbuzz-devel.i686 harfbuzz-devel.x86_64 harfbuzz.i686 harfbuzz-icu.i686 harfbuzz-icu.x86_64 harfbuzz.x86_64 libasan.i686 libasan.x86_64 libasan-static.i686 libasan-static.x86_64 liberation-fonts-common.noarch liberation-fonts.noarch liberation-mono-fonts.noarch liberation-sans-fonts.noarch liberation-serif-fonts.noarch liblsan.x86_64 liblsan-static.x86_64 libpng-devel.i686 libpng-devel.x86_64 libpng.i686 libpng.x86_64 libubsan.i686 libubsan.x86_64 libubsan-static.i686 libubsan-static.x86_64 llvm.i686 llvm.x86_64 make.x86_64 pango-devel.i686 pango-devel.x86_64 pango.i686 pango.x86_64 pkgconf.i686 pkgconf.x86_64 sqlite.x86_64 sqlite-devel.x86_64 sqlite-libs.i686 sqlite-libs.x86_64 valgrind.i686 valgrind.x86_64 which.x86_64 xorg-x11-server-Xvfb.x86_64 zlib-devel.i686 zlib-devel.x86_64 zlib.i686 zlib.x86_64 && uname -a": while running runtime: exit status 1 ``` FYI. A week before I had a working build with glib2-devel-2.78.3-1.fc40.i686 glib2-devel-2.78.3-1.fc40.x86_64 Regards Andre Reproducible: Always Steps to Reproduce: use the attached Dockerfile for building the image Actual Results: image doesn't get build. Expected Results: install the packages properly without conflicts and the image builds
Created attachment 2008888 [details] Dockerfile which triggers the described problem
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
This also prevents an upgrade to F40 on my laptop: Transaction failed: Rpm transaction failed. - file /usr/share/gir-1.0/GLib-2.0.gir conflicts between attempted installs of glib2-devel-2.79.1-1.fc40.i686 and glib2-devel-2.79.1-1.fc40.x86_64 We should get this resolved before people start upgrading to F40.
*** Bug 2271710 has been marked as a duplicate of this bug. ***
So what exactly is the difference between the i686 and x86_64 versions of the files? They're expected to be identical.
Created attachment 2026376 [details] diffoscope output for /usr/share/gir-1.0/GLib-2.0.gir
Created attachment 2026389 [details] diffoscope output for /usr/share/gir-1.0/GLib-2.0.gir
I have just encountered this problem with the later glib2 version, now that fc40 is properly out: Error: Transaction test error: file /usr/share/gir-1.0/GLib-2.0.gir from install of glib2-devel-2.80.0-1.fc40.i686 conflicts with file from package glib2-devel-2.80.0-1.fc40.x86_64 I have diff'ed the two gir files, most of it is uninteresting, and of the form: @@ -59,7 +59,7 @@ GPid is used in GLib only for descendant processes spawned with the g_spawn functions.</doc> - <source-position filename="glib/glibconfig.h" line="200"/> + <source-position filename="glib/glibconfig.h" line="201"/> <type name="gint" c:type="int"/> </alias> <alias name="Quark" c:type="GQuark"> They really should get-rid of that line number, if the two header differs by one line hear the top. But there is an interesting difference towards the end: @@ -53055,6 +53055,10 @@ </parameter> </parameters> </function-macro> + <constant name="VA_COPY_AS_ARRAY" value="1" c:type="G_VA_COPY_AS_ARRAY"> + <source-position filename="glib/glibconfig.h" line="124"/> + <type name="gint" c:type="gint"/> + </constant> <constant name="VERSION_MIN_REQUIRED" value="2" c:type="GLIB_VERSION_MIN_REQUIRED" that appears to be the source for the line number difference - somehow one version of the header has an extra constant define, on line 124.
*** Bug 2279957 has been marked as a duplicate of this bug. ***
OK, I think the next step here is an upstream bug report. We probably need to either (a) remove the integer formats from the introspection data, or else (b) define them in terms of standard macros like PRIu64. Can't decide that on a downstream issue tracker. Then we still need to figure out what's wrong with VA_COPY_AS_ARRAY in glibconfig.h....
This probably never worked, but you didn't notice because the gir files were previously in the gobject-introspection package rather than in the glib package. Upstream is suggesting building gobject-introspection with -Dgir-dir-prefix=/lib64 to force gobject-introspection to look for gir there. I'm reluctant to attempt this in F40 for fear of breaking something, but seems like a good solution for rawhide.
(In reply to Michael Catanzaro from comment #11) > Upstream is suggesting building gobject-introspection with > -Dgir-dir-prefix=/lib64 to force gobject-introspection to look for gir > there. I'm reluctant to attempt this in F40 for fear of breaking something, > but seems like a good solution for rawhide. Sorry, the suggestion is to build both gobject-introspection and GLib with this option. Also, do the same in any other packages that provide architecture-specific gir files. (Who knows how many packages this would entail. We'll just have to wait for further bug reports to come in, I suppose.) Let's try this in rawhide first. I don't know if we should backport to F40 or not. Probably not, because this is only a -devel package, so it shouldn't stop anybody from running i686 applications, only from building for i686. Hi Kalev, are you OK with this plan? It means a new directory /usr/lib64/gir-1.0
Actually it looks like that plan will not work, per Simon's comments in https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/323.
I re-built both glib2-devel.i686 and x86_64 by moving the gir and man files into a %package devel-common with BuildArch:noarch and I was able to install both without issues, and was able to compile 32-bit packages from there. I think I saw this solution in previous Fedora bug report on glib2 or something. Maybe that could be a solution.
Don't think so. The files need to be different for each architecture. Making them noarch is not a solution for that.
Running transaction Transaction failed: Rpm transaction failed. - file /usr/share/gir-1.0/GLib-2.0.gir from install of glib2-devel-2.82.2-1.fc41.i686 conflicts with file from package glib2-devel-2.82.2-1.fc41.x86_64 This is still an issue with F41. And looking at glib2-2.84.0-1.fc42 the same goes for F42. Any chance the Debian solution could be adopted for Fedora? See the following links: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/323 https://salsa.debian.org/gnome-team/gobject-introspection/-/tree/debian/latest/debian?ref_type=heads Reason for request: Upstream Wine 10.3+ builds wine.x86_64 + wine.i686 in a single build environment which requires both x86_64 and i686 dependencies to be installed at the same time. This is not possible because Wine requirement gstreamer1.x86_64 & gstreamer1.i686 can not be installed concurrently because of the glib2.x86_64/glib2.i686 /usr/share/gir-1.0/GLib-2.0.gir conflict. I'll be happy to test a scratch build, copr or patch. If you need more info please let me know. Thanks!
I'm afraid i686 issues are absolute bottom priority for me, so I won't spend time on this myself. * Ideally, somebody interested would tackle the issue upstream. * Downstream workarounds would be acceptable if relatively small and contained.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Still an issue in F42: Transaction failed: Rpm transaction failed. - file /usr/share/gir-1.0/GLib-2.0.gir from install of glib2-devel-2.84.2-1.fc42.i686 conflicts with file from package glib2-devel-2.84.2-1.fc42.x86_64
This message is a reminder that Fedora Linux 42 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '42'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 42 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Still an issue in F45(rawhide): Transaction failed: Rpm transaction failed. - file /usr/share/gir-1.0/GLib-2.0.gir conflicts between attempted installs of glib2-devel-2.88.1-1.fc45.i686 and glib2-devel-2.88.1-1.fc45.x86_64
Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27. Fedora Linux 42 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.