On Wed, 12 Sep 2012 11:15:25 -0400 Michael Mol <mike...@gmail.com> wrote:
> On Wed, Sep 12, 2012 at 10:55 AM, Alan McKinnon > <alan.mckin...@gmail.com>wrote: > > > On Wed, 12 Sep 2012 16:00:34 +0200 > > Alex Schuster <wo...@wonkology.org> wrote: > > > > > Michael Mol writes: > > > > > > > On Wed, Sep 12, 2012 at 9:33 AM, Neil Bothwick > > > > <n...@digimed.co.uk <mailto:n...@digimed.co.uk>> wrote: > > > > > > > Instead we get, try USE="-*" :P > > > > > > > > "Try MAKEOPTS='-j1'" > > > > > > Which in fact often helps... especially for me, I am using > > > MAKEOPTS="-j --load=4", and I often experience build problems that > > > are not reproducible with a fixed number of jobs, regardless how > > > large. > > > > Yes indeed, and that one is good advice. > > > > Not every Makefile out there is safe for -j > 1, so running it as > > one job is valid debugging. It's the correct thing to do with weird > > build failures as it tests if a specific condition is true or not. > > > > > Yeah, except I've already gone that route, or otherwise ruled it out, > before I ask. That's why it's grating. (Even more grating when I have > to spend the time building a package again, just to convince someone > that, no, it's not MAKEOPTS that's the problem.) > > It's like "Have you tried turning it off and back on again". I learned that one the hard way :-) Now when I submit support posts, I try emulate what bgo asks: 1. nature of problem 2. what have I tried already 3. steps to reproduce 4. result gotten 5. expected result 6. relevant config files and settings Tends to weed out a lot of the silly auto-bot style answers > > > > > > > > > "Turn off distcc" > > > > > > "revdep-rebuild" > > > > > > And "emerge -e world && perl-cleaner --all && python-updater && > > > lafilefixer --justfixit". > > > > Another example of proper debugging. A wise troubleshooter will > > first verify that all relevant maintenance and consistency factors > > have been done first before doing extensive troubleshooting. > > > > The last one, "lafilefixer --justfixit" is especially valuable as it > > gets right of a huge gigantic steaming pile of crap that a) should > > never have been there at all in the first place and b) if it's > > causing the problem is almost impossible to pin down without lots > > of work. So even if b) is not true, you still get the huge benefit > > of a) > > > > > > > > > > > > -- > > Alan McKinnon > > alan.mckin...@gmail.com > > > > > > > > -- Alan McKinnon alan.mckin...@gmail.com
