=== lamont__ [~lamont@15.238.5.130] has joined #ubuntu-toolchain | ||
=== Seveaz [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain | ||
=== BenM is now known as bhome | ||
=== bzzz is now known as BenM | ||
fabbione | morning | 06:13 |
---|---|---|
fabbione | infinity: ping? | 06:33 |
fabbione | lamont: ping? | 06:34 |
lamont | fabbione: ack | 07:06 |
fabbione | lamont: yo.. | 07:06 |
lamont | gcc-4.0 -8ubuntu3 is at 9.5 hours. sigh | 07:06 |
fabbione | lamont: i was asking infinity as well.. do you remember the commands that a buildd needs to have in sudo privileges without passwd? | 07:06 |
fabbione | right now we figured apt-get and dpkg | 07:07 |
lamont | I know it passes lots of cruft in - generally the machines I've seen just gave buildd all commands, prolly out of lazyiness | 07:07 |
lamont | it's going to need chroot as well, I expect | 07:07 |
fabbione | and if any of you 2 remembers how to get stats out of a single buildd? | 07:08 |
fabbione | lamont: hm right.. | 07:08 |
fabbione | like i have N buildds.. but i want to know exactly how much work one buildd is doing | 07:08 |
lamont | more ~buildd/stats/Summary | 07:09 |
fabbione | there is no Summary :) | 07:09 |
lamont | dunno why I have one then | 07:10 |
fabbione | some of your scripts generate it? | 07:10 |
=== lamont shrugs. all of the (neuro-based) buildd's I'm running have stats... | ||
fabbione | this is the one from db.d.o | 07:11 |
lamont | yep | 07:11 |
fabbione | sparcbuildd@test7:~/stats$ ls | 07:11 |
fabbione | build-time builds taken | 07:11 |
=== fabbione scratches his head | ||
fabbione | is it a config option? | 07:12 |
lamont | buildd-watcher creates summary | 07:12 |
fabbione | hmm i don't think i am running it.. should i? | 07:12 |
lamont | it'll give you a summary :-) | 07:12 |
lamont | and keep buildd running.. | 07:13 |
lamont | 20,50 * * * * nice -10 /usr/bin/buildd-watcher | 07:13 |
lamont | is what debian has | 07:13 |
fabbione | buildd keeps running anyway :) | 07:13 |
=== lamont needs to sleep | ||
fabbione | lamont: last question :) | 07:14 |
fabbione | the option to fork buildd if more than N packages needs-build | 07:14 |
fabbione | did you ever use it? | 07:14 |
fabbione | does it actually work? | 07:14 |
fabbione | (i know infinity i did ask you already ;)) | 07:14 |
lamont | haven't used it | 07:14 |
fabbione | ok | 07:14 |
lamont | but I expect that works | 07:14 |
lamont | since some of the slower debian architectures have been using it at least in the past | 07:15 |
fabbione | i wonder who i could ask for sure... | 07:16 |
lamont | any more 'one last question's? | 07:16 |
fabbione | nope :) | 07:16 |
lamont | ok. gonna sleep, I think. | 07:16 |
infinity | Are you talking about the secondary threshold? | 07:16 |
fabbione | infinity: yes | 07:16 |
lamont | bah - /me looks at the buildd source for a minute | 07:16 |
fabbione | lamont: don't worry.. | 07:17 |
fabbione | have a good night :) | 07:17 |
infinity | Revisiting that recently, I'm not sure it's an option to fork at all. | 07:17 |
fabbione | please it's really nothing urgent | 07:17 |
fabbione | Build daemon statistics from 19700101-0100 to 20050617-0715 (12951.22 days): | 07:17 |
fabbione | haah | 07:17 |
infinity | But rather to declare the this particular buildd is a "secondary", and should only --take and build packages if needs-build is > foo | 07:17 |
fabbione | the first run is sick :) | 07:17 |
lamont | logger( "$dist: total $total packages to build.\n" ) if $total; | 07:17 |
lamont | if ($total && $conf::secondary_daemon_threshold && | 07:17 |
lamont | $total < $conf::secondary_daemon_threshold) { | 07:17 |
lamont | logger( "Not enough packages to build -- ". | 07:17 |
lamont | "secondary daemon not starting\n" ); | 07:17 |
lamont | next; | 07:17 |
lamont | } | 07:17 |
lamont | looks right to me | 07:17 |
lamont | infinity: exactly | 07:17 |
infinity | See? :) | 07:18 |
infinity | No forking. | 07:18 |
lamont | so the buildd just idles along doing nothing until such time as the rest have fallen behind. then it kicks in and actually does something for a bit | 07:18 |
=== lamont sleeps | ||
fabbione | good night lamont | 07:18 |
lamont | infinity: forking wouldn't help, since it's on the same machine... /me just figured that fabbione was using words in a slightly european manner. :) | 07:19 |
fabbione | ehhe | 07:19 |
=== lamont cries. I'll deal with caballero tomorrow when I'm awake | ||
lamont | starting with a fresh kernel build for it. | 07:22 |
lamont | esp if fabbione has finished and uploaded -1.2 | 07:22 |
fabbione | lamont: i am almost done :) | 07:22 |
fabbione | i miss usb-modules, pcmcia* and nic* | 07:23 |
fabbione | the latter is a real pain :( | 07:23 |
infinity | lamont : No, forking obviously wouldn't work, hence the confusion. :) | 07:25 |
infinity | (Well, forking could work if you made dead sure that you were always building for two different dists in parallel, and never two packages on the same dist) | 07:25 |
infinity | Could be handy to get RIGHT NOW, DAMNIT security builds without runinng a second buildd. | 07:26 |
fabbione | infinity: it can't be that hard to implement | 07:30 |
fabbione | but i am hounestly far away motivated to do so | 07:30 |
fabbione | or given a good design | 07:31 |
fabbione | get sbuild to understand the concept of target chroot | 07:31 |
fabbione | and get buildd to for N instances of sbuild | 07:32 |
fabbione | at that point the concept of suite can be easily implemented in buildd to run sbuild N times | 07:32 |
=== fabbione thinks.... | ||
fabbione | can't be that hard | 07:33 |
infinity | I think all you really need here is target locking. | 07:33 |
fabbione | with target locking you can run only one instance of sbuild for breezy for ex | 07:34 |
fabbione | and one for hoary-security | 07:34 |
infinity | Also handy if a machine goes down in the middle of a build. No more @reboot touch ~buildd/NO-DAEMON-PLEASE, but instead you get a buildd that comes up building for all the non-locked chroots, and you get the clean the locked on. | 07:34 |
fabbione | that's because sbuildd is hardcoded for the target chroot | 07:34 |
infinity | Why would I want more than one for breezy?... | 07:34 |
infinity | Oh, I guess if you want to take advantage of multiple CPUs and fast disk. | 07:35 |
fabbione | exactly | 07:35 |
infinity | But that's a use case I don't care about as much as timely security updates. | 07:35 |
daniels | and timely xorg updates | 07:35 |
fabbione | so the first step would be to let sbuild understand in what chroot it should build | 07:35 |
fabbione | no option = use the default | 07:35 |
fabbione | otherwise switch to the specified chroot | 07:36 |
infinity | Just have it pick a random unlocked chroot at build-target/chroot-target[0-9] | 07:36 |
fabbione | buildd at that point can really for N instances of sbuild | 07:36 |
infinity | Or whatever. | 07:36 |
infinity | (And don't spawn new instances if all available chroots are locked) | 07:36 |
fabbione | and buildd will need to understand the concept of forking and forking per release/security or whatever | 07:37 |
fabbione | exactly | 07:37 |
infinity | No config file changes to add new chroots that way. And when you fix a locked chroot, it magically comes back online. | 07:37 |
fabbione | it doesn't sound impossible.. just boring to death to do it :) | 07:37 |
infinity | It sounds like something I'd happily do... If I was allowed to. | 07:37 |
infinity | <cough> | 07:37 |
=== BenM is now known as bsleep | ||
=== doko [~doko___@dsl-084-059-075-240.arcor-ip.net] has joined #ubuntu-toolchain | ||
fabbione | elmo: did you already setup logs@u.c ? | 09:58 |
elmo | fabbione: no | 09:59 |
fabbione | elmo: ok thanks :) | 10:00 |
\sh | make[4] : *** [Sequence.o] Segmentation fault | 11:48 |
\sh | ppc..if anybody is interessted to check: http://people.ubuntu.com/~lamont/buildLogs/o/openscenegraph/0.9.8-4ubuntu2/openscenegraph_0.9.8-4ubuntu2_20050617-0944-powerpc-failed.gz | 11:49 |
fabbione | \sh: ppc is known to send spurios segfaults | 11:49 |
fabbione | it's probably enough to kick the package back | 11:49 |
fabbione | that problem will go away as soon as we can install ppc64 kernels on the buildd | 11:49 |
\sh | so...version+1 and do it again | 11:50 |
fabbione | no | 11:50 |
fabbione | you wait for lamont/infinity/elmo to kick it back | 11:50 |
\sh | oh ok | 11:50 |
fabbione | uploading to trigger a rebuild is BAD | 11:50 |
fabbione | and pointless | 11:50 |
infinity | And BAD. | 12:29 |
infinity | Also, it's not good. | 12:29 |
=== jbailey crawls towards being alert. | ||
=== cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain | ||
=== cartman [foobar@cartman.developer.konversation] has left #ubuntu-toolchain ["Ich] | ||
=== zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain | ||
lamont | fabbione: ppc is known to send spurious SIGILL, not SEGV | 03:12 |
jbailey | HPPA on the other hand... | 03:15 |
=== jbailey hides. | ||
fabbione | lamont: well whatever :) | 03:18 |
fabbione | lamont: ppc64 kernels fix that | 03:18 |
fabbione | lamont: i did try to be extremely careful changing the d-i stuff on hppa | 03:18 |
fabbione | lamont: but i can't be 100% sure it's ok | 03:18 |
fabbione | of all the changes i missed one on ppc.. (the HACK ALERT ) | 03:18 |
lamont | so I should do another test build, eh? | 03:19 |
fabbione | if it fails on hppa please send me the last 30 lines of the log | 03:19 |
fabbione | lamont: i already uploaded | 03:19 |
fabbione | mdz wants .12 in main asap | 03:19 |
lamont | buildd 18155 0.0 0.2 37800 17068 ? SN 02:15 0:00 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe | 03:20 |
lamont | buildd 18156 0.0 0.2 37800 17068 ? SN 02:15 0:00 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe | 03:20 |
lamont | buildd 18157 20.4 0.2 37800 17068 ? RN 02:15 62:11 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe | 03:20 |
lamont | buildd 18158 20.4 0.2 37800 17068 ? RN 02:15 62:16 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe | 03:20 |
lamont | buildd 18159 20.4 0.2 37800 17068 ? RN 02:15 62:19 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe | 03:20 |
lamont | buildd 18160 20.4 0.2 37800 17068 ? RN 02:15 62:06 /build/buildd/gcc-4.0-4.0.0/build/hppa-linux/libjava/testsuite/SyncTest.exe | 03:20 |
lamont | buildd 18161 0.0 0.0 2224 564 ? SN 02:15 0:00 \_ c++filt -s java | 03:20 |
=== lamont throws SyncTest.exe at doko | ||
=== doko ducks | ||
lamont | otoh, your ada-test-b0rkage-killer seems to work fine | 03:23 |
=== lamont --> work | ||
doko | hmm, but somebody reported something with the acats-killer ... | 03:29 |
=== doko [~doko___@dsl-084-059-081-250.arcor-ip.net] has joined #ubuntu-toolchain | ||
=== lamont [~lamont@15.238.5.145] has joined #ubuntu-toolchain | ||
=== bhome is now known as BenM | ||
lamont | wow. after killing all those doko-be-damned SyncTest.exe's, gcc-4.0 may actually finish building (it's installing now) | 04:41 |
lamont | Subject: Log for successful build of gcc-4.0_4.0.0-8ubuntu3 (dist=breezy) | 04:54 |
lamont | Build needed 19:17:02, 2076384k disk space | 04:55 |
lamont | admittedly, something around 5 hours of that was waiting for some nice admin to killall -9 SyncTest.exe | 04:55 |
lamont | I'm not sure if it's worse that I have a 24-port managed switch under my desk, or that there are 8 ports currently lit in it. | 04:59 |
lamont | wow. binutils wants 7 min on i386, 21 on ia64, and 94 on hppa. WTH? | 06:23 |
lamont | hrm. probably binutils-hppa64 | 06:23 |
\sh | lamont: libtool: link: `../lib/libh5tools.la' is not a valid libtool archive <- hdf5 only on ppc all other archs ok | 06:26 |
doko | lamont: tausq did just email me: | 06:27 |
doko | fyi gcc-4.0 is significantly broken for hppa until #22051 | 06:27 |
doko | (gcc bugzilla) is fixed.... | 06:27 |
lamont | as in I should turn off the autobuilder until it is? | 06:27 |
doko | your decision, you're the port maintainer :) | 06:31 |
doko | forwarding the mail ... | 06:31 |
=== elmo_ [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain | ||
lamont | doko: we already switched to 4.0 for breezy, though..... Time to go find out what "significantly broken" means | 06:38 |
doko | lamont: we did? ;) yes, sure, we have to. | 06:42 |
lamont | jbailey: you around? | 09:33 |
jbailey | lamont: Yup | 09:36 |
lamont | why did we disable glibc test suite for hppa (besides "because lamont said to") | 09:36 |
lamont | (see #parisc) | 09:36 |
lamont | doko: still awake by chance? | 10:27 |
doko | it's 10:30pm | 10:27 |
jbailey | lamont: We're Canonical employees, we're not permitted sleep. | 10:27 |
lamont | is our gcc-4.0 built using gcc-4.0? | 10:28 |
doko | no | 10:28 |
doko | 3.3 | 10:28 |
=== lamont hugs doko | ||
doko | you're talking on #paris? | 10:29 |
lamont | yes | 10:29 |
lamont | uh.... | 10:29 |
lamont | gcc-4.0 does not Build-Depend: gcc-3.3 | 10:30 |
doko | gnat-3.3 | 10:30 |
lamont | no, I meant gCC-4.0 | 10:30 |
=== lamont is trying to work around the gcc-bug | ||
lamont | 22051, that is | 10:31 |
doko | gcc-4.0 b-d on gnat-3.3. gnat-3.3 depends on gcc-3.3 | 10:31 |
lamont | ah, ok | 10:31 |
lamont | and how does the build invoke gcc to build things? the only place that the string 'gcc-3.3' appears in the log file is in a Conflicts... | 10:31 |
doko | gnatgcc | 10:32 |
lamont | how, um, bizare | 10:32 |
lamont | so we know that no gcc-4.0 compiler is used in the building of gcc-4.0, right? | 10:32 |
lamont | er, that is: so we know that no -4.0 compiler is used in the building of gcc-4.0, right? | 10:33 |
doko | correct. unless you disable ada | 10:35 |
lamont | which hppa doesn't? | 10:35 |
doko | which server was #parisc on | 10:35 |
doko | no | 10:35 |
doko | but I should make it more robust and use gcc-3.3 explicitely. | 10:36 |
=== lamont nods | ||
doko | or 3.4 ... | 10:37 |
doko | so, what did you find out? | 10:37 |
jbailey | doko: #parisc is on oftc | 10:44 |
jbailey | (god, I almost said efnet for a sec...) | 10:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!