#5288 mock default epel-5-x86_64 config differences with Koji
Closed: Fixed None Opened 7 years ago by msuchy.

Forwarded from https://bugzilla.redhat.com/show_bug.cgi?id=1325533

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...


FYI, it fails to build in mock for me.

Unfortunately I think this might be an epel-rpm-macros problem. I've seen a similar failure before. Building now to double check.

Yes, it builds if you remove the %clean section.

I'll have to figure out how I can work around this, though I do wish we could just remove all of the %clean sections from EPEL packages.

Should we move this over to a bug on epel-rpm-macros now?

Please open a epel-rpm-macros bug for this. ;)

Login to comment on this ticket.

Metadata