=== diwic__ is now known as diwic
=== diwic is now known as diwic_
[13:00] <stepjohn> I've just checked out the kernel source from git and there isn't debian/patches dir. Where are the custom kernel patches stored for the ubuntu kernel?? Am I wrong in thinking that you patch the kernel?
[13:02] <diwic_> stepjohn, patches are applied to the kernel, but as git commits, not as added files in debian/patches
[13:03] <stepjohn> diwic_: Arrrrr OK now I totally get it 
[13:03] <stepjohn> diwic_: branch apply patch, update changelog, tag , build 
[14:17] <alexbligh1> Am I correct that CVE-2015-0239 / usn-2516-3 per http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-0239.html is fixed in the HWE kernel for trusty (i.e. linux-image-generic-lts-utopic) in 3.16.0-31.41~14.04.1 which (despite what it says on the page) is not released, the latest version being 3.16.0.31.24? If so, when would one expect 3.16.0-31.41?
[14:21] <alexbligh1> I'm confused as it appears to be in utopic-security but not precise
[14:24] <henrix> alexbligh1: where do you see that 3.16.0-31.41 isn't yet released?
[14:24] <alexbligh1> henrix, http://packages.ubuntu.com/trusty-updates/linux-generic-lts-utopic and 'apt-get update'
[14:26] <henrix> alexbligh1: you're looking at the -meta package.  here's the correct link: http://packages.ubuntu.com/trusty-updates/kernel/linux-image-3.16.0-31-generic
[14:30] <alexbligh1> henrix, thanks - all very peculiar. I better find out why it's not installing then
[14:31] <alexbligh1> henrix, a fresh install this morning didn't pull it in.
[14:31] <henrix> alexbligh1: after the 'apt-get update', a 'apt-get dist-upgrade' should do the job
[14:32] <alexbligh1> henrix, we used 'aptitude full-upgrade'. I'll try that too. It's also not appearing in a debootstrap build. Something odd is going on.
[14:37] <infinity> alexbligh1: It's been upgraded just fine.
[14:38] <infinity> alexbligh1: If you have linux-generic-lts-utopic 3.16.0.31.24, that depends on linux-image-3.16.0-31-generic
[14:38] <alexbligh1> infinity, henrix: DaGoaty and I are currently working on a PEBCAK error
[14:38] <infinity> alexbligh1: You can't have one without the other.
[14:40] <alexbligh1> henrix, infinity sorry for the noise. Looks like what happened was we expected an update as of the CVE date, but it would appear we'd already got the update earlier. Then we looked at the meta package version not the image version when we didn't see another update. Sigh.
[14:41] <henrix> alexbligh1: no prob!
[15:13] <tinoco> hey guys
[15:13] <tinoco> oops wrong #
[17:57] <slangasek> smb: hi - question regarding nfs kernel interfaces
[17:59] <smb> slangasek, you may try your luck...
[17:59] <slangasek> smb: after switching to the nfs-utils systemd units, I noticed that rpc.idmapd wasn't being started on clients, only on servers; it turns out that, according to upstream, it's superseded by an upcall to /usr/sbin/nfsidmap
[18:00] <slangasek> smb: can you help me figure out what kernel introduced support for this upcall?  I know that it was there at least in Linux 3.5 (http://serverfault.com/questions/415908/nfs4-rpc-idmapd-or-nfs-idmap-upcall)
[18:00] <slangasek> that's obviously enough to cover us for LTS upgrades, but in the unlikely event that we had someone wanting to support NFS on an android kernel :P, I'd like to know what our story is
[18:01] <smb> slangasek, I can try... give me a few minutes
[18:01] <slangasek> smb: cheers
[18:16] <smb> slangasek, So it seems the "new" method was introduced (added to Documentation/filesystems/nfs/idmapper.txt) with 2.6.37. However for a while (until 3.4) it required an option (NFS_USE_NEW_IDMAPPER) to be set at compile time. Which we did not do in Precise (3.2). Starting with 3.4 this was replaced by making new the default but automatically fall back (e6499c6f4b5f56a16f8b8ef60529c1da28b13aea NFS: Fall back on old 
[18:16] <smb> idmapper if request_key() fails)
[18:16] <smb> slangasek, Is that enough to help you?
[18:17] <slangasek> smb: yes, thanks