[00:53] <mup> PR snapcraft#1132 opened: Revert "qbs plugin: add plugin support for the Qt Build Suite (#1079)" <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1132>
[01:41] <james0r> how would i go about moving the snap dir out of my home dir?
[02:11] <mup> PR snapcraft#1120 closed: Update rustup link.  Bug: 1662960 <Created by cholcombe973> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1120>
[03:03] <Son_Goku> zyga: ping
[03:24] <Son_Goku> zyga: I found out how to make the selinux policy domain "permissive"
[03:24] <Son_Goku> so now it won't completely shut down snapd when it violates policy
[03:25] <Son_Goku> https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/4566045b2d4ab6d72cc8991814753997a53f6377
[03:33] <Son_Goku> anyway, "snap run hello" works in enforcing mode now
[03:33] <Son_Goku> the AVC denials are still made, but the thing doesn't break
[03:34] <Son_Goku> zyga: now, you need to update snapd to the latest version and refresh all the patches for snap-confine and snapd
[03:34] <Son_Goku> and we're *finally* pushing this out to F24+
[03:35] <Son_Goku> and we need to retire snap-confine and obsolete it with a snap-confine provided by snapd source package
[03:36] <Son_Goku> zyga: when I wake up tomorrow morning, I hope to see all of this done ;)
[06:26] <mup> PR snapcraft#1133 opened: tests: fix the test that was modifying the environment variables <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1133>
[06:40] <mup> PR snapd#2819 closed: packaging/ubuntu-14.04: inform user how to extend PATH with /snap/bin <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2819>
[07:27] <zyga> Son_Goku: \o/
[07:28] <zyga> Son_Goku: I'm going to the doctor now, I'll check back later
[07:28] <zyga> Son_Goku: let's try to roll out the package if we can this weekend
[08:12] <mardy> pstolowski: hi! So... I tried again with a working snapd, but I still get the same message: error: cannot add authorization: open /home/mardy/.snap/auth.json: permission denied
[08:12] <mardy> pstolowski: any idea what the message is about?
[08:14] <pstolowski> mardy, hmm that's a macaroon file used for connections with the store. are the permissions of the file correct? are you trying to do anything unusual from the hooks?
[08:15] <mardy> pstolowski: no, just snapctl :-) Let me have a look at the file...
[08:16] <pstolowski> mardy, this auth file is owned by regular user and permissions are 0600 here on my box
[08:16] <mardy> pstolowski: it's -rw------- for mardy.mardy (my user)
[08:17] <pstolowski> mardy, yeah, that's fine. does journalctl shows anything interesting?
[08:19] <mardy> pstolowski: a few denials, let me paste them...
[08:20] <mardy> pstolowski: http://paste.ubuntu.com/23965752/
[08:22] <pstolowski> mardy, yeah, these are "expected" and we have a bug opened to get rid of them (we needlessly try to connect to that socket)
[08:22] <pstolowski> mardy, but that doesn't cause any issues
[08:23] <pstolowski> mardy, can you push all your changes to that branch you gave me earlier?
[08:23] <mardy> pstolowski: yup
[08:24] <mardy> pstolowski: all pushed to lp:~mardy/webapps-core/iface-hook-test
[08:24] <mardy> pstolowski: let me also push my snapd branch, where I've added the online-accounts interface...
[08:26] <mardy> pstolowski: this is my snapd branch: https://github.com/mardy/snapd/tree/hook-test
[08:26] <pstolowski> ok
[08:26] <mardy> pstolowski: it's snapd master from today, + your branch, + the OA interface
[08:29] <pstolowski> mardy, and what do you do to trigger that error?
[08:33] <imexil> Hi, I was wondering, is there a website where I can browse current registered snaps and see which account they are maintained by?
[08:35] <imexil> Also how can one overtake the maintenance of a snap package that was pushed earlier by another dev that no longer has an interest in maintaining them and agrees to give the rights to me.
[08:35] <pstolowski> mardy, also.. do you have encrypted home?
[08:36] <mardy> pstolowski: the error is triggered when I connect the interface
[08:36] <mardy> pstolowski: no encrypted home here
[08:36] <pstolowski> mardy, do normal store ops (installing snaps from store) work?
[08:57] <imexil> ogra_,  popey: FYI The kind of feedback I was already assuming from upstream regarding yesterdays discussion/help from you: https://github.com/otfried/ipe-tools/pull/24#issuecomment-278880408
[08:57] <mup> PR otfried/ipe-tools#24: Upgrade snap to version 7.2.7 <Created by dietmarw> <Merged by otfried> <https://github.com/otfried/ipe-tools/pull/24>
[08:58] <pstolowski> mardy, when you say you trigger it when you connect the interface, do you mean you see it immediately on 'snap connect ...', or on any other operation, *after* the interface was connected?
[09:04] <mup> PR snapd#2828 opened: tests: increase service retries <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2828>
[09:29] <mup> PR snapcraft#1129 closed: 96boards: fix the dragonboard example <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1129>
[09:56] <zyga> re
[10:17] <mardy> pstolowski: sorry, somehow missed your pings :-)
[10:17] <mardy> pstolowski: yes, I can install snaps from the store (just installed the snappy-debug one)
[10:17] <mardy> pstolowski: I see it immediately
[10:18] <mardy> pstolowski: I presume it's part of the stderr of snapctl, but that's only my guess
[10:23] <mvo> mardy: you are on classic, right? not on an ubuntu-core only system? what is the output of snap version?
[10:23] <pstolowski> mardy, doesnt that happen only if interface hooks are in use? do you see it with other connect?
[10:24] <pstolowski> mvo, fyi, he is plying with my hooks branch, and they are using snapctl
[10:24] <mardy> mvo: classic, zesty
[10:24] <mardy> pstolowski: let me try to remote the call to snapctl
[10:24] <mvo> mardy: and snapctl gives you this error?
[10:28] <mardy> mvo: I think it's coming from invoking snapctl from within the hook; if I remove that call, then the error goes away
[10:28] <mardy> pstolowski: ^
[10:29] <mvo> mardy: we fixed this about a week ago but you may need to ensure that your snapctl is the one coming from the branch
[10:29] <pstolowski> mardy, ok, so we've been discussing it via telegram, apparently this was fixed ~week ago; are you up-to-date?
[10:35] <mardy> mvo, pstolowski: right, I only rebuilt snapd, not snapctl; let me try...
[10:38] <mardy> mvo, pstolowski: still getting the same... can you please point me at the commit which fixes it, to make sure that I have it?
[10:39] <mvo> mardy: https://github.com/snapcore/snapd/pull/2756
[10:40] <mup> PR snapd#2756: snapctl: add config in client to disable auth and use it in snapctl <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2756>
[10:40] <mvo> mardy: thinking about this, I think you get the snapctl from the core snap. please try "sudo snap refresh core --edge"
[10:41] <mvo> mardy: that should give you the latest up-to-date snapctl
[10:42] <sborovkov> jdstrand: hi, follow up question to my yesterday's question about dbus. I tried the solution you described but I was getting errors when installing snaps about plugs and slots having the same name. Now I changed yaml to this. Did I understand correctly what needs to be done for it to work? https://hastebin.com/ovuxiqiciz.http
[10:44] <mardy> mvo: mmm... updated, but I still get the same error
[10:45] <mvo> mardy: hrm, what do you see with "snap version"?
[10:45] <mup> PR snapd#2829 opened: tests: add libvirt interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2829>
[10:47] <mardy> snap    2.22+17.04
[10:47] <mardy> snapd   unknown
[10:47] <mardy> series  16
[10:47] <mardy> ubuntu  17.04
[10:47] <mardy> mvo: ^
[10:57] <mvo> mardy: let me investigate this a bit more. as a workaround you can do "mount  -o bind /usr/bin/snapctl /snap/core/current/usr/bin/snapctl"
[10:57] <mvo> mardy: or instead of /usr/bin/snapctl your own build of it
[10:59] <mardy> mvo: mmm... still the same
[10:59] <mardy> mvo: I'll now try with my own build
[11:00] <pedronis> snapd unknown ?
[11:00] <mvo> pedronis: I think he is running from a build dir
[11:01] <mardy> mvo: oh, if I bind-mount the one I've built, then it works
[11:02] <pedronis> mvo: doesn't that then use the one outside
[11:02] <mvo> mardy: yay
[11:02] <mardy> mvo: maybe the fix did not land to the core snap yet?
[11:02] <mardy> mvo, pstolowski: anyway, thanks a lot! Now I've something to work on :-)
[11:02] <mvo> mardy: I will check that, it should be but obviously there is a disconnect between theory and reality
[11:03] <pstolowski> mvo, thanks for looking at that!
[11:08] <mup> PR snapd#2236 closed: interfaces: add realsense interface <Decaying> <Created by swem> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2236>
[11:15] <Son_Goku> mvo, morning!
[11:15] <mvo> hey Son_Goku
[11:15] <Son_Goku> how are you? :)
[11:16] <mvo> Son_Goku: good, thank you! how are you?
[11:16] <Son_Goku> a bit groggy, but otherwise fine
[11:17] <mvo> Son_Goku: ha! I share that feeling, I need a cup of tea :)
[11:17] <Son_Goku> hehe
[11:17] <Son_Goku> I'm pleased that we'll *finally* be able to release snapd into Fedora, though
[11:17] <Son_Goku> unfortunately, I can't do it because there's a bunch of patches that need to be rediffed for snap-confine and snapd, and possibly more patches
[11:18] <Son_Goku> and unfortunately, none of the patches can be upstreamed :(
[11:18] <zyga> Son_Goku: hey
[11:18] <zyga> Son_Goku: I can help
[11:19] <Son_Goku> I mean, you're going to have to do it :/
[11:19] <Son_Goku> we're so far behind
[11:19] <mvo> Son_Goku: meh, that is sad. at the same time, super exciting that it can go in now
[11:19] <zyga> Son_Goku: I think we need to ship snap-confine setuid root, I've been digging through the kernel but I didn't find the test that fails without it
[11:19] <Son_Goku> you *can* use setuid
[11:19] <Son_Goku> it's just not preferred
[11:19] <zyga> Son_Goku: oh, in that case one issue less off the table
[11:19] <Son_Goku> file a bug about the cap issue against snapd and we'll switch back once it's fixed
[11:20] <zyga> Son_Goku: I think we can figure out the caps but I don't want it to block the release
[11:20] <zyga> Son_Goku: yes, I filed it...
[11:20] <zyga> https://bugs.launchpad.net/snapd/+bug/1657099
[11:20] <mup> Bug #1657099:  snap-confine cannot perform namespace capture even with CAP_SYS_ADMIN <snapd:New> <https://launchpad.net/bugs/1657099>
[11:20] <zyga> that's the issue
[11:21] <zyga> Son_Goku: btw, did you try to refresh the package to 2.22?
[11:21] <Son_Goku> not yet
[11:22] <Son_Goku> I just figured out the selinux policy thing before going to sleep
[11:22] <zyga> Son_Goku: that's great news, my fedora box is so lonely without snaps :/
[11:22] <zyga> Son_Goku: I found a way to run snaps with classic confinement on fedora
[11:22] <zyga> Son_Goku: I didn't code the patch yet but I will as soon as I'm done with content
[11:22] <Son_Goku> so, it's not a real solution, but it means that AVC denials won't block snapd
[11:22] <zyga> Son_Goku: let's do that, we can iterate on the policy
[11:23] <zyga> Son_Goku: but not without being able to use it at the same time
[11:23] <Son_Goku> that's the point of it :)
[11:23] <mup> PR snapcraft#1135 opened: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1135>
[11:23] <Son_Goku> we should have done it in the beginning, but I didn't know about it
[11:23] <zyga> Son_Goku: I've been fixing some issues in the content interface but this is dragging on due to extra complexity
[11:23] <Son_Goku> and no one told me
[11:23] <Son_Goku> I stumbled on it, and realized it resolved our problem
[11:25] <Son_Goku> I also have some bad-ish news for you regarding openSUSE packaging
[11:25] <zyga> Son_Goku: yes?
[11:25] <Son_Goku> they've completely changed how Golang packaging is done
[11:25] <zyga> !!!
[11:25] <zyga> do you have a reference?
[11:25] <Son_Goku> whoo boy do I have one
[11:25] <zyga> and what did they decide upon?
[11:26] <Son_Goku> https://github.com/openSUSE/golang-packaging/pull/5
[11:26] <mup> PR openSUSE/golang-packaging#5: fix for SLE11SP3 <Created by marguerite> <Closed by tboerger> <https://github.com/openSUSE/golang-packaging/pull/5>
[11:26] <Son_Goku> they're now doing the same thing Fedora does
[11:26] <Son_Goku> source code only libraries
[11:27] <Son_Goku> basically, the Docker team and the creator of golang packaging didn't get along
[11:27] <Son_Goku> so the golang packaging creator was forced out, and now openSUSE packaging is closer to Fedora than before
[11:27] <zyga> Son_Goku: oh boy
[11:27] <zyga> Son_Goku: some heavy words fly there
[11:27] <Son_Goku> yeah
[11:28] <Son_Goku> and of course, it's all still undocumented :(
[11:28] <zyga> Son_Goku: after content I should be able to do a deep dive
[11:29] <zyga> Son_Goku: with debian in good hands (CI will be working on Debian soon, I heard)
[11:29] <Son_Goku> bah
[11:29] <zyga> Son_Goku: I plan to split my focus 50/50 on Fedora and Suse
[11:29] <zyga> Son_Goku: and after Fedora is operational see if we can build for derivatives and CentOS
[11:29] <Son_Goku> the only obstacle for RHEL and friends is the go compiler
[11:29] <Son_Goku> if it builds, we're gravy
[11:30] <Son_Goku> golang libraries will need to be refreshed too...
[11:30] <zyga> Son_Goku: ok, let's try to win some packages this week; I'm sick but I can hack on this all weekend if we have a chance to solve the problems
[11:31] <Son_Goku> I'm not sure how available I will be this weekend
[11:31] <zyga> Son_Goku: I didn't follow the drama/discussion closely
[11:32] <Son_Goku> I'm going to be at a hackathon on behalf of my company
[11:32] <zyga> Son_Goku: but I guess I just have to see how it looks like now
[11:32] <zyga> Son_Goku: woot, nice :)
[11:32] <zyga> Son_Goku: maybe next week then
[11:32] <mup> PR snapcraft#1136 opened: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1136>
[11:32] <Son_Goku> zyga: my bit is done :)
[11:32] <Son_Goku> you've got to refresh snapd.spec and patches up to 2.22
[11:33] <Son_Goku> and move snap-confine into being a subpackage of snapd
[11:35] <zyga> Son_Goku: thank you!!
[11:35] <zyga> Son_Goku: I'll see if I can get it to all work tonight
[11:35] <mup> Bug #1663565 opened: Media Keys do not work in strictly confined snaps <isv> <snapd:New> <Snappy:New> <https://launchpad.net/bugs/1663565>
[11:35] <zyga> Son_Goku: I'm really happy to see progress in this front
[11:36] <zyga> Son_Goku: btw, what about Mageia?
[11:36] <Son_Goku> keep in mind that you'll need to have snap-confine subpackage "Obsoletes: snap-confine < 1.0.44-3"
[11:36] <zyga> Son_Goku: ok, will do
[11:37] <Son_Goku> as for Mageia, since there's be zero progress on AppArmor upstreaming, it still doesn't work with stock AppArmor :(
[11:37] <Son_Goku> s/be/been/
[11:37] <Son_Goku> so no confinement
[11:37] <Son_Goku> but I can probably get it going derived from the Fedora packages as soon as you've made them and published them
[11:38] <zyga> Son_Goku: there's a lot of progress, look at's what in mainline now
[11:38] <zyga> Son_Goku: it's not all there but a good chunk did land
[11:39] <zyga> Son_Goku: now with the main part out there's been a large number of small fixes (I helped find a few of those :)
[11:39] <zyga> Son_Goku: they are all going up
[11:39] <Son_Goku> anyway, it doesn't matter that much since Mageia has no MAC enablement right now
[11:39] <Son_Goku> that'll have to wait for Mageia 7
[11:39] <zyga> Son_Goku: can packaging from Fedora be used on Mageia?
[11:39] <Son_Goku> yes
[11:39] <zyga> Son_Goku: sounds good
[11:39] <Son_Goku> we follow the same rules as Fedora
[11:41] <Son_Goku> zyga: also /writable will need to be moved, if that's still a thing
[11:41] <zyga> Son_Goku: /writable only exists on core systems
[11:41] <Son_Goku> can it be moved?
[11:42] <zyga> Son_Goku: are you talking about making a all-snap image with mageia base?
[11:42] <zyga> Son_Goku: /writable doesn't show up anywhere on the filesystem
[11:42] <Son_Goku> potentially, yes
[11:42] <zyga> Son_Goku: for a core system it is required and I can explain why
[11:42] <Son_Goku> okay..
[11:42] <zyga> Son_Goku: it could be "moved" but there's little reason to IMHO (but we can explore that later)
[11:43] <Son_Goku> it's not something we'll deal with right now
[11:43] <Son_Goku> I can't make an all-snap system until snapd and snapcraft remove their ubuntu assumptions anyway
[11:51] <zyga> Son_Goku: ogra keeps thinking about buildroot-based base snap
[11:52] <Son_Goku> bah
[11:52] <zyga> Son_Goku: I think we're getting closer to base snaps, maybe around spring?
[11:52] <ogra_> zyga, well, we have better tools in the distro actually :)
[11:52] <zyga> Son_Goku: the idea is that a totally separate base opens up a way to experiment
[11:52] <Son_Goku> I've already made tooling for producing such base snaps :)
[11:52] <ogra_> i think i'd actually use copy_exec() from initramfs-tools with a file list fed into it
[11:53] <Son_Goku> oh, man
[11:53] <Son_Goku> please don't tell me we can't use dracut?!
[11:53] <Son_Goku> and that Ubuntu Core still doesn't use dracut
[11:54] <Son_Goku> Debian has stated their intent to retire initramfs-tools for years
[12:02] <ogra_> Son_Goku, no, we dont use dracut, though there were some changes recently that at least allow you to use it in debian and ubuntu
[12:02] <Son_Goku> :(
[12:03] <Son_Goku> if Ubuntu Core is the Ubuntu of the future, it should be using dracut :/
[12:03] <ogra_> but the above has nothing to do with either ... i just want to use a function from the tools :)
[12:04] <ogra_> copy_exec resolves reverse binary and lib dependencies automatically ... if you use it to put any file in place you get exactly the bare minimum of libs and binaries needed to execute what you copy
[12:05] <ogra_> while buildroot is nice and all i think we should not stop using ubuntu binaries for creating core
[12:06] <Son_Goku> ogra_: well, you can guess what my opinion is :P
[12:06] <ogra_> we want the binaries but drop the overhead a deb package puts upon us and limit the set of shipped things to the bare minimum ...
[12:07] <ogra_> the current design doesnt allow that since we use a build tool that completely relies in dpkg
[12:08] <ogra_> s/in/on
[12:33] <mup> Bug #1663220 changed: Add support to Secret Service APIs <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1663220>
[12:57] <mup> PR snapd#2723 closed: tests/main: add test case to verify core snap conf option service.ssh.disabled <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/2723>
[13:18] <jdstrand> sborovkov: hey, gyi, I'm off today so at best 'in and out' (but mostly out :)
[13:19] <jdstrand> sborovkov: but I saw your question, so, per https://github.com/snapcore/snapd/wiki/Interfaces#dbus, you need to use 'name' on both sides
[13:19] <jdstrand> sborovkov: your slot looks fine. you need your plugs to also specify 'name: com.screenly'
[13:20] <jdstrand> sborovkov: also, if you want to rename your slot, you can use:
[13:20] <jdstrand> slots:
[13:20] <jdstrand>   something:
[13:20] <jdstrand>     interface: dbus
[13:20] <jdstrand>     name: com.screenly
[13:20] <jdstrand>     bus: system
[13:20] <jdstrand> then your plugs is fine:
[13:20] <jdstrand> plugs:
[13:21] <jdstrand>   somethingelse:
[13:21] <jdstrand>     interface: dbus
[13:21] <jdstrand>     name: com.screenly
[13:21] <jdstrand>     bus: system
[13:25] <zyga> jdstrand: o/
[13:25] <jdstrand> sborovkov: but you need to have one of your apps 'plugs: [ somethingelse ]' and one 'slots: [ something ]'. as it is now, since none of the apps use 'slots', they all get your toplevel slots, and since at least one of your apps 'plugs' stuff, none of them will get 'somethingelse'
[13:25] <jdstrand> sborovkov: see https://git.launchpad.net/~jdstrand/+git/test-hello-dbus/tree/snapcraft.yaml as an example
[13:25] <jdstrand> zyga: hey, not sure you saw, but I'm off today
[13:26] <jdstrand> sborovkov: good luck! there are others here who can help you if I don't see your followup questions :)
[13:26] <zyga> jdstrand: oh, I didn't remember; I'm just saying hi :)
[13:26] <jdstrand> zyga: heh, ok, hi!
[13:26] <zyga> jdstrand: nothing to do today :)
[13:27] <jdstrand> zyga: I think you've conditioned me to expect a code review when you wave at me :P
[13:27] <sborovkov> jdstrand: thanks :)
[13:27] <zyga> jdstrand: I'm sorry; I should give you a hug and beer sometimes :)
[13:27] <zyga> jdstrand: nothing to review :)
[13:28] <jdstrand> zyga: it's fine! :)
[13:44] <sborovkov> Hello, can someone help me out and tell me if I got correct syntax here? Want to expose interface by playlist service. And websocket service calls that interface. https://hastebin.com/foluxekeya.pl
[13:47] <mup> PR snapcraft#1137 opened: Build-depend on git <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1137>
[14:14] <mup> PR snapd#2830 opened: allow core_support interface to modify /etc/default/swapfile <Created by ogra1> <https://github.com/snapcore/snapd/pull/2830>
[14:24] <mup> Bug #1663615 opened: snap broken out of the box on 16.04.1 <Snappy:New> <https://launchpad.net/bugs/1663615>
[14:44] <mup> PR snapd#2831 opened: interfaces: add missing recvfrom syscall to dbus interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2831>
[14:46] <mup> Bug #1663303 changed: Running snapcraft on Ubuntu 14.04  fails with a traceback <isv> <trusty> <Snapcraft:New> <https://launchpad.net/bugs/1663303>
[14:48] <sergiusens> slangasek: more like a feature that only works on xenial
[15:01] <mup> PR snapd#2832 opened: interfaces/builtin: add network-setup-control which allows rw access to netplan <Created by morphis> <https://github.com/snapcore/snapd/pull/2832>
[15:22] <ara> question for anyone
[15:23] <ara> if you have a daemon that requires plug foo to be connected in order to work
[15:23] <mup> PR snapcraft#1131 closed: lifecycle: hardcode test_core_snap's PATH <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1131>
[15:23] <ara> is there a way to tell snapd to start the daemon only when that plug has been connected?
[15:24] <kyrofa> ara, unfortunately no
[15:25] <kyrofa> ara, snapd has no way of knowing that the plug in question is actually required or optional
[15:25] <ara> kyrofa, OK, thanks for confirming
[15:25] <kyrofa> ara, e.g. if you managed to write your service such that the plug only extended its functionality
[15:26] <kyrofa> ara, this is somewhat difficult without seccomp returning ERRNO, but it'll get easier soon
[15:29] <mup> PR snapcraft#1133 closed: tests: fix the test that was modifying the environment variables <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1133>
[15:51] <joc> elopio: hey, i got odd failures in tests after updating my PR again
[15:53] <didrocks> zyga: hey, are you around? I was able to connect 2 content interfaces which have different "content:" name
[15:55] <kyrofa> didrocks, my gift to you: https://lists.ubuntu.com/archives/snapcraft/2016-December/002189.html
[15:56] <didrocks> kyrofa: thx! I didn't remember your email :p
[15:57] <kyrofa> didrocks, haha, no problem
[15:57] <kyleN> should I always see the browser-support interface now, for example on pi2? (I don't: snapd version 2.21)
[15:57] <Blu2_> KDE neon to officially support snaps? nice. http://www.omgubuntu.co.uk/2017/02/kde-neon-intergrating-snap-apps
[15:59] <seb128> kyrofa, Tony asked on the list but is there a launchpad bug about it?
[16:00] <kyrofa> seb128, not that I logged anyway-- I read that it was a known bug and moved on, but I wonder if it's logged
[16:00] <seb128> :-/
[16:01] <kyleN> kyrofa, should I always see the browser-support interface now, for example on pi2? (I don't: snapd version 2.21)
[16:01] <kyrofa> kyleN, I thought so, but I'm not 100% sure. It's provided by the core snap
[16:02] <kyrofa> kyleN, once ogra_ is off of his call he can help
[16:02] <kyleN> kyrofa, yes its a builtin but I don't see it. I have a client that needs to use it and they don't see it either. do you have a recommended next step I should take?
[16:02] <zyga> didrocks: on a call
[16:02] <kyleN> ok
[16:03] <didrocks> zyga: no worry, kyrofa answered. A bug in content interface that you told "known" ;)
[16:22] <kyleN> kyrofa, ogra_: on browser-support interface not visible, I reported https://bugs.launchpad.net/snapd/+bug/1663656
[16:22] <mup> Bug #1663656: browser-support interface not reported <snapd:New> <https://launchpad.net/bugs/1663656>
[16:22] <ogra_> kyleN, not sure thats actualyl a core interface ... jdstrand would know
[16:23] <ogra_> i think it is tied somehow to unity7/x11
[16:23] <kyleN> kyrofa, ok. looking for pointers & info here to help a client.
[16:23] <ogra_> (which we do not have on the core images)
[16:25] <kyleN> ogra_, hi. ok so I suppose I can dig into why they need that interface and see if there is an existing one they can use, else we are blocked
[16:25] <ogra_> kyleN, well, lets see what jdstrand says perhaps we should have it in core but that might need some extra bits since we dont have any graphics system by default
[16:26] <kyleN> ogra_, ok
[17:06] <EEight> if I want access to a webcam, what should I put in the snap.yaml???
[17:09] <Blu2_> https://snapcraft.io/docs/reference/interfaces
[17:09] <brunch875> EEight: https://snapcraft.io/docs/reference/interfaces
[17:09] <Blu2_> camera
[17:09] <Blu2_> 1 second faster :D
[17:09] <brunch875> blast, I never thought I'd take precisely as long to reply
[17:10] <EEight> This is defined in plugs: right?
[17:11] <Blu2_> yes
[17:11] <Blu2_> https://snapcraft.io/docs/snaps/metadata
[17:14] <brunch875> is it / will it be possible for an user to restrict snap permissions?
[17:15] <brunch875> thinking twice about it, this is a silly question; since it's always possible to re-package the snap, right? :p
[17:15] <kyrofa> brunch875, can you be more specific?
[17:15] <kyrofa> brunch875, no such thing as silly questions!
[17:17] <brunch875> kyrofa: let's say some developer makes some... social media snap which asks for camera permission. And I want to use the whole social-media thing but I'm very concerned that the piece of software might spy me using the camera. Can I decide to deny access to the camera completely, even if the snap requires camera persmissions?
[17:18] <kyrofa> brunch875, oh certainly, one of my favorite features
[17:19] <kyrofa> brunch875, assuming you have any snaps installed, run `snap interfaces`
[17:19] <brunch875> any IRC snap I can fetch?
[17:20] <brunch875> oh, I could try telegram
[17:20] <kyrofa> brunch875, yeah that'll work
[17:20] <ogra_> theer should be a hexchat snap too
[17:20] <ogra_> even from the upstream guys afaik
[17:21] <kyrofa> brunch875, anyway, once you do that, you'll see a list of "slots" on the left and "plugs" on the right
[17:22] <kyrofa> brunch875, snaps are confined by using these (they're called interfaces). Plugs plug into slots
[17:22] <kyrofa> brunch875, so if an app "plugs into" the camera interface, you can simply use `snap disconnect` to break that connection
[17:22] <kyrofa> brunch875, which means it no longer has permission to access the camera
[17:22] <brunch875> nice!
[17:22]  * brunch875 applauds
[17:23] <kyrofa> brunch875, now, take this with a grain of salt: this will deny access, but not all applications will be written to be HAPPY with that
[17:23] <kyrofa> brunch875, ideally the app would just run and say "Ah, can't access the camera, no matter."
[17:23] <EEight> last question, is it true that a snap gets refresh automagically after 24h?
[17:24] <brunch875> and yet applications without exception handling will just [rude remark] themselves
[17:24] <kyrofa> EEight, four times a day, randomly distributed
[17:24] <kyrofa> brunch875, heh
[17:25] <brunch875> this design could allow for fake slots
[17:26] <kyrofa> brunch875, what would that be, technically?
[17:26] <brunch875> well, I was thinking of a fake camera device which was just a video on loop
[17:27] <brunch875> so the snapped application could be fooled to believe it was accessing the camera when it was not
[17:28] <cholcombe> in my snap plugin is it possible to install another snap that is needed to build the snap?
[17:28] <kyrofa> brunch875, that sounds difficult to implement in a generic way
[17:29] <kyrofa> brunch875, but nothing prevents you from writing a snap that provides a camera slot
[17:29] <brunch875> kyrofa: so could I re-route the slot from one snap to another, then?
[17:29] <mup> PR snapcraft#1132 closed: Revert "qbs plugin: add plugin support for the Qt Build Suite (#1079)" <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1132>
[17:29] <kyrofa> brunch875, yes you can
[17:30] <brunch875> !! So it already is there! Woah
[17:30] <kyrofa> brunch875, just `snap disconnect` it and `snap connect` it to another slot
[17:30] <brunch875> brilliant!
[17:30] <ogra_> sexy, aint it ? :)
[17:30] <elopio> joc: hey, we got a few issues closing this release. Please rebase with master.
[17:30] <kyrofa> brunch875, but it's not that easy-- the camera slot provides apparmor/seccomp snippets to allow hardware access. You'll have to fake that out somehow
[17:30] <brunch875> Wow, I'm really excited about snappy now
[17:31] <ogra_> welcome to the club :)
[17:35] <joc> elopio: we've also noticed that when using master our python parts fail to install
[17:35] <joc> elopio: we get clashes with "RECORD" files
[17:36] <brunch875> oops, apparently starting a line with !! triggered and ubottu edit request, whatever that means :x
[17:36] <joc> elopio: e.g. http://paste.ubuntu.com/23967962/ this doesnt happen with 2.26
[17:38] <elopio> kyrofa: did we change something in the conflicts on this release?
[17:39]  * elopio tries.
[17:41] <cholcombe> elopio, so in the rust plugin i'm thinking that if i snap rustup i can install that and it might help resolve my issue and eliminate the script needed to choose the correct rustup version
[17:42] <elopio> cholcombe: that will make sabdfl very happy.
[17:42] <cholcombe> elopio, can you install a snap in a plugin to help that plugin?  that seems like it wouldn't work?
[17:43] <elopio> cholcombe: that's how we want to support go1.7 in the go plugin. So we haven't done it yet, but we will do it soon.
[17:43] <cholcombe> cool.  is there a bug i can watch for that?
[17:43] <elopio> cholcombe: https://bugs.launchpad.net/snapcraft/+bug/1616985
[17:43] <mup> Bug #1616985: the go plugin doesn't support go 1.7 <isv> <plugin> <Snapcraft:Confirmed for sergiusens> <https://launchpad.net/bugs/1616985>
[17:45] <cholcombe> elopio, cool.  any idea when that might land?  just curious it's not critical or anythign
[17:46] <elopio> cholcombe: I think it's on top of the backlog for Sergio, but he's down sick today. Early next week.
[17:46] <cholcombe> elopio, nice.  that's rather quick.  i'll keep an eye on this bug
[17:46] <elopio> cholcombe: however you can play with that. Take a look how we are installing stage-packages, and change that to call snap install instead of apt install.
[17:46] <cholcombe> ok
[17:47] <elopio> that's the gist. The most simple implementation is just that. On debs we do some niceties with caches that would be great to do with snaps, but that can come later.
[17:47] <cholcombe> yeah
[17:48] <mup> PR snapd#2833 opened: many: allow core.refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
[17:48] <cholcombe> yeah i think that gets me out of the jam.  i install the rustup snap for a given architecture and then build as usual
[17:48] <cholcombe> otherwise i'm patching that bash script
[17:53] <EEight> ok last last question: when uploading my snap on myapps.developer.ubuntu.com will it ever be listed in Ubnuntu Software Center (under the Category that I put in the snap.yaml)?
[18:20] <kyrofa> EEight, as long as it is in the stable channel, yes
[18:46] <kyrofa> Hey ogra_ I can't seem to install ubuntu-image from any channel
[18:46] <ogra_> kyrofa, hmm, barry maintains it ... did you try devmode ?
[18:46] <kyrofa> ogra_, "snap not found" for everything. Do you know anything about that? Was it unpublished for some reason?
[18:47] <kyrofa> Wait... it tells me "not found" if I don't use devmode?!
[18:47] <kyrofa> Come on...
[18:47] <ogra_> yeah, thats policy
[18:47] <ogra_> devmode snaps are never listed in find
[18:48] <kyrofa> ogra_, I don't care if they're not listed in find. Non-stable snaps aren't listed either
[18:48] <kyrofa> But if I forgot to pass --devmode, tell me I made a mistake!
[18:48] <ogra_> well, iirc it "is not desired" that find finds anything devmode
[18:49] <kyrofa> ogra_, I'm not finding though... I'm trying to install
[18:49] <ogra_> if it would tell you there is a devmode version that would defeat the purpose
[18:49] <ogra_> well, i think it is the same for install
[18:49] <ogra_> talk to mark or gustavo :)
[18:50] <ogra_> iirc the idea is to discuorage using devmode for actual proted snaps
[18:50] <ogra_> promoted
[18:50] <kyrofa> ogra_, that all makes sense for not showing in find
[18:50] <ogra_> well, but why would install be different here
[18:51] <kyrofa> ogra_, because that implies I know something is there. Particularly when I'm using a non-stable channel
[18:51] <ogra_> well, file a bug and lest see ;)
[18:51] <ogra_> *lets
[18:52] <kyrofa> ogra_, haha, yeah
[18:58] <EEight> patcou01
[18:58] <EEight> it's me
[18:58] <EEight> not a password
[18:58] <EEight> :)
[18:59] <EEight> kyrofa: after how many days will it be listed in ubuntu software center?
[19:00] <kyrofa> EEight, I _think_ as soon as it makes it to stable. If you can find it with `snap find`, I think it'll be in the software center
[19:01] <EEight> I can find it using the search bar in the ubuntu software center & also using snap find, but it's not listed in the Categories (for me Games)
[19:01] <kyrofa> EEight, ahhh, you left that out!
[19:02] <kyrofa> attente, are snaps not sorted into categories in the software center?
[19:03] <EEight> furthermore, i don't like the fact that I need to ask my users to create an ubuntu one account to install my apps... others app in the ubuntu software center (under categories) do not ask this
[19:04] <kyrofa> EEight, I think we all agree with you
[19:04] <kyrofa> EEight, we're working on making that better
[19:04] <kyrofa> EEight, for what it's worth, you can install from the terminal with `sudo snap install <snapname>` with no UO account
[19:06] <EEight> kyrofa: you've been really helpful, thank you. yes i know, but the main idea of deploying to ubuntu was that i would be in the ubuntu software center, simply search in games / kids = install (no terminal, no account)
[19:06] <kyrofa> EEight, of course, understood
[19:08] <kyrofa> EEight, can you please log a bug about the categories against https://bugs.launchpad.net/ubuntu/+source/gnome-software ?
[19:14] <elopio> joc: still here?
[19:14] <joc> elopio: for a few mins
[19:15] <elopio> joc: this PR has the fault, but we need it to support classic: https://github.com/snapcore/snapcraft/pull/1093/files#diff-258c2f9c12b9527559611776a87d8ba5R26
[19:15] <mup> PR snapcraft#1093: python plugin: do the right thing with classic <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1093>
[19:16] <elopio> joc: could you add those RECORD excludes in your snap before leaving? We'll see if we can fix it before the release, and we will see if it affects others.
[19:16] <elopio> but as you are about to leave, maybe better if you leave a workaround just in case :)
[19:19] <joc> elopio: so you would like one of the integration test snaps to trigger the conflict?
[19:23] <elopio> joc: no, I mean to get https://git.launchpad.net/checkbox-snappy back to green, it needs those exclussions.
[19:24] <joc> oh i see
[19:26] <joc> well i might add it to the integration tests anyway so you don't break it in the future ;)
[19:28] <mup> PR snapd#2513 closed: refactor the dialer init code <Created by teknoraver> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2513>
[19:36] <ryebot> Is there any way to transfer a snap in the store to another owner? Alternatively, rename or delete a snap in the store?
[19:55] <kyrofa> ryebot, nessita might be able to help you with that
[19:56] <ryebot> kyrofa: excellent, thank you :)
[20:47] <elopio> matiasb: do you know what the python RECORD files are for?
[20:50] <elopio> nessita: ^
[20:50] <elopio> I need a python expert :(
[21:22] <Cynerva> zyga: apologies if i'm too late getting back to you, are you still available today to help me with permissions on the kubelet snap?
[22:11] <mup> PR snapcraft#1138 opened: python plugin: exclude the RECORD files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1138>