[01:30] PR snapcraft#1139 closed: plainbox-provider plugin: filter out sitecustomize [01:31] PR snapd#2843 opened: cmd/snap-confine: look for PROCFS_SUPER_MAGIC [01:39] PR snapd#2844 opened: dirs: differentiate between "distro" and "core" libexecdir [01:42] PR snapd#2845 opened: dirs: use the right snap mount dir for the distribution [01:43] PR snapd#2846 opened: cmd: autoconf for centos === markusfluer1 is now known as markusfluer [02:20] Bug #1664427 opened: thefuck snap gets an apparmor denial even in classic confinement [02:37] Pharaoh_Atem: around? [02:50] PR snapd#2846 closed: cmd: autoconf for centos [02:53] zyga: hm? [02:54] oh, btw, I think the Fedora EPEL buildroots are actually RHEL systems [02:54] though I'm not sure about that [02:54] so you'll need to add "redhat" [02:54] and "rhel" [02:55] actually, I think the identifier is just "rhel" [02:55] yep, rhel [03:16] zyga: you need to add "rhel" otherwise snap-confine won't build right in epel === chihchun_afk is now known as chihchun [04:17] Bug #1650187 changed: Can't run any snap application on Mint 18 === JanC is now known as Guest77653 === JanC_ is now known as JanC [06:25] ogra_, ping [06:28] ogra_, I cannot console-conf my pi3 device. it just shows that (Client.Timeout exceeded while awaiting headers). error: while creating users: cannot create use 'xxxxx". I have sent an email titled with "Currernt config hook implementation scales very badly". There are some attached picttures there. how can I resolve this problem? [06:28] ogra_, sorry, the email was tittled with "Issue with ubuntu OS snap first time boot." [07:14] lool ping === chihchun is now known as chihchun_afk [08:30] PR snapd#2515 closed: snap run: create "current" symlink in user data dir [09:16] Bug #1664484 opened: Missing interface to record audio from pulseaudio [09:27] liuxg, how is that related to the config hooks ? [09:29] Pharaoh_Atem: hey, I've sent a few patches that make the code work on fedora/centos/rhel [09:29] Pharaoh_Atem: I'll refresh the package once 2.23 which includes those fixes is out [09:59] ogra_, ping [09:59] yes [09:59] i'm here :) [10:00] he is here \o/ [10:03] lol [10:04] ogra_, currently I cannot get my pi3 device console-conf I just reported a bug at https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1664471 [10:04] Bug #1664471: Creating user failed when doing console-conf for raspberry pi3 device [10:04] ogra_, is that a network problem? [10:04] liuxg, sounds like a store bug to me [10:05] or do you have some proxy in place [10:05] ogra_, interestingly, my pi2 device can get the job done. [10:05] both through wired lan ? [10:05] ogra_, no, I do not have any proxy. my colleague in shanghai did get the work done. [10:05] ogra_, yes. [10:05] and through the same lan specifically ? [10:06] ogra_, exactly, the same cable. [10:06] and it is properly plugged ? :) [10:06] ogra_, I think so. otherwise, it cannot go the last step. [10:06] true, you wouldnt get an IP [10:06] (or do you use static ?) [10:07] ogra_, I tried it for the whole morning. I did not set anything, I think. [10:08] ogra_, I just attached the syslog file in the bug report. [10:29] liuxg: pong [10:30] ppisati_: Hi! [10:30] ppisati_: one of the MWC demos is on RPis, and it breaks with a kernel backtrace when refreshing snaps: [10:30] https://bugs.launchpad.net/snapd/+bug/1664368 [10:30] Bug #1664368: snap refresh hangs on arm architecture [10:30] lool, I am now having a problem on console-conf my pi3 device. I reported a bug at https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1664471.. ogra_just now helped me to answer me. [10:30] Bug #1664471: Creating user failed when doing console-conf for raspberry pi3 device [10:31] ppisati_: would you mind scheding some light ont his? [10:31] *this [10:31] liuxg: oh cool, sorry for the delay [10:31] hadn't opened IRC since yesterday morning [10:32] lool, it is ok. :) [10:32] liuxg, your syslog looks fine, i really bet its a login.ubuntu.com issue [10:33] ogra_, yeah, it is a little bit weird. my colleague also experienced the same problem. but he tried a few times more, then it became successful.. [10:33] ogra_, lool another colleague didrocks got 10 mins to configure a device. [10:34] (that was in december, under the same network that I'm complaining snapd to regularly fail) [10:34] yeah, thats rather normal ... still being researched (part of it is that the initial snapd configuration eats all CPU cores at 100% for a while) [10:34] liuxg: btw, I know ogra_ and lool for years (almost 10), no need to present me :) [10:35] isn't it a nice thing though? [10:35] the system is under high load and very slow at that point ... sometimes you are lucky and it is fast ... but thats rather the exception [10:35] lool, well, your CPU is completely eaten ... not sure IO nicing would change that [10:36] haha [10:36] it took me a while to even get the joke, tells you how fried my CPU is [10:36] bug 1632124 btw [10:36] Bug #1632124: snapd pegging cpu at 100% [10:37] oh, mvo closed it ... [10:37] I think you are mixing the snapd network issue with this, but yeah, it could be 2 separated things [10:37] didrocks, if it succeeds it is the systerm load most likely [10:37] (when snapd disconnect, it's really due to the network/snapd interactions, even when io load and CPU are next to 0) [10:38] ogra_: it expired, looking at it again it looks like for the wrong reasons [10:38] yeah [10:39] i know someone dug into it (Chipaca ?) ... but i dont remember it being fixed [10:40] o/ [10:40] hey guys, I've been here just busy with meetings [10:40] stop having meetings then ! [10:40] :) [10:40] I moved all of them to one day [10:41] (next step is to take a day off on that day) ;-) [10:41] do you call it the pain-day ? :) [10:52] lool: replied to that lp bug and assigned to me [10:53] ppisati_: <3 [10:57] didrocks, mvo, hah, my bug search actually failed me ... i was actually meaning bug 1638537 above [10:57] Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 [10:58] the classic does 100% cpu one is indeed in the works [10:58] (silly me, was just searching for "100% CPU" and hit the wrong one) [11:03] ogra_: oh btw, is your classic snap a chroot or a lxd container? [11:04] I was aked when reading the tutorial, I was telling it's a container [11:05] chroot [11:05] we dont have lxd support in the core snap by default [11:05] (you need the lxd snap) [11:08] ogra_: ok, thanks for the clarification :) [11:18] PR snapcraft#1127 closed: Release changelog for 2.27 [11:35] PR snapd#2775 closed: cmd: add functions to load/save fstab-like files [11:35] jdstrand: hey, can you please try to review https://github.com/snapcore/snapd/pull/2827/files today [11:35] PR snapd#2827: cmd: add helpers for mounting / unmounting [11:36] jdstrand: it's based on the earlier mount work and is very small (doesn't get used in snap-confine yet, just adds the library functions) [11:36] jdstrand: using this I can propose nice chunks of update-ns next [11:53] PR snapd#2588 closed: cmd/snap: add shell completion to connect [12:01] PR snapd#2251 closed: interface hooks: support for setting/getting slot/plug attributes with snapctl (step 3) [12:03] PR snapd#2421 closed: tests: add basic test for docker [12:12] PR snapd#2475 closed: tests: nested image testing [12:36] PR snapd#2654 closed: i18n: look into core snaps when checking for translations [12:41] PR snapd#2626 closed: interfaces: relax path requirements for serial [12:42] PR snapd#2847 opened: tests: enable docker test [13:20] pstolowski: hi! Quick question: if an interface is auto-connectable, and then I manually disconnect and reconnect it, will the interface hooks be run at this last step? [13:22] mardy, hey. interesting question, I think they will be run, but to be 100% sure I'd need to check the code [13:22] mardy, btw, my branch #3 landed [13:22] pstolowski: I saw, great stuff! :-) [13:23] pstolowski: should I file a bug to track when the interface hooks will be run for auto-connectable interfaces, or do you already have a task for that? [13:26] mardy, no need for bug, it's on my list I shared with alecu and i've it on my whiteboard at home ;) [13:27] pstolowski: send a pic [13:27] pstolowski: joking ;-) [13:27] he cant, he has all his passwords written there too ;) [13:28] autoconnect is going to be the most complex of all changes, since this code is currently kind of a special case which doesn't work the way connect does [13:32] mardy, http://imgur.com/a/hILGi ;) [13:32] mardy, see, i'm not making this up ;) [13:32] pstolowski: :-D [13:49] PR snapd#2848 opened: cmd/snap-update-ns: add compare function for mount entries [14:10] zyga: historically setuid executables are attacked in their failure conditions [14:12] zyga: everything is typically fine when things go right, but when they go wrong, there may be latent bugs. that is mitigated somewhat on Ubuntu because of the apparmor profile (though it necessarily allows a lot), but many distros don't have that [14:13] jdstrand: I understand that, we could make the debug code somewhat more paranoid (e.g. we could quote the paths and filesystem type) [14:13] zyga: I thought I was quite clear weeks ago that lots of string handling code (ie, a greater attack surface) would not be used in production, only debug [14:13] zyga: and I thought all the new code I was reviewing was working towards that [14:13] jdstrand: I think that right now we still do logging and (and do so less carefully) and this PR was aiming to fix that [14:14] jdstrand: no that wasn't clear, I though you wanted that to be off by default (hence the lazy compute of the command) [14:14] jdstrand: at some point without code like this the debug / die messages are useless [14:14] zyga: I didn't think anything was using sc_mount_cmd yet, as it was only added to the library [14:14] jdstrand: if you want to remove those we need a plan on how the app will be debuggable [14:14] jdstrand: nothing is using it yet, only thew two new calls added in this PR [14:15] zyga: env var aside, it isn't off by default if when you die() you run through all the code [14:15] jdstrand: yes, and I did that on purpose [14:15] I'm confused then [14:15] you just said "I though you wanted that to be off by default" and then you said "I did that on purpose" [14:15] jdstrand: I misunderstood you earlier and I implemented the lazy code so that we don't do it usually [14:16] jdstrand: but we do compute it when the message is needed (either because debug is on or because we need to die) [14:17] jdstrand: if you are saying I cannot, under no conditions, compute the message in production then that's fine [14:17] jdstrand: but what is the app going to do then [14:17] jdstrand: I think this is a reduction in functionality compared to what we have now (hand-made message in each case) [14:17] zyga: I expected the die() to have a simpler must_snprintf hand-made message [14:18] jdstrand: then the whole point of this branch is lost [14:18] no it isn't [14:18] someone trying to reproduce can use it with debugging enabled [14:18] or [14:19] you make this config file option [14:19] and the config file is root owned [14:19] or [14:19] you permanently drop privileges [14:19] jdstrand: nobody will do any of those things when they report a bug with a message they got, for debugging done by an experienced person various things are possible [14:19] jdstrand: actually [14:19] jdstrand: how about that last idea? [14:19] jdstrand: I have a branch for that [14:20] jdstrand: adds library function for dropping/raising/permanently dropping privs [14:20] jdstrand: I did that after the sprint [14:20] zyga: what inexperienced person is going to debug the finer points of snap-confine's mount operations? [14:20] jdstrand: after tyler's suggestion [14:20] jdstrand: exactly, nobody [14:20] jdstrand: so they will just throw a bug with a message that they get [14:20] jdstrand: the point of this branch is to have that message as good as we can use [14:20] zyga: yes, so, an experienced person could flip a setting in a config file [14:21] jdstrand: well, you assume you can reproduce, that's not always the case [14:21] anyway, there is also dropping privileges [14:21] jdstrand: (weird kernel/setting) [14:21] jdstrand: I'd much rather drop privs [14:21] jdstrand: and for the config, that's more parsing (but we can explore that as it would have some value) [14:21] jdstrand: so if you are +1 on doing this after dropping privs then I'll just do it [14:22] if we *permanently* drop privileges, I have no problem [14:22] perfect [14:22] jdstrand: thank you and I'm sorry for the confusion [14:22] jdstrand: I recall we spoke about this as an option (compile time choice) [14:22] jdstrand: but I didn't think we agreed on that [14:22] * jdstrand shrugs [14:22] jdstrand: it's just been in review and iteration for too long and I must have forgotten (the whole mount code change) [14:23] jdstrand: I'll get right to it :) [14:23] jdstrand: oh [14:23] one way to reduce attack surface is to not have the code compiled [14:23] jdstrand: can you review a 3 line difff? [14:23] for the next release tomorrow: https://github.com/snapcore/snapd/pull/2843 [14:23] PR snapd#2843: cmd/snap-confine: look for PROCFS_SUPER_MAGIC [14:23] zyga: I was going to that when you pinged me [14:23] the release is tomorrow? [14:23] jdstrand: this makes snap-confine functional on the 3.10 kernel [14:23] jeez [14:23] jdstrand: I think it is, I'm not sure [14:24] jdstrand: especially with the state of reexec being in the middle [14:24] jdstrand: but mvo mentioned that deadline is tomorrow [14:24] I thought it was always on thursday [14:24] jdstrand: probably what mvo meant was EOD tomorrow is when master feezes [14:25] s/probably/possibly/ (or maybe) [14:25] jdstrand, zyga: 2.23 is EOD tomorrow, I plan to make the 2.23 release in my morning on Thursday [14:26] (not having any more context, I assume this is what you asked?) [14:26] mvo: what is the state of reexec code? [14:26] mvo: yes [14:26] mvo: I think we wanted to polish that to the point where we can reenable everything I removed from the policy [14:26] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662181 # this bug is blocking a couple of snaps - can we get a plan of record on that bug? zyga ? [14:26] zyga: you requested that https://github.com/snapcore/snapd/pull/2749 not land until snap-confine is executed from the core [14:26] Bug #1662181: Aliases didn't enable out of the box [14:26] PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) [14:26] zyga: but there are 3 or 4 PRs that already landed that use arg filtering [14:27] zyga, mvo: does that mean https://github.com/snapcore/snapd/pull/2749 won't be in 2.23? [14:27] popey: that's something for pedronis I think [14:27] jdstrand: I see [14:28] jdstrand: I added it to the 2.23 list, at least it will get priority this way [14:28] also, I thought that snap-confine executed from core was going to land Friday-ish [14:28] I thought I saw it merged, I'm I mistaken? [14:28] mvo: I think that we need to have a clear story on how this is going to affect 2.23, I think it's fine to delay for next week if that is required, otherwise we'd have to do more changes (negative) to the security profiles [14:28] zyga, I left a comment on https://github.com/snapcore/snapd/pull/2845 [14:28] PR snapd#2845: dirs: use the right snap mount dir for the distribution [14:29] jdstrand: snap-confine from core is still under review, I hope we can get this in [14:29] jdstrand: I gave +1 on one of the branches but that will break debian/14.04 I'm sure [14:29] Son_Goku: hey [14:29] zyga: ok, if its fine to delay, w edelay [14:29] Son_Goku: thank you [14:30] let me see if there is anything else that would break. quota and ioctl were the two we undid. I thought there were others [14:30] Son_Goku: replied [14:32] jdstrand: it's not merged yet: https://github.com/snapcore/snapd/pull/2810 [14:32] PR snapd#2810: snap: use snap-confine from the core snap [14:33] zyga: replied ;) [14:35] Son_Goku: replied, also given the merge window closing I think the more elaborate checks will have to wait a few weeks [14:35] okay [14:37] Son_Goku: did you see my tweet last night? [14:37] do we need https://github.com/snapcore/snapd/pull/2844 when https://github.com/snapcore/snapd/pull/2845 already has its commit? [14:37] PR snapd#2844: many: differentiate between "distro" and "core" libexecdir [14:37] PR snapd#2845: dirs: use the right snap mount dir for the distribution [14:37] zyga: I did [14:37] zyga, mvo: the other one I was thinking of was 'setpriority PRIO_PROCESS 0 <=19', but that isn't a problem because PRIO_PROCESS has been in snap-confine for ages [14:38] mvo: it it help if I rebased https://github.com/snapcore/snapd/pull/2749 on https://github.com/snapcore/snapd/pull/2810? is there another way in github to say that one branch depends on another? [14:38] PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) [14:38] PR snapd#2810: snap: use snap-confine from the core snap [14:38] s/it it/would it/ [14:39] * jdstrand remove the netlink rule from https://github.com/snapcore/snapd/pull/2842 since if we allow it, it will be with arg filtering [14:39] PR snapd#2842: interfaces: misc updates for network-control, firewall-control, unity7, x11 and default policy [14:40] jdstrand: maybe, but let me try to get a review for #2810 [14:44] zyga: you available to help me figure out permission errors on the kubelet snap? [14:50] Can you guys have a look at https://bugs.launchpad.net/juju/+bug/1660273 ? It seems like /snap/bin is missing from PATH [14:50] Bug #1660273: /etc/environment does not include /snap/bin in $PATH [14:50] mvo: can you add https://github.com/snapcore/snapd/pull/2842 to the 2.23 list? I reverted the commit that zyga, tyhicks, tsdgeos and I were discussing. the rest has a +1 from zyga [14:50] PR snapd#2842: interfaces: misc updates for network-control, firewall-control, unity7 and default policy [14:50] mvo: so just need another +1 [14:51] Cynerva: hey [14:51] Cynerva: can you tell me more about the problem please [14:51] Cynerva: I'll try to help but I'll be also coding on a few other branches while we speak [14:52] balloons: I just did, can you be more specific please [14:54] zyga: cool, thanks. we're working on a kubelet snap, we have it working with classic confinement, but trying to make it strict [14:55] zyga, ty. /snap/bin is missing from PATH in /etc/environment. This means non-login shells don't have PATH set properly for snaps [14:56] zyga: we're hitting permission errors on several files i can't find an interface for - a bunch related to cgroups, like /proc/self/cgroup, /sys/fs/cgroup/memory, and several others [14:56] zyga: full list is here https://gist.github.com/Cynerva/9150f379cdf1d41aac9ae233597c1f64 [14:57] balloons: I don't think we can add it there, we only add it through /etc/profile.d/apps-bin-path.sh [14:57] zyga: it looks like it's also trying to move the docker pid in /var/run/docker.pid (we have the docker snap installed and connected from stable channel) [14:58] Cynerva: for everything apart from docker: do file a bug report on launchpad.net/snapd, tag it with snapd interface [14:58] Cynerva: snapd-interface (with a dash) [14:59] Cynerva: there's no interface for cgroups that I'm aware of and snapd also uses cgroups in some ways some please describe as much as you can what the app is doing and why [14:59] nessita: are you available to discuss snap store namespaces? I'm wondering if there's a way to either transfer a snap to another namespace, rename a snap, or delete a snap. [15:00] Cynerva: for the /var/run/docker.pid, can you tell me what's going on there? why would the app move it? [15:00] ryebot, hi! yes we can do first and last option [15:00] ryebot, renames are not a thing yet [15:00] ryebot, what's the snap? [15:00] zyga, I think we want PATH to be consistent [15:00] balloons: want != can [15:00] balloons, where is that ? classic ? [15:01] balloons: whatever we want is done somehow, there's no way that we know of that would let us stick an item in path other than /etc/environemt [15:01] zyga: okay, will do on the others, thanks :) as for the docker pid, i really have no idea, but i can look into it [15:01] nessita: ah, that's excellent, thanks! There's three of them: kube-apiserver, kube-controller-manager, and kube-scheduler [15:01] balloons: and there are plenty of small places that keep a copy of "vanilla path" that still break [15:01] ryebot, let me check a few things first [15:01] balloons: I'd like to know why the current approach that we do doesn't work in the places that were mentioned in the bug [15:01] nessita: I think just deleting them would be fine [15:03] ryebot, I can certainly delete them, but may I ask what's the reason? [15:03] popey: we are likely changing how aliases work, so that bug won't be quite the same [15:04] nessita: I posted them to the store for testing purposes, but we'll be making a namespace for them in the future and I didn't want the tests to be in the way. Poor choice of name the first time around, basically. [15:04] nessita: my suggestion would be to take advantage of the new project for the store and route all such requests through bugs there [15:04] balloons, note that this is a bash "feature" ... [15:04] nessita: you'll get free accountability and tracking [15:05] zyga, did those messages are truly for me? [15:06] nessita: yes, [15:06] zyga, ah, I see what you mean :-) [15:06] nessita: all the store request are informal / on irc; I think it would be a good idea, for transparency to request that they are filed as bugs on the store [15:06] popey: anyway short story both now and in the future you need to ask on snapcraft list or a reviewer to get the aliases enabled [15:06] ogra_, zyga, perhaps it's better in /etc/bash.bashrc? [15:06] zyga, sounds good, thanks for the suggestion [15:06] popey: through a store mechanism [15:07] and you are right.. ksh or other users are busted too :-) [15:07] balloons, i thin thats not read if you have ~/.bashrc ... which we cant midify [15:07] *modify [15:07] mm.. Indeed [15:07] (and which is created by default usually when a user is created) [15:07] balloons, where do you have that issue ? on classic [15:08] ryebot, following the suggestion from zyga, would you mind filing a bug-request at https://bugs.launchpad.net/snapstore with the delete request? then I can execute asap [15:08] ogra_, I imagine you would have it for all non-login shells [15:08] note that we have a bit more freedon regarding /etc/environment on the core images [15:08] nessita: Not at all, thanks a ton! [15:08] ogra_, but yes this is on non-core ubuntu images [15:08] and the last edge images actually have that path in /etc/environment [15:08] nessita: \o/ thank you, I think this is very important [15:09] for all other setups you need to add a snippet to your bashrc to source profile.d [15:09] nessita: https://bugs.launchpad.net/snapstore/+bug/1664601 [15:09] Bug #1664601: Please remove kube-apiserver, kube-controller-manager, and kube-scheduler from the store [15:10] PR snapd#2849 opened: cmd: don't reexec on RHEL family [15:10]