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.
Created attachment 976157 [details] output from mock --verbose during a run
Created attachment 976158 [details] config.log from the actual configure attempt
Can't reproduce it. Could you attach your mock config?
'rpm -V mock' says that everything is unchanged, but I'll attach fedora-20-i386.cfg and site-defaults.cfg just in case. Also in case it makes a difference, my yum plugins are: PackageKit-yum-plugin-0.8.17-1.fc20.x86_64 yum-langpacks-0.4.4-1.fc20.noarch anaconda-yum-plugins-1.0-10.fc20.noarch yum-plugin-auto-update-debug-info-1.1.31-27.fc20.noarch yum-plugin-changelog-1.1.31-27.fc20.noarch yum-plugin-keys-1.1.31-27.fc20.noarch yum-plugin-list-data-1.1.31-27.fc20.noarch yum-plugin-local-1.1.31-27.fc20.noarch yum-plugin-upgrade-helper-1.1.31-27.fc20.noarch yum-plugin-versionlock-1.1.31-27.fc20.noarch I have no packages locked with versionlock.
Created attachment 976383 [details] my mock site-defaults.cfg
Created attachment 976395 [details] my mock fedora-20-i386.cfg
I have the same mock cfg's and still can't reproduce (even with the same yum plugins).
I don't know enough about what mock and yum are doing here to know what other packages or parts of my environment to look at. On the other hand, looking at the /var/lib/mock/fedora-20-i386/root/ that mock sets up and the yum commands that mock invokes, I'm not sure how this is supposed to work at all. My in-root yum config winds up saying eg: [fedora] name=fedora metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch failovermethod=priority gpgkey=file:///etc/pki/mock/RPM-GPG-KEY-fedora-20-primary gpgcheck=1 Unless mock has some magic way of forcing yum's $basearch value that does not appear in the mock --verbose output, I think yum is always going to look at the architecture and decide 'yep, 64-bit, default to 64-bit packages'. Presumably this means I don't understand what's going on.
I tried this in a relatively stock Fedora 20 x86_64 virtual machine image and couldn't reproduce this either. So something very funny is going on on my machine; unfortunately I don't know what it could be. Do you know where yum derives $basearch from and anything that might override it, so that I can try to look around for that?
Yum defines it from os.uname()[4] function ( rpmUtils/arch.py:getCanonArch() from yum sources ). The only thing, that I know can affect it is setarch, but mock uses its own 'internal setarch' if config_opts['internal_setarch'] = true (by default). Also, from mock site-default.cfg comments: # internal_setarch defaults to 'True' if the python 'ctypes' package is # available. It is in the python std lib on >= python 2.5. On older versions, # it is available as an addon. On systems w/o ctypes, it will default to 'False'
The bugs sounds very similar as bug 1111147 (which is fixed now), which resulted in RFE bug 1115483, but we workaround it in mock for now by resetting personality.
Can you try to disable ccache plugin: config_opts['plugin_conf']['ccache_enable'] = False in /etc/mock/site-defaults.cfg And probably yum_cache: config_opts['plugin_conf']['yum_cache_enable'] = False in the same file And check if that make difference for you?
I added these to /etc/mock/site-defaults.cfg and they didn't make any difference; 64-bit packages still got installed. I did notice that if I run 'mock -r fedora-20-i386 --shell', 'uname -a' and 'uname -m' in the resulting chroot'd shell report the right thing, ie i686 et al. So it seems to only be the actual yum commands run during setup. Would it be useful for me to manually hack up mockbuild/util.py to see if (and when) the condPersonality() function gets called in my particular environment? (I'm happy to make on the fly Python code changes here, and I know Python.)
Can you please post here version of your yum? rpm -q yum
# mkdir -p /tmp/doh # setarch i386 /usr/bin/yum \ --installroot /tmp/doh \ --releasever 20 install @buildsys-build \ --setopt=tsflags=nocontexts --nogpgcheck -v Does that ^^ install i686 packages? If not, something is wrong with your yum because this works for me. (In reply to Chris Siebenmann from comment #13) > Would it be useful for me to manually hack up mockbuild/util.py to > see if (and when) the condPersonality() function gets called in my > particular environment? IMO it could help. Any kind of debugging. (In reply to Miroslav Suchý from comment #14) > Can you please post here version of your yum? > rpm -q yum Based on the comment #0, yum-3.4.3-152.fc20.noarch
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.
> 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.
'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 message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
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.
It is still present in yum. But in DNF this logic is now in hawkey and it does not try to parse /etc/rpm/platform so this bug should be gone with DNF. So keeping closed.