/srv/irclogs.ubuntu.com/2005/05/29/#ubuntu-toolchain.txt

lamontmoo12:16
lamontelmo: I don't recall seeing a reject for icu...12:18
Riddelllamont: error on powerpc kdebindings compile "virtual memory exhausted: Cannot allocate memory"12:36
lamontRiddell: most cool.12:38
lamontwhich machine?12:38
lamont(top of the file...)12:39
RiddellAutomatic build of kdebindings_4:3.4.0-0ubuntu3 on ross by sbuild/powerpc 1.170.512:39
=== lamont will give it back
jbaileydoko: Feh, shwab's fix doesn't seem to work.12:45
jbaileyIt's actually in there this time, and it's the right test, but I still get the failure.12:45
jbaileyOh, hm..12:45
jbaileylt-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 value12:45
jbaileyFAIL: bootstrap with --static12:45
jbaileyfeh, I thought this chroot was up to date.12:46
jbaileyNo, gcc is point at 4.0.  So why the 3.3.6 reference?12:48
jbaileyRight, so I'm on total crack.12:51
jbaileyTwo tabs to the machine, one is in the chroot, one is not.12:51
jbaileyRan the build in the wrong tab.12:51
jbailey=)12:51
dokoheh, /etc/debian_chroot in the prompt is your friend ;)12:52
jbaileyThe sad part is that it's even there =)12:52
jbaileyI'm still not used to having bind mounts of my home dir in the chroots.12:53
jbaileyI have a new libc6-ppc64 that's current with what I'm going to upload RSN.  Do you want it for anything?12:53
dokohmm, 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 well12:55
jbaileyJoy.12:56
jbaileydoko: I'm going to look at gcc-4.0 for biarch ppc64 now.  That's what waldi said he was working with.12:56
jbaileydoko: Have a good night.12:57
dokonight12:58
lamont /build/buildd/arts-1.4.0/./mcop/dynamicskeleton.cc:205: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:10101:12
lamontPlease submit a full bug report,01:12
lamontwith preprocessed source if appropriate.01:12
lamontSee <URL:http://gcc.gnu.org/bugs.html> for instructions.01:12
lamontICE baby!01:12
lamontarts/hppa01:12
lamontthat's with the -7ubuntu6hppa2 compiler01:12
=== lamont_r [~lamont@phantom.acmeps.com] has joined #ubuntu-toolchain
danielsice ice baby02:17
=== daniels giggles:
daniels  ICE:02:19
daniels        * configure.ac:02:19
daniels        Add ICE_t #define required by Xtrans headers. Replace static defines02:19
daniels        of LOCALCONN & UNIXCONN with new XTRANS_CONNECTION_FLAGS macro.02:19
=== elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain
jbaileydoko: home/jbailey/Programming/packaging/glibc/glibc-2.3.5/build-tree/ia64-libc/csu/crtn.S:22: Error: `_init#' was not defined within procedure05: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 procedure05:15
jbaileydoko: That's building glibc with binutils 2.1605:15
jbaileyI got curious about the failure, since it claims that it's a TLS mismatch within glibc.05:16
jbaileySo 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
jbaileyThe 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.html05:16
=== doko [~doko___@dsl-082-082-196-023.arcor-ip.net] has joined #ubuntu-toolchain
fabbionemorning05:55
fabbioneyay... build-dep madness06:01
jbaileySeem CVS HEAD of glibc has a fix for the _init# stuff in the new binutils.07:03
jbaileyOff to sleep in the meantime....07:05
=== 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"]
fabbionedoko: you around?10:36
dokomorning fabbione11:14
fabbionemorning dude11:14
fabbionedoko: the latest bash fails on sparc :(11:15
fabbionei am trying to build it manuallt11:15
fabbionebut it hangs on a test case11:15
fabbionelike the original one was doing on all arches11:15
fabbionerun-jobs11:15
fabbioneand it hangs there11:15
fabbione27342 pts/0    S+     0:00 /home/sparcbuildd/bash-3.0/build-bash/bash ./jobs.tests11:16
fabbione27343 pts/0    R+     2:19 /home/sparcbuildd/bash-3.0/build-bash/bash ./jobs1.sub11:16
fabbionethese are the jobs running11:16
dokohmm ... didn't see this on the other archs11:16
fabbionejobs.tests is the main caller11:16
fabbioneyeah i know11:16
fabbionejobs1.sub is running (100% of CPU)11:16
fabbionebut stracing:11:16
fabbionewaitpid(-1, 0xefffed8c, WUNTRACED|0x8)  = -1 EINVAL (Invalid argument)11:16
fabbioneit's a infinite seq of the above11:17
dokoamu reported something like this on amd6411:17
fabbionewhat info can i provide you to check what is wrong?11:17
dokocan you try to compile with 3.3 as a workaround to lower the urgency?11:18
fabbionedoko: sure..11:20
fabbionechecking for sparc-linux-gnu-gcc... gcc-3.311:21
fabbioneit's building11:21
fabbionei just forced CC=gcc-3.3 in debian/rules11:24
fabbionei guess that should be enough....11:24
dokogcc-3.3 build for sparc:11:25
dokodebian/rules.d/binary-libstdcxx.mk: line 226: add a mkdir -p $(d)/$(gcc_lib_dir)/6411:26
dokosparc is our only biarch gcc-3.311:26
fabbionedoko: ok, do you want me to upload it? or will you?11:27
fabbioneor do you want me to do a test-build before upload?11:28
dokohave to do other fixes as well (dpkg-architecture things)11:30
fabbioneok11:31
fabbionedid you also start building gcc-3.4?11:32
fabbionei will pass by later.. gotta cook lunch11:34
fabbionewife is sick11:34
fabbioneand my "attributes" are breaking down11:34
dokohmm, it's something else, the compiler isn't built biarch :-(11:36
\shguys.../usr/X11R6/include/X11/Xlib.h should be normally /usr/include/X11/Xlib.h, right? I'm a bit confused right now ;)11:39
daniels\sh: <X11/Xlib.h> is guaranteed to exist if you have libx11-dev installed and -I/usr/X11R6/include12:51
danielsit may be in /usr/X11R6/include/X11/Xlib.h (where it is right now), or it may be in /usr/include/X11/Xlib.h12:51
daniels(where it will be soonish)12:51
dokohi daniels 12:57
dokowhat is soonish? we could wait fixing stuff, when it ends in /usr/include soon12:58
danielsdoko: maybe next week, I don't know.  depends on how much time I have to spend working on other stuff01:00
dokoheh, it would _save_ lots of work for other people ;)01:01
fabbionedoko: compiling with gcc-3.3 makes no difference01:15
fabbionethe test case still hangs01:16
dokohmm01:21
dokofound out, that we don't configure gcc-3.3 as biarch for sparc anymore, some more dpkg-architecture fallout01:21
fabbionedoko: amen....01:24
dokosorry, didn't see it on the other archs01:25
fabbionedoko: don't worry.. it's fixable :)01:26
dokobefore 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
danielsdoko: how many packages are ftbfs because of it?  i didn't think it was too many01:27
fabbionedoko: i don't care :)01:27
dokodaniels: from the 50 I did upload 3 or 4.01:27
fabbioneyou guys are the toolcrap maintainers :)01:28
danielsdoko: heh01:28
fabbioneanyway.. i need to wash dishes.. and later F1 :)01:28
elmothings generally broke because they were testing the output of dpkg-architecture right?01:28
dokoelmo: yes01:28
elmoit wouldn't be hard to grep the source and see how many packages are even using that01:29
dokoyou get many false positives, if you grep for GNU_TYPE01:29
dokoand you miss many, if you grep for dpkg-architecture01:30
elmohow come?01:30
elmoI mean just: a) get a list of packagers using dpkg-architecture, then b) eyeball them to see what they're checking01:30
elmo+ for01:30
elmos/rs/s/01:30
dokoyes, but you can use *_GNU_TYPE without calling dpkg-architecture, can't you?01:31
elmoerr, how?01:31
dokoor is on only *_ARCH set by dpkg-buildpackage?01:31
dokono, they are all set by default01:35
dokoelmo: 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:38
dokoadd the -gnu for <arch>-linux, or remove it?01:39
elmogar, that's so much crack01:47
elmowell can we not grep for DEB_HOST/DEB_TARGET ?01:47
elmodoko: I dunno - has keybuk appeared yet? 01:47
elmoI'd really like to know why this change was made01:47
dokono, i didn't see him after the dpkg upload :(01:48
dokook, 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 broken01:50
fabbioneF1 is starting...01:57
fabbioneops01:57
fabbioneECHAN :)01:57
dokofabbione: why do you still watch it, or is it a must to see Ferrari loose? ;-)01:59
fabbionedoko: die! :P02:01
fabbionethere is always a hope02:01
danielsof what, Ferrari losing? :)02:01
fabbionei guess Keybuk is upset to death02:02
fabbionesince BAR has been disqualified for 3 races02:02
fabbioneok let see how many damanges at the first turn02:03
fabbioneimpressive02:03
fabbionenot even one!02:03
danielsheh02:03
danielsbar aren't exactly the best, though02:03
fabbionesame quality as dpkg these days02:04
dokoso we should disqualify keybuk as well ;)02:04
fabbioneeheh good point02:04
=== _infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain
=== infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain
dokoelmo: I did upload binutils for breezy to stick with <arch>-linux, need to fix gcc-* now02:37
fabbioneyay02:51
fabbionedoes that mean another gcc-* upload round?02:51
dokoyes, starting with 3.302:53
fabbionegood.. i am happy i didn't build 3.4 yet :)02:53
=== jbailey fades into reality.
=== cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain
cartmanjbailey: low priority ping03:43
jbaileycartman: 'sup?03:43
dokohi jbailey03:43
cartmanjbailey: is a binutils 2.16 update planned? I guess you take care of binutils too?03:43
dokodo you plan any gcc uploads today?03:43
jbaileydoko: Heya Matthias.03:44
jbailey'take care of' is the wrong term for my relationship with the toolchain.03:44
jbaileyBut 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
doko2.16.1 is scheduled for next week03:45
jbaileydoko: 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:45
dokowhich arch?03:46
jbaileyppc6403:46
dokowith 3.4?03:46
jbaileyI have it, and it's local, so I figured I'd use that to learn the biarch setup.03:46
dokowhat does gcc-3.4 -v say?03:47
cartmanjbailey: thanks for info. whats the right term btw? :) for your relationship with toolchain?03:47
jbaileyI tried both 4.0 and 3.403:47
jbaileyI 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:47
jbaileyjbailey@ppc64:~$ gcc-3.4 -v03:48
jbaileyLecture des spcification  partir de /usr/lib/gcc/powerpc-linux/3.4.4/specs03:48
jbaileyConfigur 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=gt03:48
jbaileyk --enable-targets=powerpc-linux,powerpc64-linux --disable-softfloat --disable-softfloat powerpc-linux03:48
jbaileyModle de thread: posix03:48
jbaileyversion gcc 3.4.4 20050408 (prerelease) (Debian 3.4.3-13ubuntu1)03:48
jbaileydoko: It produces a hello world binary with gcc-3.4 -m6403:48
dokohmm, does it really need --enable-targets=powerpc-linux,powerpc64-linux ?03:49
dokooh, yes, you are right, that is a change from 2005-03-3103:52
dokoat least for 3.403:52
jbaileydoko: 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:53
jbaileyAh, I see Modra's change, right.03:54
jbaileyI had been thinking it was entirely the packaging, my bad.03:54
dokojbailey, I'll leave early on Tuesday, so maybe Wednesday.03:54
jbaileydoko: Sounds lovely.03:54
jbaileydoko: 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
dokoI'll do one more upload today to fix more dpkg stuff ...03:55
jbaileydoko: It'll make the OOo stuff you're doing a bit easier for me to fix.03:55
dokoyes, sounds good03:56
jbaileydoko: Lovely, so I'll test that config after I get this running too.03:56
jbaileydoko: 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:57
dokocool03:58
=== Seveas [~seveas@83.160.7.26] has joined #ubuntu-toolchain
jbaileycartman: You could probably say 'quite interested' and 'stupid enough to hack on it when I need to'04:10
cartmanjbailey: ok :)04:10
cartmanjbailey: one of the tough things to mess04:11
cartmanso kudos to you :)04:11
=== jbailey points to doko.
jbaileycartman: Give him kudo's, he's the true madman. =)04:13
=== cartman bows to doko
cartman=)04:13
cartmanand the debian maintainer the japanese guy I can't spell his name :/04:13
jbaileydoko: 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:09
jbaileydoko: 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:10
\shah jbailey :) 05:17
\shthe right person05:17
jbailey\sh: Eh?05:28
jbailey\sh: I'm just wandering off to play a video game...  Anything you need urgently?05:28
\shjbailey: problem with cdbs magic05:28
jbaileyJoy.05:28
jbailey'sup?05:29
\sharkrpg...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
\shso whats the best way to take diffs for it ;)05:29
jbaileyUsually 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
jbaileyIn that case, I often fix upstream though and try to get them on a recent version of automake and autoconf.05:31
jbaileyThere's also some stuff in the autotools.mk that you can use to auto update config.sub and config.guess05:31
\shjbailey: i read about it, but I also read that it can break ;)05:31
\shanyways, the tarball method I was thinking about :)05:32
jbaileytarball method is a bit nicer for that05:32
jbaileysimple-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:32
\shapplying the patches from the debian packages beforehand, then do the work inside the source, take the patches and diff 05:33
jbaileyYup.05:33
jbaileyWe need a make_patch method.05:33
jbaileyAgain patches welcome, but you'd probably be happier hacking it into cdbs2.05:33
\shjbailey: well..I would like to exchange simple-patchsys with dpatch magic05:33
jbaileyUgh.05:33
jbaileyI'd really like to see dpatch go away.05:33
\shwhy? 05:34
jbaileySimple-patchsys does a better job in that you don't have to add crap to the top of each patch.05:34
jbaileyAnd simple-patchsys will auto detect -p0 -p1 or -p205:34
\shok...let me try this out :) 05:34
jbaileyWhat we really need is all of the dpatch magic for handling patch files with simple-patchsys' application methods.05:34
jbaileyCool, I'll be lagging for about 90 minutes to play a round, I'll check in after.05:35
\shjbailey: can I use the orig.tar.gz ? or should I use a real clean one05:35
\shsorry ;)05:35
jbaileyFor 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 .orig05:36
jbaileyYou 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
jbaileyReally off now.05:36
jbailey=)05:36
\shjbailey: thx and have fun now :)05:37
\shanybody up for some libGLU.so.1.3 magic?? ,-)06:20
=== cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain
fabbione  xorg_6.8.2-16: successful06:49
fabbioneGO DANIELS!06:49
cartmanxbase-clients still depend on xlibmesa-glu instead of  libglu1-xorg06:51
cartmanin case its simple to fix :/06:51
\shcartman: right06:51
\shwe have to recompile some packages after it's fixed i think06:52
cartmanyup06:52
\shkdelibs4c2 etc. gksu bla06:52
cartmanbzflag,libfox, rezound and some more possibly06:52
cartmanbut they might be from universe06:53
cartmannot sure06:53
fabbionecartman, \sh: it's pointless to spend too much time fixing xorg as it is07:01
fabbionethe only reason why it is still there is to provied build-deps for other packages07:01
cartmanfabbione: well lemme know when you want to hear whats borked =)07:01
fabbionexorg as source will die pretty soon and fast07:01
fabbioneno we don't really care because we are going modular07:01
\shfabbione: so, replacing Build-Deps: xlibmesa-glu with libglu1-xorg?07:01
fabbioneonce we are modular we will care again07:01
fabbione\sh: it depends on what package, but yeah that should be it07:02
\shdoko: please review your kdelibsc2 patch ;)07:02
doko\sh, there's nothing wrong with the patch, it's the *ing xorg reorganisation at the wrong time07:03
fabbionedoko: can i build gcc-3.* on sparc or should i expect failures?07:03
dokofabbione: it "should" work ...07:04
fabbionedoko: ok.07:04
fabbionein that case i don't mind trashing a few hours :)07:04
fabbioneif it doesn't i am going to bitch slap you :P07:04
\shdoko: hmmm..libglu1-xorg is replacing xlibmesa-glu so kdelibs4c2 will be removed as well..07:05
\shbut it could be more worse...07:05
fabbione\sh: please ... don't worry..07:06
fabbioneall this stuff will be sorted pretty soon07:06
\shah...I'm a bit tired ;) I just fixed one error and the next is approaching 07:06
fabbionethere are automatic scripts checking these kind of stuff07:06
fabbioneuhuh binutils... gcc.. glibc...07:08
\shfabbione: so...right now, libglu1-xorg(-dev) is the right package for build-deps07:11
dokono, libglu-dev-xorg07:12
\shor this way ;) but libglu is the right one, linked against libstdc++607:12
cartmanright07:17
cartmanalso libtunepimp2 needs to recompiled with new libmusicbrainzc207:17
\shanyways...it doesn't solve my problems...cause libsdl1.2-dev depends on xlibmesa-glu07:18
cartman\sh: isn't that just a simple depends fix + a recompile ?07:19
\shcartman: 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:00am07:20
cartman\sh: :/07:20
doko\sh, yes, but the real problem is the xbase-client's dependency on xlibmesa-glu, which daniels has to fix07:22
\shdoko: yeah07:22
\shbut tomorrow is also a day...so I have to think about our BMR reboot and Divitech SI Server reboot07:23
\shit means, all non-upgrade dtv network areas in NRW are without DTV at least for 5 mins07:24
\shand those 5 mins means: please report to CTO why this had to be done :(07:25
dokofabbione, daniels: do you know what the replacement for xlibmesa-dev is?07:28
fabbionedoko: no sorry.07:29
fabbionedoko: btw did you read the scrollback? bash with gcc-3.3 still hangs07:31
cartmandoko: libglu1-mesa-dev looks like the xlibmesa-dev replacement07:32
cartmandoko: looking at the conflicts at least07:32
dokohmm, yes, so xlibmesa-dev -> xlibmesa-gl-dev, libglu-dev-xorg07:37
=== doko doesn't like scrollbacks today ...
=== fabbione -> dinner -> cinema
fabbionecya tomorrow guys07:41
dokosee you, sparc toolcarp builder ;)07:42
jbaileytoolcarp?07:48
dokos/ar/ra/g07:51
jbaileyI was imagining a fish with "gcc" written on the side. =)07:53
dokosparcling carp ?07:55
jbaileydoko: That sounds like a nasty drink. =)07:55
jbaileyFizzy cod liver oil. =)07:55
jbaileydoko: 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-linux08:25
jbaileydoko: How do you want things like that reported?08:25
dokojbailey: fetch the fresh sources and don't complain ;-P08:36
jbaileyAh, did you upload one newer than this morning?08:36
dokoyep, because it was broken on ia64 and sparc08:37
jbailey'kay.  I'll see how for this build gets first.08:37
dokofinished on i38608:39
jbaileySorry, I mean locally.08:40
jbaileyThe biarch one.08:40
jbaileyShould 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:41
jbaileyafk for food.08:43
dokohmm, yes, we could, but the libraries aren't convert yet, some are still missing08:44
dokodaniels: 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:00
=== zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain
jbaileydoko: Right, but there's a few steps done that we should probably have listed there.09:40
jbaileydoko: 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
jbaileyzul: Heya Chuck.09:40
zulhey jeff how goes?09:56
jbaileyzul: Good, just on the phone. =)10:03
jbaileyBuild finishes, produces libgcc_s_64.so this time, sweet.10:20
jbaileythere's a bad dh_link call, I'll tweak it.10:21
jbaileyBut aside from that I might have a useful biarch ppc64 toolchain now, yay. =)10:21
dokojbailey: which package?10:28
jbaileydoko: gcc-3.4 in rules.d/binary-gcc.mk10:31
jbaileyLemme open an Xterm so I can cut and passte.10:31
jbaileyUnder the ifeq ($(biarch),yes)10:31
dokohmm, glibc for amd64 did not build10:31
jbaileyI think it should probably be:10:31
jbailey        dh_link -p$(p_gcc) \10:32
jbailey          /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/libgcc_s_64.so10:32
jbailey          /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/64/libgcc_s_64.so10:32
jbailey          /$(PF)/$(lib64)/libgcc_s.so.$(GCC_SONAME) /$(gcc_lib_dir)/64/libgcc_s.so10:32
jbaileyYou didn't have the $(PF) in there.10:32
dokook, not /lib64, but /usr/lib6410:33
jbaileyRight, that's where it is under debian/tmp anyway.10:33
dokohmm, glibc for amd64 didn't build10:33
jbaileyDid it fianlly come back with a failure?10:34
jbaileyProbably the kernel bug again, /me checks.10:34
jbaileyNo build log yet.10:34
jbaileyWhere do you see the failure?10:34
jbaileyHmm, no env variable for disabling libffi?10:38
dokono, set with_libffi by hand ...10:43
dokoadding it in 4.010:43
jbaileyThanks. =)10:46
jbaileyThe 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:22
dokolamont, 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:36
dokothen 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:39
jbaileyBAH! found the second typo. =)11:50
jbaileytesting.11:50
jbaileyHmm, it's still not putting everything in the right place, although the package run goes fine.11:54
jbaileydoko:  Each line of that dh_link bit that I pasted above needs to grow \'s. =)11:54
jbaileyI'm guessing that I disabled too much, though, since it didn't make a libgcc1 package at all.11:55
jbaileyOh. hmm.11:55
jbaileyNo, that would probably be disabled for 3.411:55
jbailey*sigh*11:55
jbaileySo I quite possibly have a gcc-3.4 package that would work. =)11:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!