[07:11] <apw> omicrom (N,BFTL), hmmm that says you can't load them in old kernels, and can in new, is that right ?
[08:16] <SrinivasGowda> Hi guys just wanted to report a change that needs to be made on this document
[08:16] <SrinivasGowda> https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues
[08:16] <SrinivasGowda> The last section near the footer with "sudo restart thermald"
[08:17] <SrinivasGowda> needs to be changed to  "sudo service  thermald restart"
[08:52] <apw> SrinivasGowda (N,BFTL), thanks
[09:28] <apw> SrinivasGowda (N,BFTL), and fixed
[09:37] <soren> apw: "(N,BFTL)"?
[09:41] <smb> soren, Not(there), But For The Log. I wondered the same. :)
[09:44] <apw> soren, yeah that
[10:06] <onicrom> apw: sorry i cannot load the nvidia kernel modules in any kernel newer than 3.13.0-30
[10:08] <apw> onicrom, i think we are already aware of that, i think tseliot was on the case there
[10:08] <apw> soren, and i think that shows that is worth it :)
[10:08] <tseliot> onicrom: weren't you using drivers from a ppa?
[10:15] <onicrom> tseliot: i was then i switched back 
[10:15] <onicrom> same problem
[10:16] <tseliot> onicrom: what driver are you using?
[10:16] <onicrom> nvidia-331-updates 331.38-0ubuntu7.1
[10:17] <tseliot> onicrom: are you running Precise or Trusty?
[10:17] <onicrom> trusty
[10:19] <tseliot> onicrom: ok. Is there a bug report about it?
[10:20] <onicrom> i had only been searching google for something and couldnt find, if there is a more appropriate place to search for a bug i can do there
[10:20] <soren> apw: :)
[10:20] <soren> smb: Thanks :)
[10:20] <tseliot> onicrom: please type "ubuntu-bug nvidia-331-updates" and file a bug report from there
[10:20] <soren> Google gave some interesting suggestions, though, but I'll leave it as an exercise to the reader to look them up. :)
[10:29] <onicrom> thanks tseliot 
[16:07] <rtg> dannf, your patch 'Allow for package revisions condusive for branching' does not correctly extract the ABI number when the version is of the form 3.16.0-8.13~14.10 (as it is for the LTS kernel).
[16:07] <dannf> rtg: ah, wasn't familiar with that string - i'll fix. if you need to revert in the meantime, no hard feelings :)
[16:09] <dannf> rtg: are there any other version forms you need to deal with?
[16:09] <rtg> dannf, that is the only other version form I use. I've reverted your patch only in the LTS branch so far.
[16:10] <dannf> ack
[17:27] <hallyn> apw: stgraber: hi, in a current ubuntu-cloud utopic vm (3.16.0-5-generic) unprivileged overlayfs appears broken
[17:27] <hallyn> lxc-clone -s -o u1 -n u2 fails
[17:35] <bjf> hallyn, do you know if there are any tests for that in lxc-tests? we run those tests and nothing is failing.
[17:36] <bjf> stgraber, ^
[17:36] <stgraber> I don't believe lxc-test-unpriv currently tries that, though we probably should
[17:36] <bjf> thanks
[17:36] <bjf> would also give apw handy tests to run
[17:41] <apw> sounds good
[17:43] <hallyn> Yeha, it'd be a good thing to test, just not sure how to finagle that for upstream tests
[17:43] <hallyn> I.e. most kernels don't yet expect that to be allowed, so how do we sanely say "in this system, fail if the overlayfs mount fails"
[17:59] <apw> hallyn, i'll have a look at the unpriv issue in the am i guess, i am fading fast, is there a bug filed
[18:00] <hallyn> apw: not yet.  in a bit i'll file a bug with hopefully a testcase
[18:00] <hallyn> apw: thanks - ttyl
[18:01] <apw> hallyn, sweet, we may have lost a fix rolling forward, has happened before
[18:01] <hallyn> yeah usually it tends to be apparmor :)
[18:05] <apw> hallyn, or that :)
[18:08] <stgraber> hallyn: IIRC lxc-test-userns is already an Ubuntu-only test (as in, configure will only include it on Ubuntu systems)
[18:09] <apw>  /proc/version_signature is pretty much ubuntu specific
[18:09] <hallyn> stgraber: yeah, Makefile.am does it.  
[18:10] <hallyn> so the test can go there
[18:10] <hallyn> meanwhile i need to set up a trusty vm so i can actually test overlay clones real quick :)
[18:39] <hallyn> apw: opened bug 1357025
[21:44] <kees> did you guys typo this:
[21:44] <kees> * auditsc: audit_krule mask accesses need bounds checking
[21:44] <kees>     - LP: #1347088
[21:44] <kees> 3.13.11.5 is not in trusty's kernel.
[21:46] <bjf> kees, i'll check but i think that's going into what we are currently working on ... will come out in 2 weeks
[21:47] <rtg> kees, its in Ubuntu-3.13.0-33.58
[21:47] <rtg> according to the git log
[21:48] <bjf> kees, rtg is right that came out on monday
[21:48] <kees> rtg: but why does the Makefile show 3.13.11.4 then?
[21:48] <bjf> kees, because we pulled it from the upstream stable set and put it into a special kernel
[21:49] <kees> $ git log | grep -m1 "Linux 3.13.11.4"
[21:49] <kees>     Linux 3.13.11.4
[21:49] <kees> but this returns nothing:
[21:49] <kees> $ git log | grep -m1 "Linux 3.13.11.5"
[21:49] <rtg> d428381b112e220dbba0b6d8197b51db60318432 in master-next
[21:49] <kees> so it's certainly not in 33.58
[21:50] <bjf> kees, are you looking at master or master-next ?
[21:51] <kees> I'm looking at master, but specifically I was looking at 33.58 which claimed to have that bug (3.13.11.5) fixed.
[21:51] <kees> so it looks like a typo in the changelog, and that 3.13.11.5 is on it's way.
[21:52] <bjf> kees, one sec. 
[21:53] <bjf> 6ff733c0b2cac445b2535a9adc83c76a315052be auditsc: audit_krule mask accesses need bounds checking
[21:53] <bjf> $ git tag --contains 6ff733c0b2cac445b2535a9adc83c76a315052be
[21:53] <bjf> Ubuntu-3.13.0-33.58
[21:53] <bjf> Ubuntu-3.13.0-34.59
[21:53] <bjf> Ubuntu-3.13.0-34.60
[21:55] <bjf> kees, ^
[21:56] <kees> bjf: 6ff733c0b2cac445b2535a9adc83c76a315052be is not "all of 3.13.11.5" which is what bug #1347088 claims to be
[21:57] <bjf> kees, yes and as i said above we pulled that one commit from the .5 stable release just specially for "someone" who was whining at us about it
[21:58] <kees> sure, but it seems like that bug shouldn't be closed, since all the other fixes (e.g. "ptrace: fix fork event messages across pid namespaces") haven't been imported yet.
[21:58] <bjf> kees, ok, but that's kind of a minor nit
[21:59] <bjf> kees, i can fix that
[21:59] <kees> I just found it confusing since "Trusty update to 3.13.11.5 stable release" hasn't happened, but the bug got closed. :)
[22:00] <bjf> kees, yes, that was confusing
[22:01] <kees> but it sounds like it's on it's way still, which is totally fine. I just had people asking me why their ptrace stuff was still breaking even though they were running with the kernel version that closed that bug. :)
[22:01] <kees> all is clear now! thanks :)
[22:02] <bjf> kees, .5 is almost in the oven
[22:02] <kees> \o/
[22:03] <rtg> kees, we often cherry-pick patches in advance of stable releases
[22:03] <bjf> rtg, the issue here is/was that it has a buglink for a general upstream stable release
[22:04] <bjf> rtg, and then we pulled it earlier so when 33.58 went out the .5 tracking bug got marked fix-released
[22:04] <rtg> bjf, oh, I see how that could happen.
[22:05] <bjf> rtg, i saw that it was going to happen and ment to go back and fix the bug but forgot
[22:15] <hallyn> jjohansen: hi, bug 1357103 is a squirrely one andreas just ran into
[22:16] <hallyn> apparmor is denying file_mmap to a file which presumably is cloned from another btrfs subvolume
[22:41] <jjohansen> hallyn: interesting
[22:42] <hallyn> jjohansen: heh, any ideas on the cause though?
[22:43] <jjohansen> hallyn: maybe the name is disconnected
[22:43] <jjohansen> hallyn: I think that will be due to an issue with bind mounts that I hit
[22:44] <jjohansen> hallyn: I have a patch that for that, that we can try and see if it resolves it
[22:44] <hallyn> jjohansen: cool!  better than i'd hoped
[22:45] <jjohansen> hallyn: which kernel would you like me to build to test? trusty, utopic?
[22:45] <jjohansen> the bug is trusty, so I am assuming that, but ...
[22:46] <hallyn> jjohansen: yeah, i haven't reproduced myself, so what andreas has
[22:47] <jjohansen> okay, I added a note to the bug, and I will get the test kernel attached tonight
[22:48] <hallyn> thanks!