[gentoo-dev] Re: mtime preservation

[Peter Hjalmarsson <xake@rymdraket.net>]

tor 2009-11-26 klockan 05:04 +0000 skrev Duncan:
> Ciaran McCreesh posted on Wed, 25 Nov 2009 22:13:27 +0000 as excerpted:
> 
> > Examples will merely be
> > dismissed as one-off cases that can be worked around, or as relying upon
> > a string of coincidences that will "obviously" never really happen,
> > right up until they do, at which point they'll be dismissed with a
> > WORKSFORME. What you have is a proof that it's broken, which is far
> > better than an example.
> 
> Actually, that "dismissed with WORKSFORME" strikes a chord, here.  There 
> was a very strange parallel make bug that I filed that was closed with 
> that.  I'd have really liked to see someone with some skill tackle it, as 
> that was the only one I've ever seen that had striped fail and working 
> zones, and I've have loved to see some logic as to why...  (If -j10 
> failed, -j3 and -j15 might succeed, -l24 fail again, and -j33 succeed 
> again...)  Unfortunately, flameeyes, the only one I know who really gets 
> into such things, was fresh out of the hospital at the time, and I think 
> it was beyond the maintainer's abilities, so WORKSFORME was about the 
> best that could be done.  I've long since changed and changed again my 
> makeopts, and don't remember the pkg now, tho I could probably find it in 
> my old bug mail if I needed to.
> 
> So I gotta admit you have a point, with that one.
> 

That is just a *really* bad maintainer. Or a *really* bad bugreport. Or
something that showed you already had a *really* screwed up system.
What is the bug number?
Did you post your emerge --info and a *full* build.log?

Also information about what makeopts works and not gives nothing, that
just becomes noise. Becouse what makeopts works and not depends most of
the time on a race condition in the makefiles and can because of that
also depend on stuff like your current system load.