[06:13] <fabbione> morning
[06:33] <fabbione> infinity: ping?
[06:34] <fabbione> lamont: ping?
[07:06] <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:07] <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:08] <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:09] <lamont> more ~buildd/stats/Summary
[07:09] <fabbione> there is no Summary :)
[07:10] <lamont> dunno why I have one then
[07:10] <fabbione> some of your scripts generate it?
[07:11] <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:12] <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:13] <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:14] <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:15] <lamont> since some of the slower debian architectures have been using it at least in the past
[07:16] <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:17] <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:18] <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] <fabbione> good night lamont
[07:19] <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:22] <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:23] <fabbione> i miss usb-modules, pcmcia* and nic*
[07:23] <fabbione> the latter is a real pain :(
[07:25] <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:26] <infinity> Could be handy to get RIGHT NOW, DAMNIT security builds without runinng a second buildd.
[07:30] <fabbione> infinity: it can't be that hard to implement
[07:30] <fabbione> but i am hounestly far away motivated to do so
[07:31] <fabbione> or given a good design
[07:31] <fabbione> get sbuild to understand the concept of target chroot
[07:32] <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:33] <fabbione> can't be that hard
[07:33] <infinity> I think all you really need here is target locking.
[07:34] <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:35] <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:36] <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:37] <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.

[09:58] <fabbione> elmo: did you already setup logs@u.c ?
[09:59] <elmo> fabbione: no
[10:00] <fabbione> 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] <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:50] <\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
[12:29] <infinity> And BAD.
[12:29] <infinity> Also, it's not good.
[03:12] <lamont> fabbione: ppc is known to send spurious SIGILL, not SEGV
[03:15] <jbailey> HPPA on the other hand...
[03:18] <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:19] <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:20] <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:23] <lamont> otoh, your ada-test-b0rkage-killer seems to work fine
[03:29] <doko> hmm, but somebody reported something with the acats-killer ...
[04:41] <lamont> wow.  after killing all those doko-be-damned SyncTest.exe's, gcc-4.0 may actually finish building (it's installing now)
[04:54] <lamont> Subject: Log for successful build of gcc-4.0_4.0.0-8ubuntu3 (dist=breezy)
[04:55] <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:59] <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.
[06:23] <lamont> wow. binutils wants 7 min on i386, 21 on ia64, and 94 on hppa.  WTH?
[06:23] <lamont> 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] <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:31] <doko> your decision, you're the port maintainer :)
[06:31] <doko> forwarding the mail ...
[06:38] <lamont> doko: we already switched to 4.0 for breezy, though.....  Time to go find out what "significantly broken" means
[06:42] <doko> lamont: we did? ;) yes, sure, we have to.
[09:33] <lamont> jbailey: you around?
[09:36] <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)
[10:27] <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:28] <lamont> is our gcc-4.0 built using gcc-4.0?
[10:28] <doko> no
[10:28] <doko> 3.3
[10:29] <doko> you're talking on #paris?
[10:29] <lamont> yes
[10:29] <lamont> uh....
[10:30] <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:31] <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:32] <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:33] <lamont> er, that is: so we know that no -4.0 compiler is used in the building of gcc-4.0, right?
[10:35] <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:36] <doko> but I should make it more robust and use gcc-3.3 explicitely.
[10:37] <doko> or 3.4 ...
[10:37] <doko> so, what did you find out?
[10:44] <jbailey> doko: #parisc is on oftc
[10:44] <jbailey> (god, I almost said efnet for a sec...)