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