[12:37] <medberry> What's the ideal (or canonical) way to apt-get my kernel source and rebuild it (with a two line .config change).  The google hits I'm finding searching for that are out of date or just plain wrong.
[12:37] <medberry> I'll need the i686 and any modules/initrds and I'm running an up to date feisty
[09:05] <kraut> moin
[01:41] <AndyP> hi kernel folks, is bug #120297 likely to be fixed for 7.10?
[01:42] <fabbione> AndyP: before filing that kind of bugs and asking for a fix you should really read the kernel devel timeline
[01:43] <fabbione> not all drivers can be re-added right away during the beginning of the devel phase
[01:43] <fabbione> but it's guaranteed that they will come back as soon as possible
[01:43] <AndyP> fabbione: ok that's understandable, thanks, where is the timeline?
[01:44] <fabbione> AndyP: https://wiki.ubuntu.com/GutsyReleaseSchedule
[01:45] <fabbione> stuff needs to be all there as soon as possible before beta
[01:45] <AndyP> fabbione: oh, the release schedule, ok thanks again 
[01:45] <fabbione> but they never had to stretch drivers that far in time
[01:45] <fabbione> usually it happens way earlier
[01:46] <AndyP> right, ok
[01:47] <AndyP> i'll use my ethernet cable a while longer then :)
[01:49] <JanC> there is also https://wiki.ubuntu.com/KernelTeam/Roadmap :)
[01:52] <AndyP> JanC: thanks :)
[02:51] <TheMuso> /c
[02:51] <TheMuso> gah
[04:09] <zul> BenC: has there been any though on adding vserver I think there has been a couple of requests
[04:10] <BenC> zul: like many of the virt implementations, request != maintainer
[04:10] <zul> yeah yeh :)
[04:12] <BenC> VMI, xen and openvz (hopefully) will have someone behind it making sure it works and that we can go to them for help when we need it
[04:12] <BenC> we don't have that for vserver that I know of
[04:13] <zul> ill try playing with it this weekend who knows
[04:29] <BenC> amitk: just added you to ubuntu-kernel-team, expect lots of email
[04:56] <BenC> crimsun: sent you codec for the sigmatel chip
[06:19] <slmnhq> Hi, On an SMP machine is it normal that the LOC interrupt rate on one CPU differs from anothers?
[06:20] <slmnhq> On my dual core machine, CPU0's LOC rate is about 18677 Hz and on CPU1 it's 1000 Hz
[06:53] <jwendell> Hi, folks
[06:54] <jwendell> does anyone could verify bug 104155 ?
[06:55] <mkrufky> jwendell: is the drive unmounted when you try to eject it?
[06:55] <jwendell> mkrufky, yep
[06:56] <mkrufky> ok, then i have nothing to offer :-P
[06:56] <jwendell> if it's umounted, it's ejected normally
[06:56] <mkrufky> oh!  then i do
[06:57] <mkrufky> so you just have to unmount it before you try to eject it
[06:57] <mkrufky> IMHO, if previous code allowed you to eject without first unmounting, then THAT was a bug, and now its fixed
[06:57] <jwendell> mkrufky, but it worked in edgy :)
[06:57] <mkrufky> sounds like edgy is bugged, then
[06:57] <jwendell> hehe
[06:57] <mkrufky> edgy is 2.6.17.y, right
[06:57] <mkrufky> ?
[06:57] <jwendell> right
[06:59] <mkrufky> i am not an authority here -- i am just being nosy...  but, anyway, i think your bug #104155 is a feature and not a bug, and that the previous behavior was the bug -- you are betetr off now
[07:00] <jwendell> mkrufky, i got the point, but we are talking about read only media
[07:01] <mkrufky> i think perhaps there is a different way to approach your issue
[07:01] <jwendell> mkrufky, anyway, if i press the eject button on drive, it ejects normally
[07:01] <jwendell> even when it's mounted
[07:01] <mkrufky> maybe, what you want is for Fn+F10 to handle the umount command for you, and then eject
[07:01] <mkrufky> so the problem is that the umount step is missing
[07:02] <jwendell> mkrufky, i want the same behavior as if i press the eject button on drive
[07:02] <mkrufky> in which case, this is not really a kernel issue, so i think this might not be the right place to ask about it :-/
[07:02] <mkrufky> if you press eject, does the drive unmount AND eject ?  (i assume yes)
[07:02] <jwendell> yes
[07:03] <mkrufky> ok, so that's it ... your Fn+F10 macro handler,  or whatever it is, is neglecting to umount before trying to eject
[07:03] <jwendell> yep
[07:03] <jwendell> where do i fix that?
[07:03] <jwendell> do you know?
[07:03] <mkrufky> i dont know
[07:04] <mkrufky> but your bug is files against the linux-source-2.6.20 , and probably needs to be re-classed if you want a useful response... (i dont know what it SHOULD be files against, but they can probably tell you in #ubuntu , or whatever other ubuntu support room)
[07:04] <mkrufky> s/files/fileD
[07:05] <jwendell> mkrufky, ok, i'll search a bit more
[07:05] <jwendell> thanks
[07:05] <mkrufky> you're welcome, jwendell
[07:29] <afie> Any proper fixes for snd_intel_hda yet?
[07:29] <afie> Ubuntu of all distros should be the _last_ to do something like this. >_>
[07:29] <afie> Break sound after an update :-\
[08:02] <BenC> kylem: do you know if we support Intel GMA3000?
[08:02] <BenC> kylem: in dapper that is
[08:03] <kylem> nope, it's way too new.
[08:04] <kylem> GMA3000 is i965.
[08:04] <BenC> kylem: ok, thanks
[10:58] <bdmurray> rtg: ping
[11:16] <crimsun> BenC: ok, thanks. I'm still needing the SSID from `lspci -nv|grep 0403 -A1`.
[11:49] <BenC> crimsun: Ah, ok