On 8 March 2016 at 19:36, Digimer lists@alteeve.ca wrote:
On 08/03/16 02:32 PM, James Hogarth wrote:
What's odd is how it works in Fedora using mock but not EPEL6 with mock
...
got to be down to how the build roots are constructed.
Decided to do a quick test of something given how EPEL has adjusted
macros
recently to reduce boilerplate between Fedora and itself ...
I just removed the rm -rf line from %clean and got a clean mock build
on
a
CentOS6 base.
It must have cleaned out the generated makefile between %build and
%install
and that left it with the bare one that had no install: section
This will bite Red Hat at the 6.8 milestone (unless they build on
Fedora)
and presumably CentOS when 6.8 rolls round if RH don't remove the rm
-rf
from %clean ;)
Should the priority on the bug be changed?
No leave it as is for now ...
I'm really quite confused as after it worked I thought I'd try the
original
SRPM again and it worked :/
I have no idea what has changed on the system to provide for that - doing some quick looks now.
OK, let me know if I can assist/test.
Okay I have what I believe to be the answer ... a rather horrible race condition.
The generated makefile has a '(sleep 3; cp Makefile.dist Makefile) &' in it for the distclean target.
The Makefile.dist is the bare empty one.
Note how this backgrounds ? There is no wait after this ...
So three seconds after the make distclean target is hit *bam* the full Makefile with the install target gets overwritten by the bare one.
So now whether the build works or not is a function of how fast you make it to make install .... Take longer than 3 seconds after the ./configure and there won't be a valid Makefile for the install (unless ./configure has rerun already - see how messy this is?)
This is definitely not a mock bug - that can be closed. It's a bug in the EL6 mtr spec file.
See lines 1812 and 4005 for the relevant happenings in the pastebin I put up before showing the behavioural difference between F23 and EPEL6
Note that my EPEL6 system is a VM so inherently slower... but once the data from disk is in the kernel cache it's faster on the subsequent builds and makes the race....
The VM is on a spinning disk (on btrfs) whereas the F23 build happened on an SSD (btrfs but less of an issue then) which would naturally cause the big speed difference.
I'd open a bug on bugzilla instead against RHEL6 and mtr explaining the race condition.
I can't think of a good reason in a spec file to background a 3 second wait and then overwrite a file that will be used in compilation/install ...