Bug 798113

Summary: mock 1.1.21 fails to initialize epel-6-x86_64 chroot
Product: [Fedora] Fedora Reporter: ice799
Component: mockAssignee: Clark Williams <williams>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: ice799, mebrown, williams
Target Milestone: ---Flags: ice799: needinfo-
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-21 00:36:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
output of mock when trying to initialize an epel-6-x86_64 chroot none

Description ice799 2012-02-28 04:37:26 UTC
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.

Comment 1 ice799 2012-02-28 04:38:28 UTC
Created attachment 566198 [details]
output of mock when trying to initialize an epel-6-x86_64 chroot

Comment 2 Clark Williams 2012-03-22 18:02:50 UTC
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?

Comment 3 ice799 2012-03-22 18:13:22 UTC
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.

Comment 4 Clark Williams 2012-03-22 22:21:04 UTC
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)?

Comment 5 ice799 2012-03-23 00:45:25 UTC
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.

Comment 6 Clark Williams 2012-03-23 20:03:10 UTC
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.

Comment 7 Clark Williams 2012-08-18 15:25:27 UTC
any luck?

Comment 8 Fedora End Of Life 2013-04-03 18:00:02 UTC
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

Comment 9 Clark Williams 2014-01-21 00:36:13 UTC
closing