[CentOS] Can anyone compile mtr source RPM on CentOS 6.7?

[James Hogarth]

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