[00:38] <noonien> How can one tell what interfaces a snap needs?
[00:38] <noonien> I'm guessing there's no way of knowing, not even at runtime
[02:15] <jamesh> noonien: "snap interfaces" should tell you
[02:15] <jamesh> "snap interfaces $snap_name" will limit it to just a particular named snap
[05:21] <amosbird> hello
[05:21] <amosbird> can I use snap in centos 6?
[09:23] <noonien> jamesh: I'm creating a snap of an app of which I don't know everything about
[09:23] <noonien> And would like to know what interfaces said app needs
[09:48] <noonien> 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] <noonien> It gets denied by apparmor
[09:48] <noonien> the snap gets listed under home in `snap interfaces`
[11:23] <ogra_> noonien, dont forget that the home interface will not allow access to hidden dirs (for security reasons)
[11:27] <noonien> Yes, I know. It was not a hidden directory
[11:27] <jgdx> ogra_: is wlan expected to work on pi3? i get a timeout. Ethernet works fine.
[11:28] <jgdx> also, are there any instructions on how to set up wlan on a running core?
[11:28] <noonien> 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] <ogra_> jdstrand, only if you fist configure it with wired ... there is a driver bug ...
[11:28] <ogra_> bah
[11:28] <jgdx> :)
[11:28] <ogra_> jgdx,
[11:29] <ogra_> 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] <jgdx> cool, thx!
[11:30] <jgdx> ogra_: is it known that rocket chat isn't accepting anything on 80/3000 out of the box?
[11:31] <noonien> Perhaps an android type permission system would have been better, allow everything until an interface for restricting is implemented.
[11:31] <jgdx> noonien: wouldn't that … what??
[11:34] <noonien> 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] <jgdx> 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] <noonien> 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] <noonien> 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] <jgdx> noonien: it doesn't get any clearer than that
[11:41] <ogra_> 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] <ogra_> the trick with snaps it to stop thinking in old packaging mechanisms, everything is possible, just different ;)
[11:45] <ogra_> s/it/is/
[11:49] <jgdx> ogra_: if the snap already have hw acc, e.g. a .so in the common dir would also have access to it?
[11:49] <ogra_> if it is in $SNAP_COMMON ? sure
[11:50] <jgdx> okay good, thanks
[11:50] <ogra_> jgdx, oh, and i totally missed your second ping, what ports would you like rocket to use ?
[11:51] <ogra_> (and why)
[11:55] <jgdx> ogra_: i'm not getting any response on the ports I try, so any, really.
[11:55] <ogra_> well, its a web service
[11:56] <ogra_> port 80 should definitely return some hhtp :)
[11:56] <ogra_> *http
[11:56] <jgdx> i agree, but it doesn't.. logs confirms it's running fine afaics
[11:57] <jgdx> anyway, maybe the default web server is configured to use localhost as a host. Need to take a closer look
[13:09] <Cyrus104> Good day, looking to see if having multiple default command is in the snap roadmap.
[13:21] <noonien> 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] <Son_Goku> you don't :)
[13:25] <noonien> As far as I can tell, the only solution is to build every permutation of the app.
[13:48] <Son_Goku> noonien: :)
[14:50] <jgdx> noonien: out of curiosity, when would that ever be wanted? You have file level control during creation of a snap…
[14:52] <noonien> 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] <noonien> So I don't know if the polybar package should depend on i3 or i3-gaps.
[15:04] <Son_Goku> sergiusens: morning!
[17:44] <jgdx> ogra_: is snap installation possible on rasbian?
[19:05] <Bashfulrobot> 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] <oky> Bashfulrobot: to publish into a channel, you have to use the CLI (afaict) - its documented somewhere
[19:11] <oky> 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] <ogra_> jgdx, well, perhaps without any confinement enabled, not sure, but i guess even then the kernel will miss a lot
[19:12] <jgdx> ogra_: okay
[19:13] <ogra_> 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] <oky> Bashfulrobot: ok, i checked my command history. i did: `snapcraft push <package_file.snap>`, followed by `snapcraft release <package> <ver> <channel>`
[19:14] <ogra_> right, as oky said you can also use snapcraft release...
[19:14] <oky> ogra_: the web UI was quite confusing to me and i could not see how to change channels its available in
[19:14] <oky> maybe Bashfulrobot will have different experience (and i hope so)
[19:15] <ogra_> 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] <oky> 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] <oky> ogra_: awesome, thanks!
[19:18] <ogra_> 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] <Bashfulrobot> Oh! Just push it yourself and that is that. Great to know.
[19:20] <Bashfulrobot> Is there a spot on the site that explains this? Was I a dumbass that missed this?
[23:17] <thos37> @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] <nothal> thos37: No such command!
[23:17] <thos37> (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] <thos37> offer significant quality technical feedback and testing on this issue if needed.