[07:11] omicrom (N,BFTL), hmmm that says you can't load them in old kernels, and can in new, is that right ? === infinity_ is now known as infinity [08:16] Hi guys just wanted to report a change that needs to be made on this document [08:16] https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues [08:16] The last section near the footer with "sudo restart thermald" [08:17] needs to be changed to "sudo service thermald restart" === ikonia_ is now known as ikonia [08:52] SrinivasGowda (N,BFTL), thanks [09:28] SrinivasGowda (N,BFTL), and fixed [09:37] apw: "(N,BFTL)"? [09:41] soren, Not(there), But For The Log. I wondered the same. :) [09:44] soren, yeah that [10:06] apw: sorry i cannot load the nvidia kernel modules in any kernel newer than 3.13.0-30 [10:08] onicrom, i think we are already aware of that, i think tseliot was on the case there [10:08] soren, and i think that shows that is worth it :) [10:08] onicrom: weren't you using drivers from a ppa? [10:15] tseliot: i was then i switched back [10:15] same problem [10:16] onicrom: what driver are you using? [10:16] nvidia-331-updates 331.38-0ubuntu7.1 [10:17] onicrom: are you running Precise or Trusty? [10:17] trusty [10:19] onicrom: ok. Is there a bug report about it? [10:20] 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] apw: :) [10:20] smb: Thanks :) [10:20] onicrom: please type "ubuntu-bug nvidia-331-updates" and file a bug report from there [10:20] Google gave some interesting suggestions, though, but I'll leave it as an exercise to the reader to look them up. :) [10:29] thanks tseliot === FJKong is now known as FJKong_CW === _ruben_ is now known as _ruben === lamont` is now known as lamont [16:07] 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] rtg: ah, wasn't familiar with that string - i'll fix. if you need to revert in the meantime, no hard feelings :) [16:09] rtg: are there any other version forms you need to deal with? [16:09] dannf, that is the only other version form I use. I've reverted your patch only in the LTS branch so far. [16:10] ack === FreezingAlt is now known as FreezingCold === Mikee_C is now known as Mikee_C_afk [17:27] apw: stgraber: hi, in a current ubuntu-cloud utopic vm (3.16.0-5-generic) unprivileged overlayfs appears broken [17:27] lxc-clone -s -o u1 -n u2 fails [17:35] hallyn, do you know if there are any tests for that in lxc-tests? we run those tests and nothing is failing. [17:36] stgraber, ^ [17:36] I don't believe lxc-test-unpriv currently tries that, though we probably should [17:36] thanks [17:36] would also give apw handy tests to run [17:41] sounds good [17:43] Yeha, it'd be a good thing to test, just not sure how to finagle that for upstream tests [17:43] 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] 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] apw: not yet. in a bit i'll file a bug with hopefully a testcase [18:00] apw: thanks - ttyl [18:01] hallyn, sweet, we may have lost a fix rolling forward, has happened before [18:01] yeah usually it tends to be apparmor :) [18:05] hallyn, or that :) [18:08] hallyn: IIRC lxc-test-userns is already an Ubuntu-only test (as in, configure will only include it on Ubuntu systems) [18:09] /proc/version_signature is pretty much ubuntu specific [18:09] stgraber: yeah, Makefile.am does it. [18:10] so the test can go there [18:10] meanwhile i need to set up a trusty vm so i can actually test overlay clones real quick :) [18:39] apw: opened bug 1357025 [18:39] bug 1357025 in linux (Ubuntu) "unprivileged overlayfs mounts no longer work in utopic" [Undecided,New] https://launchpad.net/bugs/1357025 [21:44] did you guys typo this: [21:44] * auditsc: audit_krule mask accesses need bounds checking [21:44] - LP: #1347088 [21:44] Launchpad bug 1347088 in linux (Ubuntu) "Trusty update to 3.13.11.5 stable release" [Undecided,Confirmed] https://launchpad.net/bugs/1347088 [21:44] 3.13.11.5 is not in trusty's kernel. [21:46] 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] kees, its in Ubuntu-3.13.0-33.58 [21:47] according to the git log [21:48] kees, rtg is right that came out on monday [21:48] rtg: but why does the Makefile show 3.13.11.4 then? [21:48] kees, because we pulled it from the upstream stable set and put it into a special kernel [21:49] $ git log | grep -m1 "Linux 3.13.11.4" [21:49] Linux 3.13.11.4 [21:49] but this returns nothing: [21:49] $ git log | grep -m1 "Linux 3.13.11.5" [21:49] d428381b112e220dbba0b6d8197b51db60318432 in master-next [21:49] so it's certainly not in 33.58 [21:50] kees, are you looking at master or master-next ? [21:51] 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] so it looks like a typo in the changelog, and that 3.13.11.5 is on it's way. [21:52] kees, one sec. [21:53] 6ff733c0b2cac445b2535a9adc83c76a315052be auditsc: audit_krule mask accesses need bounds checking [21:53] $ git tag --contains 6ff733c0b2cac445b2535a9adc83c76a315052be [21:53] Ubuntu-3.13.0-33.58 [21:53] Ubuntu-3.13.0-34.59 [21:53] Ubuntu-3.13.0-34.60 [21:55] kees, ^ [21:56] bjf: 6ff733c0b2cac445b2535a9adc83c76a315052be is not "all of 3.13.11.5" which is what bug #1347088 claims to be [21:56] bug 1347088 in linux (Ubuntu Trusty) "Trusty update to 3.13.11.5 stable release" [Undecided,Confirmed] https://launchpad.net/bugs/1347088 [21:57] 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] 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] kees, ok, but that's kind of a minor nit [21:59] kees, i can fix that [21:59] 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] kees, yes, that was confusing [22:01] 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] all is clear now! thanks :) [22:02] kees, .5 is almost in the oven [22:02] \o/ [22:03] kees, we often cherry-pick patches in advance of stable releases [22:03] rtg, the issue here is/was that it has a buglink for a general upstream stable release [22:04] rtg, and then we pulled it earlier so when 33.58 went out the .5 tracking bug got marked fix-released [22:04] bjf, oh, I see how that could happen. [22:05] rtg, i saw that it was going to happen and ment to go back and fix the bug but forgot [22:15] jjohansen: hi, bug 1357103 is a squirrely one andreas just ran into [22:15] bug 1357103 in lxc (Ubuntu) "apparmor denied a golang build inside a container" [Undecided,New] https://launchpad.net/bugs/1357103 [22:16] apparmor is denying file_mmap to a file which presumably is cloned from another btrfs subvolume [22:41] hallyn: interesting [22:42] jjohansen: heh, any ideas on the cause though? [22:43] hallyn: maybe the name is disconnected [22:43] hallyn: I think that will be due to an issue with bind mounts that I hit [22:44] hallyn: I have a patch that for that, that we can try and see if it resolves it [22:44] jjohansen: cool! better than i'd hoped [22:45] hallyn: which kernel would you like me to build to test? trusty, utopic? [22:45] the bug is trusty, so I am assuming that, but ... [22:46] jjohansen: yeah, i haven't reproduced myself, so what andreas has [22:47] okay, I added a note to the bug, and I will get the test kernel attached tonight [22:48] thanks!