[12:06] <jbailey> Riddell: You around for a moment or two?
[12:07] <Riddell> jbailey: yes
[12:08] <jbailey> Riddell: I've discovered that a newer snapshot of arts doesn't fail.  How ugly is it if I just update it?
[12:08] <Riddell> jbailey: from svn?
[12:09] <jbailey> From ftp.kde.org, but it was in the unstable directory.  I can slowly work back and converge, or cherry pick a patch out if that's a better idea.
[12:10] <Riddell> jbailey: well it's not a problem at all, there will be a new KDE point release in a week anyway
[12:10] <\sh> 3.4.1?
[12:10] <jbailey> Riddell: This package doesn't appear to have a ChangeLog, so I don't have any hints as to how far apart they are in development.
[12:11] <Riddell> \sh: yes
[12:11] <\sh> Riddell: nice
[12:11] <Riddell> jbailey: arts isn't really maintained
[12:11] <Riddell> jbailey: from daily snapshots?  ftp.kde.org/pub/kde/unstable/snapshots 
[12:13] <Riddell> jbailey: it would be better to get it from 3.4 brach if that works
[12:13] <Riddell> branch
[12:13] <jbailey> Right, that's where it was from.
[12:13] <jbailey> 'k, I'll look at that too then.
[12:17] <Riddell> jbailey: http://dev.kubuntu.org.uk/~jr/kubuntu/arts-svn20050519.tar.bz2
[12:17] <Riddell> that's from kde 3.4 branch
[12:17] <Riddell> but if it doesn't work just use a snapshot from head
[12:20] <jbailey> Makefile.am.in?
[12:20] <jbailey> What's the right tool to generate a build env out of that?
[12:22] <\sh> Makefile.cvs?
[12:22] <\sh> or was it a script under admin/
[12:23] <jbailey> Trying makefile.cvs
[12:25] <jbailey> seems good.
[12:25] <jbailey> Thx. =)
[12:31] <jbailey> Riddell: This one works.  I'll try to see if there's something quick between the two.  I'm only worried because the failure shows up only on ppc.
[12:34] <Riddell> make -f debian/rules buildprep   (which runs make -f Makefile.cvs which runs make -f admin/Makefile.common cvs)
[01:08] <doko> back again
[01:13] <jbailey> doko: arts bug appears to be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[01:13] <jbailey> doko: Newer snapshot has a workaround for it, but maybe consider it for out 4.0 package?
[01:13] <jbailey> s/out/our/
[01:20] <doko> doh! 54 comments, maybe we just found the regression mark asks for ..
[01:23] <doko> jbailey: maybe you could add your comments to the report?
[01:25] <jbailey> "spent 3 hours chasing why old software didn't work.  That really sucked.  Please apply."
[01:25] <jbailey> s/didn't work/didn't work on ppc only, but worked fine on ia64, i386 and amd64/
[01:26] <jbailey> I'll do a test run overnight first to make sure this patch actually fixes it. =)
[01:28] <doko> heh, yes
[01:43] <jbailey> Riddell: Erm, does that make -f admin/Makefile.common cvs overwrite acinclude.m4? 
[01:46] <Riddell> jbailey: yes, it'll replace it with the one from admin/acinclude.m4
[01:48] <jbailey> Riddell: This packaging is going to drive me to drink.
[02:33] <jbailey> lamont: -xc is fine.
[02:59] <jbailey> lamont: arts uploaded, ready to watch her spin.
[05:25] <lamont> jbailey: coolness
[05:27] <infinity> doko : How goes the transition, and are there things you want help with?
[05:27] <infinity> (upload monkeying, whatever)
[05:31] <lamont> doko: what's the story with gnome-menus?
[05:32] <lamont>   libgnome-menu-dev: Depends: libgnome-menu2 (= 2.11.1.1-0ubuntu1) but it is not installable
[05:40] <fabbione> morning guys
[05:40] <lamont> morning fabbione 
[05:41] <fabbione> hmm coolness
[05:41] <fabbione> kicking back gcc made it compile this time
[05:41] <lamont> fabbione: when seb128 is awake again and/or doko, wanna ping them wrt gnome-menus?  (see above)
[05:42] <fabbione> sure
[05:43] <fabbione> are you already compiling C++ apps?
[05:43] <lamont> libs
[05:43] <fabbione> ok
[05:43] <lamont> eel2 et al are backed up.  could be that we need to deal with bootstrapping something, but ew.
[05:43] <fabbione> uh? crap
[05:43] <lamont> libgnome-menu0 2.10.<mumble> is current in the archive
[05:44] <lamont> gnome-menu is not listed in cxxapps.txt
[05:55] <lamont> jbailey: you probably don't want to know that arts_1.4.0-0pre1ubuntu6 is ftbfs on ppc,  do you?
[05:56] <lamont> actually, that is pretty old news
[06:13] <fabbione> night lamont
[06:13] <lamont> g'night
[06:20] <infinity> 'night lamont.
[06:32] <jbailey> lamont: ubuntu7 is the one I uploaded. =)
[06:34] <jbailey> fabbione: I did an lkh upload - Can you give back xorg?
[06:34] <fabbione> jbailey: yup! i saw that
[06:35] <\sh> hmmm
[06:35] <fabbione> i need to wait gcc-4.0 to finish
[06:35] <fabbione> \sh without all the libs, is really BAD to build apps
[06:35] <infinity> Indeed.
[06:35] <\sh> fabbione: well...i needed only arts kdelibs4c2 
[06:36] <\sh> right now :) and libqt
[06:36] <\sh> and everything is there
[06:36] <\sh> with some tricks, yes;)
[06:37] <infinity> Note that the app recompiling is going to be done automagically once the libs are done.
[06:38] <\sh> infinity: problem is adjusting the build-deps and finding out bugs in the c++ code itself...and I need at least a testing env for some other things like qt bindings/kde bindings :) 
[06:39] <\sh> and other question is, has anybody the resources to have a "remote access possibility" to ppc and amd64 machines to do a test breezy chroot on it?
[06:40] <infinity> Adjusting build-deps?... The -dev packages shouldn't be changing names, only the library packages..
[06:41] <\sh> infinity: as I learned yesterday, we should tighten the build-deps to the latest libs compiled with g++4
[06:42] <\sh> so it means the -dev package must be something like >= version-ubunturev
[06:43] <infinity> Interesting.  That wasn't (and still isn't) in the transition plan.  And it also means mangling every single C++ app, which was previously not going to be done.
[06:45] <\sh> so there are >1 real truth
[06:46] <jbailey> I don't know how much value there is in tagging every build-dep.  The only value is people backporting, and with a 6 month release cycle it's hard to feel any sympathy.
[06:47] <\sh> in the end, I adjusted some nice pitfalls with packages directly from debian and on cxxtransition list
[06:47] <\sh> wrong makefiles etc. 
[06:49] <infinity> \sh : If those bugs are relevant to both Debian and Ubuntu, could you get them filed upstream?
[06:49] <\sh> infinity: sure
[06:49] <infinity> As for having all our build-deps diverge with Debian, that seems ludicrous, as we're suddenly carrying around a bunch more patches that prevent us from syncing easily.
[06:50] <jbailey> infinity: We have that anyway - But Debian is at least on a path to convergeance.
[06:50] <infinity> And in the Ubuntu case, it's pointless from a buildd perspective, cause we keep tight control over how each package is compiled anyway.
[06:51] <infinity> And it's not even relevant for backports, since the packge IS buildable with the old build-deps.
[06:51] <\sh> well...sometimes it's only a pitfall cause some packages are using cdbs with autotools.mk and behaving not as expected 
[06:51] <infinity> If anything, updating the build-deps makes backports harder for no real reason (it doesn't help the archive's consistency)
[06:52] <\sh> is gcc/g++ 4.0.x default in debian unstable now?
[06:52] <infinity> \sh : No.  Won't be until after Sarge releases.
[06:53] <infinity> That doesn't seem relevant, though.  There's no law that states a source package has to produce specific binary dependencies outside of a specific archive/suite.
[06:53] <\sh> hmmm..after hurd release then ;)
[06:54] <infinity> (example being someone who builds a package on woody that happens to have the build-deps satisfied, and ends up with different glibc/stdc++/ncurses/whoknows deps)
[06:55] <\sh> in my point of view, if we're trying to compile apps now to test if the upstream source works to compile nicely with 4.0.x suite
[06:55] <infinity> Inverse example is all the stuff we recently synced from Debian that is uninstallable on Debian systems, because we have a newew glibc.
[06:55] <\sh> or not makes sense and fixing it
[06:56] <infinity> \sh : Oh, by all means, compile away, using new libs, I'm just arguing that tightening build-deps is broken, and isn't what build-deps are for.
[06:57] <infinity> If we seriously think that's what build-deps are for, then we need to change every package in Ubuntu to build-dep on libc6-dev >= 2.3.5
[06:57] <\sh> infinity: ok, then I can change the build-deps not to be tightend, but some packages are having g++ as build deps (tightent to 3.3 or at least 3.1)
[06:57] <infinity> Which is, obviously, retarded.
[06:57] <infinity> \sh : Any packages with g++ (unversioned) as a build-dep are wrong (it's in build-essential), but won't break.
[06:57] <infinity> \sh : Any package with a versioned g++ build-dep, find out why first. :)
[06:58] <infinity> (And, odds are, most of them are wrong too.. Except for stuff depending on qt2... Which should just go away)
[07:02] <\sh> k..lets see what to change anyways..
[07:12] <daniels> it's my mum's birthday today, and she's showed up a few hours earlier than expected, so I'm going to be AFK until very late tonight.  will be working on the weekend, though.
[07:12] <infinity> Have fun birthdaying.
[07:12] <infinity> I'm working all weekend too, to make up for moving/immigration time wasteage.
[07:18] <daniels> heh.  wot fun.
[07:28] <fabbione> daniels: did you plan to upload zorg any time soon?
[07:29] <fabbione> let say within the next 12 hours...
[07:39] <daniels> fabbione: that's the plan, I'm just fixing the last bits now
[07:40] <daniels> do you need something done, or just wondering whether or not to kick off a sparc build?
[07:41] <fabbione> daniels: well if you upload -16 soon it's ok
[07:41] <fabbione> i just don't want to kick -15 and get -16 in the queue 4 hours after :)
[07:41] <fabbione> i think the fix to l-k-h should be enough to build X
[07:41] <fabbione> but i can't test until gcc-4.0 is finished
[07:43] <daniels> cool
[07:43] <daniels> ok, bbiab
[07:44] <fabbione> ok
[11:38] <doko> hi fabbione
[12:02] <fabbione> hey doko
[12:03] <doko> how's sparc going?
[12:06] <chmj> hey doko 
[12:06] <fabbione> doko: weird enough gcc-4 didn't build at the first shot
[12:06] <fabbione> it's installing right now
[12:13] <doko> hi chmj
[12:24] <doko> lamont, elmo: please requeue libsdl1.2 on powerpc, the build deps should be there now (and if that's built, xine-lib as well)
[12:28] <doko> lamont, elmo: libtunepimp on all archs
[12:29] <doko> Kamion: libxplc0.3.11-dev (universe) is a build dependency of wvstreams (main), could you update the seeds?
[12:30] <Kamion> there is no need to update the seeds for that
[12:30] <Kamion> germinate follows dependencies and build-dependencies; the *point* of seeds is not to have to list all that stuff. :)
[12:30] <doko> hmm, the buildd doesn't know about it yet
[12:30] <Kamion> yes, elmo needs to move it to main
[12:31] <Kamion> universe->main propagation is only semi-automatic
[12:33] <doko> elmo: please move xplc to main
[12:52] <elmo> is there any point in maintaining the sync blacklists still?
[12:55] <doko> elmo: which ones?
[12:55] <elmo> cxxapps and cxxlibs
[12:56] <doko> we can drop the cxxlibs for main, every library package now should have a ubuntuX upload.
[12:59] <doko> I'll start uploading -buildN packages today (C++ apps in main), then we can drop the cxxapps from main as well.
[01:00] <elmo> but, a sync would have the same affect as -buildN wouldn't it?
[01:00] <elmo> well, I suppose not for non-main, ok, blah, nm
[01:02] <fabbione>  signfile gcc-4.0_4.0.0-7ubuntu6_sparc.changes C14C0CBD
[01:02] <fabbione> yay
[01:02] <doko> elmo, yes, for main we can sync again, if all libs are built, but they are not yet. kdelibs wasn't yet uploaded.
[01:10] <\sh> doko: upload it ;)
[01:10] <\sh> doko: or do u want to wait until 3.4.1 is out?
[01:11] <doko> Riddell and amu are preparing the package ...
[01:11] <doko> they do have the needed patches
[01:15] <fabbione> daniels: ping?
[01:16] <fabbione> hey jb
[01:16] <fabbione> going to kick back X in a few minutes
[01:16] <fabbione> food first :)
[01:17] <jbailey> Yeah, I need breakfast and then to do the glibc upload to fix the dependancy.
[01:17] <fabbione> can you also check that ulti-linux FTBFS on sparc?
[01:17] <fabbione> it claims an error in one include file shipped by glibc
[01:17] <jbailey> Yeah, umount2 redefinition.
[01:18] <jbailey> I just love these things that show up on one arch only. =)
[01:18] <fabbione> :)
[01:23] <jbailey> Hmm, this will be fun.
[01:23] <jbailey> I have a workshop that I'm supposed to go to this afternoon and I forgot to rent a car.
[01:23] <jbailey> May long weekend - biggest party WE of the year in this city. =(
[01:29] <doko> elmo: please move libdc1394-13-dev to main, build dependency of pwlib
[01:37] <jbailey> fabbione: Oh right, I did look at this before.  Sparc and arm specific define, stupid.
[01:39] <jbailey> I should try harder to get sysutils to where it replaces util-linux.
[01:45] <doko> elmo: could you give me a list of main cxxapps, for which newer debian versions exist?
[01:58] <jbailey> fabbione: Uploaded.
[01:58] <fabbione> eheh i see thanks
[01:59] <fabbione> so it was not glibc
[02:00] <jbailey> Nope.  #if defined (MNT_FORCE) && !defined(__sparc__) && !defined(__arm__)
[02:04] <fabbione> ok xorg kicked back
[02:04] <fabbione> elmo: thanks for ocfs2-tools NEW love :)
[02:09] <fabbione> daniels: please please please do NOT upload xorg -16 now that i started building -15
[02:12] <lamont> elmo: gconfmm2.6 UNACCEPT
[02:12] <lamont> Rejected: libgconfmm-2.6-1c2_2.10.0-0ubuntu3_amd64.deb is NEW for breezy.
[02:13] <fabbione> hey lamont
[02:22] <lamont> morning fabbione 
[02:30] <jbailey> g'm lamont
[02:36] <doko> hi lamont
[02:51] <fabbione> hmm lamont 
[02:51] <fabbione> perhaps you want to kick back ocfs2-tools
[02:51] <fabbione> or update the chroots
[02:51] <fabbione> E: Package debhelper has no installation candidate
[03:03] <doko> lamont: ross sbuild/powerpc still tries to install an outdated libarts-dev, when building libsdl1.2
[03:04] <doko> lamont: please build openh323
[03:05] <doko> lamont: please build libtunepimp
[03:11] <daniels> fabbione: uhm, ok
[03:11] <fabbione> daniels: you were too slow :)
[03:11] <fabbione> sorry ;)
[03:12] <fabbione> daniels: if you want to go to sleep, just stick the sources somewhere and i will upload them for you if it fails 
[03:12] <fabbione> or after it completes the build and i can uplaod the bins
[03:15] <daniels> nah it's ok, I'll do it tomorrow morning
[03:15] <daniels> it's not urgent, just more modularisation and some hppa love
[03:16] <fabbione> ok
[03:16] <fabbione> so if it still doesn't build you can give sparc love too :)
[03:17] <daniels> fo'sho
[03:18] <doko> daniels: do you have a chance to investigate the libpng3 miscompilation on powerpc?
[03:26] <daniels> doko: not now I don't
[03:26] <daniels> how urgent is it?
[03:27] <daniels> i plan to spend all tomorrow (saturday) catching up on xorg stuff, which would mean that monday or tuesday would be the first chance I got to look at libpng stuff
[03:28] <doko> it's wrong code generation in our default compiler, so it's not minor, just wanting to have the testcase in the bug report, so I can investigate it on ppc without building xorg
[03:31] <daniels> the testcase should already be there
[03:31] <daniels> grab davis:~daniels/redglass/X_cursor*, and run xcursorgen X_cursor.cfg X_cursor, on powerpc with the affected libpng
[03:34] <doko> are the xcursorgen sources there as well?
[03:36] <daniels> nope
[03:36] <daniels> you can pull it out of xbase-clients tho
[03:37] <daniels> ar x xbase-clients_6.8.2-16_powerpc.deb data.tar.gz && tar zxvf data.tar.gz usr/X11R6/bin/xcursorgen, or something
[03:37] <doko> ok thanks, will look at it
[03:38] <daniels> np
[04:28] <doko> lamont: did you reschedule openh323 and libtunepimp?
[04:31] <lamont> doko: once I see what exactly "reschedule" means in buildd-ese
[04:32] <lamont> libs/openh323_1.15.3-2ubuntu1: Dep-Wait by buildd+vernadsky [optional:out-of-date] 
[04:32] <lamont>   Dependencies: libpt-dbg (>= 1.8.4-1ubuntu1)
[04:32] <doko> openh323 needed pwlib, which is built now. maybe it needs some main love from elmo?
[04:32] <lamont> so does that mean that you changed pwlib?
[04:32] <lamont> or rather, changed the dependency?
[04:32] <doko> no, lib package
[04:32] <lamont> because libpt-dbg_1.8.4-1 is current in the archive
[04:34] <doko> libpt-1.8.3c2 isn't there ...
[04:34] <lamont> is NEW?
[04:35] <lamont> libs/libtunepimp_0.3.0-2ubuntu6: Dep-Wait by buildd+vernadsky [optional:out-of-date] 
[04:35] <lamont>   Dependencies: libid3tag0-dev (>= 3.8.3-4.1ubuntu1)
[04:35] <lamont> and that one's even cuter
[04:35] <lamont> libid3tag0-dev_0.15.1b-6 is the current version
[04:36] <lamont> so, no.  I haven't rescheduled them.  since it won't do a damn thing
[04:37] <doko> Accepted:
[04:37] <doko> id3lib3.8.3_3.8.3-4.1ubuntu1.diff.gz
[04:37] <doko> elmo: ^^^
[04:38] <doko> Accepted:
[04:38] <doko> pwlib_1.8.4-1ubuntu1.diff.gz
[04:39] <lamont> yeah - is likely an elmo-requiring issue, if you've uploaded them, and they've been accepted, and they're not in the archive...
[04:40] <doko> oh, and same for kdelibs ...
[04:41] <lamont> libs/pwlib_1.8.4-1ubuntu1: Uploaded by buildd+rothera [optional:out-of-date] 
[04:41] <lamont> but that's a patience issue, not an archive issue.
[04:41] <lamont> as for libtunepimp, it's blocked on libid3tag, not id3lib3.8.3
[04:42] <doko> archive issues are patience issues ;-)
[04:43] <daniels> fabbione: would it hurt too much if I uploaded xorg now?
[04:44] <lamont> daniels: that depends on how many more things it'll break
[04:44] <daniels> hopefully nothing, and it will unbreak some crappy scc architectures :P
[04:44] <lamont> the timing of retiring /usr/X11R6/ and the links from /usr was, um, poor.
[04:45] <daniels> but it will dep-wait on stuff in NEW
[04:45] <daniels> lamont: nothing I could do, dude
[04:45] <daniels> lamont: i was arse-deep in a new upload by the time I was told it would be nice if I could transition libGLU an hour ago
[04:45] <lamont> :-)
[04:45] <daniels> the whole three-ring circus knocked me back outside the timeline for XRoadmap
[04:45] <lamont> that transition caused some FTBFS's in a rather inopportune time.  see arts. :-(
[04:45] <doko> daniels: sorry, no, I told you the week before
[04:46] <daniels> doko: sure, that was a 'can you handle libGLU and dbus'
[04:46] <lamont> daniels: yeah.. just grumbling... don't mind me
[04:46] <daniels> speaking of dbus, need to do that still
[04:46] <doko> daniels: done it already
[04:46] <doko> just waiting for kdelibs
[04:46] <daniels> oh cool, thanks
[04:46] <daniels> libdbus-qt-1-1c2?
[04:46] <doko> yes
[04:47] <doko> hmm, I can upload it, even if it won't build
[04:48] <daniels> lamont: uhm, looking at arts, I just see C++ errors?
[04:49] <doko> daniels: the latest arts build by jbailey should be fine
[04:49] <lamont> the first one was the 'libsdl is missing the -I directive' or some such
[04:49] <lamont> after that was jbailey dealing with things
[04:50] <lamont> including kludging around the fact that libsdl was missing the -I, since libsdl1.2 was d-w arts.
[04:51] <doko> libsdl1.2 is fixed as well
[04:54] <lamont> doko: yes.  I was bitching about the past problem.
[04:54] <doko> BitchingBOF 
[04:55] <daniels> i planned to do the xorg transition in larger chunks
[04:55] <daniels> which would have not as much pain
[04:55] <daniels> also while we weren't attempting to rebuild half the archive
[04:55] <lamont> (specifically, that the xorg directory transition caused a circular build-dep loop in arts/sdl, that jbailey had to kludge around as part of fixing arts CXX issues)
[04:56] <lamont> right
[04:56] <daniels> anything in X?
[04:57] <daniels> x should be pretty nicely bootstrappable these days
[04:57] <lamont> no.  all I've seen recently are in the g++ transition
[04:57] <daniels> the mots pain we're hitting right now is possible circular symlinks
[04:58] <lamont> doko: what happens when something is built with mixed (pre- and post- transition) libs?  does the link fail ( hope oh hope), or does it happen to work (that'd be ok too), or does it just successfully build something that is completely useless?
[04:59] <doko> well, hope is near, you'll detect it (hopefully) as something with a dep on libstdc++5 _and_ libstdc++6
[05:00] <doko> it may work ...
[05:02] <lamont> so scc architectures may just have a longer trip through the land of transition
[05:02] <lamont> and they could do builds/uploads to deal with that.  except that we don't like binNMU's....  hrm...
[05:11] <doko> but you can just keep the cxxapps list as no-build ... why not?
[05:17] <lamont> doko: yeah - it just means that the initial bootstrapping also gets to deal with the magical ordering of the g++-4.0 transition as well.
[05:18] <lamont> if it's really a new architecture (hppa has a hoary port, hence the pain), then it's just more ordering constraints for the bootstrap.  that's all
[05:18] <doko> lamont: yes, but that the only way we don't have to touch the cxxapp packages
[05:18] <lamont> right
[06:37] <doko> jbailey: does glibc still builds with -g1? 3.4.4 doesn't have this patch anymore, so I'll drop that one as well, and you should use -g2.
[07:17] <fabbione> daniels: x is fTBFS on sparc
[07:20] <fabbione> -mv
[07:20] <fabbione> 8
[07:20] <fabbione> humpf....
[07:20] <fabbione> daniels: i will send you a patch for that
[07:20] <fabbione> it's quite annoying
[07:30] <fabbione> daniels: in any case go ahead and upload -16
[07:31] <fabbione> we can catch on sparc with -17
[07:52] <doko> elmo, Kamion: we need some universe->main love ... kdelibs4c2
[07:53] <Kamion> ok, give me a moment while I work out what to do
[07:54] <Kamion> er, elmo already did it
[07:54] <Kamion> kdelibs4c2 | 4:3.4.0-0ubuntu6 |        breezy | amd64, i386, ia64, powerpc
[07:56] <doko> oops, yes, must be within the last hour or so. sorry the noise. 
[07:57] <doko> lamont: so we can rebuild dbus?
[07:58] <doko> lamont: same for openh323
[09:21] <doko> lamont: libgnomeuimm2.6 should be retried on amd64 and ia64? had bugs in dbus and openh323
[09:23] <fabbione> doko: are you already compiling apps?
[09:23] <fabbione> or still libs?
[09:25] <doko> still libs, but I we can start soon ...
[09:30] <fabbione> daniels: i have a patch to fix the first FTBFS on sparc. it's building the rest of the tree now...
[09:33] <fabbione> daniels: p.u.c/~fabbione/992_ubuntu_sparc_fix_ftbfs.diff for now
[09:40] <lamont> doko: openh323 will rebuild as soon as libpt-dbg is there
[09:41] <lamont> that's what Dep-Wait in buildLogs/Lists/* is for
[09:41] <doko> lamont: no, I had a wrong version in the build deps
[09:41] <lamont> so what you really want is for me to clear the dependency?
[09:42] <doko> ?
[09:43] <lamont> anybody working on the smpeg ftbfs, or is that fixed already
[09:43] <lamont> ?
[09:50] <doko> libgnomeuimm2.6 ?
[09:51] <doko> lamont: smpeg is fixed, that's what http://people.ubuntu.com/~lamont/buildLogs/s/smpeg/ is for ;-)
[09:51] <lamont> doko: heh
[09:58] <doko> jbailey: Bugzilla Bug 21657: [4.0 regression]  TLS reference miscompiled, ia64 only, so fabbione and lamont don't necessarily need to build it.
[09:58] <lamont> doko: I expect I might in my ia64 buildd hat, no?
[10:00] <doko> yes, I did mean, for the poor hppa and sparc machines
[10:00] <lamont> well, if you upload, we have to build it eventually...
[10:00] <lamont> this is gcc-4.0?
[10:00] <lamont> because the current version in the archive doesn't build on hppa...
[10:18] <doko> lamont: is there a status, which things are not up to date in main?
[10:19] <lamont> doko: in Lists/breezy.all.$ARCH, grep out-of-date | grep -v Installed
[10:47] <doko> lamont: can you blacklist the packages in cxxapps.txt on the hppa and fabbione's sparc buildd?
[10:52] <lamont> doko: already doen
[10:53] <lamont> or rather, fabbione did sparc, I did hppa
[10:53] <lamont> or did you change the list since we started this game?
[10:55] <doko> no, I think I removed dpkg from it, but didn't add anything
[10:56] <lamont> doko: fresh build of libgnomeuimm2.6 on amd64 says:    libgconfmm-2.6-dev: Depends: libgconfmm-2.6-1 (= 2.10.0-0ubuntu1) but it is not going to be installed
[10:56] <lamont> mind you, it may try to build kdebase with the old kdelibs
[10:57] <doko> no, it will fail
[10:57] <doko> new qt and old kdelibs don't like each other
[10:59] <doko> lamont: libgconfmm-2.6-1c2 is in main, why isn't it installed?
[11:00] <lamont> because libgconfmm-2.6-dev Depends: libgconfmm-2.6-1
[11:01] <doko> no
[11:01] <doko> $ apt-cache show libgconfmm-2.6-dev
[11:01] <doko> Package: libgconfmm-2.6-dev
[11:01] <doko> Priority: optional
[11:01] <doko> Section: libdevel
[11:01] <doko> Installed-Size: 1048
[11:01] <doko> Maintainer: Bradley Bell <btb@debian.org>
[11:01] <doko> Architecture: i386
[11:01] <doko> Source: gconfmm2.6
[11:01] <doko> Version: 2.10.0-0ubuntu2
[11:01] <doko> Depends: libgconfmm-2.6-1c2 (= 2.10.0-0ubuntu2), libgconf2-dev (>> 2.6.0), libgtkmm-2.4-dev
[11:01] <lamont> i386 != amd64
[11:02] <lamont> amd64 has libgconfmm-2.6-dev_2.10.0-0ubuntu1
[11:02] <doko> but the build succeeded on amd64 ...
[11:12] <lamont> ubuntu2 only has i386/ppc in the archive, and ubuntu3 is source only
[11:13] <lamont> oh hell.  kids
[11:13] <lamont> back in a while
[11:15] <doko> lamont: come you back again today?
[11:15] <lamont> yes.  I live here.
[11:15] <lamont> :-(
[11:16] <doko> ;)
[11:16] <lamont> back in ~90 min or so
[11:16] <lamont> but poppy is alive again, that'll help
[11:16] <doko> I want to finish C++ tonight ...
[11:26] <fabbione> daniels: i confirm that the patch make X build. I am going to do the full build/install dance now
[11:26] <fabbione> and tell you tomorrow morning as soon as i wake up
[11:43] <doko> Kamion, elmo: just in case you're reading this ... last three libraries, which need promotion to main: libdbus-qt-1-1c2, libopenh323-1.15.2c2, libtunepimp2c2
[11:43] <doko> then we need a rebuild of kdebase (lamont?), and then we're done
[11:46] <doko> lamont: please remove the Dep-Wait for xerces25 and xerces26