[12:05] <doko> you may want to enable building the shared lib64gcc1 package in debian/rules.defs ...
[12:06] <doko> until gcc-4.0 builds it
[12:10] <jbailey> Yeah.  The other thought I had was that if we do gcc-4 first for these then a new gcc-3.4 can be built without overriding CC
[12:11] <jbailey> I discovered this by forgetting to override CC when I updated to thge gcc-3.4 from this morning and it still built.
[12:12] <doko> upload the 3.4 which builds lib64gcc1, it can be overwritten by 4.0 later
[12:12] <jbailey> 'k
[12:45] <fabbione> hey guys
[12:51] <fabbione> lamont: ping?
[12:52] <fabbione> lamont: can you kick back db4.2 on i386?
[12:52] <fabbione> there is no reason why it failed at all
[12:52] <fabbione> ubuntu5 is exactly as ubuntu4 with one line change in debian/rules that doesn't touch i386
[01:01] <doko> elmo: please move gnat-4.0 to main
[01:57] <elmo> doko: please seed it
[03:15] <daniels> doko: uhm, xbase-clients doesn't depend on xlibmesa-glu
[03:16] <daniels> doko: unless it crept in through ${shlibs:Depends}, which would be annoying
[03:16] <daniels> and also shouldn't happen
[03:19] <doko> daniels: it did happen, and it is annoying :-)
[04:02] <daniels> elmo: do any of the buildd chroots have xlibmesa-glu-dev installed?  if so, can they please not?
[06:57] <fabbione> morning
[07:06] <jbailey> Heya Fabio
[07:06] <fabbione> hey jeff!
[07:09] <fabbione> latest glibc is almost done on sparc :)
[07:09] <jbailey> Nice!
[07:09] <jbailey> This version decouples the locales dependancy
[07:09] <fabbione> AH COOL!
[07:09] <jbailey> So if you want to skip glibc for a rev or two after this, you're welcome to without penalty.
[07:11] <fabbione> jbailey: you tell me :)
[07:12] <fabbione> i can ban it from being auto built
[07:12] <fabbione> specially if you plan to do 3/4 uploads with no benefits for sparc
[07:12] <jbailey> fabbione: I don't see any reason why not to ban it for most of this week unless I tell you otherwise.  It looks like we'll be in good shape to do some biarch/multiarch work, i386/amd64 and ppc/ppc64.
[07:13] <jbailey> fabbione: It makes sense to tweak sparc/sparc64 at the same time to look the same.
[07:13] <jbailey> But it won't be first....
[07:14] <fabbione> of course :)
[07:41] <fabbione> dpkg is still fucked
[07:41] <fabbione> dpkg-architecture -qDEB_HOST_GNU_SYSTEM
[07:41] <fabbione> linux-gnu
[07:42] <fabbione> this break at least kernel-package
[07:43] <jbailey> Well, at least it's now reporting what config.{guess,sub} does so there won't be inconsistancy anymore.
[07:43] <jbailey> But it took two glibc and two gcc uploads to get it right for us.
[07:46] <fabbione> jbailey: so the final decision is linux-gnu?
[07:47] <jbailey> I didn't realise there had been any discussion about it.
[07:48] <fabbione> well we need to decide and fast
[07:48] <fabbione> otherwise i can't upload the kernel
[07:48] <fabbione> that is a big blocker for me atm
[07:48] <jbailey> dpkg 1.13.2 contains the change pretty explicitely, so it's not an error.
[07:48] <jbailey> doko and I each fixed other toolchain bits to cope.
[07:49] <jbailey> Although both of us included bits for backwards compatibility.
[07:49] <fabbione> well i need to change kernel-package
[07:49] <fabbione> and hounestly i can just build-dep on a specific version of it
[07:49] <fabbione> + add a versioned depends on dpkg
[07:50] <fabbione> that in this case it is allowed due to the mess
[07:50] <fabbione> (even if dpkg is essential)
[07:50] <svenl> hi jbailey 
[07:51] <jbailey> ifeq ($(DEB_HOST_GNU_SYSTEM),linux)
[07:51] <jbailey> DEB_HOST_GNU_SYSTEM := linux-gnu
[07:51] <jbailey> endif
[07:51] <fabbione> that would work too
[07:52] <fabbione> are you aware of other entries that did change?
[07:52] <jbailey> svenl: Heya
[07:52] <jbailey> fabbione: I'm just looking at what doko did in gcc
[07:52] <jbailey>   # configure as linux, not linux-gnu
[07:52] <jbailey>   TARGET_ALIAS := $(subst linux-gnu,linux,$(TARGET_ALIAS))
[07:52] <svenl> jbailey: i want to give rebuilding glibc/gcc a try again.
[07:52] <fabbione> hmm that can be done too
[07:52] <jbailey> svenl: I haven't got all the packaging sorted out yet. =(
[07:53] <jbailey> svenl: The latest gcc-3.4 in Ubuntu is very close, though.
[07:53] <jbailey> svenl: The source changes aren't the important bits.  It's a tiny change to glibc and to gcc.
[07:53] <svenl> Ok, i will give it a try. 
[07:53] <jbailey> The problem is that you need to start from working binaries.
[07:54] <svenl> Yep.
[07:54] <svenl> Well, not necessarily, as we have all started in some other way.
[07:54] <svenl> I mean, you originally built glibc with a cross compiled biarch gcc, didn't you ? 
[07:55] <jbailey> I don't know how it was generated, doko gave it to me.
[07:55] <svenl> the glibc ? 
[07:55] <jbailey> I'd assume so, though.
[07:55] <svenl> or the gcc ?
[07:55] <jbailey> the gcc.
[07:55] <svenl> Oh, so you where not the first one in building it.
[07:56] <svenl> mmm, no xfonts-utils this morning too.
[07:56] <jbailey> No.  Before it gets uploaded to Ubuntu, though, I'm tempted to do a clean bootstrap of the whole thing so that I can feel very happy about it.
[07:57] <svenl> bah, gnome still gives me a message entitled Xession, and a little lamp, but without further text.
[07:57] <svenl> jbailey: :)
[07:57] <jbailey> Does recovery mode work for you?
[07:58] <svenl> session de secours gnome ? 
[07:58] <jbailey> Sounds right.
[07:58] <svenl> ah, works much better.
[07:58] <jbailey> My gdm isn't set to french, only my login sessions.
[07:58] <svenl> mmm.
[07:58] <svenl> there it is.
[07:59] <svenl> all gnome plugin are dead though, i guess because loads of gnome libraries are bogus.
[07:59] <svenl> mmm, gnome-panel just crashed.
[08:00] <jbailey> What are you doing to your box? =)
[08:00] <jbailey> My system has been stable all day..
[08:00] <jbailey> Unless there was some mid-day update.
[08:00] <daniels> svenl: i assume the binaries for xfonts-utils are waiting on NEW love
[08:00] <svenl> daniels: indeed, there are no xfonts-utils on ppc.
[08:00] <svenl> daniels: do you have unofficial ones ? 
[08:01] <svenl> (it all started because i wanted to compile biarch gcc :/)
[08:01] <svenl> oh well, standard session seems to call xsession and not gnome-session.
[08:02] <daniels> http://people.ubuntu.com/~daniels/xfonts/xfonts-utils_6.8.2-12_all.deb
[08:02] <svenl> daniels: :)
[08:03] <svenl> oh, seems better, if i validate the xsession dialogue, i get a working gnome-session.
[08:03] <svenl> daniels: do you know where that xsession dialog comes from ?
[08:03] <daniels> probably missing fonts, particularly if you have no text
[08:03] <jbailey> svenl: I'm uploading to people.ubuntu.com/~jbailey/glibc
[08:03] <svenl> jbailey: thanks.
[08:03] <jbailey> I have a slow DSL uplink and I'm headed to bed.
[08:04] <svenl> daniels: your xfonts-utils will help me on that.
[08:05] <jbailey> svenl: The most recent gcc-3.4 in the archive is mostly setup for the biarch.  You need to change debian/rules to set CC to gcc-3.4 (the one that you got from me before), debian/rules.defs to enable the biarch config, and debian/binary-gcc.mk to fix the dh_link bug (missing $(PF) and missing some \'s.
[08:05] <daniels> svenl: maybe.  if it doesn't, remember to change your paths from /usr/lib/X11 to /usr/share/X11 in xorg.conf
[08:05] <svenl> jbailey: ok, will give a try today.
[08:05] <jbailey> Sorry, scratch the CC bit in rules.  Current gcc seems to build biarch gcc fine.
[08:05] <svenl> daniels: yep, i did that.
[08:05] <daniels> cool
[08:05] <svenl> daniels: well, actually, they are not in /usr/share/X11 for some reason, so i have them pointing to /usr/X11R6/...
[08:06] <jbailey> However with all that, the current package doesn't produce lib64gcc_1.so.  That's where I go to before going out for drinks this evening.
[08:06] <daniels> errrrrrr
[08:06] <daniels> if they're not in /usr/share/X11, then you're not using the packages from xfonts-core
[08:06] <daniels> which is xfonts-* 6.8.2-12
[08:06] <jbailey> svenl: Oh yeah, I had to redo my font config this morning, are you on a pegasos box?
[08:06] <svenl> daniels: i only have type1 and truetype in shate.
[08:06] <svenl> jbailey: nope, powerbook.
[08:06] <jbailey> svenl: Ah, okay.
[08:06] <daniels> svenl: then you need -75dpi, -100dpi, and others from 6.8.2-12
[08:06] <jbailey> svenl: Otherwise I'd send you my xorg.conf
[08:06] <daniels> jbailey: it's not pegasos-specific by any means
[08:07] <svenl> daniels: i have a couple of fonts upload waiting for xfonts-utils..
[08:07] <daniels> svenl: um, for ubuntu?
[08:07] <svenl> daniels: sure.
[08:07] <daniels> main or universe packages?
[08:07] <svenl> daniels: all of them, breezy even.
[08:07] <daniels> cool
[08:07] <jbailey> daniels: Yeah, I wasn't looking for a good solution to the problem, just to offer him a working config if he happened to be on the same system as I.
[08:07] <jbailey> =)
[08:08] <daniels> send the universe ones to the motu guys at #ubuntu-motu
[08:08] <daniels> heh
[08:08] <svenl> i did install x-window-system though, which may have been a mistake, as i tried to solve the font dissapeared issue cluelessly.
[08:10] <svenl> xfonts-utils -16 is conflicting with xutils -10 :?
[08:10] <svenl> :/ even
[08:12] <svenl> mmm, forcing it.
[08:13] <svenl> ok, that seems to fix it, thanks daniels
[08:14] <svenl> daniels: altough the fonts and co are only at -11
[08:15] <daniels> yeah, update-fonts-* was in xutils until about -15 or so
[08:15] <daniels> and the binaries are stuck in NEW
[08:15] <daniels> but when that gets fixed, we'll have -12 everywhere, and dist-upgrades will pick up what's needed
[08:16] <svenl> daniels: do you have unofficial fonts package too ?
[08:16] <daniels> not going to upload them, they take about an hour on my DSL
[08:17] <svenl> daniels: can i build them from source ? 
[08:18] <daniels> sure, the .diff.gz is in the repository
[08:19] <jbailey> Sleep time, g'n all!
[08:19] <daniels> night dude
[08:20] <fabbione> night
[08:30] <fabbione> infinity: ping?
[08:45] <infinity> fabbione : pong.
[08:45] <infinity> fabbione : I'm in the middle of insalling Ubuntu on my girlfriend's amd64 machine, so I have something faster to work on.
[08:46] <fabbione> infinity: eheh neat... i had a question for you.. just a sec i need to find the reference again
[08:46] <infinity> fabbione : Was it a toolchain question, or are you just picking random channels to ping me in? :)
[08:48] <fabbione> #$secondary_daemon_threshold = 70;
[08:48] <fabbione> random chan :)
[08:48] <fabbione> it's a buildd question
[08:48] <fabbione> prefer in pvt?
[08:48] <infinity> Nah, public is cool.
[08:49] <fabbione> what does that option do exactly?
[08:49] <infinity> Allows a second daemon to be spawned if the queue is over $x deep, IIRC.
[08:49] <fabbione> i understand that if there are more than N pkgs in needs-build, buildd will fork.. but how and with what criteria?
[08:49] <fabbione> what's the point of spawning if the chroot is locked by another package?
[08:50] <infinity> If you want "whate precisely does it do when it forks?", I'd recommend reading the source.  As you may imagine, that's a feature I never turn on. :)
[08:50] <fabbione> or there is a way to specify a seconday chroot for the same distro?
[08:50] <fabbione> well the code doesn't say much..
[08:50] <fabbione> that's why i was asking :)
[08:51] <infinity> Heh.  Well, given that all my buildds are really slow single-CPU machines, the very idea of forking more instances is just plain wrong, so I've not examined that codepath.
[08:51] <infinity> If it's sharing a chroot, though, that does seem broken, I agree.
[08:52] <fabbione> buildd:# New config var $conf::secondary_daemon_threshold: If not at least that
[08:52] <fabbione> buildd:         if ($total && $conf::secondary_daemon_threshold &&
[08:52] <fabbione> buildd:                 $total < $conf::secondary_daemon_threshold) {
[08:52] <fabbione> it seems only to add a log entry
[08:53] <fabbione> there is no code basically
[08:53] <fabbione> or i am misreading it
[08:54] <fabbione> ahhhh
[08:54] <fabbione> i get it
[08:54] <fabbione> if that var is set
[08:54] <fabbione> and you run a second instance of buildd
[08:54] <fabbione> than it will fork
[08:55] <fabbione> but it seems like it will share the same configs and chroots
[08:55] <fabbione> it looks bad
[08:55] <infinity> Hrm.  Yeah.
[08:56] <infinity> I wonder who thought that was a good idea?
[08:56] <infinity> You'd have sbuilds walking all over each other with package installations/removals...
[08:57] <fabbione> probably sbuild has some kind of locking protection?
[08:57] <fabbione> otherwise /var/sbuild/src-lock would have no meaning :)
[08:57] <fabbione> or whatever is called
[08:58] <fabbione> meh debbuild
[08:58] <infinity> srcdep-lock?
[08:59] <fabbione> sub check_srcdep_conflicts {
[08:59] <fabbione> yeah
[08:59] <fabbione> it's done at sbuild level the next check
[08:59] <fabbione> yeah that one
[09:00] <infinity> All srcdep-lock does, IIRC, is lock when sbuild is installing packages.
[09:00] <infinity> It doesn't hold any locks during a build.
[09:00] <fabbione> well i am not going to turn that on since the code isn't really clear
[09:00] <infinity> Or, if it's meant to, that feature doesn't work. :)
[09:00] <fabbione> hahha
[09:00] <infinity> (Cause the lock dir is pretty much always empty..)
[09:01] <fabbione> yeah i was checking right now
[09:01] <infinity> I think the w-b suite is littered with unfinished features, so I wouldn't be surprised if this was another.
[09:01] <fabbione> yeah i can see that
[09:10] <infinity> Oh, great.  GRUB blew up the Windows boot sector, and it can't chainload Windows properly.  Yay, I lose!
[09:10] <fabbione> infinity: eh? you kidding....
[09:10] <fabbione> it did never happen here
[09:12] <infinity> Oh, I told it to eat the Windows boot sector.  But I didn't tell it to suck at loading Windows, that part it's done on its own.
[09:12] <fabbione> infinity: have fun :)
[09:12] <fabbione> i have no idea on how to recover a wincrap boot sec
[09:14] <infinity> Well, usually, with the install CD.  Which I don't have a copy of here.
[09:27] <fabbione> switch the entire box to linux :)
[09:27] <fabbione> and kill winnt
[09:27] <fabbione> and i mean.. NT??
[09:27] <fabbione> put her on XP at least
[10:19] <daniels> infinity: fdisk /mbr?
[10:19] <daniels> infinity: you trashed zofia's xp mbr, didn't you?
[10:21] <infinity> fabbione : It is XP... Which is NT 5.1.
[10:21] <infinity> daniels : Maybe.
[10:21] <infinity> daniels : Downloading an install CD right now to fix it. :)
[10:21] <svenl> doko_: you there ? 
[10:21] <infinity> (fdisk /mbr is a DOS thing, and also would only work if I had a floppy drive)
[10:27] <\sh> hmmm
[10:27] <svenl> hi sh
[10:27] <svenl> hi \sh 
[10:27] <\sh> what is the replacement for xlibmesa-gl-dev
[10:27] <svenl> even
[10:27] <\sh> g'morning svenl  :)
[10:28] <\sh> found it :)
[10:28] <svenl> \sh: what was it ?
[10:29] <daniels> \sh: xlibmesa-gl-dev is still xlibmesa-gl-dev
[10:30] <svenl> daniels: don like to install on ppc though, since libglu are not in sync.
[10:31] <\sh> daniels: i have here build-deps on libglu-dev-xorg (because of libstdc++) xlibmesa-* wasn't compiled against libstdc++6
[10:32] <daniels> svenl: huh?
[10:32] <daniels> \sh: xlibmesa-glu-dev wasn't built against libstdc++6; xlibmesa-gl-dev is not C++
[10:33] <daniels> libglu1-xorg and libglu-dev-xorg were built against libstdc++6, unless there's been a terrible, terrible compiler mishap
[10:34] <daniels> (on the buildds)
[10:34] <svenl> daniels: well, my error, it needs :  xlibmesa-dev libglu-dev-xorg libglu1-xorg
[10:34] <svenl> these are the ones, but they will uninstall half my system for now, including gdm and such stuff.
[10:34] <svenl> well, half my system is exagerated.
[10:34] <daniels> seems to work alright for me
[10:35] <svenl> daniels: 2$ sudo apt-get install xlibmesa-dev libglu-dev-xorg libglu1-xorg
[10:35] <svenl> Les paquets suivants seront ENLEVS:
[10:35] <svenl>   freeglut3 gdm gksu gnome-netstatus-applet gnome-system-monitor gnome-system-tools hwdb-client libgksu1.2-0 libgksuui1.0-0
[10:35] <svenl>   libgle3 libglut3 python-opengl python2.4-opengl rss-glx xbase-clients xlibmesa-glu xlibmesa-glu-dev xprint xprint-common
[10:35] <svenl>   xprt xscreensaver-gl
[10:35] <\sh> daniels: right..but if xlibmesa-glu-dev is now libglu1-dev-xorg, is there also a name change in xlibmesa-gl?
[10:35] <svenl> ENLEVE -> REMOVED, obviously.
[10:35] <daniels> enlevs -> removed?
[10:35] <daniels> right
[10:35] <daniels> \sh: no.
[10:36] <\sh> chaos ;)
[10:38] <daniels> well, versioned provides just don't work
[10:38] <daniels> so I want to avoid changing the package name unless I have to
[10:38] <daniels> bbl
[10:38] <daniels> dinnertime
[11:05] <\sh> hmmm
[11:05] <\sh> libglu-dev-xorg: Depends: libglu1-xorg (= 6.8.2-16), xlibmesa-gl-dev | libgl-dev, libstdc++5-3.3-dev | libstdc++-dev, libc6-dev | libc-dev
[11:09] <svenl> \sh: welcome to breezy :)
[11:10] <\sh> svenl: well...
[11:10] <\sh> it doesn't have to do with breezy
[11:10] <\sh> because
[11:11] <\sh> libglu1-xorg: Depends: libc6 (>= 2.3.4-1), libgcc1 (>= 1:4.0.0-7), libstdc++6 (>= 4.0.0-7), libxext6 | xlibs (>> 4.1.0), xlibmesa-gl | libgl1
[11:11] <\sh> ;)
[11:11] <fabbione> so what is that for???????
[11:11] <svenl> \sh: bah.
[11:13] <\sh> fabbione: the dependencies for binary package and dev package are not fitting together :( and I need this stuff to fix a package here
[11:13] <fabbione> \sh: well but that's for breezy or not?
[11:17] <\sh> fabbione: yepp
[11:17] <\sh> think i need a cup of coffee and a cigarette
[11:21] <doko> morning all
[11:22] <fabbione> hi doko
[11:23] <doko> is daniels coming back?
[11:23] <svenl> hi doko.
[11:23] <fabbione> doko: he went for dinner.. so i guess yes
[11:23] <svenl> doko: maybe.
[11:24] <svenl> doko: what is the latest version of your biarch gcc .debs you have available ? 
[11:25] <doko> svenl: the same as before, let jbailey sort it out this week, then it should be ready
[11:26] <svenl> doko: i wanted to build it myself today.
[11:27] <elmo> is it known locales' dep is SNAFU on amd64?
[11:28] <svenl> oh well.
[11:29] <fabbione> elmo: to what level of SNAFU?
[11:29] <fabbione> because jb did relax the locales depends: 
[11:29] <fabbione> to something like >= ${Source-Ver}
[11:30] <elmo> uninstallable SNAFU
[11:30] <fabbione> instead of =
[11:31] <elmo> katie@jackass:~$ dpkg -I pool/main/g/glibc/locales_2.3.5-1ubuntu3_all.deb | grep Depends
[11:31] <elmo>  Depends: glibc-2.3.5-0ubuntu1, debconf (>= 0.2.26)
[11:31] <elmo> looks fairly = to me
[11:31] <Kamion> I think that's meant to be provided by everything with the same locale API or similar
[11:32] <Kamion> amd64 just hasn't built the new glibc yet
[11:32] <Kamion> $ dpkg -f libc6_2.3.5-1ubuntu3_i386.deb Provides
[11:32] <Kamion> glibc-2.3.5-0ubuntu1
[11:33] <elmo> why do they have a virtual package whose version number is divorced from the source version number?  that's just whack
[11:34] <elmo> the glibc build is just stalled on amd64
[11:34] <Kamion> same idea as shlibdeps, just done with a virtual package because the package name is different on different architectures
[11:34] <Kamion> well, not quite the same as shlibdeps
[11:34] <elmo> root     31196  0.0  0.0   9132   696 ?        SN   May22   0:00      \_ /usr/bin/sudo perl -e kill( -15, 17624 )
[11:35] <daniels> sudo perl -e kill?
[11:35] <fabbione> omg
[11:49] <\sh> argl
[11:49] <\sh> daniels is working on the xorg stuff right?
[11:56] <Riddell> \sh: kdebindings and base are in, we could probably try for pyqt pykde?
[11:56] <\sh> Riddell: no
[11:56] <\sh> the deps are not as they should
[11:57] <Riddell> what's needed?
[11:58] <\sh> xlibmesa-glu is replaced by libglu-xorg and libglu-dev-xorg...but the deps for libglu-dev-xorg are set against libstdc++5-3.3 and not like the bin package libglu1-xorg against libstdc++6-4.0
[12:00] <doko> \sh: that shouldn't hurt, libstdc++-dev already is installed on the buildd's.
[12:02] <\sh> doko: but not on my update ;)
[12:02] <\sh> lunch
[12:03] <doko> \sh, install build-essential first
[12:06] <elmo> doko: what's the current state of play with the freeze?
[12:06] <elmo> did lamont unfreeze c++ apps?
[12:08] <doko> elmo: as I did write on IRC yesterday, lamont wasn't online yesterday
[12:09] <elmo> meh
[12:09] <elmo> can _I_ unfreeze them?
[12:09] <doko> by unfreeze you mean, put the new cxxapps.txt in effect?
[12:11] <doko> elmo: yes, if unfreeze is limited to c++ apps in main
[12:18] <elmo> doko: cxxapps.txt still has main apps?
[12:19] <doko> yes, those depending on mozilla-dev
[12:19] <doko> hmm, yes, I can remove the KDE things as well
[12:20] <doko> elmo: ok, done
[12:21] <doko> and I removed aptitude from the cxxapps in universe, so mvo can play the apt upgrade game
[12:22] <mvo> doko: aptitude is main 
[12:23] <doko> mvo: even better
[12:23] <doko> never used it ...
[12:24] <Kamion> the installer kind of does ;)
[12:25] <mvo> Kamion: is it only used for the installation of the tasks? or for more stuff?
[12:25] <Kamion> mvo: for task installation, and for fallback if that fails
[12:26] <mvo> thanks
[12:32] <Riddell> so the build daemons are now going to go nuts?
[01:00] <\sh> doko: it's installed :)
[01:00] <\sh> so lunchtime is over :)
[01:12] <doko> elmo: is the cxxapps.txt updated on the buildd's? if yes, I could at least upload all packages, for which we have ubuntuN versions
[01:14] <elmo> doko: no, I want to talk to mdz about buildd stuff
[01:14] <elmo> + first
[01:14] <elmo> btw, you might as well upload apps, they just won't get built yet
[01:25] <elmo> better to have them ready to build than not..
[01:31] <doko_> hmm, daily disconnect ...
[01:32] <doko_> elmo: ok, assume a upload a -buildN, which you then sync with a newer version. will the buildd build both versions, if both are available when the buildd restarts building the apps, or will it skip the older one?
[01:33] <elmo> eh
[01:33] <elmo> doko: for any given arch, only one version of a package is in a suite at any one time
[01:35] <doko> elmo: do you sync with the new cxxapps.txt today? then I'll wait with the upload of the -buildN packages until after the sync
[01:36] <elmo> what about cxxlibs? is that up-to-date?
[01:38] <elmo> heh, that updated a whole 3 apps
[01:42] <doko> elmo: cxxlibs updated. yes, we don't have that many C++ stuff in main, and most is modified anyway. which are the three apps?
[01:42] <elmo> uh, dunno, check breezy-changes?
[01:42] <elmo> doxygen, lftp and something
[01:44] <doko> knew about doxygen, still waiting for the mails
[01:44] <elmo> sorry, it got mixed in with a bunch of your uploads, and it's now hard for me to tell what's what
[01:45] <doko> ok, uploading the buildN's as well, so one will get rejected
[01:45] <elmo> that's fine
[01:51] <elmo> how's the universe transition being handled, given the uploads are blocked on certain keys?
[01:51] <elmo> oh, we're not anymore, nm me
[01:53] <svenl> checking whether the C compiler works... configure: error: cannot run C compiled programs.
[01:53] <svenl> Mmm, i guess something failed badly here :)
[01:54] <doko> the universe part of cxxlibs.txt and cxxapps.txt shouldn't be synced, but libs should be built.
[01:57] <doko> elmo, mvo: I made a mistake: uploaded synaptic, would probably be better, if this one does not enter the archive. sorry for that one
[01:58] <svenl> doko: the above test, does it check that the result from the compilation run is actually runnable, right ?
[01:58] <elmo> that's all right, the sync will overwrite it?
[01:58] <svenl> doko: and this is the place where it fails on 3 bit ?
[01:58] <svenl> 32bit even.
[02:00] <doko> elmo, mvo: aptitude as well
[02:10] <lamont> morning
[02:11] <doko> hi lamont
[02:11] <lamont> still need cxxapps unblocked on the buildds?
[02:11] <doko> glibc did timeout in some network tests on amd64
[02:11] <lamont> _again_.
[02:12] <lamont> redland-bindings is ftbfs for me... no swig.  Wonder if that's everywhere...
[02:12] <elmo> I already gave it back
[02:12] <doko> lamont: yes, but I updated cxxlibs.txt and cxxapps.txt
[02:12] <lamont> elmo: coolness
[02:12] <elmo> lamont: but it had hung pretty spectacularly, the 'kill -TERM' invocation was hung too
[02:12] <lamont> neato
[02:13] <doko> elmo wanted to talk with mdz about the buildd's first
[02:13] <elmo> no, that's fine, if lamont's here, go for it
[02:16] <lamont> doko: so another round of 'replace the list we have with what's currently in cxxapps'?
[02:18] <doko> lamont: yes please, basically remove all of main, keep all of universe. thom just told me that he's preparing a mozilla upload, so I remove the one's depending on that as well.
[02:19] <doko> lamont: done
[02:22] <lamont> chinstrap:~doko/cxxapps.txt, yes?
[02:23] <doko> correct
[02:23] <doko> lamont, fabbione: but keep the installed one on the sparc and hppa buildd
[02:24] <doko> maybe not necessary for sparc, it's building binutils, glibc, gcc-* this week anyway ;)
[02:24] <jbailey> lamont: Hey, not my fault the kernel hangs in the middle of a syscall. =(
[02:26] <jbailey> lamont: I've gone over the test-ifaddrs code, as has vorlon - it's a quite simple bit of code.  Following it with strace, it goes in to ask a question and just never seems to come back.
[02:26] <elmo> it seemed stuck in recvmsg, does that sound right?
[02:27] <doko> lamont: perl on i386 did fail in network test ... interesting, dist-upgrade now wants to remove build-essential
[02:27] <jbailey> When I traced it I think it was in getgid or something like that, but I don't have notes handy.
[02:27] <elmo> ok
[02:28] <jbailey> I'm surprised to see it triggered twice in a row on amd64, though.
[02:28] <jbailey> Usually on Debian it would be months between uploads where it would die.
[02:28] <lamont> doko: fixed perl
[02:28] <lamont> doko: it kinda assumes that 'localhost' resolves, which isn't necessarily true, but we decided it should....
[02:29] <lamont> and terranova was down when I upgraded all the chroots by copying in /etc/hosts....
[02:29] <elmo> lamont: how's yellow been?
[02:30] <jbailey> elmo: FWIW, I loosened the locales dependancy with this upload, so hopefully if there's glibc problems on an arch in the future it won't bring the whole thing to a grinding halt.
[02:31] <doko> jbailey: finally ... :)
[02:32] <elmo> jbailey: yay, thanks
[02:32] <elmo> tho, to be honest, I don't mind grinding halt in ubuntu
[02:32] <elmo> our glibc really shouldn't be out of sync
[02:32] <elmo> at least for release arches
[02:34] <jbailey> Right.  It's one of those changes that I hope I can convince gotom to pick up that he might not be willing to.
[02:37] <doko> jbailey: so we won't have a chance to build the compilers, because one of the architectures will be broken at any time ;)
[02:38] <lamont> elmo: seems to be doing OK
[02:38] <elmo> lamont: ok
[02:38] <lamont> doko: I'll have the changes made sometime in the next 20-40 minutes
[02:38] <jbailey> doko: Nah, elmo said he doesn't mind breakage. =)
[02:39] <jbailey> Anywho running off to spend the morning with my belle.
[02:39] <doko> jbailey: well, it may be interesting for sparc and hppa 
[03:04] <lamont> doko: ia64 is ready for this change too?
[03:06] <doko> lamont: yes
[03:09] <lamont> ok.  chroot-upgrade/buildd restart now in progress
[03:09] <lamont> cc1: error: unrecognized command line option "-fwritable-strings"
[03:09] <lamont> is there a comparable option in 4.0?
[03:10] <doko> lamont: no
[03:10] <lamont> unicode.c:19:26: error: linux/string.h: No such file or directory
[03:10] <lamont> grumble
[03:13] <lamont> cool.  dies on i386 too.  /me bugzillas
[03:15] <Kamion> will take some porting if it expects writable strings, probably ...
[03:19] <lamont> Kamion: yeah.
[03:19] <lamont> the i386-too was hfsplus.  the writable strings is palo (which no one but hppa cares about)
[04:07] <chmj> lamont: powerpc-given-back.gz what does that mean on the build logs ?
[04:08] <lamont> it means that the buildd decided it shouldn't even try, and gave it back
[04:08] <lamont> and inside the log should be an error that gives a hint...
[04:08] <lamont> is the timestamp from somewhere around :03-08 or :33-38?
[04:19] <doko> jbailey: groff: *** glibc detected *** double free or corruption (!prev): 0x0805a678 ***
[04:19] <lamont> bad groff
[04:21] <doko> tetex-bin is another xorg victim
[04:21] <daniels> tetex?  people still use that crap?
[04:22] <Kamion> "glibc detected"? wtf?
[04:22] <Kamion> doko: I'll have a poke at groff
[04:22] <doko> Kamion: thanks
[04:43] <\sh> who uploaded sip4?
[04:44] <Kamion> \sh: breezy-changes says doko
[04:44] <\sh> yes saw it
[04:45] <\sh> i'm wandering if the build-deps are correct against xfree
[04:45] <\sh> and not against xorg
[04:47] <doko> \sh: unmodified upload, probably needs to be corrected
[04:47] <\sh> doko: ah ok :)
[05:02] <lamont> Kamion: glibc (more specifically, malloc, et. al.) do corruption checking now.  most cool, except that it turns heisenbugs into hard failures.
[05:03] <lamont> daniels: you don't even want to know how many packages (build-)?depend tetex-bin, directly or indirectly.
[05:04] <daniels> lamont: heavy sarcasm detected
[05:05] <lamont> it's kinda early on in the bootstrapping pain
[05:06] <doko> lamont: fix uploaded
[05:06] <doko> tetex-bin
[05:06] <lamont> apt-cache showsrc gcc-4.0
[05:06] <lamont> Build-Depends: ... tetex-bin ...
[05:06] <doko> cursing the xorg reorganisation again
[05:06] <lamont> daniels: so that'd be, um, everybody
[05:07] <daniels> lamont: yeah :) 'twas joking
[05:07] <lamont> heh
[05:07] <Kamion> lamont: yeah, it was a double fclose() in grn - fixing
[05:08] <Kamion> lamont: I misread "glibc detected <stuff>" as "I detected glibc"
[05:08] <lamont> lol
[05:08] <lamont> yoda it is not.
[05:08] <doko> we're nearing the point where the number of needed xorg fixes exceeds the number of needed C++ fixes ;-)
[05:09] <daniels> yeah, and glibc's double-free stuff is fucking us, too :P
[05:09] <daniels> exposing previously-unseen breakage
[05:09] <lamont> daniels: nah - it's finding things.
[05:10] <lamont> the X directory structure was only broken for you pedants.
[05:10] <daniels> eh, it only worked by accident
[05:12] <lamont> dude - that's all of X11 :) 
[05:12] <lamont> I mean when the standard changes everytime some student at MIT sneezes and gets code all over the desk... :-)
[05:13] <elmo> doko: dude, did you not fix bison?
[05:14] <doko> ?
[05:15] <elmo> I just created a breezy chroot and got file overwrite errors
[05:17] <doko> looking at it
[05:23] <daniels> lamont: r7 is all about fixing the 'by accident' bit
[05:27] <lamont> daniels: so r7 is just continuing in the tradition of 'tightening the spec', like gcc-3.x and 4.x have?
[05:28] <daniels> lamont: that's the one!
[05:28] <lamont> ah, well then, it must be a good thing...
[05:28] <daniels> indeed
[05:28] <daniels> 'xorg, now with 97% more API reinterpretation!'
[05:28] <daniels> the current 'spec' is largely defined by myself and ajax's definition of good taste
[05:29] <lamont> as long as it's not being done by some 19 year old radical who's still wet behind the ears.....
[05:29] <lamont> :-)
[05:30] <daniels> hey, the average age of us two is about 20.5
[05:31] <daniels> that's old, right? :)
[05:31] <lamont> daniels: add me in ad the average goes to 27.3
[05:31] <lamont> s/ad/and/
[05:32] <lamont> yesterday, my daughter reminded me of the apache vs evolution debate 
[05:32] <daniels> apache vs evolution?
[05:32] <lamont> yeah - "apache is so much cooler than evolution, you should use that instead."
[05:32] <daniels> er
[05:33] <lamont> it was something I threatened to troll #ubuntu with one day
[05:33] <lamont> (commented in #u-devel, and still got a few takers...)
[05:34] <daniels> haha, brilliant :)
[05:34] <daniels> there's a comment to be made about age not having dulled your wit somewhere ;)
[05:34] <lamont> the funnest part was the number of fully clueful people who got involved in the discussion just to keep it going.
[05:36] <daniels> heh
[05:38] <daniels> lamont: feb 10th, so must've been hoary
[05:38] <daniels> 20:45  * lamont considers draging the "which is better, evolution or apache" debate over to this channel, decides not.
[05:40] <lamont> was it that recent?
[05:40] <doko> lamont: how do you like your vacations?
[05:41] <lamont> doko: lengthy :-)
[05:41] <lamont> Feb 10 10:49:58 <lamont_r> maybe I should start a thread on users on why evolution is better than apache
[05:41] <lamont> in another chanel
[05:42] <lamont> s/another/a different/
[05:42] <daniels> lamont: ahr
[05:42] <daniels> except the debate in there wasn't exactly long or interesting :P
[05:42] <doko> lamont: could you remove the dep-wait for xerces2[56] 
[05:43] <lamont> daniels: no, but it does give the context for the idea....
[05:43] <lamont> doko: sure
[05:43] <daniels> lamont: right
[06:00] <doko> nice, tetex-bin on ia64
[06:00] <doko> {standard input}: Assembler messages:
[06:00] <doko> {standard input}:15316: Error: Use of p0 is not valid in this context
[06:00] <doko> make[4] : *** [writet1.o]  Error 1
[06:01] <daniels> doko: there you go, now you have something to bitch about other than xorg :P
[06:01] <fabbione> ahha
[06:02] <fabbione> ./Redland_wrap.c:13:20: error: Python.h: No such file or directory
[06:02] <fabbione> neat!
[06:02] <fabbione> only 200K of error from a missing include :)
[06:03] <doko> buy a bigger disk :P
[06:03] <fabbione> that was not the point :)
[06:03] <fabbione> Alloc PE / Size       123655 / 483.03 GB
[06:03] <fabbione> Free  PE / Size       33712 / 131.69 GB
[06:03] <fabbione> i have enough space :)
[06:04] <fabbione> at least failed for everybody :)
[06:04] <Kamion> elmo: please sync groff 1.18.1.1-8 from incoming, should fix that build failure
[06:06] <elmo> Kamion: done
[06:08] <Kamion> ta
[06:09] <\sh> fabbione: send me some GB ;)
[06:10] <doko> elmo: please could update the halley/breezy chroot and install tetex-bin's build deps?
[06:13] <fabbione> elmo: mind to upgrade breezy and breezy-i386 on concordia and breezy on davis with the new dpkg? (it has been unbanned/built)
[06:14] <elmo> doko: done
[06:14] <fabbione> elmo: well if you can do halley too it would be lovely :)
[06:15] <fabbione> otherwise i will start bouncing ia64 to somebody else... and have an excuse for that :P
[06:15] <elmo> halley's just been done
[06:15] <fabbione> cool
[06:16] <elmo> concordia/native done
[06:17] <fabbione> thanks
[06:17] <elmo> concordia/386 done
[06:17] <fabbione> rocking!
[06:24] <doko> gv is another xorg victim, fixing ...
[06:27] <doko> elmo: please could you install g++-3.4 on halley:breezy?
[06:28] <fabbione> dpkg-architecture: warning: Unknown gcc system type amd64-linux, falling back to default (native compilation)
[06:28] <fabbione> this is on concordia breezy chroot...
[06:30] <doko> fabbione: yes filed a dpkg bug
[06:30] <fabbione> elmo: while at it, can you also install linux-source-2.6.12 build-deps + xmlto ?
[06:30] <fabbione> (halley/breezy chroot)
[06:30] <fabbione> doko: it's only amd64 fucked?
[06:31] <doko> yes
[06:32] <fabbione> ok
[06:32] <fabbione> it's only a warning tho
[06:35] <elmo> fabbione: done
[06:35] <fabbione> elmo: thanks you rock!
[06:39] <fabbione> elmo: can you also do breezy on davis please? i think it's the last one missing
[06:51] <elmo> fabbione: done
[06:51] <fabbione> elmo: cheers :)
[06:53] <doko> halley:
[06:53] <doko> doko@halley:~$ w
[06:53] <doko>  17:53:16 up 9 days,  7:52,  2 users,  load average: 6.17, 5.34, 3.72
[06:53] <doko> USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
[06:53] <doko> doko     pts/0    82.211.81.135    17:05    0.00s  0.02s  0.01s w
[06:53] <doko> w(4130): unaligned access to 0x60000fffffffb5fc, ip=0x2000000000048040
[06:53] <doko> w(4130): unaligned access to 0x60000fffffffb5fc, ip=0x2000000000048060
[06:53] <doko> w(4130): unaligned access to 0x60000fffffffb5fc, ip=0x2000000000048040
[06:53] <doko> w(4130): unaligned access to 0x60000fffffffb5fc, ip=0x2000000000048060
[06:58] <doko> elmo: please could you install g++-3.4 on halley:breezy?
[07:01] <elmo> doko: done
[07:03] <doko> thanks
[07:10] <lamont> daniels: workrave needs your love
[07:10] <daniels> lamont: file a bug, I'm going to sleep after I upload all this shit
[07:10] <lamont> right
[07:12] <lamont> daniels: 11117 assigned to you
[07:12] <daniels> let's see how xorg -17 ftbfses
[07:12] <lamont> -17 is uploaded?
[07:13] <daniels> in the process of doing so
[07:14] <lamont> daniels: in /etc/sbuild.conf, do these need to change, too???
[07:14] <lamont>         "xlibs-dev"             => [qw(/usr/X11R6/lib/libX11.a /usr/X11R6/lib/libX11.so /usr/X11R6/lib/libICE.a /usr/X11R6/lib/libICE.so /usr/X11R6/lib/libXp.a /usr/X11R6/lib/libXp.so)] 
[07:14] <lamont>         "libgl-dev"                     => "xlibmesa-gl-dev",
[07:14] <daniels> just uploaded all the fun build-deps
[07:14] <lamont> :-)
[07:14] <daniels> lamont: aieeeeeee
[07:14] <elmo> doko: btw, given we're sticking with linux-gnu, we should probably make binutils and gcc match?
[07:14] <lamont> rather, what do they need to change to?
[07:14] <elmo> lamont: trash them all
[07:14] <lamont> woot
[07:14] <elmo> that's useless these days
[07:14] <daniels> lamont: libX11.* -> libx11-dev, libICE.* -> libice-dev, libXp -> libxp-dev (which is being removed anyway)
[07:15] <lamont> well, they're completely gone, now. :0)(
[07:15] <doko> elmo: yes, I just want Keybuk change _GNU_TYPE to i486-linux-gnu first
[07:15] <daniels> word
[07:16] <doko> elmo: should ask jbailey and fabbione first, if that would cause problems with glibc and the kernel
[07:17] <elmo> yeah, makes sense
[07:20] <cartman> aspell-en should depend on libaspell15c2
[07:20] <fabbione> i have no problems on whatever convention you want to use
[07:20] <cartman> this prevents aspell from upgrading
[07:21] <fabbione> just tell me your decision so that i can upload a fixed kernel-package
[07:23] <doko> cartman: ok, taking care of it
[07:24] <cartman> doko: thank you
[07:25] <cartman> daniels: ping?
[07:25] <daniels> cartman: pong
[07:26] <cartman> daniels: xbase-clients still depends on xlibmesa-glu in case you missed it
[07:26] <daniels> i certainly didn't miss it
[07:26] <cartman> daniels: cool ok :)
[07:26] <daniels> the good news: i know what the problem is
[07:27] <daniels> the bad news: i might have to wait until libglu1-xorg -17 enters the archive, then upload -18, before it's fixed
[07:27] <cartman> daniels: alright as far as you are aware, its ok
[07:32] <doko> daniels: could you put -18 on chinstrap, so somebody else can upload it, while you're sleeping?
[07:33] <daniels> doko: no
[07:34] <daniels> i've just uploaded -18 *now*, but that won't fix it (see #u-d)
[07:34] <daniels> if it's that desperately important that you need to upload your own -19, you can do that
[07:34] <daniels> but my next upload won't be for about aonther day or so
[07:34] <daniels> when I remove more modules, fix the keyboard and configuration bugs, and yeah
[07:41] <doko> daniels: is a simple re-upload supposed to fix the xbase-clients dependency on xlibmesa-glu?
[07:48] <doko> doko@concordia:~ $ w
[07:48] <doko>  18:48:22 up 9 days,  9:11,  3 users,  load average: 108.56, 108.98, 100.87
[07:48] <doko> USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
[07:48] <doko> fabbione pts/0    82.211.81.135    17:24   20:52  21.45s  0.00s /bin/sh /usr/bin/dpkg-buildpackag 
[07:48] <doko> fabbione pts/2    82.211.81.135    17:24   20:50  12.69s  0.00s /bin/sh /usr/bin/dpkg-buildpackag 
[07:49] <fabbione> doko: yeah.. 
[07:49] <fabbione> it's faster with -j100 :)
[07:49] <fabbione> doko: concordia can easily take up to -j500
[07:50] <doko> it's nice, if it's 2% faster for you, but for me, it's 500% slower :-(
[07:50] <fabbione> doko: it's almost finished :)
[07:50] <fabbione> and it's not just 2% faster :)
[07:50] <fabbione> it's like a lot faster
[07:51] <fabbione> elmo: please upgrade condordia to a 128 CPU's and 64Tera of RAM
[07:51] <doko> :)
[07:52] <doko> we buy low profile racks only ...
[08:09] <cartman> humpf
[08:10] <cartman> apt still not compiled against gcc4
[08:20] <elmo> WTF?!
[08:20] <elmo> why is db1-compat back? :P
[08:22] <elmo> err, and why is none of the X stuff turning up
[08:23] <doko> NEW?
[08:26] <elmo> hmm, some of the binaries, are still in queue/accepted, maybe that's it
[08:26] <elmo> but seriously, did someone restore the db1-compat dpeends on purpose?
[08:26] <elmo> oh, linux-gnu breakage, meh
[08:26] <fabbione> i remember Kamion mumbling about it
[08:27] <daniels> doko: xbase-clients MUST be built with libglu1-xorg >= 6.8.2-18 for the deps to be fixed
[08:27] <daniels> else it's a waste of an upload
[08:28] <doko> daniels: ok, will look at it tonight. are you still awake?
[08:28] <fabbione> doko: a -j50 has basically done...
[08:28] <fabbione> the other has almost finished
[08:28] <daniels> doko: can't sleep
[08:28] <doko> ;)
[08:29] <fabbione> daniels: what will happen to arches that will not build -18 right away? can they still catch up building xorg -19 ?
[08:32] <daniels> fabbione: sure, but xbase-clients will still be uninstallable
[08:33] <fabbione> daniels: who cares :)
[08:34] <doko> fabbione: maybe you as well, because kdelibs4c2 depends on it :-(
[08:34] <cartman> kdebase should too
[08:39] <Kamion> fabbione: I did?
[08:39] <Kamion> fabbione: I'm entirely happy for libdb1-compat to go away - it was always intended to, post-sarge
[08:40] <elmo> well, it's back, I suspect it only disappeared Thanks To Keybuk(tm)
[08:41] <elmo> we show need "keybuk broke my dpkg-architecture" t-shirts
[08:41] <elmo> s/how/so/
[08:48] <daniels> can someone please explain to me in very small terms why kdelibs4c2 depends on xbase-clients?
[08:48] <daniels> terms, words, whatever
[08:48] <elmo> daniels: autoconf
[08:49] <elmo> hmm, no, that's xutils
[08:49] <elmo> I give up
[08:49] <elmo> daniels: I bet it probably does path checkes for something in xbase-clients
[08:49] <elmo> I ungive up
[08:49] <daniels> if that's all it is, I'm going to fucking smash KDE
[08:50] <elmo> daniels: I think you need some sleep dude
[08:50] <elmo> whee, anastacia's gone INSANE
[08:50] <daniels> elmo: yeah, I think I do too, but it's not working out
[08:51] <elmo> please demote parted, K THANKS BYE
[08:51] <Kamion> eh?
[08:52] <elmo> Kamion: check out /home/katie/scratch/x
[08:52] <elmo> as I said.. INSANe
[08:52] <elmo> I think I managed to catch it while base was regenerating or something
[08:55] <fabbione> doko: i didn't build kde stuff yet
[08:55] <fabbione> Kamion: i think so... i didn't pay particular attention to it
[08:56] <daniels> kdelibs probably runs glxgears to benchmark it or something
[08:56] <lamont> ../boost/boost/config/compiler/gcc.hpp:81:7: warning: #warning "Unknown compiler version - please run the configure tests and report the results"
[08:56] <lamont> heheh
[08:56] <lamont> aqsis wants some porter-love
[08:56] <daniels> 'UNDER FIVE BAJILLION FPS, TOO SLOW, TRY A BETTER CARD YOU FRIGGIN' WEENIE'
[08:56] <daniels> (seriously, xbase-clients stuff requires a connection to an X server, so it can't be *using* it)
[08:58] <lamont> doko: would it be too much to ask for a list of all cxx{libs,apps} and the first version that is transitioned?
[08:58] <doko> > ----------------------------------------------------------------------
[08:58] <doko> > mrvn@mips:~$ amor
[08:58] <doko> > _KDE_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root
[08:58] <doko> > sh: line 1: iceauth: command not found
[08:58] <doko> > ICE Connection rejected!
[08:58] <doko> > ----------------------------------------------------------------------
[08:58] <doko> > 
[08:58] <doko> > Iceauth is contained in xbase-clients.
[08:58] <lamont> that'll help us make sure we have stuff built eventually
[08:58] <doko> This is almost certainly a general DCOP requirement, not a specific amor
[08:58] <doko> requirement (certainly the iceauth call doesn't show up anywhere in the
[08:58] <doko> kdetoys source tree).  I'm reassigning to kdelibs-bin accordingly.
[08:59] <doko> for the list of libs, see the wiki
[08:59] <lamont> doko: and that has the version that was uploaded with the change?
[08:59] <doko> I don't have one for the apps
[09:00] <doko> https://www.ubuntulinux.org/wiki/CxxLibraryList
[09:00] <daniels> OH MY GOD IT'S WORSE THAN I THOUGHT
[09:00] <lamont> cool
[09:00] <doko> lamont: yes
[09:00] <lamont> doko: it better not use that during the build...
[09:00] <lamont> (ice)
[09:01] <daniels> agh, thpethul ... thpethul!!!!
[09:01] <daniels> they include a complete copy of iceauth.c, and build it into libkICE
[09:01] <daniels> as well as including several other X source files
[09:01] <daniels> they then completely ignore that, and call the iceauth binary anyway
[09:02] <elmo> yeah, I still can't see why they're b-d-ing on it
[09:02] <cartman> uhm libICE is dcop only
[09:02] <elmo> it might actually be easier to test-compile it on concordia
[09:02] <fabbione> because it's 31337
[09:02] <elmo> hmm, or nto
[09:02] <daniels> elmo: not a b-d, only a depends for kdelibs4c2
[09:02] <daniels> i.e. kdelibs4c2 -> uninstallable
[09:02] <daniels> the solution here is to fix this fucking schitzrophrenia properly
[09:02] <elmo> daniels: OH
[09:02] <daniels> schitzophrenia, even
[09:09] <daniels> i'm going to try this whole sleep thing again
[09:22] <doko> daniels: I'm confused about gstreamer-plugins ... http://people.ubuntu.com/~lamont/buildLogs/g/gst-plugins0.8/0.8.8-3ubuntu2/gst-plugins0.8_0.8.8-3ubuntu2_20050523-1816-i386-failed.gz
[09:22] <lamont> micropolygon.cpp:41: error: declaration of 'Aqsis::CqMemoryPool<Aqsis::CqMicroPolygon, 512l> Aqsis::CqPoolable<Aqsis::CqMicroPolygon, 512l>::m_thePool' outside of class is not definition
[09:22] <lamont> micropolygon.cpp:42: error: declaration of 'Aqsis::CqMemoryPool<Aqsis::CqMovingMicroPolygonKey, 512l> Aqsis::CqPoolable<Aqsis::CqMovingMicroPolygonKey, 512l>::m_thePool' outside of class is not definition
[09:22] <lamont> feh
[09:22] <lamont> sigh...  that's an motu thing... sorry
[09:28] <cartman> doko: ping ?
[09:29] <cartman> doko: new aspell-en still depends on libaspell15 and not libaspell15c2
[09:29] <cartman> before ping timeouts ;)
[09:30] <cartman> uhm same for aspell-bin
[09:34] <doko> which version?
[09:34] <cartman> one second
[09:35] <cartman> aspell-en                       6.0-0-3build1
[09:35] <doko> dpkg -l aspell-bin
[09:35] <cartman> aspell-bin                      0.60.2+20050121-2ubuntu2
[09:36] <doko> ubuntu4 is the current
[09:36] <cartman> maybe fails on amd64 hmm
[09:36] <cartman> its not under http://people.ubuntu.com/~lamont/buildLogs/a/ or I am blind?
[09:37] <doko> http://people.ubuntu.com/~lamont/buildLogs/a/aspell/0.60.2+20050121-2ubuntu4/
[09:37] <cartman> huh thats weird
[09:37] <doko> no
[09:38] <cartman> its been kept back
[09:39] <cartman> ok manual install worked
[09:39] <cartman> only problem is aspell-en
[10:56] <lamont> doko: if you do another gcc-3.4 upload, could you do the expect 8.3 hack for hppa there too?
[10:57] <doko> did it work for 4.0?
[11:00] <lamont> dunno... it's waiting for 3.4 to finally finish.. :-)
[11:01] <lamont> Running /build/buildd/gcc-3.4-3.4.4/src/libjava/testsuite/libjava.compile/compile.exp ...
[11:01] <lamont> and if java segv's, I'm gonna be annoyed'
[11:09] <doko> lamont: could you me a favour an poke Gannef on #debian-release, so you need it? it's stuck in the new queue (expect-tcl8.3)
[11:10] <lamont> who's Gannfe?
[11:10] <doko> Joerg Jaspert, ftp-admin
[11:10] <lamont> doko: quite possible I only need it on 2.6 kernels --> ubuntu, but will go poke
[11:11] <doko> thanks
[11:12] <lamont> the request was really breezy driven
[11:33] <mvo> lamont: the new apt has finished building. should I upload aptitude now with a versionsied build-dependency? or will the new version now automatically pulled in as a build-depends?
[11:33] <mvo> I want to upload aptitude now
[11:33] <elmo> mvo: the former
[11:34] <elmo> you should always update build-depend appropriately and not assume/hope the latest version will be used
[11:34] <mvo> ok
[11:36] <lamont> elmo++
[11:43] <doko> elmq
[11:43] <lamont> what happened to elmp?
[11:43] <doko> hmm, elmp
[11:43] <doko> ;)
[11:56] <doko> lamont: does xorg build or is it waiting?
[11:57] <lamont> it's ftbts
[11:57] <lamont> ftbfs, even
[11:57] <lamont> because of xorg headers.  ROCK
[11:58] <lamont> ConnDis.c:38:23: error: X11/Xauth.h: No such file or directory
[11:58] <lamont> ConnDis.c:39:23: error: X11/Xdmcp.h: No such file or directory
[11:58] <doko> ok, preparing an uplaod ...
[11:58] <lamont> gcc -c -fsigned-char : now that's just _SICK_