[06:55] ogra_: hi, do you have any expectation on the order of the uboot environment vars? I use alphabetic order right now but was wondering if I should keep the order of the input file inside the uboot.env. I guess it does not matter but I wanted to double check [07:03] good morning [07:19] good morning [07:26] mvo_, no, no expectations, uboot loads all at once before processing, so any order should be fine [08:17] Chipaca: hi, I think https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/265259 is good now, I fixed the missing dependency and update tha ppa. I also createda backport for 15.04 but have not proposed it yet, wanted to do the full willy image test first [08:17] Chipaca: if you could check if its really good now, that would be great [08:18] mvo_: When this is merged and i build a new willy image, will that include the new behavior? [08:18] longsleep, yes [08:19] you will need the updated device snap [08:19] ogra_: Even if i have my own device snap? [08:19] yeah, we are just wating for the final code review, I guess I could top-approve, john said "good except the missing package dependency wich i added) [08:20] * mvo_ wonders how impatient he is today :) [08:20] longsleep, you will need uboot.env support in the bootloader [08:20] yes i got that [08:21] btw - did you see my script for resizing from yesterday: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh [08:21] i would suggest adding something like this to the boot process by default [08:22] will just grow the writable partition no matter what [08:22] (if it can be grown) [08:23] longsleep, we have a set of initramfs script already that are widely used (i.e. on the phones) ... we just havent decided to include them yet because there are potentially more and bigger changes to the partitioning setup ahead [08:24] ok - understoot. So for now see it as easy way for people to resize their snappy installation. [08:26] so just to be sure - once mvo_ merged the changes, 'ubuntu-device-flash core --channel edge .. 15.10 should' fuse them into an image right? [08:29] the snapy on the image will deal with both new uboot.env and old uEnv.txt, if uboot.env is there its used, otherwise it just keeps using the old system [08:29] ah, sweet [08:31] ok - so i could now even remove the empty uEnv.txt ? [08:32] and the snappy tool will still detect u-boot environment? [08:33] if there is no uboot.env file u-boot will fall back to the defaults [08:33] (and load uEnv.txt or boot.ini or whatever you have definaed by default) [08:35] ogra_: hey, I found two bugs in snappy amd64 boot config [08:35] file them then [08:35] ogra_: I'll report them later today after meetings but I wanted to share this [08:35] * ogra_ has never touched the grub stuff ... luckily :) [08:35] ogra_: first, we use the wrong identifier for the hard drive and snappy really boots by accident [08:35] ogra_: it should be hd0 instead of hd1 everywhere [08:36] ogra_: I suspect this is because after the image was generated the grub config generator never ran again [08:36] ogra_: this makes it boot by accident really, it boots because -- [08:36] ogra_: the filesytem identifiers are used as a fallback and those actually work [08:36] ogra_: which is the second bug: everyone that downloads the pre-made image will have the same unique identifier [08:37] ogra_: and then mess happens, boot snappy, plug snappy on a usb drive, reboot -- you will boot into the random one depending on bios [08:37] ogra_: we should re-generate them on first boot [08:37] ogra_: like other things (ssh keys) [08:37] ogra_: I'll file them today, thanks [08:42] ogra_: yeah if there is no uboot.env file, my uboot will now fail to boot as i have dropped the boot.ini. But i am also not loading uEnv.txt and in the past this file was used to detect u-boot environment - thus is shipped an empty one and still do. [08:42] well, why did you drop the boot.ini code ? [08:43] i assume thats just a fatload somewhere in the u-boot default config ? [08:43] because it is not needed anymore as everthing is in boot.env [08:43] yes, and that means you can keep the old env around [08:43] uboot.env will completely replace it if it is there ... if it is not there you fall back to the old methid automatically [08:43] Mhm - i thought to clean it up to avoid confusion [08:44] well, its a safety net :) [08:44] * ogra_ doesnt want to admit that he is just to lazy to clean that up in his own images :P [08:45] mhm - i was thinking to bring back uboot.ini eventually so people can customize "some" variables without modifying the .env file [08:45] the .ini file is handy as it supports comments and empty lines [08:45] i think these two points are the reason they added it [08:45] well, with uboot-go around changing the env vars isnt actually a biggie [08:46] but yeah, we dont remove the loading code for uEnv.txt either [08:46] so you could use it to override thins [08:46] *things [08:46] well you have to do it from command line - i was thinking about people who insert the sdcard into some pc and use notepad to edit it [08:46] right [08:47] there are some things people might want to change, like hdmi resolution, mode, sdcard compatibility [08:47] ogra_: btw, who's working / looking after the amd64 images? [08:48] Good morning all; happy Hammock Day! 😃 [08:48] ogra_: and in my old boot.ini i was hacking and calling snappy_boot, so i really want to get rid of this [08:53] longsleep, just ship an empty one then [08:54] yeah i will do that with some examples for customization [08:54] this is not possible with uEnv.txt [08:54] no comments and no empty lines right? [08:55] i mean for the bbb uEnv.txt is just loaded with import -t -r [08:55] uEnv.txt is exactly the same [08:55] same was what? [08:55] comments and all [08:56] they are identical ... just differently named [08:56] (i never understood why odroid felt they need their own filename) [08:56] identical to what ? sorry i am not getting it :) [08:56] you mean the boot.ini ? [08:56] they are not the same [08:56] they are similar [08:57] but the boot.ini is parsed differently [08:57] boot.ini and uEnv.txt are absolutely identical, just that whoever implemented the odroid uboot bits decided he wants it called boot.ini [08:57] no thats not true [08:57] boot.ini supports empty lines and comments [08:57] i dont think there is any difference in parsing [08:57] uEnv.txt too [08:57] oh [08:57] our beagle and RPi images hsip a uEnv.txt with empty lines and comments ;) [08:57] well they have 100 lines parsing code added to u-boot [08:58] so let me check that code [08:58] i would be happy to use uEnv.txt [09:00] heh, seeing the wily-devel ML it looks like slangasek had "a-f day" :) [09:01] err ... wily-changes i mean indeed [09:03] ogra_: so the code is here: https://github.com/hardkernel/u-boot/blob/odroidc-v2011.03/board/hardkernel/odroidc/cfgload.c - they have logic to load it from muliple locations which we do not need, the rest is about ignoring comments and parsing all with hush. Is uEnv.txt also parsed with hush? [09:03] * longsleep needs to learn about uEnv.txt [09:03] if hush is enabled, yeah [09:03] ok then - i do not know why they added this cfgload stuff either :) [09:04] it might be implemented a few mobnths before the uEnv.txt support landed or some such [09:04] mhm well that wile was added end of 2014 - so i guess uEnv.txt support is older [09:04] uEnv.txt comes from 2010 or 2011 IIRC --- [09:05] might have been 2012 [09:05] they have some text comparison verifying that the file is for the correct target - maybe that is the reason (it has to start with ODROIDC-UBOOT-CONFIG to be used). [09:08] mhm - i still fail to see how "env import" can process stuff like "setenv foo bar" assuming uEnv.txt is the same as boot.ini [09:13] mvo_: approved; sorry for the delay (first day of school holidays!) [09:13] Chipaca: no problem at all [09:14] Chipaca: I *so* look forward to the school holidays too [09:14] * mvo_ will sleep until noon that day [09:14] :) [09:14] i instead got a supermarket delivery at 6:30am, just to celebrate [09:15] but then went back to sleep \o/ [09:15] lol [09:15] your kids dont show up at your bed at 7 ? [09:16] 6:45 [09:16] but he's just started a longish book, so he was lost in it before 7 [09:17] i must admit the fact that he's reading "young adult" fiction does bother me a little bit :) [09:19] why is that ? [09:19] because he's 10? [09:19] nothing to bother about then :) [09:20] that's why the smile :) [09:20] especially considering i was reading LOTR at his age [09:21] i had a hang for scifi short stories at that age ... [09:21] (it's my grandpa's fault, as he gave me the best encouragement he could: he told me i was to young to read it) [09:21] (i think i was way older before i read LOTR) [09:22] nice, the kvm hung overnight [09:26] ogra_: so - from my testing uEnv.txt gets loaded as key=value file - it supports comments, but one cannot use if, or setenv in it. Do you have an example for an uEnv.txt which does that? [09:26] mvo_: anything you'd do different wrt http://pastebin.ubuntu.com/11919018/ ? [09:27] lohmm, no [09:27] longsleep, hmm, no [09:28] longsleep, why do you feel the need for setenv ? [09:28] well it all comes down how the uEnv.txt is loaded, in your bbb its just "env imported", the boot.ini is parse_string_outer line by line. [09:28] var=value is enough [09:28] setenv is not required true [09:28] but i need if/else [09:28] if/else work inside a var [09:29] look at the old snappy-system.txt [09:29] i.e. the snappy_boot cmd [09:29] well, ok - i need to do this: if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi [09:29] i need to run commands inside if/else [09:30] and the settings should be controllable by user [09:30] mytest=if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi [09:30] then you exec mytest from somewhere [09:30] ok i guess i could do that [09:30] let me try :) [09:30] run mytest [09:30] ... [09:30] snappy_boot=if test "${snappy_mode}" = "try"; then if test ${snappy_trial_boot} = 1; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; else setenv snappy_trial_boot 1; saveenv; fi; fi; run loadfiles; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr} [09:30] uenvcmd=run snappy_boot [09:31] like that :) [09:31] yes, and those vars i could predefine in the .env file even [09:31] ok sounds like a plan - thanks [09:34] :) [09:35] i want to get rid of all hardkernel special stuff if possible, so make it easier to switch to upstream u-boot eventually. [09:36] +1 [10:18] mvo_, do you need an extra approval on https://code.launchpad.net/~mvo/snappy/snappy-bootsuccess-env/+merge/264981 ? i assume we wont get one from sergio this week === bigcat is now known as bigcat[off] [10:27] ogra_: I self approved now, this branch is obsolete with the env2 one anyway [10:27] ah [10:28] so now i need to find out how to get the snap into the store [10:28] seems it was uploaded by a canonical account [10:29] (and i guess both people that could tell me about it are gone this week) === bigcat[off] is now known as bigcat [11:01] ogra_: so the snappy change is merged, I triggered a ppa build, once that is in the PPA we can do a new image [11:01] ogra_: re store, [11:01] mvwe need the snap in the store ... [11:01] mvo_, we need the snap in the store ... [11:02] ogra_: so the snappy change is merged, I triggered a ppa build, once that is in the PPA we can do a new image [11:02] and i have not the slightest clue how to get it there [11:02] ogra_: re store, one sec [11:04] ogra_: you have a private message with details :) [11:04] ah, i need to go to the other machine then :) [11:04] * ogra_ is having brunch :) [11:08] is it possible to rollback more than 1 step? i kinda find it interesting to be able to rollback 12 versions back if i'm crazy. the a/b is nice but the whole alphabet is nicer :D [11:09] ii think currently only one step [11:09] :'( [11:09] oh currently :d [11:09] so there is hope! [11:09] OMG! [11:10] i'm not sure we plan to actually keep all versions of a snap on your disk forever ... [11:10] which would be needed for endless rollback [11:10] maybe for selected snaps? :D [11:10] i don't need all of them, but would be nice to work for selected snaps [11:10] i also don't care about disk space [11:11] we plan to move to a more flexible way than a/b in the future, but its not done yet [11:11] mvo_, thats about app snaps [11:11] ogra_: let me know if the msg made it, if not I can also handle the upload [11:11] thanks mvo_ and ogra_ :D sounds amazing to me! :D [11:11] i guess starting a discussion on the ML might be helpful [11:12] mvo_, well ~30min, then i'll be back in the office [11:12] oh, app snaps, yeah, we already keep 3 by default iirc, easy enough to keep more [11:12] ogra_: thats fine, I get lunch then I think [11:12] yeah [11:35] yeah, we'll allow a/b and *also* 𝛼/𝛽 \o/ [11:37] greek rollback ? [11:45] mvo_, ok, new bealeblack snap sits in review in the store, someone needs to manually approve it [11:47] *beagleblack [11:59] ogra_: so now that the change is merged - you think i can build a new image which should handle uboot.env ? [12:00] longsleep, not yet ... we dont have a new rootfs yet [12:00] ogra_: ah yes - that reminds me that i need to learn how to build a rootfs myself [12:00] yeah, thats next on my list ... making rootstock-ng work for home builds again [12:03] well does it actually matter how the preinstalled tarball is created? I mean building that should be easy. I am only worried about what comes after that - as i have no clue yet :) [12:04] after that it gets processed by system-image [12:05] which unpacks it and the last tarball, diffs the files and creates a delta tarball [12:05] yeah thats the scary part :) [12:06] * longsleep still needs to build a system-image and deltas for odroidc [12:08] https://wiki.ubuntu.com/ImageBasedUpgrades/Server [12:08] yes i have been reading that a couple of times - until now i found something which was more fun to work on [12:10] i'm also not sure it is worth the effort ... eventually your device tarball will become a snap too ... then a system-image server would be rather pointless (as you would just serve the same rootfs we serve) [12:11] ogra_: only for rolling right now, correct? [12:11] ogra_: the 15.04 backport is not approved yet, but we should focus on that now I guess [12:11] mvo_, well i didnt change anything in the package setup on the page ... it had both ticked ... can you just release for one ? [12:11] ogra_: i am not so sure yet, i might require changes to the rootfs or some software inside it. Or for the paranoid, i might want to have self compiled versions of everything [12:12] ogra_: I think no, will it still install the old files? i.e. will a old snappy still work? [12:12] longsleep, that breaks snappy design though ... you should put your extra bits into snaps people can install at build time of the image [12:12] ogra_: eh, nevermind, of course not [12:12] mvo_, uEnv.txt is empty [12:13] ogra_: meh, ok [12:13] ogra_: I will ask Chipaca for another review then :) [12:13] yeah, then we can blame him if it breaks, good idea :) [12:14] ogra_: thats the idea, right? its always the reviewers fault [12:14] yup [12:14] ogra_: unless I did the review in which case its the original authors fault [12:14] *indeed* ! [12:14] Chipaca: if you have a moment, could you plese check https://code.launchpad.net/~mvo/snappy/15.04-snappy-bootsuccess-env2/+merge/265510 [12:15] I shall consider it. [12:15] ogra_: yes, but what about images for certain hardware which come with pre installed stuff? [12:16] Chipaca: meh, I just noticed it may miss a upstream revision, let me quickly double check [12:16] longsleep, same thin [12:16] g [12:16] longsleep, your extras should be in snaps [12:17] ogra_: ok i see - can the snap modify base behavior? Like add or change systemd services ? [12:18] theoretically yes, not sure how that will practically work ... but confinement is something we enforcxe artificially so you can indeed work around it (as long as a store reviewer approves it) [12:18] Chipaca: ok, should be ready now [12:19] ogra_: what about third party devices with custom behavior, do these have their own store then? [12:19] i guess so [12:19] * ogra_ doesnt know the exactly planned setup for that [12:20] ogra_: ok, that is probalbly soemthing i need to investigate more then. [12:20] yep [12:20] beuno should be abck next week, he can elaborate [12:20] *back [12:21] well, don't kick me out just yet! [12:21] :D [12:21] hey, didnt you mail that you are vacating ? [12:21] tomorrow and thu! [12:21] er, tomorrow and fri! [12:22] ah [12:22] longsleep, we're still working out the details on how to support third-party devices that need to break out of confinement. We can point you to the commercial team to help you flesh that out if you'd like [12:23] beuno: Yeah - i just had a call with Marteen and he sent an email to connect me with lool [12:24] ah, perfectd [12:26] but i also would prefer to have as less customizations as possible. So i am checking all the possibilies here. Not sure if it really needs to break out of confinement. [12:27] longsleep: hi! [12:27] I have control on uboot, kernel, snaps and device part. Device part will become a snap eventually. What i need in addition is a customization like some post image build scripts. [12:27] longsleep: just read through Maarten's email; reading the fwded one now [12:27] lool: hey - no hurries [12:28] longsleep: ok, done reading, and BTW well done on the ODROID-C OEM snap :-) [12:28] longsleep: I didn't find details of the questions around SSL and ports; is this written up somewhere in email or bug? [12:28] lool: thanks - that was the easy part. Getting the thing doing the same as with normal ubuntu is the hard part. [12:29] lool: i sent some points to the mailling list in the past, and i have added some stuff to the tracker as well. [12:29] rsalveti, do we have much of an agenda for the snappy community call? [12:30] oh, i totally forgot about that one [12:30] no asac today too [12:30] lool: bot i think its best explained all together rather to get the idea [12:30] rsalveti, I had a few days off so not too much to report on my side [12:31] lool: right now it comes down to entropy, having a NGINX framework so many snaps can share port 443 and SSL setup [12:31] * ogra_ was busy with technical stuff the last days ... [12:31] not much from my side either [12:32] longsleep: I see [12:33] longsleep: I think it's a great thing to provide [12:33] longsleep: so in general, we have not been mandating how this or that should be designed but rather gave a set of primitives (like frameworks and apps) as to let various experiences bloom [12:34] longsleep: and then we see what picks up and makes the most sense [12:34] longsleep: I think it's a wonderful example [12:34] longsleep: in general, framework provide services typically in the sense of a shared resource; port 443 is one; entropy pool is another; great things to expose in a framework [12:35] longsleep: how would the API be? apps depend on your nginx-based framework and register a name over HTTP/REST to localhost to get traffic forwarded to them for /name/ or for name.xyz? [12:36] lool: yes something like that - not sure if it needs to be an api though. In non snappy we just have a conf.d folder where packages can put their configs. [12:36] well, you could have snappy config do it from your oem snap [12:37] snappy config can use script hooks to apply the config [12:37] lool: and the entropy one is tricky, on first boot keys need to be generated - it needs to be ensured that there is entropy available. Right now it creates key with essentially no entropy on first boot. [12:38] ogra_: ok, snappy config - thats something i need to investigate then. Is that only for oem snaps or also for software snaps? [12:38] longsleep: so apps (and frameworks) are sandboxed as to prevent apps to see files from other apps; there needs to be a provisioning mechanism; we dont want maintainer scripts, but you could have data bits [12:38] longsleep, thats for all snaps [12:38] but in context of oem it can indeed be more powerful [12:38] I dont think config hook will help to cross app barriers [12:38] no, but to alter system defaults without having to hack the rootfs snap [12:39] the idea of config hooks if to have a standard interface for one snap to load/dump its config in YAML [12:39] (or tarball) [12:39] what longsleep wants, as i understand is some firstboot config to be applied [12:39] for that the config hooks in the oem snap should be fine [12:40] only if applying that would block boot [12:40] or start of systemd services [12:40] i mean, the problem exists today. The SSH keys are generated on first boot with essentially no entropy. [12:40] Thats why i think the problem needs solving on snappy level. [12:40] we're discussing two different things [12:41] well, on a cloud-init level [12:41] one is the entropy, the other is providing nginx to other apps [12:41] yes true [12:41] lets talk nginx first [12:41] i was thinking to have something similar to the docker framework [12:41] it essentially the same [12:41] provide outside resouces to snaps [12:41] right? [12:42] yup, kind of [12:42] right now i would have to ship nginx inside my snap [12:42] instead i could create a nginx snap [12:42] and somehow depend on it [12:42] are frameworks snaps too? [12:42] so generally, we are not trying to use frameworks as a mean to distribtue dependencies [12:43] liek packages were [12:43] snaps are apps [12:43] yes, frajmeworks are snaps [12:43] fully contained [12:43] frameworks are to deliver a service or access to a shared resource [12:43] yes [12:43] for instance, a bluetooth service [12:43] but if the goal is to make it easy for an app to embed a HTTP server like nginx, then I think this is more of a snapcraft topic [12:44] which is the optional developer tool to create snaps [12:44] mhm not sure - that would mean there would be multiple nginx running [12:44] with snapcraft, you can say "embed a java runtime in my snap" [12:44] similarly, you might want to embed a HTTP server [12:44] yes, multiple HTTP servers running is fine [12:44] obviously not on the same port [12:44] not on the same port - and they all would need access to the same private key [12:45] not necessarily [12:45] that's if they serve the same site [12:45] true [12:45] so perhaps it would make sense to discuss the larger problem you're trying to solve [12:46] right now we have a bunch of micro services all providing HTTP web server. To the outside they get exposed with specific configuration by Nginx TLS on 443/tcp [12:46] is it to make it easy to server a bunch of websites from a snappy install? [12:46] well, if web sites mean differnt domains then no. [12:47] its about exposing web services on port 443/tcp with a secure TLS configuration. [12:47] lets take the example from spreed-webrtc [12:47] its a go service, wich listens on port 8080/tcp [12:48] it needs to be exposed to the world on port 443/tcp with tls [12:48] it could do that itself or the snap could include a web service which does it [12:48] longsleep: is there an architecture diagram of spreed somewhere? [12:48] sure [12:48] hold on [12:49] but spreed-webrtc is simple [12:49] in the default setup it has only one end point [12:49] longsleep: yes, but rather than discussing bottom up, I'd like us to have a top down discussion [12:49] let me upload it [12:50] longsleep: for instance, from my naive understanding, I understand that this is about delivering spreed easily; I instinctively think this shoud be implemented by delivering a single spreed snap that offers the whole thing with hardcoded configs for most things, then exposing more and more features [12:50] lool: yes - but that only works if no other snap uses port 443. [12:50] longsleep: basically, the closest thing that matches this for me is how I'd run Kodi on an Android device [12:51] I'd install the Kodi app [12:51] and then run it [12:51] and perhaps have snappy config options to en/disable single spreed bits [12:51] in the first version, this would not expose all the crazy advanced features like the web services for the remote control or the storage abstraction or etc. [12:52] * ogra_ tried a kodi snap on the weekend but failed to build a static binary *sniff* [12:52] lool: can you go to https://spreed.me/struktur/longsleep and i share the diagram with you there [12:52] longsleep: so port conflicts are a real issue; we need to provide a definitive solution for this, but for now I'd say take port 443 by default, make the port configurable in the config hook and let anyone install the app; if the port is free, it's used, otherwise it's configurable [12:52] longsleep: I have a personal opinion on how we should solve the port issue, but I dont think it was discussed [12:52] longsleep: the current plan was around having an API to negociate/reserve ports [12:53] lool: ok - what about muliple ips - do you have ideas around that as well? [12:53] my personal opinion is that we should start apps in some kind of network namespace where they can do what they want and some core snappy config allows routing host ports to snappy apps [12:53] Chipaca: \o/ [12:53] :) [12:53] lool, sounds like ubuntu-fan for ports :) [12:54] longsleep: I'm there [12:55] lool: ok - i shared the file with you. [12:55] longsleep: https://wiki.ubuntu.com/Snappy/CoreImageBuild as well [12:56] dholbach: we can do a short call, just wanted to talk about snapcraft quickly [12:56] sure [12:56] longsleep: got it [12:57] so you see Nginx STUN and TURN [12:57] In the simple case we have only Nginx [12:57] that is on port 443 [12:57] but what if we want to have a TURN server as well [12:57] that would be a different snap [12:58] also needs to listen on port 443 [12:58] different IP [12:58] or if we would add other backend services [12:58] longsleep: ok, so what's the minimal first version we could target? coudl we do everything on top of User 2 in a single snap to start with? [12:58] yes that is no problem [12:58] longsleep: BTW, checkout snapcraft; it's alpha but it allows bundling binaries from .debs easily [12:58] I've used it to embed a java runtime and tomcat with a webapp [12:59] lool: Maarten told me about this today [12:59] will check it out for sure [12:59] longsleep: (NB: I have a call tunnel starting now and going 4 hours) [12:59] 4.5 actually [12:59] no problem [12:59] but I'm reading IRC [12:59] think about the entropy problem though [12:59] that is more critical :) [13:00] thanks for your time [13:07] longsleep: so are STUN and TURN typically provided / deployed with spreed? [13:07] are you saying the second IP is mandatory? [13:07] no they are optional [13:07] but you should have a STUN server somewhere [13:07] and a TURN server too for firewalled users [13:08] longsleep: ok; entropy... again super naive thought, but we do that in all our cloud images: they boot and get some entropy from linux to generate a SSH key (I guess /dev/random provides a limited amount thanks to entropy of network traffic?) [13:08] eg on our deployments they are all installed and that requires 3 IP's even. But the spreed server works fine with one. [13:08] longsleep: are the TURN/STUN bits typically provided with the spreed codebase? [13:08] lool: no it is a separate software [13:09] longsleep: are the TURN/STUN generally useful with non-spreed use cases? [13:09] lool: cloud images are a little different, they have most likely network connection on first boot and load entropy from your entropy service. While i find that scary too at least the keys are fine assuming the entropy service is providing good random. [13:10] (I know what kind of services these provide, just not sure if these are typically used outside of spreed in general) [13:10] lool: yes sure, many services require / can use a STUN/TURN service [13:10] ogra_, since i2c isn't enabled on the rpi2, does that mean the GPIO works out of the box? [13:11] longsleep: I can't really judge on this question product-wise, but I see two ways this could be done: either bundle all the software in a spreed snap, with 3 sets of services; second and third set of services would be disabled by default but could be enabled from a tunable [13:11] kyrofa, no [13:11] longsleep: would also expose config to set IP address to use [13:12] lool: yes - that is possible. No problems here - though i wanted to avoid problems when people have other snaps also binding port 443 (current example is the ownlcoud snap). [13:12] ogra_, can I get it to work, or is it in a similar situation to i2c? [13:13] you need to have the bootloaders load the overlay dtb files that are needed for this ... and it will onyl work with ppisati's new kernel which will only be in the next image [13:15] ogra_, alright, thanks for the info :) === kickinz1 is now known as kickinz1|afk [13:20] mvo_, E: Build-Depends dependency for ubuntu-snappy cannot be satisfied because the package golang-uboot-go-dev cannot be found ... [13:20] anything to worry about ? [13:20] https://launchpadlibrarian.net/212301215/buildlog.txt.gz [13:20] ogra_: yeah, I coped the depenency but looks like it was only copied but not published [13:20] ogra_: I'm sitting here very impatiently [13:21] ogra_: fwiw, I started a wily image build now, that should have the real deal [13:21] ah, sweet [13:21] ogra_: and once the golang-uboot-go package is available on vivid we can test that too [13:21] yup [13:24] ogra_: yay, build! now once that is published we should have a 15.04 test image [13:25] cool .... i'll test after the call [13:25]