| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 07:10 |
|---|---|---|
| fgimenez | good morning dholbach and all | 07:11 |
| dholbach | hey fgimenez | 07:12 |
| === bigcat_ is now known as bigcat | ||
| JamesTait | Good morning all; happy Ingersoll Day! 😃 | 09:08 |
| === carlo is now known as Guest22910 | ||
| === soee_ is now known as soee | ||
| dholbach | ogra_, somebody in our shared office ordered a spreedbox :) | 11:55 |
| ogra_ | dholbach, wheee ! | 11:55 |
| ogra_ | still ~2000€ missing ... | 11:55 |
| === 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 | ||
| elopio | fgimenez: https://github.com/elgris/check/commit/45ed7de654751f962e5c6d493a18933dcea604ec | 15:04 |
| elopio | making an outputWriter interface seems like a good upstream step | 15:04 |
| fgimenez | elopio, yep very good approach, in that case we would need to control the gocheck output, no skips on reboot | 15:12 |
| 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:24 |
| 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:25 |
| sergiusens | ogra_: as a general practice, it's good to not keep the unknowns and knowns together, that's all ;-) | 15:26 |
| ogra_ | i commented | 15:28 |
| john-mcaleely | ogra_, where do i look for details of how bluetooth might work on snappy systems today? | 16:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| ogra_ | but thats just from my own "dream compartment" :) | 16:54 |
| john-mcaleely | its a good start. thank you | 16:54 |
| john-mcaleely | ogra_, is wifi different or the same? | 16:55 |
| 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:56 |
| john-mcaleely | ? | 16:57 |
| ogra_ | wifi is slightly different, we shhip all bits needed to set uip wifi in the core | 16:57 |
| 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:58 |
| 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 | 16:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| john-mcaleely | sure | 17:06 |
| 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:54 |
| seshu | so can a snappy app be a daemon? | 19:56 |
| beuno | seshu, yes, it can run as a service | 19:56 |
| 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:57 |
| seshu | Would I have to bundle the libraries along with the app? | 19:58 |
| beuno | seshu, yes | 20:00 |
| beuno | snaps are self-contained | 20:00 |
| 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:14 |
| beuno | seshu, correct | 20:15 |
| beuno | seshu, keep in mind, a framework like that would generally not be accepted into the snappy store | 20:19 |
| 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:20 |
| 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:27 |
| seshu | later, the idea is to see how I could use snappy for an IoT solution. | 20:31 |
| === carlo is now known as Guest42010 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!