[12:16] moo [12:18] elmo: I don't recall seeing a reject for icu... [12:36] lamont: error on powerpc kdebindings compile "virtual memory exhausted: Cannot allocate memory" [12:38] Riddell: most cool. [12:38] which machine? [12:39] (top of the file...) [12:39] Automatic build of kdebindings_4:3.4.0-0ubuntu3 on ross by sbuild/powerpc 1.170.5 === lamont will give it back [12:45] doko: Feh, shwab's fix doesn't seem to work. [12:45] It's actually in there this time, and it's the right test, but I still get the failure. [12:45] Oh, hm.. [12:45] lt-ld-new: __libc_errno: TLS definition in /usr/lib/gcc-lib/ia64-linux/3.3.6/../../../libc.a(errno.o) section .tbss mismatches non-TLS reference in /usr/lib/gcc-lib/ia64-linux/3.3.6/../../../libc.a(check_fds.o) [12:45] /usr/lib/gcc-lib/ia64-linux/3.3.6/../../../libc.a: could not read symbols: Bad value [12:45] FAIL: bootstrap with --static [12:46] feh, I thought this chroot was up to date. [12:48] No, gcc is point at 4.0. So why the 3.3.6 reference? [12:51] Right, so I'm on total crack. [12:51] Two tabs to the machine, one is in the chroot, one is not. [12:51] Ran the build in the wrong tab. [12:51] =) [12:52] heh, /etc/debian_chroot in the prompt is your friend ;) [12:52] The sad part is that it's even there =) [12:53] I'm still not used to having bind mounts of my home dir in the chroots. [12:53] I have a new libc6-ppc64 that's current with what I'm going to upload RSN. Do you want it for anything? [12:55] hmm, no, going to bed now. trying to understand why libjava doesn't build on amd64 with -m32, so heck, mithrandir can put it in ia32-libs-openoffice.org as well [12:56] Joy. [12:56] doko: I'm going to look at gcc-4.0 for biarch ppc64 now. That's what waldi said he was working with. [12:57] doko: Have a good night. [12:58] night [01:12] /build/buildd/arts-1.4.0/./mcop/dynamicskeleton.cc:205: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 [01:12] Please submit a full bug report, [01:12] with preprocessed source if appropriate. [01:12] See for instructions. [01:12] ICE baby! [01:12] arts/hppa [01:12] that's with the -7ubuntu6hppa2 compiler === lamont_r [~lamont@phantom.acmeps.com] has joined #ubuntu-toolchain [02:17] ice ice baby === daniels giggles: [02:19] ICE: [02:19] * configure.ac: [02:19] Add ICE_t #define required by Xtrans headers. Replace static defines [02:19] of LOCALCONN & UNIXCONN with new XTRANS_CONNECTION_FLAGS macro. === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain [05:15] doko: home/jbailey/Programming/packaging/glibc/glibc-2.3.5/build-tree/ia64-libc/csu/crtn.S:22: Error: `_init#' was not defined within procedure [05:15] /home/jbailey/Programming/packaging/glibc/glibc-2.3.5/build-tree/ia64-libc/csu/crtn.S:36: Error: `_fini#' was not defined within procedure [05:15] doko: That's building glibc with binutils 2.16 [05:16] I got curious about the failure, since it claims that it's a TLS mismatch within glibc. [05:16] So I decided to try and build glibc with the new binutils to see if there was something that got fixed along the 2.15 path. [05:16] The closest reference I found to the failure was: http://www.darkliquid.co.uk/?item=lfs-trouble-fixed and http://lists.parisc-linux.org/pipermail/parisc-linux/2005-April/026289.html === doko [~doko___@dsl-082-082-196-023.arcor-ip.net] has joined #ubuntu-toolchain [05:55] morning [06:01] yay... build-dep madness [07:03] Seem CVS HEAD of glibc has a fix for the _init# stuff in the new binutils. [07:05] Off to sleep in the meantime.... === ubuntulog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-toolchain === Topic for #ubuntu-toolchain: GNU Compiler Collection, Glibc, Binutils, Linux-kernel-headers | GLIBC Todo: hppa, sparc NPTL, i386 biarch, C++ ABI change: 33/55 library packages in the archives === Topic (#ubuntu-toolchain): set by doko at Thu May 19 00:40:28 2005 === #ubuntu-toolchain [freenode-info] help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup === lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-toolchain === doko [~doko___@dsl-082-082-196-023.arcor-ip.net] has joined #ubuntu-toolchain === svenl [~luther@AStrasbourg-251-1-51-64.w82-126.abo.wanadoo.fr] has joined #ubuntu-toolchain === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain === ajmitch [~ajmitch@port162-41.ubs.maxnet.co.nz] has joined #ubuntu-toolchain === Kamion [~cjwatson@host81-153-126-219.range81-153.btcentralplus.com] has joined #ubuntu-toolchain === amu [~amu@bofh.debian.net] has joined #ubuntu-toolchain === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain === jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain === svenl_ [~luther@AStrasbourg-251-1-57-223.w82-126.abo.wanadoo.fr] has joined #ubuntu-toolchain === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === minghua [~minghua@ppp-69-153-138-167.dsl.hstntx.swbell.net] has joined #ubuntu-toolchain === minghua [~minghua@ppp-69-153-138-167.dsl.hstntx.swbell.net] has left #ubuntu-toolchain ["Leaving"] [10:36] doko: you around? [11:14] morning fabbione [11:14] morning dude [11:15] doko: the latest bash fails on sparc :( [11:15] i am trying to build it manuallt [11:15] but it hangs on a test case [11:15] like the original one was doing on all arches [11:15] run-jobs [11:15] and it hangs there [11:16] 27342 pts/0 S+ 0:00 /home/sparcbuildd/bash-3.0/build-bash/bash ./jobs.tests [11:16] 27343 pts/0 R+ 2:19 /home/sparcbuildd/bash-3.0/build-bash/bash ./jobs1.sub [11:16] these are the jobs running [11:16] hmm ... didn't see this on the other archs [11:16] jobs.tests is the main caller [11:16] yeah i know [11:16] jobs1.sub is running (100% of CPU) [11:16] but stracing: [11:16] waitpid(-1, 0xefffed8c, WUNTRACED|0x8) = -1 EINVAL (Invalid argument) [11:17] it's a infinite seq of the above [11:17] amu reported something like this on amd64 [11:17] what info can i provide you to check what is wrong? [11:18] can you try to compile with 3.3 as a workaround to lower the urgency? [11:20] doko: sure.. [11:21] checking for sparc-linux-gnu-gcc... gcc-3.3 [11:21] it's building [11:24] i just forced CC=gcc-3.3 in debian/rules [11:24] i guess that should be enough.... [11:25] gcc-3.3 build for sparc: [11:26] debian/rules.d/binary-libstdcxx.mk: line 226: add a mkdir -p $(d)/$(gcc_lib_dir)/64 [11:26] sparc is our only biarch gcc-3.3 [11:27] doko: ok, do you want me to upload it? or will you? [11:28] or do you want me to do a test-build before upload? [11:30] have to do other fixes as well (dpkg-architecture things) [11:31] ok [11:32] did you also start building gcc-3.4? [11:34] i will pass by later.. gotta cook lunch [11:34] wife is sick [11:34] and my "attributes" are breaking down [11:36] hmm, it's something else, the compiler isn't built biarch :-( [11:39] <\sh> guys.../usr/X11R6/include/X11/Xlib.h should be normally /usr/include/X11/Xlib.h, right? I'm a bit confused right now ;) [12:51] \sh: is guaranteed to exist if you have libx11-dev installed and -I/usr/X11R6/include [12:51] it may be in /usr/X11R6/include/X11/Xlib.h (where it is right now), or it may be in /usr/include/X11/Xlib.h [12:51] (where it will be soonish) [12:57] hi daniels [12:58] what is soonish? we could wait fixing stuff, when it ends in /usr/include soon [01:00] doko: maybe next week, I don't know. depends on how much time I have to spend working on other stuff [01:01] heh, it would _save_ lots of work for other people ;) [01:15] doko: compiling with gcc-3.3 makes no difference [01:16] the test case still hangs [01:21] hmm [01:21] found out, that we don't configure gcc-3.3 as biarch for sparc anymore, some more dpkg-architecture fallout [01:24] doko: amen.... [01:25] sorry, didn't see it on the other archs [01:26] doko: don't worry.. it's fixable :) [01:27] before the next upload, we should decide on the target_alias, is it -linux or -linux-gnu ? at least binutils and gcc should match. [01:27] doko: how many packages are ftbfs because of it? i didn't think it was too many [01:27] doko: i don't care :) [01:27] daniels: from the 50 I did upload 3 or 4. [01:28] you guys are the toolcrap maintainers :) [01:28] doko: heh [01:28] anyway.. i need to wash dishes.. and later F1 :) [01:28] things generally broke because they were testing the output of dpkg-architecture right? [01:28] elmo: yes [01:29] it wouldn't be hard to grep the source and see how many packages are even using that [01:29] you get many false positives, if you grep for GNU_TYPE [01:30] and you miss many, if you grep for dpkg-architecture [01:30] how come? [01:30] I mean just: a) get a list of packagers using dpkg-architecture, then b) eyeball them to see what they're checking [01:30] + for [01:30] s/rs/s/ [01:31] yes, but you can use *_GNU_TYPE without calling dpkg-architecture, can't you? [01:31] err, how? [01:31] or is on only *_ARCH set by dpkg-buildpackage? [01:35] no, they are all set by default [01:38] elmo: how should we set the target alias for binutils/gcc ? currently binutils sets a different one, depending on the dpkg version it's built with. [01:39] add the -gnu for -linux, or remove it? [01:47] gar, that's so much crack [01:47] well can we not grep for DEB_HOST/DEB_TARGET ? [01:47] doko: I dunno - has keybuk appeared yet? [01:47] I'd really like to know why this change was made [01:48] no, i didn't see him after the dpkg upload :( [01:50] ok, for now, I'll manally set it to -linux, we shouldn't break more things at the moment, I'll fix binutils to do the same, or else the hppa64 gcc will be broken [01:57] F1 is starting... [01:57] ops [01:57] ECHAN :) [01:59] fabbione: why do you still watch it, or is it a must to see Ferrari loose? ;-) [02:01] doko: die! :P [02:01] there is always a hope [02:01] of what, Ferrari losing? :) [02:02] i guess Keybuk is upset to death [02:02] since BAR has been disqualified for 3 races [02:03] ok let see how many damanges at the first turn [02:03] impressive [02:03] not even one! [02:03] heh [02:03] bar aren't exactly the best, though [02:04] same quality as dpkg these days [02:04] so we should disqualify keybuk as well ;) [02:04] eheh good point === _infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain === infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain [02:37] elmo: I did upload binutils for breezy to stick with -linux, need to fix gcc-* now [02:51] yay [02:51] does that mean another gcc-* upload round? [02:53] yes, starting with 3.3 [02:53] good.. i am happy i didn't build 3.4 yet :) === jbailey fades into reality. === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [03:43] jbailey: low priority ping [03:43] cartman: 'sup? [03:43] hi jbailey [03:43] jbailey: is a binutils 2.16 update planned? I guess you take care of binutils too? [03:43] do you plan any gcc uploads today? [03:44] doko: Heya Matthias. [03:44] 'take care of' is the wrong term for my relationship with the toolchain. [03:45] But in any event, I'm interested in the binutils update, and am testing a patch on glibc to make it build with binutils 2.16 on ia64 right now. [03:45] 2.16.1 is scheduled for next week [03:45] doko: I have questions for you. I think I'm missing something in the biarch setup, becuase it's trying to create the 64bit packages, but isn't attempting to build the 64bit binary. [03:46] which arch? [03:46] ppc64 [03:46] with 3.4? [03:46] I have it, and it's local, so I figured I'd use that to learn the biarch setup. [03:47] what does gcc-3.4 -v say? [03:47] jbailey: thanks for info. whats the right term btw? :) for your relationship with toolchain? [03:47] I tried both 4.0 and 3.4 [03:47] I notice that you usually have 2 patches to apply to the toolcahin to enable it, though. .40 doesn't have either of them, and 3.4 only has one of them. [03:48] jbailey@ppc64:~$ gcc-3.4 -v [03:48] Lecture des spcification partir de /usr/lib/gcc/powerpc-linux/3.4.4/specs [03:48] Configur avec: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gt [03:48] k --enable-targets=powerpc-linux,powerpc64-linux --disable-softfloat --disable-softfloat powerpc-linux [03:48] Modle de thread: posix [03:48] version gcc 3.4.4 20050408 (prerelease) (Debian 3.4.3-13ubuntu1) [03:48] doko: It produces a hello world binary with gcc-3.4 -m64 [03:49] hmm, does it really need --enable-targets=powerpc-linux,powerpc64-linux ? [03:52] oh, yes, you are right, that is a change from 2005-03-31 [03:52] at least for 3.4 [03:53] doko: Aside from that, timing-wise I would need lamont to be around, and he's not often here on Sundays so it's not likely to be today. Tomorrow is a holiday here and I'll be away from the computer most of the day, so Tuesday probably? [03:54] Ah, I see Modra's change, right. [03:54] I had been thinking it was entirely the packaging, my bad. [03:54] jbailey, I'll leave early on Tuesday, so maybe Wednesday. [03:54] doko: Sounds lovely. [03:55] doko: Did you read your backlog when you came on? What do you think of the idea of just doing the biarch stuff multiarchish. [03:55] I'll do one more upload today to fix more dpkg stuff ... [03:55] doko: It'll make the OOo stuff you're doing a bit easier for me to fix. [03:56] yes, sounds good [03:56] doko: Lovely, so I'll test that config after I get this running too. [03:57] doko: Then do the match glibc upload and lkh upload. Hopefully have it all the way you need by the end of the week or so? [03:58] cool === Seveas [~seveas@83.160.7.26] has joined #ubuntu-toolchain [04:10] cartman: You could probably say 'quite interested' and 'stupid enough to hack on it when I need to' [04:10] jbailey: ok :) [04:11] jbailey: one of the tough things to mess [04:11] so kudos to you :) === jbailey points to doko. [04:13] cartman: Give him kudo's, he's the true madman. =) === cartman bows to doko [04:13] =) [04:13] and the debian maintainer the japanese guy I can't spell his name :/ [05:09] doko: When I build the new binutils, install it, build the new glibc (with a patch to make it like the new gas), and then rebuild the binutils the failure goes away. [05:10] doko: I'm not sure the best way to track to see that this isn't corruption leaking in, or if it's a bug that was fixed. [05:17] <\sh> ah jbailey :) [05:17] <\sh> the right person [05:28] \sh: Eh? [05:28] \sh: I'm just wandering off to play a video game... Anything you need urgently? [05:28] <\sh> jbailey: problem with cdbs magic [05:28] Joy. [05:29] 'sup? [05:29] <\sh> arkrpg...i need to update some files (config.sub and config.guess to aclocal-1.7/automake-1.7) and it's using simple-patchsys ;) [05:29] <\sh> so whats the best way to take diffs for it ;) [05:31] Usually I either use the tarball method, or I cp FOO /tmp; fiddle FOO; diff -u /tmp/FOO FOO >debian/patches/###-description.patch; vi debian/patches/###-description.patch to fixup the diff headers. [05:31] In that case, I often fix upstream though and try to get them on a recent version of automake and autoconf. [05:31] There's also some stuff in the autotools.mk that you can use to auto update config.sub and config.guess [05:31] <\sh> jbailey: i read about it, but I also read that it can break ;) [05:32] <\sh> anyways, the tarball method I was thinking about :) [05:32] tarball method is a bit nicer for that [05:32] simple-patchsys sucks in a couple ways, like if you get the patch wrong, you have to back out all the applied patches by hand. [05:32] (patches to fix that welcome, it should be pretty easy) [05:33] <\sh> applying the patches from the debian packages beforehand, then do the work inside the source, take the patches and diff [05:33] Yup. [05:33] We need a make_patch method. [05:33] Again patches welcome, but you'd probably be happier hacking it into cdbs2. [05:33] <\sh> jbailey: well..I would like to exchange simple-patchsys with dpatch magic [05:33] Ugh. [05:33] I'd really like to see dpatch go away. [05:34] <\sh> why? [05:34] Simple-patchsys does a better job in that you don't have to add crap to the top of each patch. [05:34] And simple-patchsys will auto detect -p0 -p1 or -p2 [05:34] <\sh> ok...let me try this out :) [05:34] What we really need is all of the dpatch magic for handling patch files with simple-patchsys' application methods. [05:35] Cool, I'll be lagging for about 90 minutes to play a round, I'll check in after. [05:35] <\sh> jbailey: can I use the orig.tar.gz ? or should I use a real clean one [05:35] <\sh> sorry ;) [05:36] For the tarball method? You can use the .orig.tar.gz, just dump it in the directory, then take a tarball of that to make the new .orig [05:36] You still don't want a Debian Native package. [05:36] (What we really want is Scott to implement the Wig and Penn proposal. But *sigh*) [05:36] Really off now. [05:36] =) [05:37] <\sh> jbailey: thx and have fun now :) [06:20] <\sh> anybody up for some libGLU.so.1.3 magic?? ,-) === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [06:49] xorg_6.8.2-16: successful [06:49] GO DANIELS! [06:51] xbase-clients still depend on xlibmesa-glu instead of libglu1-xorg [06:51] in case its simple to fix :/ [06:51] <\sh> cartman: right [06:52] <\sh> we have to recompile some packages after it's fixed i think [06:52] yup [06:52] <\sh> kdelibs4c2 etc. gksu bla [06:52] bzflag,libfox, rezound and some more possibly [06:53] but they might be from universe [06:53] not sure [07:01] cartman, \sh: it's pointless to spend too much time fixing xorg as it is [07:01] the only reason why it is still there is to provied build-deps for other packages [07:01] fabbione: well lemme know when you want to hear whats borked =) [07:01] xorg as source will die pretty soon and fast [07:01] no we don't really care because we are going modular [07:01] <\sh> fabbione: so, replacing Build-Deps: xlibmesa-glu with libglu1-xorg? [07:01] once we are modular we will care again [07:02] \sh: it depends on what package, but yeah that should be it [07:02] <\sh> doko: please review your kdelibsc2 patch ;) [07:03] \sh, there's nothing wrong with the patch, it's the *ing xorg reorganisation at the wrong time [07:03] doko: can i build gcc-3.* on sparc or should i expect failures? [07:04] fabbione: it "should" work ... [07:04] doko: ok. [07:04] in that case i don't mind trashing a few hours :) [07:04] if it doesn't i am going to bitch slap you :P [07:05] <\sh> doko: hmmm..libglu1-xorg is replacing xlibmesa-glu so kdelibs4c2 will be removed as well.. [07:05] <\sh> but it could be more worse... [07:06] \sh: please ... don't worry.. [07:06] all this stuff will be sorted pretty soon [07:06] <\sh> ah...I'm a bit tired ;) I just fixed one error and the next is approaching [07:06] there are automatic scripts checking these kind of stuff [07:08] uhuh binutils... gcc.. glibc... [07:11] <\sh> fabbione: so...right now, libglu1-xorg(-dev) is the right package for build-deps [07:12] no, libglu-dev-xorg [07:12] <\sh> or this way ;) but libglu is the right one, linked against libstdc++6 [07:17] right [07:17] also libtunepimp2 needs to recompiled with new libmusicbrainzc2 [07:18] <\sh> anyways...it doesn't solve my problems...cause libsdl1.2-dev depends on xlibmesa-glu [07:19] \sh: isn't that just a simple depends fix + a recompile ? [07:20] <\sh> cartman: think so, but not for me today anymore...I'm stopping right here right now, trying to watch at least 2 episodes of "Lost" and then I'll try to sleep, cause tomorrow morning i have to go to work at least at 4:00am [07:20] \sh: :/ [07:22] \sh, yes, but the real problem is the xbase-client's dependency on xlibmesa-glu, which daniels has to fix [07:22] <\sh> doko: yeah [07:23] <\sh> but tomorrow is also a day...so I have to think about our BMR reboot and Divitech SI Server reboot [07:24] <\sh> it means, all non-upgrade dtv network areas in NRW are without DTV at least for 5 mins [07:25] <\sh> and those 5 mins means: please report to CTO why this had to be done :( [07:28] fabbione, daniels: do you know what the replacement for xlibmesa-dev is? [07:29] doko: no sorry. [07:31] doko: btw did you read the scrollback? bash with gcc-3.3 still hangs [07:32] doko: libglu1-mesa-dev looks like the xlibmesa-dev replacement [07:32] doko: looking at the conflicts at least [07:37] hmm, yes, so xlibmesa-dev -> xlibmesa-gl-dev, libglu-dev-xorg === doko doesn't like scrollbacks today ... === fabbione -> dinner -> cinema [07:41] cya tomorrow guys [07:42] see you, sparc toolcarp builder ;) [07:48] toolcarp? [07:51] s/ar/ra/g [07:53] I was imagining a fish with "gcc" written on the side. =) [07:55] sparcling carp ? [07:55] doko: That sounds like a nasty drink. =) [07:55] Fizzy cod liver oil. =) [08:25] doko: In the gcc-3.4 I pulled from the archive this morning, rules2 has an ifeq ($(DEB_TARGET_GNU_TYPE),powerpc-linux) and another one against ia64-linux [08:25] doko: How do you want things like that reported? [08:36] jbailey: fetch the fresh sources and don't complain ;-P [08:36] Ah, did you upload one newer than this morning? [08:37] yep, because it was broken on ia64 and sparc [08:37] 'kay. I'll see how for this build gets first. [08:39] finished on i386 [08:40] Sorry, I mean locally. [08:40] The biarch one. [08:41] Should we be updating ToolchainRoadmap directly now? It's an approved spec, but there's things in the TODO that need tweaking (because they're done, mostly) [08:43] afk for food. [08:44] hmm, yes, we could, but the libraries aren't convert yet, some are still missing [09:00] daniels: we need a fixed xbase-clients package, which doesn't depend on xlibmesa-glu, but on libglu-xorg. kdelibs4-dev currently cannot be installed. === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain [09:40] doko: Right, but there's a few steps done that we should probably have listed there. [09:40] doko: I'll ping JaneW to find out how she wants that done - then she doesn't have to chase us for status updates. [09:40] zul: Heya Chuck. [09:56] hey jeff how goes? [10:03] zul: Good, just on the phone. =) [10:20] Build finishes, produces libgcc_s_64.so this time, sweet. [10:21] there's a bad dh_link call, I'll tweak it. [10:21] But aside from that I might have a useful biarch ppc64 toolchain now, yay. =) [10:28] jbailey: which package? [10:31] doko: gcc-3.4 in rules.d/binary-gcc.mk [10:31] Lemme open an Xterm so I can cut and passte. [10:31] Under the ifeq ($(biarch),yes) [10:31] hmm, glibc for amd64 did not build [10:31] I think it should probably be: [10:32] dh_link -p$(p_gcc) \ [10:32] /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/libgcc_s_64.so [10:32] /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/64/libgcc_s_64.so [10:32] /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/64/libgcc_s.so [10:32] You didn't have the $(PF) in there. [10:33] ok, not /lib64, but /usr/lib64 [10:33] Right, that's where it is under debian/tmp anyway. [10:33] hmm, glibc for amd64 didn't build [10:34] Did it fianlly come back with a failure? [10:34] Probably the kernel bug again, /me checks. [10:34] No build log yet. [10:34] Where do you see the failure? [10:38] Hmm, no env variable for disabling libffi? [10:43] no, set with_libffi by hand ... [10:43] adding it in 4.0 [10:46] Thanks. =) [11:22] The dh_link failed. I've taken off the leading /'s but I screwed up the debuild command so I have to redo the build again. *sigh* [11:36] lamont, elmo: I updated chinstrap:~doko/cxxapps.txt, removing most of the C++ apps, after checking, that the dependencies are in. KDE stuff and stuff with mozilla-dev deps is still blocked. this new list could be updated anytime on the buildds. [11:39] then htmldoc needs to be built, which is a build-dep for fltk1.1. after fltk1.1 is built, the new cxxapps.txt can be enabled for the package syncing/package uploading. [11:50] BAH! found the second typo. =) [11:50] testing. [11:54] Hmm, it's still not putting everything in the right place, although the package run goes fine. [11:54] doko: Each line of that dh_link bit that I pasted above needs to grow \'s. =) [11:55] I'm guessing that I disabled too much, though, since it didn't make a libgcc1 package at all. [11:55] Oh. hmm. [11:55] No, that would probably be disabled for 3.4 [11:55] *sigh* [11:55] So I quite possibly have a gcc-3.4 package that would work. =)