[07:29] <dholbach> good morning
[09:35] <JamesTait> Good morning all; happy Monday, and happy Learn Your Name In Morse Code Day! 😃
[10:57] <zyga> I've pushed some code related to the capability hook system
[10:58] <zyga> https://github.com/ubuntu-core/snappy/pull/310
[10:58]  * zyga now focuses on security again
[13:13] <kyrofa> Good morning
[14:02] <kyrofa> Grr... Anyone else having trouble getting into the weekly?
[14:03] <kyrofa> mvo, I see you're in there
[14:03] <kyrofa> It's telling me "It's taking too long to connect you to this video call." I could have told it that
[14:07] <kyrofa> sergiusens, I can't seem to be able to get into the weekly
[14:14] <sergiusens> kyrofa, yeah, it has just been cancelled, no one could
[14:14] <kyrofa> sergiusens, okay good
[14:14] <sergiusens> given the issue, I'm going to move today's standup a bit into the future
[14:14] <kyrofa> sergiusens, fine by me
[14:15] <sergiusens> my morning has been bad so far, landline and dsl died for a bit, then came back, no this meeting gets cancelled (for which I spend time prepping for), meh
[14:15]  * sergiusens plans on going for a run now
[14:15] <sergiusens> kyrofa, lets discuss with elopio then what he found for 1.x
[14:16] <kyrofa> sergiusens, ah, sorry man. Yeah go run. Sounds like a plan for the meeting
[14:16] <sergiusens> kyrofa, hey, you already reviewed it all? snap yaml?
[14:17] <kyrofa> sergiusens, yessir
[14:18] <kyrofa> sergiusens, my familiarity with the codebase is still obviously growing though, so I'm sure elopio's review will be more helpful
[14:19] <kyrofa> (I lack some context around these things)
[14:20] <kyrofa> sergiusens, though the changes reminded me of a question: when I throw exceptions in the plugin it turns into a nice error message and halts the process, which means you must have a catchall somewhere. However, when an exception is thrown in, say, wrap_exe the thing dies with an ugly stack trace. Where is that catchall?
[14:25] <sergiusens> kyrofa, wrap_exe in the new code base has a catch all
[14:25] <sergiusens> kyrofa, it is something I want to discuss though
[14:25] <sergiusens> it doesn't seem to be the best of approaches
[14:25] <kyrofa> sergiusens, alright we can put that on the docket as well
[14:26] <sergiusens> kyrofa, it's here now https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/main.py#L92
[14:27] <sergiusens> kyrofa, but I'd rather we only capture our own exceptions
[14:27] <kyrofa> sergiusens, and explicitly fail ourselves?
[14:27] <kyrofa> sergiusens, would certainly make actual errors easier to debug
[14:39] <sergiusens> kyrofa, I didn't go for a run
[14:39] <kyrofa> sergiusens, haha, you should!
[14:39] <sergiusens> kyrofa, lets try a hang out and go over it if you want
[14:39] <sergiusens> kyrofa, I would melt :-)
[14:39] <kyrofa> sergiusens, hahaha
[14:39] <kyrofa> sergiusens, alright let's do it. See if it works. Standup url
[14:40] <sergiusens> sun is too strong today; it had been overcast these past days so it wasn't a problem to do a noon run, a bit humid, but not too hot :-)
[14:41] <sergiusens> elopio, if you want to join even though I moved the standup, feel free to join
[14:41] <elopio> I'm confused :)
[14:41] <elopio> ahh, ok.
[15:00] <kyrofa> sergiusens, internet go down again?
[15:01] <elopio> sergiusens: one small detail I didn't mention. You wanted to get rid of the trusty pep8. I can split the static tests, and tell them to run only on the vivid/xenial lxc.
[15:05] <sergiusens> kyrofa, elopio internet is back, I should start calling it internetz though
[15:05] <sergiusens> that said, the handout is dead to me
[15:06] <sergiusens> but you may have already dropped
[15:06] <kyrofa> sergiusens, yeah we weren't sure how long you'd be out, so we dropped
[15:06] <sergiusens> kyrofa, that's fine
[15:06]  * zyga pushed the initial take on security
[15:06] <sergiusens> summary is we ave the green light to get 1.0 out
[15:06] <sergiusens> so lets do that
[15:06] <zyga> https://github.com/ubuntu-core/snappy/pull/312
[15:07] <kyrofa> sergiusens, agreed! I'd like to do it with you whenever you're ready
[15:07] <sergiusens> kyrofa, that said, a webcam with something to demo would be cool; I think olli would allow expensing
[15:08] <kyrofa> sergiusens, alright I'll see if I can throw something together :)
[15:15] <olli> sergiusens, kyrofa yep
[15:15] <olli> rickspencer3 also has an interest in that topic
[15:17] <rickspencer3> https://code.launchpad.net/~rick-rickspencer3/+junk/rest-cam
[15:18] <rickspencer3> I have a binary working that takes a shot, am now adding a rest api for it, and then will include a web page
[15:18] <kyrofa> rickspencer3, I'm going to try and throw a face detector together
[15:18] <rickspencer3> kyrofa, ok
[15:19] <rickspencer3> so, what I am trying to do is make a snap that provides the camera part for you, that you can access over local host
[15:19] <rickspencer3> so, you could do localhost:8082/api/photo and that will provide you a photo from the /dev/video0
[15:20] <rickspencer3> alternatively, you can just for my project and keep the binary that I have working there already
[15:20] <rickspencer3> (or you can do your own from scratch, of course, I'm just offering ;) )
[15:20] <tedg> jdstrand: Is there a list of capability names that are already defined, and their schemas? i.e. for things like networking.
[15:21] <kyrofa> Thanks rickspencer3, I'll check it out :)
[15:22] <zyga> tedg: nope
[15:22] <zyga> tedg: we haven't done that work yet
[15:23] <zyga> jdstrand: hey, do you have a moment, I'd to get your feedback on something
[15:24] <tedg> zyga: So then are snaps still having the security caps field in them?
[15:24] <zyga> tedg: I haven't changed the meta-data yet, we're still working on it
[15:25] <zyga> tedg: I'm pushing some code to github every day, have a look at that if you want
[15:25] <zyga> tedg: there are still a few things that need to land before we can start defining new capability types
[15:25] <sergiusens> zyga, did you seem my PR already? the one with the internal format?
[15:25] <tedg> zyga: Is there a document that says which caps you're headed to though? Or is it just entirely organic?
[15:26] <tedg> I mean, there has to be coordination with the security folks for instance.
[15:28] <zyga> sergiusens: no, not yet, do you have a pointer handy?
[15:29] <zyga> tedg: there's coordination and agreement on the design, actual capability types are not something we've looked at
[15:30] <jdstrand> tedg: is there a list of capabilities: yes, they were definied in Brazil. I implemented them, renaming some based on feedback from niemeyer on how things should be named and will seek his approval for them (planned to do that this week)
[15:31] <jdstrand> tedg: there is a command that can be used on a 1604 device to see them. let me get that for you
[15:31] <tedg> jdstrand: Cool
[15:31] <tedg> jdstrand: Where are they defined? In the snappy codebase?
[15:32] <jdstrand> they are defined in the ubuntu-core-security package that is part of the os snap
[15:32] <jdstrand> snappy install snappy-debug
[15:32] <jdstrand> snappy-debug.security list -i
[15:34] <zyga> jdstrand: can you please have a look at https://github.com/ubuntu-core/snappy/pull/312/files#diff-9cbf3db5a11d15acb53c4e907e03e558R24
[15:34] <zyga> jdstrand: I'd like to hang apparmor and seccomp delta generators from each capability type using that mechanism
[15:34] <jdstrand> let me send that email to niemeyer and CC you guys
[15:35] <zyga> jdstrand: k
[15:35] <zyga> jdstrand: specifically https://github.com/ubuntu-core/snappy/pull/312/files#diff-70fe37b72a9aa2d6bb98b9a35910a01cR39 adds this feature
[15:35] <jdstrand> then I read that. give me just a minute
[15:35] <jdstrand> I'll
[15:35] <zyga> jdstrand: thanks!
[15:38] <sergiusens> zyga, https://github.com/ubuntu-core/snapcraft/pull/215
[15:39] <sergiusens> kyrofa, heh, you found my little change on raise e
[15:40] <sergiusens> kyrofa, it is one of the reasons I mentioned that this strategy wasn't the best (one is nice for consuming, the other for developing)
[15:40] <sergiusens> this is missing an env flag
[15:40] <sergiusens> good catch!
[15:41] <sergiusens> oh, it was elopio who saw it :-P
[15:42] <kyrofa> sergiusens, haha, thanks for the props though
[15:43] <zyga> sergiusens: thanks!
[15:43] <zyga> sergiusens: ahh, I heard about this merge request :)
[15:44] <zyga> sergiusens: quick question before reading everything, are hooks copied automatically?
[15:45]  * jdstrand reads pull requests now
[15:47] <jdstrand> zyga: fyi, typo in legacySecurtySystem
[15:47] <jdstrand> should be legacySecuritySystem
[15:47] <sergiusens> zyga, well, it is declarative in snapcraft; it's a hook in the internal format
[15:48] <zyga> jdstrand: thanks, add a note so that I can fix it easily please
[15:53] <elopio> sergiusens: I'm not sure I'm understanding this meta_legacy. So in the end, the snap will have a snap.yaml and a pcakge.yaml?
[15:54] <sergiusens> elopio, yeah, until snappy fully grasps snap.yaml; once it does, we just rm meta_legacy.py and test_meta_legacy.py and remove on line of code in meta.py
[15:55] <sergiusens> elopio, https://bugs.launchpad.net/click-reviewers-tools/+bug/1532842
[15:56] <elopio> sergiusens: got it. On the first pass, the branch looks really good. The code looks nicer.
[15:56] <sergiusens> elopio, I took the opportunity to fix most of the code that I always said I'd fix later on :-)
[16:02] <jdstrand> zyga: ok, so I think this all looks fine. basically, you have a list of securitySystems. then, when granting or revoking permissions, you loop through your list of securitySystems and apply anything that the capability defined for that securitySystem (and fail atomically to avoid a half granted/revoked state)
[16:03] <jdstrand> zyga: today, you are focusing on hwaccess cause it is there, but (soon?) you'll add security capabilities and, additionally, move away from the hwaccess model
[16:04] <jdstrand> zyga: at that point, it can handle both something like 'firewall-management' which is a pure security capability, and something like 'camera' for hardware access
[16:07] <jdstrand> zyga: with hardware capability, we will support capability definitions that have lists of accesses, as opposed to just single file rules (ie, I want to define the 'foo' hw capability, so I can say '/dev/foo, some stuff in /sys/devices, this other thing, etc)
[16:07] <rickspencer3> sergiusens, so, I have a Golang project
[16:07] <jdstrand> zyga: does that summarize your direction?
[16:07] <rickspencer3> when I run snapcraft on it, it doesn't rebuild my Go code
[16:07] <rickspencer3> is there a switch I need to give snapcraft to make it rebuild?
[16:08] <davidcalle> kyrofa: sorry for the half-baked snapcraft pull request, it's my first time with git/github :)
[16:09] <sergiusens> rickspencer3, `clean`
[16:09] <rickspencer3> snapcraft clean? snapcraft -clean?
[16:09] <kyrofa> davidcalle, oh no worries, you're pretty much there, just missing the bug ref
[16:09] <sergiusens> rickspencer3, or if still on <1.0 `snapcraft build`
[16:10] <rickspencer3> sergiusens, how do I see which version I am on?
[16:10] <rickspencer3> I am in Xenial
[16:10] <sergiusens> rickspencer3, `snapcraft clean`
[16:10] <rickspencer3> in classic
[16:10] <sergiusens> rickspencer3, you will only have more than 1.0 if working from trunk
[16:10] <kyrofa> rickspencer3, if you're not running from source you're < 1.0
[16:10] <rickspencer3> ok
[16:10] <rickspencer3> so, after clean, you just run snapcraft again?
[16:10] <sergiusens> rickspencer3, our release plan is to release 1.0 today to everything; then 2.0 with all the breaking changes only and only to xenial
[16:10] <rickspencer3> hmmm
[16:10] <rickspencer3> ok
[16:11] <rickspencer3> sergiusens, it is rebuilding a bunch of things that didn't change
[16:11] <rickspencer3> I only changed one .go file
[16:12] <sergiusens> rickspencer3, yeah; I can't start complaining enough with the inconsistencies of some of this logic which is why we made it all go away in 2.x and going to engineer something better
[16:12] <rickspencer3> ok
[16:12] <sergiusens> rickspencer3, clean is like running 'make clean' it makes everything go away
[16:12] <rickspencer3> yeah
[16:12] <rickspencer3> I want "rebuild what changed"
[16:13] <zyga> jdstrand: yes, that's about right
[16:13] <rickspencer3> I guess I could be more surgical about rm'ing things from the stage and snap dirs
[16:13] <sergiusens> `snapcraft build [partname]` can build what you already built for a specific part but it really has a bunch of unworking corner cases
[16:13] <zyga> jdstrand: I'll try to post initial apparmor work tomorrow
[16:13] <zyga> jdstrand: to show you how we can stop using hwaccess and use entirely the new thing
[16:14] <jdstrand> great
[16:14] <sergiusens> kyrofa, btw, lets not throw away your lamp work and get it into the wiki and have that as an example (eventually)
[16:15]  * rickspencer3 is dangerously close to having his rest-cam snap working
[16:15] <kyrofa> sergiusens, agreed
[16:15] <kyrofa> sergiusens, it's a deliciously complex example
[16:25] <bellyfeel> is there a way to build a snap without downloading and installing the dependencies on my dev machine?
[16:29] <rickspencer3> bellyfeel, yes, you can build on your device in the classic shell
[16:34] <bellyfeel> rickspencer3: could you elaborate?
[16:36] <rickspencer3> bellyfeel, so, I am writing a snap right now, without having the dependencies on my local machine
[16:36] <rickspencer3> what I do is I edit on my desktop
[16:36] <rickspencer3> then I push to my bzr branch
[16:36] <rickspencer3> then, on my rpi2 I run snappy classic
[16:36] <rickspencer3> and use snapcraft inside classic to build the snap
[16:37] <rickspencer3> snapcraft takes care of putting all of my dependencies together for me
[16:37] <rickspencer3> then, I just exit classic and install the snap to try it
[16:38] <bellyfeel> forgive me, what do you mean by classic?
[16:45] <rickspencer3> bellyfeel, so, if you get a very recent image
[16:45] <rickspencer3> you can enable something called "classic dimension"
[16:46] <rickspencer3> in there, you can use tools like snapcraft
[16:46] <rickspencer3> and thus, build on your device instead of your desktop
[16:46] <bellyfeel> Okay, nice. My image is from over the summer...
[16:48] <rickspencer3> bellyfeel, oooh
[16:49] <rickspencer3> yeah, you will find that snappy has changed some
[16:49] <rickspencer3> and is much easier to use now
[16:49] <rickspencer3> a lot of rough edges sanded off
[16:49] <bellyfeel> sounds great, thanks for the help!
[16:50]  * rickspencer3 proclaims that is web-cam snap kicks all other web-cam snaps in the a**
[16:53] <rickspencer3> jdstrand, so let's say I want to find out from within my snap if a web cam is ready
[16:53] <rickspencer3> so I can report status
[16:53] <rickspencer3> like, test if one is connected
[16:54] <rickspencer3> what would you suggest?
[16:54] <rickspencer3> it will be from within a service, so it will have root
[16:56] <jdstrand> rickspencer3: try to open the device and check the return code. if it failed, log something to stderr (which will show up in 'snappy service logs foo'
[16:56] <rickspencer3> jdstrand, well, my goal is to return this over the web
[16:56] <rickspencer3> so, I need to capture the results in my Go code
[16:57] <jdstrand> is the service a web service?
[16:57] <rickspencer3> jdstrand, yes
[16:57] <rickspencer3> but I can run shell commands from in it
[16:57] <jdstrand> is it the one that would be doing the camera access in the normal case?
[16:57] <rickspencer3> yes
[16:57] <rickspencer3> it already is
[16:57] <rickspencer3> I just want to have an api call to get the status
[16:57] <rickspencer3> so, you could write a smarter program
[16:58] <jdstrand> ok, right, so have it try to open the camera-- if that fails, report that back to the user that it doesn't have access to a camera
[16:58] <rickspencer3> jdstrand, can you give me a hint about a good shell command to try to open the camera?
[16:58] <jdstrand> you could put that in a loop if you wanted (perhaps trying every 10 seconds, failing after 5 minutes (or something))
[16:58] <rickspencer3> jdstrand, well, it's on demand
[16:58] <rickspencer3> easier that way ;)
[16:59] <jdstrand> you could when the user clicks on the web interface to take a picture check the return code of that
[17:00] <jdstrand> 'that' meaning the service trying to take a picture but unable to
[17:01] <jdstrand> in the future capabilities world, there might be a callback when the hardware is assigned (not sure if that is something zyga is thinking about)
[17:02] <jdstrand> let me see about a shell command if you want to know up front
[17:11] <jdstrand> rickspencer3: as for an api command to query the status, I don't know of a simple shell command. it sounds like you have a screengrab command. you could use that to try to do a screen grab, throwing away the picture if it was successful, and checking the error code if it was not
[17:12] <rickspencer3> jdstrand, yeah, or I wonder if I can just tell fswebcam to do something, and see if it works
[17:12] <rickspencer3> I'll figure something out
[17:16] <elopio> huh, interesting discussion about packaging: https://lwn.net/Articles/670754/
[17:56] <LefterisJP> Hey all. Got some questions about framework development. I am developing an Ubunt-Core framework that should always run a specific daemon on the background. Apps that use this framework only need to be able to contact this daemon via JSON-RPC (in the non-ubuntucore world)
[17:57] <LefterisJP> Now for the framework what should be done to achieve the same? Make a dbus service inside the framework that would be listening for events from other apps and then translate those events to JSON rpc calls to the daemon that is running inside the framework?
[17:57] <LefterisJP> Are there any nice framework examples for ubuntu-core to look at?
[18:14] <kyrofa> sergiusens, alright, ready to continue when you get back
[18:15] <sergiusens> kyrofa, yeah, one lets hop back onto the hangout in 5, sound good?
[18:15] <kyrofa> sergiusens, sounds good
[18:21] <bellyfeel> how do I enter the classic dimension
[18:22] <sergiusens> kyrofa, in
[18:54] <kyrofa> davidcalle, on your snapcraft PR, the commit message needs to contain the LP: #blah bit
[18:58] <kyrofa> (your PR description and title were fine)
[18:59] <jerryG> Chipaca: hi. hows it going?
[19:16] <jerryG> kyrofa: hello. is there any mir example other than deb2snap with qt?
[19:21] <jerryG> :{
[19:21] <kyrofa> jerryG, not that I know of
[19:21] <kyrofa> jerryG, might be a question for kgunn
[19:22] <jerryG> kgunn: is there any mir example other than deb2snap with qt?
[19:54] <kgunn> jerryG: so, before i dive into a convoluted answer, can i ask what your purpose is? like what are you trying to achieve/
[19:54] <kgunn> ?
[19:59] <pindonga> kyrofa, sergiusens q: for my PR for snapcraft I need to introduce a new dependency, so I packaged it up for xenial, only to find out now that travis runs tests on trusty
[19:59] <kyrofa> pindonga, heh, indeed it does
[19:59] <pindonga> what should I do? get this ported to trusty-backports?
[20:00] <kyrofa> elopio, ^^ is probably a better question for you
[20:00] <pindonga> would it be ok to vendorize this dependency?
[20:00] <elopio> pindonga: wait for it.....
[20:00] <elopio> ...
[20:01] <elopio> pindonga: https://github.com/ubuntu-core/snapcraft/pull/202
[20:01] <pindonga> kyrofa, or install the deps via pip? (though the snapcraft pkg would probably need to have the dep as a deb paackage too)
[20:01] <pindonga> elopio, nice!
[20:01] <pindonga> and just in time too :)
[20:02]  * pindonga can wait for this to land
[20:02] <pindonga> kyrofa, elopio in the meantime, here's the PR: https://github.com/ubuntu-core/snapcraft/pull/197
[20:02] <sergiusens> pindonga, if you want to make the necessary changes in a PR to have everything done in travis through pip I will indeed welcome that
[20:03] <elopio> kyrofa: how do I merge my branch with master? Do I squash the result, or something?
[20:03] <sergiusens> pindonga, btw, I'm not sure beuno has synced with you with regards to the concept of 'grade' in snapcraft.yaml which might be nice to have (or getting a snap-id on first upload)
[20:03] <kyrofa> elopio, yeah you can merge then squash, but rebasing is easier
[20:04] <pindonga> sergiusens, tell me more
[20:04] <sergiusens> elopio, git rebase -i master (standing on your branch)
[20:04] <sergiusens> pindonga, I was hoping to have beuno take upon that task :-)
[20:04] <pindonga> ok, I don't think he has yet
[20:04] <kyrofa> elopio, the -i is "interactive." You only really need it if you want to alter specific commits (e.g. squashing)
[20:05] <sergiusens> pindonga, grade in snapcraft is just information; the store and ubuntu core themselve have different logic depending on that
[20:05] <sergiusens> pindonga, snap-id is a uuid which gets assigned by the store on first upload since name is only 'informational' or a desire of intent
[20:06] <sergiusens> pindonga, of course there might be a roadmap to this and maybe this is fine, just want to make sure we have a clear road to traverse
[20:06] <jerryG> kgunn:  I'm trying to get an app working that uses MIR in snappy stable.
[20:06] <jerryG> kgunn:  using snapcraft
[20:06] <pindonga> sergiusens, yeah, not sure where it stands
[20:06] <bellyfeel> how do I enter the classic dimension?
[20:06] <pindonga> I was working to get the upload bit done and then probably switching tasks
[20:07] <beuno> pindonga, grade is an easy one
[20:07] <jerryG> kgunn:  I'm also trying to get a 'test' app running so I can confirm mir should work
[20:07] <beuno> pindonga, stable or unstable, they stop it from getting published to the wrong channel
[20:07] <beuno> stable = stale & candidate
[20:07] <kgunn> jerryG: when you say snappy stable you mean xenial?
[20:07] <beuno> unstable = edge & beta
[20:07] <sergiusens> kyrofa, 1.0 ANN is out
[20:08] <jerryG> kgunn: stable and edge are the two listed here :https://developer.ubuntu.com/en/snappy/start/
[20:09] <jerryG> kgunn:  do you have examples for a different channel?
[20:09] <kgunn> brb
[20:09] <jerryG> kgunn: k
[20:10] <kyrofa> sergiusens, thanks! :)
[20:13] <sergiusens> elopio, btw, do you plan to move us to testtools? :-)
[20:13] <elopio> sergiusens: probably. We already need them for the examples and integration tests.
[20:13] <elopio> sergiusens: would you like that we use it for the unit tests too?
[20:14] <sergiusens> elopio, yeah, I love it
[20:14] <sergiusens> I just kept with the status quo
[20:15] <elopio> sergiusens: great then. We just need to move it to the build dependencies.
[20:15] <elopio> sergiusens: I don't understand why do you want to use pip instead of apt. We can't use pip to build the package, right?
[20:16] <sergiusens> elopio, no, we can't; but I don't want to use trusty packages either
[20:16] <pindonga> elopio, right, pip would only work for the pure python pkg, not for the deb pkg
[20:16] <sergiusens> it does make it easier for people wanting to venv as well
[20:17] <sergiusens> elopio, so the snap_yaml branch is good to land?
[20:17] <sergiusens> just triple checking
[20:18] <sergiusens> I can wait, but I have no plans to change any code in there anymore
[20:19] <elopio> sergiusens: let me just double check I understand everything. Once you land this, the snaps build with snapcraft won't work on snappy until they update the format expected too?
[20:19] <sergiusens> elopio, everything keeps working
[20:19] <sergiusens> elopio, thanks to the fact we still create package.yaml and readme.md
[20:20] <elopio> sergiusens: okay, so go for it whenever you want.
[20:20] <elopio> I hope that before removing those we will have the install and run tests ready, so things will break if somebody does something wrong.
[20:22]  * elopio goes to have lunch and to cry listening to david bowie.
[20:30] <kgunn> jerryG: so the most simple answer is 15.04 core only has the deb2snap mir example, and i've only been focused on what we're going to do with xenial...
[20:31] <kgunn> also, there are some changes underway wrt frameworks for xenial, so even what i currently have i really don't want to publicize as it'll just end up changing in the end
[20:32] <LefterisJP> hey all, my questions seem to have gotten no reply so will post them again.
[20:32] <LefterisJP> I am developing an Ubuntu-Core framework that should always run a specific daemon on the background. Apps that use this daemon only need to be able to contact to it via local JSON-RPC calls(in the non-ubuntucore world)
[20:32] <LefterisJP> Now for the framework what should be done to achieve the same thing? Make a dbus service inside the framework that would be listening for events from other apps and then translate those events to JSON rpc calls to the daemon that is running inside the framework?
[20:32] <LefterisJP> Are there any nice framework examples for ubuntu-core to look at? Is DBUS the only way for apps to interact with a framework?
[20:35] <kyrofa> sergiusens, so shall I go through and set fix released on all those bugs?
[20:35] <kyrofa> sergiusens, the 1.0 ones, anyway
[20:41] <sergiusens> kyrofa, sure
[20:41] <sergiusens> kyrofa, and thanks
[20:48] <bellyfeel> how do I enter the classic dimension?
[20:53] <kgunn> bellyfeel: on the mail list snappy-devel@lists.ubuntu.com, there is a thread "classic mode (v1)" you might wanna read
[20:55]  * sergiusens is off to aikido practice
[20:55] <sergiusens> bbl
[20:57] <rickspencer3> jdstrand, slangasek due to your suggestion, I am about to delete like 10 terrible lines of code and replace it with one good one
[20:57] <rickspencer3> bellyfeel, first, you need to enable it, I think the command might be snappy enable classic (or similar)
[20:57] <rickspencer3> and then you enter it with snappy shell classic
[20:59] <bellyfeel> my image (edge) doesn't like the command "sudo snappy enable-classic" -- it gives an uknown command response
[21:00] <kyrofa> sergiusens, so is there any way on 1.x to have a forking service?
[21:01] <bellyfeel> there's a thread on askubuntu saying that the 16.04 LTS will have the classic dimension, I only have 15.04
[21:01] <jdstrand> rickspencer3: nice :)
[21:01] <rickspencer3> bellyfeel, right, like I said, you need a recent image
[21:01] <bellyfeel> yea it's from today
[21:01] <rickspencer3> oh, you need a recent 16.04 image
[21:03] <bellyfeel> I'm not sure where to get a 16.04 image, there's only 15.04 posted
[21:06] <rickspencer3> hmmm
[21:12] <rickspencer3> jdstrand, so, that means I implemented that feature already
[21:12]  * rickspencer3 brushes dirt from hands
[21:13] <bellyfeel> rickspencer3, so my next question is... where can I find the 16.04 image?
[21:13] <rickspencer3> bellyfeel, I'm not sure
[21:13] <rickspencer3> I'm wondering if I sent you on a snipe hunt because it is not released yet
[21:14] <rickspencer3> I don't see mvo online
[21:14] <rickspencer3> bellyfeel, was there a link in the thread that kgunn linked you to
[21:14] <rickspencer3> ?
[21:16] <bellyfeel> nope, just info on how to enable it
[21:20] <rickspencer3> bellyfeel, so, on 15.04, I think the best way to build on the device is by using lxc
[21:20] <rickspencer3> but classic on 16.04 is much easier
[21:20] <rickspencer3> hopefully someone who knows where to get the image soon will let you know
[22:55] <jerryG> kgunn: I'm just trying to get a proof of concept to work.  Can I see what you have for xenial?
[22:59] <jerryG> kgunn:  do you know of any1 that is using mir on stable?
[23:00] <LefterisJP> Anyone knows if a framework's service's can be contacted with in ways other than DBUS? I am trying to turn a daemon which uses jsonrpc over a local http port into a snappy framework.
[23:08] <kgunn> jerryG: i know darren landol (unsure irc nick) was doing something with mir on 15.04 using what was in the store
[23:08] <kgunn> not sure exactly what
[23:09] <kgunn> jerryG: for xenial, things are in flux, if you just want to see something run on top of mir there is this ~mir-team/+junk/snapcraft-qml-on-mir
[23:09] <kgunn> but as i stated, it's not intented for using on a product of any sort, and it will change
[23:11] <jerryG> kgunn: k thx
[23:17] <enoch85> kyrofa, hey mate, what about working on the snap tomorrow? my schedule is cleared.