[03:32] <lamont> sigh.  that took _WAY_ too long
[04:06] <daniels> fabbione: which patch?
[04:07] <daniels> oh, I see
[04:07] <daniels> fabbione: got it
[04:47] <jbailey> doko: Around?
[06:09] <fabbione> morning
[06:09] <fabbione> daniels: ping?
[06:10] <daniels> pong
[06:10] <fabbione> daniels: did you see my patch on people?
[06:11] <daniels> yeah, already merged it
[06:11] <fabbione> thanks
[06:11] <fabbione> i am uploading -15 right now
[06:11] <daniels> no worries
[06:11] <daniels> -15 of what?
[06:11] <fabbione> as soon as i get the accepted you are free to go for -16 :)
[06:11] <fabbione> xorg
[06:11] <daniels> oh, for sparc
[06:11] <fabbione> yes
[06:11] <daniels> phew
[06:12] <fabbione> if you upload -16 before, the -15 bins will be rejected
[06:12] <daniels> sure
[06:13] <fabbione> finally i can start buildd again :)
[06:29] <fabbione> http://www.theregister.co.uk/2005/05/18/vibrating_knickers/
[06:29] <fabbione> AHAHHAHAHA
[06:56] <fabbione> daniels: ok you can go anytime
[06:56] <fabbione> -15 has been accepted
[06:56] <daniels> cool
[06:58] <fabbione> thanks dude
[06:59] <lamont-away> fabbione: are you uploading binaries that are non-virgin???  you bad man you.
[07:01] <fabbione> lamont-away: yeah it's cheating on a package :)
[07:01] <fabbione> aren't you supposed to be sleeping?
[07:01] <lamont-away> yeah - came out to check on the buildd, and change the laundry
[07:02] <lamont-away> anyway, g'night again
[07:02] <fabbione> btw kernel: i need updated chroots on concordia and davis otherwise i can't test build
[07:02] <lamont-away> yeah - saw that in -kernel.
[07:02] <fabbione> lamont-away: too lazy to change the version
[07:02] <fabbione> specially because -16 with the fix will hit archive soon
[07:03] <fabbione> lamont-away: before you go... xorg gcc -> buildd?
[07:03] <fabbione> is there anything else i need to take care of?
[07:03] <fabbione> lamont-away: i doubt... the fix was sparc specific
[07:03] <daniels> lamont-away: uhm no, it was a sunffb-specific fix :P
[07:03] <fabbione> sunffb driver compilation options
[07:03] <daniels> i didn't know what -mv8 was before I started on -15
[07:03] <daniels> and I still don't
[07:04] <daniels> unless it specifies the particular sparc revision or some shit
[07:04] <lamont-away> prior to unleashing the buildd: 1) cxxapps.txt -> @no_auto_build, 2) fresh versions of gcc-4.0, gcc-defaults, dpkg, xorg (and their build-deps, of course).
[07:04] <fabbione> i think it's some gcc optimization flag
[07:04] <lamont-away> ah, ok
[07:04] <fabbione> lamont-away: yeps.. all of that it's already in place
[07:04] <lamont-away> then you're _go_ for sparc buildd
[07:04] <fabbione> coolness
[07:04] <lamont-away> once those are in the archive, that is.
[07:04] <fabbione> they are
[07:04] <fabbione> i did build all of them manually
[07:05] <lamont-away> yeah
[07:05] <fabbione> yup
[07:05] <fabbione> good night lamont :)
[07:05] <fabbione> yeah i wonder how many i will get here
[07:06] <lamont-away> some of those are hppa specific (console-tools, ubuntu-meta)  But a bunch of them are /usr/include/X11 or gcc-4.0 or such
[07:06] <fabbione> + i still have some old craft to cleanup
[07:06] <lamont-away> 232 packages built, 151 of them uploaded... damn straws
[07:08] <fabbione> i guess i am going to hit some build-deps madness...
[07:08] <lamont-away> oh yeah, big time.
[07:08] <fabbione> ehhehe
[07:08] <lamont-away> not to mention lots of NEW packages, depending on how you have your overrides set up...
[07:09] <fabbione> i didn't setup overrides
[07:09] <lamont-away> there are still a few packages in universe that need to move to main to fix the archive.
[07:09] <fabbione> oh
[07:09] <fabbione> well i don't mix universe/main anymore
[07:09] <fabbione> after ports has been up
[07:09] <lamont-away> is in scrollback from doko just before he left.
[07:09] <lamont-away> that's good
[07:09] <fabbione> so the ogre model is complete again
[07:09] <fabbione> now the local pkg cache is down to 2 hours
[07:10] <fabbione> so possiblities to hit a mix are very very very low
[07:11] <lamont-away> anyrate, time to sleep again.  g'night
[07:11] <fabbione> night lamont
[07:14] <fabbione> daniels: btw.. elmo mentioned that xtrans had some .c files in /usr/include/X11
[07:14] <fabbione> dunno if you fixed that already
[07:14] <daniels> it's not fixable
[07:14] <daniels> that's how xtrans works
[07:14] <fabbione> eh?
[07:15] <daniels> you #define a bunch of crap and then #include the .c files
[07:15] <daniels> it's utterly, utterly disgusting
[07:15] <fabbione> JEEEEE
[07:15] <daniels> now you see why I have such a deep-seated hate for xtrans
[07:15] <fabbione> can't we move the .c files somewhere like /usr/share/ ?
[07:15] <fabbione> just for the goddam sake of it?
[07:16] <daniels> we've already had that argument upstream, the consensus was that we'd put it in /usr/include and try to kill xtrans
[07:16] <fabbione> BRRRRRRR
[07:17] <fabbione> we need to get an #u-x chan or something
[07:17] <daniels> this is the sort of shit I have to deal with upstream as well as downstream :P
[07:18] <fabbione> daniels: you are d00m3d
[07:19] <daniels> indeed
[07:20] <fabbione> omg! doko! another gcc-3* full set upload?
[07:21] <fabbione> i wonder if i will ever get to the point to actually build something else than toolchain
[07:34] <doko> morning all
[07:34] <fabbione> hey doko
[07:43] <fabbione> infinity: ping?
[12:16] <Kamion> doko: all those libraries are still in NEW - I'm leaving them to elmo
[12:19] <doko> hmm, getting all these renamed libraries into the archives is really suboptimal :-(
[12:26] <doko> Kamion: the debconf build needs kdebindings fixing for amd64 from Riddell
[12:27] <cartman> koffice will need http://janeway.no-ip.org/~cartman/filters_gcc4.patch btw
[12:27] <cartman> just in case
[12:29] <Riddell> might take a few hours
[12:29] <Riddell> cartman: which version of koffice is that against?
[12:29] <cartman> head
[12:29] <cartman> but filters rarely changed
[12:30] <cartman> should apply cleanly
[12:30] <Riddell> cartman: have you sent it back to the koffice developers?
[12:30] <cartman> Riddell: trying now, psn resisting ;)
[12:31] <Riddell> cartman: is that compiled on 64 bbit or 32 bit?
[12:31] <cartman> Riddell: only errors on amd64+gcc4
[12:31] <Riddell> cartman: ah, then you'll be adding errors to x86 :)
[12:32] <cartman> hmm no
[12:32] <cartman> similar fix went into kmail last week
[12:32] <cartman> :/
[12:32] <cartman> should be safe
[12:32] <cartman> you cast it to long before casting to something else to preserve precision
[12:32] <Kamion> doko: debconf hasn't built for ages anyway :(
[12:33] <Riddell> cartman: ok, maybe you're right
[12:33] <cartman> Riddell: I will wait for dfaure to be sure
[12:33] <Riddell> he's the man
[12:33] <cartman> yep
[12:36] <Riddell> out->fScratch = ((int)(long)in & 1);   is there really no better way?  just looks ugly
[12:37] <cartman> well I stole the solution from kmail where they were casting int* to int
[01:08] <Kamion> erm. what's the type of 'in'?
[01:09] <fabbione> ehy Kamion 
[01:09] <fabbione> Kamion: do you still have katie suppah p0w3r? :)
[01:10] <cartman> Kamion: const char* I think
[01:10] <Kamion> cartman: EWWWW. so you're basically working around crappy typing elsewhere.
[01:10] <Kamion> fabbione: yes ...?
[01:10] <cartman> Kamion: its msword/mswrite filters, what do you expect? honest :)
[01:11] <fabbione> Kamion: just for curiosity... what is the status of knetworkconf 0.6.1-3ubuntu4 (hoary-updates)?
[01:11] <Kamion> fabbione: same as it was when the last two people asked about it :P
[01:11] <Kamion> fabbione: source is in the archive, but I don't think hoary-updates is building ...
[01:11] <fabbione> Kamion: i am asking becuase i could see the source and the sparc buildd got it in needs-build, but it was not taking it
[01:12] <fabbione> ah ok, but it is safe for me to upload it?
[01:12] <fabbione> sparc did built it fine
[01:12] <Kamion> I'm assuming it's turned off in w-b or something, I'm not actually sure
[01:12] <fabbione> ok, don't worry
[01:12] <Kamion> I don't know if it's safe or not - it probably is, but that's an elmo question
[01:12] <fabbione> ok, i will just keep it stand-by somewhere
[01:12] <fabbione> thanks a lot
[01:13] <Kamion> it might get rejected by the C++ transition check in jennifer
[01:13] <fabbione> uh right...
[01:13] <Kamion> which isn't distribution-guarded
[01:13] <fabbione> no it's banned as c++apps in buildd.conf
[01:13] <fabbione> i forgot that kde is all c++ 
[01:14] <fabbione> or almost :)
[01:14] <fabbione> so yeah.. it can be built, but it's not since @no_auto_build is not distro aware
[01:14] <fabbione> and the filter is applied 
[01:23] <Kamion> ah, buildd.conf, ok
[01:24] <fabbione> yeah it was the simplest solution to filter apps
[01:24] <fabbione> i just forgot to look there before asking :)
[01:38] <Riddell> kdebindings doesn't want to compile
[01:39] <Riddell> it gets stuck on sipqtpart0.cpp and sits there chewing up CPU cycles forever
[01:39] <doko> Riddell: try to lower the optimization for that file
[01:42] <Riddell> doko: that did it
[01:42] <Kamion> elmo: I NEWed dbus_0.33-0ubuntu3, openh323_1.15.3-2ubuntu2, libtunepimp_0.3.0-2ubuntu7 for c2 changes
[01:42] <Riddell> not sure how to lower the optimisation other by hand though
[01:45] <doko> Riddell: please save the preprocessed file, and put it in a bug report, need the architecture and command line options as well
[02:56] <\sh> morning
[03:48] <lamont> jbailey:  g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../grove -g --pipe -O3 -ffunction-sections -D_REENTRANT -MT GroveApp.lo -MD -MP -MF .deps/GroveApp.Tpo -c GroveApp.cxx  -fPIC -DPIC -o .libs/GroveApp.o
[03:48] <lamont> /usr/include/OpenSP/RangeMap.cxx: In member function 'unsigned int OpenSP::RangeMap<From, To>::inverseMap(To, From&, OpenSP::ISet<OpenSP::WideChar>&, OpenSP::WideChar&) const':
[03:48] <lamont> /usr/include/OpenSP/RangeMap.cxx:50: error: 'wideCharMax' was not declared in this scope
[03:48] <lamont> wanna fix openjade?
[03:53] <doko> lamont: hi
[03:53] <doko> I'm looking at it
[03:54] <lamont> thansk
[03:54] <doko> lamont: kdebase needs some love, the deps are in main now
[03:56] <doko> lamont: openjade did build on all archs ...
[03:57] <lamont> that's from hppa - haven't double checked to make sure it dies on i386
[03:57] <lamont> ruby1.8. otoh is another dpkg victim
[04:00] <lamont> ruby1.8 => #11040
[04:09] <doko> it's ok, if you see the breakage, but there's silent breakage as well. hmm, maybe it's better to just revert this change until Debian switches to the new dpkg as well
[04:10] <lamont> interesting idea
[04:13] <fabbione> hey lamont
[04:15] <fabbione> lamont: it would be interesting to implement @no_auto_build per distro
[04:15] <lamont> fabbione: heh
[04:15] <fabbione> today digging in the w-b database i noticed a knetworkconf (hoary-updates) not taken for build
[04:15] <fabbione> because it's banned in breezy
[04:15] <lamont> it would also be good to to make SIGHUP re-read it
[04:16] <fabbione> hm?
[04:16] <fabbione> yeah
[04:18] <fabbione> it's too slow!
[04:18] <fabbione> doko: you must do something about it
[04:19] <lamont> doko: might be that doing a breezy-test world with dpkg changed might be the right answer.
[04:19] <doko> ifeq arch=sparc and bbuilder=fabbione, then fail. exit 0
[04:19] <doko> that's fast!
[04:19] <doko> fabbione: did I tell you that I need another 3.4?
[04:20] <fabbione> doko: i am still building gcc-3.3
[04:20] <fabbione> so i don't really care
[04:20] <fabbione> doko: did you fix that problem with libvtest thing?
[04:20] <fabbione> doko: so if you upload the new gcc-3.4 now it's ok
[04:20] <doko> well, 3.3 does have interesting libc dependencies now ...
[04:21] <fabbione> i am still building 3.3
[04:21] <fabbione> but i care more about 3.4
[04:21] <doko> fabbione: I don't know, I built it, and I don't see the failure
[04:21] <fabbione> since we build the kernel with 3.4
[04:21] <fabbione> doko: bah you suck :P
[04:21] <fabbione> i told you.. the target is not called 
[04:21] <fabbione> come on dude...
[04:21] <fabbione> you can manage :)
[04:23] <fabbione> doko: i will see if it happens again with the next build
[04:23] <fabbione> if so i will put our buildd chroot somewhere so you can look at it
[04:24] <doko> fix ruby1.8 while you're waiting ;-)
[04:24] <fabbione> doko: are you going to do cleaning in my house in the meanwhile?
[04:24] <doko> lamont: could you remove the Dep-Wait for xerces25 and xerces26?
[04:24] <lamont> doko: sorry sure
[04:25] <lamont> done
[04:25] <doko> fabbione: hmm ...
[04:26] <fabbione> doko: trust me.. you will be more happy fixing ruby1.8 too :)
[04:26] <fabbione> + i hate c++
[04:26] <fabbione> with all myself
[04:27] <\sh> jesus
[04:27] <\sh> kdelibs4c2 is in
[04:27] <lamont> \sh: that was doko et. al., not jesus
[04:27] <fabbione> doko has short hair...
[04:27] <\sh> when doko uploaded it, he's jesus ;)
[04:27] <doko> \sh, call me as you like it ;-)
[04:28] <\sh> fabbione: and? in africa, jesus has a dark skin colour
[04:28] <doko> naa, Kamion did give it some love ...
[04:28] <fabbione> doko drinks beer... jesus doesn't
[04:28] <fabbione> or didn't...
[04:28] <fabbione> depends how you want to see it :)
[04:28] <lamont> fabbione: wine, beer, what's the diff?
[04:29] <fabbione> jesus was more for wine...
[04:29] <\sh> fabbione: we can't be sure
[04:29] <\sh> jesus had something with maria magdalena
[04:29] <fabbione> lamont: beer is like so... german.. wine is more italian :)
[04:29] <lamont> well, if the books are to be believed, he was of jewish descent...
[04:29] <doko> Riddell, amu: kdebase fails ...
[04:29] <doko> kate.la.o(.text+0xe): In function `main':
[04:29] <doko> collect2: ld returned 1 exit status
[04:29] <doko> make[4] : *** [kate]  Error 1
[04:30] <\sh> the life, the universe and the rest
[04:30] <fabbione> anyway... time to go and do some cleaning
[04:30] <\sh> let me finished libchasen
[04:30] <lamont>  /build/buildd/kdebase-3.4.0/obj-i386-linux-gnu/kate/app/kate.la.cpp:2: undefined reference to `kdemain'
[04:30] <\sh> -ed
[04:30] <lamont> doko: you forgot that line
[04:31] <doko> yes, xchat did grab it
[04:31] <lamont> yeah
[04:31] <doko> fabbione: one idea ...
[04:31] <fabbione> doko: ?
[04:31] <lamont> hppa's uploader is only 86 packages behind...  sigh.
[04:31] <doko> are there dangling symlinks in /usr/lib/gcc/3.4.4/sparc*/64/
[04:32] <doko> or in  /usr/lib/gcc/3.4.4/sparc*/
[04:32] <doko> to libgcc*
[04:32] <fabbione> doko: i dunno...
[04:32] <fabbione> and i can't really check
[04:32] <doko> fabbione, look and you will see ...
[04:32] <fabbione> do you want me to look if the build fails?
[04:32] <doko> it's a small miracle ;)
[04:33] <fabbione> one moment
[04:33] <doko> hmm, no, that can't be the reason, we don't use the stage1 compiler at this point
[04:34] <doko> just found out, why gcc-3.4 -m32 is broken on amd64, jbailey could be interested ...
[04:35] <doko> lamont: could you make sure, that all the buildd's get the current state of the archive, so that I could start uploading cxxapps from main?
[04:35] <fabbione> are all libs builded?
[04:35] <fabbione> doko: you should still be sure that the apps build-dep on a proper version of the libs
[04:36] <doko> fabbione: no, in this case we have to touch all 700 cxxapps packages.
[04:36] <fabbione> doko: dude.. that will make another breezy debootstrap impossible
[04:36] <fabbione> doko: you need to change the apps to versioned build-dep
[04:37] <doko> fabbione: why will it be impossible?
[04:38] <doko> apps which get synced from Debian don't have changed build-deps either
[04:38] <fabbione> because you can build packages on top of old libs if you are not extremely carefull
[04:38] <doko> I did always think, that the hppa and sparc buildd admins are careful, but I can be wrong ;-)
[04:38] <lamont> doko: you can upload cxxapps, but they won't get built until we change @no_auto_build... :-)
[04:39] <fabbione> doko: it's not just hppa and sparc..
[04:39] <fabbione> i think not changing the build-deps is just wrong
[04:39] <doko> lamont: elmo told me that I could upload anyway
[04:39] <lamont> fabbione: they build-dep on foo-dev, which is unchanged...
[04:39] <doko> fabbione: what do you make in case of the synced apps?
[04:39] <lamont> ISTR doko saying they might just work...
[04:40] <fabbione> usr/lib/gcc/sparc-linux/3.4.4 # ls -lR
[04:40] <fabbione> no dangling symlinks
[04:40] <lamont> fabbione: it can be handled as an archive event... painful, but it works...
[04:40] <fabbione> hmmm
[04:40] <fabbione> ok
[04:41] <doko> lamont: archive event?
[04:42] <lamont> doko: what we're doing.
[04:42] <fabbione> probably i am just too much of a purist
[04:42] <lamont> draw a line, and make sure that nothing on the right side needs anything that wasn't fixed on the left side.
[04:42] <doko> fabbione: we'll get these build-deps, when Debian is doing the transition
[04:42] <fabbione> given that sparc was out of hoary thanks to gcc-4.0 unversioned build-deps....
[04:42] <lamont> note that archive events are, by definition, a royal pain in the tail for any buildd admin
[04:43] <fabbione> lamont: oh yeah.. i agree
[04:44] <fabbione> i need to go.. doko: last offer to come and clean my house in exchange of kernel upload with mISDN
[04:44] <fabbione> (our kernel is really free like in beer ;))
[04:44] <fabbione> b180?
[04:44] <fabbione> is the slowest one?
[04:44] <doko> slow hppa ...
[04:44] <lamont> 180MHz 32-bit UP hppa
[04:44] <fabbione> amen
[04:44] <lamont> well, there's only 2 of them,.
[04:45] <doko> heh, and it fails ...
[04:45] <fabbione> lamont: why don't you add it to @no_auto_build ?
[04:45] <lamont> I just did
[04:45] <fabbione> a bit too late i guess :)
[04:45] <fabbione> lamont: you can still share the ccache between the 2 buildds
[04:45] <lamont> it had never built it (since it _was_ in n-a-b), so it didn't show up when I added all the really long build-time stuff to n-a-b
[04:45] <fabbione> it will be less painful when packages hit the slow one
[04:46] <lamont> fabbione: yeah, but that's so much like work
[04:46] <lamont> and disk I/O isn't exactly the fastest here...
[04:46] <fabbione> uh why?
[04:46] <fabbione> NFS my friend
[04:46] <lamont> well, for starters, the machines are 2-switches away from each other
[04:46] <fabbione> that's what i use here to share ccache all over
[04:46] <lamont> Not a File System
[04:46] <fabbione> lamont: OCFS2 with the next kernel upload :)
[04:47] <lamont> OCFS2?
[04:47] <fabbione> Oracle Cluster Filesystem2
[04:47] <fabbione> my wife is so going to kill me if i don't go and clean
[04:47] <fabbione> http://people.ubuntu.com/~fabbione/Screenshot.png
[04:48] <doko> lamont: does openoffice.org build?
[04:48] <lamont> on hppa? no
[04:48] <fabbione> me must go now
[04:48] <fabbione> cya later
[04:48] <doko> lamont: i386 and powerpc
[04:49] <lamont> it's in the @no_auto_build list
[04:49] <lamont> so it's not going to even try anywhere
[04:49] <\sh> hmmm...
[04:50] <lamont> ommmmm
[04:50] <\sh> i was just informed, that I'm now have a new portable 160gb usb2 hd
[04:50] <\sh> it's ready to pick up
[04:50] <\sh> strange thing is, i've never ordered one
[04:51] <\sh> and I don't have to pay it
[04:51] <\sh> weired
[04:51] <doko> lamont: are you able to change the @no_auto_build lists?
[04:51] <lamont> are we ready for me to?
[04:52] <lamont> and note that when I do, it'll be 'empty the list' on each buildd as it's done... I'm not going to do it one package at a time
[04:52] <doko> lamont: all cxxapps in main but KDE. but we can enable KDE as well, it will just fail, because kdebase isn't installable.
[04:52] <doko> yes, let's wait for kdebase, then we can do it
[04:55] <lamont> openjade is an hppa-specific issue.  sihg
[04:56] <\sh> hmm
[04:56] <\sh> think i will setup an ubuntu mirror
[05:01] <doko> lamont: could you report it upstream?
[05:02] <lamont> doko: will do, although I want to investigate it a bit first...
[05:03] <doko> jbailey: just noticed that gcc-3.4 -m32 didn't work
[05:04] <\sh> doko: u reviewed some of those debdiff outputs?
[05:04] <jbailey> doko: For which arch?
[05:05] <jbailey> (I'm lagging a bit at the moment, I updated to the new X and it won't start.  I'm just poking it a bit)
[05:05] <doko> \sh, ok, will do
[05:06] <doko> jbailey: -m32 ...
[05:06] <jbailey> doko: I think it worked fine for me the other day on amd64.  It may have been sparc, though.
[05:07] <\sh> doko: i saw some u reviewed :) u r working too much i think ;)
[05:07] <doko> hmm, the 32bit libgcc symlinks are dangling links
[05:09] <jbailey> doko: I'll take a look in a moment then.  
[05:17] <Riddell> doko: I think kdebase just needs visibility turned off, checking now
[05:27] <doko> Riddell, yes, I did see this as well ... hope, that not every KDE packages has this check ...
[05:27] <jbailey> Ah, lovely.  got X again.
[05:27] <jbailey> *bounce*
[05:29] <jbailey> mps
[05:29] <Riddell> doko: compiles now, should I upload?
[05:31] <jbailey> doko: Now that I'm actually paying attention.. =)
[05:31] <jbailey> doko: I have 3 questions:
[05:31] <jbailey> 1) What was that about -m32?
[05:32] <jbailey> 2) I've confirmed that glibc builds with -g2 on ppc at least, so I'll set that for the next upload.
[05:32] <jbailey> 3) What would be good timing for me to do the i386/amd64 biarch stuff so that I don't interfere with you.
[05:33] <\sh> Riddell: that means we will have a running kdebase at least today? ,-)
[05:33] <Riddell> \sh: it means we should have a compiling kdebase 
[05:33] <Riddell> running is a different matter
[05:44] <doko> Riddell: please do
[05:45] <doko> jbailey: 1) dangling symlinks
[05:45] <doko> 2) now ;) get the 0ubuntu2, that I did upload some minutes ago
[05:45] <doko> no, this was 3) ;)
[05:46] <jbailey> Does #3 also solve #1? =)
[05:46] <doko> yes
[05:47] <jbailey> Excellent! =)
[05:47] <Riddell> doko: that file that I said didn't compile did finish after two hours.  I innocently gave up hope after 1 hour
[05:47] <jbailey> doko: Do you have brainspace for me to ask you about biarch setups and ppc64?
[05:54] <Riddell> kdebase_3.4.0-0ubuntu21_source.changes ACCEPTED
[05:56] <jbailey> fabbione: If you're bored at some point, I had asked the main Splack guy about his throughts on requiring v9 or newer for a Sparc distro.  He says that he gots alot of requests for support from classparcs.
[05:57] <jbailey> fabbione: I Don't know if that's a good reason to support them, or a good reason to run screaming. =)
[05:57] <fabbione> jbailey: the latter :)
[05:57] <fabbione> jbailey: btw xorg did build fine with your fix
[06:02] <jbailey> fabbione: Yay!
[06:02] <jbailey> fabbione: Any other crazy blockers?
[06:03] <fabbione> jbailey: not right now.. util-linux did build as well
[06:11] <doko> Riddell: anyway, having the preprocessed source would be very useful
[06:12] <doko> jbailey, yes, why not
[06:13] <Riddell> doko: it's a 9MB file
[06:13] <jbailey> doko: Right now our bi-arch configs, i386, sparc, and s390 all succesfully build a biarch setup on a 32 bit kernel.
[06:13] <Riddell> KDE bindings is a bit crazy
[06:14] <doko> Riddell: doesn't matter
[06:14] <\sh> Riddell: do u want to disable the python qt/kde bindings in kdebindings?
[06:15] <doko> yes, do they? I did assume that the buildd's for s390 and sparc are 64bit
[06:15] <jbailey> doko: From looking at the logs, it looks like ppc is trying to actually run a built ppc64 binary.  Is that something in our packaging, or is that something upstream that needs to be poked?
[06:15] <Riddell> \sh: arn't they already apart from qt-dcop?
[06:15] <fabbione> doko: nope.. sparc userland is almost all at 32bit
[06:15] <fabbione> and it doesn't matter what kernel are you running to build
[06:16] <\sh> Riddell: i don't know...they're only disabled (in the last source tree i saw) I wanted to use the normal upstream packages...
[06:17] <Riddell> \sh: "do u want to disable" "they're only disabled" which are they?
[06:17] <doko> that should be coded in gcc/config.ml (guessing if the compiler works)
[06:18] <\sh> Riddell: I saw u complaining about python-qt sip things...I just wondered if they're enabled again
[06:18] <doko> config-ml.in in the toplevel directory
[06:19] <Riddell> \sh: right.  I suspect they're compiled and then no package is made of them
[06:19] <Riddell> which is a bit silly
[06:20] <\sh> Riddell: so remove them from configure.in and makefile.am ;)
[06:20] <\sh> I will come to python-sip4-qt and kde stuff later this day 
[06:21] <\sh> patches are already there for pkde
[06:21] <Riddell> great
[06:22] <\sh> i don't like this "copy upstream packages into kdebindings"
[06:30] <jbailey> Heya Bastian.
[06:30] <waldi> hi
[06:31] <fabbione> hey waldi
[06:32] <doko> waldi: moin
[06:37] <jbailey> doko: When should we do the binutils update?
[06:41] <doko> 2.16.1 will be released next week. I didn't had a chance yet for testing on ia64 with glibc 2.3.5
[06:42] <jbailey> doko: Do you mean with the new bintuils or in general?
[06:42] <jbailey> ia64 with glibc 2.3.5 in general is working fine.
[06:42] <jbailey> I can give you access to my box with the breezy chroot if you'd like,.
[06:44] <doko> with 2.16, I see one regression in the binuitls testsuite (on unstable)
[06:44] <jbailey> Ah, drow message about releasing 2.16.1 I had missed it.  Cool.
[06:44] <doko> jbailey: no need, just build the package from experimental in this chroot
[06:44] <jbailey> doing
[07:00] <jbailey> Feh, getting false testsuite failures because it's failing to spawn and such.
[07:02] <jbailey> Lemme boot the box, there's some d-i build processes lying around probably tying up resources.
[07:03] <fabbione> doko: can i push you a clean breezy chroot somewhere, so you can test a gcc build?
[07:04] <Kamion> hm, not a good time for a debootstrap upload - aptitude needs to be rebuilt first
[07:04] <fabbione> uh?
[07:05] <Kamion> depends on libsigc++*c102
[07:05] <fabbione> Kamion: i have a diff for the buildd variant
[07:05] <fabbione> but i am waiting for the last c++ stuff to complete the transition
[07:05] <fabbione> or do you test that one too?
[07:05] <Kamion> mail it to me and I'll do it in one upload when everything else is done?
[07:06] <fabbione> Kamion: sure.. buildd isn't that important and can be done "anytime"
[07:07] <Kamion> but if you turn out to be in a hurry for it, then feel free
[07:07] <doko> fabbione: ok
[07:07] <fabbione> no no.. it's no hurry
[07:07] <Kamion> the main scripts just need unusual handling
[07:08] <doko> Kamion: mvo told me that he did test apt and aptitude on all four archs, so maybe I'll just build it
[07:15] <doko> Riddell: "Bash 3.0-14ubuntu1 hangs on amd64 after any command taking up 99% CPU cycles", I cannot reproduce this behaviour, the testsuite looks ok  as well
[07:16] <Riddell> doko: hmm, it's definatly very reproducable on amu's machine
[07:16] <Riddell> doko: old chroot and fresh one
[07:17] <doko> lamont: ^^^ maybe do not update the buildd's while we are working this out
[07:38] <fabbione> oh great
[07:38] <fabbione> doko: gcc-3.3 fails too
[07:38] <fabbione> mv debian/tmp/usr/lib64/lib*c++*.{a,so} debian/tmp/usr/lib/gcc-lib/sparc-linux-gnu/3.
[07:38] <fabbione> 3.6/64/.
[07:39] <fabbione> mv: when moving multiple files, last argument must be a directory
[07:39] <fabbione> Try `mv --help' for more information.
[07:39] <fabbione> make[1] : *** [stamps/08-binary-stamp-libstdcxx-dev]  Error 1
[07:39] <fabbione> btw.. it did start building gcc-3.4
[07:39] <fabbione> should i stop it?
[07:42] <fabbione> this is weird
[07:42] <fabbione> gcc-3.3 did create the debs and failed?
[07:44] <fabbione> oh yeah.. it was building the debs when it failed
[07:44] <doko> hmm, why is the target directory not present ... strange
[07:45] <fabbione> doko: i have almost done with the chroot :)
[07:57] <jbailey> Mmm.  It's not harmful to have packages in debian/control that are never built, is it?
[07:59] <fabbione> jbailey: given that you don't create the deb...
[07:59] <lamont> jbailey: not unless they ever were built
[07:59] <lamont> I think...
[07:59] <lamont> anyway, really running off now
[08:00] <fabbione> later lamont
[08:00] <jbailey> 'bye lamont
[08:00] <jbailey> 'k thanks.
[08:01] <doko> jbailey: no, that's ok
[08:02] <jbailey> I'm trying to reduce what I have to do to enable ppc64 in my build. =)
[08:04] <doko> debian/rules.defs: look for biarch
[08:05] <jbailey> Sorry, still on glibc.
[08:05] <doko> ;)
[08:12] <fabbione> guys when do you think i can start working on a ppc64 kernel?
[08:12] <fabbione> to do that i need the toolchain in place
[08:12] <fabbione> and breezy-ppc64 chroot is borked afaik
[08:12] <daniels> night folks
[08:13] <fabbione> configure: WARNING: I have to compile Test.class from scratch
[08:13] <fabbione> checking if java works... configure: error: The Java VM java failed (see config.log, 
[08:13] <fabbione> check the CLASSPATH?)
[08:13] <fabbione> db4.2 
[08:13] <fabbione> night kid
[08:14] <fabbione> ../dist/configure: line 21554: 28092 Bus error               $JAVA $JAVAFLAGS $TEST
[08:14] <fabbione> interesting :)
[08:14] <jbailey> g'n Daniel.
[08:15] <jbailey> fabbione: The ppc64 toolchain is blocked on the fact that it wants a ppc64 kernel to build.
[08:15] <jbailey> I'm trying to convince it otherwise.
[08:24] <jbailey> doko: Was it an ld failure?
[08:25] <jbailey> I see on unepxcted, but schwab posting something to the binutils list that I Can try.
[08:25] <jbailey> http://sourceware.org/ml/binutils/2005-05/msg00601.html
[08:28] <doko> jbailey: yes, that's the regression I did see
[09:33] <doko> ok, submitted #11050 for the dpkg behaviour
[09:44] <doko> lamont: where can I find the icu build? it's marked as uploaded, but not installed
[09:52] <jbailey> Wow.  The binutils patch system *doesn't fail* if a patch fails to apply.
[09:53] <doko> could be dpkg-breakage? ;-) sorry, couldn't resist
[09:54] <jbailey> If only/  I confirmed it with debian/rules patch =(
[09:54] <jbailey> So doing the ia64 test.
[09:54] <jbailey> +re
[09:55] <jbailey> I'm leaving in a moment, too, so I'll let you know how it goes later.
[09:55] <jbailey> I'm also building a ppc64 glibc.
[09:55] <elmo> jbailey: err, it so does?
[09:57] <jbailey> It didn't for me.  A lovely bit in debian/patched/123_ldwhatever_I_called it
[09:58] <jbailey> that nicely logged that the patch hadn't applied.
[09:58] <jbailey> And it merrily carried on.
[09:58] <jbailey> Anyhow, Angie's poking me to go, back in a few hours.
[10:00] <elmo> well, new dpatch might not, but new dpatch grew crackful maintainers :(
[10:05] <doko> elmo: packages from cxxapps cannot be built, even if I upload them signed with my key?
[10:10] <elmo> doko: I didn't restrict building of apps, that's lamont
[10:10] <elmo> I only restricted source uploads
[10:11] <elmo> well, you CERTAINLY can't upload binaries, signed by your key
[10:11] <doko> ;)
[10:12] <doko> where's icu currently stuck, is it buildd or new?
[10:12] <elmo>        icu | 2.1-2ubuntu1 | breezy/universe | source, amd64, ia64, powerpc
[10:13] <elmo> REJECT
[10:13] <elmo> Rejected: icu-doc_2.1-2ubuntu1_all.deb: old version (2.8-4) in breezy >= new version (2.1-2ubuntu1) targeted at breezy.
[10:13] <elmo> Rejected: icu-doc_2.1-2ubuntu1_all.deb: old version (2.8-4) in hoary >= new version (2.1-2ubuntu1) targeted at breezy.
[10:15] <doko> hmm, where can I see this?
[10:15] <elmo> you can't
[10:16] <elmo> the queue/REPORT stuff is not visible because it contains security uploads too
[10:16] <elmo> kamion/mdz can see it.  and lamont gets the REJECT mails
[10:17] <doko> hmm, well, something we should talk about
[10:18] <doko> anything else rejected from the cxx stuff?
[10:18] <elmo> I've no idea, I'm not trawling through all the possible rejects :P
[10:19] <elmo> as I said, the buildd admin gets the emails ...