[02:02] Hello all. [02:03] Are snaps basically LXC containers running different applications? [03:46] vivus, and so much more. some of the underlying security and confinment technology is similar, but that's only the basic building blocks. Cause there is a lot of mediation and support around installing/updating/upgrading snaps, allowing/disallowing snaps to do things on the host OS, and to/with other snaps to connect to each other. and the core systems, ship everything as the snap including bootloaders and kernel. [03:47] vivus, and that's definately so much more than just "containers" and "applications" [03:47] xnox: so how do I make my snap-installed IDE see my development environment such that I get code auto-complete, etc. ? [03:49] vivus, usually i would expect it to connect with a home plug to access user's home. [03:49] vivus, are you creating the IDE snap? or are you just using some IDE snap created by somebody else? [03:49] xnox: so I still need to install lots of dependencies on the main system then? [03:49] no, none. [03:49] well depends what you build. [03:50] its mostly hypothetical at this stage. Im seeing if I should switch from LXC to snaps [03:50] vivus, play around with examples to understand what snaps are. they are more like android/iphone apps then chroots/containers/vms. [03:51] since the snap app itself is read-only typically, but can have data in strict ways on the host system. [03:51] so e.g. there is golang provided as a snap, which gives one compiler. [03:51] xnox: by lots of dependencies I mean dev-environment deps. For example, let's say I install PyCharm. Now I want to use PyCharm with autocomplete for my Python environments. Where do I install the Python environment stuff? [03:52] typically in a pyenv in like ~/code [03:52] is the pyenv a snap also? [03:52] no [03:52] so that's on the host? [03:52] yeah... cause you'd need it read-write, don't you? [03:53] that seems like going a bit backwards for me then. all my dev stuff are isolated in LXC containers, because of the bloat they create on the host. [03:53] can i attach and modify a snap container? [03:54] right but pycharm itself could be a snap. and all of its dependencies would be inside the snap and do not leak on the host at all. [03:54] and you can have multiple things co-installed which use same deps, but different versions, without any conflicts on the host. [03:54] yeah but say I want to install a python package that has lots of system dependencies, like Pillow, then my host would still accumulate system-deps just for Pillow [03:55] this is generic development stuff. you would not be installing those as snaps typically, no. you would use some form of confinement. [03:55] but you would not need to install it on the host into /usr [03:56] vivus, and e.g. Pillow -> i'd be installing that in a virtual env, in project directory in a reproducible way. https://docs.python.org/3/tutorial/venv.html [03:57] cause with python, one typically creates a virtual-env which contains this project dependencies only, and develops / runs / tests code there. [03:57] xnox: yeah, but Pillow and some other Py packages will sometimes need system-deps to compile [03:57] true [03:58] now say you have to do this for Python, and then maybe Node too. Creates lots of bloat [03:58] The other day I had to install mono and I used isolation to specifically avoid the bloat [03:58] maybe you want to look at snapcraft [03:59] *on the host [03:59] that's tooling to build snaps, with isolation, which has a lot of tooling to use lxd containers to build all the layers/dependenices of your app, including your app, and bundle everything as a snap. [03:59] Perhaps I can create the snaps myself. but they are immutable right? I cannot `sudo lxc-attach -n snapcontainer` right? [04:00] but that's mostly for "from scratch build & deploy" scenario. not meant for interactive coding/iterations. [04:00] vivus, snap filesystem structure, is a bind-mounted squashfs -> so no, attaching into its mountspace will not gain you much. [04:00] and paths and prefixes may look odd to you [04:01] vivus, what's your actual problem and why did you start looking at snaps? =) [04:02] vivus, are lxd containers not working out for you? (i find $ lxc launch ubuntu:cosmic etc so much nicer than old lxc-* commands) [04:02] vivus, have you used lxd already? [04:08] xnox: ill reply in 5. just afk [04:14] xnox: the distro I use doesn't have first-class support for LXD, but I've been using LXC for a few years now, so that's not the pain-point. I was hoping I'd get to use some type of containerized desktop IDEs that can help me do code auto-complete, etc. [04:15] right now what I use is Vim [04:15] and I kind of prefer mouse interaction at times [04:19] if anyone could help me out with this in this post, i would greatly appreciate it, I need to kick this out the door soon: https://forum.snapcraft.io/t/getting-a-part-build-artifact-into-another-parts-build-before-pull/7082 [05:04] morning [05:40] o/ [05:40] good morning [05:44] hey zyga [05:44] hey, how are you doing? [05:48] zyga: doing well, thank you [05:48] zyga: how are you? [05:52] zyga: mvo: hey [05:58] mborzecki: hey hey [06:22] zyga: pushed the changes to https://github.com/snapcore/snapd/pull/5713 [06:23] looking [06:24] there is a conflict with your other patch in master now [06:24] zyga: i'm really bad at naming things, feel free to suggest something different than ExpandSnapMountVariables() [06:24] ExpandSnapVariables(perspectiveHost,perspectiveSnap) # maybe? [06:24] that is maybe a flag rather than a new function [06:25] because then anyone using it must face the fact that perspective matters [06:25] but I didn't read all so just quick reaction [06:25] idk, i'm open for alternatives [06:26] let's use the word perspective for that across the tree [06:26] though not sure if it is sufficient: [06:27] there's the outside perspective (host perspective?) [06:27] there is the inside perspective for strictly and devmode confined snaps [06:27] (perhaps for classic snaps the inside perspective should just error or be the same as outside perspective) [06:27] mvo: btw: did we decide to do something about "snap install classic" [06:27] mvo: I had some ideas on that [06:28] mborzecki: but then there's the inside perspective of instance snaps, what should is say for $SNAP - /snap/foo/42 or /snap/foo_bar/42 [06:28] zyga: hm that sounds good [06:28] mborzecki: if the instance aware path is rare we could do ExpandSnapVariables(innerPerspective | instanceAware) [06:28] zyga: snap install classic is on my todo [06:29] mborzecki: but normally just pass innerPerspective [06:29] zyga: funny enough it will work, it will just be the wrong classic [06:29] mborzecki: from what I guess there's just three places that need to be instanceAware [06:29] zyga: and it has an upside that i could push this as a pr outside of 5713 [06:29] zyga: it will pull in "core" [06:29] mvo: right :) [06:29] mvo: remember that on core18 all the snaps use pivot_root [06:29] so yeah :) [06:33] zyga: naming aside, please take a look at the rest of the changes and the spread test and i'll start looking into this change with perspective flag [06:36] I [06:36] OK [06:50] the instance layout test is very nice [06:56] zyga: do you think i could add something to the content interface test? [06:56] reading it now [06:58] mvo, hey, would it be possible to make sure https://forum.snapcraft.io/t/pulling-network-online-target-as-prerequisite-target-slows-down-starting-services/6063 does not happen on UC18? [07:00] zyga: omg, found some bad merge [07:01] abeato: indeed, sorry, it is still on my TODO let me move it up [07:01] mmm? where? [07:01] mborzecki: yeah, tell us more [07:01] mvo: my code :) no worries [07:01] puhhh :) [07:01] mvo, awesome, thanks a lot [07:01] zyga: in info.go, ExpandSnapMountVariables, around SNAP_DATA [07:02] I'm not there yet [07:02] hm wonder why it was picked up by vet on travis, but not locally, iirc go test is supposed to run vet now too? [07:04] is it? I was never using go vet automatically, it's always manual [07:06] zyga: https://golang.org/doc/go1.10#test-vet [07:06] ah,go 1.10! [07:07] so I was using it without being aware of it [07:07] they mention high confidence checks though, idk how unreachable code is not among those [07:08] I'd love unused code detector [07:08] zyga: try gometalinter [07:08] e.g. public functions that are not used [07:08] there's deadcode checker [07:09] yeah but $standard vs $toolbox [07:09] I agree I'm just lamenting it is not a standard issue feature [07:10] btw. deadcode actually picks up some stuff in the project, just didn't open any PRs yet === pstolowski|afk is now known as pstolowski [07:14] morning [07:15] mborzecki: https://github.com/snapcore/snapd/pull/5713/files#r213925025 [07:15] the path discussion summarized [07:15] hey pawel [07:15] hey pstolowski [07:15] pstolowski: cześć [07:19] zyga: wonder if that's a bit too many flags [07:19] mborzecki: four? [07:19] really we need the two flags for perspective + one flag that "flips" the natural instance awareness [07:19] so three [07:20] but the reality is that I think we just need it [07:25] zyga: i'm taking yagni angle here, all the use cases are inside mount ns now https://paste.ubuntu.com/p/RZF98hg8hd/ [07:26] snapshots need the outside path [07:26] inside you need both the instance and non-instance paths [07:26] (or we can just craft the instance paths with instance key manually [07:26] +1 on yagni though, if you can get it to work [07:26] we can add the override flag if needed [07:28] zyga: i'd expect snapshots to use snap.Info methods, those do instance-specific paths [07:28] interesting [07:28] yeah [07:30] zyga: to recap, the snap.Info.SomeSuchDir() return all instance path, then the package level helpers snap.MountDir() et al take a snapName, so you can do snap.MountDir(info.SnapName(), info.Revision) [08:10] zyga: hm need to update that symlink path in layouts test [08:10] ah, right [08:10] +1 [08:15] zyga: actually something broke there with /etc/demo, i'm looking into this right now, will ping you if i need a hand [08:15] ok [08:15] what was the error? [08:16] /etc/demo/writable is not created in $SNAP_COMMON for some reason [08:16] zyga: the fstab looks ok to me https://paste.ubuntu.com/p/wMw8hrWZmq/ [08:17] mmm [08:17] ok [08:18] zyga: i can see /etc/demo/writable inside snap mount ns, but it's not in $SNAP_COMMON/etc/demo for some reason (and not in /var/snap/test-snapd-layout_foo/common either) [08:18] is it because /etc is the real /etc and it is writable and then you don't get a private-namespace copy? [08:18] aka, trespassing bug [08:19] maybe we can revive my branch for that [08:19] zyga: mountinfo inside, https://paste.ubuntu.com/p/FXrp8Cmymc/ [08:19] zyga: hm it worked before fwiw [08:20] 894 737 8:1 /var/snap/test-snapd-layout/common/etc/demo /etc/demo rw,relatime master:1 - ext4 /dev/sda1 rw,data=ordered [08:20] so /etc/demo is /var/snap/test-snapd-layout/common/etc/demo [08:22] anyway, I'll revive it [08:22] I need to land htat [08:23] zyga: hmm https://paste.ubuntu.com/p/3MXW6fz5RC/ what if it's not? :) [08:24] and on the host :D [08:24] because this really tells you what happens [08:24] ext4 filesystem on /dev/sds1, the slice at /var/snap/test-snapd-layout/common/etc/demo is at /etc/demo [08:25] 977 764 8:1 /var/snap/test-snapd-layout_foo /var/snap/test-snapd-layout rw,relatime master:1 - ext4 /dev/sda1 rw,data=ordered [08:25] this hides it from your namespace (it's later in the sequence) [08:25] (sequence matters) [08:25] but just check on the host [08:25] am I right? [08:27] hm on the host, /etc/demo is there, /var/snap/test-snapd-layout_foo/common/etc/demo/writable is not, but /var/snap/test-snapd-layout/common/etc/demo/writable is and contains what was written by the _foo instance :/ [08:27] zyga: ^^ [08:27] right [08:27] that's what I expected [08:27] I mean, mountinfo doesn't lie [08:27] it's just non-obvious what the outcome is [08:29] zyga: heh, ok, i'll just leave a comment in the test that this part blows up too [08:39] mborzecki: I'm looking at my trespassing fix onw [08:39] the part I got stuck on is something you could help me with [08:39] if you want we can HO today and I'll walk you through it [08:39] maybe the solution will become obvious as we d oit [08:39] Is there a way I could grant a snap read-only access to /etc/ssl without going all the way and changing it to a classic one? Is there an interface I'm missing? If not, is there a potential for one to be added? [08:40] MattJ: let me look [08:40] zyga: ok, sure [08:41] so [08:41] MattJ: the network interface does that [08:42] but you need to know that /etc/ssl is not from the host [08:42] it is the one from the base snap of your app [08:42] so you cannot add ssl certs by adding them to your host [08:43] Ah, ok :/ [08:44] Thanks - do you see any easy way around this or should I give up and switch to classic confinement? [08:44] it depends on what you want to do [08:44] you can add ssl certs from your snap to your snap's runtime [08:44] that is [08:44] Another thing I thought was if I could just run one command without confinement to import the certs to the data path or something [08:44] any given snap can add certs for itself [08:45] Well it's a server process, but it needs valid certificates for the domain it is serving [08:45] Most people these days will already have these via Let's Encrypt/etc. [08:45] mmm [08:45] where do you need that cert to be exactly? [08:46] I need it anywhere that can be read by the server process launched in the snap [08:46] copy it to $SNAP_COMMON [08:46] and have your snap read it from there [08:46] I guess I could provide a script in the snap that does this, and the user could execute it manually [08:48] Thanks for the thoughts :) [08:50] MattJ: a script can detect if it's being run or being sourced, and error if it's being run, with an error along the lines of 'you need to source this' [08:51] MattJ: in bash, that is: check whether ${BASH_SOURCE[0]} is $0 [08:51] This would probably need to be actually run as root, from cron [08:51] But thanks for the tip [08:51] MattJ: systemd timers ftw [08:53] Sure, though that can't be installed by the snap... but I guess it could be installed by this script, hmm :) [08:56] MattJ: OTOH you're not the only person asking us to be able to add certificates [08:57] I think it's easier for web-based apps that may be the only thing on the system, they can bind to port 80 and include certbot in the snap [08:57] so maybe we need to think about a more general solution [08:58] MattJ: if your snap was installed on a core device, where /etc/ssl is readonly, what would your users do? [08:59] Probably install some Let's Encrypt/certbot snap [09:00] (I would like the snap to work on a core device for sure, so I would also like a solution for that - but I haven't got that far yet) [09:01] MattJ: so from your POV getting the cert is never your snap's concern, it always needs to come from outside [09:02] MattJ: why would the copying need to be put on a timer? because presumably the certs get updated periodically in some other place and the whole tree needs to be in sync? [09:03] should the app version number always be "hard-coded" in the snapcraft.yaml file? [09:03] I'd like to get it from my_python_package.__version__ instead [09:04] zyga: i'm looking at the log from test-snapd-layout_foo, https://paste.ubuntu.com/p/j5WSWJtyJH/ if the mount changes are pefroemd in the order they are logged in line 178 then this will be incorrect, won't it? [09:04] zyga: i mean i see it's doing all the layout stuff before parallel instance setup, although fstab lists parallel instance pieces first [09:05] hmmm [09:05] zyga: before it worked because layouts used instance-specific paths and the instance -> snap bind mount would not confclit [09:05] * zyga looks [09:06] aha [09:06] interesting [09:06] hmmm [09:06] right [09:06] we sort them in a specific way [09:07] * zyga thinks [09:07] hm parallel-instance then should come first? [09:07] t1mp: you can tell snapcraft to grab the version from elsewhere [09:07] lines 162-190 of the log [09:07] not sure if that's correct [09:07] zyga: we have x-snapd-origin we could use [09:07] Chipaca, Let's Encrypt certificates are only valid for 3 months, and are typically updated more often than that [09:07] yes but it's super super tricky what happens [09:07] * mborzecki looking [09:08] the rationale for the ordering is specific [09:08] I was thinking if we need to do batching [09:08] Chipaca, so either the snap needs constant access to them, or they need to be imported periodically by something with access to them [09:08] t1mp: look up "snapcraftctl set-version", i think that'll lead you to the how [09:08] zyga: like parallel instances first, then layouts, then the rest (if needed?) [09:09] perhaps [09:09] MattJ: yeah, that's what i thought [09:09] but it's all non-trivial [09:09] zyga: computing changes would be tricky [09:09] not sure if this remains correct [09:09] Chipaca: thanks, reading. [09:11] mborzecki: what if we do a stable sort [09:11] and sort by (target, source) [09:11] not just by target [09:11] I think what is happening that is wrong is [09:12] we order things by where they appear [09:12] zyga: i can try that [09:12] ignoring the what they bring aspect [09:12] and what they bring is also relevant [09:12] we need to correctly order the desired state [09:12] but then the question becomes; [09:12] is this breaking any invariants the current code has [09:13] will it undo correctly [09:13] zyga: i'll do some experimentation and we can later meet in HO [09:15] zyga: heh, finny that it worked before by accident :) [09:15] and i was like, 'oh hey it works, so nice' ;) [09:19] mborzecki: I need to go to the post office [09:19] mborzecki: we can HO after that [09:19] ok? [09:19] sure [09:19] brb [09:21] niemeyer: hi, when you're around could you take a look at https://github.com/snapcore/snapd/pull/5735 ? [09:22] mborzecki: Looking [09:23] niemeyer: thanks [09:29] mborzecki: Reviewed, np [09:34] t1mp: this: https://forum.snapcraft.io/t/extracting-information-from-sources-in-snapcraft-parts/4642 [09:42] Chipaca: thanks. [09:42] I see there is also a version-script property in the yaml file, but not a lot of docs on that yet. [09:45] re [09:47] zyga: i'm playing with this naiive change https://paste.ubuntu.com/p/K54npKZzFg/ [09:49] sure but think about the consequences as well [09:50] zyga: do you think 5307 needs another look by jamie ? or can we squash it? [09:50] zyga: just verifying that moving those mounts to be firs fixes the issue at hand [09:58] mvo: looking [09:59] mvo: ideally jamie would look but he's been busy [09:59] also gustavo asked for +1 from jamie [10:10] zyga: the tests are passing now (expectedly) [10:18] Chipaca: version-script looks like it will do what I want, but still the 'version' property is required. I assume that version-script will override that (but it is not documented what will happen). I guess I'll have to try it [10:18] WOAH [10:18] There's no a "Resolve conversation" button in GH.. [10:18] So simple and so useful [10:19] pedronis: hey, wrt your comment about revert & Sequence after currentIndex, what're the semantics of Sequence? [10:19] And "Show resolved" and "Hide resolved".. OMG.. my day just got better [10:21] niemeyer: nice [10:22] https://usercontent.irccloud-cdn.com/file/uMovdf2m/image.png [10:24] xnox: that reminds me, can I do an sru for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 or do you plan to do one anyway where you could include this change? [10:29] mvo, hmm, you said SNAP_ARCH_TRIPLET was not implemented ... this one is very curious though ... : [10:29] $ snap run --shell qemu-virgil -c "/usr/bin/env"|grep SNAPCRAFT [10:29] SNAPCRAFT_ARCH_TRIPLET=x86_64-linux-gnu [10:29] seems the snapcraft var is actually inside the installed snap [10:29] (whihc is great but smells like it should not be like that) [10:31] ogra: I did not follow what snapcraft was doing there [10:31] mvo, well, somehow SNAPCRAFT_ARCH_TRIPLET ends up in my runtime env [10:32] that snap has no wrappers or anything so this is very curious [10:33] i mean, i appreciate that ... but it doesnt feel right that a SNAPCRAFT var ends up in my installed snap package === chihchun_afk is now known as chihchun [10:34] $ grep SNAPCRAFT /snap/qemu-virgil/current/command-qemu-virgil.wrapper [10:34] $ [10:34] it is definitely not in the default wrapper [10:34] so i wonder where it comes from [10:34] gar [10:35] ignore that ... somthing exported it into the shell i'm in [10:35] (which is also curious ... should snap run --shell not wipe my env ? ) [10:42] ogra: nope, only remove some of it [10:51] ah [10:53] pstolowski: left you some comments on #5680 [10:54] mborzecki: ty! [11:37] hmm, if a test panics the panic breaks the test [11:37] but if a test panics and teardown uses c.Assert() that fails then the assertion error is show but the panic is gone [11:38] is this expected? [11:58] grr grr grr integration tests grr [11:58] * Chipaca ~> lunch === pstolowski is now known as pstolowski|lunch [12:11] mborzecki: hey [12:11] do you want to HO? [12:11] sec [12:11] I'm progressing on the trespassing fix, I rebased it and solved a blocker I had the last time [12:11] now going through tests that ... well, need some love since syscalls changed [12:12] but it's mostly inserting a syscall in a chain and going on [12:12] zyga: ok, ready [12:12] standup? [12:37] mvo: can #5583 be reviewed again? I might not get to it today tough === pstolowski|lunch is now known as pstolowski [12:46] hmm, an install hook should also run on upgrades, right ? [12:47] pedronis: yes, I updated it ~1h ago [12:48] ok [12:48] pedronis: it has a minimal wait and tracks the idle connections now [12:48] s/tracks/checks/ [12:49] mvo: likely I will look at it tomorrow, trying to getting started with something today (but had a bit of a cut up day by errands so far) [12:49] ogra: no [12:49] pedronis: no worries, its not urgent [12:49] ogra: on upgrades we run pre-refresh and post-refresh hook sinstead [12:49] *instead [12:52] pstolowski, hmm, so i need two scripts if i want something to work on install as well as on upgrades ? [12:52] hooks/install and hooks/*-refresh ? [12:53] jdstrand: hey, there's a pr that is blocked on you (the one about /mnt) [12:53] jdstrand: do you think you will have time to review it today [12:53] ogra: yes [12:53] I got through some yesterday. will try to get to that one [12:53] boo [12:54] ok [12:54] jdstrand: thank you! [12:54] ogra: if the logic is the same you can move it to a helper.. or maybe a symlink will work (not sure) [12:54] well, i#ll just cp it ... [13:33] I must say I love our standups [13:33] guys, any clue why i'm not able to edit https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 ? [13:34] it's not a wiki [13:34] the irony there hurts ;) [13:35] oh boy!! [13:36] I used 1TB of data this month [13:36] and I actually hit my cap [13:36] wow [13:36] (LTE cap) [13:36] I need better visibility into this, who is using this data .... [13:37] nasty neighbours :) [13:38] zyga: hm i can edit this https://forum.snapcraft.io/t/the-snap-format/698 but not the other one === chihchun is now known as chihchun_afk [14:33] hi [14:33] I have a snap containing some rust code, it compiles fine on amd64/i386 but not on arm64/armhf [14:34] error is "error[E0658]: non-reference pattern used to match a reference (see issue #42640)" [14:34] has anyone seen this ? [14:34] https://launchpad.net/~build.snapcraft.io/+snap/17fc91e19f932bd8a75175923b533019-xenial builds are here [14:39] axino: is this specific to the snap? [14:40] Chipaca: I can't answer that [14:41] axino: why not? [14:41] Chipaca: I haven't tried to build sentry outside of the snap context [14:41] Chipaca: or maybe I misunderstood your question [14:42] axino: the error does not seem to be about snaps at all [14:43] axino: I'm not sure how we could help [14:43] Chipaca: maintainers of multi-arch rust snaps might have seen this behaviour [14:46] I guess I'll try #rust === chrisccoulson_ is now known as chrisccoulson [14:56] axino: if you don't have luck there, try a topic on the forum [14:56] Chipaca: yup I will - thanks [15:17] mup: ping [15:17] mup: how much chug would a moose chug … wait === chihchun_afk is now known as chihchun [15:41] jdstrand: I'm getting a snap suddenly getting rejected by the store, which was fine previously [15:41] jdstrand: https://dashboard.snapcraft.io/snaps/scummvm/revisions/466/ [15:42] "unknown keys in snap/manifest.yaml: snapcraft-os-release-id,snapcraft-os-release-version-id,snapcraft-version lint-snap-v2_snap_manifest " [15:43] popey: tools needs an update. thanks! [15:43] popey: can you request a manual review? [15:43] popey: we'll get that fixed fast [15:43] done, thanks [15:48] * zyga goes for a bike for 1..2 hours [15:48] popey: can you do the same for 466 (i386)? [15:49] jdstrand: done [15:49] jdstrand: I'm making good progress on the trespassing bug (it was unblocked today), I'll bug you about that tomorrow [15:49] zyga: great. fyi, I'm off tomorrow/Monday (will send email later) [15:50] ah [15:50] ok, then on Tuesday [15:50] can you try to look at https://github.com/snapcore/snapd/pull/5307 - you're the last +1 needed :) [15:50] (regardless, I'm heading out) [15:51] zyga: yes, we talked about that already today :P [15:51] I know, sorry :| [15:53] snapd 2.35 is installing the .snap files as root:root 600 - previous snapds installed root:root 644 [15:53] caused an error that I've documented in the cft for snapcraft 2.43: https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/7024/5 [15:53] i had this the other day too [16:00] diddledan: popey: that is known and fixed on master fwiw [16:01] master of snapcraft that is [16:01] how can snapcraft, running as me, decide to override root-only access? [16:05] * diddledan eyes it suspiciously [16:11] diddledan: say again? [16:11] diddledan: it doesn't [16:11] diddledan: it no longer tries to copy those files into the container [16:12] you said it was fixed in snapcraft, but snapcraft can't override the root-only access [16:12] aah [16:12] gotcha [16:12] * diddledan removes suspicious eyes [16:12]