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