[00:38] How can one tell what interfaces a snap needs? [00:38] I'm guessing there's no way of knowing, not even at runtime [02:15] noonien: "snap interfaces" should tell you [02:15] "snap interfaces $snap_name" will limit it to just a particular named snap === markusfluer1 is now known as markusfluer [05:21] hello [05:21] can I use snap in centos 6? [09:23] jamesh: I'm creating a snap of an app of which I don't know everything about [09:23] And would like to know what interfaces said app needs [09:48] Hmm, I'm using snap-debug.security to check interface violations, I gave a snap I made a plug to "home", however, it cannot access files in my home directory. [09:48] It gets denied by apparmor [09:48] the snap gets listed under home in `snap interfaces` [11:23] noonien, dont forget that the home interface will not allow access to hidden dirs (for security reasons) [11:27] Yes, I know. It was not a hidden directory [11:27] ogra_: is wlan expected to work on pi3? i get a timeout. Ethernet works fine. [11:28] also, are there any instructions on how to set up wlan on a running core? [11:28] Snap looks like great packaging, however, due to needing to specify every single thing that an app needs access to, I've decided not to use it [11:28] jdstrand, only if you fist configure it with wired ... there is a driver bug ... [11:28] bah [11:28] :) [11:28] jgdx, [11:29] jgdx, so on first boot, set it up with wired ... then reboot, ssh in, run sudo console-conf, turn off wried and enable wlan ... rebopot again and it should all work [11:29] cool, thx! [11:30] ogra_: is it known that rocket chat isn't accepting anything on 80/3000 out of the box? [11:31] Perhaps an android type permission system would have been better, allow everything until an interface for restricting is implemented. [11:31] noonien: wouldn't that … what?? [11:34] Packaging apps that need minimal access to the system seems trivial, but packaging something that needs access to a wider set of system facilities seems rather impossible at this point, as far as I can tell. [11:35] noonien: then you write an interface, then another … there's only a finite number of interfaces to write. There are, however, a bazillion ways to get hacked on a traditional system with no security [11:36] I wonder how apps that support plugins are supposed to be packaged, considering some plugins might need interfaces that the app did not. [11:38] jgdx: I agree, however, from my point of view, because of the said restrictions, I would have to either invest time into creating interfaces, or drop snappy, the latter would provide me with even less security than what I proposed. [11:40] noonien: it doesn't get any clearer than that [11:41] if your app has an upstream way to handle these plugins already you just make sure they are used from one of the snap dirs and ship a tool to download and install them ... as long as the plugin doesnt need HW access you wont need interfaces, just handle it internally in the snap itself [11:43] the trick with snaps it to stop thinking in old packaging mechanisms, everything is possible, just different ;) [11:45] s/it/is/ [11:49] ogra_: if the snap already have hw acc, e.g. a .so in the common dir would also have access to it? [11:49] if it is in $SNAP_COMMON ? sure [11:50] okay good, thanks [11:50] jgdx, oh, and i totally missed your second ping, what ports would you like rocket to use ? [11:51] (and why) [11:55] ogra_: i'm not getting any response on the ports I try, so any, really. [11:55] well, its a web service [11:56] port 80 should definitely return some hhtp :) [11:56] *http [11:56] i agree, but it doesn't.. logs confirms it's running fine afaics [11:57] anyway, maybe the default web server is configured to use localhost as a host. Need to take a closer look [13:09] Good day, looking to see if having multiple default command is in the snap roadmap. [13:21] How would one support alternatives? For example, let's say an app relies on command "X", packaged by app X, however, app "X-but-better" also provides "X", how can my app use the X from "X-but-better"? [13:24] you don't :) [13:25] As far as I can tell, the only solution is to build every permutation of the app. [13:48] noonien: :) [14:50] noonien: out of curiosity, when would that ever be wanted? You have file level control during creation of a snap… [14:52] Well, for example, I was trying to package polybar, it depends on i3, however, I'd like to have the flexibility of using i3-gaps, and do not know if the communication protocol is completely compatible. [14:53] So I don't know if the polybar package should depend on i3 or i3-gaps. [15:04] sergiusens: morning! [17:44] ogra_: is snap installation possible on rasbian? === JanC_ is now known as JanC [19:05] I have been reading through the site, and the one thing I can't seem to find info on is how to get your snap into the channels. Is there a documented process? Review? Etc. [19:10] Bashfulrobot: to publish into a channel, you have to use the CLI (afaict) - its documented somewhere [19:11] for review, it seems like automated vetting (i've packaged one package and submitted to beta channel, so that's very small experience point) [19:12] jgdx, well, perhaps without any confinement enabled, not sure, but i guess even then the kernel will miss a lot [19:12] ogra_: okay [19:13] Bashfulrobot, just go to https://myapps.developer.ubuntu.com, log in and in the details page of your snap you can then select the channels you want it in [19:13] Bashfulrobot: ok, i checked my command history. i did: `snapcraft push `, followed by `snapcraft release ` [19:14] right, as oky said you can also use snapcraft release... [19:14] ogra_: the web UI was quite confusing to me and i could not see how to change channels its available in [19:14] maybe Bashfulrobot will have different experience (and i hope so) [19:15] you click on the revision on the left ... then there is a "Channels" on the right with a "Release" link ... if you click that there is a form with the list of possible channels and checkboxes next to them [19:16] Bashfulrobot: notice that to release to certain channels, your package has to be marked 'stable' or whatever the equivalent is. otherwise, edge / beta are the available channels [19:17] ogra_: awesome, thanks! [19:18] right, the stable channel only allows packages with strict confinement ... also note that "snap find" or the software center only operate on the stable channel [19:19] Oh! Just push it yourself and that is that. Great to know. [19:20] Is there a spot on the site that explains this? Was I a dumbass that missed this? === paperManu_ is now known as paperManu [23:17] @kyrofa @JohnAgosta I’m working on a time-sensitive embedded system project in which we’re attempting to use Ubuntu 16.04 (desktop or snappy) on an Intel Joule 570x (codename tuchuck) instead of Intel’s minimalistic Ostro linux. A pretty big deal-breaker problem is lack of support in 16.04 for the board’s 2 SPI ports and 2 UARTs. An answer on one of our AskUbuntu threads [23:17] thos37: No such command! [23:17] (http://askubuntu.com/questions/879580/spi-appears-broken-ubuntu-core-and-intel-joule) referenced this #channel and the channel logs (https://irclogs.ubuntu.com/2017/02/01/%23snappy.html#t18:25) referenced a private bug tracked at https://bugs.launchpad.net/tuchuck/+bug/1661067 This is a high priority issue for our project. Is there any possibility that I could have access to at least this bug and this tuchuck tracker channel? We can [23:17] offer significant quality technical feedback and testing on this issue if needed.