Bug 1111251

Summary: mockchain fails after installing build requires
Product: [Fedora] Fedora Reporter: Mattias Ellert <mattias.ellert>
Component: mockAssignee: Clark Williams <williams>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: asamalik, jdisnard, mattias.ellert, mebrown, msuchy, williams
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-17 08:28:35 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:
Attachments:
Description Flags
The root.log as requested
none
Patch that fixes the problem none

Description Mattias Ellert 2014-06-19 14:56:15 UTC
Description of problem:

If I build a srpm in mock it works fine:

mock --root fedora-rawhide-x86_64 udt-4.11-2.fc20.src.rpm

If I try to do the same with mockchain it fails (I know it doesn't make sense to build a single package with mockchain, but this is a minimal example to trigger the problem):

mockchain --root fedora-rawhide-x86_64 udt-4.11-2.fc20.src.rpm

The above command just fails completely. The only result is a "fail" file containing the word "undone". If I use absolute path to the srpm it work slightly better:

mockchain --root fedora-rawhide-x86_64 ${PWD}/udt-4.11-2.fc20.src.rpm

I don't unserstand why this would make a difference at all. Also in this case it doesn't work. The root.log shows the installation of the default build root and the build requires, but then it doesn't do anything further. The build.log contains a single line saying "Mock Version: 1.1.39" and nothing more.


Version-Release number of selected component (if applicable):

$ rpm -q --whatprovides /usr/bin/mockchain 
mock-1.1.39-1.fc20.noarch


How reproducible:
Always

Steps to Reproduce:
1. See above

Actual results:
Failed build

Expected results:
Successful build

Comment 1 Miroslav Suchý 2014-06-19 15:02:12 UTC
This behaviour happen when mock (called by mockchain) fail.

Can you please try:
  mock --root fedora-rawhide-x86_64 udt-4.11-2.fc20.src.rpm

What error it will print. And attach root.log here?

Comment 2 Mattias Ellert 2014-06-20 09:43:44 UTC
Created attachment 910737 [details]
The root.log as requested

The output from the command is;

$ mockchain --root fedora-rawhide-x86_64 udt-4.11-2.fc20.src.rpm
starting logfile: None
results dir: /var/tmp/mock-chain-ellert-19618-cV9XyG/results/fedora-rawhide-x86_64
config dir: /var/tmp/mock-chain-ellert-19618-cV9XyG/configs/fedora-rawhide-x86_64
Start build: udt-4.11-2.fc20.src.rpm
building udt-4.11-2.fc20.src.rpm
End build: udt-4.11-2.fc20.src.rpm
Error building udt-4.11-2.fc20.src.rpm.
See logs/results in /var/tmp/mock-chain-ellert-19618-cV9XyG/results/fedora-rawhide-x86_64
Results out to: /var/tmp/mock-chain-ellert-19618-cV9XyG/results/fedora-rawhide-x86_64
Pkgs built: 0

Comment 3 Adam Samalik 2014-07-14 08:48:12 UTC
Hi, I just tried to reproduce this issue and it worked for me fine:

$ mockchain -r fedora-rawhide-x86_64 hello-2.8-1.fc20.src.rpm 
starting logfile: None
results dir: /var/tmp/mock-chain-adam-2750-H7FV0O/results/fedora-rawhide-x86_64
config dir: /var/tmp/mock-chain-adam-2750-H7FV0O/configs/fedora-rawhide-x86_64
Start build: hello-2.8-1.fc20.src.rpm
building hello-2.8-1.fc20.src.rpm
End build: hello-2.8-1.fc20.src.rpm
Success building hello-2.8-1.fc20.src.rpm
Results out to: /var/tmp/mock-chain-adam-2750-H7FV0O/results/fedora-rawhide-x86_64
Pkgs built: 1
Packages successfully built in this order:
hello-2.8-1.fc20.src.rpm

$ rpm -q --whatprovides /usr/bin/mockchain
mock-1.1.39-1.fc20.noarch

Comment 4 Mattias Ellert 2014-07-16 19:27:48 UTC
Created attachment 918505 [details]
Patch that fixes the problem

I have debugged the problem and found a solution. Patch attached.

Comment 5 Miroslav Suchý 2014-07-17 08:28:35 UTC
Ah! This was already fixed in bug 1108265.

Marking as duplicate

*** This bug has been marked as a duplicate of bug 1108265 ***