[12:09] <fabbione> hmm i can't find the archive
[12:09] <fabbione> ops
[12:10] <doko> back again
[12:11] <fabbione> hey doko
[12:12] <lamont> ftbfs on ppc
[12:12] <fabbione> fuck
[12:12] <doko> where are we? xorg?
[12:13] <fabbione> doko: yes. xorg
[12:13] <lamont> LD_LIBRARY_PATH=../../../exports/lib XLOCALEDIR=../../../exports/lib/locale  ../../../exports/bin/xcursorgen
[12:13] <lamont> +X_cursor.cfg X_cursor
[12:13] <lamont> libpng error: Call to NULL read function
[12:13] <lamont> PNG error while reading X_cursor-16.png!
[12:13] <lamont> xorg
[12:13] <fabbione> ENOCLUE
[12:13] <lamont> ^5
[12:14] <lamont> I don't think a give-back will help
[12:14] <lamont> otoh, why are we building the cursor here?  isn't that arch-indep?
[12:14] <doko> lamont: all the buildd's do have the new built-essential?
[12:14] <lamont> doko: yes
[12:15] <fabbione> it's a library or something for the server
[12:15] <lamont> just waiting on xorg to finish up in the next 20-30 min, then we can play with libraries
[12:15] <doko> ok, then I'll go through the libs in main and upload libs, which don't depend on glu-something
[12:15] <fabbione> doko: please wait
[12:15] <fabbione> let's get Xorg to build first
[12:15] <lamont> doko: given that we build pretty much all of main in < 6 hours or so, it's not like there's a big hurry.../
[12:16] <fabbione> and we can upload all the libs in one go
[12:16] <fabbione> doko: the Xorg deps and build-deps aren't stable yet
[12:16] <fabbione> so something might need to change
[12:17] <doko> ok, will wait
[12:17] <fabbione> + after X there is still one x package that needs upload
[12:17] <fabbione> once that one is in, you are clear to go
[12:22] <lamont> fabbione: so about the ppc xorg ftbfs....
[12:22] <lamont> thoughts?
[12:23] <fabbione> lamont: no.. not really
[12:24] <fabbione> i am checking the buildlog now
[12:25] <lamont> i386 and amd64 == uploaded
[12:25] <lamont> ia64 is about 5/14's done
[12:26] <fabbione> it looks like an error in libpng to me
[12:28] <lamont> which leads to the question of what to do to fix it...
[12:28] <fabbione> lamont: try to kick back
[12:28] <lamont> given back
[12:28] <fabbione> it's not an X problem imho
[12:28] <fabbione> the error comes from libpng attempting to read that file
[12:28] <fabbione> and the file is valid
[12:28] <lamont> is the abuse in x-common such that we could stall on uploading 1.0?
[12:29] <fabbione> lamont: do you feel more confortable to wait to upload x-common 1.0?
[12:29] <fabbione> it's just question of removing a Pre-Depends
[12:29] <lamont> well, if we did that, then ia64 could catch up...
[12:29] <fabbione> sure it can wait
[12:29] <fabbione> i don't see a big problem with that
[12:29] <fabbione> sparc will catch up too
[12:30] <fabbione> but again.. once xorg-common -11 is in, the pre-depends can disappear :)
[12:30] <lamont> right.  and that's the next cron.daily run
[12:30] <fabbione> sure.. i didn't plan to upload x-common until at least the 3 major arches have all the binaries in place
[12:31] <lamont> doko: you planning to upload a fixed gcc-4.0 (is ftbfs) soon?
[12:31] <fabbione> even if i would pay gold to go to sleep now :)
[12:32] <doko> lamont: no
[12:32] <doko> have to find out, why it fails
[12:33] <fabbione> daniels: you awake yet?
[12:35] <lamont> ah, right
[12:35] <fabbione> lamont: ?
[12:35] <lamont> doko: while you're in there, could you disable the testsuite on hppa?
[12:35] <fabbione> ahah
[12:35] <lamont> fabbione: was aimed at doko and gcc-4.0
[12:35] <fabbione> ehhe yeah
[12:53] <fabbione> fuck
[12:54] <fabbione> server died again for no reasons
[12:54] <fabbione> i had the time to hear all the disks spinning down nicely
[12:54] <fabbione> and puff... it was frozen
[12:57] <lamont> overtemp?
[12:58] <lamont> fabbione: on the bright side, with ccache, it only takes 10 minutes for powerpc to reproduce the failure
[12:58] <fabbione> lamont: nope.. it would send the alarm
[12:59] <fabbione> hmmm
[12:59] <fabbione> what version of libpng gets installed in the different chroots?
[12:59] <fabbione> is it the same?
[12:59] <lamont> was the same buildd, same chroot
[12:59] <lamont> libpng12-0
[01:00] <fabbione> i mean across the arches :)
[01:00] <lamont> should be the same... /me checks
[01:01] <lamont> libpng12-0_1.2.8rel-1 on all 4
[01:01] <lamont> OTOH, ppc is the only big-endian arch in the pile
[01:01] <fabbione> yeah
[01:01] <jbailey> Bah, /me fixes the typo and starts again.
[01:01] <lamont> short gym trip, eh>?
[01:01] <fabbione> so is sparc... but it will take time to get there
[01:02] <lamont> yeah.  gcc-4.0 build running now
[01:02] <jbailey> lamont: I felt guilt, so I started the build on amd64 and ia64 as well, by the time I got them running, ppc had failed.
[01:02] <fabbione> i wonder if libpng is broken on ppc
[01:02] <jbailey> fabbione: It is.
[01:02] <jbailey> fabbione: sb had me test that yesterday
[01:02] <lamont> is fix known?
[01:02] <lamont> because it's blocking the transition
[01:02] <jbailey> Ugh, really?
[01:02] <lamont> xorg is ftbfs/ppc
[01:03] <lamont> fabbione: you saw that xorg/amd64 was rejected, yes?
[01:03] <fabbione> don't tell me that there is known fix and it had not been uploaded...
[01:03] <fabbione> lamont: meh.. no why?
[01:03] <jbailey> Gimme a sec to fire these things up.
 Rejected: xprt_6.8.2-11_amd64.deb: old version (1:0.1.0.alpha1-10) in breezy >= new version (6.8.2-11) targeted at breezy.
 so that's 2/3
[01:04] <jbailey> fabbione: Nope, I was just asked to test it.  I was hacking on other stuff so didn't explore it any further.
[01:05] <lamont> doko: ew... patch fuzz in gcc-4.0... :-)
[01:05] <fabbione> hmmm
[01:05] <fabbione> that should have happened on i386 too
[01:05] <fabbione> xprt is an arch: any
[01:05] <fabbione> and why on heart daniels still ship that shit
[01:05] <fabbione> ok let's make a summary
[01:06] <fabbione> libpng is fucked on ppc
[01:06] <fabbione> that is a blocker for xorg
[01:06] <fabbione> xorg needs xprt love
[01:06] <fabbione> and another upload
[01:06] <lamont> sounds about right.
[01:06] <fabbione> otherwise we cannot go for libs
[01:06] <fabbione> or ppc will lag eons behind
[01:07] <lamont> and dropping ppc from breezy is _not_ an option...
[01:07] <doko> should we reupload libpng compiled with 3.3 on powerpc?
[01:07] <lamont> doko: is that known to fix it?
[01:07] <fabbione> doko: are we sure that is the right thing to do?
[01:08] <doko> no
[01:08] <fabbione> than no
[01:08] <lamont> fabbione: you have ppc at your place?
[01:08] <fabbione> somebody needs to investigate the real issue
[01:08] <fabbione> lamont: no
[01:08] <fabbione> i have been begging for one for a long time
[01:08] <fabbione> i keep getting i386trash
[01:08] <fabbione> lamont: davis?
[01:09] <lamont> davis is an option..
[01:09] <lamont> elmo about?
[01:09] <fabbione> elmo can upgrade a chroot and that's it
[01:09] <lamont> exactly
[01:09] <fabbione> jbailey, lamont: there is nothing more i can do for today
[01:09] <fabbione> i am crashing
[01:09] <elmo> lamont: ?
[01:09] <lamont> g'night fabbione
[01:10] <fabbione> daniels should be awake soon
[01:10] <doko> good night
[01:10] <lamont> can you freshen the breezy chroot on davis?
[01:10] <lamont> elmo^^
[01:10] <fabbione> elmo: with the new xorg build-dep ;)
[01:10] <lamont> then I'm going to try building libpng with gcc-3.3, and have you install that in the chroot.
[01:10] <lamont> and then we'll see if that fixes the xorg build problem
[01:10] <fabbione> if there is something, i will have my mobile phone with me
[01:10] <lamont> and then I'll cry
[01:11] <fabbione> lamont: no.. just wake up the kid :)
[01:11] <lamont> heh
[01:11] <fabbione> i am off
[01:11] <fabbione> good night guys
[01:11] <jbailey> lamont: I have to go in 10 minutes, is there anything you need me to do nowish?
[01:11] <jbailey> g'n Fabio!
[01:11] <lamont> jbailey: not unless you can upload a fix for libpng. :-(
[01:12] <lamont> jbailey: any hints on what it was?  or you just verified it was NFG?
[01:12] <jbailey> Just verified it was nfg.
[01:12] <lamont> that is, braindump would be cool.
[01:12] <lamont> and done. sigh.
[01:12] <lamont> way quick braindump
[01:12] <elmo> lamont: doing
[01:22] <lamont> elmo: and libpng3 build-deps, of course.
[01:23] <elmo> nothing to install?
[01:23] <elmo> and done
[01:23] <lamont> probbaly nothing to install
[01:29] <elmo> ARGH
[01:29] <elmo> Rejected: xprt_6.8.2-11_ia64.deb: old version (1:0.1.0.alpha1-10) in breezy >= new version (6.8.2-11) targeted at breezy.
[01:30] <lamont> yeah - we discussed that a bit a while back.
[01:30] <lamont> it's on the list of things to deal with.
[01:31] <lamont> but libpng is a bigger blocker...
[01:31] <lamont> unless you wanna make the old xprt just go away... :-)  But that would be, well, wrong.
[01:32] <lamont> elmo: in davis:breezy-chroot: dpkg -i ~lamont/breezy/libpng12*.deb please
[01:32] <elmo> eh, what are they?
[01:33] <lamont> they're the same source, built with gcc-3.3
[01:33] <elmo> installed
[01:36] <lamont> dpkg-checkbuilddeps: Unmet build dependencies: xtrans-dev
[01:36] <elmo> installed
[01:37] <lamont> so if the libpng3 build fixes things, we'll know in about 50 minutes... if it doesn't, then I'll actually have a tree to start debugging on.
[01:40] <lamont> meanwhile, sort break time
[01:48] <doko> lamont: what do you sort?
[01:48] <lamont> short
[01:49] <doko> :-)
[01:52] <doko> lamont: ok, I found the 4.0 bootstrap failure. mind, if I upload a fixed one?
[01:52] <elmo> doko: why would lamont mind?  unlike Debian, he has 3 buildds per arch on a GB LAN :P
[01:53] <elmo> not that I'm bitter every time vore grinds to a halt after one of your upload sprees or anything
[01:55] <doko> elmo: yes, that' why I uploaded the last one built for sparc ...
[01:56] <elmo> doko: dude, you REALLY shouldn't do that
[01:56] <lamont> please don't upload binaries unless you're a buildd
[01:57] <lamont> oh. debian.  well, still shouldn't
[01:57] <lamont> doko: upload away
[01:57] <doko> heh, it doesn't even go to sarge. lamont: will do
[01:57] <lamont> doko: this has my hppa fix too?
[01:57] <elmo> heh, in Ubuntu, you CAN'T upload binaries unless you're a buildd
[01:57] <elmo> (or have access to their secret key)
[01:57] <elmo> I wish I could enforce that level of facism in Debian :(
[01:58] <doko> lamont: fix? crappy workaround of disabling the testsuite a fix? ;-)
[01:58] <lamont> doko: yeah. that "fix". :-)
[01:59] <lamont> doko: I'm willing to bet that it's the long-standing bug in signals, but really can't say for sure
[01:59] <daniels> i'm here now
[01:59] <daniels> elmo: xprt isn't something we care about for the time being
[01:59] <daniels> if the rest of the upload goes through, that's a win
[01:59] <elmo> the rest of the upload so doesn't go through
[02:00] <elmo> if it did, I'd shoot myself
[02:00] <lamont> daniels: it's kinda this atomic thing, you see...
[02:00] <daniels> elmo: the xtrans stuff isn't a bug, mmkay
[02:01] <daniels> elmo: this is why I've said several times that I despise xtrans and want it to die
[02:01] <lamont> daniels: one option is to just not deliver the xprt binary package...
[02:01] <lamont> although I expect that breaks some other packages down the line
[02:02] <daniels> elmo: ok
[02:02] <doko> hi daniels, short night ... ;)
[02:02] <daniels> i'll prepare a new xorg
[02:02] <daniels> heh
[02:02] <lamont> doko: he was gone almost 8 hours...
[02:03] <lamont> daniels: we also need to figure out what's up with libpng/ppc
[02:03] <doko> lamont: you're right, that's too much
[02:03] <lamont> and note that fabbione had to do some stuff to xorg to make it build with gcc-4.0....
[02:03] <lamont> if you have a shared source archive, greate... if not, you need to fetch from the archive...
[02:03] <daniels> yeah, I slept in by an hour
[02:03] <lamont> doko: and I need ccache bindings for ada, so that the gcc-4.0 build can go fast.
[02:04] <lamont> ditto for gcj
[02:05] <doko> lamont: hmm, these are not yet upstream?
[02:05] <elmo> night all
[02:06] <elmo> lamont: a lot of the gcc slowness is hte test suite ..
[02:06] <lamont> elmo: not when it's disabled. :-)
[02:06] <lamont> g'night elmo
[02:06] <doko> night
[02:06] <doko> ccache doesn't help in the testsuite
[02:07] <lamont> right\
[02:07] <lamont> while waiting for the xorg build to fail agian
[02:08] <lamont> elmo: if you're still around, I'm wondering why xorg seems to have made it in on i386 - was there no xprt agony there?
[02:10] <daniels> was xprt ftbfs on i386?
[02:10] <daniels> nigt elmo
[02:12] <lamont> daniels: dunno
[02:12] <lamont> what source package?
[02:12] <daniels> xprt
[02:13] <lamont> xprt doesn't show up in wanna-build for i386
[02:13] <lamont> or any arch, for that matter
[02:13] <lamont> hoary or breezy
[02:14] <daniels> um
[02:14] <daniels> so this might sound a little bit nasty
[02:14] <daniels> but is there any chance you could hack the changes file to exclude xprt and shepherd the rest of the upload through?
[02:14] <lamont> no
[02:16] <daniels> agh
[02:16] <lamont> (not just because all the .debs and the .changes file get deleted...()
[02:17] <lamont> the ubuntu archive remains unviolated by hand-edited changes files, and shall remain so on my watch.
[02:17] <infinity> s/is/it/
[02:19] <lamont> infinity: you don't have the key to violate it
[02:20] <doko> infinity: looks like your buildd career did finish before it did begin ;-P
[02:23] <infinity> ;)
[02:23] <doko> lamont: http://people.ubuntu.com/~lamont/buildLogs/j/java-gcj-compat/1.0.28-0.0ubuntu1/ ???
[02:26] <lamont> doko: any chance something Provides: libgcj-dev?
[02:27] <daniels> lamont: what, you're telling me you're the paragon of cleanliness and archive sanctity now? :P
[02:27] <lamont> daniels: I always play by the specified rules.
[02:27] <lamont> that's what makes it so much fun. :-)
[02:28] <doko> ehh, yes ... libgcjX-dev ... looks like I should remove it
[02:31] <lamont> daniels: my forte lies in analyzing complex systems and determining how to accomplish a specified task within the structure imposed by that system.
[02:32] <lamont> some call it hackish and kludgy, others also call it necessary.
[02:32] <lamont> s/it/it only/
[02:33] <lamont> ubuntu is nice because we have a very minimal set of complexity in the system.  mostly, it's just implemented correctly to begin with.  hence we can keep it more pure and clean...
[02:33] <lamont> that, and one of the rules is 'it shall remain unviolated' :-)
[02:33] <infinity> lamont : If that's your forte, you should have been a tax accountant, not a programmer. :)
[02:34] <daniels> heh
[02:34] <lamont> infinity: note that said forte also applies very well in computer security, forensic analysis, and so forth
[02:34] <lamont> our family calls it "rules lawyering"
[02:35] <infinity> Oh, I realise it has many uses, it just happens that good tax accountants make a lot more than those other professions. :)
[02:35] <lamont> although, I must admit, life is more interesting when you have to explain both the letter of the law and the intent of the law to your kids, so as to avoid hearing "but dad, you said ..."
[02:35] <infinity> (I consulted to one who worked exclusively with clients who had salaries of over a million a year... His income was significantly higher)
[02:35] <lamont> heh
[02:36] <lamont> infinity: fwiw, I apply it pretty much to all aspects of my existance
[02:36] <doko> lamont: please build 4.0-5, not -4 on your slooow hppa box
[02:36] <lamont> debian?
[02:37] <doko> breeeezzzzyyy
[02:37] <lamont> so 0ubuntu5.  check
[02:37] <lamont> actually, I think  I'm going to let 0ubuntu2hppa1 finish building first. :-)
[02:37] <doko> yes, skip 0ubuntu4
[02:38] <lamont> ew.
[02:38] <doko> hmm, I'm going to sleep, doing more harm then good
[02:38] <lamont> doko: given hoary/hppa's pseudo-existance
[02:38] <lamont> I really can't build any of the cxxlibs before you upload them, yes?
[02:38] <lamont> given breezy/hppa with g++4.0
[02:39] <doko> build them using g++-3.4, hack around gcc-defaults
[02:40] <lamont> actually, it just means adding build-essential and gcc-defaults to the no_auto_build list
[02:40] <lamont> since they haven't built yet.
[02:41] <lamont> dpkg-genchanges: binary-only upload - not including any source code
[02:41] <lamont> dpkg-buildpackage: binary only upload (no source included)
[02:41] <doko> lamont: I don't understand what you gain
[02:41] <lamont> doko: fix gcc-{3.4,4.0} so that it builds libpng3 correctly
[02:42] <lamont> doko: gain with not building build-essential, gcc-def?  it means that I don't have to hack around gcc-defaults...
[02:42] <lamont> then once you upload the libs, then it's no issue again
[02:43] <doko> yes, but you end up with the wrong C++ ABI
[02:44] <doko> so you verified, that libpng3 is miscompiled with gcc-3.4 _and_ 4.0 on powerpc?
[02:44] <lamont> libpng doesn't Depend: C++
[02:45] <lamont> seems to be wrong on gcc-4.0.  didn't check 3.4
[02:45] <doko> I didn't write this
[02:45] <doko> ahh, ok
[02:45] <doko> daniels: could you destill a testcase from the xorg build?
[02:45] <daniels> um, possibly
[02:46] <lamont>  Depends: libc6 (>= 2.3.4-1), zlib1g (>= 1:1.2.1)
[02:46] <lamont>  Depends: libpng12-0 (= 1.2.8rel-1ubuntu1), zlib1g-dev
[02:47] <doko> lamont: if you do have time, could you recheck with a libpng3 compiled with -O2 and/or -O1?
[02:49] <lamont> sure
[02:51] <lamont> doko: except that I was testing it by using the package installed in the chroot...  and I can't update that...
[02:51] <lamont> actually, it's built without -O
[02:51] <lamont> see debian/patches/makefile.patch
[02:51] <doko> ?
[02:52] <lamont> nm
[02:52] <lamont> gcc -Wall -D_REENTRANT  -g -O3    -c -o pngset.o pngset.c
[02:52] <lamont> ah.  that part comes from debian/rules
[02:53] <daniels> -O3??
[02:53] <lamont> daniels: yeah. crack
[02:53] <doko> DEB_BUILD_OPTIONS overwrites this ...
[02:53] <lamont> doko: yes
[02:54] <doko> looking at the archives I see issues with -funroll-loops, which is enabled by default in 4.0 at -O3. So I assume -O2 will help here ...
[02:54] <lamont> hrm... I suppose LD_LIBRARY_PATH could help force things to the rebuilt package.
[02:54] <daniels> (breezy-chroot)daniels@davis:~/redglass $ xcursorgen X_cursor.cfg X_cursor
[02:54] <daniels> (breezy-chroot)daniels@davis:~/redglass $ dpkg -l libpng\*
[02:54] <daniels> [...]
[02:54] <daniels> ii  libpng12-0                1.2.8rel-1ubuntu1         PNG library - runtime
[02:54] <lamont> that's the new version.
[02:55] <lamont> which is built with gcc-3.3
[02:55] <daniels> note the lack of segfault
[02:55] <lamont> you have ppc there?
[02:55] <daniels> note the 'daniels@davis' ;)
[02:55] <lamont> ah, that's in the same chroot where I just verified my fix.
[02:55] <daniels> oh, so you installed it?
[02:55] <lamont> note that -1ubuntu1 source will be in the archive in about 8 minutes
[02:55] <lamont> no, elmo did.  before he left.
[02:56] <doko> ok, going to bed now, 3am ...
[02:56] <doko> good night
[02:56] <lamont> g'night doko
[02:56] <lamont> daniels: once we have xorg/xprt love, then we can upload doko's libraries
[02:56] <lamont> doko: before you leave...
[02:56] <doko> yes?
[02:56] <lamont> where do all the libs live, so we can upload them once X is happy?
[02:57] <doko> chinstrap:~doko/cxxsrc, but without kdelibs please
[02:57] <lamont> no kdelibs.  check
[02:57] <daniels> lamont: yep, I'm testing the xprt-less build
[02:57] <lamont> daniels: once you get an xorg that is xprt-happy, let me know.  (then we can see about finishing debugging the libpng thing...)
[02:58] <daniels> doko: in any case, xcursorgen, and davis:~daniels/redglass/X_cursor*, is your testcase
[02:58] <daniels> lamont: will do
[06:54] (fabbione/#ubuntu-toolchain) at what time did i go offline?
[06:55] (jbailey/#ubuntu-toolchain) daniels: if gcc-3.3 fixed it, then it's probably altivec fuckage.  I can try to take a look at that tomorrow.
[06:57] <jbailey> And in the meantime, Fabio showing up for his morning work is my hint that it's bed time.
[06:57] <jbailey> g'n all!
[06:57] <fabbione> hey jb
[06:57] <fabbione> jbailey: klibc is FTBFS on sparc :)
[06:57] <fabbione> goot night
[06:57] <daniels> night jbailey
[06:57] <lamont> daniels: want to try a -14 that has fabbione's fixes from -11?????>????"??
[06:57] <daniels> fabbione: 3h17m before you joined
[06:57] <jbailey> fabbione: Forward me a build log?  It's working everywhere else. =(
[06:58] <daniels> lamont: the what now?
[06:58] <lamont> all the bugs that fabbione fixed so that it actually builds with gcc-4.0 were reintroduced in your upload.
[06:58] <lamont> please fix them.
[06:58] <daniels> oh, biteage
[06:58] <daniels>    * Add patch 991_ubuntu_gcc_flags.diff as a temporary workaround to a borked
[06:58] <daniels>      gcc-3.4 check.
[06:58] <fabbione> oh fuck.. daniels you didn't merge from the archive?
[06:58] <lamont> also, please test your upload in a gcc-4.0 chroot, k?
[06:59] <daniels> fabbione: no, I didn't know you made any changes to xorg
[06:59] <daniels> lamont: this is with gcc4
[06:59] <jbailey> fabbione: I want to work magic of some sort that combines all the build daemon activity, including ports into an rss feed that I can just look at and show even things that would be on ports.ubuntu.com.
[06:59] <daniels> fabbione: is it just #991?
[06:59] <fabbione> daniels: and build-deps
[06:59] <daniels> ok
[06:59] <lamont> daniels: go back about 6 hours in your scrollback...
        daniels: we also need to figure out what's up with libpng/ppc
[07:00] <lamont> May 17 18:03:12 <doko>  lamont: you're right, that's too much
[07:00] <lamont> May 17 18:03:14 <lamont>        and note that fabbione had to do some stuff to xorg to make it build with gcc-4.0....
[07:00] <lamont> May 17 18:03:39 <lamont>        if you have a shared source archive, greate... if not, you need to fetch from the archive...
[07:00] <lamont> although maybe that was pre-coffee
[07:00] <lamont> anyway, past my bedtime
[07:00] <fabbione> good night lamont
[07:01] <daniels> night lamont
[07:01] <lamont> fabbione: -13 is ftbfs, libpng should be fixed, just need a gcc-4.0 friendly -14, and xorg should actually make it into the archive.
[07:01] <fabbione> lamont: ok thanks
[07:01] <fabbione> i won't be around that long
[07:01] <fabbione> not after 19 hours of yesterday
[07:02] <daniels> fabbione: sure
[07:02] <lamont> heh
[07:02] <lamont> at any rate, if things need buildd love, I expect you'll see elmo before me.,
[07:04] <daniels> indeed, i'll get it sorted out somehow
[07:08] <daniels> i need to do a mirror sync to get the new packages, so I'll go afk for about an hour while my internet connection is useless
[07:11] <fabbione> daniels: my archive is synced
[07:11] <fabbione> do you want me to merge for -14?
[07:11] <fabbione> it will take me the same amount of time as for you to wait
[07:15] <daniels> it's ok, i'll do more testing in chroots and stuff
[07:26] <fabbione> hmmm something is already pulling in x-common
[07:26] <fabbione> oh right
[07:26] <fabbione> xrender
[07:30] <daniels> yep
[07:30] <daniels> the /usr stuff should pull it in
[07:30] <fabbione> yeah it does
[07:30] <daniels> else it'll be stuck in /usr/X11R6
[07:30] <fabbione> but it's ok
[07:30] <fabbione> the buildd likes it
[07:31] <daniels> do xft and xcursor have the pre-depends?
[07:31] <fabbione> no, but they depends on xrender
[07:31] <fabbione> that pre-depends on x-common
[07:31] <fabbione> so that's enough to pull in * in the proper wat
[07:31] <fabbione> way
[07:31] <daniels> mmmmmmm
[07:32] <daniels> i'd still rather it was explicit, but just as long as it works
[07:57] <doko> morning all
[07:58] <fabbione> hi doko
[08:00] <fabbione> doko: FYI we are waiting for xorg
[08:00] <fabbione> -14 will hit the archive sometime in the next 3 hours
[08:00] <fabbione> after that we should have greenlight
[08:02] <doko> heh, cool
[08:04] <fabbione> i am tired to death
[08:04] <fabbione> why my wife needs to wake up at 6am
[08:40] <\sh> it's a problem with all wifes ;)
[08:41] <doko> did jbailey notice about the glibc build failure?
[08:48] <\sh> doko: did u upload kdelibs4c2?
[08:48] <fabbione> \sh: no libs have been uploaded yet
[08:49] <fabbione> doko: doh! it's building here
[08:49] <\sh> hmmm....
[08:50] <\sh> ok..in dokos repos ;)
[08:52] <doko> ? building?
[08:53] <doko> lamont: hmm, the glibc patch, which fails to apply in the datacenter, applies cleanly here
[08:54] <fabbione> it works here to
[08:54] <fabbione> i think it's a LANG= thing
[09:01] <doko> does work with LANG= as well.
[09:01] <fabbione> no i mean.. how it has been setup on the buildd
[09:01] <fabbione> but it's weird
[09:01] <fabbione> probably a kick back would do
[09:01] <fabbione> so at the end
[09:02] <fabbione> the only arch that doesn't need new libc, is the only one building it
[09:02] <doko> :(
[09:05] <fabbione> oh well
[09:05] <fabbione> it will refresh the ccache :)
[09:35] <fabbione> daniels: how is -14 coming?
[09:35] <daniels> good; my mirror pulse just hit universe not too long ago, so I'm in the middle of refreshing the chroot
[09:36] <fabbione> doko: can i build gcc-4 7ubuntu5 or are you planning an upload in 3 minutes?
[09:37] <doko> sorry, I won't make it in 3 minutes ;)
[09:38] <doko> no, built ok.
[09:38] <fabbione> doko: well do you plan any upoad withing the next 24 hours?
[09:38] <fabbione> upload even
[09:39] <doko> hmm, do we save some time, if we reupload glibc?
[09:39] <fabbione> doko: no
[09:39] <fabbione> let see why it fails on the buildd first
[09:39] <fabbione> otherwise it is pointless
[09:42] <\sh> so..if the old name is libsomelibc102  the new name will be libsomelib right?
[09:43] <daniels> correct
[09:43] <\sh> thx :)
[10:21] <daniels> yeah, it's in the install target now :P
[10:21] <fabbione> daniels: goody
[10:21] <fabbione> daniels: btw.. 991 was just a workaround to get it to build
[10:21] <fabbione> the real issue is the macro that changes HasGCC34
[10:21] <fabbione> that doesn't know gcc-4
[10:22] <daniels> yeah, I'll look into that for -15
[10:23] <fabbione> yeah
[10:23] <\sh> hmmm
[10:24] <elmo> morning
[10:24] <\sh> any explanation why the resulting package for libqssl2 (recompiled with g++4) is named like _hurd-i386?
[10:24] <fabbione> hey elmo
[10:24] <fabbione> elmo: can you please kick back glibc on all arches?
[10:25] <fabbione> elmo: for some reasons it FTBFS at the DC, but it is building fine both on doko machine and my buildd
[10:30] <elmo> given back on i386
[10:30] <elmo> it looks like a fairly generic failure
[10:30] <fabbione> yeah it is
[10:30] <elmo> are you sure it's not something like patch ordering due to locale?
[10:31] <fabbione> elmo: i have the same overrides here as lamont does
[10:31] <fabbione> LANG=C
[10:31] <fabbione> but that was the same impression i got
[10:31] <fabbione> # Environment variables to set/override:
[10:31] <fabbione> %ENV_OVERRIDES = {
[10:31] <fabbione>         'LC_ALL' => 'C',
[10:31] <fabbione> };
[10:32] <fabbione> and my buildd is choaking on it right now
[10:35] <doko> let's fix dpkg-architecture first :(
[10:35] <elmo> dpkg-buildpackage: host architecture hurd-i386
[10:35] <elmo> ?!?!?!?!
[10:35] <fabbione> does dpkg-architecture come from dpkg?
[10:35] <elmo> what the FUCK?
[10:35] <doko> $ dpkg-architecture -qDEB_HOST_GNU_TYPE
[10:35] <doko> i386-gnu
[10:35] <fabbione> if so we are doomed
[10:35] <\sh> elmo: ah ;)
[10:35] <fabbione> dpkg is C++ application
[10:36] <fabbione> and banned from being built
[10:36] <\sh> so i'm not the only one who pushed the button for the Infinite Improbability Drive
[10:36] <elmo> DEAR SCOTT, PLEASE STOP BREAKING THE WORLD.  K THANKS BUH BYE
[10:36] <fabbione> you know what??!?!?!??!
[10:36] <\sh> at least we know for sure: Hurd is not dead ;)
[10:37] <fabbione> I AM SO FUCKING HAPPY THAT SPARC IS SO SLOW THAT DIDN'T GET TO BUILD THE BROKEN DPKG!!!
[10:37] <doko> fabbione: dpkg was just uploaded before we stopped ...
[10:38] <fabbione> doko: but it didn't get builded on sparc :)
[10:38] <fabbione> it was in the queue
[10:38] <fabbione> so i am still running a good dpkg
[10:38] <fabbione> MUHA MUHA MUHA
[10:38] <fabbione> now
[10:38] <fabbione> let's think how to unfuck this mess
[10:38] <\sh> fabbione: but r lame ;) U r not able to fly withus in the "Heart of Gold"
[10:39] <daniels> fabbione: step 1: call scott.  step 2: shout.
[10:39] <fabbione> daniels ++
[10:39] <fabbione> but the main issue is that dpkg is a C++ application
[10:40] <fabbione> i wonder if we still have some pre-transition-breezy chroots
[10:40] <fabbione> if so we could manually build a working dpkg
[10:40] <fabbione> install it in the chroots
[10:40] <elmo> eh, it's a C++ apps that only links against libstdc++ ?
[10:40] <fabbione> complete the transition
[10:40] <elmo> what's wrong with just compiling it?
[10:41] <fabbione> elmo: doko banned it.. no idea why
[10:41] <fabbione> doko: ?
[10:41] <doko> no reason, should un-ban it
[10:42] <doko> elmo: removed it from cxxapps.txt
[10:47] <fabbione> elmo: that needs to be manually removed on all 12 buildd
[10:47] <elmo> undone here too
[10:47] <elmo> oh, BLAH, seriously?
[10:47] <fabbione> elmo: yes from buildd.conf
[10:48] <fabbione> @no_auto_build = qw(....);
[10:48] <elmo> actually, no it doesn't, only one per arch
[10:48] <elmo> anyway, when you guys have a fix, lemme know
[10:49] <doko> hmm, gcc already picked up the wrong architecture, and dpkg-architecture relies on gcc -dumpmachine
[10:50] <fabbione> dpkg-buildpackage: host architecture hurd-i386
[10:50] <fabbione> ahhaha
[10:50] <fabbione> amazing
[10:50] <fabbione> we need to stop the buildd
[10:50] <fabbione> and see how many pkgs have been affected
[10:51] <elmo> I don't think many well?
[10:51] <elmo> s/well/will/
[10:51] <elmo> but yeah, I'll stop katie now
[10:52] <fabbione> in the worst case around 60 pkgs
[10:53] <fabbione> that's according to -changes
[10:53] <chmj> oh my, this is a a worm, speading as buildd goes on
[10:57] <fabbione> doko: are you sure that the gcc build was affected?
[10:58] <doko> yes, it was configured for the target 'i386-linux-gnu', which is not the hurd, but i386, not i486 ...
[10:59] <fabbione> xorg -11 was affected
[10:59] <fabbione> let's go back
[11:00] <fabbione> well should we consider affected all packages that have been built with the new dpkg?
[11:00] <fabbione> i think that would be a sage threshold
[11:01] <elmo> we can grep the logs for the 'host architecture' line
[11:02] <fabbione> i fount it
[11:02] <fabbione> at least on i386 the last safe package is build-essential
[11:02] <daniels> elmo: please kick xorg through as soon as dpkg is !fucked, it was uploaded about 10-15 minutes ago
[11:02] <fabbione> already java-gcj-compat has the wrong host architecture
[11:02] <daniels> i'll be down at dinner; my phone will get me
[11:02] <fabbione> daniels: we will need to rebuild and reupload all the packages before that :/
[11:03] <daniels> ok, well I need to eat :P
[11:03] <daniels> but phoneable if you need.  will be back in ~30.
[11:04] <fabbione> elmo: do you want to grep as well to be 100% sure?
[11:04] <fabbione> and is it only i386 affected?
[11:12] <elmo> hum?
[11:12] <elmo> dpkg-buildpackage: source package is xorg
[11:12] <elmo> dpkg-buildpackage: source version is 6.8.2-11
[11:12] <elmo> dpkg-buildpackage: host architecture i386
[11:13] <elmo> were you just grepping for 'hurd'?
[11:13] <fabbione> elmo: no i was checking the version of dpkg used to build
[11:13] <elmo> $ find . -newer d/dpkg/1.13.4/dpkg_1.13.4_20050517-1340-powerpc-successful.bz2 -type f | xargs bzgrep "host architecture hurd-" -l
[11:13] <fabbione> i didn't grep.. i just manually checked
[11:13] <elmo> ./g/glibc/2.3.5-1ubuntu1/glibc_2.3.5-1ubuntu1_20050518-0934-i386-failed.bz2
[11:13] <elmo> ./j/java-gcj-compat/1.0.28-0.0ubuntu1/java-gcj-compat_1.0.28-0.0ubuntu1_20050518-0545-i386-successful.bz2
[11:13] <elmo> is all I get
[11:17] <fabbione> elmo: i think we need to consider the option that debian/rules might use the output of dpkg-arch to set build parameter
[11:17] <fabbione> and you won't catch it from host archi
[11:17] <Kamion> elmo: dpkg 1.13.4ubuntu1 uploaded, please let it through
[11:17] <fabbione> packages might have been miscompiled
[11:17] <elmo> Kamion: does dpkg use dpkg-architecutre? :>
[11:17] <elmo> fabbione: eh?
[11:17] <elmo> fabbione: that host architecture hurd-<blah> is output from dpkg-buildpackage
[11:18] <elmo> fabbione: if the chroot had the right version of dpkg-dev and gcc, it'd _always_ trigger?
[11:18] <Kamion> haha
[11:18] <Kamion> elmo: yes
[11:18] <Kamion> elmo: this build will probably think it's cross-compiling
[11:18] <fabbione> elmo: hmm point
[11:18] <Kamion> since DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE in the Brave New Linux/Hurd World
[11:19] <elmo> ok, so I have to downgrade chroots? :(
[11:19] <Kamion> probably a good plan
[11:19] <elmo> or, hum, build dpkg-dev on concordia and nstall it there
[11:19] <elmo> s/there/from there/
[11:21] <fabbione> amen
[11:22] <fabbione> God just called that needs to know asap if we can include Oracle FS in our kernel
[11:22] <Kamion> hmm, how does all this interact with daniels' complicated scheme with x-common for the X transition?
[11:22] <fabbione> i am around if needed, but kinda busy
[11:22] <fabbione> Kamion: that x doesn't build anymore?
[11:23] <Kamion> at all, ever
[11:26] <elmo> ok, building dpkg on vernadsky only (hopefully)
[11:29] <daniels> Kamion: um, should be OK
[11:29] <daniels> if not, I want someone to go to Birmingham and extract BLOOD
[11:31] <doko> people tend to believe that all bugs during a toolchain transition can be blamed to the toolchain ;)
[11:36] <doko> ok, prepared a 4.0 upload which only trusts dpkg-architecture for the cpu, elmo, let me know, when it's safe for an upload
[11:37] <Kamion> doko: is that the right fix, long-term?
[11:37] <Kamion> I mean where do you get the system type from?
[11:37] <elmo> oh, christ
[11:38] <elmo> buildd doesn't delete stuff from no_auto_build on a config reread
[11:38] <doko> no, but as long as dpkg-architecture picks up the '-gnu' from gcc -dumpmachine, we need an intermediate solution
[11:38] <\sh> hmmm
[11:38] <elmo> doko: eh?
[11:38] <Kamion> doko: the point of the builds elmo's doing is to fix that
[11:38] <Kamion> I'd expect a no-change gcc-4.0 upload to be enough?
[11:39] <doko> yes, but that doesn't help the current gcc in breezy.
[11:39] <Kamion> if people are going to upgrade gcc-4.0, they could just as easily upgrade dpkg
[11:39] <Kamion> er, dpkg-dev
[11:39] <doko> no, the dpkg-architecture patch makes it a bit more correct, but still prints i386-linux-gnu instead of i386-linux
[11:40] <Kamion> daniels: my point being, is the x-common etc. in the archive usable for building xorg against, despite the hurdishness?
[11:40] <doko>   # overwrite ix86 CPU defaults
[11:40] <doko>   ifeq ($(TARGET_ALIAS),i386-linux)
[11:40] <doko>     TARGET_ALIAS := i486-linux
[11:40] <doko>   endif
[11:40] <Kamion> doko: oh, I thought that was desirable ... ok
[11:40] <doko> so, we build for i386, not i486
[11:41] <infinity> Kamion : The -gnu has never been there before, adding it would break any package that matches on that string.
[11:41] <Kamion> k
[11:42] <fabbione> Kamion: yes x-common in the archive is ok
[11:42] <doko> but some time ago, rms requested it to have the -gnu suffix ...
[11:43] <elmo> eh, I doubt it has anything to do with RMS
[11:43] <elmo> and much more to do with making dpkg-architecture match what the auto* tools do
[11:45] <elmo> the only binonly (or no-source-change) upload we'll need is java-gcj-compat I think
[11:45] <doko> the mail I got was definitely from RMS, but anyway
[11:45] <fabbione> and glibc
[11:46] <doko> elmo: I'll reupload java-gcj-compat
[11:46] <elmo> fabbione: no?
[11:46] <elmo> it didn't suceed anywhere
[11:46] <fabbione> elmo: ah right...
[11:46] <elmo> doko: what's your mail got to do with Scott's motives for changing dpkg?
[11:46] <fabbione> elmo: it's like. i didn't sleep shit in the last 36 hours :)
[11:47] <elmo> doko: please upload your gcc
[11:47] <elmo> I think we need that built and installed first
[11:49] <doko> ok, I'll disable the testsuite, no code change
[11:50] <elmo> eh, why disable the testsuite?
[11:50] <doko> because I want to have something done today? that's two hours saved
[11:51] <Kamion> elmo: you're talking at cross-purposes - there's the matter of what dpkg-architecture says, and there's the matter of what gcc -dumpmachine says; doko's talking about the latter I think
[11:52] <doko> yes, I did mean gcc -dumpmachine
[11:52] <elmo> doko: please don't disable the testsuites
[11:52] <elmo> it's two hours of machine time not human time
[11:53] <doko> hmm ...
[11:53] <fabbione> i am off for a while
[11:53] <fabbione> if there is something important i have my mobile phone with me
[11:57] <doko> elmo: 4.0 uploaded
[11:57] <elmo> ok, all 12 buildds using fixed dpkg-dev
[11:57] <elmo> pushing gcc-4 through
[11:58] <elmo> once that's built + installed, I'll re-enable katie
[12:00] <doko> elmo: could you make sure, that configure runs for target <cpu>-linux, i486-linux on i386?
[12:00] <doko> s/sure/check/
[12:00] <doko> s/make//
[12:11] <elmo> checking host system type... i486-pc-linux-gnu
[12:11] <elmo> checking target system type... i486-pc-linux-gnu
[12:11] <elmo> checking build system type... i486-pc-linux-gnu
[12:16] <doko> thanks
[12:27] <daniels> Kamion: x-common, x11proto-core-dev, xtrans-dev, and x-dev are arch: all
[12:27] <Kamion> ah, ok
[12:27] <daniels> i'm going to be afk for a while, got visitors
[12:27] <daniels> but i'm phoneable
[12:54] <elmo> gcc's just reached testing on i386
[01:11] <\sh> ah...infos concerning my juniper training
[01:13] <jbailey> So, erm.  Is the theory that a broken dpkg is somehow keeping glibc from applying its patches?
[01:14] <elmo> don't know yet, but we'll find out in a bit
[01:16] <jbailey> Oh good. =)  lamont /msg'd me about the failure just as I was turning off the monitors.  I got as far as "this built in 5 separate chroots, 2 of which were on Concordia.  wtf?" and then went to sleep. =)
[01:17] <elmo> actually, no, that theory doesn't work
[01:17] <elmo> oh, yes, it does, blah, ignore me
[01:40] <fabbione> guys is there anything you need from me before i will go away?
[01:40] <fabbione> (until tomorrow morning)
[01:41] <elmo> doko: only x86 has been affected by this dpkg-dev thing, right?
[01:42] <doko> no, Kamion did paste something about powerpc-linux-gnu here as well
[01:42] <doko> Kamion: ^^^ ?
[01:42] <elmo> yes, but no gcc was built with the broken gcc
[01:43] <elmo> blah broken dpkg-dev
[01:43] <lamont> moo
[01:44] <doko> hi lamont, we did have some dpkg fun in the meantime
[01:45] <elmo> doko: he's in here too
[01:45] <elmo> and what's it matter?
[01:45] <elmo> we're not overriding anything for powerpc are we?
[01:46] <lamont> elmo: just forcing -pipe, if that's what you mean
[01:46] <Kamion> yes, it was powerpc-linux-gnu
[01:46] <elmo> lamont: no, I mean 386 vs 486 overriding
[01:46] <lamont> ah, ok
[01:47] <Kamion> and gcc-4.0 was definitely built on powerpc with the broken dpkg-dev
[01:47] <elmo> eh?
[01:48] <elmo> dpkg-buildpackage: host architecture powerpc
[01:48] <elmo> ^-- from the build log?
[01:48] <doko> dpkg-architecture prings powerpc-linux-gnu, not powerpc-linux
[01:48] <Kamion> it wasn't built on powerpc with the broken dpkg-dev+gcc-4.0 combination
[01:48] <elmo> meh, ok
[01:48] <lamont> doko: make[2] : *** No rule to make target `current_symbols.txt', needed by `check-abi'.  Stop.
[01:48] <lamont> or did you fix that between -ubuntu2 and -ubuntu5?
[01:48] <elmo> bottom line: do we care about gcc-4.0 on !i386?
[01:48] <elmo> AFAICS, there's no breakage, and so no?
[01:49] <doko> lamont: ohh no ...
[01:52] <doko> elmo: if a package uses this string to detect the architecture, then it is built different than before.
[01:53] <elmo> doko: ?
[01:54] <doko> ifeq ($(shell dpkg-architecture -q ...),powerpc-linux)
[01:54] <doko> I don't know, if/how many packages do that
[01:56] <doko> lamont: on which architecture do you see the error?
[01:56] <lamont> hppa
[01:56] <lamont> could it be from turning the tests off?
[01:57] <elmo> doko: but that only applies if broken dpkg-dev+gcc-4 was installed right?
[01:57] <doko> elmo: yes
[01:58] <elmo> right, well, we know only one package was built like that
[01:58] <elmo> gcj-java-compat
[01:58] <elmo> so.  again, is there any other reason to not re-enable the buildds?
[01:58] <doko> lamont: hmm, please put the log file somewhere
[01:59] <doko> elmo: no, we can restart then
[01:59] <elmo> lamont: have you just updated the chroots?
[01:59] <lamont> 0215 DCT
[02:00] <doko> gcc-4.0_4.0.0-7ubuntu6 is the current
[02:00] <elmo> ok, i386 updated, katie cron jobs re-enabled
[02:01] <elmo> lamont: caveat emptor: removing stuff from no_auto_build isn't sufficent, you need to kill and restart the buildd
[02:01] <lamont> elmo: right.  note also that buildd-config is on hold, since it'll overwrite buildd.conf
[02:02] <lamont> elmo: libs all got uploaded while I slept?
[02:02] <elmo> lamont: no, I mean as, in, the buildd auto-config-rereading stuff DOESN'T WORK for removals
[02:02] <lamont> doko: people.ubuntu.com/~lamont/gcc-4.0_4.0.0-7ubuntu2hppa1_20050517-1658.bz2
[02:02] <lamont> ah, ok.
[02:06] <doko> lamont: ok, I assume, you already did remove the build?
[02:06] <lamont> doko: actually, it's mid-run on ubuntu5
[02:07] <lamont> but it's almost done...
[02:07] <lamont> otoh, I did say: touch chroot-breezy/build/buildd/gcc-4.0-4.0.0/src/libstdc++-v3/config/abi/hppa-linux-gnu/current_symbols.txt
[02:08] <lamont> and no, that won't get uploaded to the archive elmo
[02:08] <lamont> besides, it's out-of-date now
[02:10] <doko> lamont: yes, should work
[02:11] <doko> lamont: gcc-4.0-nocheck.diff on chinstrap
[02:36] <\sh> can we update? ,-)
[02:37] <jbailey> \sh: I think we're still in phear-the-apt mode. =)
[02:39] <\sh> jbailey: and I'm thinking of writing a blog entry like: "Ubuntu made it. Transition from Debian-Linux to Debian-Hurd on the way, read more here" ,-)
[02:42] <jbailey> \sh: I didn't feel quite brave enough at UDU to propose a Hubuntu bof.  Had one day of the conference fallen on *April* 1st, however... =)
[02:43] <\sh> jbailey: hehe :)
[02:43] <doko> \sh: heh, attach the patches for ABI changes in bugzilla first ... ;-)
[02:44] <\sh> doko: well...qssl is compiling just fine with your version of libqt ;)
[02:44] <\sh> i only was unsure if _hurd-i386 is quite right for a linux system ;)
[02:46] <\sh> and in between the transition you should watch this movie: http://www.douglasadams.com/movie/
[02:47] <Kamion> \sh: we all went to see that at the end of UDU
[02:48] <\sh> Kamion: ah :)
[02:49] <\sh> Kamion: it's not showing here in the cinemas right now...i just watched a screener ;)
[02:53] <doko> lamont: did you look at the libpng3 miscompilation?
[02:54] <doko> I think, a recompile with 4.0 and -O2 would be worth a try
[02:54] <lamont> doko: I built it, was going to pester elmo to cycle through a few debs in davis' chroot to see if I could reproduce the failure with any of the bits
[03:00] <lamont> doko: fwiw, touching the file didn't fix things.
[03:28] <doko> elmo, lamont: what's the state of archive now?
[03:28] <elmo> waiting for you guys to do stuff?
[03:29] <doko> so xorg is built/building?
[03:29] <doko> glibc is requeued?
[03:29] <lamont> doko: last I heard, we were waiting for xorg, followed by libraries.
[03:29] <elmo> I've given back glibc again
[03:29] <elmo> for i386 first
[03:31] <elmo> and same death
[03:31] <lamont> xorg finished on amd64 (and is NEW, elmo)
[03:31] <lamont> still building on the other 3
[03:32] <doko> elmo: could you update the breezy32 chroot on concordia and install the glibc build-deps?
[03:32] <elmo> it is not NEW
[03:32] <lamont> no jbailey yet this morning?
[03:33] <lamont> well, is byhand then...
[03:33] <lamont> gah.
[03:33] <lamont> that's -13, not -14.
[03:33] <lamont> nm
[03:33] <elmo> doing concordia breezy chroots
[03:34] <lamont> -14 is packaging xorg debs
[03:37] <doko> lamont, elmo: fix the buildd?, glibc patches fine on concordia
[03:37] <elmo> doko: please don't be such a troll
[03:38] <doko> elmo: I'll try ...
[03:38] <elmo> Unpacking libstdc++6-dev (from .../libstdc++6-dev_3.4.3-13ubuntu4_amd64.deb) ...
[03:38] <elmo> dpkg: error processing /var/cache/apt/archives/libstdc++6-dev_3.4.3-13ubuntu4_amd64.deb (--unpack):
[03:38] <elmo>  trying to overwrite `/usr/share/doc/gcc-3.4-base/C++/README.libstdc++-baseline', which is also in package libstdc++6-0-dev
[03:38] <elmo> doko: seriously, how is that a helpful comment?
[03:39] <elmo> the buildd chroots aren't obviously broken since they've compiled all of breezy so far
[03:39] <elmo> "it works for me - you suck" is stunningly unhelpful
[03:39] <doko> elmo: that's amd64? yes, I fixed it.
[03:39] <jbailey> lamont: I'm here.
[03:39] <doko> elmo: no, I didn't say that, not did I mean it that way
[03:39] <lamont> elmo: to be fair, there have been 1 or 2 issues with gcc -v not behaving the same as gcc -pipe -v... sucky command line parsing, and all that...
[03:40] <lamont> clues on the glibc failure jbailey ?
[03:40] <lamont> etc
[03:40] <jbailey> lamont: I can't reproduce on any of my boxes here, with LANG=C or anything.
[03:40] <elmo> and besides concordia isn't remotely representative of current breezy
[03:40] <elmo> so your test is rather fatally flawed
[03:41] <jbailey> lamont: It's noto even getting as far as config.log from what you pasted last night.  It's just failing during the patching.
[03:42] <jbailey> lamont: I don't know what could cause that.  Maybe a skew in the version of patch?
[03:42] <jbailey> But my boxes here are pretty current breezy.
[03:43] <lamont> yeah
[03:44] <daniels> sorry, amnesiac went down for a while
[03:44] <daniels> how are we looking?
[03:44] <elmo> lamont: please wait till I upgrade concordia
[03:44] <daniels> successful on amd64 \o/
[03:44] <elmo> or rather till dselect finishes
[03:44] <jbailey> lamont: If you can step inside the chroot, from a clean dpkg-source -x glibc*dsc, you should be able to run "debian/rules patch"
[03:44] <daniels> dselect?  isn't that in universe?
[03:47] <lamont> --- linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h  15 Oct 2003 04:40:10 -0000      1.1
[03:47] <lamont> buildd@terranova:/build/buildd/glibc-2.3.5/build-tree/glibc-2.3.5$ find . -name malloc-machine.h
[03:47] <lamont> ./nptl/sysdeps/pthread/malloc-machine.h
[03:47] <lamont> ./sysdeps/generic/malloc-machine.h
[03:47] <lamont> ./sysdeps/mach/hurd/malloc-machine.h
[03:47] <lamont> interesting... but that's not clean either
[03:48] <lamont> jbailey: what's the target to unpack the beast, but not patch?
[03:48] <elmo> BZZT
[03:48] <elmo> it failes on concordia/breezy now too
[03:48] <elmo> as I said, lamont, please stop fucking around with the buildd chroots, there's nothing wrong with them
[03:48] <jbailey> Lovely, lemme dive in.
[03:49] <lamont> elmo: turning off purge=always and looking at the remains is benign.
[03:50] <jbailey> lamont: debian/rules unpack, in case you ever need it again, btw.
[03:50] <jbailey> dpkg-architecture: warning: Unknown gcc system type amd64-linux, falling back to default (native compilation)
[03:50] <jbailey> -l looks like it's giving me the right answers, though.
[03:51] <elmo> jbailey:'linux32 dchroot -c breezy-i386'
[03:51] <elmo> patches to make dchroot auto do that, welcome
[03:51] <jbailey> elmo: I'm in the amd64 one.  Is i386 a better choice right now?
[03:51] <elmo> jbailey: oh, no, I just thought i saw you in i386 in ps
[03:51] <elmo> sorry, don't mind me if you're not
[03:51] <elmo> they're both uptodate, I reproduced the failure in i386
[03:52] <doko> me too
[03:52] <Kamion> daniels: dselect> not since I added it to the standard seed yesterday to stop it disappearing, it isn't
[03:53] <elmo> Kamion: don't feed the troll; it wasn't going out of main as long as I had root on jackass in any event :-p
[03:54] <Kamion> hah
[03:55] <jbailey> err..  linuxthreads tarball isn't unpacking?
[03:56] <jbailey> nor is libidn.
[03:59] <jbailey> Output from dpkg-architecture -qDEB_HOST_GNU_SYSTEM changed.
[03:59] <jbailey> =(
[03:59] <jbailey> Is this permanent breakage?
[04:00] <Kamion> believe so, it's now *-linux-gnu not *-linux
[04:00] <lamont> is dpkg 1.13 feature
[04:00] <Kamion> it's the main thing Keybuk flagged about 1.13
[04:00] <jbailey> Ah, I must've missed the post on it.
[04:01] <jbailey> So do I build-dep on the newer dpkg?
[04:03] <elmo> either that or have the make magic handle either
[04:04] <jbailey> Erm.  I wonder if I lose my accounts on the gnu systems if I s/linux-gnu/linux/... =)
[04:04] <lamont> hehe
[04:05] <lamont> you could s/linux$/linux-gnu/ instead...
[04:05] <lamont> the gentoo users backporting your glibc to warty will appreciate it if the make magic handles both... :)
[04:05] <lamont> s/users/refugees/
[04:08] <Kamion> hmm, no dpkg build for powerpc or amd64 yet?
[04:08] <elmo> it's in the exclude list
[04:08] <elmo> dpkg-dev is arch: all, so does it matter?
[04:09] <Kamion> true, hadn't thought of that
[04:15] <doko> xorg did finish on i386 and powerpc
[04:15] <doko> do we have to wait for it on sparc and hppa?
[04:15] <lamont> I'm just glad this wasn't an hppa bug causing the glibc failure... :-)
[04:16] <lamont> doko: no
[04:17] <daniels> until the binaries are in the archive, no rest for the wicked
[04:17] <lamont> about 30 minutes more on the xorg build for ia64, etc.
[04:18] <daniels> oh, -14 binaries on the archive
[04:18] <daniels> wicked sick
[04:18] <daniels> s/on/in/
[04:18] <lamont> daniels: I'm not wicked.  and I'm going to take a break in a very short while
[04:18] <daniels> well, sort of.
[04:18] <daniels> lamont: um, dude
[04:18] <daniels> http://archive.ubuntu.com/ubuntu/pool/main/x/xorg/
[04:19] <daniels> libdmx-dev is there, but not xserer-xorg
[04:19] <doko> maybe we have a chance to compile the libraries, before somebody uploads libtool or a new kernel ;)
[04:19] <daniels> nothing past libxxf86dga-dev is there
[04:19] <lamont> daniels: did you look in universe?
[04:19] <elmo> daniels: err?
[04:20] <elmo> if you mean -14, that's cos it's still syncing
[04:20] <elmo> archive.u.c is still running on one machine which is hurting it badly
[04:20] <daniels> xserver-xorg is not in universe
[04:20] <daniels> elmo: thank fucking christ
[04:20] <daniels> thanks
[04:21] <lamont> daniels: good catholics would tell you He didn't do that...
[04:21] <cartman> ha :)
[04:22] <daniels> lamont: i'd smile and tell them we'd have to agree to disagree
[04:22] <lamont> daniels: ditto
[04:22] <daniels> and that's about all I'm going to say on the topic, because I still recall the last time I talked about Christian religious groups
[04:23] <cartman> yeah transition is more important than religion
[04:26] <jbailey> tested with old dpkg and new.  Any other last requests?
[04:26] <daniels> ouch, ouch, goddamn ouch
[04:26] <daniels> my fonts are fucked
[04:27] <cartman> daniels: all X apps? ( because here Tcl apps got fscked after last tcl update )
[04:30] <jbailey> pushed./
[04:30] <daniels> cartman: nope, seems to be either just firefox, or freetype
[04:30] <daniels> freetype doing strange things wouldn't surprise me in the least
[04:30] <cartman> hmm I use freetype from cvs :/
[04:31] <lamont> daniels: see the logs of #u-devel from early april, where milli was bitching about sid's fonts and what he had to do to fix them
[04:31] <elmo> ok, what's holding up this #&%"* transition actually starting now?
[04:32] <lamont> elmo: jbailey, I think...
[04:32] <elmo> new glibc needs built?
[04:32] <lamont> needs to be uploaded, at least.
[04:32] <jbailey> I've uploaded it - it should only hold you up if you're counting on hppa participating, though.
[04:33] <lamont> jbailey: hppa's still working on having a breezy gcc-4.0 :-(
[04:33] <lamont> it is _so_ not participating yet.
[04:33] <lamont> although it hopes to have a gcc-4.0 in about 2.5 hours
[04:33] <elmo> ok.  anything else?
[04:33] <elmo> doko?
[04:34] <lamont> I think ia64 needs to stop building stuff and wait for xorg to hit the archive
[04:35] <lamont> ia64 is packaging
[04:35] <doko> glibc? not necessarily
[04:38] <lamont> right??  order (at this point) is: (1) make sure xorg -14 is in the archive, (2) build all the libs that doko uploads, (3) make sure they hit the archive, (4) unleash cxxapps.txt stuff
[04:38] <lamont> right?
[04:39] <doko> yes
[04:39] <lamont> ok.
[04:39] <doko> hope we finish tomorrow ...
[04:39] <lamont> elmo, my life would be easier if we had one more cron.daily run in before doko's mass upload (in about 5 minutes time)
[04:40] <lamont> ia64 is in dpkg-deb
[04:40] <elmo> shout when
[04:41] <lamont> fabbione: you're out and about, not here, correct?
[04:41] <doko> daniels: libglu1-xorg-dev does not appear to be available
[04:41] <daniels> doko: libglu-xorg-dev
[04:42] <doko> xlibmesa-dev depends on libglu1-xorg-dev
[04:42] <daniels> oh, fuck it all to hell
[04:42] <lamont> doko: I don't think that needing -15 to happen really needs to hold up the cxxlibs upload
[04:42] <daniels> doko: does this *need* to be fixed?
[04:42] <lamont> that is, we have a good set of xlibs, and some build dep issues to fix.
[04:43] <lamont> daniels: yes, it needs to be fixed.  But I don't think it needs to be fixed before doko's mass upload of libs
[04:43] <doko> yes, I hope, the packages on it will just break to build
[04:43] <lamont> it'll block sfuff
[04:43] <lamont> doko: sure.
[04:43] <daniels> go upload and I'll sort another xorg upload; I have more things to keep on doing, anyway
[04:44] <lamont> doko: please wait before uploading
[04:44] <lamont> (at xserver-common)
[04:44] <doko> anyway, the KDE people need it
[04:45] <lamont> daniels: soon would be good, but not before I tell doko he can upload libs
[04:45] <lamont> (the non-data-center architectures all have but single buildd's - which makes handholding them past xorg a bit less painful.)
[04:46] <lamont> dpkg --info spewage.. almost there
[04:48] <lamont> May 18 15:47:53 buildd-uploader: Setting to Uploaded(breezy): xorg
[04:48] <lamont> elmo: cron.daily after the next cron.hourly, if you please
[05:02] <daniels> is 'about ten hours from now' an acceptable answer for xorg -15?
[05:02] <daniels> it's now 0102, and I'm tired as hell
[05:03] <daniels> you've got two minutes; speak now or forever hold your peace
[05:03] <lamont> daniels: that depends entirely on how much stuff it blocks
[05:03] <lamont> but worst case, I'll upload -14.1
[05:04] <lamont> or maybe I'll call it -15. :0-)
[05:04] <lamont> since it's literally just the Depends: change, yes?
[05:04] <daniels> there's a couple of Depends changes to do
[05:04] <daniels> just look for 'libglu'; it should be either libglu1-xorg, libglu1-dbg-xorg, or libglu-dev-xorg
[05:05] <daniels> (if in doubt, check the Packages: line)
[05:05] <lamont> (1) try to install all of the packages, and (2) fix the broken build-deps.  right?
[05:05] <daniels> the B-Ds are fine
[05:05] <lamont> s/build-//
[05:05] <daniels> tell you what.  i've got a couple of other things I'd like to do that I can do in about an hour if need be.  so if it's too much of a spanner in the works, call me and I'll be up.
[05:06] <doko> hmm, can't you just make an upload with the fixed build-dep?
[05:06] <lamont> s/build-//
[05:06] <daniels> doko: um, I'd really rather not just for one line
[05:06] <lamont> daniels: I'd really rather you did...
[05:06] <lamont> this isn't debian.  we have cycles
[05:06] <daniels> give me an hour or two
[05:06] <lamont> daniels: meaning that you're already hip deep in some other changes?
[05:07] <daniels> i'll send the mirror admins to you when they come lynching
[05:07] <lamont> I'd rather have _JUST_ this fix.
[05:07] <daniels> lamont: however did you guess?
[05:07] <daniels> lamont: which would make it about six uploads in two days ...
[05:07] <lamont> mind if I toss -14.1 into the fray?
[05:07] <lamont> daniels: so we'll start calling you cam
[05:07] <lamont> camm
[05:07] <daniels> camm
[05:07] <daniels> ?
[05:07] <lamont> nm
[05:07] <Kamion> camm maguire, maintainer of a bunch of maths packages in Debian
[05:07] <doko> an what about the libglu stuff?
[05:07] <lamont> he has big packages that he uploads 6 times in a day to debian...
[05:07] <daniels> erk
[05:08] <lamont> but he only does it about once every 6 months or so...
[05:08] <daniels> well, I'll finish up the stuff I was working on now
[05:08] <daniels> run it through another cycle, and have the fixed xlibmesa-dev deps up asap
[05:08] <lamont> daniels: could I pretty please have an upload with _JUST_THE_DEPENDS_FIX???
[05:08] <daniels> bear in mind that only stuff which B-Ds on xlibmesa-dev is affected
[05:08] <lamont> right
[05:08] <daniels> how many packages B-D on xlibmesa-dev?
[05:08] <doko> that's about 25% of all uploads
[05:09] <doko> KDE
[05:09] <lamont> doko: in any case, you are go for library uploads as far as I'm concerned
[05:09] <lamont> (with apologies to sparc)(
[05:10] <doko> hmm, even qt b-deps on it
[05:10] <doko> ok, then I'll go :-)
[05:12] <doko> lamont: ok to go, jbailey, ready for FTBFS fixing? ;-)
[05:12] <jbailey> More or less.
[05:12] <doko> elmo: ok to go?
[05:12] <doko> poor fabbione, but the sparc buildd is stopped ...
[05:12] <jbailey> doko: From where do we get the list of ftbfs' and how do we avoid race conditions?
[05:13] <doko> lamont's pages
[05:13] <elmo> doko: sure?
[05:14] <doko> elmo: what do you mean?
[05:14] <daniels> a very dull -15 coming right up
[05:14] <doko> elmo: what do you mean? that the sparc buildd is stopped?
[05:15] <elmo> 16:12 < doko> elmo: ok to go?
[05:15] <elmo> in response to that
[05:17] <doko> uploading the library packages
[05:18] <daniels> -15 uploaded, *grumble*
[05:18] <lamont> doko: is gcc -7ubuntu6 needed for the library builds?
[05:18] <lamont> jbailey: ditto for glibc
[05:18] <lamont> ?
[05:19] <jbailey> lamont: Nope.  It only exists to keep you happy with hppa.
[05:19] <lamont> jbailey: sshhhh  don't say that...
[05:19] <lamont> daniels: thank you
[05:20] <daniels> i live to give
[05:20] <lamont> daniels: now go to sleep and upload -16 in 10+hours. :-)
[05:20] <jbailey> lamont: Err, I mean.  The Debian merge doesn't affect the C++ transition in any way.
[05:20] <lamont> jbailey: LOL
[05:20] <doko> lamont: I know of two C libs failing, which is fixed in -7ubuntu6, don't know of any C++ libs
[05:21] <lamont> doko: but it's an FTBFS in any case, not a 'built but bogus' issue.   coolness. (ia64 is still building -7ubuntu6, you see..)
[05:21] <doko> lamont: how long?
[05:22] <lamont> doko: another hour or two.
[05:22] <lamont> I don't mind the ftbfs, if it's really that...
[05:22] <lamont> don't worry about ia64... I'll do that enough for all of us
[05:23] <doko> heh, but -7ubuntu5 is there ...
[05:23] <lamont> yeah
[05:23] <doko> no code changes
[05:23] <lamont> hence no worries
[05:23] <lamont> oh, even better
[05:23] <elmo> is someone going to upload a fix gcj-java-compat, btw?
[05:23] <doko> just configured for ia64-linux-gnu, not oa64-linux
[05:23] <doko> elmo: will do, but it's arch all
[05:23] <lamont> elmo: doko's going to fix the package it depends on, iirc.
[05:24] <lamont> but first he's uploading boatloads of libraries, I expect
[05:24] <lamont> elmo: versioned depends on a package that is also Provided: elsewhere
[05:24] <lamont> but you probably knew that
[05:25] <doko> lamont: that should be fixed in gcc-4.0, not yet in gcc-3.x
[05:28] <daniels> night.  phone next to bed and all that.
[05:29] <doko> daniels: good night
[05:31] <lamont> doko: libs all uploaded?
[05:33] <doko> no, taking with the hppa build admin ;)
[05:37] <lamont> I wanted to do that _after_ you uploaded libs...
[05:37] <lamont> sigh
[05:38] <lamont> doko: please ignore me and do the library uploads now
[05:40] <doko> :)
[05:41] <doko> lftp jackass:~> mput [a-z] *
[05:41] <doko> 13168521 bytes transferred in 2 seconds (6.96M/s)
[05:41] <doko> Total 170 files transferred
[05:41] <doko> lftp jackass:/>
[05:41] <lamont> yeah, kinda neat.  isn't it?
[05:41] <Kamion> *thunk*
[05:41] <lamont> hrm.. that's still less than 100mbps.
[05:42] <lamont> of course, for larger uploads, you want to put the .changes files last...
[05:42] <lamont> hrm.. sorts that way too
[05:42] <Kamion> lamont: surely poppy shouldn't care
[05:43] <elmo> lamont: no, doesn't matter with poppy
[05:43] <lamont> elmo: awesom
[05:43] <lamont> er
[05:43] <lamont> awesome, evne.
[05:43] <lamont> gah.
[05:46] <lamont> elmo: some cron.daily love for us impatient types?
[05:51] <doko> the ocaml reject is ok
[05:52] <lamont> jbailey: do you wat to know that cdbs_0.4.28-1ubuntu2 is ftbfs
[05:53] <lamont> because of bad Depends: in ocaml*
[05:53] <lamont> (there is no gcc-3.4)
[05:55] <doko> in main?
[05:55] <lamont> doko: build-dep
[05:55] <lamont> gcc-3.4 is not build-essential, and ocaml does not Depend: on it.
[05:55] <lamont> but yet it executes gcc-3.4 explicitly
[05:56] <doko> Build-Depends: gcc-3.4, debhelper (>> 4.0.2)
[05:57] <jbailey> P'haps I'm confused.  You mean ocaml is ftbfs, or cdbs is because of this?
[05:57] <lamont> jbailey: cdbs is ftbfs because ocaml lacks a Depends:
[05:58] <doko> ahh, a Depends?
[05:58] <lamont> doko: yes.
[05:59] <jbailey> lamont: Thanks.  I think I'll avoid tossing ocaml into the build mess of the moment, but I'll note it for later.
[05:59] <doko> fixing it
[05:59] <lamont> jbailey: works for me
[06:00] <lamont> anyone need anything before I go finish my beauty sleep?
[06:01] <doko> lamont: does it really help?
[06:01] <lamont> doko: no.
[06:02] <lamont> but it makes me _feel_ better.
[06:02] <lamont> less cranky and all that
[06:02] <doko> could go to bed as well ;-) ... who tells us about build failures?
[06:02] <lamont> http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
[06:02] <doko> nice
[06:02] <lamont> that's pushed by an rsync that happens every 20 minutes
[06:03] <lamont> phones will ring if all hell breaks free
[06:04] <doko> at 00/20/40?
[06:04] <lamont> doko: yeah, but it runs for > 5-10 minutes...
[06:05] <lamont> see ~lamont/buildLogs/Lists/Time for the time of the most recent run
[06:06] <lamont> (part of the delay is that it dumps the entire wanna-build database for all architectures on breezy)
[06:08] <jbailey> Is w-b still an underindexed db4 database?
[06:08] <elmo> hahaha
[06:08] <elmo> it's a gdbm database
[06:08] <elmo> ENTIRELY UNINDEXED
[06:08] <jbailey> Ah.  I had obviously blocked that out. =)
[06:11] <doko> elmo: can we open the uploads for cxxlibs.txt for everyone, but not the Debian sync?
[06:13] <Kamion> doko: hasn't there previously been a libdb3++?
[06:13] <Kamion> i.e. before the last C++ transition?
[06:13] <doko> yes, but we don't support upgrades from pre-sarge
[06:14] <Kamion> just seems a bit needlessly fragile ...
[06:14] <Kamion> i.e. aggressive non-support rather than passive non-support
[06:15] <doko> hmm, that's what neuro proposed on #debian-release, and nobody complained about the updated proposal
[06:15] <doko> we did rename all c102 packages back to their original name
[06:15] <elmo> doko: done
[06:15] <Kamion> ok ...
[06:16] <elmo> doko: ugh
[06:16] <elmo> that's hideous
[06:17] <doko> DIFFS/aiksaurus.diff
[06:17] <doko> DIFFS/aspell.diff
[06:17] <doko> DIFFS/flac.diff
[06:17] <doko> DIFFS/fltk1.1.diff
[06:17] <doko> DIFFS/libsidplay1.patch
[06:17] <doko> DIFFS/qt-x11-free.diff
[06:17] <doko> DIFFS/sablotron.diff
[06:17] <doko> DIFFS2/db3.diff
[06:17] <doko> DIFFS2/fam.diff
[06:17] <doko> DIFFS2/gtkmm2.0.diff
[06:17] <doko> DIFFS2/icu.diff
[06:17] <doko> DIFFS2/libsigc++-1.2.diff
[06:18] <doko> DIFFS2/zipios++.diff
[06:18] <doko> these are affected
[06:22] <doko> hmm, I don't want to change the naming policy at this point. If we (or Debian) decide on a changed naming policy, then we'll have to rename them again. I'm sorry the plans for this hyperexpressway were shown at alpha centauri some time ago ...
[06:58] <jbailey> Wow, 1pm.  I should go eat soon.
[06:59] <jbailey> elmo: May I get the build-deps for directfb installed in the breezy (amd64) chroot on concordia, please?
[07:49] <lamont> FTBFS: arts/ppc (sym vesions), libmusicbrainz (cast loses precision), smpeg (missing build-dep)
[07:49] <lamont> so far, that is
[07:52] <doko> ia64 buildd running?
[07:53] <jbailey> lamont: Can you requeue glibc on amd64 please?
[07:55] <doko> what do we gain from the xorg restructering besides changing build dependencies?
[07:56] <lamont> elmo: where did gcc-4.0 -7ubuntu6 for ia64 go?
[07:56] <lamont> jbailey: oh yeah.. that one got annoyed in if_addr, btw
[07:57] <doko> daniels: libx11-dev is not contained in xlibs-dev?
[07:57] <jbailey> lamont: Yeah, I saw.    All it's doing is asking for an interface list and getting hung in the syscall.  All arch's show this behaviour sometimes.
[07:57] <lamont> jbailey: given back
[07:57] <jbailey> lamont: tx.
[07:58] <lamont> doko: smaller packages
[07:58] <lamont> and no huge bump to rebuild identical fonts each upload
[07:59] <jbailey> I thought fonts were split out a while back?
[08:00] <doko> not from the source
[08:01] <lamont> jbailey: you may be right.  dunno
[08:02] <jbailey> source: xorg, weird.  I thought they had at least split the fonts out.  my bad.
[08:02] <lamont> the biggest thing will be that little trivial fixes in one package don't require a 200MB bump of the archive
[08:03] <lamont> jbailey: as of -10, they weren't.  as of -14, they appear to be.
[08:03] <lamont> hoary shipped -10
[08:06] <doko> jbailey: does cdbs1 know about amd64?
[08:06] <jbailey> doko: Does cdbs1 know about archs in general?
[08:06] <jbailey> doko: I think we defered to type-handling for that level of evilness.
[08:07] <doko> dpkg-architecture: warning: Unknown system type amd64-linux
[08:07] <jbailey> doko: dpkg appears to be broken, that's all.
[08:07] <jbailey> doko: I see that without using cdbs.
[08:08] <doko> let's upload binutils, nobody will notice the breakage, and if somebody notices it, we blame dpkg for it :)
[08:08] <lamont> jbailey: no type-handling in ubuntu's cdbvs
[08:09] <jbailey> doko: Sounds good.  Will you take a snapshot from the branch to get the ppc64 fixes?
[08:09] <lamont> unless you'd rather move to universe....
[08:10] <jbailey> lamont: Hey, I don't use type-handling for anything. =)
[08:10] <lamont> FTBFS: aspell/amd64: can't stat /usr/share/locale
[08:10] <jbailey> lamont: Although I wish that someone would come up with a better solution for the problem that it solves.
[08:11] <lamont> jbailey: btw, you might want to verify that I didn't screw up the depends/build-depends for cdbs when I ripped type-handling out of it
[08:11] <jbailey> lamont: skew between locales and glibc from the amd64 build failure?
[08:11] <lamont> jbailey: aspell?  remotely possible
[08:11] <jbailey> No build-dep on locales.
[08:12] <jbailey> Probably just needs it added, I'll get it.
[08:12] <lamont> amd64 in dpkg-builddeb for glibc, btw
[08:13] <jbailey> lamont: Nice.  At some point I'll get annoyed enough to dive into the kernel to fix that.  But I might finish the Hurd first...
[08:13] <minghua> Hi, I am wondering if there are any official words on Fortran packages
[08:13] <minghua> I am working on the c++ transition of arpack++
[08:14] <minghua> which is a c++ wrapper for arpack
[08:14] <minghua> and arpack is a Fortran package
[08:14] <minghua> the default fortran compiler is g77
[08:14] <jbailey> Erm, no that's not right.  bash and dpkg provide /usr/share/locale as well, it can't be just a missing build-dep on that.
[08:15] <minghua> but g77 is only in GCC 3.4, and GCC 4.0 has gfortran instead
[08:15] <minghua> gfortran is a completely different code base
[08:15] <jbailey> gfortran isn't completely backwards compatible to g77 yet, it's planned to be eventually.
[08:16] <minghua> jbailey: yes I know that
[08:16] <jbailey> AIUI, the gfortran testsuite is pretty complete, though, so you can generally expect it to work.
[08:16] <minghua> my problem is, it seems g77 depends on gcc-3.4 and g++-3.4
[08:16] <minghua> or libg2c0
[08:17] <jbailey> g++-3.4 shares the 4.0 abi.
[08:17] <minghua> anyway, when I do "apt-get build-dep arpack++" I got gcc-3.4, g++-3.4 and stuff
[08:18] <minghua> jbailey: so are you suggesting to just use gcc-4.0 and g++-4.0?
[08:18] <elmo> jbailey: done
[08:18] <minghua> I haven't looked at the code yet
[08:19] <jbailey> If you just use 'gcc' and 'g++', it should all work as normal.  gcc-4.0 and g++-4.0 will still be on the system as the defaults.
[08:19] <minghua> but I think it uses gcc and g++, which will give 4.0 in breezy
[08:19] <lamont> jbailey: debian/tmp/usr/share/locale...
[08:19] <lamont> (sorry)
[08:19] <jbailey> lamont: I'd flog you for it, but I change money for that sort of thing now...
[08:20] <jbailey> elmo: Thanks
[08:20] <lamont> hehe
[08:20] <minghua> jbailey: okay thanks.  I think I'll just use 4.0 here, and see if anything breaks
[08:21] <jbailey> minghua: Thanks.  Poke your head in here if it does.  We're all on weird schedules, so sorry if it takes us a bit to respond.
[08:39] <doko> lamont, jbailey: debian/tmp/usr/share/locale is from aspell?
[08:40] <lamont> doko: yres
[08:40] <doko> lamont: yes, I'm looking at it. hmm, interesting ...
[08:41] <doko> lamont: is the ia64 buildd running?
[08:41] <lamont> doko: still looking for gcc-4.0
[08:41] <lamont> elmo: any chance that gcc-4.0/ia64 is NEW?
[08:42] <elmo> no, it's in accepted
[08:42] <elmo> unbreaking cron.daily ..
[08:46] <lamont> ah, that would also explain it... :-(
[08:47] <jbailey> This truly was broken in a different way on each arch.
[08:47] <jbailey> Amazing.
[08:49] <doko> directfb?
[08:50] <jbailey> doko: Yeah.  It's one of the gcc4 breakages you gave me before.  I got an answer a little bit ago on how the syscall they use is supposed to work on ia64.
[08:50] <lamont> jbailey: coolness
[08:51] <lamont> btw, fonts came out in -11
[08:56] <doko_> no new breakages, or are the buildds busy?
[08:56] <lamont> no new breakages
[08:56] <lamont> heh.  let me rephrase that.
[08:56] <lamont> no new breakages in main/restricted. :-)
[08:57] <doko_> the last log I see is for: glibc_2.3.5-1ubuntu2_20050518-1857-amd64-successful.bz2
[08:58] <lamont> After installing, the following source dependencies are still unsatisfied:
[08:58] <lamont> libicu21-dev(inst 2.1-2 ! >= wanted 2.1-2ubuntu1)
[08:58] <lamont> from xerces26
[08:58] <lamont> seems to be about the last one
[08:59] <doko_> no, see http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
[09:00] <lamont> right
[09:05] <lamont> ia64 starts building
[09:08] <lamont> doko: is depwait tree from hell, it would appear.
[09:09] <lamont> so it may just take extra cron.daily love and iterations
[09:12] <lamont> vdk2_2.4.0-3ubuntu1 on ppc/amd64
[09:13] <lamont> doko: the depwait chains have to make it through the cron.daily iterations, so time will tell.....
[09:13] <elmo> all the NEW stuff is going to universe too, which is going to make things... fun
[09:13] <lamont> elmo: NOOOOOOOOOOOOOoooooooooooooooo  :-(
[09:14] <lamont> that sounds, um, fun. yeah.. that's the right word
[09:14] <doko> elmo: can we speed up things in some way?
[09:15] <lamont> elmo: Rejected: file 'libcwd0c2_0.99.39-1ubuntu2_powerpc.deb' has unknown component 'non-free'.
[09:15] <lamont> Rejected: file 'libcwd0c2-dbg_0.99.39-1ubuntu2_powerpc.deb' has unknown component 'non-free'.
[09:15] <elmo> meh
[09:15] <elmo> crackwhoreness
[09:16] <lamont> hehe
[09:16] <elmo> how many other non-free packages are there?
[09:16] <elmo> they'll all be like that
[09:17] <elmo> fixed libcwd anyway
[09:17] <doko> elmo: that's the only one
[09:18] <elmo> cool
[09:22] <elmo> hmm, crap
[09:22] <elmo> lamont: I just did a bunch of promotions which might cause unaccept spam, yell if it does
[09:22] <lamont> ok
[09:26] <lamont>  opencv_0.9.6-1ubuntu1
[09:26] <lamont> amd64
[09:26] <lamont> apyramids.cpp:189: error: cast from 'void*' to 'int' loses precision
[09:26] <lamont> bad opencv
[09:26] <lamont> tulip/amd64 same storry
[09:38] <doko> hmm, I don't understand the db4.2 build failure yet
[09:39] <lamont> bad build-deps????
[09:39] <lamont> nfc
[09:39] <lamont> was down-rev build-deps before, fwiw
[09:40] <lamont> that is, -18ubuntu1 was dep-wait
[09:40] <doko> yes, I fixed that
[09:40] <lamont> ew.  smpeg is really SDL bug.
[09:41] <lamont> In file included from gtv.c:14:
[09:41] <lamont> /usr/include/SDL/SDL_syswm.h:56:22: error: X11/Xlib.h: No such file or directory
[09:41] <lamont> missing Depends
[09:42] <fabbione> re
[09:42] <fabbione> lamont: did you stop the sparc buildd??
[09:42] <doko> go sparc, go !
[09:42] <lamont> fabbione: yes
[09:42] <fabbione> why?
[09:43] <lamont> well, it needs to have xorg built and in the archive before it starts building libraries.  also good to get gcc-4.0...-7ubuntu6 built first
[09:43] <lamont> and then trider-g7 stopped talking to me...
[09:44] <fabbione> right...
[09:44] <fabbione> i was thinking to use it as a guine pig to see if the build-deps are correct
[09:44] <fabbione> guinea even
[09:44] <fabbione> hmm trider is having weird issues
[09:44] <lamont> ISTR that doko didn't bother fixing the X depends to be versioned...
[09:45] <doko> ?
[09:45] <lamont> doko: for why we needed to have X built before we did lib building...
[09:45] <lamont> though
[09:46] <fabbione> so ok.. xorg, gcc-4 and the rest
[09:46] <doko> they have to be changed, versioned provides don't work. how should I know that x-dev packages get renamed?
[09:46] <lamont> doko: wasn't blaming.  just explaining that "testing the build-deps" was probably a fruitless exercise...
[09:47] <jbailey> aspell is gettext b0rkage, which in turn stopped building ages ago because they added java support to it and we don't have classpath in main.  Should I just disable the java bits for now and go back to it when we have java bits in main?
[09:47] <doko> lamont, sorry, maybe I need a break ...
[09:47] <lamont> doko: no, my bad.
[09:47] <lamont> but you can have a break anyway. :-)
[09:48] <lamont> "java is a mess"
[09:48] <lamont> jbailey: personally, I'd drop java from gettext, and file a bug in the bts saying that we need to add it back once we have classpath in main
[09:48] <fabbione> so ok.. xorg, gcc-4 and the rest?
[09:48] <lamont> fabbione: yes
[09:48] <fabbione> ok
[09:48] <fabbione> what about dpkg?
[09:48] <lamont> well, no cxxapps.txt packages
[09:48] <jbailey> lamont: This seems to be a lovely example of what you were talking about though: http://people.ubuntulinux.org/~lamont/buildLogs/g/gettext/0.14.4-2/ =)
[09:48] <fabbione> i still have the very old one working in the sparc chroot
[09:48] <lamont> jbailey: yeah.
[09:48] <lamont> exactly
[09:49] <fabbione> lamont: yes, they are still hardencoded in buildd.conf
[09:49] <lamont> fabbione: dpkg probably doesn't hurt, but it's more the DEB_*_ARCHITECTURE stuff that got tweaked from *-linux to *-linux-gnu
[09:50] <lamont> so building dpkg early will enhance your experience.
[09:50] <fabbione> lamont: yes  i know the story
[09:50] <lamont> xorg, gcc-4.0, dpkg, and let 'er rip
[09:50] <fabbione> i need to build x build-dep first
[09:50] <fabbione> hmm no, they are just new versions
[09:52] <lamont> jbailey: btw, any word on iptraf?
[09:52] <jbailey> lamont: Sorry, had slipped my mind.  Grabbing it while this builds.
[09:54] <fabbione> jbailey: do i need to rush to build the new glibc?
[09:54] <fabbione> i have it all ccache so it would be fast anyway
[09:54] <lamont> cp -p debian/README.libstdc++-baseline \
[09:54] <lamont>         debian/libstdc++6-4.0-dev/usr/share/doc/gcc-4.0-base/C++/README.libstdc++-baseline
[09:54] <lamont> cp: cannot stat `debian/README.libstdc++-baseline': No such file or directory
[09:54] <lamont> make[1] : *** [stamps/08-binary-stamp-libstdcxx-dev]  Error 1
[09:54] <lamont> make[1] : Leaving directory `/build/buildd/gcc-4.0-4.0.0'
[09:54] <lamont> fabbione: glibc is unrelated to the transitiuon
[09:55] <fabbione> ok
[09:55] <fabbione> i guess i can build dpkg before xorg and gcc...
[09:55] <fabbione> mainly because i can suffer 3 hours more or less for x
[09:56] <fabbione> but clearly i am not going to stay aware 17 for gcc
[09:56] <doko> debian/rules.d/binary-libstdcxx.mk: unmodified: line 318
[09:56] <lamont> doko: thanks
[09:56] <doko> lamont: move the ifdef two lines up
[09:56] <jbailey> fabbione: For locales stuff, probably.  Otherwise, there's no real magic in there for sparc.
[09:56] <fabbione> yeah that's why
[09:57] <lamont>   x-common: PreDepends: xorg-common (= 6.8.2-10) but 6.8.2-14 is to be installed
[09:58] <fabbione> EH????
[09:58] <fabbione> what package is that?
[09:58] <fabbione> no i mean
[09:58] <fabbione> wtf
[09:58] <lamont> time to upload x-common? 1.0
[09:58] <fabbione> why a versioned pre-depends?
[09:58] <fabbione> we didn't add that
[09:58] <fabbione> or at least I did NOT
[09:59] <lamont>  Pre-Depends: xorg-common (= 6.8.2-10)
[09:59] <lamont>  Package: x-common
[09:59] <lamont>  Version: 0.99
[09:59] <fabbione> BAH
[09:59] <fabbione> lamont: the one i did local was not so binding
[09:59] <fabbione> that's why my i386 didn't catch it
[09:59] <fabbione> lamont: i think it is safe to upload 1.0 without that
[10:00] <lamont> yes
[10:00] <lamont> it is
[10:00] <lamont> you wanna do that?
[10:01] <lamont> or shall I?
[10:01] <fabbione> go ahead
[10:01] <lamont> (and where is the source repository for it if I do...)
[10:01] <fabbione> just get it from the archive
[10:01] <lamont> ok
[10:01] <fabbione> 1.0 is 0.99 without the Pre-Depends
[10:01] <lamont> drop the predepends entirely, right?
[10:01] <fabbione> yes afaik
[10:01] <fabbione> let me check on chinstrap
[10:01] <fabbione> daniels left some pkgs there
[10:03] <lamont> given the contents, I think we're safe
[10:03] <fabbione> no changes... so yes
[10:03] <fabbione> it's safe
[10:03] <lamont> uploaded
[10:04] <doko> fabbione: adding a build-dep to get X11/Xlib.h ... should that be libx11-dev ?
[10:04] <lamont> +-Wl,xineplug_decode_mad.so -o .libs/xineplug_decode_mad.so
[10:04] <lamont> /usr/bin/ld: cannot find -lmad
[10:04] <lamont> xine-lib
[10:04] <fabbione> doko: i am not 100% sure with the X transition going on
[10:04] <fabbione> doko: you will need to check the new packages
[10:06] <doko> xine-lib: merge error, will fix
[10:06] <fabbione> lamont: btw.. building dpkg on sparc is not the same mess as it happened at the DC
[10:07] <fabbione> because sparc didn't even get closer to build the broken dpkg
[10:08] <jbailey> lamont: in http://people.ubuntu.com/~lamont/buildLogs/i/iptraf/ - why is the dtime on the directory 11-may, when the contents of the files are late 2004?
[10:08] <lamont> interesting how much 'fakeroot debian/rules binary-arch' rebuilds
[10:09] <lamont> 11 may sounds about right for when I did the 'find . -type f | xargs bzip2'
[10:10] <jbailey> Huh.  Surprising that bzip2 left the mtime alone on the files themselves.
[10:10] <jbailey> thx.
[10:19] <lamont> same as gzip does
[10:19] <fabbione> lamont: confirmed that x-common 1.0 is safe once all the buildd have xorg-common -11 or higher
[10:20] <fabbione> and given that it is arch: all
[10:20] <fabbione> you are clearly green light
[10:20] <lamont> fabbione: s/are/were/
[10:20] <lamont> :-)
[10:20] <fabbione> right :)
[10:21] <fabbione> good
[10:21] <fabbione> xorg is building on sparc
[10:22] <fabbione> but i am pretty sure something is going to break
[10:23] <lamont> fabbione: of course: it's X
[10:23] <fabbione> i am more worried about the amount of sparc asm in it
[10:23] <fabbione> than the real build system
[10:23] <fabbione> i can cope with the build system easily
[10:23] <fabbione> but not with asm :/
[10:24] <fabbione> this evening i was at a neighbour meeting stuff
[10:24] <fabbione> we might get fiber soon :)
[10:24] <fabbione> up to 20Mb as MBR
[10:24] <fabbione> and higher when the net is unloaded
[10:26] <lamont> MBR?
[10:27] <fabbione> Min. (guaranteed) Bit Rate
[10:27] <lamont> kewlness
[10:27] <fabbione> yup
[10:27] <fabbione> i only need to convince 70 families in the neighbourood that they *REALLY* need fiber at home
[10:35] <lamont> gcc-4.0_4.0.0-7ubuntu6hppa1_hppa.changes
[10:36] <doko> lamont: :)
[10:37] <fabbione> rocking!
[10:37] <fabbione> go hppa!
[10:43] <lamont> of course, I had to get out and push...
[10:43] <lamont> but gcc-4.0_4.0.0-7ubuntu6hppa2 (and -7ubuntu7) will really build
[10:43] <fabbione> ehehe
[10:43] <fabbione> so when will you start uploading breezy to ports?
[10:44] <lamont> fails 6.5 hours into the build
[10:44] <lamont> already diud
[10:44] <fabbione> and btw.. it's time you send me an ia64 and a hppa :)
[10:44] <lamont> doxygen and lkh are there already
[10:45] <fabbione> i told bdale but he bounced me to some local dk offices that are pretty useless
[10:45] <lamont> I'll see what I can scrounge up for you next month
[10:45] <fabbione> coolness :)
[10:46] <fabbione> i am already using twice amount of energy of a normal 2 person dk family
[10:46] <fabbione> but i can do better..
[10:46] <fabbione> on the other side i used only 30% for the house heating
[10:47] <fabbione> i didn't check how much tbh
[10:47] <fabbione> my wife gave me a briefing :)
[10:47] <lamont> LOL
[10:47] <fabbione> nah my wife gets them.. i pay
[10:48] <fabbione> and since i still pay with or withou details...
[10:48] <lamont> hehe
[10:54] <fabbione> uhuh???
[10:54] <lamont> libsdl1.2 fails to build:   libarts1-dev: Depends: libqt3-mt-dev (>= 3.3.3) but it is not going to be installed
[10:54] <lamont> i386, ppc, and maybe more
[10:54] <fabbione> ahaha gotta love circular build-dep
[10:55] <doko> elmo: libid3-3.8.3c2 needs main love
[10:55] <lamont> is easy to fix though... just add the x build-dep to arts :-(
[10:56] <fabbione> i guess i am going to watch some TV while X builds
[10:57] <fabbione> looking at the log file growing isn't really that sexy
[10:57] <doko> watching sexy tv instead? ;)
[10:58] <fabbione> doko: xXx 2
[10:59] <lamont> fabbione: someone beat me to x-common
[11:01] <fabbione> lamont: right
[11:01] <fabbione> daniels did
[11:02] <lamont> heh
[11:02] <lamont> wfm
[11:02] <lamont> anyway, back in a few
[11:02] <fabbione> later
[11:08] <jbailey> fabbione: The ia64 will possible double what you're using now.  I think it was mdz who estimated that his ia64 would cost him about $80 US a month to run.
[11:08] <jbailey> fabbione: That's what data centres are for. =)
[11:22] <lamont> jbailey: nah
[11:26] <lamont> 1-600           .0730
[11:26] <lamont> 601-1100        .0690
[11:26] <lamont> 1101-           .0650
[11:26] <lamont> sadly, I'm around 2900-3200kwh/month
[11:27] <lamont> wish there was a 4th tier.... :-)
[11:27] <jbailey> I phear what mine is.  Right now it's included in my rent.
[11:28] <lamont> much better that way
[11:28] <jbailey> In the new place I have to cover it, as well as purchase fridge/stove/washer/dryer.
[11:28] <jbailey> But the upshot is that I'll have multiple rooms!
[11:28] <lamont> WOOHOO!!!
[11:29] <lamont> computer room, and sleeping room? :-)
[11:29] <jbailey> Someone looking at xerces yet?
[11:29] <jbailey> lamont: A separate room for the kitchen even.
[11:29] <jbailey> lamont: I'll have to buy my own clock, I won't be able to read it off the stove anymore.
[11:29] <lamont> build-dep, istr
[11:29] <lamont> hehehe
[11:30] <jbailey> On hppa?
[11:31] <jbailey> Right, it's given-back.  I was sitting far enough back I couldn't see the difference between orange-on-white and red-on-white.
[11:31] <doko> jbailey, xerces seems to build, missing deps on ia64
[11:32] <lamont> jbailey: yes, on hppa.
[11:32] <lamont> sorry about the orange vs red
[11:32] <jbailey> np, now that I know to look for it, I can see it pretty clearly.
[11:33] <doko> lamont, make it violent
[11:33] <doko> s/n//
[11:33] <jbailey> *g*
[11:33] <lamont> basically, every 30 minutes, there's this few-minute window where everything gets given back. :-(
[11:35] <jbailey> Not from me, I have stuff this evening, so I'll be signing off shortly.
[11:36] <doko> hmm, no I'll go bed. I think, the new libs will be in main tomorrow without manual intervention?
[11:38] <lamont> I think they'll be there by sometime tomorrow, possibly with some muppet-intervention...
[11:49] <fabbione> jbailey: well my server now sucks aroun 700W
[11:49] <fabbione> it has 2 PSU
[11:49] <fabbione> and it's loaded
[11:50] <fabbione> so i guess it won't be too much of a difference
[11:50] <fabbione> later lamont
[11:50] <elmo> fabbione: you're up late
[11:50] <fabbione> elmo: yeah
[11:52] <fabbione> unfortunatly i crashed for 45 minutes this afternoon and now i am all awake :)
[11:56] <jbailey> elmo: BTW, Do you generally want us to tell you when we're done with build-deps that you put in repo's for us, or do you just reap them from time to time?
[11:57] <elmo> jbailey: nah, I like to leave the chroots fat
[11:57] <jbailey> elmo: Cool, thx.


[07:54] <bobsy> hi
[07:58] <bobsy> just installed on pinephne
[09:27] <hisacro> bobsy: was it straightforward or far from it?


[10:24] <venda> ChrisH, you up
[10:34] <venda> darn I knew I should have written it down. Whats the URI for upgrade from warty to hoary
[10:50] <venda> abelli, hi
[10:51] <venda> sawubona
[10:52] <abelli> sawubona
[10:52] <abelli>  Hoe gaan dit?
[04:45] <froud> enrico, hi
[04:46] <enrico> hi froud!
[04:46] <froud> finally got the vendor drop thing sorted
[04:46] <froud> but needs upgrade of svn to 1.1.1 or 1.1.2
[04:46] <froud> a combined use of symlinks
[04:47] <froud> I can script the checkout from upstream GNOME etc
[04:47] <froud> into vendor/gnome/current
[04:48] <enrico> upgrade of svn? uhm... I wonder what version is in warty
[04:48] <froud> and copy to vendor/gnome/2.8
[04:48] <froud> then we have symlinks in trunk/ to the 2.8
[04:48] <enrico> We're lucky if Elmo will eventually cooperate at all in this moving of the repository, I seriously doubt he'll want to install a specific version
[04:49] <froud> well that is a problem
[04:49] <froud> but I can now generate ubuntu cust docs for user man
[04:49] <froud> so elmo must decide what he wants to do
[04:50] <froud> btw what is the url for upgrade to hoary?
[04:50] <froud> I want to do it via synaptic
[04:50] <enrico> you just change "warty" with "hoary" in the APT sources
[04:50] <froud> that's it
[04:51] <froud> ok will try, but most of those are linked to archive
[04:51] <froud> is hoary in archive
[04:52] <froud> my repos in synaptic points to archive.ubuntu.com/ubuntu
[04:53] <froud> so if I cange the distribution field to haory you think that's what will work
[04:53] <froud> any issues with the upgrade?
[04:54] <froud> and warty-security with hoary-security ?
[04:57] <enrico> archive?  uhm, strange
[04:58] <froud> I am looking under synaptic : settings > repositories
[05:00] <enrico> yes, sorry, it's archive.ubuntu.com/ubuntu
[05:01] <enrico> yes, just s/warty/hoary/g
[05:01] <froud> ok so just change the distribution string
[05:01] <froud> did you upgrade go ok?
[05:02] <enrico> Seems to be, yes
[05:02] <enrico> I did it with aptitude, but that shouldn't change much
[05:02] <froud> I assume once I have done this that I will get online updates as they are released, though I wont know what candicate it is?
[05:03] <froud> yes, i can do it via aptitude, but it does the same thing as synaptic
[05:03] <enrico> yes, you'll get every new package developers will upload during the development phase
[05:03] <froud> ok here goes
[05:03] <enrico> you can check HoaryReleaseSchedule to see in which phase we are
[05:05] <froud> reloadingpackage list
[05:07] <venda> enrico, just mark all upgrades and GO!
[05:09] <venda> ok, well here goes nothing :-)
[05:09] <venda> enrico, so what about that SVN thing
[05:09] <enrico> nothing?
[05:10] <venda> yes venda is my crash and burn box
[05:10] <venda> if I crash it does no damage
[05:10] <venda> great for testing
[05:10] <enrico> I run ubuntu under qemu :)
[05:10] <venda> Hmm what's that give url
[05:11] <venda> I hav eused VMware in some cases
[05:11] <venda> but that costs
[05:11] <enrico> apt-cache show qemu
[05:11] <enrico> http://fabrice.bellard.free.fr/qemu/
[05:12] <enrico> It works really well
[05:13] <venda> whew gnome is slow or what
[05:13] <enrico> you mean, on qemu or in general?
[05:13] <venda> nah just GNOME in general
[05:14] <enrico> how much memory do you have?
[05:14] <venda> and now I remember why I stick with KDE
[05:14] <venda> on this box 768
[05:14] <venda> p3 1 ghz
[05:15] <venda> one of those celeron coppermine processors
[05:16] <venda> so vendor drops
[05:16] <venda> now I have the formula do you want to adopt it?
[05:16] <enrico> Same as in my laptop.  Gnome's quite fast here
[05:16] <enrico> actually, I'm centrino 1.6, but it shouldn't be that much of a difference
[05:17] <venda> you worked on kde yet?
[05:17] <enrico> Yes, I used KDE before
[05:17] <venda> try it you'll feel the difference
[05:17] <enrico> I don't really care about what desktop I use, actually: I mainly use terminals :)
[05:17] <enrico> plus firefox and openoffice
[05:17] <enrico> but I can code in gtk--, and cannot code in QT
[05:18] <venda> yah terminals nice, but not for everyday user
[05:18] <enrico> ehy, that's the everyday usage of this user on this computer :)
[05:18] <venda> so what do you want to do about vendor drops
[05:18] <enrico> When I give lessons to people, we use KDE or Gnome depending on "people"
[05:19] <enrico> about vendor drops, the problem is having the right version on the new server.  That's nontrivial
[05:19] <enrico> Elmo will probably want to have the version that is in Warty, because the servers run warty.  If he installs an arbitrary versions, then he has a nightmare tracking security updates and so on
[05:19] <enrico> So, if warty has the right version, then that's cool.  Else, it's a problem
[05:20] <venda> no warty does not
[05:20] <enrico> does not what?
[05:20] <venda> have the right version
[05:20] <venda> dunno about hoary
[05:21] <venda> I don't get it. Do people want to get docs and be able to take advantage of upstream or not?
[05:22] <enrico> In that case, we might very well postpone customization of the Gnome User's Manual to after hoary came out
[05:22] <enrico> Unless someone will solve the problem for us
[05:22] <venda> sh1t
[05:22] <venda> We are meant to be working on hoary
[05:23] <venda> I give up
[05:23] <enrico> I'm honestly bored with chasing elmo just for this simple migration.  I'd say that we write down what's needed to support the Gnome User's Manual, and either we'll have it, or we won't support it until we have it
[05:24] <enrico> We are working on hoary, but the servers run warty
[05:24] <enrico> You don't want to run an unstable distribution on your servers, don't you? :)
[05:24] <enrico> venda: "never give up, never surrender!"
[05:24] <venda> he can install svn 1.1.2 on warty
[05:25] <venda> I really dont see the problem
[05:25] <venda> this kind of crap from a sys admin
[05:25] <venda> is not good
[05:25] <venda> get a new sys admin
[05:27] <enrico> well, for one thing noone still said "no" to installing 1.1.2 on canonical's servers (the reason being that noone has asked yet :)
[05:27] <enrico> So, we can put down the list of requirements for supporting the GUM and see if they get met
[05:28] <venda> I dont see how we can move forward at the pace required when  we have to deal with shit like this.
[05:28] <venda> crikey this is a technology project
[05:28] <venda> canonical either want to do it properly or just dont do it
[05:28] <venda> we are not asking to bring god to earth
[05:29] <venda> just move to canonical servers and when we do install svn 1.1.2
[05:29] <venda> at the moment we are working on poor hornbecks machine
[05:29] <enrico> I've been chasing Elmo for the last 2 weeks or so
[05:29] <venda> since we dont have svn in canonical and we need to move why not just DO IT
[05:30] <venda> perhaps a message to mark will do the rick
[05:30] <enrico> I'm trying to getting past this issue without attacking people directly
[05:30] <venda> I mean shiot ubuntu want free contibutions and have people who say yes they will
[05:30] <venda> yet when they bring solutions, they cant do it
[05:31] <venda> that's crap
[05:31] <enrico> venda: cool down :)
[05:31] <venda> i spent three days of my time to work it all out
[05:31] <enrico> let's try to ask first :)
[05:31] <venda> you did an you cant even get them to make the move
[05:31] <enrico> I said I'm pessimist, but I didn't say we won't get it
[05:32] <venda> really I am running out of patience
[05:32] <enrico> well, so far I asked politely, but we have a deadline for the move, which is the end of january
[05:32] <enrico> so, the more we get near the deadline, the less I'll be polite
[05:32] <venda> end of january
[05:33] <enrico> About the G.U.M.: to work on it we need vendor drops, and to have vendor drops working fine we need at least subversion 1.1.2.  Is that right?
[05:33] <venda> you do know the hoary freeze is 21 Feb
[05:33] <venda> As I said, my solution needs symlinks
[05:34] <venda> that's only supported in 1.1.1 or 1.1.2
[05:34] <enrico> Ok, so at least 1.1.1
[05:34] <venda> cant see why not 1.1.2
[05:34] <venda> you know what I franklly dont care anymore
[05:35] <venda> just get somebody to do it
[05:35] <enrico> It's goot to set a minimum requirement and an optimal requirement, just in case the optimal requirement turns out to have some problems
[05:35] <venda> argh!! crap. you just set a requirement period
[05:35] <venda> enough
[05:36] <venda> I am not wasting my time
[05:49] <ChrisH> The planet will probably not explode if we don't use vendor drops in Hoary already.
[06:01] <enrico> ChrisH: I agree.  But I can understand froud's frustration after spending time investigating this
[06:02] <ChrisH> Conclusion.... froud is investing too much time. :)
[09:43] <abelli> ciao a tutti