[00:23] Bug #1610025 opened: snapd fails to start after installing snaps [01:28] Hi all. I'm trying to snappify an electron app that I'm a fan of. I'm following the SimpleNote example, but get an error [01:28] ~/.../parts/.../build/wrapper so such file. [01:28] no such file [01:29] my wrapper file is in the $SNAP directory before I run snapcraft [01:30] any suggestions? [01:46] The only difference is that I'm pulling the tar.gz from the internet instead of untarring it locally [01:47] hi === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [03:54] just did a popey and made a script for running snapcraft on a linode server [05:13] hey hey [07:28] zyga: ping [07:33] does someone know how to fix this issue https://travis-ci.org/snapcore/snapd/jobs/149977843 with the spread tests running on linode? [07:33] looks like they broken with the now landed snapd 2.0.11 in xenial [08:14] PR snapd#1638 opened: interfaces: add uefi-manager interface [08:17] ahoneybun: yay [08:19] dholbach: lemme know if/when you get a chance to try my silly script :) [08:22] popey, probably not today :-/ [08:23] I looked at the team option already though and it looks like what we want :) [08:23] well that's good news! [08:43] hi guys [08:44] I would like to ask you something on IoT project development on Ubuntu Snappy [08:44] if someone could answer I appreciate [08:46] I'm a newbie on Ubuntu Snappy, and I have to develop a project using a gateway (where snappy is installed) and sensors connected to it [08:47] which is the best way, the language that I have to use, etc.. ??? [08:48] you can build your software whichever language you are most comfortable using [08:48] snapcraft (the tool to turn your software into a snap) has a lot of different build plugins, so building it should be easy [08:49] http://snapcraft.io has more info about it [08:50] yes, i've read something on snapcraft [08:50] but in this context, I would like to know if I can test the software during the developing [08:51] I mean, my Ubuntu Snappy is installed on a gateway, so I have no GUI [08:51] and I'm not sure if I can install snapcraft on it [08:52] I'm not sure how you would debug or interact with your software - is it a service you can reach over the network? [08:52] or do you mean building it on an ARM machine while you're on x86? [08:52] nop [08:53] yes, something like that [08:53] i have to build it for a different machine [08:53] PR snapd#1639 opened: tests: allow-downgrades on upgrade test to prevent version errors [08:54] I'm not quite sure what the best way to do this is... I'll leave the question for somebody else [08:55] if nobody responds in time, maybe best send an email snapcraft@lists.snapcraft.io and explain your setup [08:55] I'm sure you're not the only one looking for this :) [08:55] thank you guys [08:55] Launchpad supports building snaps on multiple architectures; there are some restrictions on what architectures are generally available, so I don't know if that helps. [08:56] ah, nice one - of course [08:56] * dholbach clearly needs some more mate tea [08:56] Alternatively, you could try running snapcraft inside a $arch KVM, if you can get one running. [08:57] I see [08:57] I haven't actually done either of these things though (as I lead a blessedly amd64 life ;), so I can't promise they'll work for you. :) [08:59] https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way [08:59] lucalar, ^ [09:01] Hmm, update-alternatives not running when you stage-packages is irritating. [09:01] cool, I will give it a look ;) [09:01] Just spent several iterations of snap/upload/install trying to work out why awk wasn't in my path after installing gawk. >.< [09:12] wow, cool...launchpad is very interesting. Thanks a lot dholbach and Odd_Bloke [09:13] PR snapd#1639 closed: tests: allow-downgrades on upgrade test to prevent version errors [09:14] another question, do you know the existance of a Java API to work with sensors on an OS Ubuntu Snappy installed on an architecture amd64? [09:18] I don't, but I'd recommend just using the java api your sensors work with and bundling that in the snap (snapcraft will help you do that) [09:20] Odd_Bloke: hey, did you figure out the browserify step? [09:21] beowulf: I haven't, no. [09:25] Odd_Bloke: let me know what you come up with :) I think using npm's package.json to define that steps pre and post installing some modules via snapcraft's node plugin is worth exploring, but i haven't had time [09:26] beowulf: I don't really know enough about npm/node to really dig in to it; I was hoping it would Just Work (TM). ;) [09:27] Odd_Bloke: let me try something simple and if it works it might help you :) [09:27] Bug #1610149 opened: writing to the "common" directory needs to have sudo right [09:28] beowulf: :) Thanks! [09:28] ogra_, I assume the answer is yes, but.. does your Pi3 core image include drivers for BT and Wifi? [09:28] willcooke, the answer is no currently [09:29] :) [09:29] sorry ... they will land soon [09:29] ogra_, ah :) Glad I asked then. What about wired ethernet? [09:29] (it includes the drivers, but not the additional firmware) [09:29] wired works fine [09:29] perfect, thanks! [09:29] * willcooke ponders netbooting a pi3 in to core [09:30] unlikely to work ... but try it [09:30] will try and carve out some time to play this afternoon [09:31] (the initrd searches for labels on partitions for the whole system setup ... if the label isnt there or the snaps arent in the right place on the labeled partition it will fall flat on its face) [09:31] Ah, I see [09:32] for netbooting we'd need to add some bits to the scriptery [09:33] Not worth it atm I expect. [09:33] well, there was some desire to do netbooting at some point, i thinnk lool worked on that ... though i also think that was via a special system that puts bits into place first [09:34] I have not but I'd like it too :-) [09:35] in Heidelberg we noted it would be a quite desirable thing ot have [09:35] Is this made any easier by the recent Pi annoncement of netbooting? [09:35] nope [09:36] darn [09:36] in all cases you need an SD to boot the pi ... [09:36] since we default to using uboot for booting, a generic solution would kick in on that level, not in the first stage bootloader [09:37] i.e. you would have an SD with the binary blob plus the uboot binary and config [09:37] (in general the pi isnt realyl a great target given you will always need an SD due to a missing eMMC boot) [09:38] yeah [09:38] (if you need an SD anyway, you could as well do a local boot) [09:38] only use case for netbooting I have is that SD cards don't like getting hot, so industrial applications might want to boot from SD card and load everything else over the network [09:39] plus, people like me who like to play [09:39] well, it is definitely a valid target ... (i guess also for cloud stuff) [09:41] This confuses me: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md [09:42] It says that the boot ROM is "One Time Programmable" [09:42] and then it talks about setting bits in there [09:43] But does suggest that it might be possible to boot without an SD card [09:44] ah, well, try it if you like [09:45] I'll see what I can get working, and then bother you about it next time we meet [09:58] willcooke: prompted by your remark about netbooting, I landed on the exact same page and I have been diving into it; seems quite useful [09:58] willcooke: the OTP seems indeed to be write once; my understanding is that the firmware supports USB netboot and USB mass storage, but that's disabled by default because potentially buggy or unsecure [09:58] so we flip a bit once to enable it forever [09:58] can't disable it [09:59] Hmm https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md says if you remove it it's turned off [10:00] lool, I think there are a few typos in those docs. [10:00] can't find much about this flash except that it holds a bunch of device specific stuff like serial [10:02] https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md [10:03] http://www.elinux.org/RPI_vcgencmd_usage is where I found the info on the otp contents === hikiko is now known as hikiko|ln [10:06] willcooke: ah well the net tutorial page is consistent with the hardware behavior I suspect: program_usb_boot_mode=1 is only needed to be present once, and then it's enabled forever [10:06] lool, this page talks about getting involved in the beta of netbooting: https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/README.md [10:06] Bug #1591664 changed: 'snap install' should support --beta, --candidate and --edge options [10:06] lool, @ program_usb_boot_mode - yeah, I think so too [10:07] https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/bootflow.md is pretty nice [10:08] * willcooke reads [10:09] willcooke: if I read the bottom correctly ("By default the USB device boot mode is enabled at manufacture time [...]"), once you switch to netboot you can't ever go back to device mode [10:09] erk [10:10] maybe you can change that with pulling the GPIOs up? [10:10] or down [10:10] or with pliers and a soldering iron :P [10:10] :) [10:18] Bug #1602154 changed: "snap find" command cannot find ubuntu-calculator-app. However, it can be installed on 16.04 [10:21] Bug #1605471 changed: Cannot refresh a devmode snap [10:24] Bug #1606100 changed: "snap revert" command cannot be found [10:36] Bug #1607717 changed: no snaps installed error [10:37] Odd_Bloke: so, the nodejs plugin would probably need a few changes to make my suggestion work :( [10:39] Bug #1590704 changed: "snap interfaces" command doesn't filter by snap === hikiko|ln is now known as hikiko === LarreaMikel1 is now known as LarreaMikel === vrruiz_ is now known as rvr [11:34] on a minor note on http://snapcraft.io/create/ "... the two highlighted files ...", but there is only one highlighted - prime/command-hello-service.wrapper should be bold as well I think [11:42] link https://myapps.developer.ubuntu.com/dev/click-apps/register-name-dispute/ as referred by http://snapcraft.io/create/ is broken as well [11:43] Bug #1610211 opened: Interface to manage block devices === LarreaMikel1 is now known as LarreaMikel === JanC is now known as Guest20161 === JanC_ is now known as JanC [12:16] popey, didrocks: i am currently getting this exact error http://askubuntu.com/q/787258/12435 [12:17] even to the extent that one day later the error changed from failing on the package lists to the deb files [12:17] erk [12:18] i have no idea what I did to fix it [12:18] I think I nuked my lxd config and started again [12:18] i started with a fresh lxd config [12:18] I guess the issue is Err:5 http://archive.ubuntu.com/ubuntu xenial-updates/main Translation-en [12:18] 500 Internal Server Error [12:18] oh, also, I had an apt-cacher-ng which I removed [12:18] installed it yesterday for this purpose [12:18] oh [12:18] it can't update that repo [12:18] no cachers here [12:18] ok [12:18] actually [12:19] yesterday it failed on a en translation file [12:19] today it didn't even try to download that [12:19] http://paste.ubuntu.com/22306053/ is today's error [12:20] didrocks: yes, yesterday that was the error. today the error is different ^ [12:20] i have changed nothing on my end. just gave up yesterday and went to bed... [12:20] weird, and no issue from your host at all? [12:20] apt works fine on the host afaik [12:21] maybe ask stgraber if there is some lxd cache? [12:50] PR snapd#1640 opened: tests: add gsettings interface spread test [13:21] PR snapd#1628 closed: store: refactor newRequest/doRequest to take requestOptions [13:23] kyrofa: hey, now for me to ask you a couple questions :) 1) if I run 'snapcraft' which directory is mksquashfs run on? 2) Let's suppose that I stage-packages and all the debs are unpacked but I want to add/tweak something that was unpacked. is it possible to insert a command at sometime after unpack but before mksquash? [13:42] niemeyer: are you looking at https://github.com/snapcore/snapd/pull/1432 today? jhodapp is waiting already for some days [13:42] PR snapd#1432: interfaces/builtin: improve pulseaudio interface [13:42] morphis: I've been actively going through the queue in the last few days.. will get to it [13:43] aye [13:43] thanks niemeyer [13:45] jhodapp: np, sorry for the delay.. it's obviously been a little hectic after the sprints [13:46] niemeyer, yeah understood [13:47] niemeyer, this PR has been reviewed many times, so it should just be ready to go...an easy merge [13:51] jhodapp: Yeah, this is an epic branch [13:51] jhodapp: What is that line 217 on manual-tests.md? [13:52] niemeyer, that shouldn't be there...slipped through in my conflict resolution [13:52] PR snapd#1641 opened: interfaces: implement systemd-control [13:52] niemeyer, let me get rid of that quickly [13:53] jhodapp: Can you please also take this chance to fix the tab indentation on the yaml snippets? [13:53] jhodapp: It's being improperly tagged red there for good reasons.. yaml can't take tabs [13:53] (not your fault) [13:53] jhodapp: 4 spaces on all of them please [13:53] I mean, four spaces indents [13:53] niemeyer, I can change it but those tabs are not from me [13:54] oh you said that [13:54] jhodapp: You've marked it as yaml in the branch, though (correctly) [13:54] sure I can fix that [13:54] it was bugging me too [13:55] jhodapp: Thanks, the indentation is also pretty broken in that one snippet you touched at least.. it has 8 spaces and 4 spaces, interchangeably [13:55] and then next one has 2 spaces.. indentation party [13:58] niemeyer, fixed that section [14:01] jhodapp: Why were the consts changed to vars on all snippets? [14:02] niemeyer, at least pulseaudioConnectedPlugAppArmor is modified in the code later [14:03] jdstrand: ok, i'm getting a seccomp denial for sendto and it's clearly in my connectedplug snippet [14:03] jhodapp: It's actually not, I think [14:05] kgunn: is it in the resulting policy in /var/lib/snapd/seccomp/snap.your.thing.that.is.failing [14:07] niemeyer, oh you're right it isn't...sorry brand new to Go [14:07] niemeyer, so am I able to just slap "const" back on the front of those? === Tristit1a is now known as Tristitia [14:07] even as byte slices [14:10] jhodapp: No, unfortunately not.. you'll need to move them back to being strings, and use []byte in place [14:11] jhodapp: I'd prefer that in general, as a guideline.. it means those strings are in unchangeable memory, and won't be mutated behind our back [14:11] jhodapp: A bit of paranoia, arguably, but not too crazy given the context [14:11] niemeyer, using []byte in place is a cast, yes? [14:11] jhodapp: Type conversion, not a cast [14:11] jhodapp: Cast means something else if we're pedantic enough [14:12] niemeyer, so it's not the same thing as in C/C++ [14:12] jhodapp: No, it's not.. in those languages you can actually tell the compiler you want to look at that memory under different eyes, whethere that's correct or not [14:13] jhodapp: That's casting [14:13] niemeyer, yeah ok, so this is safer [14:14] jhodapp: On b := []byte(s) you're allocating new memory, copying data over, and converting the type.. [14:14] yeah === matiasb1 is now known as matiasb [14:20] Hey jdstrand!Sorry, I had to switch work locations [14:20] jdstrand, (1) snapcraft (which defaults to snapcraft snap) runs mksquashfs on the prime/ directory [14:22] PR snapd#1642 opened: many: pass device to store [14:23] jdstrand, (2) not by utilizing the default plugins, but you have a few options. You can either write your own plugin that does stuff right after the pull step, or write a Makefile that does stuff in the all: rule (which is run during build, right after pull [14:25] jdstrand, you can ship a local plugin alongside the snapcraft.yaml [14:25] niemeyer, fixed [14:27] jdstrand: This is an interesting point to keep an eye on for future reviews.. the snippets should ideally live as consts rather than var []byte [14:28] kyrofa, ping [14:31] liuxg, pong [14:32] kyrofa, if I want to write to the common directory, do I need to have the root previlege? thanks [14:33] liuxg, there are two common directories: SNAP_COMMON and SNAP_USER_COMMON. Yes, SNAP_COMMON (like SNAP_DATA) is owned by root [14:33] niemeyer: noted [14:34] SNAP_USER_COMMON though is owned by the user. Note however that it's not currently usable as nothing creates it. niemeyer, speaking of that, did you see the email thread about that? [14:34] jhodapp: Just waiting for it to go green [14:34] niemeyer, cool [14:34] kyrofa, I mean the directory SNAP_COMMON [14:34] kyrofa: Nope [14:34] liuxg, then yes [14:34] kyrofa: great, thanks! [14:34] jdstrand, let me know what path you decide to follow and I can give you a few more hints [14:35] kyrofa, do you mean it needs have the root previlege? it is like /home//snap/hello/common [14:35] liuxg, that's SNAP_USER_COMMON [14:35] liuxg, SNAP_COMMON is in /var/snap//common [14:35] But yes [14:36] kyrofa: My vague memories are that with snap run creating that directory becomes trivial [14:36] kyrofa: Not sure what changed since we last discussed this, though [14:37] niemeyer, indeed, that's true. But snap run is taking a while to land and people are starting to get confused by the behavior of not creating them [14:37] kyrofa, right. so, the one SNAP_USER_COMMON a user right is fine, right? [14:37] niemeyer, will that land soon you think? Or should we add that logic back to snap-confine? [14:37] liuxg, right [14:38] kyrofa, thanks for your clarification. By the way, I have shared you a document about core, would you please help to review it, thanks. [14:38] * kgunn has more fun with network [14:38] kgunn, I share your pain [14:38] liuxg, sure! [14:38] jdstrand: sorry had to re-run and yes it is listed in /var/lib/snapd/seccomp/profiles/snap.mir-client.client-start [14:39] the denial signature in syslog appears as [14:39] Aug 5 14:34:56 localhost kernel: [ 267.421706] audit: type=1326 audit(1470407696.839:12): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1383 comm="clocks" exe="/snap/mir-client/x1/clocks" sig=31 arch=c000003e syscall=44 compat=0 ip=0x7fcdea268b7f code=0x0 [14:39] kyrofa: The only blocker for snap run is snap-confine, which I believe is now about to be in updates [14:39] kyrofa, by the way, another developer yesterday met a same problem, and he confirmed it.. https://bugs.launchpad.net/snapcraft/+bug/1601834 [14:39] Bug #1601834: Error "[Errno 21] Is a directory" when building a snap package for a qmake project [14:40] kyrofa: So *maybe* next week [14:43] niemeyer, ah, good deal. Okay, we'll just live with it then [14:43] kgunn: is clocks running under snap.mir-client.client-start? [14:43] kgunn: and it this on amd64? [14:44] kyrofa: Did I miss something else in that conversation? [14:45] niemeyer, no, people seemed to think snap run was already used. I tried to clarify, but asked you and mvo about timeline. It would be great if you could quickly respond just to close the thread, if you have a minute [14:50] what's snap run? test the current snap without installing it? [14:51] kyrofa: Where's the thread? [14:51] PR snapd#1643 opened: many: support interactive payments in snapd, filter from command line [14:51] ali1234: Any app may be run via "snap run snap[.app]" [14:52] ali1234: Instead of /snap/bin/snap[.app] [14:52] oh right, i was thinking of "snapcraft run" [14:52] ali1234: The latter will become just a symlink to /usr/bin/snap [14:53] ali1234: So it's a much nicer pipeline for how things get executed [14:53] Bug #1610149 changed: writing to the "common" directory needs to have sudo right [14:53] yeah, i see. i was thinking of something else entirely [14:53] ali1234: It's coming for a while, but there were several moving parts, so it took a while to get to this point [14:54] * ogra_ grumbles about not being able to use sidloaded kernel snaps anymore with latest u-d-f [14:57] PR snapd#1625 closed: asserts: make account-key's `until` optional to represent a never-expiring key [15:07] niemeyer, looks like CI completed successfully [15:12] jdstrand: sorry, network killing me....not sure if you saw i do have sendto in the seccomp profile for the client [15:13] kgunn: is clocks running under snap.mir-client.client-start? [15:13] kgunn: and it this on amd64? [15:13] is* [15:16] jdstrand: yes, this is on amd64 and clocks is the exe launched by client-start [15:16] http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/client-start [15:17] kgunn: and you are 100% sure that sendto is listed in /var/lib/snapd/seccomp/snap.mir-client.client-start ? [15:18] kgunn: grep sendto /var/lib/snapd/seccomp/snap.mir-client.client-start [15:19] kgunn: and you are seeing the denial by launching mir-client.client-start ? [15:19] jdstrand: it is literally on line 469 of /var/lib/snapd/seccomp/profiles/snap.mir-client.client-start [15:19] kgunn: is the interface connected? [15:19] jdstrand: the interface is connected manunally [15:19] meh, if it is in there it should be [15:20] jdstrand: so i put a sleep at the top of client-start, then manually connect [15:21] kgunn: can you tail -f /var/log/syslog in one terminal, then sudo systemctl stop your.unit ; sudo systemctl start your.unit [15:21] kgunn: then tell me if you see a new denial in syslog? [15:22] jdstrand: sure will try [15:28] jdstrand: when i call sysctl on snap.mir-client.client-start.service [15:28] it fails with [15:28] Failed to stop snap.mir-client.client-start.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files [15:28] See system logs and 'systemctl status snap.mir-client.client-start.service' for details. [15:30] niemeyer, are you still around? [15:36] hmm I have two snaps that must communicate through unix socket [15:36] where do I put the socket ? [15:36] in /tmp one won't be able to open it [15:37] in home, the home interface isn't autoplug I think ... [15:44] (and I guess I won't be in devmode since I install the snap through webdm) [15:45] kgunn: did you run that with sudo? [15:45] jdstrand: i can try [15:45] so what's the way to communicate between two snaps via unix socket without devmode ? [15:46] kgunn: basically, I don't understand how the sendto denial is being logged. it shouldn't be. I think it is either an old denial or it happens on install before the connection. I'd like to see confirm that a sudo sysctemctl stop ... followed by start triggers it [15:46] kgunn: if it wasn't working, there would be people screaming left and right about it being broken... [15:50] ysionneau: I would recommend using SNAP_DATA if both are running as root, until we get a better answer from jdstrand or niemeyer :) [15:52] hmmm i'm running as root yes [15:52] but I guess one snap does not have access to another snap's SNAP_DATA, right ? [15:52] ah, it's 2 snaps, sorry, I read 2 apps [15:53] so, yeah, question for jdstrand & niemeyer in that case (maybe ask on the ML so that they can catch up later on?) [15:54] I have lool helping me out in fact at the moment :) [15:54] thanks ! [15:55] lool: ysionneau: do you mind keep us posted on the ML? That would be interesting to quite a lot of people I think [15:55] didrocks: at the moment it's a bit hackish with a devmode snap [15:55] didrocks: the docker snap is a good example of how to do this properly, but it requires landing an interface in snapd [15:55] didrocks: https://github.com/snapcore/snapd/pull/1619/files has the interface [15:55] PR snapd#1619: Add initial "docker" interface based on some of 15.04's privileges [15:55] you can see it gives access to /run/docker.sock [15:56] lool: hard for 3rd party apps to land an interface for their specific socket though… [15:56] yep I would prefer to not have to modify snapd, for now at least, even if it's a bit hackish like reusing some interface [15:56] didrocks: well it's the otherway around here [15:57] didrocks: they have a first (devmode) snap with a socket somewhere, and another snap (confined) accessing it, I'm not sure which dir is accessible by default to all snaps though, checking default policy [15:57] yes it would be for out autopilot, that Parrot should land an interface to allow 3rd party apps to connect to our unix ocket [15:57] socket* [15:57] ysionneau: BTW I wanted to tell you about shm [15:57] ah! [15:57] ysionneau: not sure if you saw the exchange on the ML, but shm is open by default with snap.XXX prefix [15:57] ysionneau: https://lists.ubuntu.com/archives/snapcraft/2016-August/000611.html [15:58] /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix, [15:58] !! [15:58] ah this is for shm, ok thanks! [16:00] ysionneau: damn, I'm out of time, but I think this is the default policy: https://github.com/snapcore/snap-confine/blob/master/debian/usr.bin.snap-confine [16:00] ysionneau: I have to run to a meeting, perhaps you'll find a dir in there [16:01] ah no I still have :30 [16:02] I have updated my fw btw [16:02] I'm using ubuntu-core_148.snap [16:03] usr.bin.ubuntu-core-launcher -> usr.lib.snapd.snap-confine [16:03] I'm not very fluent in apparmor profiles though, where to look for "unix socket rights"? [16:04] jdstrand: sorry otp, but sudo systemctl stop/start worked...and now i get a different denial so that's good [16:04] does not seem to be any unix socket stuff related in the default profile :/ [16:04] ysionneau: I think it's just about read on the socket [16:04] ysionneau: to do open() [16:05] hmmm no special rights for connect listen bind send recv sendmsg ? [16:06] hmm maybe I can use the shm related exception ? [16:06] I think you get these from network [16:06] which is autopluggable [16:06] ysionneau: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network.go [16:06] ysionneau: so [16:06] ysionneau: just say plugs: [network] [16:07] I already have it === davidcalle is now known as davidcalle|afk [16:11] hey snappy peeps! I'm looking at the snapcraft-daily ppa and it looks like it hasn't been built in a week [16:11] i need the latest so i can try out the rust plugin [16:12] lool: question is, where do I put it (the socket :p) [16:12] ysionneau: ah I was wrong, the default perms are in https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template.go [16:13] thx [16:13] ysionneau: unfortunately the 3 rw locations seem to be /tmp which is diverted to a per snap tmp, shm, and ptmx [16:13] ysionneau: is this a rw socket you need? [16:14] hmmm [16:14] well you'll need to send messages I guess [16:14] yes [16:14] send and receive [16:14] both sides are going to send/recv [16:15] ysionneau: so I guess your best bet is to use a snap specific location, but avoiding the version; perhaps /snap//common/foo.socket [16:15] that way the confined snap has rw access [16:15]