[01:28] "el desempleo un mecanismo creado por el capitalismo para oprimir los pueblos y poder mantener las ganancias millonarias" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival* === DalekSec_ is now known as DalekSec === henrix_ is now known as henrix [08:18] moin [08:19] apw: ping regarding that bug you requested a follow up on regarding multi touch track pad no response on upstream mailing list :( [09:08] * apw yawns [09:08] ppisati, moin [09:09] * smb has coffee [09:09] moin2 [09:09] eagles0513875, upstream is a slow grinding place, i'd expect a couple of days turn round before response [09:09] smb, a good plan [09:09] smb, re-moin [09:17] apw: im just worried it might fall through the cracks again [09:38] could easily do indeed [09:55] apw: how can we push that it gets looked at [10:00] a difficult one when they won't respond [10:00] being insistant in a polite way normally works in my experience [10:02] apw: ok ill give it a few days [10:03] yeah it just needs monitoring === davmor2_ is now known as davmor2 === Trevinho_ is now known as Trevinho === zequence_ is now known as zequence [13:57] rtg: "Use Chromium on Linux? Adobe Flash Will Stop Working From April" [13:57] rtg: http://www.omgubuntu.co.uk/2014/01/chromium-npapi-flash-dropped-april-2014 [13:57] ppisati, installing the package suggested by sconklin did the trick [13:58] rtg: which one? [13:58] ppisati, hang on a sec... [13:58] ppisati, chromium-codecs-ffmpeg-extra [13:58] rtg: let me try... [13:58] * apw confirms that very package fixed things on one of his laptops [14:18] apw, gotta whack on trusty HEAD. I messed up the startnewrelease [14:18] rtg, i just pushed a chunk of config changes [14:18] apw, yep, I checked first [14:18] ack [14:19] rtg, let me know when its pushed so i can rebase [14:21] apw, done [14:22] now, one moretest build to make sure I've got the modules check correct [14:22] rtg, wierd you signed all my commits off ;) [14:22] uh, just habit I guess. [14:22] git am -s [14:23] odd, you must 'replace' a commit in a completley different way to me [14:23] apw, just this time. I knew I would have conflicts, so I just made your stuff patches, then reapplied [14:24] i'd normally revert the original, make a new one, then rebase -i back to the original and squash them together [14:24] I think it would be handy to be able to cherry-pick a range of SHA1's [14:25] that is mostly what rebase does [14:25] you use -i and then hack the list about [14:26] apw, its just all in how you look at it. [14:26] true indeed [14:26] git is both a hammer and a nail gun [14:26] apw, sidenote - I was able to compile android-msm-flo-3.4-kitkat-mr1 with Trusty gcc-4.6 native [14:27] great [14:27] kind of slow even on a calxeda [14:27] now, on to packaging [14:58] hey there, because I spend any more time on this, is there any known apparmor problem with the new 3.13 kernel? [14:58] it looks like we don't have all of jjohansen's changes and that's making stuff blow up [14:58] stgraber, not that we've noticed. jjohansen ? [14:59] rtg: I guess adding a "/etc/init.d/apparmor reload" to your post-rebase tests would be a good idea then :) [14:59] as that's how I usually detect that things are broken apparmor-wise (well, that and people shouting at me because LXC is broken and none of the QA stuff runs anymore) [15:00] hmmm, just thecked and our apparmour test is failing in our automatic testing [15:01] s/thecked/checked/ [15:01] stgraber, I've been assuming AA works from a cold boot 'cause I'm getting a IP address [15:11] stgraber, "it looks like" how are you detecting that [15:12] apw: "/etc/init.d/apparmor reload" is complaining heavily [15:13] apw: so it looks like we're missing the patches for the dbus rules, network rules and mount rules. That latter is causing problems with LXC which broke all of the CI desktop testing (I've proposed a few workarounds for them though) [15:15] stgraber, well woopy doo, shows how useless our testing is indeed [15:21] rtg, this might be tractible [15:21] stgraber: what kind of lxc problems does this cause? Because I've been failing in trying to create a container with a privete user namespace that will actually start. [15:23] sforshee: that bug shouldn't affect unprivileged containers (as I've been using them with the 3.13 from the kernel team PPA) but setting up cgroups so that those containers are happy is slightly tricky [15:23] sforshee: (I have a blog post ready for that, just waiting for slangasek to upload a fixed pam) [15:24] stgraber: bascially I'm doing lxc-create; container-userns-convert; lxc-start; then I get "failed to get real path" for the rootfs [15:26] sforshee: I never the convert tool myself, I usually do a straight lxc-create -t ubuntu-cloud -n -f user-lxc.conf [15:27] sforshee: then with the right cgroup setup ($NAME/lxc in all controllers with $NAME chowned to the user and the current shell in $NAME/lxc/tasks), I can do lxc-start just fine [15:27] stgraber: I'll try that, thanks [15:30] tseliot: did you solve the issue with nvidia that popey was suffering with yesterday? I only ask as I'm still getting low gfx mode on start up using 3.13 [15:31] davmor2: its fine for me today after updating and rebooting [15:31] davmor2, i am pretty sure that he uploaded a new nvidia for that [15:31] davmor2: yes, I did [15:32] tseliot: it might be that optimus hates you then :( let me uninstall and try again [15:32] davmor2: it's hard to tell without any logs or clues [15:33] davmor2: make sure the linux headers for your kernel are installed (and the linux-generic metapackage) [15:34] davmor2: and reinstall the nvidia driver [15:34] (the latest release) [16:02] apw, is there a reason for CONFIG_MLX4_DEBUG to be different in ppc64el ? debian.master/config/ppc64el/config.common.ppc64el:CONFIG_MLX4_DEBUG=y [16:02] rtg, likely not, i am working my way down the list slowly, its pretty long [16:02] apw, ok [16:03] if it is hurting you likely you can flip it, else ignore it and i'll wack it when i get there [16:03] apw, nope, I just happened to notice it whilst researching another topic [16:03] ok it is much easier conflicts wise if you leave it be then :) [16:03] np [16:32] rtg, should we have the auto-abi-bumper patch on this branch [16:33] arges, so you are asking henrix and kamal about the proper proceedure here? [16:34] henrix: kamal : hey guys. I have a set of 4 patches (https://lkml.org/lkml/2013/10/16/818) that would make sense for stable. I've already sent one patch to stable and it was accepted. Whats the best way to format this email that makes it easier for everybody [16:34] I've already cherry-picked and build tested from 3.4 > and its clean and builds [16:34] apw, prolly a good idea [16:35] rtg, will grub it [16:35] grab [16:36] arges: so, if they are clean cherry-picks, you can simply send the email with the list of SHA1s to stable@ [16:36] henrix: one email per hash? [16:37] arges: no, you can list them all in the same email. just make sure you specify the stable series you want them to be applied to [16:37] arges: let me try to find you an example.. [16:38] henrix: thanks. [16:43] arges: sorry, got distracted with something else... :p here's 2 examples [16:43] arges: http://article.gmane.org/gmane.linux.kernel.stable/54115/ and http://article.gmane.org/gmane.linux.kernel.stable/64503 [16:43] henrix: great! that's easy enough [16:43] arges: something like the above should be enough [16:43] thanks [16:43] np === medberry is now known as med_ [17:07] rtg, i am wanting to shift a commit down the stack and bump the abi in the newrelease, is the tree stable ? [17:07] (master-next only) [17:08] apw, yep, I'm working on the flo branch [17:08] rtg i noticed when i got 50M of stuff :) [17:08] apw, prolly wondered wtf I was doing, huh ? [17:09] rtg, as you see the objects long before the new branch is metioned ... yeah :) [17:14] apw, by the way, I figured out that one can cross compile the flo branch under precise-amd64. dunno why I didn't think of that yesterday. too many distractions I guess. [17:14] rtg, a good point, as that is exactly waht i have done with them myself, DOH [17:15] for the 3.0 ones [17:15] flo is 3.4 [17:15] yeah, but i have done what you suggested before, and forgotten [17:47] apw: infinity: I'd like to apply for uploading rights for the Ubuntu Studio package set, and was wondering if one of you would be kind enough to add something to my application page, under "endorsements" https://wiki.ubuntu.com/zequence/DeveloperApplication#Endorsements === josepht_ is now known as josepht [19:27] jjohansen: how is the apparmor mount set upstreaming looking? (i havent' followed it on lkml at all) [19:36] hallyn: its waiting of the labeling work which is still getting revisions [19:36] hallyn: it will comes its just been slow [19:39] jjohansen: what is the eta for a patchset to hit the 3.13 kernel that's in trusty? [19:39] hallyn: I will send it today [19:39] jjohansen: thanks. [19:40] hallyn: I've been trying to reproduce bug #1263738 but my containers with private user namespaces won't start. Is there a guide somewhere on how to set that up properly? [19:40] Launchpad bug 1263738 in lxc (Ubuntu Trusty) "login console 0 in user namespace container is not configured right" [High,Triaged] https://launchpad.net/bugs/1263738 [19:42] hallyn: lxc-start says "Permission denied - failed to get real path for ..." [19:43] for what? :) [19:43] it's the container rootfs [19:43] I'm guessing you have a cgroup issue. you need to do: [19:43] sforshee: let me put up a wiki page with instructions, gimme a bit [19:43] hallyn: okay, thanks! [19:54] sforshee: i'll stick it in a wiki later (dont wanna deal with formatting right now) but: http://people.canonical.com/~serge/userns.wiki [19:54] you'll probably find some errors or something i forgot to put in. [19:54] stgraber: (^ you might have input as well) [19:56] hallyn: awesome, I'll try it out in a few minutes [19:57] sforshee: I'm about to go run an errand, but will look for any comments when i get back. then i'll put it on the wiki tonight. maybe it actually should go on linuxcontainers.org... [19:57] * hallyn bbl [20:02] hallyn: I'll have a well formatted blog post up soonish with that, just waiting for pam to land in the archive first [20:39] hallyn: it's still not working, here's what lxc-start says: [20:39] lxc_container: Permission denied - failed with errno 13 to create /usr/lib/x86_64-linux-gnu/lxc/dev/lxc [20:39] lxc_container: failed to setup the console for 'c1' [20:39] lxc_container: failed to setup the container [20:39] lxc_container: invalid sequence number 1. expected 2 [20:39] lxc_container: failed to spawn 'c1' [20:40] hallyn: also a few comments on the istructions [20:41] 1. In step 7 I had to use sudo, not sure if that's expected or not [20:41] 2. In step 9 you have a typo: memory/use_hierarchy [20:42] 3. I also had to use sudo in step 11 [20:42] 4. Step 12: s/#HOME/$HOME/ [21:08] sforshee: if you used sudo in step 7 then yo uwon't be able to start the container. [21:10] hallyn: I couldn't create the container without using sudo though [21:10] what happened [21:11] mapped_uid is .9999. [21:11] ubuntu-cloudimg-query is /usr/bin/ubuntu-cloudimg-query [21:11] wget is /usr/bin/wget [21:11] cp: failed to preserve ownership for ‘/tmp/ubuntu-cloudimg-query.rSlpz4/trusty.server.released-dl.current.txt’: Invalid argument [21:11] failed to get https://cloud-images.ubuntu.com/query/trusty/server/released-dl.current.txt [21:11] lxc_container: container creation template for c1 failed [21:11] lxc_container: Error destroying container directory for c1 [21:11] lxc_container: Error creating container c1 [21:11] hallyn: ^ [21:13] mapped_uid is .9999. <- can you paste your lxc.conf? [21:13] (it sounds like you used $MAPUID without defining it) [21:14] lxc.id_map = u 0 100000 9999 [21:14] lxc.id_map = g 0 100000 9999 [21:14] lxc.network.type = veth [21:14] lxc.network.link = lxcbr0 [21:14] note since you've created one as root, you should probably sudo rm -rf ~/lxcbase; mkdir ~/lxcbase [21:14] hm,m that looks ok. [21:14] and what is your /etc/subuid entry? [21:15] sforshee:100000:10001 [21:16] hallyn: since then I've installed some updates which included lxc packages and rebooted the machine, now it doesn't work at all [21:16] lxc-create just says "Error creating container c1" [21:16] I get the c1 directory but no files in it [21:18] I should probably mention that I'm using lxc from the ppa [21:18] huh. lemme restart from scratch [21:19] sforshee: oh wait. are you on 3.13 kernel now? [21:19] hallyn: yep [21:19] if so pls revert to 3.12. [21:19] but that won't fix all problems. i'm reproducing right now... [21:29] sforshee: huh. it's working for me. on a fresh ec2 trusty instance [21:30] sforshee: can you pastebin your lxc.conf and the commands you type and results? [21:31] hallyn: just a second, still trying to test with 3.12. I think there's still some screwed up permissions from when I did lxc-create with sudo. [21:31] ok [21:32] hm, now network didn't come up. Not sure if that's something fixed in ppa. [21:34] hallyn: I had a couple of directories in ~/.cache which were owned by root. I blew them away and now lxc-create is running, I'll see how it goes. [21:35] cool [21:42] sforshee: yeah so for networking to work, you do need ppa:ubuntu-lxc/daily for now [21:43] sforshee: updated the copy of that file. I'm going to wait to see stgraber's blog entry before deciding whether to put up a wiki page I guess [21:43] hallyn: I'm already using the ppa version. The container is running now. [21:45] hallyn: but based on 'readlink /proc/pid/ns/user' it looks like it's in the same namespace [21:45] and you created and ran it without sudo? [21:45] yep, no sudo [21:46] then you shouldn't be able to be root in the container without being in another ns. which two pids are you comparing? [21:46] I screwed up, let me look again [21:47] k [21:47] ok, they are different [21:47] I forgot to ssh back in on my second terminal after rebooting :-/ [21:48] so then it all seems to be working, except the part where I reproduce the bug [21:49] what do you mean? [21:49] if you control-c in the console your container doesn't reboot? [21:50] ah, it does [21:50] perfect [21:50] thanks a lot for your help! [21:58] sforshee: np. and so now look at the login process in the container and look at its /proc/pid/*, and you'll see the files owned by GLOBAL_ROOT_UID (which becomes -1 in the container)