[00:17] <greg_> greetings all
[00:17] <greg_> anybody home?
[00:18] <jk-> some are :)
[00:20] <greg_> hi  - quick question if anyone has a second, if I want to be more informed about future direction of the kernel and maybe even have my thoughts heard about it, where would I look/watch/join? 
[00:21] <RAOF> greg_: The kernel mailing list would probably be the best place overall, but various subsystems have their own mailing lists.
[00:23] <RAOF> greg_: Note that the kernel mailing list is unlikely to be receptive to general thoughts not backed up by the possibility of a code submission.  Reviewing specific patches will likely be welcomed, though.
[00:24] <greg_> thanks RAOF.  When I first installed lucid server and discovered there was no x86 server kernel, but the package was essentially a pointer to the generic-pae kernel, it was suggested that the change was announced via some community mechanism that I now don't remember, shamefully, and no one objected.  I'd like to make sure I don't get that kind of surprise in the future without wading through every mail and patch....  
[00:24] <greg_> the not remembering is the shameful part
[00:24] <greg_> :-)
[00:24] <RAOF> Ah.  You're more interested in the Ubuntu kernel configuration, then.
[00:25] <RAOF> In that case, kernel-team@lists.ubuntu.com :)
[00:26] <crimsun> sometimes the info comes across sooner on ubuntu-devel@.
[00:26] <RAOF> For bigger changes, yeah.
[00:30] <greg_> ok, thanks very much RAOF and crimsun
[00:34] <Omega> < trap15> does anyone know the reason that usbfs was removed from the ubuntu kernels?
[00:35] <crimsun> other than it's deprecated, or at this point, obsolete?
[02:53] <jk-> RAOF: regarding https://blueprints.launchpad.net/ubuntu/+spec/hardware-desktop-n-xorg-configuration-the-final-ten-percent, where would be the best place to put my device-tree proposal?
[02:58] <RAOF> jk-: If it's small, in the whiteboard.  If it's big or needs discussion, on the wiki.
[02:59] <jk-> ROAF, yep, was thinking the wiki is more suitable, somewhere like X/Dev/DeviceTreeDetection ?
[03:00] <RAOF> I was thinking of linking it to the blueprint.
[03:01] <jk-> X/Dev/hardware-desktop-n-xorg-configuration-the-final-ten-percent ?
[03:02] <RAOF> Ah.  I haven't set a URL for that blueprint yet.
[03:02] <jk-> yep :)
[03:03] <RAOF> In that case, X/Dev/DeviceTreeDetection sounds like a good name.
[03:03]  * jk- discovers X/Blueprints
[06:45] <jk-> apw: ping?
[13:13] <cking> apw, any sign of manjo today?
[13:19] <apw> cking, yep he is my left-hand man, wassup
[13:20] <cking> apw, just wondering if he made it through to London OK - I didn't seem him on IRC today
[13:23] <jjohansen> ah that explains apw's silence
[13:23] <cking> indeedy
[13:27]  * apw is always quiet, i am very very introverted
[13:30] <cking> cough, splutter,
[13:30] <cking> what?!
[13:31] <smb> Rather the most extrovert introvert we met
[13:31] <cking> if apw is introverted then I'm basically so introverted that one would class me as clinically dead
[15:03] <didrocks> hey guys
[15:04] <didrocks> since grub 1.99~2010112, with nvidia proprietary driver, I can't get a working X/gdm
[15:04] <didrocks> cjwatson pointed me to the framebuffer spec and I saw that gfxpayload=keep is activated
[15:05] <didrocks> I remember having issues with it in maverick, so it's maybe linked
[15:05] <didrocks> how can I help getting the relevant info to you?
[15:12] <lag> apw: Have all the delta patches been deleted now?
[15:16] <apw> lag ?
[15:17] <lag> apw: https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyUbuntuDeltaReview
[15:17] <lag> apw: I can't find my patches for looking
[15:20] <apw> lag in the wiki page or in the ubuntu delta ?
[15:22] <lag> I can find the entries on the Wiki
[15:22] <lag> But they're missing from git log etc
[15:27] <apw> lag, then perhaps they got dropped, are they in the dropped section below 
[15:27]  * lag checks
[15:29] <lag> apw: They don't appear to be
[15:29] <lag> apw: Maybe they were dropped when ARM support was removed?
[15:29] <apw> lag hmmm, ok well mark them as missing and i'll try and find out
[15:30] <lag> Okay
[16:38] <JFo> <-lunch
[17:59] <JFo> back
[18:16] <cking> JFo, dude, how's it going?
[18:16] <JFo> cking, not too bad despite being overwhelmed by everything :)
[18:16] <JFo> cking, how about you?
[18:17] <cking> JFo, ditto :-)
[18:17] <JFo> heh
[18:18] <cking> Those bug reports keep in coming it. I understand it can be most overwhelming.
[18:18] <JFo> I'd be on mumble, but I stupidly forgot to charge my headset over the weekend
[18:18] <charlie-tca> JFo: We got a bug day tomorrow for you, right?
[18:18] <JFo> oh yes, the bug reports are never ending
[18:18] <JFo> charlie-tca, yessir
[18:18] <JFo> bugs with patches
[18:18] <charlie-tca> Great!
[18:18]  * JFo plans to remind folks via e-mail and blog today
[18:18] <charlie-tca> I can try to do some, at least.
[18:19] <JFo> excellent! I welcome anyone interested in helping
[18:19] <JFo> especially if that person is you charlie-tca :)
[18:19] <charlie-tca> thanks
[18:21] <cking> bjf, thanks for helping me out with the fwts over the weekend
[18:24] <bjf> cking, glad to, i'll do some further testing sometime this week i think
[18:25] <cking> bjf, cool, I'm still unable to trip that lucid bug, but I've not had much change since Saturday to reproduce.
[18:49] <_Groo_> hi/2 all
[18:49] <_Groo_> found a very ugly bug with reiserfs + ecryptfs in maverick/natty thats wasnt there in previous kernels
[18:49] <_Groo_> if my machine crashes via a hardware freeze (damn you nvidia), reiserfs runs its log file, so far so good
[18:49] <_Groo_> unfortunatelly ecryptfs is not yet mounted or a bug lies at that lvl, and reiserfs is writing the raw data in the ecryptfs inodes, borking all the data
[18:50] <_Groo_> or something like that for what i could test.
[18:50] <_Groo_> anyway when reiserfs kicks the log write, the file affected gets borked if you use a eccryptfs layer
[18:50] <_Groo_> anyone ever seen this behaviour before?
[18:51] <sconklin> back in a couple of hours
[19:03]  * tgardner --> lunch
[19:52] <ppetraki> quick question, is the -server kernel using CFS be default, and how do I find out which scheduler were using at runtime?
[19:59] <soren> ppetraki: /sys/block/<name of block device>/queue/scheduler
[20:01] <ppetraki> soren, I got that one, and it's deadline
[20:01] <ppetraki> soren, now what about processes? it a mess in proc somewhere
[20:01] <soren> ppetraki: What about processes?
[20:01] <ppetraki> soren, the config says http://pastebin.com/CQWTBS8q
[20:02] <ppetraki> soren, which appears to be deadline for process scheduling too
[20:04] <soren> ppetraki: I'm not sure what you're saying. CONFIG_DEFAULT_DEADLINE=y means the the deadline scheduler is the default i/o scheduler.
[20:07] <ppetraki> soren, there's one for io and one for process. I'm just trying to verify at runtime which one we're using
[20:07] <ppetraki> soren, the io one is easy enough as you pointed out
[20:07] <ppetraki> soren, with the CFS, am I using it? how do I find out. the docs aren't exactly clear
[20:08]  * soren is not aware that there's much of an option when it comes to process scheduling (other than preempt and HZ settings)
[20:08] <ppetraki> fair enough
[20:08] <ppetraki> thanks
[20:09] <soren> That is not to say that there isn't. I just don't know about it.
[20:09] <ppetraki> that's what I'm trying to determine
[20:41] <GrueMaster> Can someone tell me when linux-ti-omap4 2.6.35-903.19 will move from proposed to release?  I busted my butt to get it tested during US holiday, and need it for natty testing.
[20:43]  * jjohansen -> lunch
[20:45] <tgardner> GrueMaster, we have no plans to produce a natty ti-omap4 kernel. I thought Linaro was doing it?
[20:45] <GrueMaster> That is for omap, not omap4 as far as I know.
[20:46] <GrueMaster> And you guys asked me to test this kernel two weeks ago for Maverick.
[20:46] <tgardner> hmm, then I'm waiting on Bryan Wu as he is the omap4 dude.
[20:46] <GrueMaster> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/673504
[20:46] <ubot2> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (heat: 192)" [High,Fix committed]
[20:46] <GrueMaster> That has all the info for 2.6.35-903.19
[20:47] <tgardner> GrueMaster, checking...
[20:47] <GrueMaster> Until then, natty is currently pulling 2.6.35-903.17
[20:48] <tgardner> GrueMaster, re: maverick, I think we're waiting on the SRU team to promote it to -updates
[20:50] <GrueMaster> Well, lets hope it gets released before the next security patch cycle.  I really don't want to keep spinning loops around these bugs because of flawed release processes.
[22:22] <jjohansen> bjf, sconklin: do the lts-backport kernels get security updates
[22:23] <sconklin> jjohansen: good question. rtg? ^^
[22:24] <jjohansen> sconklin: tgardner isn't around currently
[22:24] <bjf> jjohansen, i believe that they do though we have left the updating of them to rtg
[22:24] <bjf> jjohansen, it's on our list of thing to find out how exactly he is maintaining them
[22:25] <sconklin> jjohansen: I think that they do by virue of being backported from kernels which have security applied, but I don't think it's simultaneous with the security releases
[22:25] <jjohansen> right, thanks
[22:31] <sbeattie> bjf, sconklin, jjohansen: I think the question is, will the lts-backports get security updates that come through the lucid-security pocket?
[22:31] <sbeattie> or will they just be part of the periodic updates that roll into -proposed/-updates?
[22:31] <bjf> sbeattie, heh, that's a good question
[22:31] <sconklin> yeah, I agree. That's the question
[22:31] <sconklin> we don't have an answer