Hide Forgot
Description of problem: Trying to initialize an epel-6-x86_64 chroot (as well as trying to build an srpm) fail (output below). Version-Release number of selected component (if applicable): 1.1.21 (taken from git) How reproducible: every single time, even after deleting the cache from /var/cache/mock and starting over. maybe i'm forgetting a cache somewhere? i have tried: mock --scrub=all -r epel-6-x86_64 --resultdir=/tmp sudo yum clean all rm -rf /var/cache/mock/epel-6-x86_64 before initializing the epel-6-x86_64 chroot. Steps to Reproduce: 1. i installed mock 1.1.21 from git. 2. i have chroots (and successfully completed builds) for epel-5-i386, epel-5-x86_64, epel-6-i386 -- maybe having multiple chroots has something to do with it? 3. mock --init -r epel-6-x86_64 --resultdir=/tmp Actual results: actual results are quite verbose, so please see the attached log file. Expected results: an initialized epel-6-x86_64 chroot that can be used to build source rpms. Additional info: my machine is 64bit.
Created attachment 566198 [details] output of mock when trying to initialize an epel-6-x86_64 chroot
I've been trying to reproduce this on my F16 system with no luck. It kinda looks like a repository sync issue, since first you see this: DEBUG util.py:257: Not using downloaded repomd.xml because it is older than what we have: DEBUG util.py:257: Current : Sun Feb 26 20:07:10 2012 DEBUG util.py:257: Downloaded: Sun Feb 19 17:48:58 2012 Then you get a depsolve issue between libselinux.so.1 and glibc (and I do see the 64-bit glibc in the list of packages to install). So, two questions: 1. Are you still seeing this? 2. If so, on what OS are you hosting mock?
Thanks for the reply. Yes, I am still seeing this. I was using mock on an Ubuntu Lucid (10.04) machine with the default versions of yum (3.2.25) and rpm (4.7.2). I was unable to reproduce this on a CentOS 6 machine -- it appears to work fine there (as expected). I wonder: is it possible that mock is looking at my local machine when trying to depsolve instead of the chroot itself and finding the older libc6 that ships with Lucid? Let me know how else I can help.
well, it's not mock that's doing the looking, it's yum; mock uses yum to do dependency solving. All chroot building is done *outside* a chroot with the native yum/rpm, but if they honor the --root option there shouldn't be a problem. Did you install the mock/yum/rpm combo from Ubuntu repositories (ala apt-get)?
right, my mistake. i'm using the yum/rpm combo from the lucid repositories (yes via apt-get), but i am using mock from the official git repository and not the apt package.
Might want to try: $ mock --verbose --init -r epel-6-x86_64 --resultdir=/tmp and see if anything interesting pops out. Might also try not using /tmp but letting the results go to /var/lib/mock. Another data point would be to know what the versions are for rpm and yum.
any luck?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
closing