[00:07] PR snapd#2037 opened: asserts,interfaces/builtin,overlord/assertstate: introduce base-declaration [01:02] PR snapd#2038 opened: many: add email to UserState [01:07] uh [04:10] PR snapcraft#843 opened: Add `snapcraft history` and `snapcraft status` === hikiko_ is now known as hikiko [04:57] PR snapd#2039 opened: overlord/configstate: support nested configuration [05:40] PR snapd#2038 closed: many: add email to UserState === mup_ is now known as mup === mup_ is now known as mup === mup_ is now known as mup [07:07] PR snapd#2040 opened: daemon: add support for `snap create-user --known` [07:07] good morning === longsleep_ is now known as longsleep [08:00] PR snapd#2041 opened: daemon: add `snap create-user --force-managed` support [08:10] PR snapd#2042 opened: daemon: add users to the sysInfo data [08:48] As a user of a snap, is there a planned way to get in contact with a developer, or leave a review for a broken snap? [08:48] e.g. htop is broken on the pi, but works on amd64 === ycheng is now known as ycheng-afk [10:26] PR snapd#2036 closed: daemon, store: switch to new store APIs in snapd [10:29] popey, htop works here, whats your issue ? [10:29] (pi3 that is) [10:29] PR snapd#2043 opened: store: change purchase to order and store clean up first pass [10:43] ogra_: 2016/09/29 14:49:55.859377 cmd_run.go:179: WARNING: cannot create user data directory: cannot create "/home/popey/snap/htop/41": mkdir /home/popey/snap/htop: permission denied [10:43] failed to create user data directory. errmsg: Permission denied [10:43] when i try and run it [10:45] popey, thats not a htop issue .... i assume you have classic installed and ran sudo classic ? [10:45] yes [10:45] Hello, where do we report issues with the snap store? [10:45] and you installed that as your first snap ? [10:46] possibly, yes [10:46] well, then the sudo caused /home/popey/snap to be created root owned [10:46] jusz chrown -R popey /home/popey/snap [10:46] Is "Developer registration portal" correct? [10:46] there is a bug open somewhere about that [10:46] ok, thanks [10:47] \o/ fixed [10:49] oparoz, https://bugs.launchpad.net/software-center-agent/+filebug [10:50] Thanks ogra_ [10:50] popey, bug 1620592, seems zyga is on it [10:50] Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership [10:53] PR snapd#2044 opened: snap: auto-import assertions from block devices [10:54] pitti: hi, quick question - I have a udev rule in https://github.com/snapcore/snapd/pull/2044/files#diff-ae4a6795688426c8798d190872d58f89R1 that ideally triggers when a new block device is mounted. this works fine, however I noticed there is a small race, i.e. I get the udev event when the device is not fully mount (not available in /proc/self/mountinfo yet). a small wait fixes it but that is of course not ideal, do you have a suggestion how to p [10:54] roperly fix this? [10:54] PR snapd#2044: snap: auto-import assertions from block devices === hikiko is now known as hikiko|ln [11:12] PR snapd#2044 closed: snap: auto-import assertions from block devices [11:24] * cjwatson belatedly uploads a bzr SRU for https://bugs.launchpad.net/bzr/+bug/1606203 (though it'll need SRU team approval) [11:24] Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' (Ubuntu Xenial):In Progress by cjwatson> [11:30] cjwatson, whee ! [11:37] mvo: err, udev rules do NOT trigger on mounts, at least not in general; they trigger when a device appears or goes away, or gets reformatted [11:38] mvo: how do you mount the device? [11:39] mvo: sorry, on a conference, 'orribly lagging on IRC [11:41] mvo: if "snap auto-import" does the mouting by itself, don't you want to hand it the device name as an argument? [11:41] pitti: yeah, I think that is actually what I want [11:41] mvo: but if it doesn't, what *does* mount the device? [11:42] mvo: do you have some kind of udisks2 and automounter? [11:42] pitti: it seems udev+systemd makes this a bit tricky, maybe with%I and the @ thing of systemd? [11:42] pitti: I think snapd may need to do the mounting itself (ro mounting) [11:42] pitti: to a temp location and all that, we do not have udisks2 in the general case :/ [11:43] mvo: yes, you can start snapd.autoimport@%k.service from the udev rule [11:44] mvo: so how does this work right now? (aside from the sleep) [11:44] pitti: it works only on the desktop currently, next step is to add mounting if no automounter is available [11:45] ah [11:46] mvo: open a new unshared mount ns and mount it there, to not confuse the host system [11:46] pitti: I guess that is also going to be tricky because I don't want to interfere with the existing automounters [11:46] we have autofs ... couldnt we use systemds automounter ? [11:46] pitti: yeah, that was my thinking [11:46] ogra_: you can, if you pin down the mount dir [11:46] but then you can't easily have more than one at a time [11:46] (not sure if that's a thing) [11:48] sorry, need to go again, bbl [11:48] pitti: thank you! I will do the %k and %I stuff and do the mounting next, thanks for your help === hikiko|ln is now known as hikiko [12:09] PR snapd#2043 closed: store: change purchase to order and store clean up first pass [12:22] PR snapd#2045 opened: many: remove all traces of the /v2/buy/methods endpoint [12:58] PR snapd#2046 opened: cmd, disconnect: abbreviated forms of disconnect [13:03] Is it possible to namespace snaps at install time? In order to have different versions of the same snap installed [13:03] is there a way to provide configflags with spaces to the autotools plugin without it breaking? [13:03] snap install mysnap --prefix=featureX [13:04] if I use different lines, that works but not when same thing needs to be repeated multiple times. on the same line the space character causes error for the configure script [13:05] (multiple times -> non-unique elements error) [13:16] PR snapd#2044 opened: snap: auto-import assertions from block devices [13:18] when packaging an (python) app which tries to write to /etc/init.d/appname, and obviously fails during snappy, what's best practice here? Patch setup.py and install into some $SNAP.. dir and patch the app not to look in global /etc? [13:19] ogra_: so - we think about udisks2 as part of ubuntu-core, what do you think? looks like its just 300kb [13:19] mvo, not thrilled about adding all that stuff lately .. :(( [13:20] mvo, why cant you use systemd's automount ? [13:20] pitti: so while I was working on this auto-impoter I noticed that its tricky to not get in the way of existing auto-mounting, it feels like replying on udisks2 is more reliable, do you think that is an reaonable idea? add it to ubuntu-core [13:20] ogra_: because the names are not predicatable - or am I overlooking a way ? [13:21] ogra_: i.e. if there is a way to say "mount any block device to /media/" from systemd that would be great [13:21] https://www.freedesktop.org/software/systemd/man/systemd.automount.html [13:21] Where= [13:21] Takes an absolute path of a directory of the automount point. If the automount point does not exist at time that the automount point is installed, it is created. This string must be reflected in the unit filename. (See above.) This option is mandatory. [13:22] so you make a udev rule that creates the unit on plugin ... with a "Where=/media/$device-label" or some such [13:22] and a udev rule that removes the dir on unplug [13:23] super simple [13:23] jdstrand, hi, is it possible to define an apparmor rule that allows access to path "/"? it looks like http://paste.ubuntu.com/23255279/ does not work, for instnace [13:24] ogra_: that sounds interessting, I'm slightly concerned about when teams like morphis who use udisks2 as a snap that it does not interfere here [13:24] mvo, my prob with udisks is that along with the diskspace you also add another constantly running daemon [13:25] we slowly start to grow out of embedded (though the keyboard stuff was worse here than udisks would be ...) [13:26] i'm not sure if there would be any interference between automounter and udisks ... thats a pitti question ... worst case we'd need some automatism that turns off the automounter stuff dynamically [13:29] (we could abuse interfaces here ... if a certain interface is used, turn off the global mounting support and hand it over to the in-snap udisks) [13:30] (or simply tell morphis to use the system level mounting :P ) [13:35] abeato: yes, we do that in several places. can you show me the denial? [13:36] jdstrand, Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.95" (uid=0 pid=5079 comm="/snap/ofono/x1/usr/bin/dbus-send --system --type=m") interface="org.ofono.Manager" member="GetModems" error name="(unset)" requested_reply="0" destination="org.ofono" (uid=0 pid=5061 comm="/snap/ofono/x1/sbin/ofonod -d ") [13:36] abeato: the apparmor denial from syslog [13:36] jdstrand, [22568.513731] audit: type=1107 audit(1475242602.796:90): pid=1198 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.ofono.Manager" member="GetModems" name=":1.103" mask="receive" pid=5061 label="snap.ofono.ofono" peer_pid=5141 peer_label="snap.ofono.dbus-send" [13:36] exe="/usr/bin/dbus-daemon" sauid=100 hostname=? addr=? terminal=?' [13:38] abeato: is the interface connected? [13:38] jdstrand, yes [13:39] can you paste /var/lib/snapd/apparmor/profiles/snap.ofono.ofono ? [13:39] jdstrand, things go through with path different from "/" , like /sss [13:39] sure [13:40] ogra_: I poke at it some more, maybe I find a reliable way [13:40] jdstrand, http://paste.ubuntu.com/23255346/ [13:40] well, i think the systemd automounter should be the way to go [13:40] * ogra_ wonders if systemd doesnt also have a keymap selection for consoles :P [13:43] abeato: can you 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.ofono.ofono' and try again? [13:45] jdstrand, same error, must be in another profile [13:46] jdstrand, is says exe="/usr/bin/dbus-daemon" ? [13:46] abeato: what do you mean 'must be in another profile'? [13:46] that doesn't matter [13:46] another apparmor file [13:46] label="snap.ofono.ofono" [13:46] that is the profile we need to modify ^ [13:46] abeato: can you paste the new denial? [13:47] jdstrand, [23082.209137] audit: type=1107 audit(1475243116.493:101): pid=1198 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.ofono.Manager" member="GetModems" mask="send" name="org.ofono" pid=5614 label="snap.ofono.dbus-send" peer_pid=5566 peer_label="snap.ofono.ofono" [13:47] exe="/usr/bin/dbus-daemon" sauid=100 hostname=? addr=? terminal=?' [13:48] that is a different denial :) [13:48] label="snap.ofono.dbus-send" [13:48] so now update /var/lib/snapd/apparmor/profiles/snap.ofono.dbus-send to have: [13:49] dbus (send) bus=system path=/ interface=org.ofono.* peer=(name=org.ofono, label=snap.ofono.ofono), [13:49] abeato: ^ [13:50] abeato: then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.ofono.dbus-send [13:50] jdstrand, aha, let me modify the connected interface [13:50] abeato: it is important to remember that if you change the apparmor profile on disk, to reload it with apparmor_parser -r. it is also important to remember that we mediate both sides of the connection and to keep the label and the peer_labels straight [13:51] abeato: it easy to miss something unless you're used to looking at denials [13:51] it's* [13:52] jdstrand, that did the trick, thanks a lot [13:53] jdstrand, yep, thanks for the hints :) [13:54] abeato: fyi, the two rules in http://paste.ubuntu.com/23255346/ could be combined into one: dbus (receive, send) bus=system path=/{,**} interface=org.ofono.* peer=(label=###PLUG_SECURITY_TAGS###), [13:55] abeato: fyi, the two rules in http://paste.ubuntu.com/23255346/ could be combined into one: dbus (receive, send) bus=system path=/{,**} interface=org.ofono.** peer=(label=###PLUG_SECURITY_TAGS###), [13:55] sorry for the double paste-- the second rule is what I think you would want [13:55] jdstrand, sure, will do that [13:56] abeato: the path=/{,**} in an alternation. the interface=org.ofono.** is for org.ofono.foo.bar. if you only have org.ofono.* then org.ofono.foo matches, but org.ofono.foo.bar doesn't [13:57] abeato: perhaps the ofono api doesn't need org.ofono.**, but in case it does, there you go [13:58] don't think it needs **, but yeah [14:10] Hey! I just got back to debugging my simple python3 snap again [14:10] The problem I have is that the script does not work because I get "exec: image-info: not found" (image-info is the script name) [14:11] So I went into snap run --shell for the snap and started debugging [14:11] PR snapcraft#813 closed: "snapcraft validate" and "snapcraft gated" commands [14:12] And the strange thing my experiments revealed: the command-image-info.wrappercommand-image-info.wrapper only works when I change the interpreter from sh to bash (uh?) [14:12] are you using any bashisms ? [14:12] No, this is just a pure python3 script [14:13] The part that's failing is the wrapper which is autogenerated I guess? [14:13] yes, it is [14:13] With it having the default /bin/sh, the PATH doesn't seem to be respected by the final 'exec' call [14:13] No idea why [14:13] (and it works for all other snaps without changing to bash) [14:13] Yeah, it completely makes no sense to me... [14:14] No one had any issues like that? [14:14] i havent heard about any [14:16] though i havent seen anyone call python3 directly from the apps: entry in snapcraft.yaml either [14:17] which IIRC you are doing [14:19] I'm not calling it directly per se, I just install the main part in parts: using the python3 plugin, add the image-info app with the image-info command [14:20] Since my setup.py installs the python3 scripts to the right bin place [14:20] So in theory it should all just work: scripts are in the right /usr/bin in the snap, the PATH is set to the correct values [14:20] show me your snapcraft.yaml again [14:20] But when trying to run the snap, I get exec: image-info: not found [14:21] http://paste.ubuntu.com/23255543/ [14:21] Really simple yaml right now [14:21] and the image-info script ? [14:21] (the shebang mainly) [14:22] Well, the image-info script is "#!/usr/bin/python3" and then the rest of the script [14:22] right, thats wrong [14:22] What is failing is the command-image-info.wrapper [14:22] Wrong? [14:22] I thought it should be the command to call? [14:22] make it "#! /usr/bin/env python3" [14:22] Oh [14:23] hm [14:23] you are forcefully calling the python3 from ubuntu-core ... not the one you ship [14:23] Let me try that [14:23] PR snapd#2047 opened: snap: auto mount block devices and import assertions [14:23] the one you ship is in $SNAP/usr/bin/python3 ... which your env points to [14:23] (through the PATH) [14:24] though i thought the python plugin actually re-writes the shebang lines at package build [14:25] ogra_: yeah, it does - but it re-wrote it to something strange [14:25] When I examine the /snap/landing-team-tools/x1/usr/bin/image-info script, I see the interpreter being set to "/parts/landing-team-tools/install/usr/bin/python3" [14:26] Doesn't look like it's correct [14:26] yeah [14:26] even after you changed the line and re-built ? [14:26] No, didn't try that yet [14:26] I'm wondering if it'll help though, as currently the exec line in the wrapper is failing [14:27] It's not even reaching my image-info script [14:27] Like, at all [14:27] "exec: image-info: not found" reads to me like it tries to sxec image-info ... [14:28] but cant exec it because something inside (the interpreter) is not found [14:28] else i'd expect "exec: not found" [14:31] hi, having some issues while trying to snap an app that tries to write to SNAP_COMMON. the app is unable to write there, getting: permission denied. [14:32] * ogra_ hugs mvo for https://github.com/snapcore/snapd/pull/2047 [14:32] PR snapd#2047: snap: auto mount block devices and import assertions [14:32] beautiful :) [14:33] ogra_: yeah, all without new stuff [14:33] yep :D [14:34] * ogra_ loves it [14:34] ogra_: I'm very happy, probably need a look from pitti but I think its good [14:34] yeah, looks totally fine to me [14:34] morphis: all good, looks like we don't need udisks afterall [14:34] morphis: sorry for the noise [14:35] verterok, looks like either Bug 1611063 or Bug 1610149 [14:35] Bug #1611063: can't mkdir SNAP_USER_COMMON directory [14:35] Bug #1610149: writing to the "common" directory needs to have sudo right [14:36] verterok, for a user app/executable you need to use SNAP_USER_COMMON ... SNAP_COMMON would be for a daemon or some sudo executed app [14:38] ogra_: ok. I was trying to store a file accesible from this app for any user running it, not just for this user [14:38] ogra_: but I think I can workaround this by having a file per user [14:39] well, or you could create some daemon script that handles the file or so [14:39] ogra_: hah, ok, I upgraded snapd, ubuntu-core-launcher and snapcraft and now things work [14:39] hah [14:39] Strangeness [14:40] ogra_: thanks for the help nevertheless! :) [14:40] heh [14:41] ogra_: thanks [14:41] :) [14:55] PRO TIP: if you want ubuntu-image to use your kernel snap locally, you have to specify it with --extra-snaps in addition to setting it in the model assertion [14:55] yep ... that was just discussed on the meiling list recently :) [14:56] I was just about to say... that sounds familiar [14:56] *mailing [14:56] huh [14:56] I had to dig into the snapd source to figure it out [14:57] niemeyer, i got poked about hibernate on snappy images recently ... that made me think ... we kind of didnt define "swap" as a partition type for gadget.yaml, i think we should add that as optional type [14:57] Croepha, no! Don't look directly at it! [14:57] my snapd is riddled with fmt.Printfs now [14:57] Hahaha [14:58] niemeyer, we'll indeed never used it on SD images ... but i can immagine there are plenty use-cases where people want/need it [14:58] *use it [14:58] it took me a solid 20 minutes to figure out that ubuntu-image doesn't actually do anything, and it just passes most work off to snapd [14:58] I [15:02] pitti: ping [15:04] cyphermox: maybe you can help too [15:06] pitti, cyphermox: is it correct that netplan does not restart networkd/network-manager when the last netplan configuration file was removed and this causes the current configuration not to be disabled and still being active until the next device reboot? [15:07] Is the apparmor issue with ld.so.preload is only created by Launchpad? [15:16] oparoz, ask jdstrand [15:17] lool, is there any reason that snapweb is constanly running instead of using socket activation ? it eats from 10MB reserved memory (pi2) to 30MB (dragonboard) just for idling [15:17] ogra_, does snapd support socket activation? [15:17] i guess we dont actually need it running all the time, do we ? [15:18] kyrofa, well, systemd does ... should only be a matter of writing the unit differently [15:18] having suchh processes run all the time on an IoT device seems very wasteful [15:18] ogra_, sure, I'm just saying that I think that might be the reason :P [15:18] ah [15:18] k [15:21] * ogra_ has a hard time resisting to suggest to use a three char suffix at https://github.com/snapcore/snapd/pull/2047 [15:21] PR snapd#2047: snap: auto mount block devices and import assertions [15:22] oparoz: I don't understand the question. if you are talking about https://bugs.launchpad.net/snappy/+bug/1627813, I need to prepare an update for that [15:22] Bug #1627813: AppArmor denies access to /etc/ld.so.preload on armhf [15:22] s/update/PR/ [15:29] Thanks jdstrand. It seems to only happen with Snaps built from Launchpad, but maybe I'm wrong and that bug appeared in a snapd update pushed this week [15:40] PR snapd#2048 opened: interfaces: allow read of /etc/ld.so.preload by default for armhf on series 16 [15:40] oparoz: fyi ^ [15:42] Thanks jdstrand can this be patched live? [15:43] oparoz: yes. add '/etc/ld.so.preload r,' to /var/lib/snapd/apparmor/profiles/snap.your.app, then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app [15:43] oparoz: you'll have to do that after refresh, install, install/remove, etc [15:44] Thanks jdstrand that will at least tell me if the other error messages I get related to Go6 are related or not :) [15:48] jdstrand, tht didn't work: AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.spreedme in /var/lib/snapd/apparmor/profiles/snap.spreedme at line 1: syntax error, unexpected TOK_MODE, expecting TOK_OPEN [15:48] oparoz: can you paste the file in paste.ubuntu.com? [15:49] jdstrand, the file contains a single line: /etc/ld.so.preload r, [15:50] jdstrand, my bad... I overwritten it [15:50] oparoz: did you delete everything out of that file or create a new one? [15:50] oparoz: you can uninstall the snap then install it (back up your data if it is important) [15:53] jdstrand, looking at the profiles, I got it wrong. It needs to be installed for every single service and I had used the snap name [15:54] oparoz: yes, sorry if I wasn't clear. that is what I meant with snap.your.app === victorp_ is now known as victorp [15:59] jdstrand, that doesn't change anything unfortunately: https://paste.ubuntu.com/23255934/ === dpm is now known as dpm-afk [16:29] so, is the current paradigm to have grub mount the kernel snap and load the kernel that way? [16:41] looks to be that way [16:42] thats pretty clever [17:06] lol, ive got the craziest nesting doll of loopback mounts going on right now, ive got a .img mounted, and I have a kernel snap mounted form inside it, then the initrd inside of it [17:48] PR snapd#2048 closed: interfaces: allow read of /etc/ld.so.preload by default for armhf on series 16 [17:51] jdstrand: was this breaking arm snaps? [17:51] zyga: it was as the reporter said, 'spamming the logs' [17:52] I don't think it would cause them to break outright [17:52] but I guess it is possible [17:52] jdstrand: I recall someone asking about snaps breaking on arm [17:52] jdstrand: with some cryptic message about v6 [17:52] could be this. could be the 4.8 kernel [17:52] zyga: oh that was different [17:52] we fixed that a while ago [17:53] jdstrand: was that auxv? [17:53] that was the 'unsafe' rules [17:53] yeah [17:53] ah [17:53] so, i spent part of the day away from home, I managed to make spread testing of snap-confine work offline [17:54] oh neat :) [17:55] I need to automate creation of the offline setup (one file left) but it should be ok [17:55] jdstrand: I'll get to making all the small branches for everything today and tomorrow [17:55] a cool next addition to spread would be running snapd in local lxd [17:55] I might take a look at that at some point if others don't [17:56] jdstrand: oh, after some of my experiments I love qemu [17:56] jdstrand: I heard that we can now have nested apparmor, lxd just might be a target now [17:57] jdstrand: but still, offline apt, offline snap, that's useful regardless of where that works [17:58] I <3 qemu (with livirt especially) [17:58] yes, if you have amd64 you should be able to do nested qemu [17:59] PR snapd#2049 opened: Allow writing DHCP lease files to /run/NetworkManager/dhcp [17:59] I mention lxd cause running the snapd and snap-confine testsuites inside of lxd shipped as a snap would be handy for local tests but also really exercise the apparmor stacking feature [18:00] and be a great regression test [18:01] hmm, I didn't think about the stacking case, that is a good point [18:02] it's exciting-- all the pieces are in flight fr 16.10 [18:02] and once there, the SRUs will begin [18:03] that is some very cutting edge stuff [18:03] and it'll be great for the lxd project and snappy [18:06] jdstrand: any chance this is all also upstream in relevant places? [18:06] btw, the complexity of lxd running as a snap on lxd running as a snap is mind boggling [18:06] what's the kernel mount namespace layout again? [18:06] PR snapd#2050 opened: interfaces/policy: start of interface policy checking code based on declarations [18:06] zyga: everywhere except the kernel. the kernel bits are still work in progross [18:07] do you need kernel devs? :-) [18:07] zyga: well, that is deep nesting and won't be supported just yet (it's planned). lxd as a snap running snapd is supported [18:08] zyga: well, the kernel devs that were working on the upstreaming got put on the stacking feature [18:08] zyga: tyhicks can comment on the progress and next steps [18:08] tyhicks: context: stacking support and upstreaming [18:09] jdstrand, that bug is killing snaps on armhf [18:09] oparoz_: ack (zyga ^) [18:09] It's impossible to install anything. Services all crash [18:09] I was joking :) maybe I can re-brand myself as a junior kernel developer [18:09] oparoz_: it's committed now [18:10] Yeah, I saw, thanks :). I can't test if it works because app-confine doesn't seem to have a customizable apparmor profile [18:10] zyga, jdstrand: the kernel changes needed for stacking are not upstream [18:11] zyga, jdstrand: now that stacking is just about finished, upstreaming can commence after the bits of work left for gsettings mediation [18:15] oparoz_: snap-confine has a profile that you can change (well, perhaps not in a presistent way but still) [18:15] zyga where? [18:15] Noting in the apparmor folder [18:16] Couldn't find doc about it [18:16] PR snapd#2035 closed: asserts: support parsing the slots stanza i.e. slot rules in snap-declarations [18:18] oparoz_: anywhere, you can just load the profile [18:18] oparoz_: look at /etc/apparmor.d/usr.lib.snapd.snap-confine [18:18] oparoz_: you can copy/edit that anywhere [18:18]