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