Pardon my bad mood, but you're chasing symptoms, not the problem. This bug isn't new, particularly related to processes hogging pelix, but is a more or less annoying recurring flaw in how pikefarm (xenofarm?) enforces checkin latencies.
I understand that the current process correctly detects the last known checkin and how long to wait after that, but does not correctly detect when the last build was generated, since it equates the time when the package was made available with the time its generation cycle was initiated, This will remain a bad aproximation for the foreseeable future.
A process that would work better:
1) enforce latencies before kicking off a new build (steps 2-4) 2) cvs co -D"$DATETIME" (DATETIME=Calendar.ISO_UTC.dwim_time(T)->set_timezone("localtime"); T=Protocols.HTTP.get_url_data(URL); URL="http://pike.ida.liu.se/development/cvs/latest-Pike-commit") 3) prepare the package 4) export the package, marked as $DATETIME in the pikefarm UI (same value, kept from above)
At present, the time spent running steps 2-4 breaks step 1 of the next cycle. This procedure would work regardless of extraordinary CPU hogs, like my xemacs runner-up eating 0.49% CPU time, or comstedts, however intense it might have been. It is also required to get links between pikefarm and the CVS browser to work. (Having the UI module know only UTC time would also help, of course, but I feel enough at ease hacking there to do so myself if need be, whereas I don't know my way around in the server.pike domain.)
/ Johan Sundström (ärkehertig av Lysators rootgrupp)
Previous text:
2002-10-12 15:21: Subject: Broken tests
It is building a dist since 14:04. Most of the CPU on the machine is used to run comstedts xemacs, with jhs' xemacs as runner up.
/ Martin Nilsson (Fake Build Master)