[12:06] Riddell: You around for a moment or two? [12:07] jbailey: yes [12:08] Riddell: I've discovered that a newer snapshot of arts doesn't fail. How ugly is it if I just update it? [12:08] jbailey: from svn? [12:09] 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] 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] 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] \sh: yes [12:11] <\sh> Riddell: nice [12:11] jbailey: arts isn't really maintained [12:11] jbailey: from daily snapshots? ftp.kde.org/pub/kde/unstable/snapshots [12:13] jbailey: it would be better to get it from 3.4 brach if that works [12:13] branch [12:13] Right, that's where it was from. [12:13] 'k, I'll look at that too then. [12:17] jbailey: http://dev.kubuntu.org.uk/~jr/kubuntu/arts-svn20050519.tar.bz2 [12:17] that's from kde 3.4 branch [12:17] but if it doesn't work just use a snapshot from head [12:20] Makefile.am.in? [12:20] 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] Trying makefile.cvs [12:25] seems good. [12:25] Thx. =) [12:31] 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] make -f debian/rules buildprep (which runs make -f Makefile.cvs which runs make -f admin/Makefile.common cvs) [01:08] back again [01:13] doko: arts bug appears to be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664 [01:13] doko: Newer snapshot has a workaround for it, but maybe consider it for out 4.0 package? [01:13] s/out/our/ [01:20] doh! 54 comments, maybe we just found the regression mark asks for .. [01:23] jbailey: maybe you could add your comments to the report? [01:25] "spent 3 hours chasing why old software didn't work. That really sucked. Please apply." [01:25] s/didn't work/didn't work on ppc only, but worked fine on ia64, i386 and amd64/ [01:26] I'll do a test run overnight first to make sure this patch actually fixes it. =) [01:28] heh, yes [01:43] Riddell: Erm, does that make -f admin/Makefile.common cvs overwrite acinclude.m4? [01:46] jbailey: yes, it'll replace it with the one from admin/acinclude.m4 [01:48] Riddell: This packaging is going to drive me to drink. === daniels [~daniels@amnesiac.heapspace.net] has joined #ubuntu-toolchain [02:33] lamont: -xc is fine. [02:59] lamont: arts uploaded, ready to watch her spin. === infinity [~adconrad@loki.0c3.net] has joined #ubuntu-toolchain [05:25] jbailey: coolness === doko [~doko___@dsl-082-082-195-045.arcor-ip.net] has joined #ubuntu-toolchain [05:27] doko : How goes the transition, and are there things you want help with? [05:27] (upload monkeying, whatever) [05:31] doko: what's the story with gnome-menus? [05:32] libgnome-menu-dev: Depends: libgnome-menu2 (= 2.11.1.1-0ubuntu1) but it is not installable [05:40] morning guys [05:40] morning fabbione [05:41] hmm coolness [05:41] kicking back gcc made it compile this time [05:41] fabbione: when seb128 is awake again and/or doko, wanna ping them wrt gnome-menus? (see above) [05:42] sure [05:43] are you already compiling C++ apps? [05:43] libs [05:43] ok [05:43] eel2 et al are backed up. could be that we need to deal with bootstrapping something, but ew. [05:43] uh? crap [05:43] libgnome-menu0 2.10. is current in the archive [05:44] gnome-menu is not listed in cxxapps.txt === lamont wipes his brow [05:55] jbailey: you probably don't want to know that arts_1.4.0-0pre1ubuntu6 is ftbfs on ppc, do you? [05:56] actually, that is pretty old news [06:13] night lamont [06:13] g'night [06:20] 'night lamont. === infinity decides that lamont going to bed is his cue to actually wake up and get to work. [06:32] lamont: ubuntu7 is the one I uploaded. =) [06:34] fabbione: I did an lkh upload - Can you give back xorg? [06:34] jbailey: yup! i saw that [06:35] <\sh> hmmm [06:35] i need to wait gcc-4.0 to finish === \sh is compiling c++ apps for cxx trans ;) [06:35] \sh without all the libs, is really BAD to build apps [06:35] 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] 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] 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] 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] 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] \sh : If those bugs are relevant to both Debian and Ubuntu, could you get them filed upstream? [06:49] <\sh> infinity: sure [06:49] 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] infinity: We have that anyway - But Debian is at least on a path to convergeance. [06:50] 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] 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] 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] \sh : No. Won't be until after Sarge releases. [06:53] 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] (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] 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] \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] 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] Which is, obviously, retarded. [06:57] \sh : Any packages with g++ (unversioned) as a build-dep are wrong (it's in build-essential), but won't break. [06:57] \sh : Any package with a versioned g++ build-dep, find out why first. :) [06:58] (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] 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] Have fun birthdaying. [07:12] I'm working all weekend too, to make up for moving/immigration time wasteage. === infinity wonders when the monitor for the amd64 machine will finally get here. [07:18] heh. wot fun. [07:28] daniels: did you plan to upload zorg any time soon? [07:29] let say within the next 12 hours... [07:39] fabbione: that's the plan, I'm just fixing the last bits now [07:40] do you need something done, or just wondering whether or not to kick off a sparc build? [07:41] daniels: well if you upload -16 soon it's ok [07:41] i just don't want to kick -15 and get -16 in the queue 4 hours after :) [07:41] i think the fix to l-k-h should be enough to build X [07:41] but i can't test until gcc-4.0 is finished [07:43] cool [07:43] ok, bbiab [07:44] ok === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain === cartman [foobar@cartman.developer.konversation] has left #ubuntu-toolchain ["Ich] === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain === Seveas [~seveas@ksl403-uva-131.wireless.uva.nl] has joined #ubuntu-toolchain === Seveas [~seveas@ksl403-uva-134.wireless.uva.nl] has joined #ubuntu-toolchain === \sh [~shermann@server3.servereyes.de] has left #ubuntu-toolchain ["Konversation] === \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain [11:38] hi fabbione [12:02] hey doko [12:03] how's sparc going? [12:06] hey doko [12:06] doko: weird enough gcc-4 didn't build at the first shot [12:06] it's installing right now [12:13] hi chmj [12:24] 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] lamont, elmo: libtunepimp on all archs [12:29] Kamion: libxplc0.3.11-dev (universe) is a build dependency of wvstreams (main), could you update the seeds? [12:30] there is no need to update the seeds for that [12:30] germinate follows dependencies and build-dependencies; the *point* of seeds is not to have to list all that stuff. :) [12:30] hmm, the buildd doesn't know about it yet [12:30] yes, elmo needs to move it to main [12:31] universe->main propagation is only semi-automatic [12:33] elmo: please move xplc to main [12:52] is there any point in maintaining the sync blacklists still? [12:55] elmo: which ones? [12:55] cxxapps and cxxlibs [12:56] we can drop the cxxlibs for main, every library package now should have a ubuntuX upload. [12:59] I'll start uploading -buildN packages today (C++ apps in main), then we can drop the cxxapps from main as well. [01:00] but, a sync would have the same affect as -buildN wouldn't it? [01:00] well, I suppose not for non-main, ok, blah, nm [01:02] signfile gcc-4.0_4.0.0-7ubuntu6_sparc.changes C14C0CBD [01:02] yay [01:02] 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] Riddell and amu are preparing the package ... [01:11] they do have the needed patches [01:15] daniels: ping? === jbailey fades into reality. [01:16] hey jb [01:16] going to kick back X in a few minutes [01:16] food first :) [01:17] Yeah, I need breakfast and then to do the glibc upload to fix the dependancy. [01:17] can you also check that ulti-linux FTBFS on sparc? [01:17] it claims an error in one include file shipped by glibc [01:17] Yeah, umount2 redefinition. [01:18] I just love these things that show up on one arch only. =) [01:18] :) [01:23] Hmm, this will be fun. [01:23] I have a workshop that I'm supposed to go to this afternoon and I forgot to rent a car. [01:23] May long weekend - biggest party WE of the year in this city. =( [01:29] elmo: please move libdc1394-13-dev to main, build dependency of pwlib [01:37] fabbione: Oh right, I did look at this before. Sparc and arm specific define, stupid. [01:39] I should try harder to get sysutils to where it replaces util-linux. [01:45] elmo: could you give me a list of main cxxapps, for which newer debian versions exist? [01:58] fabbione: Uploaded. [01:58] eheh i see thanks [01:59] so it was not glibc [02:00] Nope. #if defined (MNT_FORCE) && !defined(__sparc__) && !defined(__arm__) [02:04] ok xorg kicked back [02:04] elmo: thanks for ocfs2-tools NEW love :) [02:09] daniels: please please please do NOT upload xorg -16 now that i started building -15 [02:12] elmo: gconfmm2.6 UNACCEPT [02:12] Rejected: libgconfmm-2.6-1c2_2.10.0-0ubuntu3_amd64.deb is NEW for breezy. [02:13] hey lamont === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [02:22] morning fabbione [02:30] g'm lamont [02:36] hi lamont === Seveas [~seveas@ksl403-uva-134.wireless.uva.nl] has joined #ubuntu-toolchain [02:51] hmm lamont [02:51] perhaps you want to kick back ocfs2-tools [02:51] or update the chroots [02:51] E: Package debhelper has no installation candidate [03:03] lamont: ross sbuild/powerpc still tries to install an outdated libarts-dev, when building libsdl1.2 [03:04] lamont: please build openh323 [03:05] lamont: please build libtunepimp [03:11] fabbione: uhm, ok [03:11] daniels: you were too slow :) [03:11] sorry ;) [03:12] 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] or after it completes the build and i can uplaod the bins [03:15] nah it's ok, I'll do it tomorrow morning [03:15] it's not urgent, just more modularisation and some hppa love [03:16] ok [03:16] so if it still doesn't build you can give sparc love too :) [03:17] fo'sho [03:18] daniels: do you have a chance to investigate the libpng3 miscompilation on powerpc? [03:26] doko: not now I don't [03:26] how urgent is it? [03:27] 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 === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [03:28] 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] the testcase should already be there [03:31] grab davis:~daniels/redglass/X_cursor*, and run xcursorgen X_cursor.cfg X_cursor, on powerpc with the affected libpng [03:34] are the xcursorgen sources there as well? [03:36] nope [03:36] you can pull it out of xbase-clients tho [03:37] 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] ok thanks, will look at it [03:38] np [04:28] lamont: did you reschedule openh323 and libtunepimp? [04:31] doko: once I see what exactly "reschedule" means in buildd-ese [04:32] libs/openh323_1.15.3-2ubuntu1: Dep-Wait by buildd+vernadsky [optional:out-of-date] [04:32] Dependencies: libpt-dbg (>= 1.8.4-1ubuntu1) [04:32] openh323 needed pwlib, which is built now. maybe it needs some main love from elmo? [04:32] so does that mean that you changed pwlib? [04:32] or rather, changed the dependency? [04:32] no, lib package [04:32] because libpt-dbg_1.8.4-1 is current in the archive [04:34] libpt-1.8.3c2 isn't there ... [04:34] is NEW? [04:35] libs/libtunepimp_0.3.0-2ubuntu6: Dep-Wait by buildd+vernadsky [optional:out-of-date] [04:35] Dependencies: libid3tag0-dev (>= 3.8.3-4.1ubuntu1) [04:35] and that one's even cuter [04:35] libid3tag0-dev_0.15.1b-6 is the current version [04:36] so, no. I haven't rescheduled them. since it won't do a damn thing [04:37] Accepted: [04:37] id3lib3.8.3_3.8.3-4.1ubuntu1.diff.gz [04:37] elmo: ^^^ [04:38] Accepted: [04:38] pwlib_1.8.4-1ubuntu1.diff.gz [04:39] 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] oh, and same for kdelibs ... [04:41] libs/pwlib_1.8.4-1ubuntu1: Uploaded by buildd+rothera [optional:out-of-date] [04:41] but that's a patience issue, not an archive issue. [04:41] as for libtunepimp, it's blocked on libid3tag, not id3lib3.8.3 [04:42] archive issues are patience issues ;-) [04:43] fabbione: would it hurt too much if I uploaded xorg now? [04:44] daniels: that depends on how many more things it'll break [04:44] hopefully nothing, and it will unbreak some crappy scc architectures :P [04:44] the timing of retiring /usr/X11R6/ and the links from /usr was, um, poor. [04:45] but it will dep-wait on stuff in NEW [04:45] lamont: nothing I could do, dude === lamont will accept that excuse, for now. [04:45] 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] :-) [04:45] the whole three-ring circus knocked me back outside the timeline for XRoadmap [04:45] that transition caused some FTBFS's in a rather inopportune time. see arts. :-( [04:45] daniels: sorry, no, I told you the week before [04:46] doko: sure, that was a 'can you handle libGLU and dbus' [04:46] daniels: yeah.. just grumbling... don't mind me [04:46] speaking of dbus, need to do that still [04:46] daniels: done it already [04:46] just waiting for kdelibs [04:46] oh cool, thanks [04:46] libdbus-qt-1-1c2? [04:46] yes [04:47] hmm, I can upload it, even if it won't build [04:48] lamont: uhm, looking at arts, I just see C++ errors? [04:49] daniels: the latest arts build by jbailey should be fine [04:49] the first one was the 'libsdl is missing the -I directive' or some such [04:49] after that was jbailey dealing with things [04:50] including kludging around the fact that libsdl was missing the -I, since libsdl1.2 was d-w arts. [04:51] libsdl1.2 is fixed as well [04:54] doko: yes. I was bitching about the past problem. [04:54] BitchingBOF [04:55] i planned to do the xorg transition in larger chunks [04:55] which would have not as much pain [04:55] also while we weren't attempting to rebuild half the archive [04:55] (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] right === lamont continues to have issues with all the magical build-ordering that isn't encapsulated in build-deps. [04:56] anything in X? [04:57] x should be pretty nicely bootstrappable these days [04:57] no. all I've seen recently are in the g++ transition [04:57] the mots pain we're hitting right now is possible circular symlinks === lamont pitys any new architectures that come along after last week. [04:58] 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] well, hope is near, you'll detect it (hopefully) as something with a dep on libstdc++5 _and_ libstdc++6 [05:00] it may work ... [05:02] so scc architectures may just have a longer trip through the land of transition [05:02] and they could do builds/uploads to deal with that. except that we don't like binNMU's.... hrm... [05:11] but you can just keep the cxxapps list as no-build ... why not? [05:17] 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] 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] lamont: yes, but that the only way we don't have to touch the cxxapp packages [05:18] right === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [06:37] 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] daniels: x is fTBFS on sparc [07:20] -mv [07:20] 8 [07:20] humpf.... [07:20] daniels: i will send you a patch for that [07:20] it's quite annoying [07:30] daniels: in any case go ahead and upload -16 [07:31] we can catch on sparc with -17 [07:52] elmo, Kamion: we need some universe->main love ... kdelibs4c2 [07:53] ok, give me a moment while I work out what to do [07:54] er, elmo already did it [07:54] kdelibs4c2 | 4:3.4.0-0ubuntu6 | breezy | amd64, i386, ia64, powerpc [07:56] oops, yes, must be within the last hour or so. sorry the noise. [07:57] lamont: so we can rebuild dbus? [07:58] lamont: same for openh323 [09:21] lamont: libgnomeuimm2.6 should be retried on amd64 and ia64? had bugs in dbus and openh323 [09:23] doko: are you already compiling apps? [09:23] or still libs? [09:25] still libs, but I we can start soon ... === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [09:30] daniels: i have a patch to fix the first FTBFS on sparc. it's building the rest of the tree now... [09:33] daniels: p.u.c/~fabbione/992_ubuntu_sparc_fix_ftbfs.diff for now [09:40] doko: openh323 will rebuild as soon as libpt-dbg is there [09:41] that's what Dep-Wait in buildLogs/Lists/* is for [09:41] lamont: no, I had a wrong version in the build deps [09:41] so what you really want is for me to clear the dependency? [09:42] ? === lamont notices that openh323 didn't go Dep-Wait, gives it back [09:43] anybody working on the smpeg ftbfs, or is that fixed already [09:43] ? [09:50] libgnomeuimm2.6 ? [09:51] lamont: smpeg is fixed, that's what http://people.ubuntu.com/~lamont/buildLogs/s/smpeg/ is for ;-) [09:51] doko: heh === lamont considers him self properly bitchslapped [09:58] 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] doko: I expect I might in my ia64 buildd hat, no? [10:00] yes, I did mean, for the poor hppa and sparc machines [10:00] well, if you upload, we have to build it eventually... [10:00] this is gcc-4.0? [10:00] because the current version in the archive doesn't build on hppa... === lamont is running 4.0.0-7ubuntu6hppa1 :-) === lamont says to hell with it, gives back all the failure logs he has for main. [10:18] lamont: is there a status, which things are not up to date in main? [10:19] doko: in Lists/breezy.all.$ARCH, grep out-of-date | grep -v Installed [10:47] lamont: can you blacklist the packages in cxxapps.txt on the hppa and fabbione's sparc buildd? [10:52] doko: already doen [10:53] or rather, fabbione did sparc, I did hppa [10:53] or did you change the list since we started this game? [10:55] no, I think I removed dpkg from it, but didn't add anything [10:56] 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] mind you, it may try to build kdebase with the old kdelibs [10:57] no, it will fail [10:57] new qt and old kdelibs don't like each other [10:59] lamont: libgconfmm-2.6-1c2 is in main, why isn't it installed? [11:00] because libgconfmm-2.6-dev Depends: libgconfmm-2.6-1 [11:01] no [11:01] $ apt-cache show libgconfmm-2.6-dev [11:01] Package: libgconfmm-2.6-dev [11:01] Priority: optional [11:01] Section: libdevel [11:01] Installed-Size: 1048 [11:01] Maintainer: Bradley Bell [11:01] Architecture: i386 [11:01] Source: gconfmm2.6 [11:01] Version: 2.10.0-0ubuntu2 [11:01] Depends: libgconfmm-2.6-1c2 (= 2.10.0-0ubuntu2), libgconf2-dev (>> 2.6.0), libgtkmm-2.4-dev [11:01] i386 != amd64 [11:02] amd64 has libgconfmm-2.6-dev_2.10.0-0ubuntu1 [11:02] but the build succeeded on amd64 ... [11:12] ubuntu2 only has i386/ppc in the archive, and ubuntu3 is source only [11:13] oh hell. kids [11:13] back in a while === lamont is already 15 min late, and 30 min away from where he should be... [11:15] lamont: come you back again today? [11:15] yes. I live here. [11:15] :-( [11:16] ;) [11:16] back in ~90 min or so [11:16] but poppy is alive again, that'll help [11:16] I want to finish C++ tonight ... === \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain [11:26] daniels: i confirm that the patch make X build. I am going to do the full build/install dance now [11:26] and tell you tomorrow morning as soon as i wake up === rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain [11:43] 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] then we need a rebuild of kdebase (lamont?), and then we're done [11:46] lamont: please remove the Dep-Wait for xerces25 and xerces26