Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: [remote:10]: mprchlik@dhcp-1-137 [master] ~/git/tests/rust/Sanity/basic-smoke $ docker run -it --rm rhscl-tech-preview/rust-toolset-7-rhel7 /bin/bash bash-4.2$ rpm -qa | grep devtoolset- devtoolset-4-gcc-5.2.1-2.2.el7.x86_64 devtoolset-4-runtime-4.0-9.el7.x86_64 bash-4.2$ I'd expect DTS-7 gcc & runtime. I suppose this could happen if the image has been built with wrong repositories enabled. Version-Release number of selected component (if applicable): rhscl-tech-preview/rust-toolset-7-rhel7 871a5b58059e How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
See bug 1482062 comment 1 -- I wasn't expecting to get a DTS gcc at all.
Radku, similar to https://bugzilla.redhat.com/show_bug.cgi?id=1482062. The image gets built with wrong buildroot, or whatever is the right term for the yum repositories available during the image build.
The log shows that it is installing some stuff from rhel-7-server-rpms, but I don't know why yum isn't picking gcc from there.
Martin, Josh, these packages are in container because devtoolset-7-dwz.x86_64 requires libelf.so.1()(64bit)) which is provided by devtoolset-3. Therefore devtoolset-3 was pulled into beta compose and from there it was taken for docker image. We have to fix devtoolset-7-dwz and then we will need new Beta compose. See below for more details. Pungi:INFO: Added devtoolset-3-elfutils-libelf.x86_64 (repo: pungi-repo) for devtoolset-7-dwz.x86_64 (Requires: libelf.so.1()(64bit)) rpm -qp --provides devtoolset-3-elfutils-libelf-0.161-1.el7.x86_64.rpm devtoolset-3-elfutils-libelf = 0.161-1.el7 devtoolset-3-elfutils-libelf(x86-64) = 0.161-1.el7 libelf.so.1()(64bit) libelf.so.1(ELFUTILS_1.0)(64bit) libelf.so.1(ELFUTILS_1.1)(64bit) libelf.so.1(ELFUTILS_1.1.1)(64bit) libelf.so.1(ELFUTILS_1.2)(64bit) libelf.so.1(ELFUTILS_1.3)(64bit) libelf.so.1(ELFUTILS_1.4)(64bit) libelf.so.1(ELFUTILS_1.5)(64bit) libelf.so.1(ELFUTILS_1.6)(64bit) scl-package(devtoolset-3) rpm -qp --provides devtoolset-7-elfutils-libelf-0.170-1.el7.x86_64.rpm devtoolset-7-elfutils-libelf = 0.170-1.el7 devtoolset-7-elfutils-libelf(x86-64) = 0.170-1.el7 libelf.so.dts.1()(64bit) libelf.so.dts.1(ELFUTILS_1.0)(64bit) libelf.so.dts.1(ELFUTILS_1.1)(64bit) libelf.so.dts.1(ELFUTILS_1.1.1)(64bit) libelf.so.dts.1(ELFUTILS_1.2)(64bit) libelf.so.dts.1(ELFUTILS_1.3)(64bit) libelf.so.dts.1(ELFUTILS_1.4)(64bit) libelf.so.dts.1(ELFUTILS_1.5)(64bit) libelf.so.dts.1(ELFUTILS_1.6)(64bit) libelf.so.dts.1(ELFUTILS_1.7)(64bit) scl-package(devtoolset-7)
Hmm, truth is that devtoolset-7-elfutils-libelf provides /opt/rh/devtoolset-7/root/usr/lib64/libelf.so.dts.1 with soname 'libelf.so.dts.1'. This was intentionally changed per bz1412305 within the dts-6.1 erratum RHBA-2017:1149. But devtoolset-7-dwz should be happy with the base rhel elfutils-libelf, like it did on my rhel-7.4 test box: ======= 7.4 Server x86_64 # rpm -qf /opt/rh/devtoolset-7/root/usr/bin/dwz devtoolset-7-dwz-0.12-1.el7.x86_64 7.4 Server x86_64 # ldd /opt/rh/devtoolset-7/root/usr/bin/dwz linux-vdso.so.1 => (0x00007fff435ee000) libelf.so.1 => /lib64/libelf.so.1 (0x00007fb0fe557000) libc.so.6 => /lib64/libc.so.6 (0x00007fb0fe194000) libz.so.1 => /lib64/libz.so.1 (0x00007fb0fdf7d000) /lib64/ld-linux-x86-64.so.2 (0x000055b3b0b59000) 7.4 Server x86_64 # rpm -qf /lib64/libelf.so.1 elfutils-libelf-0.168-8.el7.x86_64 7.4 Server x86_64 # ======= But interesting is that devtoolset-3 was pulled into play in instead of devtoolset-4 which provides newer libelf.so.1: ======= 7.4 Server x86_64 # eu-readelf --dynamic --notes /opt/rh/devtoolset-4/root/usr/lib64/libelf.so.1 | grep SONAME SONAME Library soname: [libelf.so.1] 7.4 Server x86_64 # 7.4 Server x86_64 # 7.4 Server x86_64 # rpm -qf /opt/rh/devtoolset-4/root/usr/lib64/libelf.so.1 devtoolset-4-elfutils-libelf-0.166-1.el7.x86_64 7.4 Server x86_64 # eu-readelf --dynamic --notes /opt/rh/devtoolset-4/root/usr/lib64/libelf.so.1 | grep SONAME SONAME Library soname: [libelf.so.1] 7.4 Server x86_64 # =======
That's true, in that case we need to look at lookaside repos during composes creation. I will try to investigate more.
fixed on composes side but we will need beta respin
For this purpose, I don't really want to get any devtoolset-*-gcc at all, but just the base OS gcc. Will that really be solved now?
from log is visible that wrong devtoolset package was taken from beta compose. There is not new beta compose yet, so it is fixed in configuration but we need prepare new compose. Right now I'm collecting other issues for new beta compose.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3035