=== zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain [12:38] gcc 3.4 hasnt been touched in breezy has it? [12:42] sorry dumb question === desrt_ [~desrt@kopesetik.desrt.ca] has joined #ubuntu-toolchain [04:50] morning [05:41] hello. [05:41] [05:45] moo [05:53] oow === desrt_ is now known as desrt [05:54] doko: on amd64, gnome-media Depends: libnautilus-burn1, not 2. [05:54] so gnome-media needs another upload, since the build-deps were clearly wrong on the last upload... [05:55] Updating the gdk-pixbuf loaders list for GTK+-2.4.0.../usr/sbin/update-gdkpixbuf-loaders: line 25: 27053 Killed /usr/bin/gdk-pixbuf-query-loaders >$TMPFILE [05:55] dpkg: error processing libgtk2.0-bin (--configure): [05:55] subprocess post-installation script returned error exit status 137 [05:55] so I shouldn't be killing that 14 hours after it started running, eh? [05:55] hppa hateses gdk-pixbuf [05:56] well, libgtk2.0-bin_2.6.7-1ubuntu1 [06:02] lamont! [06:03] lamont: You around tomorrow? [06:03] yeah [06:03] Cool. Looks like we have ppc64 ready to go. [06:03] rocking! [06:03] oh joy. Just tell me the dance [06:04] Lemme get the requirements from you: You require that anything installed into the buildd chroot be built by you, and then we upload binaries that use those, right? === lamont also just gave back most everything in main that was not built. === fabbione puts gcc and glibc in no_auto_build [06:04] jbailey: it's easier to phrase it in the negative... [06:04] lamont: Well, I'm looking for an afirmative set of steps to give you. [06:04] binaries not built by the buildd in a chroot containing only things built by the buildd are not uploaded [06:05] I'm less worried about what's uploaded than I am by what you're willing to install in that chroot to build what's going to be uploaded. [06:05] binaries built by the buildd using binaries built by the buildd using binaries built by $UBUNTU_GOD are ok [06:05] haha === fabbione likes the definition of $UBUNTU_GOD [06:06] the end-state requirement is that what's in the archive must be able to build what's in the archive. [06:06] Okay, so you need one iteration pass. I wonder if what I have on rookery is signed. [06:06] hence, if we have the trivial case of A Build-Depends B Build-Depends A, then we build A using random B binaries, build B using the A binaries just built, upload B, and let A just get built [06:07] fabbione: s/$UBUNTU_GOD/baby jesus/ ?? [06:07] ehhee [06:08] btw.. do we have a way to determine when all c++ libs are built for arch $foo ? [06:08] so that we can unban the apps? [06:08] fabbione: doko tells me. :-) [06:08] lamont: good point :) [06:08] and no, I don't believe that they are, even for the big-3. [06:09] that is, all 5 arch's that I have still have the banlist. although I did remove the 3 libs packages that were called apps packages, yesterday or the day before. [06:09] yup [06:10] so did i [06:10] hrm... maybe by morning my mirror-sync from yesterday will finish. (new kernel *2, new xorg - sigh.) [06:10] and maybe even my uploads will catch up with the builds. that'd be cool [06:11] jbailey: you know cdbs is ftbfs, yes? [06:11] lamont: ocaml's busted. [06:11] doh. I remember now [06:11] lamont: I should remember to look at that tomorrow. [06:12] /msg jbailey jbailey: look at ocaml [06:12] bah [06:12] hehe === lamont will sleep now, unless fabbione needs something else... :-) [06:12] lamont: The binaries I have on rookery aren't signed. I'll fix that in the morning and give you some basic step-by-steps. [06:12] thansk [06:13] And since Fabio's here, I know that it must be bed time. [06:13] g'n all! [06:13] and yeah, signed debs is kinda the requirement for installing in the buildd [06:13] jbailey: i woke up earlier today :) [06:13] fabbione: =) [06:13] fabbione: Earlier than 5am? [06:13] sick [06:13] Zzzz [06:14] jbailey: unfortunatly one of the side effects of living in dk is that during the summer the sun is up in the sky at 3am [06:14] and it woke me up at 4:something [06:14] i need to put some curtains in the bedroom === minghua [~minghua@ppp-70-246-27-204.dsl.hstntx.swbell.net] has joined #ubuntu-toolchain === minghua [~minghua@ppp-70-246-27-204.dsl.hstntx.swbell.net] has left #ubuntu-toolchain ["Leaving"] [07:27] jbailey, doko: with the patch, ugly as it is, the build succeeded. === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [11:20] doko: there's no libwpd8 any more; abiword-plugins needs to move to libwpd8c2 [11:22] doko: libintl-perl promoted [11:23] elmo: any idea why teri seems to want to promote stuff in hoary even though I said -s breezy? === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [11:27] Kamion: because it's shared ? [11:27] elmo: is that good? [11:28] no, but it's a natural consequence of how pools work [11:28] oh, it's the same version [11:28] just run hilaries once you've finished running teri [11:28] right, but I thought it could be in dists/hoary/universe/*/Packages.gz and dists/breezy/main/*/Packages.gz simultaneously [11:28] only via the magic symlinks [11:28] ok, I wasn't sure I could safely run that and wanted to check first [11:29] libintl-perl | 1.11-1 | hoary | source, all [11:29] still says that though [11:29] it will madison looks at the database [11:30] the symlinks only help for things which treat the Packages file as canonical [11:32] I guess the fact that the component is set in the database for (package,version) rather than (package,version,suite) is inherited from Debian then [11:32] but ok, as long as I didn't break the archive :) [11:33] (package,version,suite) being unique is a fairly fundamental katie thing ... === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain [12:27] lamont: I disagree, gnome-media's build log on amd64 shows me the libnautilus-burn2 dependency === daniels [~daniels@amnesiac.heapspace.net] has joined #ubuntu-toolchain === rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain === doko [~doko___@dsl-082-082-211-057.arcor-ip.net] has joined #ubuntu-toolchain === lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-toolchain === Riddell [jr@jriddell.kde] has joined #ubuntu-toolchain === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-toolchain === ajmitch [~ajmitch@port162-41.ubs.maxnet.co.nz] has joined #ubuntu-toolchain === svenl [~luther@AStrasbourg-251-1-59-4.w82-126.abo.wanadoo.fr] has joined #ubuntu-toolchain === Kamion [~cjwatson@host81-153-126-219.range81-153.btcentralplus.com] has joined #ubuntu-toolchain === infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain === jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === amu [~amu@amu.developer.debian] has joined #ubuntu-toolchain === desrt [~desrt@kopesetik.desrt.ca] has joined #ubuntu-toolchain === Seveaz [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === desrt [~desrt@kopesetik.desrt.ca] has joined #ubuntu-toolchain === daniels [~daniels@amnesiac.heapspace.net] has joined #ubuntu-toolchain === rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain === doko [~doko___@dsl-082-082-211-057.arcor-ip.net] has joined #ubuntu-toolchain === lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-toolchain === Riddell [jr@jriddell.kde] has joined #ubuntu-toolchain === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-toolchain === ajmitch [~ajmitch@port162-41.ubs.maxnet.co.nz] has joined #ubuntu-toolchain === svenl [~luther@AStrasbourg-251-1-59-4.w82-126.abo.wanadoo.fr] has joined #ubuntu-toolchain === Kamion [~cjwatson@host81-153-126-219.range81-153.btcentralplus.com] has joined #ubuntu-toolchain === infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain === jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === amu [~amu@amu.developer.debian] has joined #ubuntu-toolchain === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === desrt [~desrt@kopesetik.desrt.ca] has joined #ubuntu-toolchain === daniels [~daniels@amnesiac.heapspace.net] has joined #ubuntu-toolchain === rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain === doko [~doko___@dsl-082-082-211-057.arcor-ip.net] has joined #ubuntu-toolchain === lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-toolchain === Riddell [jr@jriddell.kde] has joined #ubuntu-toolchain === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-toolchain === ajmitch [~ajmitch@port162-41.ubs.maxnet.co.nz] has joined #ubuntu-toolchain === svenl [~luther@AStrasbourg-251-1-59-4.w82-126.abo.wanadoo.fr] has joined #ubuntu-toolchain === Kamion [~cjwatson@host81-153-126-219.range81-153.btcentralplus.com] has joined #ubuntu-toolchain === infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain === jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === amu [~amu@amu.developer.debian] has joined #ubuntu-toolchain [01:21] jbailey, doko: pthread_rwlock_wrlock <- any idea where this one should come from? [01:21] /home/sparcbuildd/rhcluster-0.20050527/magma-64/lib/global.c:536: undefined reference to `pthread_rwlock_wrlock' [01:21] this is building a 64 bit version of a library. [01:21] it's ok at 32 bit [01:21] /home/sparcbuildd/rhcluster-0.20050527/magma-64/lib/plugin.c:411: undefined reference to `dlopen' [01:21] HMMMM [01:21] this smell so much of libc6 borkage [01:22] definitely [01:25] ld: warning: sparc:v9 architecture of input file `plugin.o' is incompatible with sparc output === fabbione sighs [01:25] it happens with all kind of gcc [01:25] so it's not just gcc the problem === fabbione summons jbailey === jbailey appears [01:33] jbailey: see above :) [01:33] i am checking with older glibc right now [01:33] Are you running the buildd in a sparc32 jail? [01:34] it's just a chroot [01:34] i didn't execute anything like sparc32 or sparc64 [01:34] just added -m64 to the gcc call [01:35] Without it I can seee occasionally having problems. [01:35] (like Debian does) [01:35] afk a sec. [01:35] yeah no rush [01:37] back [01:37] hmm nope.. [01:37] same story in hoary... [01:37] hmmmmmmm [01:37] Try building it after sparc32'ing. [01:37] I've seen problems like that before. =( [01:37] i did try: [01:38] sparc{32,64} make CC="gcc-3.{3,4} -m64" [01:38] in all combinations [01:38] same error both in hoary and breezy... [01:38] i wonder.. [01:39] sparc32 -m64 doesn't make much sense... [01:39] Why would it have -m64 on it? [01:40] jbailey: because you need to build both 32 and 64 bit? [01:40] so basically the source is copied in 2 dirs [01:40] one for 32 bit build [01:40] and one 64 [01:40] I'd have to see the build log to guess. IT sounds like it's just gotten confused and mixed the two along the way somewhere. [01:41] jbailey: in glibc or this program? [01:41] this program. [01:41] sure.. one second [01:41] It's ld detecting the mismatch. [01:41] do you want the full build log? [01:41] IF it were glibc, I'd expect everything to fail. [01:41] or just the 64 bit part? [01:41] Yes please. [01:41] full [01:41] ok [01:50] jbailey: http://people.ubuntu.com/~fabbione/buildlog [01:59] Your link line is at least missing -ldl -lpthread [02:02] fabbione: This buildlog is only half there... [02:03] fabbione: It looks like you did a debuild -nc and sent me that. =) [02:04] ops [02:04] sorry about that [02:05] =) [02:05] doko: l? [02:09] hi [02:10] doko: svenl provided a patch do chew libstdc++ configure such that it assumes that we're cross compiling. I don't understand all the implications of the patch - are you comfortable with it for upload as gcc-3.4? [02:11] (I'm assuming that I need to make the patch ppc-only) [02:11] jbailey: relaod the log now :) [02:12] fabbione: Right, this is terribly confused. -m32 and -m64 code don't play together. [02:13] It's building the modules, but it's never built a -m64 libmagma.so [02:13] yes, I'm merging it now, so that it get's only applied, if we cannot run 64bit binaries. when we can run 64bit binaries, I'm enableing the -m64 tests as well [02:13] jbailey: the first part of the log is all 32 bits [02:13] the first failure is when i attempt to build the first 64bit module [02:13] module = subdirs that needs 64 [02:13] doko: Sweet, thanks. When you have that ready, I've already booked LaMont for part of today. [02:14] make[2] : Entering directory `/home/sparcbuildd/rhcluster-0.20050527/magma-64/lib' [02:14] ^^^note that it is building the same module in another dir :) [02:14] doko: I can at least get him with a bootstrap glibc and C-only gcc, after that we only need this for the upload. [02:14] fabbione: Right, but it's not actually building the libmagma again. It's building stuff to go with it without having build a 64bit libmagma. [02:15] i don't understand... [02:15] magma build is at the top of the file [02:15] magma-64 is at the bottom [02:15] don't take into account magma-plugins.. that's another story [02:16] fabbione: The first -m64 stuff I see is in magma-64/lib [02:17] Oh, bah. [02:17] My bad, sorry. I read the ld line wrong. [02:17] ehe no problem :) [02:17] nothing to be sorry about [02:17] that piece of code is a mess :) [02:17] now.. the point is that debian does exactly the same way [02:17] and it builds [02:17] jbailey: I do have a complete set of packages built with you glibc [02:17] needs copying to chinstrap [02:18] Do you prefer chinstrap to rookery? [02:18] lamont must be cheap if he can be booked that easily ;-) [02:18] I usually use rookery so that people can wget them. [02:19] doko: I promised him oral pleasure... [02:19] ... I'm buying him a pack of gum. [02:19] =) [02:19] ahaha [02:25] jbailey: say in about 4 hours work for you? [02:25] fabbione: Humour me a sec. ar -v lists sparc64 in the list of emulations at the bottom, right? =) [02:26] lamont: Yeah, should be fine. [02:26] cool. [02:26] ar: supported targets: elf32-sparc a.out-sparc-linux elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex [02:26] hey lamont [02:26] fabbione: Okay, good. =) [02:26] jbailey: :) [02:30] fabbione: Gcc sets -m elf64_sparc, can you try adding that to the ld line? [02:30] jbailey: sure thing [02:31] ld -m elf64_sparc -shared -soname libmagma.so.0 -o libmagma.so.0.0 global.o plugin.o localinfo.o ip_lookup.o memberlist.o clist.o -lc [02:31] ld: skipping incompatible /usr/bin/../lib/libc.so when searching for -lc [02:31] ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc [02:32] starts to look MUCH MUCH better! [02:32] no idea why it's searching crap in /usr/bin [02:32] but the build system is kinda borked :) [02:32] gcc does things through relative paths. [02:33] hmm [02:33] fabbione: Can you redefine ld there? [02:33] yeps [02:33] make CC="gcc-3.4 -m64" LD="ld -m elf64_sparc" [02:33] that's what i used just now [02:33] fabbione: If yes, just define it to "gcc-3.4 -m64" and see what happens, please. [02:33] that's what i did already [02:34] If the compiler notices that it's being used as a linker, hopefully it'll just do the right thing. [02:34] or you mean ld? [02:34] I mean ld. [02:34] ah ok [02:35] gcc-3.4: libmagma.so.0: No such file or directory [02:35] gcc-3.4: unrecognized option `-soname' [02:35] nope... [02:35] it didn't like it [02:35] Ugh, yeah. That stuff has to be wrapped in -Wl, magic. === jbailey boggles a moment. [02:36] jbailey, lamont: chinstrap:~doko/powerpc64 [02:36] doko: Nice, thanks. [02:37] doko: rocking :) [02:37] doko: And I think all I have to do is produce for him a libc6 that he can work with and this can be just uploaded. [02:37] fabbione: Care to share a screen session on vultus5? [02:38] jbailey: sure i can do that :) [02:38] just one sec :) [02:38] jbailey, yes, integrating svenl's patch [02:38] jbailey: just hook up in my session :) [02:39] ehehhe [02:40] if it's too big, i can resize mine :) [02:40] That's one for the quotefile. [02:41] btw.. screen is clever enough to show you the borders if you set a size bigger than the original [02:42] Really? Cool. [02:42] Thinking about sparc64 makes me need to listen to Nirvana, CD now playing. =) [02:44] ahha [02:44] it's a chroot.. there is nothing installed .) [02:44] or just the minimum [02:44] Hmm. [02:45] I would've thought that gcc or glibc would pull in libgcc_s_64 automatically. [02:45] oh [02:45] what do you want me to install? [02:46] Well, I'd like to know whose assumption is broken first. libgcc_s_64 is something brought in by gcc/the linker in this case, not the user, so the user shouldn't have to know to install it. [02:46] doko: ^^ ? [02:49] we don't have dependencies for the non-default arch in gcc [02:51] doko: What ought to pull that in? I don't think the user should have to, but I could do it as part of libc6-dev-sparc64 [02:51] libc6-dev-sparc64 is installed btw [02:52] Yup, it's just figuring out what should pull in lib64gcc1 [02:52] jbailey: yes, that might be a good place [02:52] oh so if i install that package... [02:52] it should build... [02:52] No, the last command I ran will work. [02:52] We still need to fix the package to do better than it's doing now. =) [02:53] yeah the package SUCKS BIG BIG BIG BIG BIG TIME [02:53] well the last interesting commands still return error [02:54] Are you packaging this for Ubuntu, or is this something we're importing from Debian? [02:55] jbailey: for ubuntu [02:55] part of it is already in debian [02:55] and i did check the build-dep [02:55] the point is that debian didn't build this crap in months [02:56] so with a very old toolchain [02:56] I don't think it would've worked months ago on sparc64 then... [02:57] jbailey: no idea if it works.. but it was builded [02:58] hmm, binutils bugs come flooding in [02:58] For now, let's make this work. [02:58] fabbione: Please install lib64gcc1 in this chroot. [02:58] sure [02:58] jbailey: meh.. it's installed :) === fabbione smells of deep gcc fuckage here [02:59] doko: Thinking of which, I saw drow mention that he was busy because of travelling. Would you prefer to wait for that update? [03:01] lamont: why is screem_0.12.1-1ubuntu3 not built? [03:02] jbailey: yes I did look at the ml today, maybe I just fetch a cvs update from the branch [03:02] Ah, I haven't read it today. He mentioned it in the #debian-glibc a couple days ago. === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [03:12] doko: I might have another gcc-3.4 packaging bug. Still time to get it to you? [03:16] fabbione: See that ifeq ($(with_shared_libgcc),yes) bit ? [03:16] jbailey: yes [03:16] btw.. i installed less :) [03:16] jbailey: yes [03:17] fabbione: That's not firing for some reason, so the libgcc is being left in /usr/lib64 instead of being moved to /lib64 [03:17] fabbione: We need to figure out what it didn't fire and get the patch for it to doko. =) [03:17] jbailey: a gcc-3.4 build without checks can take sometimes... [03:17] i can stop the buildd to make it faster [03:17] otherwise we can fix it in another upload [03:17] sparc won't build gcc- automatically anyway [03:18] I'd rather not hold up the ppc64 stuff for it. [03:18] installing gcc-3.4 build-deps now [03:18] yeah sure.. it works for me to wait the next upload [03:19] fabbione: There should be no reason why it didn't fire... [03:19] i can see that.... [03:19] but i have no idea.... [03:20] Oh right. [03:20] ahhh [03:20] I see. =) [03:20] gcc-4.0! [03:20] Right. =) [03:20] so gcc-3.4 has nothing to do with this problem [03:20] Right. [03:21] jbailey, should libgcc1 be installed in /lib64 or /usr/lib64? [03:21] do you want gcc-4.0 builddep? [03:21] doko: /lib64, in case it's needed for some reason to bring up /usr (encrypted filesystem or whatnot) [03:22] doko: The gcc-3.4 packaging appears to have it that way, but the gcc-4 packaging moves it to /usr/lib64. (Or rather, doesn't include the code snippet that moves it from $(d)/$(PF)/lib64 to $(d)/lib64 [03:24] jbailey: do you need gcc-4.0 build-deps? [03:24] to do a test build? [03:24] fabbione: I think it's funny that the Nirvana CD ended just as we figured it out. I should label it sparc64. =) [03:24] ahahaha [03:25] fabbione: Umm. No - I don't think I want to dive into that now. If we put a symlink in /lib64 for you so that you can hack on this, it'll be overwritten when the package is updated. [03:25] fabbione: It won't do you any good for uploading, but it will let you finish testing the build. [03:26] jbailey: yeah that's fine [03:26] doko: did you understand what you need to do to gcc-4.0? [03:29] hmm, didn't read ... the /lib64 stuff? [03:30] doko: yeps [03:51] ok [03:51] jbailey: it works perfectly! [03:52] thanks a lot! [03:55] fabbione: Any time. =) [03:58] lamont: ocaml is current FTBFS I think from the X transition, I'll poke at it next week. [04:00] Kamion : I've bitchslapped pitti, and a new upload is on its way. [04:01] cool, thanks [04:02] A little education about why testsuite output should be read and compared, and we're on our way. :) [04:02] infinity: Aren't you just the FormatTestPlans bitch now... ;) [04:03] Well, this does remind me that you should properly XPASS/XFAIL all of binutils' tests and actually error on suite failure. [04:03] s/you/we/ [04:03] Or me, even. [04:04] If I had a spare month, I'd do it with gcc too... [04:06] It was a bit shocking to come home, open up ubuntu-bugs, and see "nothing compiles on hoary anymore". Yay. === fabbione declares weekend time [04:13] later guys [04:13] Have a good one. [04:13] thansk === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [04:41] elmo, Kamion: I need libant1.6-java in main as a build dependency for OOo2 [04:42] doko: the java stuff is a mess, and AFAIK, mdz didn't want it migrated till the extraneous crap was dropped [04:46] elmo: I'm not talking about java, just libant1.6-java and ecj-bootstrap to have a working ant. that's all, not crap [04:47] o junit: junit [04:47] [Reverse-Build-Depends: libant1.6-java] [04:47] o libjaxp1.2-java: libjaxp1.2-java [04:47] [Reverse-Build-Depends: libant1.6-java] [04:47] o ecj-bootstrap: ecj-bootstrap [04:47] [Reverse-Depends: java-gcj-compat] [04:47] o java-gcj-compat: java-gcj-compat [04:47] [Reverse-Build-Depends: gjdoc] [04:47] elmo: Suggests!!! [04:47] o libgcj-dev {gcc-defaults} [04:47] [Reverse-Build-Depends: java-gcj-compat] [04:48] doko: germinate doesn't look at suggests [04:48] o kaffe: kaffe, kaffe-common, kaffe-pthreads [04:48] [Reverse-Depends: kaffe, kaffe-pthreads] [04:48] [Reverse-Build-Depends: junit] [04:48] o classpath: classpath, classpath-common, jikes-classpath [04:48] [Reverse-Depends: classpath] [04:48] [Reverse-Build-Depends: antlr, libjaxp1.2-java] [04:48] .. do I need to go on? :-P [04:49] ok, forgot about the Reverse-Build-Depends ... [04:49] let's see if I can build it with gcj-4.0 [05:04] elmo: please could you dist-upgrade davis/breezy-ppc64 and then install the packages from davis:~doko/gcc/install/ ? [05:05] I can't dist-upgrade without a fixed glibc packae set [05:05] are the ones in ~doko safe to install first? === jbailey reads the backscroll to figure out what he missed. [05:07] hmm, they have the same version as the ones in the archives [05:10] libc6-dev: Depends: linux-kernel-headers (<= 2.6.11.2-0) but 2.6.11.2-0ubuntu1 is installed [05:11] elmo: hmm, maybe just install the *64 packages then, the rest from breezy [05:11] What are you guys doing? [05:11] jbailey: rebuilding 3.4 in the breezy-ppc64 chroot [05:12] just want to check, that I don't have any new build bugs introduced [05:12] doko: Ah, you really probably want the glibc from my directory on rookery. [05:12] jbailey: yes, that's what I copied [05:13] Really? =( It shouldn't have that lkh bug... [05:13] it doesn't [05:13] Then I'm just confused. [05:29] Unpacking bison-doc (from .../bison-doc_1%3a2.0-1ubuntu2_all.deb) ... [05:29] dpkg: error processing /var/cache/apt/archives/bison-doc_1%3a2.0-1ubuntu2_all.deb (--unpack): [05:29] trying to overwrite `/usr/share/info/bison.info.gz', which is also in package bison [05:29] DUDE [05:29] Conflicts: bison (<< 2.0) [05:29] hmm, I thought I fixed it ... [05:30] Version: 1:2.0-1ubuntu2 [05:30] epochs'r'us [05:31] argh [05:33] anyway, breezyt-ppc64 done [05:33] thanks [05:33] bison supposed to be fixed now [05:37] elmo: sorry, still need autoconf2.13 automake1.4 automake1.7 [05:38] installed [05:39] jbailey: when did you book lamont? [05:40] doko: The 4 hours he quoted would be about 45 minutes from now. [05:40] I do need food, though, so I'd be happier if it were a bit later. [05:41] And I have a rental car to return over lunch. [05:42] hrm... === lamont has lunch in about 2.25 hours time.. [05:43] could start now, if you want... [05:43] doko: screem was d-w, will see how it does now [05:44] lamont: You will need to install a new binary glibc into the buildd. A source upload of gcc after that is enough to build gcc, and a source upload of glibc after that is enough to get glibc in. [05:44] lamont: What's first? =) [05:45] lamont: let's start now [05:45] /usr/include/sys/procfs.h:57: error: parse error before 'elf_vrreg_t' [05:45] go lkh! kill gdb. [05:46] (gdb is ftbfs on ppc) [05:48] jbailey: so what I'm most likely to do is: (1) glibc binary install, (2) build gcc, install that binary, (3) build/upload glibc, (4) build/upload gcc [05:49] hrm.. actually, (3) is build, install glibc. :-) [05:49] (5) is build/upload glibc [05:49] lamont: what's this? [05:49] bootstrapping biarch [05:49] lamont: Okay. So for version numbers, glibc 2.3.5-1ubuntu3 is in the archive now, gcc-3.4 3.4.4-0ubuntu3 is in the archive now. [05:50] lamont: What binary version do you want the first glibc to be? [05:50] jbailey: if you want to be kind, something between -1ubuntu3 and -1ubuntu4 :-) [05:50] or even -1ubuntu4, and the actual source upload be -1ubuntu5 is fine with me [05:51] lamont: biarch of what? === lamont points at jbailey [05:51] elmo: ppc/ppc64 [05:51] elmo: ppc64 [05:51] I thought you needed a 64 bit kernel? [05:51] no, only for a "sanity" check and running the testsuite [05:51] jbailey: and this is on ppc only, or which architectures am I bootstrapping? :-) [05:52] as binutils recently demonstrated, the testsuite is for wimps ;-) [05:52] lamont: I thought jbailey booked you for i386 as well? [05:53] Kamion: to be more precise, testsuite for -m64 is not run [05:54] doko: i386 was my recollection... ppc64 was the news item... :-) [05:54]