[05:47] <lamont> doko: hppa's toolchain has an issue or 23
[05:47] <lamont> gcc -shared -Wl,-soname,libz.so.1 -lc -o libz.so.1.2.3 adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infback.o inftrees.o inffast.o
[05:47] <lamont> using 3.4
[05:47] <lamont> produces a .so that has _GLOBAL_OFFSET_TABLE_ defined, which it absolutely should not.
[05:48] <lamont> thoughts?
[07:05] <lamont> doko_: and using 4.0
[07:11] <fabbione> lamont: it's probably binutils fuckage
[07:11] <fabbione> same as sparc and alpha
[07:40] <lamont> fabbione: yeah
[01:01] <doko> lamont, infinity: please fix the i386 buildd, dpkg is segfaulting again :-/ the OOo2 -ubuntu6 build did work, but -ubuntu7 fails again ...
[03:25] <lamont> doko: AFAIK, the cause of dpkg segving is unknown.  OOo2 being the prime example of a package that initiates it
[03:26] <doko> should I file a bug report?
[03:26] <doko> lamont: requeued?
[03:28] <lamont> ISTR there might already be a bug open
[03:29] <elmo> please make sure there is, dpkg sigsev == pain
[03:30] <lamont> elmo: OTOH, it seems to be vernadsky each time...
[03:30] <lamont> so I've stopped buildd there, cleaned the chroot, and given oo.o2 back
[03:31] <lamont> elmo: if you're in the DC, some memtest love on vernadsky might be good
[03:35] <elmo> memtest doesn't work on that machine
[03:37] <doko> elmo, lamont: submitted as 13306 
[03:38] <elmo> or that machine class
[03:40] <lamont> elmo: feh
[03:40] <elmo> yeah, rocks doesn't it
[03:40] <elmo> is it at all reproduceable?
[03:40] <elmo> 'cos we can invoke keybuk's mad debugging skillz, he can probably tell if it's bad memory
[03:41] <lamont> elmo: infinity knows more about it
[03:41] <elmo> ok
[03:41] <lamont> I'm just parroting him on the subject.
[03:52] <doko> lamont: please requeue debhelper (if that helps ...)
[03:53] <doko> You might want to run `apt-get -f install' to correct these:
[03:53] <doko> The following packages have unmet dependencies:
[03:53] <doko>   file: Depends: libmagic1 (= 4.12-1) but it is not going to be installed
[03:53] <doko>         Depends: libmagic1 but it is not going to be installed
[03:53] <doko>   libgl1-xorg-dev: Depends: xlibmesa-gl (= 6.8.2-44)
[03:53] <doko> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
[03:53] <doko> Build environment unusable, giving back
[03:53] <lamont> yeah, it looks to have been a victim of oo.o2
[03:54] <doko> s/oo.o2/dpkg/memory/g
[04:14] <elmo> lamont: btw, ia64's not doing dailies; not sure if you know/care
[04:15] <lamont> elmo: I turned them off, since they're worthless without a kernel
[04:15] <elmo> ok
[06:08] <infinity> The dpkg segv is NOT bad RAM.
[06:08] <infinity> I can reliably reproduce it here on two machines, one ppc32 and one i386.
[06:08] <infinity> And it's happened on several buildds.
[06:09] <infinity> And debugging with Keybuk got nowhere. :/
[06:14] <jbailey> infinity: Is there a nicer testcase than OOo2?
[06:15] <infinity> I have yet to slim it down to a tiny testcase, but you should be able to reproduce it 100% with "debootstrap a clean variant=buildd breezy chroot ; apt-get install libqt3-mt-dev mesag-dev'
[06:16] <infinity> Somewhere along the way, the stack gets hideously smashed, and the backtrace on the core is utterly useless.
[06:16] <infinity> And the assumption that it may be a GCC bug went out the window when I rebuilt with 3.4 and 3.3 (and maybe 2.95 as well, don't recall now) with the same results.
[06:17] <infinity> With any luck, the archive hasn't changed enough since the last time I played to make that testcase invalid.
[06:18] <infinity> (tests now)
[06:19] <elmo> if you need a snapshot  of the archive, let me know - it's important we be able to reproduce this
[06:20] <infinity> I'll let you know when my bandwidth catches up with my brain.
[06:23] <infinity> Yup, that testcase still works smashingly.
[06:23] <infinity> elmo : If you want to snapshot the state of the union as it is right now, it happily segv's.
[07:22] <doko> jbailey, infinity: did you already start bootstrapping the biarch builds?
[07:36] <jbailey> doko: No, I haven't hunted down that g++-4.0 bug yet.
[07:39] <doko> jabiley: we can stop building the lib64stdc++ packages for now, then the bootstrap dance can be done now, and fabbione can build a kernel, when he'S back
[07:40] <lamont> doko/jbailey: any ideas on the _GLOBAL_OFFSET_TABLE_ crap that hppa is seeing with the current binutils and gcc-{3.4,4.0}?
[07:40] <doko> lamont: it's not seen with gcc-3.3 ?
[07:41] <lamont> haven't checked
[07:42] <lamont> and probably won't have time before I leave in the morning... -> next week for me to test things out.
[07:42] <lamont> building zlib produces a bad libz.so.1
[07:43] <lamont> and that's a quick testcase
[07:50] <jbailey> doko: Well, it won't kill bootstrap we could even leave it in, which would let me hand over what I have now I guess.
[07:51] <doko> yes, that would be nice
[10:07] <elmo> lamont/infinity: terranova is back; with a newer kernel
[10:18] <lamont> elmo: woiot
[10:18] <lamont>  /me goes to kick that buildd
[10:24] <lamont> launched