On Friday 16 December 2005 19:01, Brian Harring wrote:
On Fri, Dec 16, 2005 at 12:09:10PM +0900, Jason Stubbs wrote:
On Thursday 15 December 2005 20:06, Brian Harring wrote:
This is the only blocker for merging parallel-fetch as far as I can
tell- so... my vote is nuking the wait out of
On Thu, Dec 01, 2005 at 07:41:22PM -0600, Brian Harring wrote:
snip comments on parent emerge not killing child emerge
Either way, here's the issue, atexit registers work fine across forks,
portage.portagexit is registered prior to portage_exec.cleanup, so the
main portage pid sits there and
On Thu, Dec 01, 2005 at 12:03:46PM -0800, Zac Medico wrote:
Well, I'm running the latest svn so there could be a regression in the
recent changes to portage_exec.cleanup().
Does changing SIKTERM to SIGKILL fix it?
No, SIGKILL doesn't seem to make a difference (not a regression then). It
On Wed, Nov 30, 2005 at 12:51:58PM -0800, Zac Medico wrote:
Brian Harring wrote:
Note that due to how it's implemented, this does two rounds of
verification- it'll actually do *two* rounds of fetching too, if
things go awry in the backgrounded thread.
Two possible improvements to help
Brian Harring wrote:
2) Display a warning message via an atexit hook when parallel-fetching is
enabled, in order to alert the user that background fetching may _still_ be
in progress if emerge appears to hang after an ebuild dies (this happened
to me while kde-3.5 was fetching in the
Brian Harring wrote:
The modification is pretty straight forward offhand; the notable
difference this time around is rather then extending portage_exec to
have the capability to 'spawn' python funcs (something I always found
ugly), this handles the fork itself.
This patch seems to work well
Yo.
Continuing the pillaging of ebd, attached is an integration of
parallel-fetch.
The modification is pretty straight forward offhand; the notable
difference this time around is rather then extending portage_exec to
have the capability to 'spawn' python funcs (something I always found
