| 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 | 00:38 |
| jamesh | noonien: "snap interfaces" should tell you | 02:15 |
| jamesh | "snap interfaces $snap_name" will limit it to just a particular named snap | 02:15 |
| === markusfluer1 is now known as markusfluer | ||
| amosbird | hello | 05:21 |
| amosbird | can I use snap in centos 6? | 05:21 |
| 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:23 |
| 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` | 09:48 |
| ogra_ | noonien, dont forget that the home interface will not allow access to hidden dirs (for security reasons) | 11:23 |
| 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:27 |
| 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:28 |
| 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:29 |
| jgdx | ogra_: is it known that rocket chat isn't accepting anything on 80/3000 out of the box? | 11:30 |
| 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:31 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| jgdx | noonien: it doesn't get any clearer than that | 11:40 |
| 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:41 |
| ogra_ | the trick with snaps it to stop thinking in old packaging mechanisms, everything is possible, just different ;) | 11:43 |
| ogra_ | s/it/is/ | 11:45 |
| 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:49 |
| 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:50 |
| ogra_ | (and why) | 11:51 |
| 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:55 |
| 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:56 |
| jgdx | anyway, maybe the default web server is configured to use localhost as a host. Need to take a closer look | 11:57 |
| Cyrus104 | Good day, looking to see if having multiple default command is in the snap roadmap. | 13:09 |
| 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:21 |
| Son_Goku | you don't :) | 13:24 |
| noonien | As far as I can tell, the only solution is to build every permutation of the app. | 13:25 |
| Son_Goku | noonien: :) | 13:48 |
| jgdx | noonien: out of curiosity, when would that ever be wanted? You have file level control during creation of a snap… | 14:50 |
| 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:52 |
| noonien | So I don't know if the polybar package should depend on i3 or i3-gaps. | 14:53 |
| Son_Goku | sergiusens: morning! | 15:04 |
| jgdx | ogra_: is snap installation possible on rasbian? | 17:44 |
| === JanC_ is now known as JanC | ||
| 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:05 |
| oky | Bashfulrobot: to publish into a channel, you have to use the CLI (afaict) - its documented somewhere | 19:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| oky | ogra_: awesome, thanks! | 19:17 |
| 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:18 |
| Bashfulrobot | Oh! Just push it yourself and that is that. Great to know. | 19:19 |
| Bashfulrobot | Is there a spot on the site that explains this? Was I a dumbass that missed this? | 19:20 |
| === paperManu_ is now known as paperManu | ||
| 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. | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!