[00:12] Bug #1611083 changed: Users without xenial-updates/universe can't get snapcraft version 2.11 tour. [00:21] Bug #1611080 changed: snapcraft.io says snap find has --broad, but it doesn't [00:21] Bug #1611094 changed: http://snapcraft.io/create/ mentions readmes in each tour subdirectory, they are missing [00:24] Bug #1611098 changed: snap install tab completion lacking filenames [00:27] Bug #1611099 changed: snap install tab completion lacking filenames [00:34] Bug #1611108 changed: snap install without sudo asks to login to snap store [01:17] a debian build plugin would be nice === stokachu_ is now known as stokachu === mjl_ is now known as mjl === chihchun_afk is now known as chihchun === davidcalle|afk is now known as davidcalle === hikiko is now known as hikiko|afk === cydizen_ is now known as cydizen [08:38] Hey, anyone about? I have a question. [08:38] jdstrand: https://github.com/snapcore/snap-confine/pull/99 [08:38] PR snap-confine#99: Disable owner checks for 14.04-style private home [08:44] Is there an easy way to pass environment variables into the environment of an app delivered by a snap? [08:45] I've done this currently by wrapping the binary in a shell script that is the publicly available app [08:45] ... but that seems to leave the binary itself without the permissions provided by the plugs I associated with the wrapper script. [08:45] (that's my hypothesis at least) [08:46] tealeg: can you give me a practical example [08:46] zyga: sure. [08:46] tealeg: what you are doing works very well and is used by many apps already [08:46] zyga: I have an emacs snap [08:47] tealeg: there's upcoming upstream support for defining environment in snapcraft.yaml but it's a long way to go (arguably very little works remains but it took as a while to get there) [08:47] zyga: when I run emacs from the snap, it cannot read files in my HOME directory, though the wrapper script has the home plug defined [08:48] zyga: (with strict confinement turned on, of course) [08:48] tealeg: how do you determine that it cannot read files in the home directory? [08:48] tealeg: do you see apparmor denials? [08:48] zyga: it tells me that - I try to open a file there, and it says it can't read it [08:48] zyga: I can look, just a mo [08:48] tealeg: can you run 'journalctl -f' and try that now? [08:49] zyga: so, yes, apparmour is denying it [08:50] zyga: shall I paste the lines someplace? [08:50] tealeg: yes, please [08:50] one line should be enouh [08:50] enough * [08:50] tealeg: please also pastebin your snapcraft.yaml if you can [08:50] zyga: ok.. [08:51] zyga: here's the apparmour: http://pastebin.com/wtxPkVTh [08:51] ok, that's enough [08:51] you cannot open dotfiles [08:51] even with the home plug connected [08:52] zyga: oh? [08:52] there's an ongoing discussion about this on the mailing list and on launchpad bug reports [08:52] zyga: let me try a non-dotfile :-) [08:52] zyga: yup, that's it! [08:53] zyga: thanks. OK, I'll accept that as something ongoing for now. Thanks for your time. [08:53] mvo, wow, you keep the builders busy today :) [08:54] ogra_: ? :) [08:54] ogra_: yes, created a candidate ubuntu-core for the next stable update of ubuntu-core [08:54] ogra_: (the snap) [08:54] yay [08:54] ogra_: its all in the candidate channel now, needs QA testing next [08:54] k [08:55] well, the arm builds are still sitting there (as usual since a week) [09:03] ogra_: I will do one-off uploads for pi2 and dragonboard kernels that make kernel.img/initrd.img real files, this is important to unbreak ubuntu-image. just fyi [09:04] ogra_: ok, building kernel snaps with your build scripts doesn't really work, no I get: Warning: no boot file name; using 'C0A8B2C8.img' [09:04] mvo, plkeas only dragonboard, i'm in the middle of setting up the auto-build for pc-kernel and pi2-kernel [09:04] *please [09:04] morphis, are you on the lates ? [09:04] t [09:04] morphis, they work fine on LP [09:04] ogra_: if that is ready today thats good enough, otherwise I will just do it, its not much work and will unbreak people [09:05] ogra_: hm, let me try that then [09:05] mvo, pc-kernel is ready in 10min or so [09:05] ogra_: \o/ [09:06] zyga: hmmm your refresh-bits script says I don't have systemd but I do :/ [09:06] it searches for systemd-activate but indeed I don't seem to have it [09:06] mvo, do we want a pc-kernel-i386 or should i just build two arches under the same name ? [09:06] ysionneau: are you on yakkety? [09:06] I'm on Debian testing :o [09:06] ogra_: pi2-kenrel is actually the one where this matters (the filename) and the dragonboard one of course [09:06] ysionneau: or debian testing, yes [09:07] ogra_: two under the same name seems ok, unless I hear otherwise [09:07] ysionneau: i didn;'t have time to figure that out yet, how do you run socket activated services in more recent versions of systemd [09:07] ogra_: its not clear yet if i386 will be "pc" as well for the gadget name [09:07] ysionneau: if you figure it out please send me a patch [09:07] ysionneau: that's something systemd changed upstream, maybe they just renamed the command [09:07] mvo, well, pi3 also ises pi2-kernel, so i dont think the gadget name is that important [09:08] zyga: to do that I usually just do a .service with a ListenStream part [09:08] one unit file for the socket (WantedBy=sockets.target) and one unit file for the service [09:09] ah to actually run it [09:09] ysionneau: :) [09:09] systemd-socket-activate <= [09:09] this binary [09:09] https://www.freedesktop.org/software/systemd/man/systemd-socket-activate.html [09:11] mvo, i'm picking 4.4.0-35-1 as the version. so we can bump the last part for package specific changes (the branch is set up for auto-build on commits, so if a new kernel lands we bump the version and it auto-builds (later i'll automate that and watch the linux-meta package in -updates) [09:11] is the versioning ok with you ? [09:12] (this is pc-kernel) [09:12] ysionneau: please try to patch refresh-bits to use this [09:12] anyway I don't seem to need this since I will run on a target [09:12] ysionneau: as I said, I'd love to have the patch, I'm just hacking on something eles now (snap-confine) [09:12] so I guess I'll just comment it since I'm in a hurry [09:12] ysionneau: there's a bug in --host where it still looks for systemd-activate on the host [09:13] yep no problem I'll comment the code [09:15] ysionneau: thanks! [09:17] mvo, https://code.launchpad.net/~snappy-dev/+snap/pc-kernel ---> to build you do: bzr branch lp:pc-kernel-snap -> bump the version in snapcraft.yaml, commit -> bzr push lp:pc-kernel-snap ... go to the url and watch it build for i386 and amd64 :) [09:18] ogra_: neat [09:18] (or just request a manual build on the page if you dont want to bump the version) [09:18] now setting up the same for pi2-kernel [09:19] note that this comes all from the same branch, they just differ in their snapcraft.yaml [09:20] (we should keep the Makefile in the branches in sync between them) [09:20] zyga: very cool ! your script succeeded in building snapd o/ Thanks! One small remark, you base your detection on the user space arch by using uname -m on the target, which does not work in case your kernel is aarch64 and user space is armhf. I hardcoded armv7l to make it work [09:20] now the exciting moment ... [09:21] * ogra_ watches the snaps being uploaded to the store [09:21] (havent tested that yet) [09:22] ysionneau: interesting, please feel free to report thos bugs so that at least the problem is not lost [09:22] ysionneau: (straight on github) [09:22] ysionneau: and if you have time please send pull requests [09:22] ogra_: a pi2 kernel upload will not break anything, right? this unblocks my new u-d-f (and ubuntu-image) so I'm keen to put it into the store for testing [09:23] mvo, well, how do you build it [09:23] ogra_: manual, snapcraft snap [09:23] ogra_: I just need to fix the symlinks [09:23] (as a one-off build) [09:23] (its trivial) [09:23] mvo, btw, we need store people to remove the review tools block for kernel for pc-kernel https://myapps.developer.ubuntu.com/dev/click-apps/5507/ (can you approve them = [09:23] ?) [09:24] zyga will do the reporting at least, thanks [09:24] ogra_: I can approve them, one sec [09:24] mvo, well, i would prefer we use the new way right away to test the symlinks there too :) but if you need it right now, go for it ... my set up takes still 10-15min [09:25] (thogh given the state of armhf builders it might end up being 3-4h) [09:25] ogra_: 10,15min is fine, then I won't waste enegery on it, thank you [09:25] ogra_: heh :) if 3-4h I may become too impatient ;) [09:25] mvo, can you bump build scores if needed ? [09:25] ogra_: but its fine, its literally 5min work for me [09:25] ogra_: unfortunately I can't :/ [09:26] k, lets see ... [09:26] ogra_: I think we should get auto-high-score just like for the old image builds [09:26] yeah [09:31] ogra_: kenrels approved [09:31] thx [09:37] mvo, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel ... i asked for a score bump [09:37] ogra_: ta [09:37] mvo, for that ... same procedure as above ... either bump the version and commit/push ... or do a manual build through LP [09:38] ogra_: neat [09:39] for dragonboard i'll do a build in my own test branch since i cant really set up the snap package under the snappy-dev name when i dont have the correct name (i dont want to create cruft there) [09:39] ogra_: +1 [09:41] when creating an interface, if I want to allow a snap to connect to a unix socket, do I just pretend it's like a file and I just give rw access to the file path ? [09:42] or does it need some other special rights since it's not really "just" a file? [09:42] ysionneau: yes [09:42] ysionneau: it's just a file [09:42] ysionneau: you will also need to add appropriate system calls like connect and what not [09:43] ysionneau: but those are easy to add in a whack-a-mole fashion, just keep editing the generated apparmor and seccomp profiles until both sides work [09:43] (plug and slot side) [09:43] yes but then I guess I can just use the network interfaces in the snap? [09:43] ysionneau: did you see my artice about how to create new interfaces from scratch? [09:43] or is it cleaner if the "pimp" (that's my interface name) interface dierctly authorizes the network functions? [09:43] ysionneau: that's subtly different, it's better to be explicit, over time the network interface may only work for AF_INET and AF_INET6 [09:44] zyga: nop, but so far it seems pretty simple [09:44] ysionneau: so don't use it because it gives you extra thnigs you need, put the extra needs into your own iface [09:44] ysionneau: zygoon.pl [09:44] ysionneau: do read it please :) [09:44] ysionneau: feedback is welcome and appreciated [09:44] http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html [09:45] ysionneau: if it is real "connect to ip network" then do use the existing network/network-bind interfaces [09:45] ysionneau: if it is something else, put it into the interface you are creating [09:45] 11:44 < zyga> ysionneau: do read it please :) < ok I will! [09:46] btw I created the "issue" on github for your script [09:46] and added information on the already existing issue about systemd activated sockets [09:47] zyga: ok then yes I need to add the syscalls in my interface since it's just for the unix socket [09:47] ysionneau: note that we can now do partial argument filtering via seccomp [09:47] "partial" ? [09:47] ysionneau: https://github.com/snapcore/snap-confine#seccomp [09:47] like only putting a requirement on arg1 and not arg2 ? [09:48] well, when snap-confine finally is SRUd [09:48] ysionneau: (only integeres, we cannot ever see through pointers) [09:48] yep I know I've played with seccomp a bit in the past [09:48] jdstrand: hello :) [09:49] which I think has been a good decision-- we'd have to adjust the Depends of snapd to be a version of snap-confine and that would've stopped snapd uploads :) [09:49] zyga: hi! :) [09:51] jdstrand, do i have to poke you to get a package exception for "(NEEDS REVIEW) type 'kernel' not allowed lint-snap-v2_snap_type_redflag " for https://myapps.developer.ubuntu.com/dev/click-apps/5507/ ? the builds now come from automatic LP builds (like ubuntu-core) [09:51] or is that a store people thing ? [09:53] (builds now come from https://code.launchpad.net/~snappy-dev/+snap/pc-kernel ) [09:53] I see stuff like that in some apparmor profile : http://pastebin.com/cuynSmmR [09:53] what is it? is this for unix sockets? [10:02] ogra_: you do for the moment but my patch for ubuntu-core can easily be updated for the kernel (and gadget) snaps [10:02] ogra_: do you have a list of registered core, kernel and gadget names that you want me to add? [10:02] jdstrand, cool, i'll give you a list later today [10:03] ok [10:03] currently pi2-kernel and pc-kernel ... i have some hope we'll get a proper name for the dragonboard soon ... thats the last one in the list [10:06] jdstrand: hey, do you have a ecryptfs home system and a spare moment to test something? sudo snap intsall --devmode --edge ubuntu-device-flash and sudo DEBUG_DISK=1 /snap/bin/ubuntu-device-flash core 16 --kernel canonical-snapdragon-linux --gadget canonical-dragon --os ubuntu-core --channel=edge -o $(pwd)/dragon.img gives me an an permission denied error on my ecryptfs system but not on my other system. plus no denias in dmesg and I'm a bit lost [10:06] and wonder if its reproducable on other ecryptfs systems [10:07] mvo: what's the denial? note zyga just committed something to snap-confine yesterday for that [10:07] jdstrand: no denial that is the "funny" part [10:08] mvo: I can test in a vm easily enough [10:08] mvo: xenial system? [10:08] jdstrand: strace shows me stat("dragon.img") gets a permissions denied, but only if I run it with snap-confine, if I run the binary directly its fine [10:08] jdstrand: yeah, xenial [10:10] Bug #1612595 opened: 'Bad system call' when running python3 snap in strict mode [10:13] mvo: you said snap-confine-- is this the package from proposed? [10:13] jdstrand: ups, sorry, ubuntu-core-launcher is the same [10:14] jdstrand: I meant, when its running under confinement or bind mount stuff [10:14] ok [10:14] jdstrand: its not clear if its the confinment, probably not as no denials, but its something and I suspect it has to do with ecryptfs [10:14] pulling in -updates now and then will run the command [10:14] thanks [10:15] jdstrand: and sorry for hijacking you in your morning :) [10:15] it's fine. almost done confirming [10:17] mvo: failed to create user data directory. errmsg: Permission denied [10:17] mvo: is that what you are seeing? [10:18] mvo: I see that with ecryptfs. without ecryptfs is works. I do have a denial: sec-xenial-amd64 kernel: [ 463.066552] audit: type=1400 audit(1470997002.687:24): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/testuser/.Private/" pid=13878 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=0 ouid=1001 [10:18] mvo, ok, both kernels are building now ... https://code.launchpad.net/~snappy-dev/+snap/canonical-snapdragon-linux https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel [10:18] mvo: perhaps you are hitting kernel rate limiting? [10:18] i'll ping you when they are ready for store approval [10:18] mvo: let me see if zyga's commit yesterday fixed that [10:19] bah, crap FTBFS [10:20] ogra_: yay [10:20] mvo: yes, see 450b660ac91d4ced15185dbdbd2b547ae74fdcec [10:20] jdstrand: this is not what I am seeing, htis error is fixed with the version in -proposed [10:20] is it? [10:20] jdstrand: sorry, I should have mentioned this [10:20] proposed still has .4 [10:20] jdstrand: well, in the latest snap confine upload [10:21] it isn't fixed there [10:21] jdstrand: its also in the ppa:snappy-dev/image ppa [10:21] jdstrand: yeah, its not accepted yet [10:21] I can try that ppa [10:22] jdstrand: ppa:snappy-dev/image is the one [10:22] jdstrand: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/6798247/+listing-archive-extra [10:22] .7's yeah, I'm there. trying with .7 [10:22] hmm, looks like snappy-dev can not builod from a branch owned by ~ogra ... [10:24] mvo: upgrading to .7 it works fine [10:24] mvo: perhaps you are hitting rate limiting *and* your profile in /etc/apparmor.d/usr.lib.snapd.snap-confine didn't get updated? [10:25] (it's a conffile) [10:27] jdstrand: oh, it works fine, the u-d-f is creating a dragon image? [10:27] mvo: oh wait, I mispoke [10:27] (i.e. downloading stuff etc) [10:28] Error creating /home/testuser/dragon.img of size 3899999744 to stage image onto [10:28] mvo, https://myapps.developer.ubuntu.com/dev/click-apps/5573/rev/4/ ready for approval [10:28] jdstrand: woah, thats a differnt error than the one I got, vm size limitation maybe? [10:29] ogra_: done [10:29] cool [10:29] i'll build a test image :) [10:29] mvo: it worked outside of ecryptfs [10:29] (while waiting for the dragonboard kernel) [10:30] jdstrand: oh, interessting [10:30] jdstrand: the error is different than the one I got though, still interessting [10:31] Aug 12 05:31:26 sec-xenial-amd64 kernel: [ 1346.914860] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-28] [10:31] Aug 12 05:31:26 sec-xenial-amd64 kernel: [ 1346.914868] ecryptfs_write: Error encrypting page; rc = [-28] [10:31] mvo: that is my issue ^ [10:33] jdstrand: you ran out of space [10:33] ENOSPC [10:33] it looks like I did [10:33] yeah [10:34] that's weird [10:34] it completes in the non-ecryptfs [10:34] which has the same 'not enough space' [10:34] 2198480 [10:34] * jdstrand tries to free up some space [10:35] hrm, 4gb is the minimium right now :/ which is silly, 2 is probably fine [10:36] gimme a few minutes [10:38] sure, no rush, I might consider lunch in the meantime :) fwiw, the error I get is "Error: Could not stat device /home/egon/tmp/10/dragon.img - Permission denied." (and strace shows that its indeed parted doing a stat() on that file and gets a permission denied error) [10:39] mvo, before you go, please approve https://myapps.developer.ubuntu.com/dev/click-apps/4739/rev/10/ [10:40] ogra_: sure thing [10:40] ubuntu@localhost:~$ snap list [10:40] Name Version Rev Developer Notes [10:40] pi2-kernel 4.4.0-1019-raspi2-1 4 canonical - [10:40] pi3 16.04-0.1 1 canonical - [10:40] ubuntu-core 16.04.1 215 canonical - [10:40] ubuntu@localhost:~$ [10:40] \o/ [10:40] pi3 works fine, testing pi2 and dragonboard now [10:41] mvo: /home/egon/tmp is an interesting path [10:43] jdstrand: :) [10:43] ogra_: nice! [10:44] mvo, fyi, once i know all images boot and run, i'll rip out all kernel code from livecd-rootfs, that will massively speed up ubuntu-core builds ... [10:44] (a build should be below/around 5min then) [10:45] neat! [10:45] happy lunching :) [10:49] ok [10:49] Error: Could not stat device /home/testuser/dragon.img - Permission denied. === hikiko|afk is now known as hikiko [10:57] ubuntu@localhost:~$ snap list [10:57] Name Version Rev Developer Notes [10:57] pi2 16.04-0.7 12 canonical - [10:57] pi2-kernel 4.4.0-1019-raspi2-1 4 canonical - [10:57] ubuntu-core 16.04.1 219 canonical - [10:57] ubuntu@localhost:~$ [10:57] pi2 looks good as well ... [11:01] mvo: ok, I can confirm the issue. stat("/home/testuser/dragon.img", 0x7ffe650b4c40) = -1 EACCES (Permission denied) [11:02] mvo: I don't know why it is doing that [11:03] the file exists [11:03] but no denial in the logs suggests DAC [11:04] jdstrand: thanks for confirming, its super confusing - and outside of ecryptfs it does work for you, right? i.e. in /root ? [11:05] yes, outside of ecryptfs it works fine [11:06] I thought it might've had something to do with the directory perms of the user since ecryptfs uses 700 for $HOME. that wasn't it [11:07] jdstrand: utterly confusing, also working fine when I run it without ubuntu-core-launcher on ecryptfs [11:07] * mvo really lunches now [11:08] mvo: feel free to lunch-- just trying some stuff. I get the same issue if I 'apparmor_parser -R /etc/apparmor.d/usr.lib.snapd.snap-confine [11:09] ubuntu@localhost:~$ snap list [11:09] Name Version Rev Developer Notes [11:09] canonical-snapdragon-linux 4.4.0-1022-1 10 canonical - [11:09] dragonboard 16.04-0.3 2 canonical - [11:09] ubuntu-core 16.04.1 218 canonical - [11:09] ubuntu@localhost:~$ [11:10] and here we go, dragonboard fine as well [11:10] * ogra_ dances [11:15] ogra_: can you give me again the link to your latest pi3 kernel snap? [11:18] morphis, it is in the store (auto-submitted now) [11:18] zyga: I didn't follow your blog post yet but so far I just duplicated home.go builtin interface and modified it, but I don't see my interface when doing "snap interfaces". I added my interface in all.go [11:18] ogra_: yeah, looking for a download link [11:20] morphis, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel [11:20] thanks! [11:24] ysionneau: follow my whoole series please, it's lal documented [11:25] * zyga has laggy link today === chihchun is now known as chihchun_afk [11:45] mvo: sorry, I think we need tyhicks [11:48] mvo, http://paste.ubuntu.com/23049201/ ... 300 lines dropped \o/ [11:50] (well, actually more like 250 lines ... but still :) ) [11:51] mvo, niemeyer: can you guys merge https://github.com/snapcore/snapd/pull/1502 today? [11:51] PR snapd#1502: Add an interface for tpm [11:53] tyhicks: http://paste.ubuntu.com/23049207/ . Note, depending on the diskspace you might need to rm the dragon.img between switching backing and forth from /home/testuser and /home/foo [12:07] jdstrand: thanks so much [12:09] zyga: yeahh I forgot to add my interface to snap/implicit.go :' good it works now [12:28] PR snapd#1502 closed: Add an interface for tpm [12:30] mvo, i'm building an ubuntu-core with the above livecd-rootfs change now, please dont publish this set until i did some basic local testing with it [12:32] just got a messages from 2.14 that the 'copy' plugin was being deprecated in favor for the 'dump' plugin [12:32] but dump does not seem to be documented on http://snapcraft.io/docs/reference/plugins [12:36] danwest: perhaps file an issue at https://github.com/ubuntudesign/snapcraft.io/issues [12:39] popey, so I can do that but do we not have any notes, hints or something? looks like the syntax is completely different than 'copy' [12:39] sure, one moment [12:40] here's an example of a snapcraft.yaml which has been updated, linked to this so you can see the diff https://github.com/ubuntu/snappy-playpen/issues/216 [12:40] zyga: if a snap requires an interface, does that interface get automatically installed? [12:40] copy -> dump, files -> organize, basically [12:40] stokachu: interfaces are not installed, they are a part of snapd [12:40] stokachu: plugs and slots exits on specific snaps [12:41] stokachu: except for the core snap that has some implicitly defined slots, those are also defined by snapd [12:41] so if there is a juju plug do i need to make sure juju snap is installed [12:41] stokachu: or anything else that provides juju slot [12:41] like is there a way to tell my snap that it has dependencies on juju [12:41] stokachu: but yes [12:41] how would a user of my snap know to install juju as well? [12:41] stokachu: not at present [12:42] stokachu: if the interface name is just juju this could be documented somewhere (or your snap could detect this and recommend something) [12:42] stokachu: though right now that is not implemented as interface hooks are not yet implemented [12:43] doesn't having dependencies on other snaps defeat the purpose? [12:43] stokachu: it's not a dependency on a snap, it is a plug that is disconnected [12:43] mvo, ok, a build after the change takes 5-12 min now (fastest arch is 5 min, slowest (s390x) is 13), just amd64 is done in 6min [12:43] stokachu: that's a *big* differene [12:43] *difference* [12:44] zyga: right but you still have to install another snap to make the plug connected? [12:44] stokachu: and connect it as well [12:44] so the only way a user would know that is if they readme some documentation after installing my snap? [12:44] stokachu: yes [12:44] stokachu: later on your snap can detect this properly and advise the user [12:45] would it just install it automatically? [12:45] stokachu: snapd? not at present; I cannot comment on future features that are not planned at this time [12:45] stokachu: I would recomemnd that you raise this issue on the mailing list as it is an interesting use case [12:45] stokachu: and I see how it would be interesting to offer more streamlined integration [12:46] well it's basically doing what apt does [12:46] popey, thanks [12:46] stokachu: I disagree, there's a big importand difference here; your snap doesn't need juju, it needs what the juju interface provides, a socket, maybe there are many versions of juju [12:47] my snap does need juju though [12:47] stokachu: or a very popular fork of juju called, say, fufu [12:47] i see [12:47] stokachu: no, it needs juju *socket*, not some juju libraries or executables (as it cannot use those) [12:48] but if i need to bootstrap i need to run juju executable [12:48] stokachu: you have to include that in your snap, you cannot use executables from other snaps [12:48] stokachu: that executable can use a juju socket from the juju interface to talk to some juju (or over the network to talk to anything) [12:48] PR snapd#1550 closed: tests: base security spread tests [12:48] ok [12:49] that clears it up, thanks [12:49] stokachu: not all the concepts from classic packages and dependencies map to snaps in obvious ways but I strongly believe we're building something better here; [12:50] zyga: so do you think my snap is worth being a snap? i have to call out to other executables like lxc, juju, tail, etc [12:51] danwest: no problem [12:51] stokachu: yes [12:52] jdstrand: I looked at 14.04 support and it seems that some prctl arguments are not supported [12:52] jdstrand: do you think it would be sensible to just not support them and not generate / use them in our seccomp profiles? [12:53] PR snapd#1299 closed: create mir interface [12:55] zyga: hrmm, that is problematic. note that 14.04 also doesn't have apparmor unix mediation [12:55] zyga: at least with apparmor we can update the tools and they will ignore unix rules on an old kernel [12:56] zyga: I'm not sure how to do that with seccomp. I guess check for them at compile time and conditionally add them? [13:07] PR snapd#1671 opened: spread: Use /home/gopath in spread.yaml