=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:00] o/ [08:02] hi snappers [08:02] i need help [08:03] am trying to pack my qt app for snap store [08:03] anyone here ?? [08:09] my app is precompiled with qmake can i snap it ?? [08:09] who is on ?? [08:09] i need help [08:11] hey commander_! I don't think we have a qmake plugin, but kyrofa and sergiusens would be able to help you in a few hours (they are US-based) [08:11] ah, snap [08:44] hi. I'm working on packaging kodi as snap package and have problems getting opengl to work [08:46] it trying to load the intel driver i965_dri.so, but claims the file doesn't exist, while it IS in the snap at the correct location [08:47] here is the console output with LIBGL_DEBUG=verbose: http://paste.ubuntu.com/16252748/ [08:48] any pointers would be much appreciated [09:39] wsnipex: hey [09:40] wsnipex: looking at your output the thing that jumps at me is this: [09:40] libEGL warning: DRI2: failed to open i965 (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri) [09:40] libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri) [09:40] yeah, the lib is there though [09:40] note that snaps do not chroot, so your search path has to understand $SNAP [09:40] also note (play with hello-world.sh) that snap apps don't see your normal / [09:41] as they get the ubuntu-core snap bind-mounted in various places [09:41] so you don't see your normal /usr [09:41] you see the very same ubuntu-core snap /usr [09:41] the same on desktop and "devices" [09:41] wsnipex: does this make sense? do you see what I mean? [09:41] thats what I thought. How can I modify the command wrapper that sets LD_LIBRARY_PATH? its always overwritten [09:41] wsnipex: you can just add one more wrapper [09:42] wsnipex: we also have SNAP_LIBRARY_PATH but we don't use it for intal AFAIR, it is used for nvidia [09:42] I'm completely new to snaps, so pleae bear with me [09:42] no worries, we all are :) [09:42] * zyga should publish the next article about snap runtime environment and confinement details [09:43] so, how/where do I add another wrapper? [09:43] wsnipex: add a new app, say 'sh' and run shell there [09:43] in that shell experiment with various LD_LIBRARY_PATH values [09:43] once you know what you want [09:43] albeit I can do it in our own wrapper script, I'd like to change as little in kodi as possible [09:43] add a new file in the build tree, make sure it gets copied with snapcraft.yaml (using the copy plugin) [09:44] and change the command of the app you were running originally to run the wrapper [09:44] ah, I see, thanks [09:45] wsnipex: but first experiment with just a shell, look at how the environment looks like there [09:45] so currently there is no way to directly influence the default wrapper [09:45] there are two "wrappers" [09:45] the one in /snap/bin/ made by snappy on install [09:45] you cannot influence that one [09:45] heh, yes. I mean command-kodi.wrapper [09:45] and one by snapcraft (command-foo.*) [09:45] you can freely change that one though that's something snapcraft makes [09:45] it's just part of snapcraft implementation detail [09:46] I tried that, but my changes were overwritten on snapcraft snap [09:46] yes, I know, the solution is to add your own wrapper :) [09:46] run it as the 3rd wrapper [09:46] sorry, we'll get it more streamlined over time [09:46] just didn't have the time for 16.04 :) [09:47] no worries [09:47] also the plugins could be more flexible, specially autotools and cmake ;) [09:48] those are extensible [09:48] you can have your own local plugins in your tree [09:48] and snapcraft picks them up [09:48] it's all python so it is pretty flexible [09:49] yeah, I saw that, just didn't have time to look further into it [09:56] zyga, http://paste.ubuntu.com/16254300/ [09:57] libEGL warning: DRI2: failed to open i965 (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri) [09:57] same search path? [09:57] I've exported and printed LD_LIBRARY_PATH [09:57] first line, 1st entry [09:57] I saw that but look at the "search paths" part being indifferent [09:57] maybe something different [09:57] -rw-r--r-- 5 root root 6561728 Apr 14 21:08 /snap/kodi/100001/usr/lib/x86_64-linux-gnu/dri/i965_dri.so [09:58] EGL specific probably [09:58] nothing is looking at that directory [09:58] yeah, it seems to ignore the ld_library_path [09:58] there's no chroot /usr/lib/x86_64-linux-gnu/dri is _not_ the same as $SNAP/usr/lib/x86_64-linux-gnu/dri [09:58] sure, I get that [09:58] sorry, this is new ground to me [09:59] I wish I knew where this is hardcoded [09:59] might have to take this up with intel mesa devs [09:59] strace it, grep for PATH in sources, look at gdb, poke around [10:00] will do [10:00] and thanks for your help! [10:00] good luck, ping me back when you get it running [10:00] I think this should be handled better by the opengl interface [10:00] just not sure how exactly just yet [10:01] yeah, probably dlopen is not the optimal way [10:21] hi [10:22] i snapped a package but didn't got .snap file after successful compilation [10:22] am using ubuntu 14.04 [10:25] anyone to help here ?? [10:26] zyga, got a step further: LIBGL_DRIVERS_PATH: /snap/kodi/100001/usr/lib/x86_64-linux-gnu/dri [10:26] cooool [10:26] looking at the mesa code brought up this var [10:27] I'll write this down, perhaps something we should set in snapcraft/snappy by default [10:27] i snapped a package but didn't got .snap file after successful compilation' [10:27] guys [10:27] help me please [10:27] wsnipex: does it load now? [10:27] so, I now briefly see kodi starting... before it cores :) [10:27] commander_: please share the log/output in a pastebin [10:27] wsnipex: strace/gdb helps [10:27] okay zyga [10:27] wsnipex: add gdb,strace as parts to your snap [10:27] (and busybox) [10:28] shell inside and poke around [10:28] use: ulimit -c unlimited [10:28] and cd $HOME to make the core there [10:28] you can inspect that core later [10:28] I went through this experience yesterday [10:28] what helped a lot was fetching specifc libraries with apt-get source [10:28] and building them with DEB_BUILD_OPTIONS=nostrip [10:28] so that I would have symbols for gdb [10:29] this helped me zero on the issue [10:29] if you want I can also show you a trick that will let you skip snapcract snap part [10:29] and just work live [10:29] its still something with gfx [10:29] with a "writable" snap [10:29] wsnipex: after you install your snap the first time, unmount it (assuming there are no services runing) [10:29] zyga, http://pastebin.com/cEyUbB5R [10:29] that'd be cool [10:30] and sudo mount --bind /path/to/your/build/tree/snap /snap/$SNAP_NAME/10000* (the largest revision) [10:30] then you can run your snap and you can compile/edit/change stuff [10:30] a bit hacky but nice before we finish $ snap try [10:30] i got no .snap file [10:30] commander_: is this with snapcraft on ubuntu 16.04? [10:30] its on 14.04 [10:31] commander_: can you do snapcraft clean; snapcraft | pastebinit [10:31] okay wait [10:31] commander_: show that output to kyrofa or sergiusens though we're a bit busy with sprint prep (me included) so no promises [10:32] zyga, i cleaned and run snapcraft [10:32] * zyga has to dig out some ram from his 2nd PC, brb [10:32] okay [10:32] nice trick :) [10:32] zyga, it is downloading everything again [10:33] i mean libraries and other stuffs [10:33] please look and my yaml file once plz [10:34] zyga, here it is http://pastebin.com/kbpyv3Y1 [10:34] zyga: do we support it on 14.04? [10:34] popey: no [10:34] kyrofa, here is my yaml http://pastebin.com/kbpyv3Y1 [10:35] popey, [10:35] zyga: so.. the fact that commander_ is on 14.04.... [10:35] am keshav bhatt @keshavmail68 from twitter [10:35] commander_: you need to use 16.04 [10:35] i also unable to upgrade to 16.04 from ubuntu 14.04 [10:36] sergiusens: it would be nice if we could SRU snapcraft to 14.04 that says "use xenial" if it sees plugs/slots [10:36] popey, i logged in to my dev account on developer portal and it said its disabled , whats the matter ??? [10:36] or something similar to version snapcraft support properly [10:36] commander_: I don't know. [10:36] zyga, what about my yaml file bro is it okay ??? [10:37] popey, i mean why will they disable my account for no reason ?? [10:37] commander_: on xenial it might build, the icon is no longer something you set in the yaml, put it in setup/gui [10:37] does snappy use systemd? [10:37] proteusguy: yes [10:38] zyga, thanx. I don't suppose there's any simple way to eliminate systemd from snappy and use something else? [10:38] zyga, i also noticed a bug in snapcraft [10:39] proteusguy: i don't know, you'd have to explore, I doubt that would be accepted upstream though [10:39] proteusguy: systemd is used for a number of things [10:40] zyga, it is unable to build example from launchpad , if it will try do download untrusted packages , i mean if gpg signature is missing for a package it will simply skip download with some apt-get errors . [10:40] proteusguy: look at the source, there's a lot of things happening there with various places [10:40] commander_: sorry I cannot help you with 14.04 and snapcraft issues [10:41] okay i will install ubuntu 16.04 tonight [10:41] i will talk to you later okay :) thanks for your time bro [10:42] zyga, bro snap file appeared this time [10:42] haha [10:42] its working now [10:42] thanks [10:42] zyga, that's what I figured. thanx for your reply. [10:43] it saying snapping \ [10:47] my 2mb app is now 80mb wts that ??? [10:47] is it okay ?? [10:48] commander_, what libraries does it use? [10:48] qt libs [10:48] commander_, only 80mb? quite good [10:48] its a qt app uses qml and c++ [10:48] :-) [10:49] what ! :D [10:49] commander_, so the 80mb is all of qt and c++ libs [10:49] commander_: that's about right then, look at the clock and calculator apps and see how big they are :) [10:49] and whats the issue with debian packaging it make only a 2mb package [10:50] haha [10:50] guys here is my app www.ktechpit.com/ubuntu/ktechpit-com-released-ubuntu-play-store-ubuntu-14-04/ [10:50] if you wana check it out you can download a trial version . [10:51] before I forget: it might be nice to document how to use snap behind a proxy somewhere, took me a bit to find that overriding systemd config with Environment=http_proxy [10:56] bye guys i will join later [11:01] wsnipex: there's an open bug about proxy support [11:01] wsnipex: we'll have to look at how that should work properly [11:02] well, go supports the http_proxy env var ootb [11:02] but systemd doesn't allow reading those [11:02] yes but it's tricky because this is the daemon that has to know this :) [11:02] exactly [11:03] so you have to set it in the systemd.service [11:03] the real issue with systemd is: you cannot have real variables in the systemd environmet [11:03] so you can't do: Environment=http_proxy=$http_proxy [11:04] which is a real pita [11:04] well that cannot obviously work [11:05] the reality is that proxy support is more complex than a single global settinhg [11:05] it could, if it was set in /etc/environment and systemd would read that [11:05] real proxies often require more elaborate setup, if we're fixing proxy we should really make it work [11:05] not just more work [11:06] best option might be to have snap read it and pass it on to the deamon, if thats possible [11:06] what if each user has different proxy? [11:06] if snap reads the users env, that'd be no issue [11:06] what if both users want a different proxy? [11:06] not snapd [11:07] one snapd services many users [11:07] anyway all I'm saying is that there's a bug and this is not a trivial thing to solve [11:07] yes, have snap (not snapd) read it [11:07] brb [11:18] wsnipex, whats the problem with proxies? without making me read all the backlog :-) [11:19] wsnipex, do you have a particular issue that needs addressing? [11:19] or is it a more generic "we should support this" thig [11:19] thing [11:19] snap won't use a system configured proxy [11:20] unless you override the snapd systemd service [11:20] wsnipex, i ask you again, are you having a problem you need solving, or is it an on-principle issue? [11:21] I solved it for me, so the latter [11:21] wsnipex, how did you solve it? editing the .service file? [11:22] I created /etc/systemd/system/snapd.service.d/proxy.conf [11:22] [Service] [11:22] Environment=http_proxy=.... [11:23] wsnipex, question for you: would doing, instead, `EnvironmentFile=/etc/environment` solve it for you? [11:23] a little cleaner then editing the actual service file [11:23] that might actually work, let me try [11:23] ah, yes, copying to /etc/ is what i meant by editing (on a snappy core it's your only option) [11:24] wsnipex, followup question is whether instead of that, PassEnvironment= works for you [11:25] then we can talk about which approach is best of these two, if they both work [11:25] yes, works [11:25] could be a decent solution [11:25] ogra_, on snappy core is /etc/environment writable? [11:26] but it won't work for users having different proxies [11:26] Chipaca, i dont think so ... [11:26] (and we should find some other mechanism ... if you need global vars) [11:27] wsnipex, i hear you. Not sure there's much we can do for users with different proxies at this point. [11:27] I mean, passing the info from the user to the server is incredibly tricky [11:28] and most of the time is going to be the wrong thing to do anyway [11:28] PassEnvironment doesn't work [11:28] noted [11:28] ta [11:28] per user stuff should come from /etc/profile.d [11:28] didn't even know this [11:28] where should PassEnvironment take the env from? [11:28] wsnipex, systemd [11:29] wsnipex, it's "pass these env vars from systemd to the child" [11:29] ogra_, isn't /etc/profile.d (ba)shist? [11:29] ogra_, ie not something like /etc/environ [11:30] well, pam parses it iirc [11:30] so it is "loginish" :) [11:31] it is where per-user stuff should go :) [11:31] ogra_, /etc/profile.d is parsed by pam? things like /etc/profile.d/bash_completion.sh ? [11:31] that sounds wrong [11:32] well, by shell logins [11:33] its parsed by the shell [11:35] uh, maybe pam_env reads them [11:36] no, i think that reads ~/.pam_environment only [11:37] thats probably the best place to use then :) [11:38] Good morning [11:43] how can I get around: Mount snap "kodi" (cannot find mounted snap "kodi" at revision 100001) [11:43] can I force install somehow? [11:44] how did you build it ? [11:45] snapcraft ? [11:45] yes, but I had it installed before already [11:46] then following zyga's advice to debug it, umounted it manually [11:46] now I cannot get it to install anymore [11:46] hmm, zyga might know a way out then :) [11:46] since he got you into this [11:46] where does snapd store its state? [11:47] it clearly thinks its already installed, so if I could purge this somehow.. [11:52] wsnipex, may I suggest the reset-state script in https://github.com/zyga/devtools/ ? [12:04] kyrofa, thanks! [12:04] worked [12:05] wsnipex, hopefully once the next release makes it through the SRU process that won't be necessary anymore [12:06] nice [12:26] Hey guys, can we use ZFS snapshots in Ubuntu Core to keep track of changes when doing updates/rollbacks? [12:28] no [12:28] ;( [12:28] Why ogra_ ? ZFS isn't available? [12:28] Perhaps in the future.... [12:28] ogra_, will ZFS be supported at all now that it's in xenial? [12:28] right [12:28] Ah [12:29] kyrofa, I still don't see it as a good default for embedded.... Beyond that we would indeed need to have support for that in all usespace tools [12:29] *user [12:30] (and it is only available on 64 bit arches afaik) [12:30] ogra_, ah, right, now I remember a conversation you had with someone else about this a few weeks back [12:30] Ah yeah, I kind of forgot the memory requirements... [12:30] ARC is super hungry [12:31] I think it is a good idea to support it long term... Optionally [12:31] but definitely out of scope for the first image [12:33] Thanks ogra_ [12:37] hmm, how can I disable binary stipping in snapcraft? === JanC is now known as Guest26117 === JanC_ is now known as JanC === chihchun is now known as chihchun_afk [13:08] didrocks if commander comes back, tell him to watch the UOS workshop session :-) [13:09] wsnipex, what bad stuff is happening? [13:10] wsnipex we don't do binary stripping just yet [13:11] we will, we don't :-) === oparoz is now known as Guest66429 === oparoz_ is now known as oparoz [13:18] right, I simply misinterpreted the snap output. Once I disabled stripping in the applikation build, its ok [13:18] now I at least get a gdb trace of my crash: http://paste.ubuntu.com/16258222/ [13:19] wsnipex, indeed, as sergiusens mentioned, we will eventually strip (which is why it's named "strip"), so you didn't really misinterpret :) [13:19] is snap restricting access to set locale? [13:19] wsnipex, ah, I know that error! [13:20] wsnipex, are you running this in Ubuntu Core or the desktop? [13:20] desktop [13:21] wsnipex, I'm far from a locale expert so I don't actually know the problem, but one of my snaps had that problem as well and I ended up setting LC_ALL=C.UTF-8 in its wrapper to get around it. I couldn't use anything but C or C.UTF-8. I haven't investigated enough to know who to blame for it though-- the project I was snapping, or something to do with snappy [13:21] wsnipex, sergiusens might have some suggestions, though [13:22] wsnipex, note that ubuntu core _only_ has C and C.UTF-8 locales [13:22] I'm assuming its snappy, since this code is perfectly fine outside of it [13:22] wsnipex, any denials in the syslog? [13:23] I'm running in devmode [13:23] wsnipex, ah, then no :P [13:23] wsnipex, yeah wait for sergiusens. ogra_ might have some suggestions as well [13:23] otherwise it'd hang up way before that ;) [13:24] I'll try setting the locale in the meantime [13:26] sergiusens: will do! :) [13:27] oh wow, setting the locale to LC_ALL=C.UTF-8 works :) [13:27] kodi now starts :D [13:27] thanks kyrofa [13:28] wsnipex, sure thing. Sorry for a workaround instead of a solution there-- I want one as well [13:30] yeah, this needs fixing of course, but its great to have it working for now [13:30] I still have a long road with app-armor... [14:33] sergiusens, kyrofa: coverage fixed in the macaroons branch (using ~130 recorded responses), hope that address your concerns [14:35] elopio: hey-- I have a few ideas for integration tests and wanted to pass them along so they could end up on someone's queue somewhere? should I CC others? [14:36] s/somewhere?/somewhere./ [14:54] fgimenez: elopio: Hi, I have some more info about that issue I was seeing [14:55] fgimenez: elopio: on that test that hits a kernel bug for me, but seems to work for you - I can make it work, but only if I run it by hand from *outside* the snap. When I try to run it from the snappy-tests snap that I built, I hit the problem. Maybe there's some permission/isolation issue here? (I did install with --devmode) [15:14] plars, elopio mmm not sure, you only hit the problem with one of the tests? [15:14] fgimenez: so far, just that one. I haven't tried going further yet [15:18] plars, that tests exercises the home interface by creating and installing test snap with that plug defined, maybe when you try to install that snap from another one without the plug it might cause problems [15:19] fgimenez: --devmode doesn't help me here? [15:20] plars, not sure, can you try the networkInterfaceSuite? [15:22] fgimenez: some of them seemed to work, but then I got a bug here: [15:23] sudo snap disconnect network-consumer:network ubuntu-core:network [15:23] [82096.043981] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 [15:23] so as soon as it tried to disconnect it [15:24] plars, that's from the snappy-test snap, right? [15:24] fgimenez: yes [15:41] fgimenez: can I just connect somehow to everything once the snap is installed? or do I need to go rebuild with more plugs defined in my snapcraft yaml? [15:41] plars, maybe you can regenerate snappy-test defining all the plugs used by snaps created in the tests (currently home and network) [15:41] plars, yes, once it's generated afaik you cannot connect to additional slots [15:42] fgimenez: I actually already have home defined - is that all the first one should have needed? [15:43] - snappy-tests:home [15:43] plars, yes, the home-consumer snap only needs the home plug to be available, but i'm not sure of the behaviour calling it from another snap [15:43] but I also see this in snap interfaces output: [15:43] :home - [15:44] i think you need to manually connect the interfaces [15:44] plars, if you have it already defined and it is failing then that's not the solution of course [15:44] plars, yes, home doesn't autoconnect [15:45] ogra_: fgimenez: so something like: sudo snap connect snappy-tests:home ubuntu-core:home [15:45] yeah [15:45] plars, ogra_ yes, that should do, you can check snap interfaces after [15:46] let me retry homeInterfaceSuite.TestPlugDisconnectionDisablesCreate with that set up [15:46] nope, still hit but on disconnect :( [15:46] sudo snap disconnect home-consumer:home ubuntu-core:home [15:46] [ 657.125253] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 [15:48] * ogra_ guesses you are better off asking zyga or jdstrand here [15:48] plars, maybe zyga can help here ^ [15:48] ogra_, yep :) [15:48] plars: can you paste the full trace? [15:49] jdstrand: the original one was here: http://paste.ubuntu.com/16227643/ [15:49] jdstrand: but that looks slightly different from what I got now [15:49] https://www.irccloud.com/pastebin/isX3KDXU/ [15:50] plars: can you file a bug? jjohansen1, you may want to look at that ^ [15:51] plars: in your bug report, can you tar up everything in /var/lib/snapd/apparmor/profiles and /var/cache/apparmor ? [15:52] jdstrand: I'll have to reboot/retry - it's in a snapshotted qemu session right now, and it hangs when I hit this so hopefully there will be something useful there. Where's the best place to file this? [15:52] interesting that systemctl doesnt complain about the autopilot stuff ... iirc we dont ship that anymore [15:52] plars: oh, and home-consumer_1.0_all.snap. if that has sensitive stuff in it, feel free to strip out the sensitive stuff (only need the yaml) [15:52] jdstrand: that's all from the snappy integration tests [15:53] plars: https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug [15:53] jdstrand, home-consumer comes from here https://github.com/ubuntu-core/snappy/tree/master/integration-tests/data/snaps/home-consumer [15:55] * jdstrand hopes that /var/lib/snapd/apparmor/profiles has the snap.home-consumer.reader and .writer policy [15:56] jdstrand: you want me to run this like I did before, or after connecting to ubuntu-core:home slot manually? [15:56] whatever gets the kernel bug [15:58] Does security-override works to give access to /proc ? [15:59] jdstrand: they both do :) [15:59] I'll do both [16:00] ! [16:00] it's working now - every single time I've run it so far I hit that kernel bug, and now it works [16:01] I wonder if running it as a snapshot made a difference [16:01] plars: its possible sometimes the bug is a crasher and sometimes not. it is clear there shouldn't be a bug and the bug if it doesn't crash now may cause instability and other problems [16:02] ok, I got it to reproduce this time [16:03] by running the whole suite [16:18] jdstrand: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135 [16:18] Launchpad bug 1579135 in apparmor (Ubuntu) "kernel BUG on snap disconnect from within a snap" [Undecided,New] [16:18] jjohansen1: also ^ https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135 [16:18] plars: awesome, thanks! [17:24] plars: I left a couple of questions for you in the bug [17:24] (fyi) [17:36] jdstrand, any chance of a review for https://github.com/ubuntu-core/snappy/pull/1118 today? I'm going on holiday next week and I'd like to have this resolved if we can [17:44] ssweeny: I might be able to. I'm working on something else but I think I can get it done before eod. note, the snappy guys are sprinting next week and seem to be traveling today, so not sure how all that will impact your plans [17:45] jdstrand, fair enough [18:45] I have snappy working on Arch Linux now. Kind of. The problem was that after implementing another check to see if snappy is used on a classic system it tries to do some bootloader stuff upon installing ubuntu-core. Since I didn't use grub it always just exited at that point. For simplicity I just installed grub without actually using it. Now it downloads and installs all the snaps. [18:46] apparmor_status even shows that there are some profiles loaded now. [18:48] Only problem is that a) for some reason /snap/bin isn't in my PATH despite installing apps-bin-path.sh in my profile.d and b) when I try to run ubuntu-calculator-app.calculator it wants root, while on a 16.04 test machine it doesn't. It also fails with "aa_change_onexec failed with -1. errmsg: No such file or directory" [18:50] Adding support for systemd-boot is a little tricky since it's so minimalistic that it doesn't have an env file for variables. You'd probably have to implement a lot of string manipulation magic to essentially emulate that. Also the actual boot entry is a *.conf file in /boot/loader/entries. It can be named however you want. There is no sdboot.cfg for this or something. [18:56] Ahh I see on 16.04 /usr/bin/ubuntu-core-launcher has different permissions [19:34] jdstrand, thanks for the review! I'm looking at adding the label=###PLUG_SECURITY_TAGS### string and it needs a new helper function. My question is what should that string look like at the end. The function for slots includes all the bound apps but that doesn't seem right to me for this [19:35] ssweeny: the plugs side gets all the connected slots. the slots side (what you are looking to add) are all the connected plugs [19:37] jdstrand, ok, so it would still be something like "snap.name.app" or "snap.name.{app1..appn}" or "snap.name.*"? [19:37] the actual format of that string should be like what ###SLOT_SECURITY_TAGS### is. if one snap/app, then no alternation, if all apps within a snap, then a glob (.*) and it multiple snaps, alternations with globs as needed [19:37] yes [19:38] but in this case you might end up with {snap.name1.{app1..appn},snap.name2.*,snap.name3.app} [19:39] does that make sense? [19:39] it is because multiple snaps can plug into a slot. the other way there was only the one slot provider [19:40] ah [19:40] ok [19:41] jdstrand: I'm not sure I understand your comment - I'm not trying to simply install that snap, I'm trying to run one of the integration tests in snappy, which I've packaged in another snap. The integration test does install that home-consumer snap as part of it, but that's just one piece of what it's doing. And it doesn't seem to be the installation of the [19:41]