[12:16] <jbailey> doko: Sent off another lkh, should fix both mysql and libgii
[12:17] <doko> so libgii was a lkh thing?
[12:17] <jbailey> yeah, the upstream included a define that only exists in 2.4 kernels and earlier.
[12:18] <jbailey> Given that the case is a noop, I'm surprised to see it in mysql, but ah well.  It's not supposed to be in the 2.6 header.
[12:21] <lamont> doko: done
[12:22] <lamont> Kamion: yeah - in the report, they show up... I think those particular ones probably want to get removed from the archive
[12:25] <doko> lamont: yes, too early, the 2nd pike upload didn't build yet
[12:32] <doko> enchant did build, so abiword can be retried
[12:41] <lamont> kicked
[12:41] <lamont> doko: you are waiting for the cron.daily run after the builds finish before saying anything, yes?
[12:42] <doko> hmm, I don't do idle waiting ... so from time to time I refresh your web page. that's ok
[12:43] <lamont> gii now d-w lkh
[12:43] <lamont> jbailey: thanks
[12:43] <lamont> was it mysql-dfsg, or the universe package?
[12:43] <doko> the former
[12:44] <lamont> only have a failure log on ia64 - d-w'd
[12:44] <doko> yes, the other archs did succeed
[12:44] <lamont> kewl.
[12:44] <lamont> anything else before I run off again for a while?
[12:45] <jbailey> Not from me, I think.
[12:48] <lamont> back in 2-3 or so then
[12:48] <lamont> closer to 2 than 3, I think
[01:15] <doko> Kamion: could you check out, why unixodbc's build-deps cannot be fulfilled on powerpc?
[01:16] <Kamion> doko: it's hard for me to check anything in breezy on my own system because of that bash bug :P
[01:17] <doko> ouch!
[01:17] <Kamion> but http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html agrees
[01:17] <doko> yes, first thing I do tomorrow morning
[01:17] <Kamion> thanks :)
[01:18] <Kamion> it looks like gnome-libs is out of sync on powerpc
[01:18] <doko> yes, I read this list, but even the build logs aren't very helpful
[01:18] <Kamion> libgnome32 |   1.4.2-19 |        breezy | powerpc
[01:18] <Kamion> libgnome32 |   1.4.2-20 |        breezy | amd64, hppa, i386, ia64, sparc
[01:18] <Kamion> and gnome-libs FTBFS/powerpc
[01:19] <Kamion> looks like a missing imlib include?
[01:22] <doko> worse: libpng error: Call to NULL read function
[01:23] <doko> hmm, libpng was the cause for xorg build failures on powerpc as well
[01:50] <jbailey> daniels: Hmm, on the upgrade to the latest X bits, dexconf or whatever it's called now doesn't appear to write the mouse stuff to the xorg.conf file.
[02:00] <doko> jbailey, libgii and mysql-dfsg did fail
[02:00] <jbailey> chroots weren't updated with the new lkh
[02:00] <doko> lamont: after libpng did build and install on powerpc, please build gnome-libs on powerpc
[02:03] <lamont> ../sigcperl/convert.h:71: error: explicit qualification in declaration of `std::string SigCPerl::get_string(SV*)'
[02:03] <lamont> bad sigcperl
[02:03] <lamont> ../include/linux/i2o-dev.h:51: error: variable or field '__user' declared void
[02:03] <lamont> bad raidutils
[02:04] <lamont> ../llapi/vector2d.h:120: error: 'cerr' was not declared in this scope
[02:04] <lamont> bad panorama
[02:17] <lamont> pension board meeting - back in about an hour
[02:31] <daniels> jbailey: yeah, the mouse stuff is screwed
[02:31] <daniels> jbailey: that's -21 material
[02:33] <doko> daniels: congrats! -20 did build on all archs ;-)
[02:33] <daniels> fabbione: eh, branden isn't doing any of the xorg work
[02:34] <daniels> fabbione: gravity and I are doing xorg monolithic stuff ... he's so far caught one mistake and done a bit of syncing from Debian
[02:34] <daniels> fabbione: joshtriplett and I are working on the modular tree and we're hoping to have the same packages
[02:35] <daniels> doko: yeah, I noticed ... finally
[02:36] <zul> gday
[02:37] <doko> and xbase-clients seems to be built correctly
[02:38] <doko> daniels: could you have a look at xscreensaver? the changes were necessary when I built the package, but they do fail on the buildd.
[02:39] <daniels> ok
[03:09] <jbailey> daniels: That and the path being not where startx is located now. =)
[03:11] <daniels> jbailey: serves you right for not having /usr/X11R6/bin in your path :P
[03:11] <daniels> i think i'm just going to dump everything in /usr/bin with the next upload
[03:11] <daniels> being that /usr/bin/X11 is a REALLY BAD IDEA
[03:12] <jbailey> I thought the plan was to move everything to /usr/bin ages ago.
[03:18] <daniels> right, but moving it within the monolith is PAIN
[03:18] <daniels> so I'm just making all the new modules use it
[03:19] <daniels> i'm seriously considering moving everything and xbase-clients and xutils with dh_install though
[03:22] <Kamion> doesn't that break some third-party code using imake?
[03:23] <Kamion> (due to stuff not being in ProjectRoot where they expect it)
[03:31] <daniels> that's the tricky part I have to work out
[04:14] <jbailey> Hmm, libgii seems to be an X casualty this time.
[04:15] <daniels> \o/
[04:15] <daniels> does it need to build soon?
[04:16] <daniels> if it doesn't need to build in the next few days, just wait for it to start building again
[04:16] <jbailey> It's an rdepends for anything libggi based that needs to make the g++ transition.
[04:16] <jbailey> I don't know how importnat that makes it.
[04:18] <daniels> main or universe?
[04:18] <jbailey> main
[04:18] <daniels> hum
[04:19] <jbailey> Given that I'm heading to bed soon, I don't actually care that much for any value that you might consider to mean "today"
[04:20] <daniels> heh :)
[04:20] <jbailey> doko punted it to me since the first failure was a linux-kernel-headers one, lamont punted it back when it failed to build the package right because of a missing binary.
[04:22] <daniels> heh :)
[04:34] <lamont> was someone fixing gstreamer0.8?  fabbione ?
[04:41] <jbailey> It wasn't punted to me.
[04:41] <lamont> cothreads.c:654: error: invalid lvalue in assignment
[04:41] <lamont> was sparc ftbfs, iirc... --> fabbione 
[06:22] <fabbione> daniels: xorg -20 is FTBFS on sparc
[06:22] <fabbione> ConnDis.c:38:23: error: X11/Xauth.h: No such file or directory
[06:22] <fabbione> around 1.5MB in the build log
[06:24] <daniels> uhm, sure you've got libxau-dev installed?
[06:24] <daniels> because that should be in /usr/include/X11/Xauth.h
[06:24] <daniels> (and a recent libxau-dev?  doko uploaded a fixed -2)
[06:25] <fabbione> checking...
[06:26] <fabbione> well libxau-dev should be a build-dep
[06:26] <daniels> it is
[06:26] <fabbione> Unpacking libxau-dev (from .../libxau-dev_6.8.2-16_sparc.deb) ...
[06:26] <daniels> that's why it worked on amd64/i386/powerpc
[06:27] <daniels> hmmmm.  if it doesn't work with that, I guess I'll have to tighten the build-dep. :\
[06:27] <fabbione> i think it needs the new splitted one, doesn't it?
[06:27] <daniels> in the meantime, build libxau 1:0.1.2-2 and make sure that gets used
[06:27] <fabbione> yeah ok
[06:27] <daniels> yeah, so I'll tighten it up for -21
[06:27] <fabbione> but please tight the dependencies for the next upload
[06:27] <daniels> will do
[06:28] <fabbione> it's not too much of a problem for me
[06:28] <fabbione> but a new breezy re-build-strap would fail
[07:36] <fabbione> doko: please pull http://people.ubuntu.com/~fabbione/binary-gcc.mk into gcc-3.4 debian/rules.d/
[07:37] <fabbione> it fixes biarch install (dh_link) target
[07:37] <fabbione> there are a couple of \ missing ;)
[11:10] <fabbione> does anybody mind if i spin up concordia a bit?
[11:46] <doko> good morning
[11:48] <\sh> hey doko
[11:48] <ajmitch> hi doko 
[02:04] <jbailey> daniels: When I added /usr/X11R6/bin back to my path, it seems that /usr/X11R6/lib/X11/xinit/xserverrc referes to a non-existant /usr/bin/X11/X
[02:22] <daniels> jbailey: ROCK
[02:24] <Kamion> killing /usr/bin/X11/ this way seems pretty painful, considering that it seems that current Debian policy was written with an eye to *using* /usr/bin/X11/ as part of the migration path away from /usr/X11R6/ ...
[02:25] <fabbione> Kamion: that part of the policy was written by Branden iirc and he said: "If you kill *X11* we will change policy.. i wrote it :D"
[02:26] <Kamion> yeah, I know Branden wrote it, but using /usr/bin/X11/ to help the transition rather than hindered it seemed like a design feature to me at the time
[02:26] <Kamion> and still does, fwiw
[02:26] <Kamion> s/hindered/hinder/
[02:27] <jbailey> Well, policy is a reflection of current best practice.  If X changes what it does, by definition best practice has changed.
[02:28] <Kamion> I was kind of hoping that eventually we'd have /usr/bin/X11 -> /usr/bin
[02:29] <Kamion> so as not to screw over people with hardcoded paths in local config
[02:29] <Kamion> or, y'know, things like ssh
[02:30] <Kamion> which hardcodes /usr/bin/X11/xauth because that was the path that was supposed to keep working
[02:30] <fabbione> Kamion: yup... make sense
[02:31] <daniels> eh, /usr/bin/X11 isn't going away
[02:31] <daniels> the plan is to move everything to /usr/bin and make /usr/bin/X11 a symlink to /usr/bin
[02:31] <daniels> but there are only so many hours in my day, y'know?
[02:32] <Kamion> oh, ok, that's exactly the opposite impression to the one I'd got
[02:32] <daniels> dude, I don't hate /usr/bin/X11 any more than I hate /usr/X11R6
[02:32] <Kamion> you told me in #1685 that /usr/bin/X11/xauth was bad
[02:33] <daniels> i told you in #1685 that a hardcoded path in general was probably bad, yes
[02:33] <daniels> i have no intention of killing it off completely
[02:33] <Kamion> ah
[02:33] <daniels> i just don't want to put binaries in there
[02:33] <Kamion> I hadn't realised that, ok
[02:33] <daniels> bbiab
[03:55] <doko> lamont: 4.0 did sucessfully build on hppa/unstable
[03:56] <lamont> doko: which kernel?
[03:57] <lamont> or do you mean on the buildd?
[03:57] <doko> Linux pampa 2.6.8.1-pa11 #1 SMP Fri Sep 10 10:40:02 MDT 2004 parisc64 GNU/Linux
[03:57] <doko> no, my machine
[03:57] <lamont> wow.  that's with the test suite off?  because 2.6.8.1 has lots of issues with the test suite... 
[03:57] <doko> no, on
[03:58] <lamont> hrm.. maybe it was everything else that it had issues with...
[03:58] <doko> I'll restart it on breezy
[03:59] <lamont> and off to run to town. sigh
[04:00] <doko> wait, kdelibs for i386?
[04:00] <doko> lamont: ^^^
[04:02] <lamont> daniels needs to upload -21 and quit claiming to build xlibmesa-gl*-dev, then they'll not be in the archive, and kdelibs will build
[04:03] <lamont> alternatively, reversing the order of the build-deps will fix it, but they need to be in the other order for debian...
[04:06] <doko> hmm, talking with riddell
[04:07] <Riddell> what's up?
[04:13] <doko> lamont: no, kdelibs doesn't deal with xlibmesa-gl*-dev, the last qt upload did fix that, and kdelibs should be retried
[05:47] <daniels> lamont: ?!?!??!?!?!??!
[05:47] <daniels> lamont: nothing ever happened to xlibmesa-gl-dev
[05:52] <daniels> lamont: by the way, I could stop building xlibmesa-gl-dev, but seriously it wouldn't do you any good
[05:53] <jbailey> daniels: Another upload then sleep? =)
[05:54] <daniels> no.  just sleep.
[06:36] <\sh> xorg is against gcc4 now? doesn't look like
[06:42] <jbailey> fabbione: You there?
[06:42] <fabbione> jbailey: i am very close to go and cook dinner...
[06:42] <fabbione> i am hungry to deaht
[06:42] <fabbione> death
[06:43] <jbailey> fabbione: No worries.  Just I did some research on Xen this morning.  I can babble about it another time.
[06:43] <fabbione> jbailey: ok.. btw i solved a big problem with latency
[06:43] <fabbione> for some reasons my eth0 on the gw was like adding 800ms to the next eth hop :)
[06:44] <fabbione> ifdown / ifup solved :))
[06:44] <jbailey> Err. duplexing?
[06:44] <fabbione> nope
[06:44] <fabbione> it started all of a sudden
[06:44] <fabbione> it's connected to a proper swtich
[06:44] <fabbione> 100Mb FD
[06:44] <fabbione> it's the first time it does something like that
[06:44] <fabbione> anyway dinner...
[06:45] <jbailey> enjoy!
[06:45] <fabbione> i will pass by later
[06:45] <fabbione> so you can tell me about xen
[06:46] <fabbione> thanks
[06:46] <jbailey> 20 packets transmitted, 15 received, 25% packet loss, time 19189ms
[06:46] <jbailey> rtt min/avg/max/mdev = 754.573/1149.822/1433.117/166.396 ms, pipe 2
[06:46] <fabbione> doko: btw.. did you pull in the fix for gcc-3.4?
[06:46] <jbailey> That's to your router for me. =)
[06:46] <fabbione> jbailey: can you check where you actually lose packets?
[06:46] <fabbione> mrt/traceroute...
[06:47] <jbailey> Weird, I dind't have traceroute installed.
[06:47] <doko> fabbione: no, jbailey will do the next 3.4 upload
[06:48] <jbailey> fabbione: In which case, the dh_link \'s are already in my tree. =)
[06:49] <fabbione> doko: ok
[06:49] <fabbione> jbailey: thanks :)
[06:49] <fabbione> doko: btw.. it did build fine this time :)
[06:49] <fabbione> no probs with livtest
[06:50] <doko> heh, nice
[07:09] <fabbione> jbailey: so.. want to tell me that stuff about xen?
[07:09] <jbailey> fabbione: It appears that Xen may run under NPTL these days, but really suckily.
[07:10] <jbailey> I haven't got an answer yet on my questions, but there's a patch to glibc that should be it generally be better.
[07:10] <fabbione> jbailey: ah ok.. right now i am slightly more worried of xen not even being able to mount my root partition :)
[07:10] <fabbione> i need to do another test next weekend
[07:10] <fabbione> got 2.0.6 ready on my server
[07:10] <fabbione> with 2.4.30
[07:10] <fabbione> (can't run 2.6 there yet)
[07:11] <jbailey> fabbione: Right.  I've been hesitant about Xen if we'd wind up having to drop support for it.
[07:11] <fabbione> jbailey: i know smurfix and Mith are looking at other options too
[07:11] <fabbione> like L4+afterburner
[07:11] <fabbione> that appears to be much more portable and way less intrusive than xen
[07:12] <jbailey> Hah, it would be funny if L4 were useful in the Linux world.
[07:12] <fabbione> jbailey: well they run linux at the moment
[07:12] <fabbione> on top of debian
[07:12] <fabbione> that's their devel platform
[07:12] <jbailey> Oh?  Interesting.
[07:12] <fabbione> that's also why Benno was at UdU
[07:12] <jbailey> I only know L4 from my Hurd exposure.
[07:13] <fabbione> Mith and I were at the University there to see a demo
[07:13] <jbailey> Hmm, wish I had knowm about it
[07:13] <fabbione> and it was afterburner + xen/l4
[07:13] <fabbione> it was nice.. 
[07:13] <jbailey> Ah well. =)
[07:13] <fabbione> i mean.. it worked :)
[07:13] <fabbione> but after that they disappeared
[07:14] <fabbione> the userland wasn't ready yet
[07:14] <fabbione> so that's probably why
[07:14] <jbailey> 'l4 afterburner' is apparently not a useful thing to google for.
[07:14] <fabbione> jbailey: afterburner is not very well known at the moment
[07:15] <fabbione> the code has been kept private for a while
[07:15] <fabbione> but they were sorting the last license bits to go public
[07:15] <jbailey> Can you tell me where I could look to find info on it?
[07:15] <fabbione> Mith has all the URL's
[07:15] <fabbione> i don't have them handy.. sorry
[07:16] <jbailey> Tx, I'll poke him later.
[07:16] <jbailey> It's not critical, I was just looking at the Breezy tasks this morning and figured I'd look into the glibc on Xen issues a bit.
[07:17] <fabbione> yeah but i suggest to wait to push patches around
[07:17] <fabbione> specially if we are not sure we can commit to support it
[07:19] <jbailey> Well, my i386 asm isn't good enough to understand the implications of the patch.
[07:19] <jbailey> So I would need help anyway.
[07:22] <fabbione> ehhe neither is mine
[07:22] <jbailey> hey doko.. =)
[07:23] <doko> hi
[07:23] <jbailey> Sprechen ze i386-asm? =)
[07:27] <\sh> s/ze/Sie/
[07:27] <\sh> ;)
[07:29] <jbailey> \sh: Thanks.  My german is limited to asking if something is vegan.  Ordering by number off a menu.  Asking for Redwine or apple juice.  Looking at someone pleadingly and saying "Haut ban hof?" and telling them that I just shit my pants.
[07:29] <\sh> hahaha :)
[07:30] <\sh> jbailey: but in the deepest german slang you say: Sprechen'se <insert your fav language here>
[07:31] <\sh> jbailey: so u were very close to become an originating NRW inhabitant :)
[07:34] <doko> jbailey, no assembler ...
[07:36] <\sh> lda $0a
[07:36] <\sh> sta $d020
[07:36] <\sh> the last bit of assembler i remember ;)
[09:34] <doko> fabbione, lamont: is 3.4.4 built on hppa and sparc?
[10:01] <desrt> doko; with a few hickups, it looks like linux-2.6.12-rc5 is buildable with my gcc-4 cross-compiler
[10:02] <jbailey> Wow, I didn't know the kernel was gcc-4 safe.
[10:03] <desrt> jbailey: only very recently
[10:04] <desrt> and not entirely... some drivers are still broken
[10:05] <doko> desrt: nice
[10:08] <desrt> the ubuntu kernel config is the ideal stress-test platform :)
[10:10] <jbailey> I can't see Fabio diving at the chance to run an experimental kernel in breezy.
[10:16] <desrt> 2.6.12 should be soon
[10:16] <lamont> doko: 3.4.4 of what?
[10:17] <lamont>  gcc-3.4_3.4.4-0ubuntu3 fails on hppa
[10:20] <doko> ahh, ok
[10:23] <lamont>  ../include/linux/byteorder/swab.h:131: error: parse error before '__fswab16'
[10:23] <lamont> is that a lkh thing, I wonder???
[10:25] <lamont> configure: Using /var/lib/gstreamer/0.8 as registry cache dir
[10:25] <lamont> configure: WARNING: Sissy ! By asking to not build the tests known to fail, you hereby waive your right to customer support.  If you do not agree with this EULA, please press Ctrl-C before the next line is printed.  By allowing the next line to be printed, you expressly acknowledge your acceptance of this EULA.
[10:25] <lamont> checking for valgrind > 2.1... checking for sigaction... yes
[10:25] <lamont> bad gstreamer0.8
[10:26] <lamont> doko: actually, gcc-{3.3,3.4,4.0} are all ftbfs in their last hppa attempt
[10:26] <lamont> (all retrying now, just for giggles)
[10:27] <lamont> anyway, off again for a while
[10:29] <jbailey> lamont: Possibly.  Why are they using linux/byteorder instead of the glibc functions for that?
[10:30] <jbailey> byteswap.h is a far better choice, I think.
[10:31] <lamont> dunno... palo_1.8 on hppa, fwiw
[10:33] <lamont> one more massive giveback executed
[10:33] <jbailey> I'll take a look at palo in my chroot on bdale's machine.
[10:33] <jbailey> Might submit a patch for palo isntead, though.
[10:34] <lamont> kewlness
[10:34] <lamont> that'd be fine
[10:34] <lamont> (remember it was written by a kernel hacker.... so the line may be a bit more blurred than it should...)
[11:43] <desrt> desrt@gorecki:~$ uname -a; cat /etc/issue
[11:43] <desrt> Linux gorecki.cas.mcmaster.ca 2.6.12-rc5 #1 SMP Wed May 25 17:34:15 EDT 2005 ppc64 GNU/Linux
[11:43] <desrt> Ubuntu 5.10 "Breezy Badger" Development Branch \n \l
[11:43] <doko> heh ;)
[11:44] <desrt> there's this file in /proc that when you write to it it causes a kernel oops... other than that everything seems ok
[11:44] <desrt> (/etc/init.d/networking writes to this file)