[06:18] <fabbione> morning
[07:04] <jbailey> Heya Fabio
[07:29] <fabbione> hey Jeff
[07:36] <fabbione> scp makediff rookery.warthogs.hbd.com:public_html/rhcluster-make.diff
[07:36] <fabbione> makediff                                                                                                                    100%   52KB  51.7KB/s   00:00    
[07:36] <fabbione> Killed by signal 1.
[07:36] <fabbione> jbailey: are you sure the latest crack is working properly?
[07:36] <fabbione> i am getting a lot of sig 1
[07:37] <fabbione> or probably it's just ssh
[07:37] <fabbione> yeah
[07:37] <fabbione> indeed
[07:37] <jbailey> Which crack?
[07:37] <jbailey> The glibc?
[07:37] <fabbione> i will bug Kamion
[07:37] <fabbione> yeah
[07:38] <fabbione> well i dist-upgraded yesterday
[07:38] <fabbione> so probably it's ssh
[07:38] <jbailey> Which arch?
[07:38] <jbailey> ppc was the only one that got changes, and it just grew ppc64 bits.
[07:38] <jbailey> The biarch configs aren't really associated with one another, so there should be 0 effect.
[07:38] <fabbione> i386
[07:39] <jbailey> Hmm, I don't have a current breezy i386 system.
 i will bug Kamion
[07:39] <fabbione> i think it's only ssh
[07:39] <fabbione> they looked more apps
[07:39] <jbailey> Right, but since I'm here I'm just trying to think my way through whether it's possibly my fault. =)
[07:39] <fabbione> but i realized i was only using a combination of apps with ssh backend :)
[07:40] <fabbione> so with the ppc64..
[07:40] <fabbione> what versions and what b-d do i need to add?
[07:40] <fabbione> for example:
[07:40] <fabbione> Build-Depends: debhelper (>= 4.2.28), gcc-3.4, libxml2-dev, libncurses5-dev, libc6-dev-sparc64 [sparc] , libc6-dev-s390x [s390] 
[07:40] <fabbione> do i need to add libc6-dev-powerpc64 ?
[07:40] <jbailey> libc6-dev-ppc64
[07:40] <fabbione> or something along that line?
[07:40] <fabbione> ok
[07:41] <jbailey> Whatever the current gcc-3.4 is for a versioned dep on that.
[07:41] <jbailey> 3.4.4-0ubuntu4
[07:41] <fabbione> Version: 3.4.4-0ubuntu4
[07:41] <fabbione> rocking
[07:42] <fabbione> # ifneq (,$(findstring $(DEB_HOST_ARCH), s390 sparc powerpc))
[07:42] <fabbione> :)
[07:42] <fabbione> anyway the biarch build of rhcluster is disabled
[07:42] <fabbione> because of the linking issue
[07:42] <jbailey> *lol*
[07:42] <jbailey> Just easiest for now?
[07:42] <fabbione> i couldn't figure out why it fails
[07:42] <fabbione> jbailey: as soon as i have the package in archive, we can work on it officially
[07:43] <fabbione> since there will be ppc binaries :P
[07:43] <jbailey> Right.
[07:43] <fabbione> or since we should fix it for ppc64... we perhaps can do it before hand
[07:43] <fabbione> using sparc for testing...
[07:43] <fabbione> both ways work for me
[07:43] <jbailey> Well, it's incentive for you to make me appc64 kernel. ;)
[07:43] <fabbione> given that the 64bit is purely cosmetic
[07:43] <jbailey> I tried to install svenl's and got a strange error when unpacking.
[07:44] <jbailey> mmap error of some sort.
[07:44] <jbailey> I haven't investigated it at all.
[07:44] <fabbione> jbailey: i will start working on ppc64 kernels tomorrow
[07:44] <fabbione> right now i need to do more userland stuff
[07:44] <fabbione> since the rhcluster package has some implications
[07:44] <fabbione> like providing b-d for main
[07:44] <jbailey> Ah, what's today in userlanf?
[07:44] <fabbione> still rhcluster
[07:45] <fabbione> i need to split the package and start looking at init scripts
[07:45] <fabbione> i need to change branch in the kernel patches to match userland
[07:45] <fabbione> and verify the binary compatibility of my libs with the one in debian
[07:45] <fabbione> given that the source come from 2 different upstream branches
[07:45] <fabbione> and that the debian packages are pretty old
[07:46] <fabbione> since upstream is messy, i might need to do a soname transition
[07:46] <fabbione> that would probably be the safest thing to do anyway
[07:46] <fabbione> (and it requires only one or two packages upload)
[07:47] <fabbione> but one of them is lvm :P
[07:47] <jbailey> Joy.
[07:48] <jbailey> I'm hoping to send more time on EarlyUserspace this week, so I may need to poke you a bit.
[07:49] <fabbione> jbailey: sure...
[07:49] <fabbione> i saw that initramfs is already supported in the kerne
[07:49] <fabbione> kernel
[07:49] <fabbione> and there is a nice debugging message in dmesg about it
[07:49] <jbailey> Right.  I've been using distro Ubuntu kernels since January.
[07:49] <fabbione> let me know when we should try to switch
[07:49] <jbailey> NFS mount works, mounting a harddrive works.
[07:50] <jbailey> This weeks goals are to get udev finally happy with lkh and klibc and then to make an attempt to port all the logic over from initrd-tools to initramfs for guessing the modules.
[07:50] <jbailey> Once that happens we can just switch and be done with it.
[07:50] <jbailey> I can do all the hotplug work as options.
[07:50] <jbailey> (Which eventually become the default)
[07:51] <fabbione> if initramfs needs klibc, we need to check if it is built everywhere first
[07:52] <jbailey> http://people.ubuntulinux.org/~lamont/buildLogs/k/klibc/1.0.10-0ubuntu1/
[07:52] <jbailey> *success*
[07:52] <fabbione> i need to build that version on sparc
[07:52] <fabbione> the one before was FTBFS
[07:53] <jbailey> Yar.
[07:53] <fabbione> just creating the chroot right now :)
[07:53] <fabbione> unfortunatly klibc is in universe
[07:53] <fabbione> and it takes ages to get there again
[07:53] <fabbione> remember you will need to seed it to main before switching over
[07:53] <jbailey> I will start begging on my knees for you to post logs to where the rest of them are.
[07:53] <fabbione> otherwise we will seriously make boom boom
[07:53] <jbailey> It simply doesn't occur to me to look elsewhere most of the time.
[07:53] <fabbione> jbailey: i did talk with elmo already about it
[07:54] <fabbione> but he didn't give me a full solution yet
[07:54] <fabbione> jbailey: i understand perfectly the problem
[07:55] <fabbione> lamont has the same issue
[07:55] <fabbione> for hppa
[07:55] <fabbione> i will try to ping elmo again today
[07:55] <jbailey> Well, he will once he starts to actually build things.. ;)
[07:55] <fabbione> because it's in everyone interest
[07:55] <fabbione> ehehe
[07:56] <fabbione> Get:20 http://debdev.ext.fabbione.net breezy/universe linux-headers-2.6.12-1 2.6.11.92-1.1 [6290kB] 
[07:56] <fabbione> we will need the new kernel in main to move klibc
[07:56] <fabbione> also.. remember that these headers are not final yet
[07:57] <fabbione> so stuff might break for little while :)
[07:57] <jbailey> udev will move klibc.
[07:57] <jbailey> THe kernels will pull in mkinitramfs eventually which will also bring them in.
[07:57] <jbailey> Which headers?
[07:57] <jbailey> Oh, Isee.
[07:57] <jbailey> right.
[07:58] <jbailey> Right now I'm using lkh for everything else.  I pulled in the real headers for this one to avoid the hacking hassle.
[07:58] <jbailey> I now have commit rights to upstream lkh, which will be very helpful.
[07:58] <fabbione> right
[07:58] <fabbione> but real kernel headers come from me
[07:58] <jbailey> Upstream linux-libc-headers, rather.
[07:59] <jbailey> Right, but lkh ought to be good enough for everything.
[07:59] <fabbione> good :)
[07:59] <jbailey> Any place where it isn't is a place wher eI'm going to get a bug at some point.
[07:59] <jbailey> I'm using the linux-libc-headers project becaus eI'm hoping he'll get enough distros using it that it becomes the ABI headers.
[07:59] <fabbione> specially because we want to avoid to have a huge circular b-d on the kernel
[08:00] <jbailey> It's annoyingly unlikely, but he's kept at it for a year.  There's two distros using it now.
[08:00] <fabbione> kernel -> klibc -> initramfs (to boot/install the kernel)
[08:00] <jbailey> He's hoping to bring Gentoo on board.
[08:00] <jbailey> Err.  the kernel shouldn't dep on klibc.
[08:00] <jbailey> it should dep on initramfs-tools
[08:00] <fabbione> In file included from system.c:13:
[08:00] <fabbione> ../include/signal.h:81: warning: 'struct sigaction' declared inside parameter list
[08:00] <fabbione> ../include/signal.h:81: warning: its scope is only this definition or declaration, which is probably not what you want
[08:00] <fabbione> system.c: In function 'system':
[08:00] <fabbione> system.c:19: error: storage size of 'ignore' isn't known
[08:00] <fabbione> system.c:19: error: storage size of 'old_int' isn't known
[08:00] <fabbione> system.c:19: error: storage size of 'old_quit' isn't known
[08:01] <jbailey> Hah, joy.
[08:01] <fabbione> no but klibc needs the kernel to build :)
[08:01] <jbailey> That means the real kernel headers are fucked.
[08:01] <fabbione> jbailey: mostlikely yes....
[08:01] <jbailey> I'll get off my ass and clean up all the signal/socket stuff then.
[08:01] <jbailey> That's the bits that I had to pull in the real headers for anyway.
[08:01] <fabbione> jbailey: i think it is more wise to make klibc to use l-k-h or whatever you had in your mind
[08:02] <jbailey> Upstream for llh stubbed them out because glibc provides it all in private headers.  klibc assumes the use of upstream.
[08:02] <fabbione> because the kernel changes too fast for userland to follow
[08:02] <jbailey> Yes and no.
[08:02] <fabbione> and even a security update can mess up that stuff
[08:02] <jbailey> If the C library can't keep up with the kernel abi, then nothing can.
[08:03] <jbailey> Esp. the C library that's intended to be bundled with the kernel. =)
[08:04] <fabbione> ehhe
[08:05] <jbailey> Sometime in June is when you drop devfs support, right?
[08:05] <jbailey> Want to try to make it a goal for Monday next week? =)
[08:15] <fabbione> jbailey: i will drop devfs together with upstream
[08:15] <jbailey> What?!?  You're not going to be a bastard and drop it a release early like you did with ipchains/ipfwadm??
[08:16] <jbailey> =)
[08:18] <ajmitch> people still use devfs?
[08:18] <fabbione> jbailey: "release early" was only a patch from upstream :)
[08:19] <fabbione> but if you like i can drop it right away
[11:49] <fabbione> doko: ping?
[11:49] <fabbione>  /usr/bin/ld: /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib/crt1.o: relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC
[11:49] <fabbione>  /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib/crt1.o: could not read symbols: Bad value
[11:50] <doko> hmm, which package?
[11:51] <fabbione> the package is not in the archive yet
[11:51] <fabbione> but it builds fine on all other arches
[11:51] <fabbione> modulo ia64
[11:51] <fabbione> the source is in my home dir on concordia, if you want to look at it
[11:52] <fabbione> but from the error it looks like gcc-3.4 is borked on amd64
[11:57] <fabbione> doko: it happens with gcc-3.3 too
[11:57] <fabbione> but the code is compiled with -fPIC
[11:58] <doko> some assembler code?
[12:02] <fabbione> doko: apparently now
[12:02] <fabbione> not
[12:03] <doko> any libs involved?
[12:04] <fabbione> doko: it's building a lib
[12:06] <fabbione> actually....
[12:07] <Kamion> jbailey: the ssh thing can't be your fault; it's happening in Debian too
[12:08] <doko> fabbione: let have me a look later this weej
[12:08] <fabbione> doko: nah i think i did something royally stupid merging some changes from upstream
[12:09] <fabbione> and it shows up only on amd64
[12:09] <fabbione> yeah.. it builds fine
[12:09] <fabbione> sorry for the mess :((((
[12:16] <fabbione> elmo: can you please install libxml2-dev in breezy-ppc64 chroot on davis?
[12:16] <fabbione> (and also kernel build-deps)
[12:17] <fabbione> ah hold on... today is holidays in uk...
[12:17] <fabbione> crap
[12:17] <fabbione> yeah
[01:49] <jbailey> fabbione: Is it something you want me to hack on?  I have ppc64 locally.
[02:21] <fabbione> jbailey: nothing urgent.. i was only trying to build the rhcluster suite on ppc64 multiarch before upload
[02:21] <fabbione> we can do that anytime later
[02:21] <jbailey> Ah, yeah.  I could probably build it but not test it until the kernel is done.
[02:21] <fabbione> jbailey: exactly :)
[02:21] <fabbione> + actually the 64 bit libs are there just for fun
[02:22] <fabbione> since no binaries need them atm
[02:25] <jbailey> Is the cluster done in userspace or is this just hooks into the kernel?
[02:25] <fabbione> kernel and userspace
[03:19] <fabbione> jbailey: you around?
[03:20] <jbailey> fabbione: Yup
[03:21] <fabbione> jbailey: see /msg
[03:21] <fabbione> there are more errors after that...
[03:21] <jbailey> Bah, you should just paste in here.
[03:21] <jbailey> But anyhow.
[03:22] <fabbione> does it sound possible that libc6-dev is broken?
[03:22] <fabbione> this is i386
[03:22] <fabbione> and i am compiling something that is absolutely unrelated to ubuntu :)
[03:22] <jbailey> It's always possible.  It's pretty rare.
[03:23] <jbailey> LEmme see if I get the same on ppc.
[03:23] <jbailey> (My breezy i386 system is being wiped today for a reinstall)
[03:23] <fabbione> oh it's not redhatcluster :)
[03:23] <fabbione> acutally you are right.. i can try that in hoary
[03:23] <jbailey> Right, what app is it?
[03:23] <jbailey> Works in Hoary doesn't necessarily mean correct.  There's a new glibc - sometimes things change/break/whatever.
[03:26] <fabbione> jbailey: http://gridengine.sunsource.net/servlets/ProjectSource
[03:27] <fabbione> jbailey: there is a page where to get the tar.gz
[03:27] <fabbione> http://gridengine.sunsource.net/servlets/ProjectDocumentList
[03:27] <jbailey> Fatal error, aborting.
[03:27] <jbailey> anoncvs: no such user
[03:27] <fabbione> here is
[03:28] <jbailey> Ah good. =)
[03:28] <fabbione> sge-V60u4
[03:29] <fabbione> hmm you need java to build
[03:29] <jbailey> Hmm.
[03:29] <jbailey> I wonder if gcj is good enough.
[03:29] <jbailey> (It had better be, or this is headed to multiverse.. =( )
[03:31] <jbailey> What is it with people and crappy build environments?
[03:31] <fabbione> hmm sablevm is enough
[03:31] <jbailey> This is a *solved* problem for the most part.
[03:31] <fabbione> and it's building in hoary
[03:31] <jbailey> If sable can do it, then gcj/gij/ecj can.
[03:31] <fabbione> i think java is used only in the build scripts
[03:31] <jbailey> Which step is failing for you?
[03:31] <fabbione> it's the usual java crap from sun to create junk that already exists outside 
[03:32] <fabbione> read source/README.build
[03:32] <jbailey> I'm looking at that.
[03:32] <fabbione> after you run ./aimk depend
[03:32] <fabbione> that one completes fine
[03:32] <jbailey> Ugh.
[03:32] <jbailey> Needs csh
[03:32] <fabbione> the next step is to just run ./aimk to build
[03:32] <fabbione> it fails immediatly
[03:32] <fabbione> at the libs
[03:32] <fabbione> breezy.. in hoary it's building
[03:33] <jbailey> ls
[03:34] <fabbione> you will need libgjcX-dev
[03:34] <jbailey> YEah, those all come as part of java-gcj-compat
[03:35] <jbailey> _________C_O_R_E__S_Y_S_T_E_M_____________
[03:35] <jbailey> ../common/Makefile:67: ../common/common_dependencies: No such file or directory
[03:35] <jbailey> hmm
[03:36] <jbailey> Whups, had skipped a step
[03:37] <jbailey> Wow, more errors than my terminal backscroll. =)
[03:38] <fabbione> ehhehe
[03:38] <fabbione> this crack makes me enjoy my pc :))))
[03:38] <jbailey> Lovely, I see the same error here.
[03:38] <fabbione> good
[03:38] <fabbione> because it's building in hoary :)
[03:41] <fabbione> there are a few tons of build-deps...
[03:41] <fabbione> but it's fun! :P
[03:41] <jbailey> No definition for __const
[03:41] <jbailey> Hmm, what should pull it in?
[03:42] <fabbione> where do you get that?
[03:42] <jbailey> typedef int (*__gconv_fct) (struct __gconv_step *, struct __gconv_step_data *,
[03:42] <jbailey>        __const unsigned char **, __const unsigned char *,
[03:42] <jbailey>        unsigned char **, size_t *, int, int);
[03:42] <jbailey> That's what I get running the failing command through -E -dD
[03:43] <jbailey> Are you familiar with those switches to gcc?
[03:43] <fabbione> oh...
[03:43] <fabbione> nope...
[03:43] <fabbione> i am not a gcc/glibc expert :)
[03:43] <fabbione> i was trying to see some of the stuff you did last time in screen :)
[03:43] <jbailey> -E says "spit out what the compiler sees after cpp has had it's way", -dD tells it to let me know where various #defines and such happen.
[03:43] <fabbione> at least i understood how to read -v :P
[03:43] <jbailey> Hey glad to help where I can. =)
[03:44] <fabbione> yeah i learn fast :)
[03:44] <fabbione> or at least i try to
[03:44] <jbailey> Although when doing this with glibc headers, it's often helpful to have seen them a few times before.  They occasionally have crazy magic in them.
[03:44] <fabbione> no shit :)
[03:44] <jbailey> but gcc -E has to be something a compiler can understand, so that's where I usually start.
[03:48] <jbailey> fabbione: Can you help me look for something?  Save me loading a bunch of development crap on my wife's machine.
[03:48] <jbailey> (It's the Hoary one, I don't have any Java dev stuff on it)
[03:49] <jbailey> Mm, no it looks like __const is a gcc-4 builtin anyway.
[03:52] <fabbione> jbailey: sure.. just ask what you need
[03:56] <jbailey> Erm, on my system anyway it seems to be prefering /usr/include/linux/stddef.h to gcc's one.
[03:58] <jbailey> It does that with 3.3 on breezy, too.
[03:59] <jbailey> fabbione: Do you have a build log?  Can you show me the command that it's calling for that file on your hoary install?
[03:59] <doko> is /usr/include explicitely in the include path (-I option)?
[03:59] <jbailey> doko: It is here.
[04:00] <jbailey> But stddef is in /usr/lib/gcc...
[04:00] <doko> that's just wrong, gcc get's confused with include_next ...
[04:00] <jbailey> /usr/include/linux is also explicetely in there, which is strange.  I'm used to things #include <linux/FOO.h>
[04:03] <fabbione> jbailey: yes.. in a few minutes.. i need to figure how to make clean in the source...
[04:04] <jbailey> fabbione: rm -rf LINUXPPC_26 ? =)
[04:05] <fabbione> jbailey: hehe possibly.. but i am almost done with the build :)
[04:08] <fabbione> there is the need of a little patch to make it compile 100%
[04:08] <fabbione> but that's easy :)
[04:10] <fabbione> jbailey: it's building now....
[04:10] <fabbione> as soon as it's done i will upload the log
[04:11] <jbailey> Tx.
[04:11] <fabbione> no problem :)
[04:11] <jbailey> My guess is that the -I flags are slightly different between the breezy and hoary versions for some reason.
[04:12] <fabbione> hoary_log.txt
[04:12] <fabbione> on people.u.c/~fabbione
[04:18] <doko> -I/usr/include -I/usr/include/linux is just evil
[04:20] <jbailey> Right, so on Hoary it's not feeling the need to include /usr/include and /usr/include/linux in the gcc command line.
[04:22] <jbailey> fabbione: Can I leave it with you from there?  I suspect once those both go away you'll be fine.
[04:22] <lamont> doko: evil, and breaks #include_next, iirc
[04:22] <fabbione> jbailey: sure...
[04:23] <fabbione> i was only concerned about the error coming from a glibc include file...
[04:24] <jbailey> fabbione: Right - I just wanted to make sure you didn't need any more info from me before I rm -rf'd my tree locally.
[04:25] <fabbione> jbailey: if you are sure that's the problem, i am happy with that
[04:25] <fabbione> jbailey: and i will dig from there
[04:28] <jbailey> fabbione: Pretty certain.  If you look at the failing command with -E -dD, you'll see that size_t is never definned.  When you look at stddef.h, you see that it's being pulled in from /usr/include/linux instead of /usr/lib/gcc/.../include/stddef.h
[04:29] <doko> lamont: yes, scroll back a bit more ;)
[04:33] <jbailey> *bounce*
[04:37] <doko> lamont: thanks for the buildd toolchain love on the weekend
[04:39] <lamont> doko: sorry that the family had me as busy as it did...
[04:44] <doko> lamont: no reason to have an excuse for that :-)
[04:52] <fabbione> jbailey: that's right... eliminating the -I/usr/include/linux is the right solution
[04:52] <fabbione> the real problem is that i can't find a single reference to it in the entire source
[04:56] <jbailey> fabbione: I don't know how to troubleshoot csh.
[04:56] <fabbione> nah don't worry :) it was just to keep you informed :)
[04:57] <fabbione> this build system is worst than imake :)
[04:57] <jbailey> I apprecaite it.  I was curious so I looked.
[04:57] <jbailey> I enjoy fiddling with build systems.  I suspect this fix will be more than fiddling. =)
[05:21] <fabbione> AHHHHHH
[05:21] <fabbione>    if ("$JAVA_ARCH" != "") then
[05:21] <fabbione>       set CORE_INCLUDE = "$CORE_INCLUDE -I${JAVA_HOME}/${JAVA_INCL}/${JAVA_ARCH}"
[05:21] <fabbione>    endif
[05:21] <fabbione> this one!
[05:21] <fabbione> jbailey: for some incredible reasons that entry becomes /usr/include/linux
[05:21] <fabbione> but it's not meant to
[05:22] <fabbione> (btw csh accepts -x as bash
[05:22] <fabbione> )
[05:23] <jbailey> It's not something that holds over in $CORE_INCLUDE from before?
[05:23] <fabbione> i mean.. really....
[05:23] <jbailey> Mm, no, I guess I can see it.
[05:23] <fabbione> basically CORE_INCLUDE is expanede with -I${JAVA_HOME}/${JAVA_INCL}/${JAVA_ARCH}
[05:23] <jbailey> JAvA_HOME might be blank
[05:23] <fabbione> when JAVA_HOME is not empty
[05:23] <fabbione> but it is empty
[05:24] <jbailey> JAVA_INCL for gcj might be /usr/include
[05:24] <doko> fabbione: use java-gcj-compat and set JAVA_HOME=/usr/lib/jvm/gcj-java ...
[05:24] <fabbione> if ( $JAVA > 0 || $BUILDJAVADOC == 1 || $JNI == 1 ) then
[05:24] <fabbione>    # Make sure we can find JAVA_HOME
[05:24] <fabbione>    if ( ${?JAVA_HOME} == 0 ) then
[05:24] <fabbione>       echo "Please set JAVA_HOME"
[05:24] <fabbione>       exit 1
[05:24] <fabbione>    endif
[05:24] <fabbione> endif
[05:24] <fabbione> so this check fails
[05:25] <fabbione> there we go :)
[05:25] <fabbione> sick sick sick
[05:29] <fabbione> cat build-progress 
[05:29] <fabbione> glibc_2.3.5-1ubuntu4: successful
[05:29] <fabbione> yay!
[05:32] <doko> jbailey, time for the next glibc upload, i386 biarch/multiarch ;)
[05:33] <fabbione> doko: die!
[05:33] <fabbione> first sparc needs to change to NTPL
[05:34] <fabbione> or whatever is called :)
[05:34] <fabbione> doko: sparc just started building gcc-3.4
[05:34] <fabbione> do i need to stop it, or can i let it build?
[05:34] <doko> fabbione: do you need it?
[05:35] <fabbione> stop in the meaning of = do you plan an upload within the next 12 hours?
[05:35] <doko> no, why do you need the latest build on sparc?
[05:35] <fabbione> doko: i need to get the build fixes from the proper sources...
[05:35] <fabbione> the previous one was manually munged to make it build :)
[05:35] <doko> ahh, ok
[05:35] <fabbione> and it's not nice if sources and binaries do not match
[05:36] <fabbione> it would also be very nice if we can get the new gcc-4.0 in, to fix the /usr/lib64 /usr/lib thingy...
[05:42] <jbailey> doko: amd64/i386 multiarch would make more sense to do next.  It's an underused arch if we break it, and it gets you OO.o2 stuff you need.
[05:42] <jbailey> doko: I'd like to get a few EarlyUserspace things done first, though.
[05:44] <jbailey> fabbione: Sparcs conversion to nptl is dep's on binutils-2.16
[05:44] <jbailey> doko: BTW, what do you think of the ia64 workaround bit that I mentioned?  That the testsuite failure goes away if I do a build cycle of binutils, glibc against new binutils and then new binutils again.
[05:46] <fabbione> jbailey: ok :)
[05:51] <infinity> jbailey : That's not surprising at all.
[05:52] <infinity> jbailey : Makes me wonder if maybe our scorched earth bootstrapping shouldn't involve a sick round-robin of gcc/binutils/glibc builds for a few months before we build anything else. :)
[05:52] <fabbione> infinity: eheheh
[05:53] <fabbione> and pleople still believes i am sick...
[05:53] <fabbione> somebody is beating me
[05:54] <fabbione> well nice...
[05:54] <fabbione> now the gridengine is built :)
[05:54] <fabbione> tomorrow we will learn how a computing cluster grid will work :)
[05:56] <fabbione> thanks a lot guys :)
[05:57] <fabbione> i am off for dinner
[06:09] <jbailey> infinity: I beleive that it does - lamont doesn't usually install our binaries in the chroots, but instead rebuilds them with the binaries we provided and installs those in the chroots.
[06:09] <jbailey> infinity: But the concern I have is inheriting bugs.
[06:09] <jbailey> infinity: So some interaction that causes ABI instability of some sort that gets inherited down.
[06:10] <jbailey> infinity: (Given that the testsuite failure is something in static linking.  I don't have the error in front of me...)
[06:19] <infinity> Oh, fun.
[06:25] <jbailey> I think it's probably not in this case.  I suspect it's a TLS fix on a static library that is being made correct.
[06:28] <doko> I've merged these patches to 2.16.  2.16.1 is almost ready now; I'm hoping
[06:28] <doko> to release it on Friday.
[06:28] <doko> -- 
[06:28] <doko> Daniel Jacobowitz
[06:28] <doko> jbailey: ^^^
[06:29] <doko> so maybe we can wait until the next weekend?
[06:38] <\sh> I need some advise
[06:39] <\sh> ../Ark/ArkObject.h:100: error: 'Cache' has not been declared
[06:39] <\sh> ../Ark/ArkObject.h:108: error: 'Cache' has not been declared
[06:53] <jbailey> \sh: Context? =)
[06:55] <jbailey> doko: That's fine.  I'm in no rush for it.
[06:57] <\sh> jbailey: virtual bool Load (Cache *cache, const String &name);
[06:57] <\sh> the second line is the same thing..
[06:58] <\sh> Ark::Cache is included
[06:58] <\sh> its all in a namespace named Ark
[06:58] <jbailey> \sh: Right.  So is there a declaration of Cache before that in that namespace?
[06:58] <jbailey> \sh: g++ -E -dD is your friend here...
[06:58] <\sh> nope
[06:59] <jbailey> Hmm, I wonder if there's a post-processing phase for g++ where you can see all the calls with namespaces expanded.
[07:00] <jbailey> doko: Neat.  Looks like after the binutils update that we might be ready to ask for the rebuild of the world to verify that everything's transitionned.
[07:48] <doko> lamont: please could you remove the dep-wait from ftgl?
[08:10] <doko> infinity: ^^^
[08:18] <lamont> doko: done
[09:20] <doko> jbailey: I'd like to wait with the rebuild for gcc 4.0.1, announced for mid June
[09:20] <doko> lamont: thanks
[09:21] <jbailey> doko: That works, I saw Mark's email this morning about it.