Bug 1325533 - mock default epel-5-x86_64 config differences with Koji
Summary: mock default epel-5-x86_64 config differences with Koji
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 23
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-09 18:14 UTC by David Brown
Modified: 2016-05-12 16:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-12 10:39:20 UTC
Type: Bug


Attachments (Terms of Use)
Sorted package list diff between koji and local centos builds (2.04 KB, patch)
2016-04-09 18:16 UTC, David Brown
no flags Details | Diff

Description David Brown 2016-04-09 18:14:36 UTC
Description of problem:
So I'm not sure what's changed with epel-5-x86_64 recently in the Koji build system but here's the symptoms... and I'm not sure who's fault it is really...

I'm trying to rebuild a new version of torque (4.2.10-10.el5)

In my git tree I can build the package locally just fine. fedpkg mockbuild does a good job of building the el5 version of the package. However, it surprised me when I submitted the build to Koji that it failed.

http://koji.fedoraproject.org/koji/taskinfo?taskID=13605847

After some serious package list diffing from the output logs in Koji I found some differences between the mock Koji ran and the mock that fedpkg ran on my local system.

To reproduce the error in Koji I have to change the following line in the default epel-5-x86_64 config...

from: config_opts['chroot_setup_cmd'] = 'install buildsys-build buildsys-macros'
  to: config_opts['chroot_setup_cmd'] = 'install buildsys-build buildsys-macros epel-release epel-rpm-macros fakeroot fakeroot-libs wget rpmdevtools rpm-python'

I was able to reproduce the Koji error with the changed epel-5-x86_64 mock config.

So, the bug in my mind is that the default mock config that fedpkg ran isn't aligned with what Koji is using to build packages... It would be nice if they both ran the same(ish) thing. I found it odd that I had to add a bunch of packages that the package I was working on didn't depend on (directly).

If the mock configs are aligned I couldn't tell, as I can't seem to find the config that Koji used to build the package or the exact command line it was using to run mock. (maybe a Koji bug/feature request)

I did notice that Koji is using official RHEL 5.11 Server and mock is using CentOS 5.11. So, is there a difference in the base packages that brought in additional packages into the Koji build? I hope not...

Version-Release number of selected component (if applicable):
mock-1.2.17-1.el7.noarch (local machine)
INFO buildroot.py:309:  Mock Version: 1.2.17 (from Koji)

How reproducible:
Very

Steps to Reproduce:
1. find the torque el5 src rpm
2. fedpkg mockbuild (Hey it worked!)
3. fedpkg scratchbuild (Hey it didn't?!?!)

Actual results:
fedpkg build created a failed build when everything locally worked.

Expected results:
fedpkg mockbuild should have caught the issue on my local system before issuing the build to Koji.


Additional info:
I'd like to bring in the fedpkg maintainer and the Koji maintainer on this to figure out an appropriate way to fix this, as I'm not sure the right solution can be done by the mock folks. However, bugzilla only allows one component and mock is in the middle of this bug...

Comment 1 David Brown 2016-04-09 18:16:58 UTC
Created attachment 1145429 [details]
Sorted package list diff between koji and local centos builds

Comment 2 Miroslav Suchý 2016-05-12 10:39:20 UTC
This is not mock problem, but rather Fedora Koji instance. So it should be reported to Fedora Infrastructure team who operate the Koji instance. I done that for you:
https://fedorahosted.org/fedora-infrastructure/ticket/5288

Comment 3 David Brown 2016-05-12 16:26:46 UTC
Thanks, that's exactly what I expected.


Note You need to log in before you can comment on or make changes to this bug.