[01:13] jbailey, lamont: gcj-4.1 on dapper shows 500 test failures in libjava, not seen in current unstable. [01:13] see chinstrap:~doko/gcj-4.1* [01:14] nearly all interpreted test cases fail === doko [n=doko@dslb-088-073-092-101.pools.arcor-ip.net] has joined #ubuntu-toolchain === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain [04:55] jbailey: in which ways differ the stack unwinding bits in glibc in unstable and dapper on hppa? === doko wonders why lamont is not grumbling anymore ... [05:40] doko: Eh? No idea off hand. [05:40] AFAIK, everything's sync'd now. [05:42] jbailey: so what did doko break in gcj-4.1 then? :-) [05:44] just verified, that the same source works on unstable, but not dapper. so either lamont did touch the kernel, or jbailey glibc ;-) [05:45] hrm.. could signals compatibility be part of it? [05:54] lamont: maybe, the stacktrace I did send, started somewhere in the garbage collector [07:32] hrm [07:37] jda cannot reproduce it either, but maybe my chroot is corrupt [07:38] your dapper chroot, or your sid chroot? [07:38] dapper [07:41] it's possible that dapper will debootstrap from ports.u.c right now... [07:52] lamont: Well, the chroots are completely built with packages from ports.u.c now, if that's any consolation. debootstrap *should* work. [07:54] infinity: cool [07:54] yeah - it was more a question of the transient nature of things while it's playing catchup [07:55] lamont: No, I meant I *just* rebuilt the hppa chroot with ports.u.c, like, an hour ago, so really, it SHOULD work. :) [07:55] oh, rock. [07:56] Nothing toolchain-wise is coming from rockhopper anymore, just some -desktop stragglers. [07:56] I hope to turn off the rockhopper repo completely in a day or two, once GNOME is fully bootstrapped again. [07:57] (It was a big help, BTW, thanks...) [08:05] n ice [08:05] well, when debhelper isn't installable, life just isn't fun [08:06] Generally not, no. [08:06] GNOME's bootstrapping issues are just as un-fun, when you're behind too. [08:07] Took me a week to untangle ia64, so the fact that hppa Just Works (because it was mostly up to date, and just building new versions againast themselves) was a big help. [08:07] Heck, even powerpc needed untangling, and it wasn't "broken" to start with. Boy, I love new GNOME versions. :) [08:33] jbailey: ping [08:34] jbailey, lamont: it's missing glibc patch [08:34] doko: coolness. [08:42] doko: If it's a straighforward patch that's in Debian already, smack it at Malone, and I can apply it. [08:42] doko: In theory, jbailey's backing off glibc maintenance... In theory. :) [08:43] infinity: currently building on hppa ... [08:46] wondering why jbailey did rename all the debian patches ... [08:48] Patch reorg, meant to get pushed back to Debian, hasn't been yet. I need t odiscuss it with some Debina folk. [08:48] Debian, too. [09:12] lamont: how can I ask about libunwind on ia64? [09:12] s/how/who/ [09:12] should stop for today ... [09:45] doko: can you tell me which patch, and I'll upload a new glibc (or even check with jbailey...) [09:45] libunwind... hrm... [09:46] lamont: chinstrap:~doko [09:47] eh-frame-pointer [09:55] doko: uh... ENOFILE [09:57] on chinstrap? [10:24] doko: yeah - was looking on chinstrap in ~doko [10:25] no file named 'eh-frame-pointer' [10:25] nor anything named *-frame-pointer* anywhere under ~doko [10:25] infinity: They've basically agreed to it. I need to switch us to quilt first. [10:25] lamont: glibc* [10:26] ah, the diff of glibc. got it [10:27] doko: and that diff/dsc are uploadable? [10:27] rather, they have that fix, and just that fix? [10:27] and we know it'll fix things. [10:27] ? [10:29] lamont: my build is still running, currently rebooting m yi386 machine witht this glibc, please don't be IMPATIENT! [10:29] ah, ok. [10:30] doko: I'll let you/jbailey work it out, no hurry here [10:31] yes, I will ask jbailey before uploading ... [10:31] doko: Yeah yeah sure. Just don't break other things ;) [10:31] My pending glibc uploads are all for various -updates. [10:31] Thinking of which, they've probably finished by now. [10:31] btw: lamont: [10:32] lamont: who can I ask about libunwind on ia64? [10:32] So hmm. [10:32] jbailey: for dapper as well? [10:32] Should I put out a call for testers of the new glibc for warty/hoary/breezy, or should I do the usual chroot test and upload it if it works? =) [10:32] doko: No. Dapper already has the fix. [10:33] doko: mossberger seems to be the consensus [10:34] ok [10:35] jbailey: who do you ask? there are not many people on the channel? [10:37] Who do I ask for what, sorry? [10:38] Should I put out a call for testers of the new glibc for warty/hoary/breezy, or should I do the usual chroot test and upload it if it works? =) [10:39] Oh, I see. [10:39] or maybe that was a rethoric question [10:39] More talking to myself but announcing it in case someone had an opinion. === lamont considers saying "just don't break other things :-)" [10:41] Well, that's more what I'm worried about here. [10:41] Since it's a timezone update and we haven't done one of those before, I can't guess what it might break. [10:41] It *should* be nothing. [10:41] ok, i386 did survive the eh-framepointer reboot [10:43] oh. that fix [10:45] xgcc: Internal error: Segmentation fault (program as) [10:45] that'd be breezy-security's gcc-3.4 on hppa [10:47] lamont: try to configure dash as sh on hppa and see some nice segfaults building glibc [10:51] I see [10:52] the normal medical suggestion in such a situation is "don't do that, then" [11:02] doko: re libunwind - have you tried pinging the pkg maintainer/ [11:02] >? [11:05] hmm, no, it's more the gcc related patches that fc and opensuse has [11:05] still, I think the debian maintainer is probably well connected to upstream... [11:06] and therefore a reasonable resource to involve in the search