On 08/03/16 02:45 PM, James Hogarth wrote:
> On 8 March 2016 at 19:36, Digimer <lists@xxxxxxxxxx> 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?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
