How embarrasing. I forgot a scheduled down time of the netowrk and was cut off in mid-checkin...
Maybe you know why pikefarm hasn't built a new dist yet although there were checkins an hour ago?
/ Henrik Grubbström (Lysator)
Previous text:
2002-10-12 15:10: Subject: Broken tests
How embarrasing. I forgot a scheduled down time of the netowrk and was cut off in mid-checkin...
/ Martin Nilsson (Fake Build Master)
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)
Previous text:
2002-10-12 15:14: Subject: Broken tests
Maybe you know why pikefarm hasn't built a new dist yet although there were checkins an hour ago?
/ Henrik Grubbström (Lysator)
Someone probably ought to kill -STOP them...
/ Henrik Grubbström (Lysator)
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)
Thanks.
BTW: It seems laxativ.bortas.org is missing gmp...
/ Henrik Grubbström (Lysator)
Previous text:
2002-10-12 15:52: Subject: Broken tests
marcus xemacs is -STOPed since it seems to be gobble up all cpu it can get. jhs xemacs seems to be harmless, so I will leave it for now.
/ Peter Bortas
Killed now. I have no idea what it was doing; that was the emacs I used to show something to Finnman last tuesday.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-10-12 15:52: Subject: Broken tests
marcus xemacs is -STOPed since it seems to be gobble up all cpu it can get. jhs xemacs seems to be harmless, so I will leave it for now.
/ Peter Bortas
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)
No, I wont pardon your bad mood, since it clearly influences your thoughts badly. It takes longer to make a dist when there are processes running around taking most CPU. It is not a design flaw. Your comments, no matter how clever, are irrelevant.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-12 17:51: Subject: Broken tests
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:
- enforce latencies before kicking off a new build (steps 2-4)
- 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)
Okay, I'm sorry I bit you, and while it's inviting, I won't bite back; let's not make this hurt the issue.
I have not yet understood why my suggested solution is bad, or would not work. Nor have I, if you were right, understood why the pikefarm server is missing checkins (9163360), or at least why it is and should be dependent on the time it takes to build a dist at pelix.
I want to make links between pikefarm builds and the CVS browser list checkins between builds. From what I understand, the times listed in pikefarm are not times that can be fed to cvs co/up -D (after timezone translation from CEST) to produce an identical build post facto. The lack of correlation makes no sense to me, and needs to be correlated to fix the linking (hypertext sense) problem. Or, if somebody actually wants the timestamps to mark the completion time of the dist, to store the cvs snapshot timestamp where I can find it.
/ Johan Sundström (ärkehertig av Lysators rootgrupp)
Previous text:
2002-10-13 02:18: Subject: Broken tests
No, I wont pardon your bad mood, since it clearly influences your thoughts badly. It takes longer to make a dist when there are processes running around taking most CPU. It is not a design flaw. Your comments, no matter how clever, are irrelevant.
/ Martin Nilsson (Fake Build Master)
The answer to 9163360 is that a build was started but had not yet finished due to lack of system resources. That all checkins done during this mutli-hour window was ignored by Xenofarm is of course a problem, but another one.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-13 04:54: Subject: Broken tests
Okay, I'm sorry I bit you, and while it's inviting, I won't bite back; let's not make this hurt the issue.
I have not yet understood why my suggested solution is bad, or would not work. Nor have I, if you were right, understood why the pikefarm server is missing checkins (9163360), or at least why it is and should be dependent on the time it takes to build a dist at pelix.
I want to make links between pikefarm builds and the CVS browser list checkins between builds. From what I understand, the times listed in pikefarm are not times that can be fed to cvs co/up -D (after timezone translation from CEST) to produce an identical build post facto. The lack of correlation makes no sense to me, and needs to be correlated to fix the linking (hypertext sense) problem. Or, if somebody actually wants the timestamps to mark the completion time of the dist, to store the cvs snapshot timestamp where I can find it.
/ Johan Sundström (ärkehertig av Lysators rootgrupp)
Ah, we are battling daemons of robustness too, then. :) Always a few things left on the never-ending todo list.
/ Johan Sundström (ärkehertig av Lysators rootgrupp)
Previous text:
2002-10-13 15:50: Subject: Broken tests
The answer to 9163360 is that a build was started but had not yet finished due to lack of system resources. That all checkins done during this mutli-hour window was ignored by Xenofarm is of course a problem, but another one.
/ Martin Nilsson (Fake Build Master)
Still the same problem, this time the last build is from yesterday, and the most recent checkin from a few hours ago.
/ Henrik Grubbström (Lysator)
Previous text:
2002-10-12 15:14: Subject: Broken tests
Maybe you know why pikefarm hasn't built a new dist yet although there were checkins an hour ago?
/ Henrik Grubbström (Lysator)
My fault. Building new dist now.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-15 13:50: Subject: Pikefarm doesn't generate new dists properly
Still the same problem, this time the last build is from yesterday, and the most recent checkin from a few hours ago.
/ Henrik Grubbström (Lysator)
Yes, but something still seems broken, since not a single result has been reported in the ~2 hours the dist has existed.
/ Henrik Grubbström (Lysator)
Previous text:
2002-10-15 13:58: Subject: Pikefarm doesn't generate new dists properly
My fault. Building new dist now.
/ Martin Nilsson (Fake Build Master)
Aha. I know what the problem is, but it will take a while to fix.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-15 16:15: Subject: Pikefarm doesn't generate new dists properly
Yes, but something still seems broken, since not a single result has been reported in the ~2 hours the dist has existed.
/ Henrik Grubbström (Lysator)
Oh? So what is the cause?
/ Henrik Grubbström (Lysator)
Previous text:
2002-10-15 16:56: Subject: Pikefarm doesn't generate new dists properly
Aha. I know what the problem is, but it will take a while to fix.
/ Martin Nilsson (Fake Build Master)
The ID in the package is different from what is stored in the database.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-15 17:02: Subject: Pikefarm doesn't generate new dists properly
Oh? So what is the cause?
/ Henrik Grubbström (Lysator)
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Johan Sundstr�m (�rkehertig av Lysators rootgrupp) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (Fake Build Master) ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum