=== fmasi_afk is now known as fmasi
=== fmasi is now known as Guest61012
=== psivaa-afk is now known as psivaa
[08:24] <caribou> crap; my Saucy upgrade aborted since /boot was too cluttered with old kernels; when are we going to come up with a kernel cleanup script ?
[08:28] <smb> caribou, "sudo apt-get autoremove --purge"
[08:29] <smb> caribou, autoremove would be working well at least since Raring
[08:29] <caribou> smb: oh yeah; I know how to do it, I'm just thinking of the lambda user with no CLI knowledge who gets hit by that
[08:30] <smb> caribou, Ah ok. Hm, yeah don't know whether update-manager graphical would have a autoremove step before upgrade
[08:31] <caribou> smb: I usualy clean up manually (removed > 10 kernel pkg a while back) but regular users don't do this
[08:31] <caribou> smb: well apparently not, I just kicked off the Saucy upgrade and it failed because of that
[08:32] <smb> Some thing to talk about to people doing update-manager then, I guess. If we remember
[08:32] <caribou> I remember a discussion a while back on some ML about having some housekeeping mechanism to cleanup kernel packages
[08:35] <caribou> smb: found the discussion : http://ubuntu.5.x6.nabble.com/Distro-provided-mechanism-to-clean-up-old-kernels-td4476631.html
[08:35] <apw> morning
[08:36] <apw> i thought that update-manager would autoremove before it started, that would be logical
[08:36] <apw> caribou, in your case was /boot separate? which obviously exascerbates the issue
[08:36] <apw> and if so, what triggered it to be so
[08:46] <caribou> apw: autoremove will only deal with headers apparently, not the linux-image pkg themselves (unless it has changed since this ML thread)
[08:46] <caribou> apw: yeah, I'm on a separate /boot
[08:46] <caribou> apw: the mail thread leads to a Q blueprint that apparently no longer exists
[08:48] <apw> caribou, autoremove has changed to include the linux-image packages, and i believe this has been backported as well as far as P
[08:48] <caribou> apw: oh, wasn't aware of that; I would have tried it
[08:48] <apw> caribou, why do you have a /boot, not a criticism just wondering
[08:48] <caribou> apw: ok, I'll check on other systems I have around
[08:49] <caribou> apw: most probably a default when I installed last time
[08:49] <caribou> apw: oh, and most probably because I'm running a fully encrypted system
[08:49] <caribou> now I remember why
[08:50] <antarus> apw: I would like to convince you to enable CONFIG_IMA in your kernels, I see that in 2010 you added it to the config enforced to 'never enable'..which is perhaps unfortunate for me ;)
[08:50] <antarus> (or I am misunderstanding what the enforcer is doing, which could be true, it is early ;p)
[08:51] <apw> antarus, _IMA that rings a bell, it was some intergety manager thing, and i seem to remember it is enforced off because of the epic cost of it being enabled (at least at the time)
[08:52] <antarus> apw: so my security guy is working on a policy that is..not supposed to be epic cost
[08:52] <antarus> apw: I'll open a launchpad bug and try to get him to attach some tests
[08:53] <antarus> (fwiw, we have been running it for two years on over 10000 machines)
[08:53] <apw> antarus, i had the feeling that that was just the framework and, it was very expensive always, and that was why it was off.  that decision is at least a few years old, _IMA may have gotten less expensive
[08:54] <apw> antarus, was going to say the same, if you want us to consider it, some numbers to show having it turned on does not make the normal case go to shit performance wise would help a lot
[08:54] <antarus> apw: there is a policy, and certainly if your policy specifies expensive operations, it will be expensive, but IIRC the actual system call...I'll call it introspection...I believe has gotten better ;)
[08:54] <antarus> anyway, thanks for the pointers ;)
[08:55] <apw> antarus, yeah i can believe it, so yeah file a bug, and get the number in here, ping me with it so i can get  it on the list for consideration
[08:57] <antarus> apw: is there a prefered perf test you would like us to use (with IMA on, and IMA off?)
[08:57] <apw> hmmm i wonder if i reference a bug in the enforce off
[08:57] <apw> cause that would be nice of me
[09:01] <antarus> Yeah I don't see one
[09:02] <antarus> I blame kees
[09:02] <antarus> for all kernel problems ;p
[09:04]  * kees bows
[09:04] <antarus> oh I didn't even know you were in here
[09:04] <antarus> lol
[09:04] <antarus> howdy!
[09:05] <kees> in the past, CONFIG_IMA meant the kernel would track all your files, eating tons of memory.
[09:05] <kees> hi! :)
[09:05] <kees> there wasn't a way to turn it off without building it out.
[09:06]  * antarus nods
[09:07] <smb> kees, So you say this has changed now
[09:08] <kees> smb: I do? I haven't looked at it at all since disabling it to get my memory back :)
[09:08] <antarus> smb: so my understanding is that IMA is controlled by a policy now
[09:08] <kees> smb: if it HAS been fixed, then I have no objection to CONFIG_IMA
[09:08] <antarus> smb: and the policy limits the scope of what IMA is doing
[09:09] <smb> kees, Oh it was just my reading of you saying "there _wasn't_ a way to turn it off" :)
[09:09] <antarus> so as I said, if your IMA policy is 'track all files' then it will likely be dog slow ;)
[09:09] <antarus> but I think that would be a stupid default policy ;p
[09:09] <smb> Ah ok, so it might be something to review (policy and then turning it on maybe)
[09:09] <antarus> yeah
[09:10] <smb> But sure a bug report with some data would be good
[09:10] <antarus> so i have a security engineer willing to write the policy and to run perf tests
[09:10] <antarus> but we are unsure what perf tests are actually relevant to you
[09:10] <kees> nope!
[09:10] <smb> And then there is vUDS coming up too, in near future
[09:10] <antarus> kees: ?
[09:11] <kees> I'm happy to sign off on someone showing me that "CONFIG_IMA=n" and "CONFIG_IMA=y" don't show memory deltas, but I don't have tests for it, unfortunately.
[09:12] <antarus> sorry, are the memory deltas here in kernel memory?
[09:13] <antarus> (or expected deltas)
[09:15] <kees> yeah, I want to make sure IMA isn't silently stealing memory when built in :)
[11:59] <BjoernC> hi guys I've a small problem. I have recognized, that i cannot  control the brightness of my notebook. If I'm using Kernel 3.11.0-4 everything is ok, but if i make an upgrade to 3.11.0-9 or even to 3.12.0 the brightness control doesn't work. Therefore, i have tested the "original" Kernels of kernel.org where this problem doesn't exist. My question is, where should i search for this failure and how can i do that?
[12:24] <tseliot> BjoernC: what graphics driver are you using?
[12:29]  * henrix -> lunch
[12:31] <BjoernC> nvidia 325.15
[12:39] <tseliot> BjoernC: it sounds like bug 1241745
[12:39] <ubot2> Launchpad bug 1241745 in nvidia-graphics-drivers-319 (Ubuntu) "[regression] Changing the screen brightness does not work anymore in 319.xx" [Medium,Triaged] https://launchpad.net/bugs/1241745
[12:40] <tseliot> and NVIDIA is aware of the issue
[12:41] <BjoernC> hmm the problem lies not in the driver
[12:41] <BjoernC> because if i use the original kernel from kernel.org it works fine
[12:41] <tseliot> BjoernC: can you add a comment in the bug report with what you explained (the kernels you've tried, etc.)
[12:42] <tseliot> as if it's a problem we introduced, it should be easier to track down
[12:42] <BjoernC> yeah i can do that
[12:42] <tseliot> thanks
[12:42] <BjoernC> so the issue should happened between the versions 3.11.0-4 to 3.11.0-9
[12:43] <BjoernC> that the current state of my track down
[12:46] <BjoernC> So i will try another thing may be i can give you a more detailed issue report may be i can say you in which revision this issue happens but i need some hours if it is ok to you?
[12:55] <BjoernC> mybe i have found the patch - so i will try to reverse it and recompile the kernel. If everything works, i will tell you
[13:01] <tseliot> BjoernC: ok, thanks
[13:02] <BjoernC> nP
[13:36]  * ppisati -> out for a bit
[14:02] <BjoernC> Hello again
[14:02] <BjoernC> so I have found the cause of the backlight problem i have reversed that patch and now the brightness control of the backlight works again...
[14:03] <BjoernC> so what do you need?
[14:16] <BjoernC> But as i see, my solution won't work for the bug report: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-319/+bug/1241745?comments=all
[14:16] <ubot2> Launchpad bug 1241745 in nvidia-graphics-drivers-319 (Ubuntu) "[regression] Changing the screen brightness does not work anymore in 319.xx" [Medium,Triaged]
[14:34] <tseliot> BjoernC: why won't it work for that bug report?
[14:38] <BjoernC> because only my notebook were blacklisted ...
[14:39] <BjoernC> Therefore, it shouldn't work for other notebooks besides lenovo Thinkpads
[14:39] <BjoernC> I have reverted this patch here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=blobdiff;f=drivers/acpi/blacklist.c;h=f49ffaedaefdaa28d533d339a3f5cda073687ed7;hp=9515f18898b2b578053c58309185daa7934cfdda;hb=02cb06962306d96f59bc97ec8289c14b73bafb4e;hpb=2eb9acd1a1deb3f4d6428d022fc43541c9e70069
[14:41] <BjoernC> so i don't think, that this reverting will help an dell or hp notebook
[14:45] <sforshee> BjoernC: reverting that patch won't affect your machine. But the bug says you're passing acpi_osi="!Windows 2012" on the kernel command line, which has the same effect as being in that blacklist.
[14:48] <BjoernC> sforshee: i've tested it, if I revert that patch now I can control the backlight brightness - previously without reverting that patch i couldn't control the backlight brightness - (both applied on Kernel version 3.12.0) 
[14:51] <jsalisbury> **
[14:51] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:51] <jsalisbury> **
[14:52] <sforshee> BjoernC: I think I must be confused then. You're running a Lenovo and not an HP?
[14:52] <BjoernC> yep
[14:52] <BjoernC> I'm using an lenovo T430
[14:52] <sforshee> are you still passing the acpi_osi thing?
[14:53] <BjoernC> what do u mean?
[14:53] <BjoernC> passing to whom or where?
[14:53] <sforshee> nevermind, that wasn't your machine
[14:54] <BjoernC> yeah
[14:54] <sforshee> BjoernC: have you filed a bug for your problem?
[14:54] <BjoernC> no not yet
[14:55] <sforshee> once you have, point me at it and I'll look
[14:55] <BjoernC> because i thought the problem lies in the original kernel after i realised that problem lies in the ubuntu kernel, i wanted to be sure that i'm not wrong
[14:55] <BjoernC> should i open a new bug report or search for similar reports?
[14:56] <sforshee> just open a new one by running 'ubuntu-bug linux' so we'll get all the information about your machine
[14:56] <BjoernC> ok I'm not using ubuntu directly
[14:57] <BjoernC> i'm using kanotix which is using the ubuntu kernel
[14:57] <BjoernC> so i don't think, that i can run that tool
[14:58] <BjoernC> you understand my problem? ;)
[14:58] <sforshee> try it at least, and if that doesn't work just file the bug and maybe you can at least use apport-collect to attach the data
[15:04] <BjoernC> i will try to install the programm
[15:04] <BjoernC> hopefully there is an *.deb file available?
[15:05] <sforshee> BjoernC: if that distro is an ubuntu derivative it might work, but I don't know whether or not that's the case
[15:12] <BjoernC> afaik is kanotix primarly debian based and only uses the ubuntu kernel
[15:13] <BjoernC> however, ich will make that bug report and if there are any questions, then feel free to ask 
[15:37] <BjoernC> sforshee: here is the bug-report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1243267
[15:37] <ubot2> Launchpad bug 1243267 in linux (Ubuntu) "Backlight brightness control doesn't work" [Undecided,New]
[15:38] <BjoernC> hopefully this bug reports helps a little bit
[16:25] <Kano> hi,why does ndiswrapper compile with 3.12rc6 pure but not with 3.12.0-0-generic?
[16:26] <Kano> http://paste.debian.net/60500/
[16:26] <Kano> http://paste.debian.net/60505
=== rtg_ is now known as Guest33959
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues November 26th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:24] <hallyn> hm, i'm not seenig a new kernel on trusty yet.
[17:29] <bjf> hallyn, it's waiting for buildds
[17:31] <hallyn> bjf: drat.  thanks.  lemme try buildign my own from ubuntu-trusty/ if that exists
[18:53] <infinity> hallyn: There's one in the PPA.
[18:54] <infinity> hallyn: (Well, binaries are publishing right now, but it's built..)
[18:54] <Kano> did anybody try ndiswrapper with 3.12?
[18:54] <infinity> Kano: Sounds like you just volunteered to. ;)
[18:55] <Kano> infinity: i know that it compiles with pure 3.12 rc6, but it does not with the new u kernel
[18:55] <Kano> did you look at the pastes
[18:57] <infinity> Ahh, no.  Didn't realise you'd tried already.  This was with the sources in the kernel team PPA?
[18:57] <Kano> self compiled from t git
[18:57] <infinity> Looks like something you might want to bring up on the list.
[18:58] <infinity> Or, try with the binaries just built in the PPA and see if it's somehow different, but seems unlikely.
[18:58] <Kano> must be one of your extra patches
[18:58] <Kano> i can not use your binaries
[18:58] <Kano> i dont use u
[18:58] <Kano> also i prefer ahci static
[18:58] <hallyn> infinity: oh, thanks.  (think my kernel just built :)
[18:59] <infinity> hallyn: Heh.  Timing.
[19:00] <Kano> http://kanotix.com/files/dragonfire/linux-3.9.0-2.6kanotix1/patches/0001-KANOTIX-Config-CONFIG_SATA_AHCI-y.patch
[19:00] <Kano> i always use that because this way i could boot the linux image without initrd via efi
[19:19] <Kano> bbl
[21:49] <BjoernC> hi guys
[23:45] <gianko82> hello
[23:46] <gianko82> im using ubuntu 12.04 lts on hp 650 notebook
[23:46] <gianko82> after upgrade to kernel 3.2.0-55 wifi stop to work
[23:47] <gianko82> i guess is missing the rt2800pci driver
[23:48] <gianko82> for Ralink RT3290
[23:49] <gianko82> that was present in kernel 3.2.0-54
[23:51] <gianko82> with latest kernel update wireless is UNCLAIMED
[23:59] <gianko82> can somebody fix it for next kernel release? or open a bug? thanks