[01:45] Prf_Jakob, how about as a pull requestion pointing at your public git repo? [01:59] bjf: kay, where is the ubuntu kernel located, due to holidays I'm only the messanger in this case. === gerald is now known as Guest75034 === edamato is now known as edu-afk [04:42] Prf_Jakob, git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git [05:03] thanks === AceLan_ is now known as AceLan [07:46] moin [08:16] Morning [09:16] rtg was faster than me, doh! [09:30] ppisati, ? [09:54] apw: i filled up an lp bug and for a staging-driver inclusion, but i didn't send the pull req yet [09:54] apw: woke up this morning just to find out that he dit it :) [09:54] proactive merging :) [10:12] heh [11:42] ppisati, that is actually more like psychic mergine [11:59] can this small addition to a device tree be added to trusty-unstable kernel (3.14)? [11:59] https://gitorious.org/ac100/marvin24s-kernel/commit/380d2091525792a7df5b7b948d07174bd602cb97 [11:59] this is the last missing piece to get my ac100 booting out of the box [12:58] ppisati, ^^ [13:31] apw: looking right now [13:44] given that it touches only the paz00 dts (aka ac100), i'm ok with it [13:44] just a question, did you try to upstream it? [13:44] marvin24: ^ [13:53] smb, hey have you used lxc subuid stuff? what does a default entry look like for moi [13:54] apw, No, I am ignoring lxc as hard as I can [13:55] smb, heh ok [13:55] sforshee, Maybe you had more time to play with that? [13:56] apw, I think I remember some mapping statements but not well enough [13:57] apw: did you read stgraber's blog post? It's a really nice guide to setting that up. [13:57] https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ [13:57] apw, ^ Just got there too [13:57] :) [13:58] sforshee, thanks [13:58] ppisati: it's upstreamed already, but for 3.15 only [13:58] in fact, I was a few hours too late :-( [13:58] thanks! [13:59] 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] lxc_container: Could not set clone_children to 1 for cpuset hierarchy in parent cgroup. [14:08] sforshee, seen that ? [14:09] stgraber, hey ... user containers, can you have disjoint uid mappings such as below: [14:09] apw:200000:65537 [14:09] apw:1000:1 [14:10] lxc.id_map = u 0 1000 1 [14:10] lxc.id_map = u 1 200000 65535 [14:10] stylee ? [14:11] hallyn, about ? i am having trouble using your reproduce by instructions, my containers won't start [14:14] marvin24: Will that DT work with 3.13 too, or only 3.14+? [14:14] infinity: it won't work because it requires updates to the pwm and drm subsystem [14:14] then ... [14:14] a bit unfortune for trusty, but well ... [14:14] marvin24: I was afraid you'd say something like that. [14:15] not much point in pulling in the dt parts then [14:15] apw: He was asking for it to be pulled into unstable, not master. [14:16] 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] Probably. [14:17] 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] infinity: I had 3.14 in mind, which may be the standard kernel at this time [14:18] 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] infinity: I'm not sure which one we need, but I can find out [14:18] this may also be helpful for other SoCs [14:18] which have problems to get the backlight up [14:19] There are pills for that. [14:20] infinity, i would guess 17 [14:27] seems that it is only useful for tegra now as the drm/kms drivers also needs some change [14:27] not worth the effort [14:35] zequence: Are you going to get around to regression-testing the lowlatency SRU kernels? [14:36] 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] apw: yes, you can [14:43] 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] apw: I take it your current uid is 1000 right? [14:45] apw: if so, you don't have to put it in /etc/subuid as you own it already anyway [14:47] stgraber, yeah that is me [14:47] stgraber, and i had the right incantion in the other bit ? [14:53] 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] apw: I'm assuming you've put similar ranges as "g " entries and a matching line in /etc/subgid? [14:55] 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] lxc.id_map = u 0 1000 1 [14:55] lxc.id_map = u 1 200000 65535 [14:55] lxc.id_map = g 0 1000 1 [14:55] lxc.id_map = g 1 200000 65535 [14:56] and a create does this: [14:56] newuidmap: write to uid_map failed: Invalid argument [14:59] apw: why do you have the 'u 0 1000 1" lines? [14:59] or is it: [14:59] lxc.id_map = u 0 1000 1 1 200000 65535 [14:59] lxc.id_map = g 0 1000 1 1 200000 65535 [14:59] hallyn, i am trying to map container 0 to my main id for convienience [15:00] not that that works either, hurumph [15:00] no that won't work [15:00] well the first set of 4 looks ok [15:00] neither work [15:00] infinity: yep. I'll do it today sometime [15:00] zequence: Awesome, thanks. [15:01] 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] 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] lxc-create was failing trying to get to .local/share/lxc or similar, without a heap of acls [15:05] apw: it looks like a bug. It's trying to run newuidmap on the same task twice which isn't doable [15:06] 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] anyhow, with a heap of acls, things "work" [15:08] apw: no, lxc_usernsexec is supposed to just run newuidmap once. [15:09] 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] containers [15:09] apw: nnnot. really... [15:10] you're not actually root in your container unless you start a new container anyway [15:10] indeed, but a lot of the filessytem is my root id, which is handy [15:12] if you trust your container :) [15:12] mind you, this is a huge bug, and i'm quite certain a regression. your use case should be supported [15:12] in this case i prolly do indeed [15:13] MAN dh_shlibs is slow [15:13] apw: having received no response i was going to write/test/send a patch using vfssetxattr_noperms for trusted.overlafys today [15:14] stgraber: bad news, commit 0e6e3a41089c86447fef18e54c2796b312a57a94 broke it [15:14] hm, that's not the commit id :) [15:15] oh it is, it hels if i'm in a git tree to view it [15:17] hallyn: oh, hmm, so what did I break exactly? :) [15:17] apw: so you're using ppa:ubuntu-lxc/daily ? (the commit hallyn mentioned hasn't made it to the archive yet) [15:18] nope, not me, i use whats in the archive [15:18] hallyn: because I use multiple uid/gid ranges with my containers here and that clearly works... [15:18] 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] that explains that then, get 'er uploaded :) [15:20] apw: hm, then i'm confused [15:21] ill go have breakfast. bll [15:21] hallyn, i think it all makes sense now, i am doing somthing 101 will be able to do [15:21] so i'll stop doing that, cause it hurts, and add a heap of acls [15:32] jodh, jsalisbury: whats the story on CONFIG_IPMI_HANDLER ? Is it going back to being a module ? [15:35] I'd recommend against doing that [15:35] Anything that uses IPMI operation regions may be randomly broken [15:35] 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] apw: just to be sure, dpkg -l | grep lxc? [15:35] apw: what you do should be supported. [15:36] s/fixed as a module/built in/ in 3.14 [15:37] mjg59, looks like they are still working on it. I'll leave it built-in for now. [15:41] Oh I think I see the *actual* bug :) [15:42] ii lxc 1.0.0-0ubuntu4 amd64 Linux Containers userspace tools [15:45] apw: i have a fix. will send a in a bit to the list, [15:45] if you want to build your own, patch is http://paste.ubuntu.com/7033605/ [15:54] ** [15:54] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [15:54] ** [16:58] ## [16:58] ## Kernel team meeting in 3 minutes - #ubuntu-meeting ## [17:00] infinity: Will do === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 18th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:59] rtg, you have prolly already noticed, but i pushed that config revert some time ago [18:00] apw, yup [18:01] 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] rtg, did you get a broken out version? [18:04] I was working on it, but there is some confusing non-linearity [18:19] nasty indeed [18:20] 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] hallyn, just building you some test kernels with my patch applied, will post a link shortly if you could test [18:21] apw: oh. i'm working with that righ tnow too [18:21] 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] just using _noperm doesn't seem tow ork right [18:22] 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] so i'm trying a build where i set the userns in the override creds [18:23] hallyn, right that is what i ahve done, [18:24] ah [18:24] hallyn, do do it the other way you have to use them for reading as well (non-perm versions) [18:24] then we can see if we ended up with the same the exact same patch :) [18:24] and if not, why [18:24] and its jsut a mess, i have one of those working too, but the cred ns hack seems to work here [18:25] hallyn, http://people.canonical.com/~apw/overlayfs-perms2-trusty/0001-UBUNTU-ubuntu-overlayfs20-switch-to-the-init-user-na.patch [18:26] apw: looks good, thanks - I'll wait for yours to build then and test it. [18:28] hallyn, cool, should be soon ... [18:31] 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] 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] hallyn, yeah, i recon there should be a "creds_ns(foo)" at least [18:34] more likely a "override_creds_system()" or similar [18:34] hallyn, kernels at: http://people.canonical.com/~apw/overlayfs-perms2-trusty/ [18:34] let me know how you fare, they seem to work for me [18:35] thx, will do [18:42] apw: looks good [18:42] no wait [18:43] hallyn, ? [18:43] heh, sudo misuse. looks good :) [18:43] * apw slips out for an hour, will check in when i get back :) [20:31] apw: oh fwiw, patch is doing great. [20:54] "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] 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] hallyn, sweet, i'll push that on tommorrow, and shove it up as well [22:48] 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] 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] 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] 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] yep, we never make d-i from those images, nor use the full packaging flow either, they are just test builds [23:07] I see [23:07] ok, I was just concerned I was missing something since it didn't build clean [23:07] you likely can get it to work without those, disable_d_i=true or similar disables that [23:07] ok, thank you [23:07] nope they are dirty hacks to get something for every tag, they are not intended to pass an uploaders review [23:13] cheers all, have a nice day