[02:08] <lamont> moo
[02:09] <lamont> so where am I at now?
[02:09] <lamont> should I be using chinstrap:~doko/uploads?
[04:56] <zul> i just love gcc4 "warning: statement with no effect"
[04:57] <daniels> that's not just gcc4
[04:57] <zul> ok
[04:57] <daniels> put 'foo == bar;' into gcc2 and it will say the same thing
[04:57] <zul> ah...
[05:00] <zul> its something in jffs2
[08:44] <fabbione> morning
[10:07] <\sh> guys, all cxx trans bugs which r uploaded and compiled successfully on all archs..can I close them?
[10:07] <\sh> (at least my bugs ;))
[10:54] <fabbione> jbailey: we need to recheck the linking stuff we worked on yesterday, because it introduced some lintian errors;
[10:54] <fabbione> E: rhcluster: shlib-with-non-pic-code usr/lib/libgulm.so.0.0
[10:54] <fabbione> E: rhcluster: shlib-with-non-pic-code usr/lib/libmagmamsg.so.0.0
[10:54] <fabbione> E: rhcluster: shlib-with-non-pic-code usr/lib/libmagma_nt.so.0.0
[10:54] <fabbione> E: rhcluster: shlib-with-non-pic-code usr/lib/libmagma.so.0.0
[10:55] <fabbione> well.. lintian.. just errors :)
[10:55] <fabbione> and adding -fPIC seems not to be the right solution
[10:57] <fabbione> or at least it's not enough...
[04:16] <svenl> jbailey: please try out the kernel found here : 
[04:16] <svenl>   http://people.debian.org/~luther/ppc64
[04:28] <jbailey>  short read in buffer_copy (backend dpkg-deb during `./lib/modules/2.6.11-pseries/kernel/fs/lockd/lockd.ko')
[04:28] <jbailey> Any idea what that means?
[05:25] <jbailey> gcc-4.0 seems to have gotten rid of __uint128_t support, hmm.
[05:25] <jbailey> That's the cause of the gdb failure.
[05:27] <jbailey> Oy.  glibc mainline uses;
[05:27] <jbailey> typedef struct {
[05:27] <jbailey>   unsigned int u[4] ;
[05:27] <jbailey> } __attribute__ ((aligned (16))) elf_vrreg_t;
[05:35] <jbailey> lamont: ping
[06:51] <svenl> jbailey: huh ?
[06:51] <svenl> let me install it here.
[06:52] <svenl> jbailey: what glibc are you using ? 
[06:53] <svenl> jbailey: installed fine here. .../source is double, but apart from that it is ok.
[06:54] <svenl> jbailey: it did install without problems.
[07:25] <fabbione> jbailey: well the error comes only after we changed the linking method :)
[07:25] <fabbione> it was working before ;)
[07:25] <fabbione> svenl: thanks for the patch
[07:26] <fabbione> jbailey: but i think we have been attacking a little bug with a huge bottle of spray
[07:26] <fabbione> apparently there is not even a reason to build 64 bit libs :/
[07:26] <fabbione> but i will need to ask waldi why he did it in the first place (problably due to clvm...)
[07:38] <svenl> fabbione: 64bit libs -> not ppc64 kernel related ? 
[07:40] <fabbione> no
[07:40] <fabbione> nothing to do with that
[07:40] <fabbione> sparc64 :)
[07:40] <fabbione> anyway.. time to cook dinner
[10:28] <lamont> jbailey: ack
[10:31] <jbailey> lamont: heya - wanted to check with you on the ppc64 stuff.  I have a fix for glibc that lets gdb build again.
[10:31] <jbailey> (ppc, gcc-4 bug)
[10:31] <jbailey> lamont: I've lost track if where we've gotten to, and I don't want to interfere with it.
[10:33] <lamont> jbailey: where we're at is that if you have a glibc that I should use instead of what I have for the bootstrap, getting it to me within the next hour would be wonderful.
[10:33] <jbailey> lamont: I'd rather just wait it through.
[10:33] <lamont> there were some issues - I'll fire off both builds in about an hour before I go to the movies, and then hopefully be able to upload your changes and push the real build when I get back
[10:33] <lamont> jbailey: that's fine too
[10:34] <lamont> jbailey/doko: just so both of you have _source.changes for your source, I'll go ahead and upload it once PPC is primed and ready for the actual source upload
[10:34] <lamont> which should be in ~6-8 hours or so
[10:34] <jbailey> Nice. =)
[10:35] <jbailey> Good rest, LaMont.
[11:11] <doko> lamont: updated package (same version) on chinstrap:~doko/uploads
[11:42] <lamont> doko: roger
[11:46] <lamont> build launched.  movie-bound.  back in 3-4 hours