On 08/03/16 02:45 PM, James Hogarth wrote: > On 8 March 2016 at 19:36, Digimer <lists at alteeve.ca> wrote: > >> On 08/03/16 02:32 PM, James Hogarth wrote: >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1315856 >>>>> >>>>> 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 ... Um, wow. That's pretty dumb. I've reassigned the ticket to EL6 -> mtr. Thank you very much for your help! I will poke at the .spec and report back here/the ticket if I make any progress (again, I'm fairly new to all this. :) ). -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?