[00:00] <mhall119> d_ed: they aren't completely blocked, but access to them is mediated so apps can be given what they need and nothing more
[00:00] <d_ed> mediated by apparmor in the dbus server?
[00:01] <mhall119> access is determined by what "interface" they have a plug for, and that plug being connected (either automatically or with user concent, depending on the interface) to the appropriate slot
[00:01] <mhall119> d_ed: I believe it's apparmor, yes, but jdstrand or mdeslaur can probably confirm
[00:02] <mhall119> on distros without apparmor, snaps will have to run without confinement until an alternative can be integrated
[00:02] <d_ed> oh that's another topic I want clarifying:
[00:02] <d_ed> do you intent for snaps to be a thing on non Ubuntu platforms?
[00:03] <mhall119> absolutely
[00:03] <d_ed> most the snaps are linking against libs from the system aren't they?
[00:03] <mhall119> at the very least, other Linux platforms
[00:03] <d_ed> rather than all being in the snap layers
[00:03] <mhall119> no, they link against the "core" snap, which is a stripped down Ubuntu
[00:04] <mhall119> and soon they will be able to link to libs in a common shared snap
[00:05] <mhall119> so the snappy system should be insulated from the host system
[00:05] <mhall119> which would allow snaps to run on Fedora, for example, without knowing or caring that they're on Fedora
[00:06] <mhall119> d_ed: importantly, snappy as a project is welcoming to any changes/patches that are needed to make it work on other distros
[00:07] <d_ed> ok, and when buidling with snapcraft we can link .deb depencies, that'll always be Ubuntu ones because it's all from that core snap
[00:07] <sgclark> mm I don't think so
[00:08] <sgclark> I am using Neon debs atm
[00:08] <mhall119> I don't think the deb dependencies are necessarily related to the core snap, that was just a shortcut to getting pre-build binaries into the snap filesystem
[00:09] <sgclark> and I am going to be so overwehlmingly busy next week, I don't know that anything can help me lol. I also have to get all these things on my kde ci
[00:11] <sgclark> but hey, can't complain, I will be busy in the comfort of the Swiss alps.
[00:12] <mhall119> yeah, that's a pretty sweet sprint location
[00:14] <d_ed> RE DBus: It is restricted in the apparmor profile of the relevant snap
[00:14] <d_ed> with a lovely whitelist for gtk things
[00:14] <sgclark> hah
[00:15] <d_ed> but we can ship our own apparmor profiles, so that's quite good
[00:15] <sgclark> ok cool
[00:15] <mhall119> d_ed: ideally for KDE apps we would minimize most of the .deb dependencies, and build frameworks and qt
[00:15] <sgclark> I think we might go the opposite
[00:16] <sgclark> actually. to reduce repeat work
[00:16] <d_ed> we're building our for flat-pak
[00:16] <mhall119> d_ed: it's in the profile, yes, the snap's meta-data is used to generate a custom profile from a pre-defined template
[00:16] <sgclark> I am getting the latest and greatest using neons debs
[00:17] <sgclark> anyway, i am trying it, sitter asked me too and I have a hard time saying no to him lol
[00:17] <d_ed> allows us to tweak a few things to be better suited for running containerised (KDE_FORK_SLAVES for example, as we can't reach klauncher)
[00:17] <d_ed> :D
[00:17]  * mhall119 is in over his head with that
[00:19] <mhall119> d_ed: you're building apparmor profiles for flatpak?
[00:20] <d_ed> no, no, we build our own frameworks and Qt
[00:20] <mhall119> oh, ok
[00:20] <mhall119> then yes, that can be reused to build snaps
[00:20] <d_ed> flatpak doesn't use apparmor for DBus filtering, instead you have a proxy process (per "pak") that acts as a gateway between two busses
[00:20] <d_ed> it's a bit over complex
[00:22] <mhall119> do apps need to target that proxy specifically, or is it like a transparent proxy that looks like dbus?
[00:22] <d_ed> in theory or in practice?
[00:22] <mhall119> you mean they're not the same? :)
[00:22] <sgclark> lol
[00:23] <d_ed> the difference between theory and in practice, is that in theory, they're both the same
[00:23]  * mhall119 loves that saying
[00:23] <sgclark> lol
[00:23] <sgclark> ok I have to finish packing, leave tomorrow, see you Sunday d_ed!
[00:24] <d_ed> see you
[00:24] <d_ed> mhall119: I assume adding custom plugs/slots would be changes to snappy?
[00:25] <mhall119> d_ed: so snapd defined "interfaces", on one side of which is a plug and the other side is a slot
[00:26] <mhall119> interfaces for now are built into snapd itself
[00:26] <mhall119> but any snap can provide a plug or a slot for one of those interfaces
[00:26] <d_ed> ah! that's quite nice
[00:27] <mhall119> an example I'm looking at currently is Elementary's Contractor dbus service. That we would add to snapd as an interface, then they would provide a pantheon slot for that interface, and geary would provide a plug for it, and then snappy would connect the two together
[00:29] <mhall119> interfaces are fairly new, and I don't think anybody knows yet how we're going to scale that out, but having more use-cases like Contractor will help us figure that out
[00:30] <mhall119> sgclark: have a safe trip
[00:30] <mhall119> and you too d_ed :)
[00:32] <d_ed> more questions: My Ubuntu box runs snaps with "ubuntu-core-launcher" is this replaced by "smap-confine" ?
[00:33] <mhall119> sgclark: d_ed: I will be off work on Monday, though probably online, you can ping me if you need more information. Or just ask in here, which should be more active during Randa's daytime :)
[00:33] <mhall119> d_ed: that I don't know, several things are being renamed to be less "ubuntu-" and more distro-agnostic, so it could be
[00:34] <d_ed> edit, git logs says it is
[00:34] <d_ed> should have done that first
[00:35] <mhall119> snappy is evolving rapidly right now, which is part of the reason we want to have as many examples and use-cases from outside of Ubuntu and our apps as we can, so they can help direct that evolution
[00:38] <mhall119> d_ed: sgclark: something else you might be interested in, the snap store has beta-testing channels now, and snapcraft can push updates there from the command-line, so it's possible to use your CI infrastructure to publish the very latest updates to people who want to subscribe to that channel
[00:39] <d_ed> fyi, snapd doesn't appear on the repo listings of https://github.com/ubuntu-core
[00:39] <sgclark> mhall119: oh cool!
[00:39] <d_ed> but typing it manually works
[00:40] <mhall119> d_ed: It's on https://github.com/snapcore
[00:40] <d_ed> s/snapd/snappy
[00:40] <mhall119> again, moving away from ubuntu-* naming for this
[00:40] <d_ed> ah ok
[00:43] <d_ed> makes sense
[00:43] <d_ed> then I'm finally out of questions
[00:43] <mhall119> I'm sure that will chance come Monday :)
[00:44] <sgclark> yes
[00:45] <mhall119> as I said, folks in here on Monday will be able to answer any other questions you have, and I will be off-and-on around on Monday and then back fully on Tuesday
[00:46] <mhall119> I hope you both enjoy the Alps
[00:46] <sgclark> ty
[07:09] <tsimonq2> so when I try to execute snaps, I get the following error thrown at me: failed to create user data directory. errmsg: Permission denied
[07:09] <tsimonq2> anyone know what's going on here?
[08:41] <zyga> o/
[08:41]  * zyga gets to work
[10:52] <lundmar> hi, is it possible in a snap .yaml to somehow reuse eg. the version as a value in eg. source?  For example: source: https://github.com/tio/tio/releases/download/v$version/tio-$version.tar.xz ?
[10:53] <lundmar> *variable
[10:56] <lundmar> hmm, why does a 1.20 version collapse into 1.2? Does snapcraft really force this type of version scheme?
[11:01] <lundmar> hmm, version: "1.20" did the trick so it does not collapse to 1.2
[11:02] <lundmar> yaml magic aye
[12:27] <zyga> lundmar: not today. but recall that snapcraft generates snap.yaml
[12:28] <zyga> lundmar: so there's a lot of room for variables and other stuff
[12:28] <zyga> lundmar: but the proper layer is above snap.yaml,
[12:28] <zyga> lundmar: so that complexity on snapd is not increased
[12:29] <lundmar> zyga: it's one of those convenience things. Would be nice not having to change the .yaml in multiple places just to bump version.
[12:49] <zyga> lundmar: and it is possible, just do it in snapcraft
[12:51] <lundmar> zyga: I'm not sure what you mean, I'm already using snapcraft - here is my snap: http://pastebin.com/zPZ62zyE
[12:52] <lundmar> I don't know of any way to reuse version in eg. source but I'm not yaml expert either.
[13:47] <zyga> lundmar: sorry, I meant that this is something that snapcraft could support
[13:47] <zyga> lundmar: then the variable could be used in snapcraft.yaml
[13:47] <lundmar> zyga: got it.
[13:47] <zyga> lundmar: and then snapcraft would replace the variable and generate the same snap.yaml we support today
[13:48] <zyga> lundmar: putting the complexity where it hurts less
[13:48] <lundmar> it would probably be a good feture for select key variables like version, name etc.
[13:48] <lundmar> feature*
[15:03] <zyga> jdstrand: do we have to support ~/.config/pulse/cookie?
[17:53] <tsimonq2> sorry for the repeat, but when I try to execute snaps, I get the following error thrown at me: failed to create user data directory. errmsg: Permission denied
[17:54] <tsimonq2> anyone know what's going on here?
[17:54] <tsimonq2> that's for multiple snaps
[17:55] <tsimonq2> I even have a snap *I* created in devmode that doesn't work because of that error
[17:55] <tsimonq2> I'll fire up a clean VM and try, but it's just really...annoying
[18:16] <qengho> tsimonq2: $ apt policy snapd; dmesg     # to pastebin
[18:18] <tsimonq2> qengho: http://paste.ubuntu.com/17222462/
[18:19] <tsimonq2> that's apt policy snapd
[18:19] <tsimonq2> http://paste.ubuntu.com/17222480/ - and this is dmesg
[18:20] <qengho> tsimonq2: You should have 2.0.5 if you're on 16.04.
[18:20] <tsimonq2> qengho: I'm on Yakkety
[18:20] <tsimonq2> qengho: do I have to install a PPA then?
[18:20] <qengho> Oh, then you should have 2.0.8 or something!  :)
[18:21] <qengho> Actually, I don't know that^. I'll verify.
[18:21] <tsimonq2> !info snapd yakkety
[18:21] <tsimonq2> !info snapd xenial
[18:21] <tsimonq2> qengho: ^ :)
[18:21] <tsimonq2> O_O huh?
[18:21] <qengho> Ugh.
[18:21] <tsimonq2> well how does that work? :P
[18:22] <tsimonq2> I'll manually install the Xenial packages for now
[18:22] <qengho> It's technically possible, but weird because updating stable released (especially LTS!) is really hard, but updating the devel line is dead easy.
[18:23] <tsimonq2> yeah
[18:23] <tsimonq2> in fact, it probably should have went to Yakkety first
[18:23] <tsimonq2> because wouldn't it require an SRU?
[18:24] <qengho> Yes, unless it has an exception, and this might have one because it's new and not "released" yet. I don't know, here.
[18:25] <qengho> tsimonq2: Anyway, after .5, let us know if it still happens.
[18:25] <tsimonq2> I'm getting .8 from Launchpad :D
[18:26] <tsimonq2> :/ still
[18:27] <tsimonq2> [54353.152981] audit: type=1400 audit(1465669563.399:43): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/simon/.Private/" pid=9481 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[18:27] <tsimonq2> [54353.152986] ecryptfs_dir_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-13]
[18:27] <qengho> $ systemctl restart snapd.service   # try this
[18:27] <tsimonq2> nope still
[18:27] <tsimonq2> does it help to know that I have an encrypted home directory?
[18:27] <qengho> tsimonq2: That second message is really weird.
[18:28] <qengho> I can tell you have one, silly.
[18:28] <tsimonq2> [54445.418517] audit: type=1400 audit(1465669655.670:44): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/simon/.Private/" pid=9549 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[18:28] <tsimonq2> [54445.418521] ecryptfs_dir_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-13]
[18:28] <tsimonq2> again... :P
[18:28] <qengho> "r" attempt, fail, that's fine.
[18:28] <qengho> read
[18:29] <tsimonq2> so apparmor can't read anythong off of my home directory?
[18:29] <qengho> tsimonq2: $ mkdir ~/snap/YOURSNAPPACKAGENAME
[18:29] <tsimonq2> *anything
[18:29] <tsimonq2> oh okay
[18:29] <tsimonq2> $ mkdir ~/snap/liferea
[18:29] <tsimonq2> mkdir: cannot create directory '/home/simon/snap/liferea': File exists
[18:30] <qengho> Oh, good.
[18:30] <qengho> Huh!
[18:30] <qengho> "ls" to make sure that's a dir, not a regular file.
[18:30] <tsimonq2> yup
[18:30] <tsimonq2> FWIW: drwxrwxr-x 3 simon simon 4.0K Jun 11 02:06 liferea
[18:31] <tsimonq2> and drwxrwxr-x 2 simon simon 4.0K Jun 11 02:06 100001 inside of that
[18:31] <qengho> tsimonq2: I have no idea, offhand. Time to look at source code, or "strace" it.
[18:31] <tsimonq2> qengho: I'll try getting off of an encrypted home directory
[18:32] <qengho> tsimonq2: er, okay, but I have one too, and it works for me.
[18:32] <tsimonq2> if that magically fixes it, I'll file a bug
[18:32] <qengho> (I do get ugly dmesg about that^.)
[18:32] <tsimonq2> weird
[18:32] <tsimonq2> okay
[18:32] <tsimonq2> thanks :)
[18:32] <qengho> tsimonq2: I don't know if it'll work.
[18:33] <tsimonq2> well i'll try
[18:33] <tsimonq2> I'll also Google around
[18:33] <qengho> $ strace -f -o snaptrace -e trace=file -p $(pidof snapd)
[18:33] <qengho> Do as root, probably.
[18:34] <qengho> It it install time, or run time?
[18:34] <qengho> "execute". hmm
[18:34] <qengho> Okay, that's harder.
[18:34] <qengho> And I have some things to do in Real Life. Back later.
[18:35] <tsimonq2> o/