[02:14] <mjs7231> Hey guys, I'm having trouble creating a snap that uses Gtk.  It seems everything is working fine, but when I try to run my Python script, I get "ValueError: Namespace Gtk not available"
[02:15] <mjs7231> I'm probably missing a dependency, I tried gir1.2-gtk-3.0, gobject-introspection, and libgtk-3-0 -- nothing works.
=== chihchun_afk is now known as chihchun
[05:52] <Mikaela> Is there anything like apt:url for snaps?
[09:09] <zyga> o/
=== JanC is now known as Guest47278
=== JanC_ is now known as JanC
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[15:41] <sborovkov> Hi. Couple of questions about new security - is there a way now to say run root commands from snap? Particularly reboot. Also RPI specific - how would it be possible to be able to change config.txt which is a part of gadget snap from another snap?
[20:00] <jdstrand> Trevinho: hi! did you happen to get hello-unity working?
[20:01] <jdstrand> Trevinho: fyi, for the launcher API: https://github.com/ubuntu-core/snappy/pull/1173
[20:01] <Trevinho> jdstrand: yeah...
[20:01] <Trevinho> jdstrand: I mean, I got the hello unity thing working
[20:01] <Trevinho> jdstrand: I wanted to push it, but I've not done it yet
[20:01] <Trevinho> jdstrand: I'll do that in a bit
[20:02] <jdstrand> Trevinho: thanks!
[20:04] <Trevinho> jdstrand: do you happen to know why gtk apps get the anonymous path?
[20:04] <Trevinho> jdstrand: it should be appid...
[20:04] <Trevinho> That's something we also noticed at the desktop sprint
[20:04] <jdstrand> no idea
[20:07] <Trevinho> jdstrand: the only thing I don't get working in hello unity is the indicator icon... I didn't debug that much yet, though... But I believe it's libappindicator not being able to locate the icon (although I've all the caches set)
[20:18] <jdstrand> Trevinho: intersting. If you want to commit what you have, I can verify what you have so far
[20:19] <Trevinho> jdstrand: yeah, give me 10 minutes, since I've done that in a VM which is in a different machine from the one I'm on right now :)
[20:21] <jdstrand> np, thanks again
[20:21] <Kristbaum> Hello, is this the right place if I have questions about snappy?
[20:22] <jdstrand> Kristbaum: yes
[20:24] <Kristbaum> Okay thanks ;) I wanted to know what the "home" slot in "snappy interfaces" is about. I coudn't find anything elsewhere..
[20:25] <jdstrand> Kristbaum: the docs are being worked on and are a bit behind atm on the website. You can see this though: https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md
[20:28] <Kristbaum> Ah thanks, so if I enable the "home" slot in the .yaml file, what happens if a user tries to install it?
[20:29] <jdstrand> the interface is not (currently) autoconnected, so the access is denied
[20:29] <Kristbaum> Can a User enable it?
[20:30] <Kristbaum> with snap connect?
[20:30] <jdstrand> the user would then need to do something like: snap connect <you snap name>:home ubuntu-core:home
[20:31] <Kristbaum> But support for autoconnect is planned?
[20:31] <jdstrand> autoconnect is there now
[20:32] <jdstrand> it is explicitly set to not autoconnect
[20:32] <jdstrand> aiui, the gadget snap would make that auto-connectable
[20:32] <jdstrand> also, future snap assertions might make then autoconnect depending on how the store is set up (that is planned)
[20:33] <jdstrand> them*
[20:33] <jdstrand> also, tooling might improve to assist with connecting
[20:34] <zyga> jdstrand: o/
[20:34] <Kristbaum> Ah, so maybe in the future, there may be a Dialogue where the User decides if he want's to enable access tho his/her homefolder?
[20:34] <zyga> jdstrand: I was off today, sorry for not realizing this earlier
[20:34] <jdstrand> Kristbaum: it's conceivable
[20:34] <jdstrand> hey zyga :)
[20:35] <jdstrand> zyga: if you're off, why are you here now?
[20:35] <ogra_> jetlaggers paradise ;)
[20:35] <zyga> jdstrand: just talking to slangasek about a missed meeting
[20:36] <jdstrand> Kristbaum: you might be interested in https://insights.ubuntu.com/2016/05/04/security-confinement-in-ubuntu-core/
[20:36] <zyga> jdstrand: ohh, published now!
[20:36] <zyga> jdstrand: cool
[20:36] <jdstrand> zyga: that's niemeyer's blog post from a little while ago
[20:36] <jdstrand> not the whitepaper
[20:36] <zyga> ahh, too bad :)
[20:37] <zyga> I look forward for the whitepaper
[20:37] <jdstrand> Kristbaum: there is also http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
[20:38] <jdstrand> zyga: it will be nice to have up. I think it is in the community team's court at this point
[20:38] <Kristbaum> jdstrand: Thanks for this ;) How exactly are the snaps on desktop Ubuntu updated at the moment? Do I have to hit refresh on ervery app?
[20:40] <ogra_> there used to be an autorefresh feature, that was disabled and i currently re-worked
[20:40] <ogra_> it will return eventually
[20:41] <ogra_> (currently you have to use snap refresh)
[20:44] <Kristbaum> Interesting. Do you know anything about how source code will be managed in the snappy store? Are there considerations on this? (In the sense of "apt source")
[20:47] <ogra_> no, snaps are purely binary
[20:48] <ogra_> you woud just host your code on github or wherever and aadd a snapcraft.yaml to the tree
[20:49] <Kristbaum> Isn't this a Problem when you want a trusted, reproducable build?
[20:49] <ogra_> why would you ?
[20:50] <ogra_> the esssence of a snap is that it can be competely untrusted thanks to the confinement and the entry checks in the store
[20:50] <Kristbaum> If, for example, I use a FIrefox snap to to 90% of my work, how do I know that the snap  is really only the sourcecode from Mozilla, not anything else.
[20:50] <Kristbaum> ?
[20:51] <ogra_> you cant ...
[20:51] <ogra_> i mean ... iit is likely that it is unmodified if mozilla uploaded it to the store ... but there is no guarantee
[20:52] <Kristbaum> Yeah, but isn't this a problem, or am I seeing this wrong?
[20:52] <ogra_> and effectively it does not matter ... since you have to decide what you allow to that snap
[20:54] <Kristbaum> But I do need to trust Firefox, because my work is in it, not in the Rest of the System. And if i can't check if it's really Firefox, how does this help me?
[20:55] <ogra_> how do you know it today ?
[20:57] <jdstrand> Kristbaum: that gets into the assertions stuff I referenced earlier
[20:57] <Kristbaum> I guess I trust the Debian/Ubuntu Developers that took the source and put it in the repo, or I type apt source and check it myself.
[20:58] <jdstrand> Kristbaum: the idea is that you'll be able to be confident that a snap comes from a particular publisher (eg mozilla). assertions have crypto the ensures that and that crypto could be used to verify your installed snap
[20:58] <jdstrand> Kristbaum: that does not guaratee that the publisher built the snap from their source trees
[20:58] <Trevinho> jdstrand: sorry for the delay, i'm pushing the thing soon... but i've just noticed that I've lost some of the things I was working on (damn me and staing on tmp), so... let me check i can get them back
[20:59] <jdstrand> Kristbaum: Launchpad will grow functionality to build snaps, similar to ppas today, that can be triggered off source uploads. some of that is already in place
[20:59] <ogra_> it already has it
[21:00] <jdstrand> yes, but not autouploads to the store
[21:00] <ogra_> as a button for a tree though ...
[21:01] <Kristbaum> Oke, this isn't bad, so I can at least trust, it's from Mozilla. And will these Launchpad snaps be marked, so I know I can check the source if I want, and they directly are build from this source?
[21:01] <Kristbaum> jdstrand: ^
[21:02] <jdstrand> I'm not up on those details. Immediately you could download the snap from Launchpad, generate a hash of the file and compare that to what is on your system
[21:03] <jdstrand> I know source builds are something that is desired; I just don't know how they tie into assertions
[21:05] <Kristbaum> Ok, but it isn't on the roadmap yet? You would get a lot of "free-software-street-cred" if you implement this, I would presume. :D
[21:06] <jdstrand> it is on the roadmap, I just don't know the plans
[21:07] <jdstrand> Kristbaum: you might ask on the list-- you'll get more authoritative answers :)
[21:07] <jdstrand> I think a lot of people are off today
[21:08] <ogra_> at least we pretend to :)
[21:09] <Kristbaum> Thanks, you helped me a lot ;) ! Very nice talking to you, I'll be off then, good night!
[21:24] <qengho> jdstrand: it would be kind of cool to have reproducible builds and ship a snapcraft.yaml if it came from that.
[21:25] <qengho> Ask user at upload time.
[21:25] <qengho> Ask publisher, that is.
[21:26] <jdstrand> I would love reproducible builds
[21:33] <niemeyer> jdstrand, zyga: We need to work on a disc-drive interface of sorts, soonish..
[21:43] <jdstrand> niemeyer: I have no details on that. can you file a bug?
[21:43] <jdstrand> (with the snapd-interface tag of course :)
=== blr_ is now known as blr
[22:43] <niemeyer> jdstrand: Will do, although I don't have many details either ;)
[22:44] <mhall119> sergiusens: where can I find the snapcraft.yaml for your telegram snap?
[22:44] <niemeyer> jdstrand: The idea is just enabling applications that want /dev/cdrom etc
[22:44] <niemeyer> mhall119: Under his GH username
[22:45] <niemeyer> sergiusens/telegram-snap
[22:51] <mhall119> thanks niemeyer