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