Bug 1482066
| Summary: | rust-toolset-7-rhel7 image contains DTS4 packages | ||
|---|---|---|---|
| Product: | DevTools | Reporter: | Miloš Prchlík <mprchlik> |
| Component: | rust-toolset-7-container | Assignee: | Josh Stone <jistone> |
| Status: | CLOSED ERRATA | QA Contact: | Miloš Prchlík <mprchlik> |
| Severity: | unspecified | Docs Contact: | Vladimír Slávik <vslavik> |
| Priority: | unspecified | ||
| Version: | rust-toolset-7 | CC: | kanderso, mnewsome, rzima, tstellar |
| Target Milestone: | rc | ||
| Target Release: | 2.1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-10-24 08:39:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Miloš Prchlík
2017-08-16 11:56:10 UTC
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 |