[12:07] <doko> hmm, libxau-dev and libxdmcp-dev are in the archives. strange, that they cannot be found ...
[12:09] <doko> lamont: ^^^
[12:10] <lamont> missing buildd-deps, I bet
[12:11] <lamont> actually libxdmcp-dev is installed
[12:11] <lamont> no -I/usr/X11R6/include though...
[12:12] <lamont> gcc -c -fsigned-char    -I../.. -I../../exports/include   -Dlinux -D__powerpc__
[12:12] <lamont> +-D_POSIX_C_SOURCE=199309L                              -D_POSIX_SOURCE
[12:12] <lamont> +-D_XOPEN_SOURCE                                -D_BSD_SOURCE -D_SVID_SOURCE
[12:12] <lamont> +-D_GNU_SOURCE                            -DFUNCPROTO=15 -DNARROWPROTO
[12:12] <lamont> +-DXTHREADS  -D_REENTRANT -DXUSE_MTSAFE_API    -DMALLOC_0_RETURNS_NULL
[12:12] <lamont> +-DHAS_SNPRINTF -DLIBX11                        -DPOSTLOCALELIBDIR=\"lib\"
[12:12] <lamont> +-g -O2 -fno-strict-aliasing -g   -DUNIXCONN -DTCPCONN -DHAS_STICKY_DIR_BIT
[12:12] <lamont> +-DHAS_FCHOWN -DIPv6   -DX11_t -DTRANS_CLIENT -DFAIL_HARD   ConnDis.c -o
[12:12] <lamont> +unshared/ConnDis.o
[12:12] <lamont> ConnDis.c:38:23: error: X11/Xauth.h: No such file or directory
=== lamont wonders if maybe they used to come from ../../exports/include
[12:13] <doko> yes, maybe ...
[12:13] <lamont> gst-plugins0.8 is ftbfs on ppc, btw
[12:14] <doko> wuhuhuhu
[12:14] <doko> lamont: lying, take a penalty card
[12:14] <lamont> on which?
[12:15] <doko> http://people.ubuntu.com/~lamont/buildLogs/g/gst-plugins0.8/0.8.8-3ubuntu3/gst-plugins0.8_0.8.8-3ubuntu3_20050523-2138-powerpc-successful.gz
[12:15] <lamont> ah, was ubuntu2 that I looked at.   my bad
[12:15] <lamont> I am taking a penalty card
[12:16] <doko> talking ;)
[12:17] <doko> BOOTSTRAPCFLAGS=-I/usr/include/X11
[12:17] <doko> hmm, but that isn't on the command line either
[12:36] <doko> elmo: libestools1.2 (speech-tools) needs new/main love
[12:38] <elmo> doko: no, it needs to build
[12:38] <elmo> come on dude, these are things you can check yourself
[12:38] <doko> ok, time to go to bed ...
[02:12] <doko> libao is a *_GNU_TYPE victim ...
=== rtcm [~jman@217.129.142.72]  has joined #ubuntu-toolchain
=== lamont gets dragged off
[02:40] <doko> please try to get pike7.6 and then swig1.3 in.
[03:29] <daniels> huh
[03:34] <daniels> so, for what it's worth, -I/usr/X11R6/include won't gain you a thing
[03:38] <daniels> ah, pkg-config and x11proto-core-dev
[03:38] <daniels> yeah, I remembered pkg-config while I was half-asleep, decided it wasn't worth getting back up for
[03:41] <doko> heh, and the package is native
[03:47] <daniels> b-d-i vs b-d?
[03:48] <daniels> ahr, stupid libGLw
[03:48] <doko> you did have Build-Depends-Indep, which is wrong, you build for architecture any, not all
[03:49] <daniels> yeah
[03:50] <doko> would you mind writing down an email, what kind of things changed, which build-deps are likely to be replaced?
[04:00] <daniels> hm?  it's only for two packages that I fucked up on
[04:01] <doko> no, in general: xinerama-dev needs to be added, xlibmesa-glu-dev -> libglu-dev-xorg, and so on ...
[04:02] <daniels> uhm, the xinerama-dev thing has been taken care of long ago, when we broke out xlibs-static-dev before hoary
[04:02] <daniels> the only thing I've changed recently in terms of build-deps is xlibmesa-glu-dev -> libglu-dev-xorg
[04:04] <doko> and libxau-dev was needed for libao ..., and a replacement for xlibmesa-dev, and probably unknown things. *please* write it down, not every MOTU knows about it
[04:08] <daniels> um, again, this has been around since before hoary
[04:08] <daniels> and there's no direct mapping
[04:09] <daniels> there's just 'if it uses this, then it needs this, et al'
[04:13] <doko> yes, *just*. please document it.
[04:13] <doko> good night
[06:11] <fabbione> morning
[06:12] <lamont> morning fabbione 
[06:41] <fabbione> doko: gcc-3.3 did built fine :)
[06:41] <fabbione> 3.4 starting now
=== lamont sleeps
[07:05] <daniels> elmo: when you wake up, could I please have all of xorg's build-deps (in the newest versions) in concordia's chroot?
[07:06] <fabbione> hey daniels 
[07:06] <fabbione> daniels: how difficult it is to switch a crappy Makefile to automake?
[07:07] <daniels> fabbione: not too hard ... program or library?
[07:07] <fabbione> a mix
[07:07] <fabbione> there is a bit of everything :)
[07:07] <daniels> shouldn't be too hard
[07:07] <daniels> heh
[07:07] <daniels> what is it?
[07:08] <fabbione> red hat cluster suite
[07:08] <daniels> ah
[07:08] <daniels> just look at the packaging in xorg/lib/Xau
[07:08] <fabbione> their makefile system is totally retarded
[07:08] <daniels> and add bin_PROGRAMS = foo, foo_SOURCES = bar.c baz.c
[07:11] <fabbione> meh dude... i add that to what?
[07:11] <fabbione> i know >< this much about autocrap
[07:13] <fabbione> i guess i will need to learn it
[07:18] <daniels> add that to Makefile.am
[07:19] <fabbione> i am still puzzled by all the crap :)
=== infinity was considering diving into autotools this week too..
[07:31] <infinity> But then I thought better of it.
[07:33] <fabbione> infinity: let's switch the kernel to autotools :)
[07:53] <infinity> NOOOOOOO!
=== mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #ubuntu-toolchain
[09:15] <doko> morning
[09:15] <fabbione> hey doko
[09:15] <doko> NOOOOOOOOOOOOOOOOOOOOOO
[09:15] <fabbione> ?
[09:15] <doko> Package: x11proto-gl-dev
[09:15] <doko> Conflicts: xlibmesa-gl-dev (<< 6.8.2-19), xlibmesa-glu-dev (<< 6.8.2-19), libglu-dev-xorg (<< 6.8.2-19)
[09:16] <doko> we did just change dozens of packages, now again?
[09:17] <fabbione> doko: and you will keep changing them until the transition is completed
[09:19] <doko> no, I don't change them anymore, he can do it himself, 
[09:20] <doko> and he doesn't want to document/tell the needed changes
[09:22] <daniels> sigh
[09:23] <daniels> i'm trying not to cause another ftbfs by waiting and testing
[09:23] <daniels> i can dump yet another version into the archive and see how that turns out, but I'd rather not
[09:23] <daniels> no-one needs to change anything
[09:23] <daniels> libglu-dev-xorg in -19 depends on x11proto-gl-dev
[09:23] <daniels> it's just an internal reorganisation
[09:26] <doko> I'll only believe it, when I see it. does -19 fix xbase-clients?
[09:31] <daniels> http://people.ubuntu.com/~daniels/xlibs-static-dev.txt
[09:31] <daniels> and no, it won't, as I explained to you before
[09:32] <daniels> one version needs to get built and accepted, and then the next one will fix xbase-clients
=== chmj [~d3vic3@dumbledore.hbd.com]  has joined #ubuntu-toolchain
[09:46] <daniels> doko: -19 source is uploading to chinstrap now, if you want to upload it then do that, but for the love of god test it in an up-to-date chroot first
[09:46] <daniels> i can't because my mirrors' mid-pulse, and I'm stuck in the middle of main -- can't debootstrap
[09:46] <daniels> i'm leaving soon and will be out for a few hours
[09:50] <doko> ok, I'll ask elmo for build-deps on concordia, if that builds ok, then I'll upload it. can I start the build with -jN ?
[09:50] <daniels> don't
[09:50] <daniels> falls over badly when you try to parallelise it
[09:50] <doko> ok
[09:56] <fabbione> is anybody using concordia?
[09:57] <fabbione> or can i spin its load up?
[09:57] <doko> fabbione: no, please don't, trying to build xorg, when it's uploaded and build-deps are installed
[09:57] <fabbione> doko: sure.. no problem
[09:58] <doko> daniels: you have to fix xorg, to compete with fabbione for CPU time ;-)
[09:59] <fabbione> doko: tsk :)
[09:59] <fabbione> don't make me run -j400
[10:00] <fabbione> doko: btw.. 80% of my load is disk I/O bounded
[10:00] <fabbione> it's not all real CPU
[10:00] <fabbione> i have ccache configured on concordia
[10:02] <fabbione> doko: but you are not even logged in on concordia!
[10:03] <fabbione> oh great
[10:03] <fabbione> FUCK
[10:03] <doko> ?
[10:03] <doko> _when_ it's uploaded
[10:03] <fabbione> i hate DPATCH
[10:04] <fabbione> 1.2 is FTBFS
[10:05] <fabbione> FUCKING HELL
[10:23] <fabbione> elmo: can you please install a sane version of vim in halley/breezy chroot? kthxbye
=== _mvo_ [~egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #ubuntu-toolchain
[11:11] <elmo> fabbione: done
[11:11] <fabbione> elmo: thanks mucho
[11:35] <doko> elmo: please could you install xorg deps on concordia/breezy?
[11:35] <fabbione> elmo: don't :) i am building the kernel :P
=== doko slaps fabbione ;)
[11:37] <elmo> fabbione: err, too late, sorry
[11:38] <elmo> (sorry, I really did start, like 20 mins ago)
[11:38] <elmo> I should have realised that's why it was going so slowly
[11:38] <fabbione> ahha :)
[11:38] <fabbione> don't worry... i can stop if you need speed
[11:39] <elmo> nah, it's cool, as long as it doesn't break your build
[11:39] <fabbione> it shouldn't
[11:39] <fabbione> just don't switch compiler version :)
[11:39] <fabbione> that's enough
[11:47] <elmo> doko/daniels: done
[12:01] <doko> elmo: please could you move libestools1.2 to main
[12:01] <elmo> doko: done, 30 mins ago
[12:03] <doko> thanks
[01:06] <doko> fabbione, daniels: xorg -19 did cleanly build on amd64. I'm uploading the sources now
[01:06] <fabbione> doko: hold on
[01:06] <fabbione> did you change anything in the MANIFEST ?
[01:07] <fabbione> doko: or can i see the diff please?
[01:08] <doko> nothing, see /home/daniels on chinstrap
[01:10] <fabbione> doko: ok... seems alright....
=== Seveaz [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain
=== doko_ [~doko___@dsl-084-059-053-209.arcor-ip.net]  has joined #ubuntu-toolchain
[02:00] <mvo> it looks like the code in AM_GNU_GETTEXT is no longer working with 64bit/gcc-4.0. this caused aptitude to fail
[02:01] <mvo> has anyone seen that before?
[02:03] <mvo> ^--- doko
[02:04] <doko> no
[02:04] <doko> hmm, that should be fixed upstream?
[02:06] <mvo> yes
[02:06] <mvo> I'll have a look
[02:08] <jbailey> mvo: I've seen it with g++, I think.
[02:10] <mvo> the bad code is:
[02:10] <mvo> return (int) gettext ("") + _nl_msg_cat_cntr + *_nl_domain_bindings
[02:10] <mvo> conftest.cc:100: error: cast from 'char*' to 'int' loses precision
[02:10] <mvo> and it comes from gettext.m4
[02:12] <mvo> its just a matter to change it into long
[02:13] <jbailey> Yup, that's the beast.
[02:13] <jbailey> You need to run the gettext -f command or some such like that.
[02:13] <mvo> -f ?
[02:13] <jbailey> For some reason autoreconf -f -i didn't seem to be enough, I think because it calls autopoint rather than gettext (which seems a bit uselesS)
[02:14] <jbailey> force it to overwrite anything it had there before?
[02:14] <mvo> ok
[02:16] <jbailey> If that doesn't work, ping me.  My brain is split a few other ways atm so I can't check it out.
[02:16] <jbailey> mvo: You will need to do an autoreconf after, though, to make sure that configure picks up the changes.
[02:17] <mvo> yes, I think it will work fine
[02:39] <\sh> mvo: which package was it, where u had this error?
[02:45] <mvo> \sh: aptitude, it was fixed by using the latest gettext.m4 from the gettext package
[02:54] <fabbione> jbailey: impressive.. benc is on irc :)
[02:56] <jbailey> Wow.
[02:56] <jbailey> Should we pounce and scare him away? =)
[02:56] <\sh> mvo: was it something like this? check the last output of the build logs (http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/d/dar/2.2.1-1ubuntu1/dar_2.2.1-1ubuntu1_20050524-1145-ia64-failed.gz)
[02:56] <jbailey> Last I heard from benc on IRC, he was doing fiarly well in a poker tournament.
[02:57] <fabbione> jbailey: i am already working on it.. but he has 23 hours of idle
[02:58] <jbailey> He's apparently not that far of a drive from here.
[02:58] <fabbione> jbailey: what are you waiting to knock on his door?
[02:58] <jbailey> But I think the border guards might question me having a body bound and gagged in the trunk to bring home with me.
[02:58] <jbailey> Nothing.  I've long ago accepted that I will get nothing useful out of him.
[02:59] <lamont> jbailey: that's why it's _very_important_ that he be quiet
[02:59] <fabbione> ehehhe
[03:00] <mvo> \sh: let me check
[03:00] <lamont> and covered with coffee grounds, to confuse the dogs.
[03:01] <jbailey> Better that than poppy seeds...
[03:02] <lamont> heh
=== lamont figures border guarddogs are trained to alert on coffee as well...
[03:06] <jbailey> I'll do it at the Vancouver crossing.
[03:06] <jbailey> Between Vcr and Seattle, the guards would go nuts if they looked at coffee.
[03:06] <jbailey> The hard part is getting the trunk full of grinds up to body temperature so that he doesn't show up on a thermograph/
[03:06] <mvo> \sh: yep, just copy the gettext.m4 from /usr/share/aclocal/gettext.m4 to m4/ and call autoreconf (seems to work for me at least)
[03:07] <jbailey> mvo: That will probably work.  I usually prefer to update all of gettext so that at least I'm in a somewhat supported config.
[03:07] <mvo> is there a wiki page about common problems with g++-4.0 and how to fix them? could be interessting for the MOTUs to share experience
[03:07] <mvo> jbailey: runining "gettexize -f" ?
[03:08] <mvo> jbailey: runining "gettexize -f -c"
[03:08] <mvo> ?
[03:08] <jbailey> ADd -c
[03:09] <lamont> Group.cpp: In member function 'std::string libfwbuilder::Group::_ZTv0_n16_NK12libfwbuilder5Group11getTypeNameEv() const':
[03:09] <lamont> Group.cpp:55: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
[03:09] <lamont> Please submit a full bug report,
[03:09] <\sh> mvo: ah .. u r my rescue :)
[03:09] <lamont> woot.  same as arts
[03:12] <\sh> mvo: i will try this workaround
[03:19] <mvo> \sh: jbailey advice is probably better, use "gettextize -f -c; autoreconf" instead of just copying the gettext.m4 file
[03:20] <jbailey> lamont: Still on hppa?
[03:20] <mvo> \sh: you can check the result by searching in the generated configure file. what should happen is: "return (int)gettext(""); " -> "return * gettext("")" 
[03:20] <lamont> jbailey: yes
[03:21] <lamont> it would appear that we have two instances of the same ICE
[03:21] <lamont> couple more, and we can make a drink. :=)
[03:21] <jbailey> lamont: Do you have time to reduce it to a testcase?  Sounds like it might be time to punt it to upstream bugzilla.
[03:21] <lamont> I'll make time in the next day or two
[03:22] <jbailey> I'm trying to remember is hppa-hpux is a secondary platform.
[03:26] <\sh> well
[03:26] <\sh> mvo: first of all I get this after autoreconf: 
[03:26] <\sh> configure.ac:17: error: possibly undefined macro: AC_PROG_LIBTOOL
[03:26] <\sh> autoreconf: /usr/bin/autoconf failed with exit status: 1
[03:27] <\sh> apt-get install autobook for more brain autotools magic
[03:27] <mvo> \sh: dar?
[03:28] <jbailey> \sh: apt-get install libtool? 
[03:28] <doko> mvo: not explicitely, only references to the upstream release notes. Feel free to start one ;-)
[03:29] <\sh> mvo: yepp
[03:29] <\sh> jbailey: hmm...strange..
[03:39] <mvo> doko: http://www.ubuntulinux.org/wiki/GCC4CommonProblems
[03:40] <\sh> hmmm
[03:41] <doko> mvo: ok, we need to link it ...
[03:41] <\sh> gettextize -f -c is asking me to hit return ;)
[03:42] <\sh> i should go home
[03:42] <lamont> \sh: that'd be bad for the autobuilder. :-(
[03:44] <doko> daily aspell orgy ...
[03:47] <mvo> doko: updated and linked
[03:49] <doko> mvo: thanks!
[03:49] <\sh> lamont: yeah
[03:49] <\sh> mvo: did u see the same behaviour?
[03:50] <\sh> i have to check again
[03:51] <mvo> \sh: about the return thing? yes. that's ok. just follow the instructions there and press ok. it needs to be done only once (and not on the buildd)
[03:52] <\sh> mvo: so on the buildd this behaviour won't happen?
[03:52] <mvo> \sh no
[03:53] <\sh> good :)
[03:53] <mvo> \sh: :) the really interessting bit is "aclocal -I m4; autoconf"
[03:54] <mvo> \sh: feel free to add you experience to the wiki page!
[03:58] <jbailey> mvo: I think that's usually set through ACLOCAL_FLAGS or some such.
[03:58] <jbailey> Upstream shouldn't trust that the user remembers to add -I m4 when running autoreconf.
[03:59] <mvo> jbailey: ok, thanks
[04:08] <\sh> mvo: autoreconf should call them all
[04:10] <\sh> hmmm...
[04:12] <\sh> i need a faster package mirror
[04:12] <\sh> de.archive.u.c is not fast enough with syncing ;)
[04:13] <elmo> use de.archive.u.uc as a fall back
[04:14] <jbailey> \sh: autoreconf seems to call autopoint now, which is a bit on the useless side.
[04:14] <\sh> jbailey: soi u mean calling aclocal and friends "by hand" is better then to call autoreconf?
[04:14] <jbailey> No, autoreconf is always the right thing.
[04:15] <jbailey> Just that in this case getting the gettext stuff updated seems a bit broken.
[04:15] <jbailey> Probably because of the risk of screwing up C apis or something.
[04:15] <doko> elmo: please could you install mysql-dfsg build-deps on halley/breezy?
[04:18] <elmo> doko: done
[04:27] <doko> thanks
[04:39] <daniels> just uploaded xorg -20 and I'm going to bed
[04:39] <daniels> this means it's sure to FTBFS
[04:40] <lamont> daniels: lol
[06:28] <doko> xorg built while daniels was sleeping ;)
=== cartman [foobar@cartman.developer.konversation]  has joined #ubuntu-toolchain
=== cartman [foobar@cartman.developer.konversation]  has joined #ubuntu-toolchain
[08:51] <lamont> IDLAny.cc:372: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
[08:51] <lamont> that's 3.  I guess I'd best start working on that testcase soon...
[09:01] <jbailey> lamont: Three instances at least makes it sound like it shouldn't be that hard to reduce.
[09:05] <lamont> jbailey: exactly
[09:06] <lamont> #3 was libfwbuilder
[09:25] <doko> Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/hoary/Release  Unable to find expected entry  main/binary-hppa/Packages in Meta-index file (malformed Release file?)
[09:25] <doko> Reading package lists... Done
[09:25] <doko> lamont: ^^^
[09:26] <lamont> yeah. no hoary/hppa
[09:26] <lamont> hoary/hppa is at http://people.ubuntu.com/~lamont/ubuntu-hppa/tree iirc
[09:26] <doko> ok, ok, now to the breezy side of life ...
[09:28] <lamont> that's at ports.ubuntu.com/ubuntu-ports where it belongs
[09:28] <lamont> and is slowly populating
[09:28] <lamont> 37 packages queued up to sneak through the upload-straw
[09:49] <fabbione> bag
[09:49] <fabbione> bah
[09:50] <fabbione> i just trashed the gcc-3.4 build 3/4 of the way
[09:50] <fabbione> suckage
[09:50] <fabbione> doko: is it safe to start the build again with ./debian/rules build ?
[09:50] <fabbione> it was running the testsuite when i did stop it
[09:51] <doko> fabbione: yes, if stamps/*build-stamp exists. do you want to restart the check?
[09:51] <fabbione> doko: i basically did a killall make :)
[09:51] <fabbione> i didn't touch the source or the build dir
[09:51] <fabbione> so i am just re-running ./debian/rules build
[09:52] <doko> if you do not want to have tstresults, run WITHOUT_CHECK=yes debian/rules binary-arch
[09:54] <lamont> May 24 13:34:08 buildd-uploader: Setting to Uploaded(breezy): eel2 
[09:54] <lamont> progress!
[09:54] <lamont> fabbione: you aren't planning to upload that abused child, are you?
[09:54] <lamont> evil evil man. :-)
[09:55] <fabbione> lamont: i plan to do a debdiff before uploading :)
[09:55] <lamont> hehe
[09:56] <fabbione> 3 minutes to the meeting
[09:57] <jbailey> Thanks for the reminder. =)
[09:57] <jbailey> Hmm.  This is just the maintainer candidates review, right?
[09:58] <doko> it was an "urgent" meeting ...
[09:59] <jbailey> Oh?  Hmm.
[10:00] <doko> fabbione, lamont: please add speech-tools, festival and firefox to the list of libraries to build first (sparc and hppa)
[10:01] <fabbione> firefox?
[10:02] <fabbione> i only have mozilla-firefox banned as application
[10:03] <lamont> doko: actually the state of both architectures is that it's banned all cxxapps building... the rest just build as they come
=== fabbione restarts gcc-3.4 build
[10:17] <fabbione> i didn't like some scary messages while building the debs :)
[10:19] <doko> which ones?
[10:19] <fabbione> doko: nothing to be worried about.. it was the interrupted build
[10:31] <jbailey> Doh.
[10:31] <jbailey> Helps if I remember that it's a c++ compiler.
[10:31] <jbailey> doko: Should be an easy fix for mysql.  Removing variable called 'new' from asm-ia64/atomic.h =)
[10:32] <doko> heh, fine
=== lamont wonders if anyone in particular has been babysitting the cxxlibs builds to get them fixed for xorg/dpkg pain
[10:48] <doko> hey man, doing that for the last 5 days ...
[10:49] <jbailey> lamont: I see that there's a parisc CVS update for the kernel.  Is there a ChangeLog maintained for those patches?  It would be nice to know when it's time to see if some glibc stuf is happier.
[10:51] <doko> jabiley: ask on parisc-linux.org
[10:52] <jbailey> doko: They're now on oftc, but yeah.
[10:52] <fabbione> doko: now i am 100% sure... gcc on sparc is more strict than on other arches
[10:52] <fabbione> and this sucks
[10:52] <fabbione> big times
[10:52] <fabbione> http://people.ubuntu.com/~lamont/buildLogs/g/gstreamer0.8/0.8.10-0ubuntu1/
[10:53] <fabbione> cothreads.c: In function 'cothread_switch':
[10:53] <fabbione> cothreads.c:654: error: invalid lvalue in assignment
[10:53] <fabbione> make[5] : *** [libcothreads_la-cothreads.lo]  Error 1
[10:53] <fabbione> on sparc is FTBFS
[10:53] <fabbione> and that error is usually a macro on lvalu
[10:53] <fabbione> lvalue
[10:53] <doko> that's 3.4?
[10:53] <lamont> fabbione: nah - it's that strict on others too
[10:54] <fabbione> that's 4.0
[10:54] <lamont> I have lots of those
[10:54] <fabbione> i have seen a few..
[10:54] <fabbione> but why?
[10:54] <fabbione> given that is the same gcc and same code
[10:54] <lamont> because gcc-4.0 doesn't let you cast lvalues randomly
[10:55] <Kamion> that line of code is #ifndef HAVE_MAKECONTEXT
[10:55] <fabbione> hmmm
[10:55] <Kamion> I'm guessing sparc doesn't have that
[10:56] <Kamion> (or else the test is wrong)
[10:56] <lamont> doko: figured you were.  was wondering if it was helpful for me to announce them as I trip over them, or if you're already just doing it and it's only channel-noise
[10:57] <fabbione>     GST_ARCH_SETUP_STACK ((char *) cothread->sp);
[10:57] <jbailey> daniels: Hmm, the default path is now to /usr/bin/X11, but xbase-clients seems to still have things in /usr/X11R6/bin on ppc. =)
[10:57] <fabbione> that's what gcc doesn't like :/
=== fabbione hits seb128 with a sparc64 bat
[11:01] <jbailey> fabbione: Oo, did I miss something good? =)
[11:01] <jbailey> Oh, I see.  This is gstreamer.
[11:02] <fabbione> jbailey: it's all l-k-h fault!
[11:02] <fabbione>  i know that!
[11:02] <fabbione> you are hiding it very well :P
[11:03] <jbailey> fabbione: I try. =)
=== jbailey waits for :03 to watch the lkh upload.
[11:04] <fabbione> it's already :04 :)
[11:04] <jbailey> Hmm.  /me reruns ntpdate.
[11:04] <jbailey> Wow, 49 seconds off.
[11:05] <jbailey> Off an uptime of 3 days. =(
[11:05] <fabbione> Kamion: wow.. you did really a lot of magic in debootstrap :)
[11:05] <fabbione> Kamion: but really.. don't get too crazy about sparc, even if i really appreciate the extra work
[11:06] <Kamion> fabbione: that wasn't extra work
[11:06] <Kamion> fabbione: that was automatic :-)
[11:06] <fabbione> ahhhh
[11:06] <fabbione> ehheh
=== Kamion hugs ./breezy-update
[11:11] <fabbione> i guess breezy will be a porting hell if Debian doesn't switch to gcc-4 soon
[11:12] <jbailey> Or if they change the transition plan somehow.
=== fabbione ponders the idea of making only sparc server
[11:12] <fabbione> jbailey: can they? ;)
[11:12] <fabbione> let see...
[11:13] <fabbione> Kamion for sure will not vote for a different plan...
[11:13] <jbailey> fabbione: Depends if the release manager and ftp master decide that they hate Ubuntu that day... =)
[11:13] <fabbione> i know vorlon's wife.. that's like having vorlon's testicle in my hand
[11:13] <Kamion> it's been run past -release, no objections
[11:13] <doko> heh, the plan was discussed on -release ...
[11:13] <fabbione> jvw owns me a few tons of beer
[11:13] <fabbione> we can buy elmo
[11:14] <fabbione> do we need anybody else? :)
[11:14] <jbailey> Just doko, I guess. =)
=== fabbione makes doko an offer he can't refuse
[11:15] <jbailey> I wonder how many packages in Debian will silently grow -#ubuntu# versions as lazy maintainers just upload the Ubuntu version. =)
[11:15] <doko> we should switch to HEAD in unstable, it can compile KDE ;-)
[11:15] <fabbione> jbailey: almost nobody..
[11:15] <doko> heh, pike7.6 was'nt prepared for an "ubuntu" in the release part of the version
[11:15] <fabbione> i am pretty sure they are too proud of their pure versions
[11:16] <doko> hmm, but xorg are the same packages, aren't they?
[11:16] <fabbione> nope
[11:16] <fabbione> not that i know off at least
[11:16] <fabbione> had 0 time to look at xorg in debian
[11:16] <doko> oh no ...
[11:17] <Kamion> they're pretty similar
[11:17] <Kamion> they've been merging changes back and forward AFAIK?
[11:17] <fabbione> Kamion: yes
[11:17] <fabbione> but they are not the same
[11:17] <Kamion> and I was under the impression that they more or less imported Ubuntu packaging
[11:17] <Kamion> I think doko meant "same structure"
[11:17] <jbailey> fabbione: I thought of doing it with cdbs. =)
[11:17] <fabbione> Branden is correctly over paranoid about maintainer scripts and code cleanup
[11:18] <doko> gcc-4.0 (4.0.0-8) experimental; urgency=low
[11:18] <doko>   * Synchronize with Ubuntu.
[11:18] <fabbione> Kamion: we are going modular... so there will be not much to share and i doubt daniels and Overfiend will agree on the same way of splitting or pkg names
[11:18] <doko> Kamion: same "-dev" packages would be very nice
[11:18] <fabbione> doko: well that's because you upload both of them? :P
[11:19] <fabbione> doko: i will try to play some mind jedi tricks to make that happen
[11:19] <fabbione> but i am not sure i can manage
[11:19] <fabbione> the 3 sides of the Force are all really strong
[11:20] <doko> yup
[11:21] <fabbione> Kamion: let's take over ubuntu and make it only a minimal server install! at least i will manage breezy with sparc :P
[11:22] <Kamion> fabbione: gravity seems to be the guy actually doing most of the xorg work in Debian?
[11:24] <doko> jbailey, the arch you wanted fix lkh for, did FTBFS
[11:25] <fabbione> Kamion: probably... i didn't even have the time to check out the tree
[11:25] <fabbione> i planned some debian work during the next weekend :)
[11:26] <fabbione> wife is away with scouts :)
[11:27] <jbailey> doko: And how do you manage to see these so quickly after they happen? =)
[11:29] <doko> well, I'm looking when I can safely upload next packages or poke lamont retrying some others, the read noise just hurd^Dts ;)
[11:30] <doko> Kamion: you did have a page with the status of installable/not installable packages. where?
[11:30] <Kamion> doko: http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html
[11:31] <doko> thanks
[11:31] <doko> oops, the list got longer ...
[11:31] <lamont> Kamion: would it be terribly painful to do another such report containing the scc architectures?
[11:31] <Kamion> lamont: it's on my list :-)
[11:31] <lamont> or maybe one-per report - hppa will look really ugly for a while.. :-)
[11:31] <lamont> ENOGLIBC
[11:31] <Kamion> need to knock something up on rookery
[11:32] <lamont> Kamion: why is xorg 6.8.2-10 being used?  -20 should be in the archive...
[11:32] <lamont> firecall
[11:33] <doko> lamont: plese retry swig1.3 when the fire is out
[11:33] <Kamion> lamont: being used for what?
[11:34] <Kamion> lamont: oh, stale binaries I imagine
[11:34] <doko> hmm, that's just KDE
[11:34] <Kamion> those are the latest versions of xlibmesa-glu-{dbg,dev} in breezy
=== fabbione heads to bed
[11:41] <fabbione> good night
[11:45] <jbailey> g'n Fabio
=== ajmitch [~ajmitch@port162-41.ubs.maxnet.co.nz]  has joined #ubuntu-toolchain