[08:40] <tfheen> BenC: linux-source ftbfs on all arches.
[12:48] <infinity> BenC: ping... poke me when you're around.
[02:12] <BenC> infinity: blah
[02:13] <infinity> BenC: Waking up?
[02:13] <BenC> wow
[02:14] <infinity> BenC: A few linux-libc-dev related ones, which I'm trying to sort whose fault they are.
[02:14] <pitti> hi
[02:14] <infinity> BenC: pitti's got one for you, and then I'll take my turn. :)
[02:15] <BenC> well all of l-s-2.6.17 failed too, so I'm checking that as well :)
[02:15] <infinity> Yeah, but if another upload's required, we may as well wait and see if the headers need fixing first. :)
[02:20] <infinity> BenC: Ping me when you're done pondering pitti's bug.
[02:21] <BenC> ok, I'm working on that one now
[02:21] <pitti> BenC: you agree that unaligned.h is legitimate for userspace?
[02:22] <BenC> pitti: Not sure yet
[02:23] <BenC> pitti: I'm going to have to say no
[02:24] <fabbione> hey Ben
[02:24] <fabbione> BenC: i assigned a few FTBFS to you since they involve mixture of kernel and userland headers (during a mass filing)
[02:24] <fabbione> BenC: if it's a big time issue for you to work on them, i am sure pitti will love to help you :)
[02:24] <pitti> BenC: ok; any idea how programs can do an unaligned read/write in a platform independent manner?
[02:25] <BenC> pitti: main reason is that sparc64 uses asm-generic/unaligned.h and that can't be in userspace
[02:25] <BenC> pitti: Are there programs other than reiserfsprogs that try to do this?
[02:25] <pitti> BenC: not to my knowledge, but I can't really say
[02:25] <pitti> BenC: we have to check the other FTBFSes
[02:26] <BenC> pitti: Isn't there some gcc or glibc defined way of doing this already?
[02:27] <BenC> I mean, if it's such a common thing, I would think that there is a more "official" method
[02:27] <pitti> BenC: (making a clueless face)
[02:28] <infinity> Amazingly, I can picture that face.
[02:30] <BenC> pitti: From what I can tell, accessing unaligned data is not a problem, and get_unaligned/put_unaligned is only important for some architectures to improve performance a bit
[02:31] <BenC> and from what I can tell, that's only the case for sparc64 for us
[02:31] <BenC> the other arch's, the macros are pretty much (foo) and (foo = bar)
[02:31] <pitti> BenC: it's definitively not a problem on x86/amd64, but I wasn't sure whether some arches would spill SIGBUSes for that
[02:32] <pitti> BenC: and on sparc64? will it work, just slowly? or sigbus?
[02:36] <infinity> I could just remove reiserfsprogs from the archive and solve the problem that way.
[02:36] <infinity> :P
[02:39] <BenC> pitti: It should not...come to think of it, using asm-* in userspace is pointless for a few reasons, but mainly because it says nothing about the actual cpu you are running on
[02:40] <BenC> ppc -> ppc64, sparc ->sparc64, i386 -> x86_64
[02:40] <pitti> ok
[02:40] <pitti> BenC: ok, I'll fix that the naive way then; thank you!
[02:40] <pitti> (bug updated and rejected for l-s-2.6.17
[02:40] <pitti> )
[02:40] <BenC> pitti: I would just copy the macros from i386 unaligned.h and plug those in instead of the asm/unaligned.h include
[02:41] <pitti> yeah, I did something similar
[02:41] <pitti> the code already had such a fallback for powerpc
[02:41] <pitti> I just made that non-ppc-specific
[02:41] <infinity> BenC: My turn? :)
[02:41] <BenC> shoot :)
[02:42] <infinity> http://librarian.launchpad.net/4822044/buildlog_ubuntu-edgy-i386.directfb_0.9.24-4ubuntu2_FAILEDTOBUILD.txt.gz
[02:42] <infinity> Now, I'm not entirely sure how this could possibly build WITHOUT agpgart.h, so I'm curious if you need to mangle agpgart.h to be userspace-friendly, or if I should be pulling all the symbols from agpgart.h into directfb (ugh)
[02:48] <BenC> infinity: icky...that just looks like newer agp API
[02:49] <infinity> BenC: Any urge to take this one off my hands and make it build on amd64/i386?  I got it building on all other arches (yes, the package had at least 4 different FTBFS bugs)
[02:49] <BenC> infinity: I can give it a go
[02:49] <infinity> BenC: Once I start diving into kernel/userspace separation, I get a bit hazy as to whose bug is whose (kernel, headers, app)
[02:50] <BenC> infinity: This is basically a "directfb is too old" bug
[02:51] <infinity> That doesn't shock.  The bitrot can't be too bad, though. :/
[06:17] <nixternal> [17180132.352000]  APIC error on CPU0: 01(01)
[06:18] <nixternal> ever since tuesday, i switched to the -generic kernel, and now i get those
[06:18] <nixternal> i had this with the k7 kernel previously, and when i went back to the 386 kernel, the problem went away
[06:28] <BenC> nixternal: Try booting with noapic
[06:29] <nixternal> it won't
[06:29] <BenC> nixternal: Then I suggest for now sticking with the -386 kernel
[06:29] <nixternal> hehe, i am ;)
[06:29] <BenC> nixternal: File a bug and attach dmesg (or digital photo) of the problem boot without "quiet splash"
[06:30] <nixternal> just wanted to know if anyone knew of this..i didn't even see a bug for it..so i am filing one...also, you research the error on google, they say defective hardware, which i doubt that is the issue
[06:30] <BenC> a little info on your hardware too
[06:30] <nixternal> no problem
[06:30] <BenC> nixternal: I don't doubt that it could be buggy or defective hardware, but it could be something that can be worked around
[06:31] <nixternal> it is top knotch stuff here ;)
[06:31] <nixternal> however, im pointing towards memory if it is an issue though
[06:31] <nixternal> i think i noticed it with a 1gb stick installation
[06:32] <nixternal> first
[06:40] <BenC> nixternal: New doesn't mean "not broken" :)
[06:41] <BenC> nixternal: You may want to check on a BIOS update as well
[06:44] <nixternal> hehe, believe me i know. this is a kt333 mobo, i think they stopped with bios hacks years back...need to find out if there are any custom ones out there though
[06:53] <nixternal> BenC: the noapic option actually didn't lock the machine up like it had before. and it seems to have fixed something else i had an issue with on startx kicking in kdm in automatically, don't know if htey are tied in, but thats my story and im sticking to it
[06:54] <nixternal> however,t he error is still there ;(
[08:17] <tfheen> zul: hmm, you said that xen git was up-to-date now?
[08:17] <tfheen> zul: is that the git://dev.laptop.org/projects/ubuntu-xen repo or some other?
[08:29] <zul> ubuntu-xen-2.6.17
[08:30] <tfheen> cloning now.
[08:31] <tfheen> any idea when we'll have working xrm?
[08:31] <zul> when the headers are fixed again
[08:31] <tfheen> any idea when that happens? :-P
[08:31] <zul> this weekend probably :)
[08:31] <tfheen> ok