On 2009-05-09 jedd <[email protected]> wrote: > On Sunday 26 April 2009, Andreas Metzler wrote: >> This looks similar to #525494. Do you perhaps have set the >> environment variable MAKEFLAGS=-jX? (Witch X > 1, check with >> printenv).
> Yes, Andreas, you're bang on - it looks like the same bug, and I do > indeed have -j set - mostly for the benefits it gives, even on this > rinky Atom 1.6GHz. I will merge the bug reports, thanks. > I'm loathe to disable the -j setting, however, for that reason. > I see in #525494 that you suggest the hugin Makefiles may be > the causal factor - is this something you guys are taking upstream > to the hugin developers? We have already forwarded the bug report upstream http://sourceforge.net/tracker/?func=detail&aid=2781528&group_id=77506&atid=550441 > It seems that it's not a Debian problem, > of course, so I'd be surprised if only us two Debian users have > struck the problem. Even more so given that multi-core CPUs are > now the norm rather than the exception. Well, the only thing in a usual stitching process that is easy to run in parallel (nona) can make use of multiple CPUs by using threading without MAKEFLAGS=-jX. (Use File -> Settings -> # of CPUs). > What do you recommend (other than either what I'm doing now - > temporarily renaming rm - or going back to a single make thread > via MAKEFILES) for the long term? Renaming rm seems a little bit heavy handed. ;-) How about running "env -u MAKEFLAGS hugin" instead of "hugin"? For the long term I expect upstream to fix this. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
