[01:45] <bjf> Prf_Jakob, how about as a pull requestion pointing at your public git repo?
[01:59] <Prf_Jakob> bjf: kay, where is the ubuntu kernel located, due to holidays I'm only the messanger in this case.
[04:42] <bjf> Prf_Jakob, git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
[05:03] <Prf_Jakob> thanks
[07:46] <ppisati> moin
[08:16] <smb> Morning
[09:16] <ppisati> rtg was faster than me, doh!
[09:30] <apw> ppisati, ?
[09:54] <ppisati> apw: i filled up an lp bug and for a staging-driver inclusion, but i didn't send the pull req yet
[09:54] <ppisati> apw: woke up this morning just to find out that he dit it :)
[09:54] <ppisati> proactive merging :)
[10:12] <apw> heh
[11:42] <apw> ppisati, that is actually more like psychic mergine
[11:59] <marvin24> can this small addition to a device tree be added to trusty-unstable kernel (3.14)?
[11:59] <marvin24> https://gitorious.org/ac100/marvin24s-kernel/commit/380d2091525792a7df5b7b948d07174bd602cb97
[11:59] <marvin24> this is the last missing piece to get my ac100 booting out of the box
[12:58] <apw> ppisati, ^^
[13:31] <ppisati> apw: looking right now
[13:44] <ppisati> given that it touches only the paz00 dts (aka ac100), i'm ok with it
[13:44] <ppisati> just a question, did you try to upstream it?
[13:44] <ppisati> marvin24: ^
[13:53] <apw> smb, hey have you used lxc subuid stuff?  what does a default entry look like for moi
[13:54] <smb> apw, No, I am ignoring lxc as hard as I can
[13:55] <apw> smb, heh ok
[13:55] <smb> sforshee, Maybe you had more time to play with that?
[13:56] <smb> apw, I think I remember some mapping statements but not well enough
[13:57] <sforshee> apw: did you read stgraber's blog post? It's a really nice guide to setting that up.
[13:57] <smb> https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
[13:57] <smb> apw, ^ Just got there too
[13:57] <smb> :)
[13:58] <apw> sforshee, thanks
[13:58] <marvin24> ppisati: it's upstreamed already, but for 3.15 only
[13:58] <marvin24> in fact, I was a few hours too late :-(
[13:58] <marvin24> thanks!
[13:59] <marvin24> FYI: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/tegra20-paz00.dts?id=5816898b9592b877209e91c493db946ab275d825
[14:08] <apw> lxc_container: Could not set clone_children to 1 for cpuset hierarchy in parent cgroup.
[14:08] <apw> sforshee, seen that ?
[14:09] <apw> stgraber, hey ... user containers, can you have disjoint uid mappings such as below:
[14:09] <apw> apw:200000:65537
[14:09] <apw> apw:1000:1
[14:10] <apw> lxc.id_map = u 0 1000 1
[14:10] <apw> lxc.id_map = u 1 200000 65535
[14:10] <apw> stylee ?
[14:11] <apw> hallyn, about ?  i am having trouble using your reproduce by instructions, my containers won't start
[14:14] <infinity> marvin24: Will that DT work with 3.13 too, or only 3.14+?
[14:14] <marvin24> infinity: it won't work because it requires updates to the pwm and drm subsystem
[14:14] <apw> then ... 
[14:14] <marvin24> a bit unfortune for trusty, but well ...
[14:14] <infinity> marvin24: I was afraid you'd say something like that.
[14:15] <apw> not much point in pulling in the dt parts then
[14:15] <infinity> apw: He was asking for it to be pulled into unstable, not master.
[14:16] <infinity> That said, by the time trusty releases, unstable will have rolled over to 3.15rc, I suppose, and will include the commit from linux-next.
[14:16] <infinity> Probably.
[14:17] <infinity> marvin24: More curiously, are the other commits it depends on reasonably small and backportable to 3.13, or would that blow up the world (or cause our kernel team to vomit)?
[14:17] <marvin24> infinity: I had 3.14 in mind, which may be the standard kernel at this time
[14:18] <infinity> marvin24: Cause if we can make your platform go with trusty's generic kernel with very little effort, I doubt we'd say no.
[14:18]  * ppisati usually vomits for no apparent reason
[14:18] <marvin24> infinity: I'm not sure which one we need, but I can find out
[14:18] <marvin24> this may also be helpful for other SoCs
[14:18] <marvin24> which have problems to get the backlight up
[14:19] <infinity> There are pills for that.
[14:20] <apw> infinity, i would guess 17
[14:27] <marvin24> seems that it is only useful for tegra now as the drm/kms drivers also needs some change
[14:27] <marvin24> not worth the effort
[14:35] <infinity> zequence: Are you going to get around to regression-testing the lowlatency SRU kernels?
[14:36] <infinity> BenC: Can you smoketest the saucy linux-ppc kernels in -proposed on some of your kit?  I'm not home this week, so can't test on any of mine.
[14:42] <stgraber> apw: yes, you can
[14:43] <apw> stgraber, don't seem to be able to write it such that it will actually work, it just barf at the newuidthing step
[14:45] <stgraber> apw: I take it your current uid is 1000 right?
[14:45] <stgraber> apw: if so, you don't have to put it in /etc/subuid as you own it already anyway
[14:47] <apw> stgraber, yeah that is me
[14:47] <apw> stgraber, and i had the right incantion in the other bit ?
[14:53] <stgraber> apw: I think the rest is fine, I'm just not sure the multi-line subuid is valid, so I'd just go with "apw:200000:65537" as the second one isn't required anyway
[14:53] <stgraber> apw: I'm assuming you've put similar ranges as "g " entries and a matching line in /etc/subgid?
[14:55] <apw> stgraber, yeah, ok so now i have one line in subuid/gid giving me the 200000 range and the below in default.conf:
[14:55] <apw> lxc.id_map = u 0 1000 1
[14:55] <apw> lxc.id_map = u 1 200000 65535
[14:55] <apw> lxc.id_map = g 0 1000 1
[14:55] <apw> lxc.id_map = g 1 200000 65535
[14:56] <apw> and a create does this:
[14:56] <apw> newuidmap: write to uid_map failed: Invalid argument
[14:59] <hallyn> apw: why do you have the 'u 0 1000 1" lines?
[14:59] <apw> or is it:
[14:59] <apw> lxc.id_map = u 0 1000 1 1 200000 65535
[14:59] <apw> lxc.id_map = g 0 1000 1 1 200000 65535
[14:59] <apw> hallyn, i am trying to map container 0 to my main id for convienience
[15:00] <apw> not that that works either, hurumph
[15:00] <hallyn> no that won't work
[15:00] <hallyn> well the first set of 4 looks ok
[15:00] <apw> neither work
[15:00] <zequence> infinity: yep. I'll do it today sometime
[15:00] <infinity> zequence: Awesome, thanks.
[15:01] <hallyn> apw: but you say "for convenience";  lxc-create sets up the rootfs so it shouldn't really be needed...  so is lxc-create failing, or lxc-start?
[15:02] <apw> lxc-create is fialing with my setup using 0 == 1000, i was trying to do that to avoid having to have acls all over the place for 20000
[15:04] <apw> lxc-create was failing trying to get to .local/share/lxc or similar, without a heap of acls
[15:05] <hallyn> apw: it looks like a bug.  It's trying to run newuidmap on the same task twice which isn't doable
[15:06] <apw> hallyn, that is kinda why i thought i might have to put them on the one line, as the command line for newuidfoo would look like that, no dice that way either
[15:07] <apw> anyhow, with a heap of acls, things "work"
[15:08] <hallyn> apw: no, lxc_usernsexec is supposed to just run newuidmap once.
[15:09] <apw> hallyn, it does seem most logical to me to use my own id as root, so i can float round in my containes
[15:09] <apw> containers
[15:09] <hallyn> apw: nnnot. really...
[15:10] <hallyn> you're not actually root in your container unless you start a new container anyway
[15:10] <apw> indeed, but a lot of the filessytem is my root id, which is handy
[15:12] <hallyn> if you trust your container :)
[15:12] <hallyn> mind you, this is a huge bug, and i'm quite certain a regression.  your use case should be supported
[15:12] <apw> in this case i prolly do indeed
[15:13] <hallyn> MAN dh_shlibs is slow
[15:13] <hallyn> apw: having received no response i was going to write/test/send a patch using vfssetxattr_noperms for trusted.overlafys today
[15:14] <hallyn> stgraber: bad news, commit 0e6e3a41089c86447fef18e54c2796b312a57a94 broke it
[15:14] <hallyn> hm, that's not the commit id :)
[15:15] <hallyn> oh it is, it hels if i'm in a git tree to view it
[15:17] <stgraber> hallyn: oh, hmm, so what did I break exactly? :)
[15:17] <stgraber> apw: so you're using ppa:ubuntu-lxc/daily ? (the commit hallyn mentioned hasn't made it to the archive yet)
[15:18] <apw> nope, not me, i use whats in the archive
[15:18] <stgraber> hallyn: because I use multiple uid/gid ranges with my containers here and that clearly works...
[15:18] <stgraber> hallyn: right, so apw is using lxc 1.0.0 final which didn't have that commit (that commit is aimed at 1.0.1)
[15:18] <apw> that explains that then, get 'er uploaded :)
[15:20] <hallyn> apw: hm, then i'm confused
[15:21] <hallyn> ill go have breakfast.  bll
[15:21] <apw> hallyn, i think it all makes sense now, i am doing somthing 101 will be able to do
[15:21] <apw> so i'll stop doing that, cause it hurts, and add a heap of acls
[15:32] <rtg> jodh, jsalisbury: whats the story on CONFIG_IPMI_HANDLER ? Is it going back to being a module ?
[15:35] <mjg59> I'd recommend against doing that
[15:35] <mjg59> Anything that uses IPMI operation regions may be randomly broken
[15:35] <jsalisbury> rtg, configuring CONFIG_IPMI_HANDLER as a module fixes the bug, but it is also fixed as a module in 3.14 mainline, so we were also performing a revese bisect
[15:35] <hallyn> apw: just to be sure, dpkg -l | grep lxc?
[15:35] <hallyn> apw: what you do should be supported.
[15:36] <jsalisbury> s/fixed as a module/built in/ in 3.14
[15:37] <rtg> mjg59, looks like they are still working on it. I'll leave it built-in for now.
[15:41] <hallyn> Oh I think I see the *actual* bug :)
[15:42] <apw> ii  lxc                                                   1.0.0-0ubuntu4                         amd64        Linux Containers userspace tools
[15:45] <hallyn> apw: i have a fix.  will send a in a bit to the list,
[15:45] <hallyn> if you want to build your own, patch is http://paste.ubuntu.com/7033605/
[15:54] <jsalisbury> **
[15:54] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:54] <jsalisbury> **
[16:58] <jsalisbury> ##
[16:58] <jsalisbury> ## Kernel team meeting in 3 minutes - #ubuntu-meeting ##
[17:00] <BenC> infinity: Will do
[17:59] <apw> rtg, you have prolly already noticed, but i pushed that config revert some time ago
[18:00] <rtg> apw, yup
[18:01] <rtg> apw, I'm messing with vmwgfx. If I can figure it out, then I'll upload later today. never can have too many kernels.
[18:04] <apw> rtg, did you get a broken out version?
[18:04] <rtg> I was working on it, but there is some confusing non-linearity
[18:19] <apw> nasty indeed
[18:20] <apw> rtg, i guss you can use the "squash" backport for comparison when done
[18:20]  * apw seems to have a working patch for the overlayfs permissions on whiteout when using usernamespaces, one which doesn't make me hurl :)
[18:21] <apw> hallyn, just building you some test kernels with my patch applied, will post a link shortly if you could test
[18:21] <hallyn> apw: oh.  i'm working with that righ tnow too
[18:21] <rtg> apw, it should be a simple matter of applying all of the patches to drivers/gpu/drm/vmwgfx since v3.13, but its kind of driving me nuts.
[18:21] <hallyn> just using _noperm doesn't seem tow ork right
[18:22] <hallyn> well (a) it needs to be gpl exported;  and (b) i may have just done it wrong, but it left me a visible symlink to the overlayfs-whiteout file
[18:22] <hallyn> so i'm trying a build where i set the userns in the override creds
[18:23] <apw> hallyn, right that is what i ahve done, 
[18:24] <hallyn> ah
[18:24] <apw> hallyn, do do it the other way you have to use them for reading as well (non-perm versions)
[18:24] <hallyn> then we can see if we ended up with the same the exact same patch :)
[18:24] <hallyn> and if not, why
[18:24] <apw> and its jsut a mess, i have one of those working too, but the cred ns hack seems to work here
[18:25] <apw> hallyn, http://people.canonical.com/~apw/overlayfs-perms2-trusty/0001-UBUNTU-ubuntu-overlayfs20-switch-to-the-init-user-na.patch
[18:26] <hallyn> apw: looks good, thanks - I'll wait for yours to build then and test it.
[18:28] <apw> hallyn, cool, should be soon ...
[18:31] <apw> hallyn, annoyingly that is what i wanted to do first off, and the mention of the _noperm way side tracked me, i should have listened to self
[18:32] <hallyn> apw: yeah...  now there's a reasonable chance ppl will want your patch to turn into some more general new override_creds() extension.  but we'll see.
[18:34] <apw> hallyn, yeah, i recon there should be a "creds_ns(foo)" at least
[18:34] <apw> more likely a "override_creds_system()" or similar
[18:34] <apw> hallyn, kernels at: http://people.canonical.com/~apw/overlayfs-perms2-trusty/
[18:34] <apw> let me know how you fare, they seem to work for me
[18:35] <hallyn> thx, will do
[18:42] <hallyn> apw: looks good
[18:42] <hallyn> no wait
[18:43] <apw> hallyn, ?
[18:43] <hallyn> heh, sudo misuse.  looks good :)
[18:43]  * apw slips out for an hour, will check in when i get back :)
[20:31] <hallyn> apw: oh fwiw, patch is doing great.
[20:54] <miseria> "los regalos, gustenos o no, hay que agradecer ante todo, el tiempo que esa persona dedico para pensar en ti" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[22:34] <dpippenger> can anyone point me to the repo that contains the source files used to build the kernel located here? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.31-saucy/
[22:47] <apw> hallyn, sweet, i'll push that on tommorrow, and shove it up as well
[22:48] <apw> dpippenger, you need to fetch the commit in the file "COMMIT" from linus' mainline repo, and hten apply the patches in the same directory
[22:50] <dpippenger> those patches seem incomplete, for example they reference firmware files that aren't part of the upstream kernel like bnx2x/bnx2x-e1-7.8.17.0.fw
[23:04] <apw> dpippenger, they are made from that base, and the patches are git format-patch'd from there, so they should be complete; have you tried actually doing that?
[23:06] <dpippenger> yes, I've gotten it to build up until the install phase, but kernel-wedge copy-firmware bombs because newer bnx* firmware is referenced in the packaging patches that generate the control data.
[23:07] <apw> yep, we never make d-i from those images, nor use the full packaging flow either, they are just test builds
[23:07] <dpippenger> I see
[23:07] <dpippenger> ok, I was just concerned I was missing something since it didn't build clean
[23:07] <apw> you likely can get it to work without those, disable_d_i=true or similar disables that
[23:07] <dpippenger> ok, thank you
[23:07] <apw> nope they are dirty hacks to get something for every tag, they are not intended to pass an uploaders review
[23:13] <dpippenger> cheers all, have a nice day