[12:15] \sh: ?? what do you want to know? [01:14] doko: I don't care, really. === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === doko [~doko___@dsl-082-082-206-179.arcor-ip.net] has joined #ubuntu-toolchain [07:15] hey doko [07:17] 13461 sparcbui 25 0 233m 231m 2304 R 82.2 46.3 12:56.52 ld [07:17] this is the call that makes gcc-4.0 build hangs forever :) [07:17] building libgcj 6 something [07:26] That's no surprise. [07:27] hey infinity [07:27] infinity: i need your help to debug the kernel failure on i386 [07:27] because i cannot reproduce it here [07:28] or better... on concordia i386 [07:28] it just builds fine [07:29] infinity: would it be an option for you to bootstrap a buildd chroot (breezy), update it to death and rebuild? [07:29] i wonder if one of the build-deps (like binutils or so might be old) [07:29] Hrm, same failure on two different buildds is suspicious though. [07:30] infinity: still doesn't explain why it's ok here, on concordia and zul machine [07:30] Also, if you really need a versioned build-dep on specific toolchain packages, you should depend on them (but sbuild prints a header telling you whwt was used) [07:30] infinity: the point is that if it's a toolchain problem, i wasn't aware of it [07:31] i did bump the problem build-deps to my knowledge [07:31] binutils_2.15-6ubuntu1 [07:31] That's the latest. [07:32] Version: 2.15-6ubuntu1 [07:32] same on concordia [07:32] I'll see if the chroots look goofy, but I can't immediately see why they would be (on two machines) [07:32] ok [07:32] Given that this only happens in the -dbg build, I'd guess it's an obscure missing build-dep, not a bad version. [07:32] (ie: something the kernel needs to build the debug stuff, but you didn't know it) [07:33] infinity: note that 386-dbg is built successfully before the failure (686-dbg) [07:33] Oh, neat. Kay. [07:33] so the build deps are there [07:36] Should I actually look at the ksyms and see HOW they're inconsistent? :) [07:36] (Assuming the build dir hasn't been purged...) [07:37] infinity: that would be an option [07:37] my build on concordia is still all there [07:37] so we can actually compare the stuff [07:37] Oh, which it has. lamont has sbuild configured to always purge. [07:37] Meh. [07:38] infinity: well i guess it's time to do a manual build.. isn't it? [07:38] Yeahp. This is why I wish REDO worked. :) [07:40] Hrm. I wonder if ccache could be to blame. [07:40] Did you use ccache in your local build? [07:40] yes [07:40] Anyhow, copying a test chroot that should be identical to the one used for the failed build on terranova and will test a manual build in a sec. [07:41] great [07:41] I'm really hoping the manual build fails. [07:41] so do i [07:41] If it doesn't, I don't look forward to the debugging. [07:44] I can find this problem on Google in the ARM build... Not very helpful. :) [07:45] nope :) [07:50] Hrm, these chroots don't seem all thayt minimal to me... === infinity puts that on his list of things to look at. [07:57] infinity: REDO does work.. .but takes 3 args (3rd is component) [07:58] and the chroots do occasionally wind up polluted since things don't like to purge... the new infrastructure throws the chroot away each time [07:58] (and we always purge, because we don't like to run out of disk space... that's bad...) [08:04] lamont : Ahh, you originally toldme REDO didn't work at all, I hadn't had a chance to look at how it was currently working. [08:05] well, replying 'retry' doesn't work. manually saying 'echo foo_1.1 breezy universe >> build/REDO' does [08:05] anyway - I should be in bed [08:09] lamont: good night :) [08:12] 'Night. :) === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain === doko [~doko___@dsl-084-059-046-215.arcor-ip.net] has joined #ubuntu-toolchain [02:04] doko : Around? [02:04] doko : Do I need to start removing some packages from Not-For-Us? [02:08] infinity: what is the current state of the list? [02:09] I updated frozenapps.txt yesterday [02:13] Oh, fun. [02:13] Any way to get a diff between the frozenapps of last week and this new one? :) [02:14] (Maybe I have a copy somewhere... Lemme see) [02:21] infinity: sorry, don't have a diff/the old one [02:22] infinity: just diff n-f-u vs the list? [02:22] the only thing in n-f-u should be frozenapps [02:31] Oh, good point. It doesn't actually get used normally, does it? :) [02:33] elmo : If I --forget something, will cron.daily revive its correct status on the next run, asi expect it to? [02:37] infinity: I imagine so, yes [03:39] elmo : Can you process libccscript's NEW binaries? [03:39] katie@jackass:~$ helena [03:39] katie@jackass:~$ [03:40] infinity: see my whining about ntp in #u-d [03:43] Does thet helena output mean "I did it already", or "there were no NEW binaries, dumbass"? [03:44] either, take your pick [03:44] ;) [03:46] (first, IIRC) [03:50] Yeah, --forget and cron.daily get along just fine. Yay. The turnaround time for that trick is much faster than with Debian too, thank god. [04:04] I can always tell when fabbione's packages are building [04:04] 4 of the buildds start yellow-lining on nagios :-P [04:49] <\sh> starnge [04:49] <\sh> strange even [04:49] <\sh> on the buildds libccrtp fails at one point, but in my local breezy pbuilder it doesn't fail [04:50] elmo: Doesn't gcc and glibc give nagios the same heartburn? === lamont__ [~lamont@15.238.5.47] has joined #ubuntu-toolchain [04:54] jbailey: if they make -j as much as fabbione does, probably yeah [04:54] it's a tiny tiny percentage of packages that do thi [04:56] Right now it only make -j's the number of CPUs. [04:56] I keep meaning to make it 2n +1 when the cpus > 1 === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [10:32] elmo: ahhaha "fabbione: the nagios anal penetrator!" [10:32] ;) [10:35] good night guys [10:35] cya in few hours === \sh [~shermann@server3.servereyes.de] has left #ubuntu-toolchain ["And]