This behaves as designed. glibc32 package is meant to be used only in the buildroots which are *not* multilib, but they still require multilib glibc32. Please do not use buildroot repos for anything else than building packages.
Could you try your test on Fedora 34 or Fedora rawhide? I have recently added an RPM package conflict there which should paper over this issue. Daniel is right that this is expected, but at the same time people are forced to use buildroots instead of real composes in their gating tests. There is an on-demand compose service (ODCS), but presumably creating a compose with every gated package individually is too costly.
Here's the RpmDiff between the two systemtap versions: ---------------------------------------------------------------------- https://rpmdiff.engineering.redhat.com/run/493710/20/ Here's what does the systemtap specfile contain: ---------------------------------------------------------------------- %ifarch x86_64 %if 0%{?rhel} >= 8 || 0%{?fedora} >= 20 # fweimer, personal correspondence Recommends: glibc-devel(x86-32) %else Requires: /usr/lib/libc.so %endif # ... and /usr/lib/libgcc_s.so.* # ... and /usr/lib/libstdc++.so.* %endif glibc32 provides glibc32(x86-64) ---------------------------------------------------------------------- # rpm -q --provides glibc32 | fgrep x86 glibc32(x86-64) = 2.32-1.3.fc35 I've created a rhel build of glibc32 having the Conflicts: update from Fedora https://src.fedoraproject.org/rpms/glibc32/c/ea8e21c91f5f0fc6fa02660b4d2720d3c266a41d?branch=rawhide : https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=36745726 The dnf transaction problem goes away. What happens is that glibc32 stays installed, and since glibc-devel(x86-32) is a soft requirement only, it will not install. That means that the -m32 systemtap testsuite tests will run against glibc32 coming from year 2018. But maybe that's good enough, because a clean installation of the new systemtap testsuite will not pull glibc32 in and instead should install glibc-devel.i686. The systemtap-testsuite is a Buildroot repo material, so it won't hit customers anyway. This is just a CI automation problem.
Florian, would it make sense to add the Conflicts: bit to the rhel glibc32 build?
(In reply to Martin Cermak from comment #4) > The dnf transaction problem goes away. What happens is that glibc32 stays > installed, and since glibc-devel(x86-32) is a soft requirement only, it will > not install. Would you please elaborate on the “stays installed” part? Do you mean that glibc32 is automatically installed, and glibc.i686 is not? Maybe this is enough in systemtap-testsuite to get dnf to choose a different solution? Recommends: glibc(x86-32) Recommends: glibc-devel(x86-32) I can add the conflict to glibc32 if I can get qa_ack+/release+. I'd be willing to do that just facilitate further testing. We'll need buildroot tagging from RHEL SP/EXD though (no erratum attachment).
(In reply to Florian Weimer from comment #6) > Would you please elaborate on the “stays installed” part? Do you mean that > glibc32 is automatically installed, and glibc.i686 is not? Exactly. This is what I ended up with after the systemtap update: 8.5 Server x86_64 # rpm -qa | fgrep -e systemtap -e glibc | sort glibc-2.28-158.el8.x86_64 glibc32-2.28-2mcermak.1.el8.x86_64 glibc-common-2.28-158.el8.x86_64 glibc-devel-2.28-158.el8.x86_64 glibc-headers-2.28-158.el8.x86_64 glibc-langpack-en-2.28-158.el8.x86_64 systemtap-4.5-1.el8.x86_64 systemtap-client-4.5-1.el8.x86_64 systemtap-devel-4.5-1.el8.x86_64 systemtap-runtime-4.5-1.el8.x86_64 systemtap-runtime-java-4.5-1.el8.x86_64 systemtap-runtime-python3-4.5-1.el8.x86_64 systemtap-sdt-devel-4.5-1.el8.x86_64 systemtap-server-4.5-1.el8.x86_64 systemtap-testsuite-4.5-1.el8.x86_64 8.5 Server x86_64 # > > Maybe this is enough in systemtap-testsuite to get dnf to choose a different > solution? > > Recommends: glibc(x86-32) > Recommends: glibc-devel(x86-32) > > I can add the conflict to glibc32 if I can get qa_ack+/release+. I'd be > willing to do that just facilitate further testing. We'll need buildroot > tagging from RHEL SP/EXD though (no erratum attachment). Or maybe systemtap-testsuite could (also) Conflict with glibc32 (?)
(In reply to Martin Cermak from comment #7) > > I can add the conflict to glibc32 if I can get qa_ack+/release+. I'd be > > willing to do that just facilitate further testing. We'll need buildroot > > tagging from RHEL SP/EXD though (no erratum attachment). > > Or maybe systemtap-testsuite could (also) Conflict with glibc32 (?) I think the requirement is that systemtap-testsuite.x86_64 can be installed just using the x86_64 buildroot, and uses glibc32 there because glibc.i686 is not available. We can add the Conflicts: to glibc32 using this bug (I don't think there's a glibc32 component).
(In reply to Florian Weimer from comment #8) > (In reply to Martin Cermak from comment #7) > > Or maybe systemtap-testsuite could (also) Conflict with glibc32 (?) > > I think the requirement is that systemtap-testsuite.x86_64 can be installed > just using the x86_64 buildroot, and uses glibc32 there because glibc.i686 > is not available. It is available. But the depsolver just leaves glic32 installed and skips glibc-devel.i686 installation: 8.5 Server x86_64 # repoquery -q --location glibc.i686 glibc-devel.i686 http://download-node-02.eng.bos.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.5.0/compose/BaseOS/x86_64/os/Packages/glibc-2.28-158.el8.i686.rpm http://download-node-02.eng.bos.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.5.0/compose/BaseOS/x86_64/os/Packages/glibc-devel-2.28-158.el8.i686.rpm http://download.eng.rdu2.redhat.com/rhel-8/nightly/RHEL-8/RHEL-8.5.0-20210504.n.0/compose/BaseOS/x86_64/os/Packages/glibc-2.28-158.el8.i686.rpm http://download.eng.rdu2.redhat.com/rhel-8/nightly/RHEL-8/RHEL-8.5.0-20210504.n.0/compose/BaseOS/x86_64/os/Packages/glibc-devel-2.28-158.el8.i686.rpm 8.5 Server x86_64 # > > We can add the Conflicts: to glibc32 using this bug (I don't think there's a > glibc32 component). Thanks.
Requested tagging this build into the buildroot: https://projects.engineering.redhat.com/browse/RHELBLD-6107
(In reply to Martin Cermak from comment #13) > (In reply to Florian Weimer from comment #12) > > I think it's sufficient to verify that the conflict has the intended effect, > > and that gcc still builds (scratch build is fine; I can do that too). > Thanks, I'll take care of that. Attempting a GCC build: $ rhpkg request-side-tag --base-tag rhel-8.5.0-build Side tag 'rhel-8.5.0-build-side-82991' (id 82991) created. Use 'rhpkg build --target=rhel-8.5.0-build-side-82991' to use it. Use 'brew wait-repo rhel-8.5.0-build-side-82991' to wait for the build repo to be generated. $ brew tag rhel-8.5.0-build-side-82991 glibc32-2.28-1.2.el8 Created task 37156572 Watching tasks (this may be safely interrupted)... 37156572 tagBuild (noarch): free 37156572 tagBuild (noarch): free -> open (x86-031.build.eng.bos.redhat.com) 37156572 tagBuild (noarch): open (x86-031.build.eng.bos.redhat.com) -> closed 0 free 0 open 1 done 0 failed 37156572 tagBuild (noarch) completed successfully $ brew wait-repo --build glibc32-2.28-1.2.el8 rhel-8.5.0-build-side-82991 Successfully waited 18:27 for glibc32-2.28-1.2.el8 to appear in the rhel-8.5.0-build-side-82991 repo $ $ rhpkg build --scratch --target=rhel-8.5.0-build-side-82991 warning: line 249: It's not recommended to have unversioned Obsoletes: Obsoletes: libcilkrts warning: line 250: It's not recommended to have unversioned Obsoletes: Obsoletes: libcilkrts-static warning: line 335: It's not recommended to have unversioned Obsoletes: Obsoletes: libmudflap warning: line 336: It's not recommended to have unversioned Obsoletes: Obsoletes: libmudflap-devel warning: line 337: It's not recommended to have unversioned Obsoletes: Obsoletes: libmudflap-static warning: Macro expanded in comment on line 2438: %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_major}/32/libquadmath.a warning: Macro expanded in comment on line 2442: %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_major}/32/libitm.a warning: Macro expanded in comment on line 2450: %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_major}/32/libasan.a warning: Macro expanded in comment on line 2455: %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_major}/32/libubsan.a warning: Macro expanded in comment on line 2709: %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_major}/32/libgfortran.a Building gcc-8.5.0-1.el8 for rhel-8.5.0-build-side-82991 Created task: 37157162 Task info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=37157162 Watching tasks (this may be safely interrupted)...
Verified that glibc32-2.28-1.2.el8 helps avoiding the reported file conflict as expected.
@Martin Banas - I assume you still work in RTT - could a testcase making sure that glibc32 (and also libgcc32) never leak into any rhel compose? These two packages should only be available in brew buildroot, but should never leak to any of Buildroot/CRB/AppStream/BaseOS composes. Thanks.
(In reply to Martin Cermak from comment #16) > Attempting a GCC build: > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=37157162 This passed and glibc32-2.28-1.2.el8 was used during the build.
Andrei, the new glibc32 package should now be in the buildroot. Does this fix the issue you reported? Thanks.