This problem very likely occurs in DNF too. I am cloning it solely to document the use cases for bug 1163028. The resolution of this bug depends on how we decide to document behaviour of --installroot. +++ This bug was initially created as a clone of Bug #1178580 +++ Description of problem: Running on an x86_64 Fedora 20 host, I cannot use mock to rebuild RPMs for the target 'fedora-20-i386' or 'fedora-21-i386'. In both cases attempts to build the RPM will fail at ./configure time because the C compiler cannot be run. The reason it can't be run is that despite this theoretically being a 32-bit buildroot, vast swatches of x86_64 RPMs have been installed and vast swatches of i686 RPMs (such as libc) have *not* been installed. This is a fairly severe issue because it prevents rebuilding i686 packages on an x86_64 host if you have local versions of a dual architecture package installed and now need to update it for some reason. Without the ability to rebuild a 32-bit version, you're screwed (as I am now). Version-Release number of selected component (if applicable): mock-1.2.3-1.fc20.noarch yum-3.4.3-152.fc20.noarch This also happens on several prior releases of mock, so it may be a behavior change in yum. How reproducible: Completely. Steps to Reproduce: 1. Get a source RPM. Freetype will do. 2. mock -r fedora-20-i386 --scrub all 3. setarch i386 mock --verbose -r fedora-20-i386 freetype-2.5.0-7.fc20.src.rpmo setarch isn't supposed to be necessary but I've provided it as an extra-large hammer. Actual results: Build run eventually fails with: DEBUG: configure: WARNING: unrecognized options: --disable-dependency-tracking DEBUG: checking build system type... x86_64-redhat-linux-gnu DEBUG: checking host system type... x86_64-redhat-linux-gnu DEBUG: checking for x86_64-redhat-linux-gnu-gcc... no DEBUG: checking for gcc... gcc DEBUG: checking whether the C compiler works... no DEBUG: configure: error: in `/builddir/build/BUILD/freetype-2.5.0/builds/unix': DEBUG: configure: error: C compiler cannot create executables DEBUG: See `config.log' for more details DEBUG: make: *** [setup] Error 77 Inspection of the install logs will reveal that, for example, there are no 32-bit libraries that freetype depends on installed; the versions (and -devel versions) are x86_64 versions. Expected results: Build completes, produces 32-bit binaries. Additional info: I will attach the full output of a mock run and the config.log output. --- Additional comment from Chris Siebenmann on 2015-01-08 08:29:16 EST --- My current yum version is indeed yum-3.4.3-152.fc20.noarch. 'rpm -V yum' says it's unmodified except /etc/yum.conf, which I modified to keep more kernels ('installonly_limit=...'). It does appear to be yum. 'setarch i386 yum ...' tries to install 64-bit packages. The very first package it tries to install is: Resolving Dependencies --> Running transaction check ---> Package bash.x86_64 0:4.2.53-1.fc20 will be installed So from the moment it starts picking packages it's going bad. After the first try (with the command line as-is) did this, I retried with '--disablerepo=* --enablerepo fedora --enablerepo updates' and it did the same thing. I can't see anything in the yum output up to that point that's useful. setarch itself works; 'setarch i386 uname -m' shows the expected i686 and 'setarch i386 python' followed by importing the os module and looking at 'os.uname()[4]' also show i686. Oh! I found it! rpmUtils.arch.getCanonArch() looks at /etc/rpm/platform first unless called with 'skipRpmPlatform=True', which arch.py doesn't seem to do. I have an /etc/rpm/platform with 'x86_64-redhat-linux' (and I don't know where it comes from, it's been there since 2006). With this removed, everything seems to work fine (eg the yum command above works). Is yum checking /etc/rpm/platform a recent change? (Either by adding that code or by no longer calling getCanonArch() with skipRpmPlatform=True.) This definitely didn't used to happen in Fedora 20 (and in earlier Fedora versions this machine has run); I've built and rebuilt 32-bit RPMs on my machine before, although probably not in the last few months. --- Additional comment from Miroslav Suchý on 2015-01-08 09:14:24 EST --- > Oh! I found it! Perfect! Does rpm -qf /etc/rpm/platform say something? So it is yum bug. Reassigning. It is weird that this behaviour happen now to you. The code is in yum since: Tue Feb 17 05:22:35 2004 IMO correct solution should be to not read /etc/rpm/platform, but to read ${installroot}/etc/rpm/platform (if exists). However since yum is in maintance mode now, feel free to close it as DEFERRED. I done 'git grep' in dnf.git and it appear the code is not there. So DNF should be safe. --- Additional comment from Chris Siebenmann on 2015-01-08 10:43:44 EST --- 'rpm -qf /etc/rpm/platform' says that it's not owned by a package. This machine was initially installed in 2006 and has been upgraded from Fedora version to Fedora version ever since; /etc/rpm/platform appears to have been written during that initial installation (it's got about the right timestamp for it) and then never touched afterwards. (/etc/rpm/platform appears to be a 2002-era feature that was designed to get rpm out of the business of parsing uname(2) to determine the architecture. More modern Fedora installs, such as a machine initially installed in 2011 and upgraded from version to version since then, do not have an /etc/rpm/platform. I suspect that at one point the installer created it because rpm wanted it and then that feature was backed out of rpm and thus the installer.) As a result, I suspect that this is not an important bug (especially with yum in maintenance mode). As for timing of when this broke for me and versions of packages, it looks like I probably last rebuilt a i686 package with mock in March 2014, and at the time I probably had yum-3.4.3-137.fc20 and mock-1.1.36-1.fc20 (based on /var/log/yum.log*'s logging of what was updated when). I can't see anything obvious in 'rpm -q --changelog' for mock or yum since then.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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 please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still valid.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
It looks lite that it is impossible to reproduce the issue with dnf-2.5.1-1 (dnf-nightly version) on Fedora 25. If anyone will find the issue reproducer with dnf-2.5.1+, please don't hesitate to reopen the bug report.
The code was removed in commit f7dd24e10fdc6d1edc7b0924af0201dfb114223b And replaced by arch = hawkey.detect_arch() I tried to create /etc/rpm/platform with some different content and hawkey seems to ignore it, which is good. So I am fine with closing.