[12:16] <lamont> moo
[12:18] <lamont> elmo: I don't recall seeing a reject for icu...
[12:36] <Riddell> lamont: error on powerpc kdebindings compile "virtual memory exhausted: Cannot allocate memory"
[12:38] <lamont> Riddell: most cool.
[12:38] <lamont> which machine?
[12:39] <lamont> (top of the file...)
[12:39] <Riddell> Automatic build of kdebindings_4:3.4.0-0ubuntu3 on ross by sbuild/powerpc 1.170.5
[12:45] <jbailey> doko: Feh, shwab's fix doesn't seem to work.
[12:45] <jbailey> It's actually in there this time, and it's the right test, but I still get the failure.
[12:45] <jbailey> Oh, hm..
[12:45] <jbailey> 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] <jbailey> /usr/lib/gcc-lib/ia64-linux/3.3.6/../../../libc.a: could not read symbols: Bad value
[12:45] <jbailey> FAIL: bootstrap with --static
[12:46] <jbailey> feh, I thought this chroot was up to date.
[12:48] <jbailey> No, gcc is point at 4.0.  So why the 3.3.6 reference?
[12:51] <jbailey> Right, so I'm on total crack.
[12:51] <jbailey> Two tabs to the machine, one is in the chroot, one is not.
[12:51] <jbailey> Ran the build in the wrong tab.
[12:51] <jbailey> =)
[12:52] <doko> heh, /etc/debian_chroot in the prompt is your friend ;)
[12:52] <jbailey> The sad part is that it's even there =)
[12:53] <jbailey> I'm still not used to having bind mounts of my home dir in the chroots.
[12:53] <jbailey> 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] <doko> 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] <jbailey> Joy.
[12:56] <jbailey> 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] <jbailey> doko: Have a good night.
[12:58] <doko> night
[01:12] <lamont>  /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] <lamont> Please submit a full bug report,
[01:12] <lamont> with preprocessed source if appropriate.
[01:12] <lamont> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
[01:12] <lamont> ICE baby!
[01:12] <lamont> arts/hppa
[01:12] <lamont> that's with the -7ubuntu6hppa2 compiler
[02:17] <daniels> ice ice baby
[02:19] <daniels>   ICE:
[02:19] <daniels>         * configure.ac:
[02:19] <daniels>         Add ICE_t #define required by Xtrans headers. Replace static defines
[02:19] <daniels>         of LOCALCONN & UNIXCONN with new XTRANS_CONNECTION_FLAGS macro.
[05:15] <jbailey> 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] <jbailey> /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] <jbailey> doko: That's building glibc with binutils 2.16
[05:16] <jbailey> I got curious about the failure, since it claims that it's a TLS mismatch within glibc.
[05:16] <jbailey> 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] <jbailey> 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
[05:55] <fabbione> morning
[06:01] <fabbione> yay... build-dep madness
[07:03] <jbailey> Seem CVS HEAD of glibc has a fix for the _init# stuff in the new binutils.
[07:05] <jbailey> Off to sleep in the meantime....
[10:36] <fabbione> doko: you around?
[11:14] <doko> morning fabbione
[11:14] <fabbione> morning dude
[11:15] <fabbione> doko: the latest bash fails on sparc :(
[11:15] <fabbione> i am trying to build it manuallt
[11:15] <fabbione> but it hangs on a test case
[11:15] <fabbione> like the original one was doing on all arches
[11:15] <fabbione> run-jobs
[11:15] <fabbione> and it hangs there
[11:16] <fabbione> 27342 pts/0    S+     0:00 /home/sparcbuildd/bash-3.0/build-bash/bash ./jobs.tests
[11:16] <fabbione> 27343 pts/0    R+     2:19 /home/sparcbuildd/bash-3.0/build-bash/bash ./jobs1.sub
[11:16] <fabbione> these are the jobs running
[11:16] <doko> hmm ... didn't see this on the other archs
[11:16] <fabbione> jobs.tests is the main caller
[11:16] <fabbione> yeah i know
[11:16] <fabbione> jobs1.sub is running (100% of CPU)
[11:16] <fabbione> but stracing:
[11:16] <fabbione> waitpid(-1, 0xefffed8c, WUNTRACED|0x8)  = -1 EINVAL (Invalid argument)
[11:17] <fabbione> it's a infinite seq of the above
[11:17] <doko> amu reported something like this on amd64
[11:17] <fabbione> what info can i provide you to check what is wrong?
[11:18] <doko> can you try to compile with 3.3 as a workaround to lower the urgency?
[11:20] <fabbione> doko: sure..
[11:21] <fabbione> checking for sparc-linux-gnu-gcc... gcc-3.3
[11:21] <fabbione> it's building
[11:24] <fabbione> i just forced CC=gcc-3.3 in debian/rules
[11:24] <fabbione> i guess that should be enough....
[11:25] <doko> gcc-3.3 build for sparc:
[11:26] <doko> debian/rules.d/binary-libstdcxx.mk: line 226: add a mkdir -p $(d)/$(gcc_lib_dir)/64
[11:26] <doko> sparc is our only biarch gcc-3.3
[11:27] <fabbione> doko: ok, do you want me to upload it? or will you?
[11:28] <fabbione> or do you want me to do a test-build before upload?
[11:30] <doko> have to do other fixes as well (dpkg-architecture things)
[11:31] <fabbione> ok
[11:32] <fabbione> did you also start building gcc-3.4?
[11:34] <fabbione> i will pass by later.. gotta cook lunch
[11:34] <fabbione> wife is sick
[11:34] <fabbione> and my "attributes" are breaking down
[11:36] <doko> 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] <daniels> \sh: <X11/Xlib.h> is guaranteed to exist if you have libx11-dev installed and -I/usr/X11R6/include
[12:51] <daniels> 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] <daniels> (where it will be soonish)
[12:57] <doko> hi daniels 
[12:58] <doko> what is soonish? we could wait fixing stuff, when it ends in /usr/include soon
[01:00] <daniels> doko: maybe next week, I don't know.  depends on how much time I have to spend working on other stuff
[01:01] <doko> heh, it would _save_ lots of work for other people ;)
[01:15] <fabbione> doko: compiling with gcc-3.3 makes no difference
[01:16] <fabbione> the test case still hangs
[01:21] <doko> hmm
[01:21] <doko> found out, that we don't configure gcc-3.3 as biarch for sparc anymore, some more dpkg-architecture fallout
[01:24] <fabbione> doko: amen....
[01:25] <doko> sorry, didn't see it on the other archs
[01:26] <fabbione> doko: don't worry.. it's fixable :)
[01:27] <doko> before the next upload, we should decide on the target_alias, is it <cpu>-linux or <cpu>-linux-gnu ? at least binutils and gcc should match.
[01:27] <daniels> doko: how many packages are ftbfs because of it?  i didn't think it was too many
[01:27] <fabbione> doko: i don't care :)
[01:27] <doko> daniels: from the 50 I did upload 3 or 4.
[01:28] <fabbione> you guys are the toolcrap maintainers :)
[01:28] <daniels> doko: heh
[01:28] <fabbione> anyway.. i need to wash dishes.. and later F1 :)
[01:28] <elmo> things generally broke because they were testing the output of dpkg-architecture right?
[01:28] <doko> elmo: yes
[01:29] <elmo> it wouldn't be hard to grep the source and see how many packages are even using that
[01:29] <doko> you get many false positives, if you grep for GNU_TYPE
[01:30] <doko> and you miss many, if you grep for dpkg-architecture
[01:30] <elmo> how come?
[01:30] <elmo> I mean just: a) get a list of packagers using dpkg-architecture, then b) eyeball them to see what they're checking
[01:30] <elmo> + for
[01:30] <elmo> s/rs/s/
[01:31] <doko> yes, but you can use *_GNU_TYPE without calling dpkg-architecture, can't you?
[01:31] <elmo> err, how?
[01:31] <doko> or is on only *_ARCH set by dpkg-buildpackage?
[01:35] <doko> no, they are all set by default
[01:38] <doko> 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] <doko> add the -gnu for <arch>-linux, or remove it?
[01:47] <elmo> gar, that's so much crack
[01:47] <elmo> well can we not grep for DEB_HOST/DEB_TARGET ?
[01:47] <elmo> doko: I dunno - has keybuk appeared yet? 
[01:47] <elmo> I'd really like to know why this change was made
[01:48] <doko> no, i didn't see him after the dpkg upload :(
[01:50] <doko> ok, for now, I'll manally set it to <arch>-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] <fabbione> F1 is starting...
[01:57] <fabbione> ops
[01:57] <fabbione> ECHAN :)
[01:59] <doko> fabbione: why do you still watch it, or is it a must to see Ferrari loose? ;-)
[02:01] <fabbione> doko: die! :P
[02:01] <fabbione> there is always a hope
[02:01] <daniels> of what, Ferrari losing? :)
[02:02] <fabbione> i guess Keybuk is upset to death
[02:02] <fabbione> since BAR has been disqualified for 3 races
[02:03] <fabbione> ok let see how many damanges at the first turn
[02:03] <fabbione> impressive
[02:03] <fabbione> not even one!
[02:03] <daniels> heh
[02:03] <daniels> bar aren't exactly the best, though
[02:04] <fabbione> same quality as dpkg these days
[02:04] <doko> so we should disqualify keybuk as well ;)
[02:04] <fabbione> eheh good point
[02:37] <doko> elmo: I did upload binutils for breezy to stick with <arch>-linux, need to fix gcc-* now
[02:51] <fabbione> yay
[02:51] <fabbione> does that mean another gcc-* upload round?
[02:53] <doko> yes, starting with 3.3
[02:53] <fabbione> good.. i am happy i didn't build 3.4 yet :)
[03:43] <cartman> jbailey: low priority ping
[03:43] <jbailey> cartman: 'sup?
[03:43] <doko> hi jbailey
[03:43] <cartman> jbailey: is a binutils 2.16 update planned? I guess you take care of binutils too?
[03:43] <doko> do you plan any gcc uploads today?
[03:44] <jbailey> doko: Heya Matthias.
[03:44] <jbailey> 'take care of' is the wrong term for my relationship with the toolchain.
[03:45] <jbailey> 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] <doko> 2.16.1 is scheduled for next week
[03:45] <jbailey> 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] <doko> which arch?
[03:46] <jbailey> ppc64
[03:46] <doko> with 3.4?
[03:46] <jbailey> I have it, and it's local, so I figured I'd use that to learn the biarch setup.
[03:47] <doko> what does gcc-3.4 -v say?
[03:47] <cartman> jbailey: thanks for info. whats the right term btw? :) for your relationship with toolchain?
[03:47] <jbailey> I tried both 4.0 and 3.4
[03:47] <jbailey> 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> jbailey@ppc64:~$ gcc-3.4 -v
[03:48] <jbailey> Lecture des spcification  partir de /usr/lib/gcc/powerpc-linux/3.4.4/specs
[03:48] <jbailey> 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] <jbailey> k --enable-targets=powerpc-linux,powerpc64-linux --disable-softfloat --disable-softfloat powerpc-linux
[03:48] <jbailey> Modle de thread: posix
[03:48] <jbailey> version gcc 3.4.4 20050408 (prerelease) (Debian 3.4.3-13ubuntu1)
[03:48] <jbailey> doko: It produces a hello world binary with gcc-3.4 -m64
[03:49] <doko> hmm, does it really need --enable-targets=powerpc-linux,powerpc64-linux ?
[03:52] <doko> oh, yes, you are right, that is a change from 2005-03-31
[03:52] <doko> at least for 3.4
[03:53] <jbailey> 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] <jbailey> Ah, I see Modra's change, right.
[03:54] <jbailey> I had been thinking it was entirely the packaging, my bad.
[03:54] <doko> jbailey, I'll leave early on Tuesday, so maybe Wednesday.
[03:54] <jbailey> doko: Sounds lovely.
[03:55] <jbailey> 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] <doko> I'll do one more upload today to fix more dpkg stuff ...
[03:55] <jbailey> doko: It'll make the OOo stuff you're doing a bit easier for me to fix.
[03:56] <doko> yes, sounds good
[03:56] <jbailey> doko: Lovely, so I'll test that config after I get this running too.
[03:57] <jbailey> 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] <doko> cool
[04:10] <jbailey> cartman: You could probably say 'quite interested' and 'stupid enough to hack on it when I need to'
[04:10] <cartman> jbailey: ok :)
[04:11] <cartman> jbailey: one of the tough things to mess
[04:11] <cartman> so kudos to you :)
[04:13] <jbailey> cartman: Give him kudo's, he's the true madman. =)
[04:13] <cartman> =)
[04:13] <cartman> and the debian maintainer the japanese guy I can't spell his name :/
[05:09] <jbailey> 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] <jbailey> 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] <jbailey> \sh: Eh?
[05:28] <jbailey> \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] <jbailey> Joy.
[05:29] <jbailey> '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] <jbailey> 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] <jbailey> In that case, I often fix upstream though and try to get them on a recent version of automake and autoconf.
[05:31] <jbailey> 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] <jbailey> tarball method is a bit nicer for that
[05:32] <jbailey> 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] <jbailey> (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] <jbailey> Yup.
[05:33] <jbailey> We need a make_patch method.
[05:33] <jbailey> 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] <jbailey> Ugh.
[05:33] <jbailey> I'd really like to see dpatch go away.
[05:34] <\sh> why? 
[05:34] <jbailey> Simple-patchsys does a better job in that you don't have to add crap to the top of each patch.
[05:34] <jbailey> And simple-patchsys will auto detect -p0 -p1 or -p2
[05:34] <\sh> ok...let me try this out :) 
[05:34] <jbailey> What we really need is all of the dpatch magic for handling patch files with simple-patchsys' application methods.
[05:35] <jbailey> 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] <jbailey> 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] <jbailey> You still don't want a Debian Native package.
[05:36] <jbailey> (What we really want is Scott to implement the Wig and Penn proposal.  But *sigh*)
[05:36] <jbailey> Really off now.
[05:36] <jbailey> =)
[05:37] <\sh> jbailey: thx and have fun now :)
[06:20] <\sh> anybody up for some libGLU.so.1.3 magic?? ,-)
[06:49] <fabbione>   xorg_6.8.2-16: successful
[06:49] <fabbione> GO DANIELS!
[06:51] <cartman> xbase-clients still depend on xlibmesa-glu instead of  libglu1-xorg
[06:51] <cartman> 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] <cartman> yup
[06:52] <\sh> kdelibs4c2 etc. gksu bla
[06:52] <cartman> bzflag,libfox, rezound and some more possibly
[06:53] <cartman> but they might be from universe
[06:53] <cartman> not sure
[07:01] <fabbione> cartman, \sh: it's pointless to spend too much time fixing xorg as it is
[07:01] <fabbione> the only reason why it is still there is to provied build-deps for other packages
[07:01] <cartman> fabbione: well lemme know when you want to hear whats borked =)
[07:01] <fabbione> xorg as source will die pretty soon and fast
[07:01] <fabbione> 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] <fabbione> once we are modular we will care again
[07:02] <fabbione> \sh: it depends on what package, but yeah that should be it
[07:02] <\sh> doko: please review your kdelibsc2 patch ;)
[07:03] <doko> \sh, there's nothing wrong with the patch, it's the *ing xorg reorganisation at the wrong time
[07:03] <fabbione> doko: can i build gcc-3.* on sparc or should i expect failures?
[07:04] <doko> fabbione: it "should" work ...
[07:04] <fabbione> doko: ok.
[07:04] <fabbione> in that case i don't mind trashing a few hours :)
[07:04] <fabbione> 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] <fabbione> \sh: please ... don't worry..
[07:06] <fabbione> 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] <fabbione> there are automatic scripts checking these kind of stuff
[07:08] <fabbione> uhuh binutils... gcc.. glibc...
[07:11] <\sh> fabbione: so...right now, libglu1-xorg(-dev) is the right package for build-deps
[07:12] <doko> no, libglu-dev-xorg
[07:12] <\sh> or this way ;) but libglu is the right one, linked against libstdc++6
[07:17] <cartman> right
[07:17] <cartman> 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] <cartman> \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] <cartman> \sh: :/
[07:22] <doko> \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] <doko> fabbione, daniels: do you know what the replacement for xlibmesa-dev is?
[07:29] <fabbione> doko: no sorry.
[07:31] <fabbione> doko: btw did you read the scrollback? bash with gcc-3.3 still hangs
[07:32] <cartman> doko: libglu1-mesa-dev looks like the xlibmesa-dev replacement
[07:32] <cartman> doko: looking at the conflicts at least
[07:37] <doko> hmm, yes, so xlibmesa-dev -> xlibmesa-gl-dev, libglu-dev-xorg
[07:41] <fabbione> cya tomorrow guys
[07:42] <doko> see you, sparc toolcarp builder ;)
[07:48] <jbailey> toolcarp?
[07:51] <doko> s/ar/ra/g
[07:53] <jbailey> I was imagining a fish with "gcc" written on the side. =)
[07:55] <doko> sparcling carp ?
[07:55] <jbailey> doko: That sounds like a nasty drink. =)
[07:55] <jbailey> Fizzy cod liver oil. =)
[08:25] <jbailey> 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] <jbailey> doko: How do you want things like that reported?
[08:36] <doko> jbailey: fetch the fresh sources and don't complain ;-P
[08:36] <jbailey> Ah, did you upload one newer than this morning?
[08:37] <doko> yep, because it was broken on ia64 and sparc
[08:37] <jbailey> 'kay.  I'll see how for this build gets first.
[08:39] <doko> finished on i386
[08:40] <jbailey> Sorry, I mean locally.
[08:40] <jbailey> The biarch one.
[08:41] <jbailey> 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] <jbailey> afk for food.
[08:44] <doko> hmm, yes, we could, but the libraries aren't convert yet, some are still missing
[09:00] <doko> 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.
[09:40] <jbailey> doko: Right, but there's a few steps done that we should probably have listed there.
[09:40] <jbailey> 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] <jbailey> zul: Heya Chuck.
[09:56] <zul> hey jeff how goes?
[10:03] <jbailey> zul: Good, just on the phone. =)
[10:20] <jbailey> Build finishes, produces libgcc_s_64.so this time, sweet.
[10:21] <jbailey> there's a bad dh_link call, I'll tweak it.
[10:21] <jbailey> But aside from that I might have a useful biarch ppc64 toolchain now, yay. =)
[10:28] <doko> jbailey: which package?
[10:31] <jbailey> doko: gcc-3.4 in rules.d/binary-gcc.mk
[10:31] <jbailey> Lemme open an Xterm so I can cut and passte.
[10:31] <jbailey> Under the ifeq ($(biarch),yes)
[10:31] <doko> hmm, glibc for amd64 did not build
[10:31] <jbailey> I think it should probably be:
[10:32] <jbailey>         dh_link -p$(p_gcc) \
[10:32] <jbailey>           /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/libgcc_s_64.so
[10:32] <jbailey>           /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/64/libgcc_s_64.so
[10:32] <jbailey>           /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/64/libgcc_s.so
[10:32] <jbailey> You didn't have the $(PF) in there.
[10:33] <doko> ok, not /lib64, but /usr/lib64
[10:33] <jbailey> Right, that's where it is under debian/tmp anyway.
[10:33] <doko> hmm, glibc for amd64 didn't build
[10:34] <jbailey> Did it fianlly come back with a failure?
[10:34] <jbailey> Probably the kernel bug again, /me checks.
[10:34] <jbailey> No build log yet.
[10:34] <jbailey> Where do you see the failure?
[10:38] <jbailey> Hmm, no env variable for disabling libffi?
[10:43] <doko> no, set with_libffi by hand ...
[10:43] <doko> adding it in 4.0
[10:46] <jbailey> Thanks. =)
[11:22] <jbailey> 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] <doko> 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] <doko> 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] <jbailey> BAH! found the second typo. =)
[11:50] <jbailey> testing.
[11:54] <jbailey> Hmm, it's still not putting everything in the right place, although the package run goes fine.
[11:54] <jbailey> doko:  Each line of that dh_link bit that I pasted above needs to grow \'s. =)
[11:55] <jbailey> I'm guessing that I disabled too much, though, since it didn't make a libgcc1 package at all.
[11:55] <jbailey> Oh. hmm.
[11:55] <jbailey> No, that would probably be disabled for 3.4
[11:55] <jbailey> *sigh*
[11:55] <jbailey> So I quite possibly have a gcc-3.4 package that would work. =)