lamont | moo | 12:16 |
---|---|---|
lamont | elmo: I don't recall seeing a reject for icu... | 12:18 |
Riddell | lamont: error on powerpc kdebindings compile "virtual memory exhausted: Cannot allocate memory" | 12:36 |
lamont | Riddell: most cool. | 12:38 |
lamont | which machine? | 12:38 |
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:39 |
=== lamont will give it back | ||
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:45 |
jbailey | feh, I thought this chroot was up to date. | 12:46 |
jbailey | No, gcc is point at 4.0. So why the 3.3.6 reference? | 12:48 |
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:51 |
doko | heh, /etc/debian_chroot in the prompt is your friend ;) | 12:52 |
jbailey | The sad part is that it's even there =) | 12:52 |
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:53 |
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:55 |
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:56 |
jbailey | doko: Have a good night. | 12:57 |
doko | night | 12: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: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 | 01:12 |
=== lamont_r [~lamont@phantom.acmeps.com] has joined #ubuntu-toolchain | ||
daniels | ice ice baby | 02:17 |
=== daniels giggles: | ||
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. | 02:19 |
=== elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain | ||
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:15 |
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:16 |
=== doko [~doko___@dsl-082-082-196-023.arcor-ip.net] has joined #ubuntu-toolchain | ||
fabbione | morning | 05:55 |
fabbione | yay... build-dep madness | 06:01 |
jbailey | Seem CVS HEAD of glibc has a fix for the _init# stuff in the new binutils. | 07:03 |
jbailey | Off 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"] | ||
fabbione | doko: you around? | 10:36 |
doko | morning fabbione | 11:14 |
fabbione | morning dude | 11:14 |
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:15 |
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:16 |
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:17 |
doko | can you try to compile with 3.3 as a workaround to lower the urgency? | 11:18 |
fabbione | doko: sure.. | 11:20 |
fabbione | checking for sparc-linux-gnu-gcc... gcc-3.3 | 11:21 |
fabbione | it's building | 11:21 |
fabbione | i just forced CC=gcc-3.3 in debian/rules | 11:24 |
fabbione | i guess that should be enough.... | 11:24 |
doko | gcc-3.3 build for sparc: | 11:25 |
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:26 |
fabbione | doko: ok, do you want me to upload it? or will you? | 11:27 |
fabbione | or do you want me to do a test-build before upload? | 11:28 |
doko | have to do other fixes as well (dpkg-architecture things) | 11:30 |
fabbione | ok | 11:31 |
fabbione | did you also start building gcc-3.4? | 11:32 |
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:34 |
doko | hmm, it's something else, the compiler isn't built biarch :-( | 11:36 |
\sh | guys.../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/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:51 |
doko | hi daniels | 12:57 |
doko | what is soonish? we could wait fixing stuff, when it ends in /usr/include soon | 12:58 |
daniels | doko: maybe next week, I don't know. depends on how much time I have to spend working on other stuff | 01:00 |
doko | heh, it would _save_ lots of work for other people ;) | 01:01 |
fabbione | doko: compiling with gcc-3.3 makes no difference | 01:15 |
fabbione | the test case still hangs | 01:16 |
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:21 |
fabbione | doko: amen.... | 01:24 |
doko | sorry, didn't see it on the other archs | 01:25 |
fabbione | doko: don't worry.. it's fixable :) | 01:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
doko | no, they are all set by default | 01:35 |
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:38 |
doko | add the -gnu for <arch>-linux, or remove it? | 01:39 |
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:47 |
doko | no, i didn't see him after the dpkg upload :( | 01:48 |
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:50 |
fabbione | F1 is starting... | 01:57 |
fabbione | ops | 01:57 |
fabbione | ECHAN :) | 01:57 |
doko | fabbione: why do you still watch it, or is it a must to see Ferrari loose? ;-) | 01:59 |
fabbione | doko: die! :P | 02:01 |
fabbione | there is always a hope | 02:01 |
daniels | of what, Ferrari losing? :) | 02:01 |
fabbione | i guess Keybuk is upset to death | 02:02 |
fabbione | since BAR has been disqualified for 3 races | 02:02 |
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:03 |
fabbione | same quality as dpkg these days | 02:04 |
doko | so we should disqualify keybuk as well ;) | 02:04 |
fabbione | eheh good point | 02:04 |
=== _infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain | ||
=== infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain | ||
doko | elmo: I did upload binutils for breezy to stick with <arch>-linux, need to fix gcc-* now | 02:37 |
fabbione | yay | 02:51 |
fabbione | does that mean another gcc-* upload round? | 02:51 |
doko | yes, starting with 3.3 | 02:53 |
fabbione | good.. 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 | ||
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:43 |
jbailey | doko: Heya Matthias. | 03:44 |
jbailey | 'take care of' is the wrong term for my relationship with the toolchain. | 03:44 |
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:45 |
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:46 |
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:47 |
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:48 |
doko | hmm, does it really need --enable-targets=powerpc-linux,powerpc64-linux ? | 03:49 |
doko | oh, yes, you are right, that is a change from 2005-03-31 | 03:52 |
doko | at least for 3.4 | 03:52 |
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:53 |
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:54 |
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:55 |
doko | yes, sounds good | 03:56 |
jbailey | doko: Lovely, so I'll test that config after I get this running too. | 03:56 |
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:57 |
doko | cool | 03:58 |
=== Seveas [~seveas@83.160.7.26] has joined #ubuntu-toolchain | ||
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:10 |
cartman | jbailey: one of the tough things to mess | 04:11 |
cartman | so kudos to you :) | 04:11 |
=== jbailey points to doko. | ||
jbailey | cartman: Give him kudo's, he's the true madman. =) | 04:13 |
=== cartman bows to doko | ||
cartman | =) | 04:13 |
cartman | and the debian maintainer the japanese guy I can't spell his name :/ | 04:13 |
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:09 |
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:10 |
\sh | ah jbailey :) | 05:17 |
\sh | the right person | 05:17 |
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:28 |
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:29 |
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:31 |
\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:32 |
\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:33 |
\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:34 |
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:35 |
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:36 |
\sh | jbailey: thx and have fun now :) | 05:37 |
\sh | anybody 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: successful | 06:49 |
fabbione | GO DANIELS! | 06:49 |
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:51 |
\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:52 |
cartman | but they might be from universe | 06:53 |
cartman | not sure | 06:53 |
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:01 |
fabbione | \sh: it depends on what package, but yeah that should be it | 07:02 |
\sh | doko: 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 time | 07:03 |
fabbione | doko: can i build gcc-3.* on sparc or should i expect failures? | 07:03 |
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:04 |
\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:05 |
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:06 |
fabbione | uhuh binutils... gcc.. glibc... | 07:08 |
\sh | fabbione: so...right now, libglu1-xorg(-dev) is the right package for build-deps | 07:11 |
doko | no, libglu-dev-xorg | 07:12 |
\sh | or this way ;) but libglu is the right one, linked against libstdc++6 | 07:12 |
cartman | right | 07:17 |
cartman | also libtunepimp2 needs to recompiled with new libmusicbrainzc2 | 07:17 |
\sh | anyways...it doesn't solve my problems...cause libsdl1.2-dev depends on xlibmesa-glu | 07:18 |
cartman | \sh: isn't that just a simple depends fix + a recompile ? | 07:19 |
\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:20 |
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:22 |
\sh | but tomorrow is also a day...so I have to think about our BMR reboot and Divitech SI Server reboot | 07:23 |
\sh | it means, all non-upgrade dtv network areas in NRW are without DTV at least for 5 mins | 07:24 |
\sh | and those 5 mins means: please report to CTO why this had to be done :( | 07:25 |
doko | fabbione, daniels: do you know what the replacement for xlibmesa-dev is? | 07:28 |
fabbione | doko: no sorry. | 07:29 |
fabbione | doko: btw did you read the scrollback? bash with gcc-3.3 still hangs | 07:31 |
cartman | doko: libglu1-mesa-dev looks like the xlibmesa-dev replacement | 07:32 |
cartman | doko: looking at the conflicts at least | 07:32 |
doko | hmm, yes, so xlibmesa-dev -> xlibmesa-gl-dev, libglu-dev-xorg | 07:37 |
=== doko doesn't like scrollbacks today ... | ||
=== fabbione -> dinner -> cinema | ||
fabbione | cya tomorrow guys | 07:41 |
doko | see you, sparc toolcarp builder ;) | 07:42 |
jbailey | toolcarp? | 07:48 |
doko | s/ar/ra/g | 07:51 |
jbailey | I was imagining a fish with "gcc" written on the side. =) | 07:53 |
doko | sparcling carp ? | 07:55 |
jbailey | doko: That sounds like a nasty drink. =) | 07:55 |
jbailey | Fizzy cod liver oil. =) | 07:55 |
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:25 |
doko | jbailey: fetch the fresh sources and don't complain ;-P | 08:36 |
jbailey | Ah, did you upload one newer than this morning? | 08:36 |
doko | yep, because it was broken on ia64 and sparc | 08:37 |
jbailey | 'kay. I'll see how for this build gets first. | 08:37 |
doko | finished on i386 | 08:39 |
jbailey | Sorry, I mean locally. | 08:40 |
jbailey | The biarch one. | 08:40 |
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:41 |
jbailey | afk for food. | 08:43 |
doko | hmm, yes, we could, but the libraries aren't convert yet, some are still missing | 08:44 |
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:00 |
=== zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain | ||
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:40 |
zul | hey jeff how goes? | 09:56 |
jbailey | zul: Good, just on the phone. =) | 10:03 |
jbailey | Build finishes, produces libgcc_s_64.so this time, sweet. | 10:20 |
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:21 |
doko | jbailey: which package? | 10:28 |
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:31 |
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:32 |
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:33 |
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:34 |
jbailey | Hmm, no env variable for disabling libffi? | 10:38 |
doko | no, set with_libffi by hand ... | 10:43 |
doko | adding it in 4.0 | 10:43 |
jbailey | Thanks. =) | 10:46 |
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:22 |
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:36 |
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:39 |
jbailey | BAH! found the second typo. =) | 11:50 |
jbailey | testing. | 11:50 |
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:54 |
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. =) | 11:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!