[00:53] PR snapcraft#1132 opened: Revert "qbs plugin: add plugin support for the Qt Build Suite (#1079)" [01:41] how would i go about moving the snap dir out of my home dir? [02:11] PR snapcraft#1120 closed: Update rustup link. Bug: 1662960 === markusfluer1 is now known as markusfluer [03:03] zyga: ping [03:24] zyga: I found out how to make the selinux policy domain "permissive" [03:24] so now it won't completely shut down snapd when it violates policy [03:25] https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/4566045b2d4ab6d72cc8991814753997a53f6377 [03:33] anyway, "snap run hello" works in enforcing mode now [03:33] the AVC denials are still made, but the thing doesn't break [03:34] zyga: now, you need to update snapd to the latest version and refresh all the patches for snap-confine and snapd [03:34] and we're *finally* pushing this out to F24+ [03:35] and we need to retire snap-confine and obsolete it with a snap-confine provided by snapd source package [03:36] zyga: when I wake up tomorrow morning, I hope to see all of this done ;) [06:26] PR snapcraft#1133 opened: tests: fix the test that was modifying the environment variables [06:40] PR snapd#2819 closed: packaging/ubuntu-14.04: inform user how to extend PATH with /snap/bin === chihchun_afk is now known as chihchun [07:27] Son_Goku: \o/ [07:28] Son_Goku: I'm going to the doctor now, I'll check back later [07:28] Son_Goku: let's try to roll out the package if we can this weekend [08:12] 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] pstolowski: any idea what the message is about? [08:14] 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] pstolowski: no, just snapctl :-) Let me have a look at the file... [08:16] mardy, this auth file is owned by regular user and permissions are 0600 here on my box [08:16] pstolowski: it's -rw------- for mardy.mardy (my user) [08:17] mardy, yeah, that's fine. does journalctl shows anything interesting? [08:19] pstolowski: a few denials, let me paste them... [08:20] pstolowski: http://paste.ubuntu.com/23965752/ [08:22] 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] mardy, but that doesn't cause any issues [08:23] mardy, can you push all your changes to that branch you gave me earlier? [08:23] pstolowski: yup [08:24] pstolowski: all pushed to lp:~mardy/webapps-core/iface-hook-test [08:24] pstolowski: let me also push my snapd branch, where I've added the online-accounts interface... [08:26] pstolowski: this is my snapd branch: https://github.com/mardy/snapd/tree/hook-test [08:26] ok [08:26] pstolowski: it's snapd master from today, + your branch, + the OA interface [08:29] mardy, and what do you do to trigger that error? [08:33] 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] 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] mardy, also.. do you have encrypted home? [08:36] pstolowski: the error is triggered when I connect the interface [08:36] pstolowski: no encrypted home here [08:36] mardy, do normal store ops (installing snaps from store) work? [08:57] 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] PR otfried/ipe-tools#24: Upgrade snap to version 7.2.7 [08:58] 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] PR snapd#2828 opened: tests: increase service retries [09:29] PR snapcraft#1129 closed: 96boards: fix the dragonboard example [09:56] re [10:17] pstolowski: sorry, somehow missed your pings :-) [10:17] pstolowski: yes, I can install snaps from the store (just installed the snappy-debug one) [10:17] pstolowski: I see it immediately [10:18] pstolowski: I presume it's part of the stderr of snapctl, but that's only my guess [10:23] mardy: you are on classic, right? not on an ubuntu-core only system? what is the output of snap version? [10:23] mardy, doesnt that happen only if interface hooks are in use? do you see it with other connect? [10:24] mvo, fyi, he is plying with my hooks branch, and they are using snapctl [10:24] mvo: classic, zesty [10:24] pstolowski: let me try to remote the call to snapctl [10:24] mardy: and snapctl gives you this error? [10:28] 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] pstolowski: ^ [10:29] 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] mardy, ok, so we've been discussing it via telegram, apparently this was fixed ~week ago; are you up-to-date? [10:35] mvo, pstolowski: right, I only rebuilt snapd, not snapctl; let me try... [10:38] 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] mardy: https://github.com/snapcore/snapd/pull/2756 [10:40] PR snapd#2756: snapctl: add config in client to disable auth and use it in snapctl [10:40] mardy: thinking about this, I think you get the snapctl from the core snap. please try "sudo snap refresh core --edge" [10:41] mardy: that should give you the latest up-to-date snapctl [10:42] 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] mvo: mmm... updated, but I still get the same error [10:45] mardy: hrm, what do you see with "snap version"? [10:45] PR snapd#2829 opened: tests: add libvirt interface spread test [10:47] snap 2.22+17.04 [10:47] snapd unknown [10:47] series 16 [10:47] ubuntu 17.04 [10:47] mvo: ^ === chihchun is now known as chihchun_afk [10:57] 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] mardy: or instead of /usr/bin/snapctl your own build of it [10:59] mvo: mmm... still the same [10:59] mvo: I'll now try with my own build [11:00] snapd unknown ? [11:00] pedronis: I think he is running from a build dir [11:01] mvo: oh, if I bind-mount the one I've built, then it works [11:02] mvo: doesn't that then use the one outside [11:02] mardy: yay [11:02] mvo: maybe the fix did not land to the core snap yet? [11:02] mvo, pstolowski: anyway, thanks a lot! Now I've something to work on :-) [11:02] mardy: I will check that, it should be but obviously there is a disconnect between theory and reality [11:03] mvo, thanks for looking at that! [11:08] PR snapd#2236 closed: interfaces: add realsense interface [11:15] mvo, morning! [11:15] hey Son_Goku [11:15] how are you? :) [11:16] Son_Goku: good, thank you! how are you? [11:16] a bit groggy, but otherwise fine [11:17] Son_Goku: ha! I share that feeling, I need a cup of tea :) [11:17] hehe [11:17] I'm pleased that we'll *finally* be able to release snapd into Fedora, though [11:17] 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] and unfortunately, none of the patches can be upstreamed :( [11:18] Son_Goku: hey [11:18] Son_Goku: I can help [11:19] I mean, you're going to have to do it :/ [11:19] we're so far behind [11:19] Son_Goku: meh, that is sad. at the same time, super exciting that it can go in now [11:19] 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] you *can* use setuid [11:19] it's just not preferred [11:19] Son_Goku: oh, in that case one issue less off the table [11:19] file a bug about the cap issue against snapd and we'll switch back once it's fixed [11:20] Son_Goku: I think we can figure out the caps but I don't want it to block the release [11:20] Son_Goku: yes, I filed it... [11:20] https://bugs.launchpad.net/snapd/+bug/1657099 [11:20] Bug #1657099: snap-confine cannot perform namespace capture even with CAP_SYS_ADMIN [11:20] that's the issue [11:21] Son_Goku: btw, did you try to refresh the package to 2.22? [11:21] not yet [11:22] I just figured out the selinux policy thing before going to sleep [11:22] Son_Goku: that's great news, my fedora box is so lonely without snaps :/ [11:22] Son_Goku: I found a way to run snaps with classic confinement on fedora [11:22] Son_Goku: I didn't code the patch yet but I will as soon as I'm done with content [11:22] so, it's not a real solution, but it means that AVC denials won't block snapd [11:22] Son_Goku: let's do that, we can iterate on the policy [11:23] Son_Goku: but not without being able to use it at the same time [11:23] that's the point of it :) [11:23] PR snapcraft#1135 opened: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs [11:23] we should have done it in the beginning, but I didn't know about it [11:23] Son_Goku: I've been fixing some issues in the content interface but this is dragging on due to extra complexity [11:23] and no one told me [11:23] I stumbled on it, and realized it resolved our problem [11:25] I also have some bad-ish news for you regarding openSUSE packaging [11:25] Son_Goku: yes? [11:25] they've completely changed how Golang packaging is done [11:25] !!! [11:25] do you have a reference? [11:25] whoo boy do I have one [11:25] and what did they decide upon? [11:26] https://github.com/openSUSE/golang-packaging/pull/5 [11:26] PR openSUSE/golang-packaging#5: fix for SLE11SP3 [11:26] they're now doing the same thing Fedora does [11:26] source code only libraries [11:27] basically, the Docker team and the creator of golang packaging didn't get along [11:27] so the golang packaging creator was forced out, and now openSUSE packaging is closer to Fedora than before [11:27] Son_Goku: oh boy [11:27] Son_Goku: some heavy words fly there [11:27] yeah [11:28] and of course, it's all still undocumented :( [11:28] Son_Goku: after content I should be able to do a deep dive [11:29] Son_Goku: with debian in good hands (CI will be working on Debian soon, I heard) [11:29] bah [11:29] Son_Goku: I plan to split my focus 50/50 on Fedora and Suse [11:29] Son_Goku: and after Fedora is operational see if we can build for derivatives and CentOS [11:29] the only obstacle for RHEL and friends is the go compiler [11:29] if it builds, we're gravy [11:30] golang libraries will need to be refreshed too... [11:30] 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] I'm not sure how available I will be this weekend [11:31] Son_Goku: I didn't follow the drama/discussion closely [11:32] I'm going to be at a hackathon on behalf of my company [11:32] Son_Goku: but I guess I just have to see how it looks like now [11:32] Son_Goku: woot, nice :) [11:32] Son_Goku: maybe next week then [11:32] PR snapcraft#1136 opened: kernel plugin: if kernel's target == NULL, use per-arch default target [11:32] zyga: my bit is done :) [11:32] you've got to refresh snapd.spec and patches up to 2.22 [11:33] and move snap-confine into being a subpackage of snapd [11:35] Son_Goku: thank you!! [11:35] Son_Goku: I'll see if I can get it to all work tonight [11:35] Bug #1663565 opened: Media Keys do not work in strictly confined snaps [11:35] Son_Goku: I'm really happy to see progress in this front [11:36] Son_Goku: btw, what about Mageia? [11:36] keep in mind that you'll need to have snap-confine subpackage "Obsoletes: snap-confine < 1.0.44-3" [11:36] Son_Goku: ok, will do [11:37] as for Mageia, since there's be zero progress on AppArmor upstreaming, it still doesn't work with stock AppArmor :( [11:37] s/be/been/ [11:37] so no confinement [11:37] but I can probably get it going derived from the Fedora packages as soon as you've made them and published them [11:38] Son_Goku: there's a lot of progress, look at's what in mainline now [11:38] Son_Goku: it's not all there but a good chunk did land [11:39] 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] Son_Goku: they are all going up [11:39] anyway, it doesn't matter that much since Mageia has no MAC enablement right now [11:39] that'll have to wait for Mageia 7 [11:39] Son_Goku: can packaging from Fedora be used on Mageia? [11:39] yes [11:39] Son_Goku: sounds good [11:39] we follow the same rules as Fedora [11:41] zyga: also /writable will need to be moved, if that's still a thing [11:41] Son_Goku: /writable only exists on core systems [11:41] can it be moved? [11:42] Son_Goku: are you talking about making a all-snap image with mageia base? [11:42] Son_Goku: /writable doesn't show up anywhere on the filesystem [11:42] potentially, yes [11:42] Son_Goku: for a core system it is required and I can explain why [11:42] okay.. [11:42] Son_Goku: it could be "moved" but there's little reason to IMHO (but we can explore that later) [11:43] it's not something we'll deal with right now [11:43] I can't make an all-snap system until snapd and snapcraft remove their ubuntu assumptions anyway [11:51] Son_Goku: ogra keeps thinking about buildroot-based base snap [11:52] bah [11:52] Son_Goku: I think we're getting closer to base snaps, maybe around spring? [11:52] zyga, well, we have better tools in the distro actually :) [11:52] Son_Goku: the idea is that a totally separate base opens up a way to experiment [11:52] I've already made tooling for producing such base snaps :) [11:52] i think i'd actually use copy_exec() from initramfs-tools with a file list fed into it [11:53] oh, man [11:53] please don't tell me we can't use dracut?! [11:53] and that Ubuntu Core still doesn't use dracut [11:54] Debian has stated their intent to retire initramfs-tools for years [12:02] 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] :( [12:03] if Ubuntu Core is the Ubuntu of the future, it should be using dracut :/ [12:03] but the above has nothing to do with either ... i just want to use a function from the tools :) [12:04] 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] while buildroot is nice and all i think we should not stop using ubuntu binaries for creating core [12:06] ogra_: well, you can guess what my opinion is :P [12:06] 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] the current design doesnt allow that since we use a build tool that completely relies in dpkg [12:08] s/in/on [12:33] Bug #1663220 changed: Add support to Secret Service APIs [12:57] PR snapd#2723 closed: tests/main: add test case to verify core snap conf option service.ssh.disabled [13:18] sborovkov: hey, gyi, I'm off today so at best 'in and out' (but mostly out :) [13:19] 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] sborovkov: your slot looks fine. you need your plugs to also specify 'name: com.screenly' [13:20] sborovkov: also, if you want to rename your slot, you can use: [13:20] slots: [13:20] something: [13:20] interface: dbus [13:20] name: com.screenly [13:20] bus: system [13:20] then your plugs is fine: [13:20] plugs: [13:21] somethingelse: [13:21] interface: dbus [13:21] name: com.screenly [13:21] bus: system [13:25] jdstrand: o/ [13:25] 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] sborovkov: see https://git.launchpad.net/~jdstrand/+git/test-hello-dbus/tree/snapcraft.yaml as an example [13:25] zyga: hey, not sure you saw, but I'm off today [13:26] sborovkov: good luck! there are others here who can help you if I don't see your followup questions :) [13:26] jdstrand: oh, I didn't remember; I'm just saying hi :) [13:26] zyga: heh, ok, hi! [13:26] jdstrand: nothing to do today :) [13:27] zyga: I think you've conditioned me to expect a code review when you wave at me :P [13:27] jdstrand: thanks :) [13:27] jdstrand: I'm sorry; I should give you a hug and beer sometimes :) [13:27] jdstrand: nothing to review :) [13:28] zyga: it's fine! :) [13:44] 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] PR snapcraft#1137 opened: Build-depend on git [14:14] PR snapd#2830 opened: allow core_support interface to modify /etc/default/swapfile [14:24] Bug #1663615 opened: snap broken out of the box on 16.04.1 [14:44] PR snapd#2831 opened: interfaces: add missing recvfrom syscall to dbus interface [14:46] Bug #1663303 changed: Running snapcraft on Ubuntu 14.04 fails with a traceback [14:48] slangasek: more like a feature that only works on xenial [15:01] PR snapd#2832 opened: interfaces/builtin: add network-setup-control which allows rw access to netplan [15:22] question for anyone [15:23] if you have a daemon that requires plug foo to be connected in order to work [15:23] PR snapcraft#1131 closed: lifecycle: hardcode test_core_snap's PATH [15:23] is there a way to tell snapd to start the daemon only when that plug has been connected? [15:24] ara, unfortunately no [15:25] ara, snapd has no way of knowing that the plug in question is actually required or optional [15:25] kyrofa, OK, thanks for confirming [15:25] ara, e.g. if you managed to write your service such that the plug only extended its functionality [15:26] ara, this is somewhat difficult without seccomp returning ERRNO, but it'll get easier soon [15:29] PR snapcraft#1133 closed: tests: fix the test that was modifying the environment variables [15:51] elopio: hey, i got odd failures in tests after updating my PR again [15:53] zyga: hey, are you around? I was able to connect 2 content interfaces which have different "content:" name [15:55] didrocks, my gift to you: https://lists.ubuntu.com/archives/snapcraft/2016-December/002189.html [15:56] kyrofa: thx! I didn't remember your email :p [15:57] didrocks, haha, no problem [15:57] should I always see the browser-support interface now, for example on pi2? (I don't: snapd version 2.21) [15:57] KDE neon to officially support snaps? nice. http://www.omgubuntu.co.uk/2017/02/kde-neon-intergrating-snap-apps [15:59] kyrofa, Tony asked on the list but is there a launchpad bug about it? [16:00] 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] :-/ [16:01] kyrofa, should I always see the browser-support interface now, for example on pi2? (I don't: snapd version 2.21) [16:01] kyleN, I thought so, but I'm not 100% sure. It's provided by the core snap [16:02] kyleN, once ogra_ is off of his call he can help [16:02] 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] didrocks: on a call [16:02] ok [16:03] zyga: no worry, kyrofa answered. A bug in content interface that you told "known" ;) === JanC_ is now known as JanC [16:22] kyrofa, ogra_: on browser-support interface not visible, I reported https://bugs.launchpad.net/snapd/+bug/1663656 [16:22] Bug #1663656: browser-support interface not reported [16:22] kyleN, not sure thats actualyl a core interface ... jdstrand would know [16:23] i think it is tied somehow to unity7/x11 [16:23] kyrofa, ok. looking for pointers & info here to help a client. [16:23] (which we do not have on the core images) [16:25] 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] 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] ogra_, ok [17:06] if I want access to a webcam, what should I put in the snap.yaml??? [17:09] https://snapcraft.io/docs/reference/interfaces [17:09] EEight: https://snapcraft.io/docs/reference/interfaces [17:09] camera [17:09] 1 second faster :D [17:09] blast, I never thought I'd take precisely as long to reply [17:10] This is defined in plugs: right? [17:11] yes [17:11] https://snapcraft.io/docs/snaps/metadata [17:14] is it / will it be possible for an user to restrict snap permissions? [17:15] thinking twice about it, this is a silly question; since it's always possible to re-package the snap, right? :p [17:15] brunch875, can you be more specific? [17:15] brunch875, no such thing as silly questions! [17:17] 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] brunch875, oh certainly, one of my favorite features [17:19] brunch875, assuming you have any snaps installed, run `snap interfaces` [17:19] any IRC snap I can fetch? [17:20] oh, I could try telegram [17:20] brunch875, yeah that'll work [17:20] theer should be a hexchat snap too [17:20] even from the upstream guys afaik [17:21] brunch875, anyway, once you do that, you'll see a list of "slots" on the left and "plugs" on the right [17:22] brunch875, snaps are confined by using these (they're called interfaces). Plugs plug into slots [17:22] brunch875, so if an app "plugs into" the camera interface, you can simply use `snap disconnect` to break that connection [17:22] brunch875, which means it no longer has permission to access the camera [17:22] nice! [17:22] * brunch875 applauds [17:23] 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] brunch875, ideally the app would just run and say "Ah, can't access the camera, no matter." [17:23] last question, is it true that a snap gets refresh automagically after 24h? [17:24] and yet applications without exception handling will just [rude remark] themselves [17:24] EEight, four times a day, randomly distributed [17:24] brunch875, heh [17:25] this design could allow for fake slots [17:26] brunch875, what would that be, technically? [17:26] well, I was thinking of a fake camera device which was just a video on loop [17:27] so the snapped application could be fooled to believe it was accessing the camera when it was not [17:28]