[01:55] <Daviey> soren: late reply - getting verbose information 10 times per second aint helpful :)
[01:55] <Daviey> Bug 256767
[01:56] <Daviey> Bug #256767
[01:56] <Daviey> fail
[03:36] <andresmujica> hi!
[03:36] <andresmujica> is it possible if someone can check this bug? https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/290506
[10:57] <NCommander> amitk, ping
[10:58] <amitk> NCommander: hiya
[11:36] <Kano> hi, is there a 2.6.28 test git somewhere?
[11:48] <amitk> Kano: git://kernel.ubuntu.com/rtg/ubuntu-next
[11:48] <Kano> ah, this is already 2.6.28?
[11:48] <Kano> 2 month old git?
[11:48] <amitk> Kano: according to rtg's post it was supposed to be
[11:48] <Kano> well from shortlot it is 2.6.27-1.2
[11:50] <amitk> huh.. looks like he did the work, sent email to the mailing list but forgot to push it out
[11:50] <Kano> funny
[11:51] <amitk> Kano: actually it is from 5 days ago
[11:51] <amitk> so he seems to have pushed it out
[11:51] <amitk> only the tags are missing
[11:52] <amitk> http://kernel.ubuntu.com/git?p=rtg/ubuntu-next/.git;a=shortlog;pg=1
[11:52] <amitk> look for Linus' commits
[11:52] <Kano> ah rtg next
[11:53] <Kano> will check it out
[12:15] <Kano> amitk: well it does not seem to compile also it tries to create still a 2.6.27 package
[15:05] <zul> uh...include/asm-x86/ has been moved in 2.6.28?
[15:10] <mjg59> Yes, arch/x86/include
[15:41] <Kano> zul: does the new git repo compile for you?
[15:42] <zul> Kano: i havent tried
[16:56] <NCommander> amitk, you told me once why it would be a bad idea to have something, say, the rt kernel patchset (as an example) build out of the linux-ports source package via binary-custom.d, what was the reasoning behind that?
[16:57] <amitk> NCommander: i don't recall that conversation
[16:57] <NCommander> oh
[16:58]  * NCommander would like to be able to generate linux-ports-rt out of a single source package via the binary-custom mechanism, but if its a bad idea ...
[17:49] <BenC> NCommander: because if the patch starts failing to apply, it holds up the entire source
[17:50] <BenC> NCommander: we ran into that before, and that's why we took those patchsets out of the main tree
[17:50] <NCommander> BenC, that's only a problem if the tree is constantly rebasing
[17:50] <BenC> NCommander: not true...any patch has the potential to cause the rt patchset to get rejects
[17:51] <BenC> especially with something like -rt, which touches hundreds of source files
[17:51] <BenC> even drivers
[17:51] <NCommander> right
[17:51] <NCommander> Or TuxOnIce
[17:51] <NCommander> The current solution however isn't what I call pretty w.r.t. to the way linux-rt works
[17:52] <NCommander> This is one of those catch-22 scenarios
[17:52] <BenC> NCommander: the current scenario puts the blame and responsibility directly on the person who wants to maintain the patchset
[17:52] <BenC> which is exactly how it should be
[17:53] <NCommander> makes sense
[19:12] <StOrM_NW> any recommendations where can i find some information about how to debug an own kernel module?
[19:13] <StOrM_NW> i m getting kernel panic with an old own module that i tried to port to the ubuntu kernel 2.6.27-7
[23:30] <marlock> hi
[23:31] <marlock> i did recompile a vanilla kernel
[23:31] <marlock> how can i create the related restricted modules?
[23:32] <marlock> i need the same that are in linux-restricted-drivers...
[23:32] <marlock> linux-restricted-modules, sorry...
[23:40] <marlock> is there anyone can answer me?