 Assembler messages:
4: Warning: Empty argument of .endp
4: Warning: `__syscall_error_4' should be an operand to this .endp
[12:02] <jbailey> I wonder if that's new (for ia64)
[05:52] <fabbione> doko:
[05:52] <fabbione> checking LIBART_LIBS... -lart_lgpl_2  
[05:52] <fabbione> checking for XTestQueryExtension in -lXtst... no
[05:52] <fabbione> configure: error: libXtst not found, required by java.awt.Robot
[05:52] <fabbione> gcc-snapshot on sparc ^^
[05:52] <fabbione> _20051118-0ubuntu1
[05:58] <fabbione> doko: sparc is building gcc-4 and gcc-3.. if they are not FTBFS you are good go ;)
[05:58] <fabbione> later
[07:34] <infinity> doko : On ia64 and powerpc, gcc-4.0 gets this:
[07:34] <infinity> checking for X... no
[07:34] <infinity> *** xlib peers requested but no X library available
[07:34] <infinity> make[3] : *** [configure-target-libjava]  Error 1
[09:23] <doko> infinity: nice, do you know why?
[09:25] <doko> infinity: on i386 and amd64 as well?
[12:35] <infinity> doko : No, i386 and amd64 built fine, just ppc and ia64 choked.  I'll rety them in a bit to see if it was a transient build-dep issue.
[12:37] <infinity> Oh, wait.
[12:37] <infinity> Did I need a specific newer version of something that might be stuck in the chroots?
[12:38] <infinity> Nevermind, the chroots are up to date anyway.
[12:41] <doko> it's strange, that the generice test for X fails. please keep the build, so you have a look at the config.log file
[12:41] <infinity> Meh.  Too late to keep the build, already started it.
[12:42] <infinity> (sbuild on our buildds is configured to remove failed trees, so we don't eat disk insanely)
[12:42] <infinity> But if it fails again, I'll muck with it again and keep the tree.
[02:47] <Riddell> doko: so libstdc++ transition has happened?
[02:48] <doko> Riddell: no, no powerpc packages yet
[02:49] <Riddell> doko: so I shouldn't start uploading?
[02:57] <doko> no
[02:59] <jbailey> doko: What's blocking PPC?
[03:06] <doko> a strange build failure, no X found. infinity is currently rebuilding
[03:09] <jbailey> Feh, I hope it's not some part of the X transition.
[03:09] <jbailey> I have ppc and amd64 building.  i386 and ia64 fail for glibc right now.
[03:09] <jbailey> I'll be back to hacking on that in an hour or so, I think.
[03:15] <doko> X transition?
[03:26] <jbailey> To modular X, blocked by glibc.
[03:39] <infinity> doko : Around?
[03:42] <infinity> doko : conftest.c:23:27: error: X11/Intrinsic.h: No such file or directory
[03:47] <doko> that's in libxt-dev? 
[03:47] <infinity> In theory.
[03:48] <doko> strange that his breaks on only two architectures
[03:48] <fabbione> it might as well be that the other 2 chroots are dirty :)
[03:49] <infinity> They're not.
[03:49] <infinity> I already checked that.
[03:49] <doko> fabbione: but then, my own chroots are dirty as well
[03:49] <infinity> I wonder if another -dev lib used to depend on libxt-dev, and your upload happened at just the right time to catch that changing.
[03:50] <fabbione> doko: we all know you like "dirty" stuff :P
[03:50] <fabbione> is that only on gcc-4.?
[03:50] <fabbione> or also 3.4?
[03:51] <doko> no, 3.4 doesn't build java
[03:51] <fabbione> i saw that error yesterday on -snapshot
[03:51] <fabbione> (pasted the log here)
[03:51] <fabbione> on sparc
[03:51] <infinity> I blame GTK.
[03:52] <infinity> Anyhow.
[03:52] <infinity> doko : Your configure test explicitely includes that header (it's not pulled in through a transient dep in another header), so you may as well just build-dep on libxt-dev and call it a day.
[03:53] <jbailey> I like how even GCC can say "Iz gtk bug" and possibly be right.
[03:53] <doko> :)
[03:53] <doko> infinity: that configure test comes directly from autoconf ...
[03:54] <infinity> doko : And autoconf is wrong, because it assume a monolithic X, but whatever.  One battle at a time. :)
[03:54] <infinity> I believe changes are going into autoconf upstream to make the X tests more correctly modular.
[03:55] <doko> ok, thanks for figuring that out ...
[03:56] <infinity> Can you upload ASAP, or should I just pre-seed the chroots with xt-dev and rebuild?
[03:58] <doko> uploading now ...
[03:59] <fabbione> doko: you also want to reupload gcc-snapshot
[03:59] <fabbione> for the same reason
[03:59] <doko> fabbione: not now ...
[03:59] <infinity> It's hardly urgent.
[03:59] <fabbione> fabbione doko:
[03:59] <fabbione> fabbione checking LIBART_LIBS... -lart_lgpl_2  
[03:59] <fabbione> fabbione checking for XTestQueryExtension in -lXtst... no
[03:59] <fabbione> fabbione configure: error: libXtst not found, required by java.awt.Robot
[03:59] <fabbione> fabbione gcc-snapshot on sparc ^^
[03:59] <fabbione> fabbione _20051118-0ubuntu1
[03:59] <fabbione> fabbione doko: sparc is building gcc-4 and gcc-3.. if they are not FTBFS you are good go ;)
[03:59] <fabbione> no
[03:59] <fabbione> just FYI
[03:59] <infinity> xtst-dev != xt-dev
[03:59] <infinity> If Java really needs xtst-dev too, you just found another build-dep. :)
[04:00] <doko> no, that's something else. xtst-dev is needed for something called JavaRobot
[04:03] <doko> but it's interesting, that the build did succeed on i386 and amd64
[04:04] <infinity> Oh, cock.
[04:04] <infinity> doko : Do you disable logwatch on ubuntu, or is it just breaking?
[04:05] <infinity> doko : gcc-3.4 on ia64 timed out in the testsuite.
[04:05] <doko> no, it was never enabled on ia64
[04:06] <infinity> Ahh.  I assumed it was enabled on all arches.
[04:06] <infinity> Silly me.
[04:07] <infinity> Maybe if it was, the odd bugs with it occasionally hanging would have been found sooner. :)
[04:07] <infinity> (I still need to look into that some day... I had to kill logwatch on kullervo the other day for gcc-3.4... And lamont had to kill it on hppa, I think)
[04:09] <lamont-away> infinity: this time I just had to kill of an expect from 3.4
[04:09] <lamont-away> interesting... said find started after findutils sbuild started.
[04:09] <infinity> Ahh.
[04:10] <infinity> ARGH.
[04:10] <infinity> buildd-watcher on floe is racing AGAIN.
[04:10] <infinity> Why just floe?  Have you hand-hacked something there?  <stafre>
[04:10] <infinity> s/starfe/stare/
[04:10] <lamont-away> not to the best of my knowledge...
[04:11] <infinity> Same buildd-watcher as on hooker...

[04:12] <infinity> I'm going to shut down the buildd on floe for now, and look into it tomorrow when my plate's not so full.
[04:12] <infinity> Having several buildds running and competing with each other for chroots is kinda.  Uhm.  Bad.
[04:13] <infinity> (Yes, that happened earlier today)
[04:13] <infinity> Though right now, we only seem to have one buildd/sbuild, thankfully.  Many buildd-watchers, though.
[04:13] <lamont-away> buildd-watcher backs up sometimes, yes.
[04:14] <lamont-away> there might be a window where it assumes that it's find (build-tree cleaning/reporting, etc) will finish before another buildd-watcher starts.
[04:14] <lamont-away> this is not always the case...
[04:14] <fabbione> hey lamont-away 
[04:15] <infinity> Oddly enough, this never seems to happen on m68k, despite my running buildd-watcher several times per hour and having really, really, really slow I/O.
[04:15] <infinity> I guess I should check your diffs against Ryan's tree.
[04:17] <infinity> doko : I see you're getting pressure from vorlon for the system compiler split.
[04:17] <infinity> (or, at least splitting java out)
[04:18] <infinity> doko : You really should have put it in big blinking letters in your toolchain roadmap so you could do it on paid time.  It's totally justifiable for Ubuntu as well.
[04:21] <doko> infinity: it should be in JavaRoadmap
[04:24] <elmo> infinity: our insane number of distros doesn't help, most m68k buildds only have one chroot to traverse
[04:24] <elmo> at least, whenever I look at a buildd they tend to sit their in io wait for a rather pointless find over the chroots
[04:24] <infinity> elmo : Well, 6.
[04:25] <infinity> But yeah, we have more than 6.
[04:26] <jbailey> What's happening with a core compiler split?
[04:27] <elmo> ?
[04:28] <doko> gcc-4.0 sucks in the whole archive as b-d's while completing libgcj  ...
[04:28] <doko> jbailey: and even in ubuntu it would be nice to get rid of the x dependencies, as you can see
[04:29] <fabbione> jbailey: i think it all goes back to modular gcc...
[04:29] <fabbione> that i did propose not too long ago to $icantrememberwhoinhere
[04:29] <infinity> Ah-ha.
[04:30] <infinity> lamont : I'll fix the "buildd-watcher takes too effin' long" bug tomorrow when I have time to test it.
[04:30] <doko> fabbione: I can't remember, did you?
[04:30] <infinity> But it's pretty obvious.
[04:30] <infinity> Original code:
[04:30] <fabbione> doko: i don't think it was to you actually
[04:30] <infinity>         next if $file =~ m#^build/chroot-[^/] +$#;
[04:30] <fabbione> doko: more likely jbailey 
[04:30] <infinity> Ours kinda.  Uhm.  Doesn't do that.
[04:30] <elmo> hahaha
[04:30] <elmo> more to the point ours doesn't match 'build/'
[04:30] <infinity> Stupid build-* split.
[04:31] <infinity> elmo : Yes, we explicitely name all the build-$DIST targets in ours... Then don't exclude the chroots.
[04:31] <infinity> I'd blame lamont, but this is a public channel, and I'm a nice person.
[04:31] <infinity> Oops, gthat was my out loud voice. :)
[04:31] <infinity> s/gthat/that/
[04:31] <fabbione> ahaha
[04:32] <lamont-away> infinity: oops. :)
[04:32] <lamont-away> infinity: sigh
[04:33] <infinity> I'll fix it tomorrow.
[04:33] <lamont-away> was that in our original base, or just merged in from upstream?
[04:33] <infinity> For bonus points, I'll actually run a full watcher run, with no report-ed-old-files cache and actually clean everything up, so I can stop ignoring cron's whining.
[04:34] <lamont-away> ok
[04:34] <infinity> Heh, but if chroot is properly ignored (and ~/ccache as well), that's a non issue.
[04:34] <infinity> elmo : floe should stop setting off alarms for you.
[04:35] <infinity> Though I'm curious why floe is the only one that races this badly.  Either it has one mother of a huge chroot somewhere (that should be removed and rebuilt), or something's desperately wrong with that box.
[04:36] <infinity> I'm going to assume the former, cause it seems well behaved otherwise.
[04:36] <lamont-away> fwiw, pitti picks really ugly version numbers
[04:37] <lamont-away> inkscape_0.42-1build1ubuntu0.1 is now in breezy-security
[04:37] <infinity> foo_1.2.3-1ubuntu05.10?
[04:37] <infinity> Oh, eww.
[04:37] <lamont-away> 'zactly
[04:38] <infinity> Someone should point out to him that 'u' is higher than 'b'.
[04:38] <elmo> did you guys get my mail about b-backports btw?
[04:38] <elmo> [nb: I'm not chasing, I don't care when it's done, just checking] 
[04:38] <lamont-away> elmo: when did you send it?
[04:38] <infinity> elmo : Yes, and I'll enable it tomorrow, if the world doesn't come to an end first. :)
[04:39] <lamont-away> there it is
[04:39] <elmo> infinity: kthx
[04:39] <infinity> Unless lamont feels the urge.
[04:39] <fabbione> can't we forget about -backports by ... let say.. mistake?
[04:40] <fabbione> i mean
[04:40] <fabbione> that would comply with the specs
[04:40] <lamont-away> infinity: I'll go ahead and create the chroots - that's the easy part.
[04:41] <lamont-away> then it should autostart when the nightly chroot update runs
[04:41] <fabbione> quoting: https://wiki.ubuntu.com/BackportsPromotion
[04:41] <infinity> Such faith you have in your automated tools.  I like it.
[04:41] <fabbione> "Make people more aware of backports, and make the backport request process LESS transparent"
[04:42] <lamont-away> adare is now launchpad, yes?
[04:42] <fabbione> i can't see anything more hidden than not creating the chroots ;)
[04:42] <infinity> lamont-away : In theory.  Not sure it's being used as such, but it's definitely not hooked into w-b either.
[04:42] <infinity> fabbione : Hah.  Nice thinko.
[04:43] <fabbione> infinity: when i read that at UBZ i was >< this close to approve the specs :D
[04:43] <infinity> Sadist.
[04:43] <fabbione> oh yeah
[04:44] <fabbione> I LOVE TO SEE PEOPLE SUFFER IN ENDLESS PAIN
[04:44] <infinity> What I wouldn't give for a nasty case of narcolepsy in my old age.
[04:45] <infinity> Man, HP really makes you start at the bottom of the ladder when you're a new hire again, don't they? :)
[04:58] <lamont-away> elmo: chroots are created everywhere
[04:58] <lamont-away> infinity: nah - this is house work... and the more I procrastinate, the deeper the sludge in the tank.  Hence, todya
[04:59] <lamont-away> the damage was discovered friday when the nice people pumped the tank for me.
[04:59] <lamont-away> but I fear I shall be buying hip-waders before the day is out.
[05:00] <infinity> And throwing them out tomorrow.
[05:00] <lamont-away> nah - you just put trash bags on them first. :-)
[06:53] <Riddell> infinity: are you going to upload subversion with new libdb ?
[06:58] <doko> Riddell: he has to ... it's not buildable otherwise
[06:59] <Riddell> and neither is large chunks of KDE
[09:34] <lamont-away> checking for XTestQueryExtension in -lXtst... no
[09:34] <lamont-away> configure: error: libXtst not found, required by java.awt.Robot
[09:34] <lamont-away> interestingly, libxt-dev is in build-depends
[09:45] <doko_> lamont-away: which architecture?
[10:04] <lamont-away> that was -2 on ppc
[10:05] <lamont-away> is -3 the end of it?
[10:43] <fabbione> i told ya that we needed more :)
[10:43] <fabbione> gcc-snapshot rules!
[10:45] <fabbione> doko: still around?
[10:59] <doko> fabbione: yes
[10:59] <fabbione> doko: ok-- gcc-4.0 is going to build in 10/15 minutes of sparc
[10:59] <fabbione> 3.4 is up
[11:00] <fabbione> do we need gcj before we start the transition?
[11:00] <doko> no
[11:00] <doko> hmm, but gettext depends on it ...
[11:00] <fabbione> is gettext a pkg that needs transition?
[11:03] <fabbione> well i guess it's going to stall the others
[11:04] <fabbione> we will see tomorrow
[11:04] <fabbione> doko: thanks for the info
[11:04] <fabbione> i am off to sleep
[11:04] <doko> no, it doesn't need a transition, but a working libgcj
[11:04] <fabbione> ok
[11:06] <lamont> gcc-4.0 (-3) will start building on hppa momentarily
[11:08] <doko> note that I did separate the build of the gcj packages into a separate source package, so you need to build that as well. that's currently stuck in NEW
[11:09] <lamont> can we get that unstuck please?
[11:09] <lamont> or does that not need to happen before the transition starts?
[11:09] <lamont> avg-pkg-build-time gcc-4.0
[11:09] <lamont> gcc-4.0:                06:31:36 (3 entries, sigma 00:46:59)
[11:11] <doko> the build time will drop, it doesn't build java anymore