[01:37] anyone available for a silly question? [01:38] maybe mahmoh or kirkland? or anyone [01:44] guess I'm 0 for 91 here === erkules_ is now known as erkules [08:46] Good morning all; happy Equal Pay Day! :-D [11:12] does anyone know where mvo is these days? [11:20] zbenjamin, at a sprint i think ... [11:20] US timezone [11:22] ogra_: aaa ok, makes sense [11:23] ogra_: right there is a sprint in austin afaik [11:30] ogra_: what would be the right way to hack around on snappy in a VM? [11:30] ogra_: do we have any images [11:30] i never used it in a VM :) [11:31] ogra_: heh, how do you use it ? :) [11:31] but i think there are instructions for runnin it in KVM on the website somewhere [11:31] on arm boards [11:31] once you have it running you should be able to ssh into it or open the webdm UI in a browser ... [11:32] http://www.ubuntu.com/cloud/tools/snappy [11:32] that has a KVM section [11:33] ogra_: aa nice thank you [13:13] cprov: http://people.canonical.com/~ogra/snappy/odroidc/ [13:14] sergiusens, that *might* need a re-spin for the latest release ... havent done one since the last milestone ... [13:16] no worries [13:17] sergiusens: thanks === kickinz1` is now known as kickinz1|afk [14:40] Hi All, Can the "repository"/store for the snappy packages be installed localy ? [14:41] no === kickinz1|afk is now known as kickinz1 [14:48] ogra_: Is it available in commercial terms ? Or some other ideas here ? [14:52] ezobn, ah, i dont know ... beuno might though [14:52] ezobn, hi [14:52] what do you mean? as in, run your own version of the store? [14:54] beuno, yes. To have scenario like vCPE for the telcom and application delivery using localised store. [14:56] ezobn, you can't run it locally, we do offer a sub-store for products [14:56] still hosted by us, but you have control over what goes into it [14:56] in some cases, we will offer a local proxy, so clients don't need to talk outside of the network to get updates [14:57] jdstrand: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image [14:58] thanks [14:59] beuno, good to know, the idea for the local proxy is to deliver updates to not get it all from outside network, decrease amount of possible traffic or so ? [15:01] ezobn, yeah, different people want to lock down networks for different reasons [15:01] for some it's security, some bandwidth [15:02] beuno, thanks, got the point. [15:09] zbenjamin: ah yes you are [15:10] mvo: raise your ears just in case :-) (or eyes) [15:10] zbenjamin: I'd rather have mvo be the main stakeholder here ;-) [15:11] zbenjamin: we don't have a concept of hand holding builds with snappy [15:11] like click chroots didd [15:11] sergiusens: hm yeah i just had the idea that it would be nice and more lightweight to create a buildenv with the snappy tools [15:11] sergiusens: since we already have package versioning and so on [15:12] zbenjamin: right, we have no versioning in snappy either [15:12] sergiusens: you can do rollbacks no? [15:12] zbenjamin: yes [15:13] zbenjamin: but there is no dependency chain that ties you to the versioning [15:13] sergiusens: thats what i meant, so lets say you want to build a specific snap, you need a rootfs with the dependencies. The rootfs builder could read your dependencies and install them into a core rootfs [15:13] zbenjamin: as in, in the click world you could depend on ubuntu-sdk-13.10 [15:14] sergiusens: yes, but i can depend on frameworks in the snappy world [15:14] or did i get that wrong [15:14] zbenjamin: yes, you can [15:14] zbenjamin: for native builds you might want to look at what lool did [15:15] sergiusens: if it uses schroot then thats exactly what we would like to prevent... [15:15] zbenjamin: just take into account, snappy rootfs don't have apt (and won't have dpkg) [15:15] sergiusens: schroot has proven to be slow and unstable in the SDK. [15:15] bzoltan: ^^^ jus t case you want to read as well [15:16] sergiusens: so for example schroot leaks mounts. For any reason a click chroot .. run is killed or terminated it will leave mounts behind. Those mounts are restored on boot.... We had people with 16k mounts [15:16] sergiusens: also the mount/umount on every command is horribly slow [15:16] zbenjamin: https://lists.ubuntu.com/archives/snappy-devel/2015-March/000415.html [15:17] sergiusens: ah teh devpacks yeah [15:18] sergiusens: ok i thought the devpacks would be installed by snappy as well [15:19] sergiusens: the idea was that i can construct the rootfs from outside. and then use it as chroot/sysroot/whatever [15:20] sergiusens: but reverting it to a clean state is the problem here [15:21] ping ogra_, if I install your chatroom snap in kvm, what is the url? [15:22] zbenjamin: that's snapcraft; but I suggest to reply with that in the rfc email which needs some interaction love [15:22] elopio: don't forget to -redir if using kvm [15:22] elopio: and you can check by looking at the ports entry in package yaml maybe [15:22] elopio, $ip:6565/ [15:23] elopio, for kvm you need to forward that port somehow [15:23] then i think localhost:6565 might work [15:23] sergiusens: where should I use -redir ? [15:23] you likely use it already in your kvm commandline [15:24] just add another redirect for the 6565 port [15:24] got it. [15:24] elopio, and thanks for the blog comment !! [15:24] ogra_: this is really cool actually. Thanks to you for the magic tool. [15:26] :D [15:41] sergiusens: sadly i can not answer to that mail. I just registered for the snappy-devel ML [15:44] where do I report a bug for snappy-remote? [17:05] ogra_: would you know where the pins for the serial console are on the ninja sphere develoepr kit? [17:08] ogra_: nevermind, found it === kickinz1 is now known as kickinz1|afk === kickinz1|afk is now known as kickinz1 === erkules_ is now known as erkules [22:08] is anyone here with "Screen version 4.00.03 + CentOS release 6.6 " that support vsplit release? [22:08] err sorry wrong channel === ahayzen_ is now known as ahayzen === kickinz1 is now known as kickinz1|afk === essembe is now known as sbeattie === kickinz1|afk is now known as kickinz1