=== Seveas [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain
[05:30] <fabbione> morning
=== fabbione sighs
[05:31] <fabbione> gcc-3.4 did FTBFS :/
[06:01] <fabbione> guys, did we start building C++ apps in main+
[06:01] <fabbione> ?
[06:01] <fabbione> or are they still banned?
[06:01] <infinity> Any particular ones on your mind?
[06:02] <fabbione> i am not 100% sure yet, but i think sparc needs to build one or two of them to be able to build C++ libs :/
[06:03] <fabbione> i am trying to unroll the loop right now
[06:03] <infinity> The ban list is still massively huge.  I'm going to assume it's main+universe, but I could check random apps.
[06:03] <fabbione> infinity: that would be great...
[06:04] <fabbione> i just need a few minutes to understand where i need to start :)
[06:10] <fabbione> i think the problem is freeglut3...
[06:10] <fabbione> i hate that there is no easy way to figure it out :)
[06:11] <infinity> Well, freeglut isn't in the ban list.
[06:11] <fabbione> but basically the problem starts with pike7.6 build-dep not being installable
[06:11] <infinity> So, if it's C++, and it's in main, I'd gues main's been unbanned.
[06:11] <infinity> However, freeglut build-deps on a bunch of xorg stuff, which may well be hideously broken right now.
[06:12] <fabbione> exactly
[06:12] <fabbione> that's the overall problem
[06:12] <fabbione> because as a result i see:
[06:12] <fabbione> The following packages have unmet dependencies:
[06:12] <fabbione>   libglu-dev-xorg: Depends: libglu1-xorg (= 6.8.2-20) but it is not going to be installed
[06:12] <fabbione> E: Broken packages
[06:12] <fabbione> and that seems to be somekind of conflicts between freeglu3 and xorg
[06:14] <infinity> Is this on your sparc machine?
[06:14] <fabbione> yes
[06:15] <fabbione> but iirc daniels had the same problem on i386
[06:15] <fabbione> let me check on a chroot
[06:15] <infinity> What do you see if you turn on apt's problemresolver and try to manually install libglu-dev-xorg?
[06:16] <fabbione> hmm crap.. it works on i386
[06:16] <fabbione> infinity: how do i enable the problem solver?
[06:16] <fabbione> if i install only libglu-dev-xorg it works..
[06:17] <fabbione> it's when i try to add some of the other build deps that it goes foobar
[06:17] <fabbione> i think one of the package has been built at different time from the other buildds
[06:17] <fabbione> so it's carrying wrong dependencies
[06:18] <infinity> You may have to dig down to that one and rebuild it then.
[06:18] <fabbione> infinity: yeah.. that's what i was trying to do :)
[06:19] <infinity> apt-get -o Debug::pkgProblemResolver="true" <action>
[06:19] <infinity> To turn on the debugger.
[06:21] <fabbione> meh!
[06:21] <fabbione> that output is sick
[06:22] <infinity> You get used to reading it after a while.  It's kinda like talkig to Culus.
[06:23] <\sh> what output? morning btw
[06:23] <fabbione> http://people.ubuntu.com/~fabbione/sparc-resolver
[06:23] <fabbione> infinity: can you help me understand it?
[06:30] <\sh> uhh...sometimes i should avoid reading documentation
[06:31] <infinity> fabbione : Is libglu1 installed in the chroot?
[06:31] <\sh> any c++ cracks online? 
[06:31] <\sh> :)
[06:32] <infinity> fabbione : Otherwise, I'm not sure what the problem is, since nothing appears to be depending on it from this output.  But libglu1 is definitely the problem.  Something wants to keep it, but you need the new libglu1-xorg
[06:33] <fabbione> infinity: nothing is installed in the chroot
[06:33] <fabbione> it's a buildd chroot
[06:33] <infinity> fabbione : Oh, unless your libsdl1.2-dev is out of date and depend on the old libglu-dev package.
[06:34] <fabbione> checking...
[06:34] <infinity> fabbione : Or, I'm half asleep.  Let me read more.
[06:36] <infinity> Meh.  Very twisty-turny, your dependencies are.
[06:36] <fabbione> libsdl1.2 has been built   State-Change        : 2005 May 25 18:18:39
[06:37] <fabbione> and it's the latest one accoring to what i can see
[06:38] <\sh> hmmmm
[06:38] <fabbione> \sh: this is sparc.. nothing is broken
[06:38] <fabbione> not in the main archive at least
[06:39] <\sh> fabbione: no...i'm reading the changes.html of gcc3.4
[06:39] <\sh> I'm stucked with arkrpg cause of c++ build errors
[06:39] <infinity> Package x11proto-gl-dev has broken dep on xlibmesa-glu-dev
[06:39] <infinity>   Considering xlibmesa-glu-dev 0 as a solution to x11proto-gl-dev 3
[06:39] <infinity>   Added xlibmesa-glu-dev to the remove list
[06:39] <infinity>   Fixing x11proto-gl-dev via keep of xlibmesa-glu-dev
[06:40] <infinity> (note that xlibmesa-glu-dev and libglu1-dev-xorg conflict)
[06:40] <fabbione> so X is fucked
[06:40] <fabbione> but that's nothing new :)
[06:40] <infinity> Oh, wait.  No, in the main archive that's okay...
[06:41] <infinity> What version of xorg do you have built?
[06:41] <infinity> You need something over -20 for this to all work out, it looks like.
[06:41] <\sh> but now I know why classic music can sometimes help you to understand things better
[06:41] <fabbione> i have -20
[06:41] <fabbione> there is nothing newer than that
[06:41] <infinity> Erm, I meant "-20 or over", so you should be okay there.
[06:42] <infinity> <grumble>
[06:42] <infinity> Stupid X.  Who needs GUIs anyway?
[06:42] <fabbione> i am afraid something has been built with xorg older than -20
[06:42] <infinity> Almost certainly.  If the problemresolver output doesn't make enough sense, it's time to pick each package out of the problemresolver list and check its deps with apt-cache.
[06:43] <infinity> Or install each one by hand until the problem leaps out at you.
[06:43] <infinity> I need to write a good parser for that output.  The longer it gets, the harder it is to decipher. :/
[06:44] <fabbione> now i am trying to install all the build-deps manually
[06:44] <fabbione> and keep only the minimum that fails to install
[06:44] <fabbione> and see if that helps the resolver
[06:44] <infinity> The first time something tries to install xlibmesa-anything, I think you've found your issue.
[06:45] <infinity> (You're positive the chroot is clean though, right?)
[06:45] <fabbione> infinity: yes
[06:45] <\sh> infinity: for the buildlogs? ogra made a nice attempt..he takes fabbiones .bz2 logfiles and parse it via python :)
[06:45] <fabbione> \sh: my logs???
[06:46] <fabbione> i don't even publish logs...
[06:46] <\sh> lamonts
[06:46] <\sh> sorry
[06:49] <fabbione> so xlibmesa-glu is the one that should never appear....
[06:49] <infinity> Definitely not.
[06:49] <fabbione> if so there are 2 apps that are guily of trying to pull it in
[06:50] <\sh> strike... i fixed my build errors with g++4
[06:50] <\sh> finally i managed it...
[06:50] <fabbione> infinity: can you reload the log?
[06:51] <fabbione> if i am not mistaken i can see only freeglut3 and gtkglarea5 
[06:52] <infinity> Wow, you made it uglier.
[06:52] <infinity> Congrats.
[06:52] <fabbione> uh why?
[06:52] <fabbione> it's shorter :)
[06:53] <infinity> Yeah, but it has more occurances of the string "gtk", so it's bad.
[06:53] <fabbione> ahahaha
[06:53] <infinity> gtkglarea definitely seems to be a problem, at any rate. :)
[06:54] <fabbione> i could just try to rebuild these packages manually and see if that helps
[06:54] <fabbione> given that they are buildable
[06:57] <fabbione> 80 -rw-r--r--  1 sparcbuildd sparcbuildd 75652 May 25 02:10 freeglut_2.2.0-8ubuntu3_20050525-0156
[06:57] <fabbione> 12268 -rw-r--r--  1 sparcbuildd sparcbuildd 12545643 May 26 21:55 xorg_6.8.2-20_20050526-1446
[06:57] <fabbione> DA DA!
[06:58] <infinity> Built them backwards?
[06:59] <fabbione> infinity: that's the order in which they come in....
[06:59] <fabbione> at least on the sparc buildd :/
[06:59] <fabbione> so yeah they have been built in the wrong order
[07:00] <fabbione> lamont: did you already build freeglut on hppa?
[07:01] <infinity> He's asleep.
[07:01] <fabbione> lamont: and if so.. with what version of xorg?
[07:01] <fabbione> oh ok
[07:01] <fabbione> yeah he did
[07:04] <fabbione> so ok.. the first one is freeglut3.. let's check the other one
[07:06] <fabbione> freeglut (2.2.0-8ubuntu4) breezy; urgency=low
[07:06] <fabbione>   * Remove | libglu-dev otherwise if libglu-dev-xorg (>= 6.8.2-20) something
[07:06] <fabbione>     bad is installed.
[07:06] <fabbione>  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Tue, 31 May 2005 07:06:37 +0200
[07:07] <fabbione> no wonder it did build :/
[07:07] <fabbione> there was a nice | libglu-dev that is provided by another 39439483 pkgs
[07:08] <\sh> laters guys
[07:09] <fabbione> 36 -rw-r--r--  1 sparcbuildd sparcbuildd 33080 May 25 09:09 gtkglarea_1.2.3-2ubuntu1_20050525-0903
[07:09] <fabbione> and same with this one...
[07:09] <fabbione> ehheh
[07:18] <fabbione> infinity: there.. everything should be fixed now
[07:18] <fabbione> and while we wait for the sources to come back.. 
[07:19] <fabbione> let's kick back gcc-3.4
[07:57] <\sh> re
[08:26] <elmo> fabbione: done (libxml2-dev, davis breezy-ppc64)
[08:28] <fabbione> elmo: thanks.. do i also have the kernel build-dep installed?
[08:34] <elmo> fabbione: do now
[08:34] <\sh> phew
[08:34] <fabbione> elmo: thanks.. it's nothing urgent
[08:34] <\sh> arkrpg fixed
[08:35] <fabbione> elmo: when you have a second i need to know a few internal bits of the autosync from debian stuff because i need to upload a package and i am afraid that it can break
[08:36] <fabbione> elmo: the scenario is:
[08:36] <fabbione> debian has package foo coming from source foo
[08:36] <fabbione> and right now we are syncing it
[08:36] <fabbione> i am going to upload package bar that will create a binary called foo that is a newer version of foo
[08:37] <fabbione> but we don't want to get foo from debian anymore
[08:37] <fabbione> foo as source
[08:37] <infinity> Then you need to blacklist foo.
[08:37] <infinity> Most probably.
[08:37] <elmo> infinity's right, but it's not urgent, you can't really break it any way that upsets me
[08:38] <fabbione> elmo: i have no rush at all
[08:38] <fabbione> i am still fucking with the package
[08:38] <fabbione> and fucking is on purpose
[08:38] <fabbione> i never seen such a pile of shit inside a single build system
[08:38] <fabbione> not even X is that complex and fragile
[08:39] <infinity> elmo : Can I get a sync of mysql-dfsg and mysql-dfsg-4.1, since we're talking syncs? :)
[08:41] <elmo> [BROKEN]  mysql-dfsg_4.0.24-5build1
[08:41] <elmo> [BLACKLISTED]  mysql-dfsg-4.1_4.1.11-3
[08:41] <elmo> BROKEN == we have a different orig.tar.gz to Debian somehow, I suspect
[08:42] <infinity> Oh, great.
=== infinity blames doko.
[08:43] <elmo> DEAR ANACRON, WHEN I GET UP IS NOT A GOOD TIME FOR CRON.DAILY.  KTHXBYE
[08:44] <fabbione> rotfl
[08:45] <infinity> elmo : Hrm.  Our orig.tar.gz matches, and our -5build1 is indentical to their -5, save for a new changelog entry.  (syncing should be updating to Debian's -10, however, which still has the identical .orig)
[08:49] <elmo> infinity: hmm, you're right, it's been UNBROKEN by someone, synced
[08:50] <infinity> Danke.
[08:50] <\sh> elmo: when r u moving python-qt3 to universe? :)
[08:51] <elmo> \sh: not until the kubuntu guys ack it as unneeded and/or I find out why it's up for demotion in the first place
[08:52] <\sh> hmm...lemme check it
[08:53] <infinity> elmo : Oh, can you sync libmysqlclient-lgpl too, and overwrite our changes?
[08:57] <elmo> done
[08:57] <infinity> \o/
[08:58] <infinity> That's the last time I hope to type the string 'mysql' for a couple of days at least.
=== chmj [~d3vic3@dumbledore.hbd.com]  has joined #ubuntu-toolchain
[09:39] <doko> fabbione: all C++ apps are rebuilt in main
[09:39] <fabbione> doko: ok.. i think i need to finish to build the libs first
[09:40] <fabbione> given doko^Wsomebody fucked a couple of build-deps :)
[09:40] <doko> yes, and add ftgl to the lib list
[09:40] <doko> ?
[09:41] <fabbione> doko: gtkglarea and freeglut :)
[09:41] <doko> so what's correct?
[09:41] <fabbione> if you want version dependencies than it's better you also remove the | libglu-dev that is provided by another 2032093829783297 pkgs :)
[09:42] <doko> ok, fine
[09:42] <fabbione> doko: just check the changes ;)
[09:42] <fabbione> i already fixed them
[09:55] <\sh> The following packages have unmet dependencies:
[09:55] <\sh>   xlibmesa-gl-dev: Depends: x11proto-gl-dev but it is not going to be installed
[09:55] <\sh> like this
[09:59] <\sh> fabbione: u had this issue before this morning, right? with x11proto-gl-dev
[10:00] <fabbione> nope
[10:00] <fabbione> it was a different one
[10:38] <\sh> k...just fixed it
[12:11] <fabbione> hmmmm
[12:12] <fabbione> go figure... gcc-3.4 is building now
[12:12] <fabbione> this is weird
[12:12] <fabbione> the build system is too weak
[12:13] <doko> ?
[12:14] <fabbione> doko: the last gcc-3.4 that was uploaded.. it was FTBFS yesterday for not finding stage2/xgcc or something similar
[12:14] <fabbione> kick back and it builds
[12:14] <fabbione> so there is something that is weak
[12:15] <doko> fabbione: well, yes, but that is only seen on buildd's. never saw this for local builds
[12:15] <fabbione> doko: *cough*fix it*cough*
[12:15] <fabbione> ;)
[12:15] <fabbione> doko: you should definetely install sbuildd
[12:15] <fabbione> and test with it
[12:16] <doko> fabbione, would you mind a gcc-4.0 upload introducing powerpc biarch?
[12:16] <fabbione> doko: not at all, if it fixes the /usr/lib64 -> /lib64 thing
[12:16] <doko> fine, it does as well
[12:16] <fabbione> plus if i am told in advance i can still avoid that it will be taken for build
[12:56] <infinity> <fabbione> doko: *cough*fix it*cough*
[12:56] <infinity> <fabbione> ;)
[12:56] <infinity> <fabbione> doko: you should definetely install sbuildd
[12:56] <infinity> <fabbione> and test with it
[12:56] <infinity> <doko> fabbione, would you mind a gcc-4.0 upload introducing powerpc biarch?
[12:56] <infinity> Gah.
[12:56] <infinity> Bad mouse.  BAD.
[12:56] <fabbione> infinity: stop playing with it :)
[12:57] <doko> just curious where he wanted to paste it ... ;-P
[12:57] <infinity> Didn't want to paste that anywhere. :)
[12:57] <infinity> I just shouldn't drink and IRC.
[12:58] <doko> hopefully your keyboard is beerproof ;)
[01:20] <elmo> daniels: around?
[01:20] <infinity> He appears to be decidedly not around.
[01:20] <infinity> If it's urgent, I can call him.  Otherwise, I'd assume he'll be on tonightish.
[01:21] <fabbione> elmo: can you ping me back when you a few minutes free?
[01:21] <fabbione> (nothing urgent)
[01:21] <fabbione> (and it's NOT sparc related :P)
[01:25] <jbailey> fabbione: But you got this GREAT little m32r on ebay yesterday?
=== jbailey hides.
[01:25] <fabbione> ehhe
[01:25] <fabbione> you wish :)
[01:25] <fabbione> i never bought a single thing from ebay
[01:25] <fabbione> dunno why but i don't trust it
[01:28] <jbailey> Almost all of the Cisco equipment at my last job came from Ebay.
[01:28] <jbailey> Rather than buying Smartnet, we simply bought two of every device.
[01:29] <fabbione> eheh
[01:29] <jbailey> Aside from it still being half the price, it also was faster - smartnet doesn't promise faster than 4 hours.
[01:29] <jbailey> Forever in the financial industry.
[01:30] <fabbione> uh wow
[01:30] <fabbione> i never needed something faster than 4 hours
[01:30] <jbailey> They got squirmy about about the 6 minute mark.
[01:30] <jbailey> (during the day)
[01:30] <fabbione> wow
[01:31] <jbailey> In the evening they really wanted to be up in about 30 minutes, but even then the downtown would often take them hours to get all the mirrors sync'd again.
[01:32] <jbailey> fabbione: Part of the problem is that we ran the CA for the entire mutual fund industry, as well as handling all the cross-company transactions.  When we went down the entire mutual fund industry essentially stopped.
[01:32] <jbailey> And it was mostly done with used Cisco gear from Ebay. =)
[01:36] <fabbione> hehe
[01:37] <doko> jbailey: what's our time plan for java-gcj-compat entering main?
[01:38] <jbailey> doko: I don't know how these things all work.  I guess it could go in anytime now that we have g[ci] -4 as the default.
[01:39] <doko> jbailey: elmo doesn't want to do that currently, looking at the dependency chain ...
[01:40] <jbailey> I've so far just ignored the whole is-it-in-main-or-universe bits...  What do you recommend?
[01:40] <jbailey> doko: Eventually all of eclipse and its build-deps will wind up in main.
[01:41] <jbailey> doko: So I'm not sure that there's anything that can be done to reduce the dependancy chain.
[01:41] <doko> it sucks in jikes and sablevm as well at the moment ...
[01:41] <jbailey> Ugh.
[01:42] <jbailey> I can chew through and fix that.  Let's say 2 weeks from now?
[01:43] <jbailey> That should give me time to get EarlyUserspace a bit further than it is now and still get a good chunk of it done and see where it needs to go.
[01:45] <doko> ok, no problem, but then we'll have to move OOo2 to universe for that time, currently uninstallable and unbuildable
[01:46] <jbailey> Probably easiest.
[01:46] <Kamion> does OOo still work? do you have a plan to keep the desktop working (it currently depends on OOo2)?
[01:47] <doko> OOo does work, it's already rebuilt
[01:49] <doko> Kamion: the current snapshot is still the old one, so we really don't want it in main, the current snapshot doesn't build yet, because gcc-4.0 got a bit stricter again
[01:56] <fabbione> elmo: is there any reason why pqm is running on concordia?
[01:56] <fabbione> or did we change porting box?
[01:57] <elmo> fabbione: baz commits auto-build on our 3 main architectures
[01:57] <elmo> as the 'pqm' user
[01:57] <fabbione> ahhh ok
[02:34] <chmj> elmo: can you please install libbluetooth1-dev in concordia's breezy chroot
[03:37] <daniels> elmo: pong
[03:39] <daniels> spent most of today unable to remember my password to unlock my laptop.  \o/
[03:40] <jbailey> *g*
[03:42] <doko> daniels: so the cocktails were quet good?
[03:43] <daniels> doko: s/cocktails/painkillers/, but yes
[03:43] <doko> ah, drug cocktails ;-)
=== Seveas [~seveas@seveas.demon.nl]  has joined #ubuntu-toolchain
[04:08] <elmo> daniels: nothings using the new X stuff yet - is it actually targetted for main?
[04:08] <elmo> chmj: done
[04:13] <daniels> elmo: all of it; xorg b-ds on it
[04:14] <daniels> elmo: (and various pieces of gnome, etc, b-d on libice-dev and depend on libice6, ditto libsm{-dev,6})
[04:15] <chmj> hmm, any reason why avifile is not built on ppc and ai64 ?
[04:16] <jbailey> daniels: Is there some sort of useful diagnostic I can do to figure out why xorg suddenly will eat 98% of my CPU and do so for 4 or 5 minutes at a time?
[04:17] <daniels> jbailey: if you have another machine, and you're running xserver-xorg-dbg rather than -xorg, you could break on WaitForSomething and step through to figure out what it's doing with its time
[04:18] <jbailey> 'kay.  It happens a couple times a day so I'll try to wire that up.
[04:18] <elmo> daniels: sorry, xorg in the archive, or it will at some stage?
[04:19] <elmo> I'm just trying to work out why anastacia is keen to demote them; if it's a temporary/pending thing, that's fine, I just need to know before I start trying to work out why germinate/anastacia's confused
[04:21] <Kamion> xorg probably still delivers libice*
[04:22] <elmo> it's not ice, it's the new x-proto stuf and libsm
[04:22] <elmo> (panoramix, render, record, rsrc and screensavere)
[04:22] <daniels> elmo: will be
[04:22] <elmo> ok
[04:23] <daniels> figured there wasn't really much point in uploading them 'till I found out if all its new b-ds were ftbfs or not
[04:23] <daniels> WHOOHOO!!
[04:23] <daniels> fuck I'm shit
[04:24] <chmj> infinity, ping 
[04:28] <doko> chmj: why did you re-upload avifile?
[04:32] <chmj> to rebuild 
[04:32] <chmj> that doesn't seem to have worked ;/
[04:33] <doko> chmj: you didn't try ...
[04:34] <chmj> hmmm ?
[04:39] <doko> infinity, lamont: please retry the build for avifile on powerpc and ia64
[04:56] <lamont> daniels: my life would be easier if -16 had actually not been FTBFS
=== lamont creates -16hppa1 so that he can then build -20, grumbling
[04:57] <daniels> sorry, I know it's shit
[04:57] <daniels> nothing I can do about it
[04:58] <daniels> and I figure I might as well spread the pain as evenly as I possibly can
[04:58] <lamont> daniels: yeah, understood.
[04:58] <daniels> which I've been doing a sterling job of by shitting off porters and making it FTBFS on all the main arches anyway
[04:58] <doko> daniels: it's not a problem, if you tidy up afterwards ;)
[05:07] <lamont> daniels: seriously, if you would upload something that wasn't ftbfs, before you made xorg's build-deps uninstallable, that'd be a big help... :-)
[05:09] <lamont> daniels: what's the rules target to unpack and patch again?
[05:10] <daniels> lamont: setup
[05:10] <lamont>  /bin/bash: up-scripts: command not found
[05:10] <lamont> feh
[05:10] <daniels> lamont: i do my best to not have things ftbfs
[05:10] <daniels> lamont: that's not fatal
[05:10] <lamont> -16 had radeon ftbfs issues
[05:10] <daniels> lamont: unfortunately, not having things ftbfs is difficult when you have people demanding you upload what you have, yesterday
[05:10] <lamont> hehe
[05:11] <daniels> lamont: yeah, that didn't trigger on the main architectures ... go figure
[05:11] <lamont> yeah... did -17 require -16 to build, or when did that build-dep come into play?
[05:11] <daniels> the only change in -17 was fixing that ftbfs, iirc
[05:12] <daniels> or something, I can't really remember
[05:12] <daniels> most of them were done at like 3am after staring at builds going past for long enough to make my eyes bleed
[05:12] <lamont> ok
[05:12] <lamont> I'll just create a -16hppa1 then
[05:21] <lamont> O'
[05:22] <lamont> I'm going to go out on a limb, and guess that libsigc++-1.2-dev should Depend: libsigc++-1.2-5c102, not libsigc++-1.2-5
[05:24] <lamont> no, other way around
[05:24] <Kamion> bad shlibs?
[05:25] <lamont> bad build order
[05:27] <lamont> hrm.. actually it appears to be morgifiying things when I shouldn't (in my archive)
=== chmj [~d3vic3@dumbledore.hbd.com]  has joined #ubuntu-toolchain
[05:30] <lamont> s/shouldn't/didn't really want to even though I told it to/
[05:30] <doko> lamont: libsigc++-1.2-5 is correct
[05:31] <lamont> yeah, I figured that out.
[05:31] <lamont> closer root cause was that the package was recently? demoted to universe
[05:34] <doko> Kamion, jbailey: please could you bring up the topic of OOo2's build dep's in universe and OOo2 itself in main up in today's TechBoard meeting? I'm not at home before 22.00 UTC
[05:35] <jbailey> doko: Just basically whether it could be bumped back to Universe for a couple weeks while we sort it out?
[05:35] <doko> jbailey: yes
=== jbailey adds to the agenda.
[05:35] <lamont> the buildd's would appreciate that.
[05:35] <fabbione> hey guys
[05:35] <doko> we don't have the time to work on java now, and a working OOo2 in breezy would be just good
[05:38] <jbailey> doko: Added to the agenda.
[05:44] <\sh> hmm...the maintainer candidates on tbagenda can be removed, 
[06:11] <Riddell> lamont: python-qt3 couldn't build because of a depend in universe, it's now been moved to universe, will the buildd pick up the change next time it tries to build?
[06:11] <lamont> Riddell: should
[06:12] <Riddell> \sh: so hopefully the buildds will get round to it soon and it'll all work
[06:17] <Kamion> hmm, I uploaded libqt-perl a while ago, but no build yet
[06:20] <doko> buildd darkness ...
=== lamont gets his flood light
=== lamont points Kamion at doko (cxxapps.txt)
[06:29] <lamont> doko: did we get that list of cxxapps that we can release yet?
[06:30] <doko> lamont: no, just removed libqt-perl
[06:32] <doko> well, looks like I have to walk through this list and sort out the apps, which can be built ... the MOTU's aren't that fast ...
[06:34] <lamont> libqt-perl removed.
[06:34] <lamont> note that changing that list involves stopping and starting the buildd, not just a SIGHUP
[06:34] <lamont> doko: if possible, would be good to look on ports.u.c and see which ones can be removed for ia64/sparc/hppa at the same time
[06:34] <Kamion> quality
[06:35] <lamont> or at least make a list of depends
[06:35] <lamont> Kamion: heh
[06:36] <doko> Kamion: quality?
[06:36] <Kamion> doko: "high-quality", sarcasm
[06:37] <doko> we should have such kind of dependency checker in soyus?
[06:38] <lamont> soyuz will know that a package's build-deps are not met, and not build it...  BUT IF YOU DON"T UPDATE THE BUILD-DEPS, HOW CAN IT POSSIBLY KNOW???
[06:39] <Kamion> not that lamont is bitter or anything
[06:39] <lamont> :-)
[06:40] <doko> lamont: ia64 should be same as the release architectures. I don't know about sparc and hppa, they are occupied with toolchain and xorg builds all the time ...
[06:40] <lamont> Kamion: at least one buildd of each arch has restared, should grab libqt-perl
[06:41] <lamont> doko: yeah - it's more a question of how to know when the build-deps for cxxapp 'foo' are sane again, and it can be removed.
[06:41] <Kamion> I mostly only care about i386 ;-)
[06:41] <Kamion> (for the debconf arch: all build ...)
[06:41] <lamont> Kamion: ah, yes
=== lamont d-w's debconf on qt-perl
[06:43] <lamont> Kamion: you gonna care about grub next?
[06:44] <Kamion> why's grub building on ia64 in the first place?
[06:44] <lamont> Automatic build of grub_0.95+cvs20040624-17ubuntu1 on vernadsky by sbuild/i386 1.170.5
[06:44] <lamont> or is there a newer one?
[06:44] <Kamion> oh, looking at the wrong version, sorry
[06:44] <lamont> %grub: i386 hurd-i386 amd64                                           # i386 boot loader
[06:45] <jbailey> lamont: Ugh.  Type type-handling add amd64 for i386-all? 
[06:45] <Kamion> lamont: it's ok, I was looking at some ancient version by mistake
[06:45] <jbailey> s/Type/Does/
[06:46] <lamont> jbailey: what's type-handling?  we don't have that in main
[06:46] <Kamion> can I make infinity fix grub? he touched it last.
[06:46] <lamont> and yes, grub should be there for amd64
[06:46] <lamont> Kamion: hehe.  no objections here
[07:01] <jbailey> lamont: I think grub uses type-handling in Debian - did you really add hurd-i386 to the result in Ubuntu? =)
[07:01] <jbailey> (when removing t-h)
[07:06] <lamont> jbailey: that's looking at Packages-arch-specific
[07:08] <Kamion> Package: grub
[07:08] <Kamion> Architecture: darwin-i386 freebsd-i386 hurd-i386 kfreebsd-i386 knetbsd-i386 i386 netbsd-i386 openbsd-i386 amd64
[07:09] <Kamion> looks like we just kept the generated debian/controol
[07:09] <Kamion> control
[07:09] <Kamion> lamont: grub has significant DEB_*_GNU_* fun; fixing
=== 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]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
=== desrt [~desrt@kopesetik.desrt.ca]  has joined #ubuntu-toolchain
[07:37] (lamont/#ubuntu-toolchain) jbailey: I'm sure that there is... I just need to figure out how exactly... there are some code changes to be done before it would be trivial
=== ajmitch [~ajmitch@port162-41.ubs.maxnet.co.nz]  has joined #ubuntu-toolchain
=== 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
[11:47] <lamont> doko: I'd be interested in knowing how to tell if a cxxapp can be released for building, btw.
[11:47] <lamont> that is, what your check is.
[11:51] <\sh> damn
[11:56] <\sh> what about c libs with unresolved deps?