[07:10] <dholbach> good morning
[07:11] <fgimenez> good morning dholbach and all
[07:12] <dholbach> hey fgimenez
[09:08] <JamesTait> Good morning all; happy Ingersoll Day! 😃
[11:55] <dholbach> ogra_, somebody in our shared office ordered a spreedbox :)
[11:55] <ogra_> dholbach, wheee !
[11:55] <ogra_> still ~2000€ missing ...
[15:04] <elopio> fgimenez: https://github.com/elgris/check/commit/45ed7de654751f962e5c6d493a18933dcea604ec
[15:04] <elopio> making an outputWriter interface seems like a good upstream step
[15:12] <fgimenez> elopio, yep very good approach, in that case we would need to control the gocheck output, no skips on reboot
[15:24] <ogra_> sergiusens, lol, i just noticed your trello comment ... do you think it makes sense to still split the card even when everything is implemented (uboot that is) ?
[15:25] <sergiusens> ogra_: oh, well not everything is ticked
[15:25] <ogra_> documentation mainly
[15:25] <sergiusens> ogra_: if everything is ticked, just migrate it (tick it as well)
[15:26] <sergiusens> ogra_: as a general practice, it's good to not keep the unknowns and knowns together, that's all ;-)
[15:28] <ogra_> i commented
[16:49] <john-mcaleely> ogra_, where do i look for details of how bluetooth might work on snappy systems today?
[16:50] <john-mcaleely> I assume its not 'in the box'
[16:50] <john-mcaleely> so I'm wondering if there are devices/projects which have chosen to add it yet?
[16:50] <ogra_> heh, in someones dream compartment in his head i guess :)
[16:50] <ogra_> we will need a BT framework that doesnt exist yet
[16:50] <john-mcaleely> right
[16:51] <john-mcaleely> so, in a one-snap-to-include-everything model, there's still work, right?
[16:51] <ogra_> not sure how much lool has planned the architectural bits for this yet
[16:51] <john-mcaleely> because apparmor confinement, etc
[16:51] <john-mcaleely> mm
[16:51] <ogra_> it wont be a one-snap-include-everything i suspect
[16:52] <ogra_> it will be a one-snap-depend-on-bt-framework rather
[16:52] <john-mcaleely> and inside that framework, there's still work?
[16:52] <ogra_> so we first need that framework ...
[16:52] <john-mcaleely> to accomodate snappy's confinement, ect
[16:52] <john-mcaleely> ?
[16:53] <ogra_> and that framweork would have a "snappy config" ability to adjust itzs settings and add HW access etc ... i imagine
[16:53] <john-mcaleely> mmm
[16:54] <ogra_> but thats just from my own "dream compartment" :)
[16:54] <john-mcaleely> its a good start. thank you
[16:55] <john-mcaleely> ogra_, is wifi different or the same?
[16:56] <john-mcaleely> (I only have a beaglebone black here, so I don't see this for real)
[16:56] <john-mcaleely> I'm guessing there would need to be config utilities 'added' to the core image
[16:57] <john-mcaleely> ?
[16:57] <ogra_> wifi is slightly different, we shhip all bits needed to set uip wifi in the core
[16:58] <ogra_> but we dont have a configuration story for that yet ... and i'm not sure if it will be a framework itself or just a snappy config option to ubuntu-core
[16:58] <john-mcaleely> ok, so there's some software there, but actually baking it in to work in a particular way is missing?
[16:59] <ogra_> there is SW and there are modules ... but no config at all currently, you have to set it up manually
[16:59] <john-mcaleely> that's clear
[16:59] <john-mcaleely> cool
[17:00] <john-mcaleely> similar, but different :-)
[17:00] <ogra_> yeah :)
[17:00] <ogra_> i doubt we'll pull the whole BT stack into the rootfs ... thats the main difference
[17:00] <ogra_> so the Bt SW needs to come from a framework
[17:00] <ogra_> perhaps wifi will do that too later
[17:00] <john-mcaleely> yeah, there seem to be several viable BT stacks
[17:00] <john-mcaleely> sadly
[17:01] <ogra_> right
[17:01] <ogra_> wifi is more clear ... wpa-supplicant and iw tools and you are done
[17:01] <ogra_> which is why we simply included them for now
[17:01] <john-mcaleely> simpler software tech. just does IP, I guess
[17:02] <ogra_> yep
[17:02] <ogra_> no special daemons, no daemons depending on these daemons etc
[17:02] <john-mcaleely> right. ui requirements
[17:02] <john-mcaleely> for 'pairing'
[17:02] <john-mcaleely> or whatever
[17:04] <ogra_> well, even commandline pairing requires special tools
[17:04] <john-mcaleely> why am I not surprised?
[17:04] <ogra_> for the IoT side we'll need a programmatic way to do it without UI ... or perhaps web UI
[17:05] <john-mcaleely> indeed. or just use different radios
[17:05] <ogra_> sadly the framework story is still very blurry ... there is a sprint this week in lex. ... i hope they do more than snapcraft there and we actually get some more fleshed out framework stories
[17:06] <john-mcaleely> sure
[19:54] <seshu> Hello there.  My current application/service that runs on Ubuntu has no gui, its written to be a daemon. The main libraries I use for my application/service uses json and mosquitto libraries.
[19:54] <seshu> I'm trying to see if I can rebundle my application/service into snapp app.
[19:56] <seshu> so can a snappy app be a daemon?
[19:56] <beuno> seshu, yes, it can run as a service
[19:57] <seshu> thanx beuno.
[19:57] <beuno> seshu, see: https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
[19:57] <beuno> how to start it, etc
[19:58] <seshu> Would I have to bundle the libraries along with the app?
[20:00] <beuno> seshu, yes
[20:00] <beuno> snaps are self-contained
[20:14] <seshu> so looks like, if my application/service needs to incorporate functionality similar to webDM (such as triggering install,remove of other apps or trigger the upgrade of ubuntu core from remote), it should have to be a framework. Am I  correct?
[20:15] <beuno> seshu, correct
[20:19] <beuno> seshu, keep in mind, a framework like that would generally not be accepted into the snappy store
[20:20] <beuno> given it would require to be unconfined
[20:20] <beuno> so it depends on what your goal is for this snap
[20:20] <beuno> if its for a fixed function device that doesn't need access to the general store
[20:20] <beuno> or you're just trying to get a sense of how things work
[20:27] <seshu> at the moment, I'm trying to understand how things work and how I may have to modify my application to be able to run on snappy.
[20:31] <seshu> later, the idea is to see how I could use snappy for an IoT solution.