[00:23] <noizer> Hi
[00:23] <noizer> im looking into snappy these days but i want to install the boost library on snappy but how can I do that
[00:24] <noizer> anyone that can help me
[00:25] <elopio> noizer: you can use snapcraft to generate a snap that will consume the library
[00:25] <elopio> or you can use the classic mode while you are developiong something.
[00:32] <noizer> will boost then can be used of anny snap that i will deploy on it?
[01:08] <sergiusens> kyrofa, still around? I hope :-)
[01:37] <kyrofa> sergiusens, yeah hey :)
[01:43] <kyrofa> sergiusens, got your email
[01:46] <sergiusens> kyrofa, I just hacked ROS_MASTER to made up hostname and configured that in /etc/hosts
[01:46] <kyrofa> sergiusens, well, you just saved me some typing
[01:46] <sergiusens> kyrofa, just because I just read this " Great care should be taken when using localhost, as that can lead to unintended behaviors with remotely launched nodes. "
[01:47] <sergiusens> kyrofa, we should make our plugin do export VAR=http://$(hostname):####
[01:47] <sergiusens> kyrofa, lets see how it goes :-)
[01:47] <sergiusens> kyrofa, how's everything with you, all good today?
[01:48] <kyrofa> sergiusens, I'm not convinced that will change things, but if it doesn't, I bet it's still hostname-related. I have more ideas for you
[01:48] <sergiusens> kyrofa, maybe start shooting them out :-)
[01:49] <kyrofa> sergiusens, today was a bit frustrating. rpi problems. But I worked through them, things are building
[01:50] <sergiusens> kyrofa, 16.04? Did unplugging the piglow thing work btw?
[01:50] <kyrofa> sergiusens, right so, when nodes communicate they provide contact info: "here's how to reach me"
[01:50] <kyrofa> sergiusens, thing is, by default they use their hostnames
[01:50] <kyrofa> So when setting up a ROS cluster, we always make sure each computer has the others in /etc/hosts
[01:51] <kyrofa> But an alternative is to use the ROS_IP variable
[01:51] <sergiusens> kyrofa, I have /etc/hosts setup now, more so because setting up ROS_IP on the snap would be painful
[01:51] <kyrofa> Which allows you to skip using hostnames all together
[01:52] <sergiusens> kyrofa, I tried ROS_IP on the plain ubuntu box, didn't work out that well
[01:54] <kyrofa> Yeah, but snappy doesn't have a real hostname right? It's "localhost"?
[01:55] <kyrofa> So you may want to set ROS_HOSTNAME on the device as well
[01:55] <sergiusens> kyrofa, I can set one
[01:55] <sergiusens> kyrofa, using snappy config
[01:57] <kyrofa> Oh interesting. It's odd that I didn't run into this, but yeah: the surefire way to make this work is to use hostnames all the way through. dev computer has a hostname that snappy can resolve, snappy has a hostname that dev can resolve, set the ROS_MASTER_URI to localhost on snappy, set it to snappy's IP on dev
[01:57] <kyrofa> sergiusens, I'm going to have to sit down and make sure we have a config that actually works for this use-case
[01:58] <sergiusens> kyrofa, right, so when you say "ROS_MASTER_URI to localhost on snappy" I think we want it to be the hostname and not localhost
[01:58] <sergiusens> from what I saw in the wiki
[01:58] <kyrofa> sergiusens, that should be fine. I've never done it, but I can't imagine it'll hurt anything
[01:59] <kyrofa> sergiusens, how was this working for you previously? Did you change your network setup somehow?
[01:59] <sergiusens> export ROS_MASTER_URI=http://rpi2:11311
[01:59] <sergiusens> export ROS_HOSTNAME=rpi2
[01:59] <sergiusens> kyrofa, that's my setting now on the rpi2
[01:59] <kyrofa> sergiusens, if rpi2 is actually its hostname, I don't think you need ROS_HOSTNAME
[02:00] <sergiusens> ping rpi2 and ros-trusty (my hostnames) works from either side
[02:00] <sergiusens> kyrofa, I'm setting it up just in case
[02:00] <kyrofa> sergiusens, alright
[02:00] <kyrofa> sergiusens, yeah your setup sounds good. Settings on the dev machine?
[02:01] <sergiusens> kyrofa, export ROS_MASTER_URI=http://rpi2:11311
[02:01] <sergiusens> ubuntu@ros-trusty:~$ vi /etc/host
[02:01] <sergiusens> oops
[02:02] <sergiusens> just the export :-)
[02:02] <kyrofa> sergiusens, yeah fire away
[02:02] <sergiusens> rostopic and rosnode still work with that setting
[02:02] <sergiusens> kyrofa, waiting for the squash now ;-)
[02:03] <kyrofa> sergiusens, nice. And no-- I'm still waiting for the owncloud build. Now you know why this has taken me so darn long
[02:04] <sergiusens> kyrofa, hah
[02:04] <kyrofa> sergiusens, compiling mysql died several times for lack of RAM. I started using swapfiles... 1G... 2G... screw it, plugged in a flash drive, 16G swapfile
[02:04] <sergiusens> kyrofa, I've been considering scalingstack
[02:05] <kyrofa> sergiusens, do they have ARM?
[02:05] <kyrofa> sergiusens, I just learned about the alpha launchpad .snap builds, too
[02:05] <kyrofa> sergiusens, I asked to get in on that
[02:05] <sergiusens> kyrofa, I probably got the name wrong though
[02:06] <sergiusens> it is arm exclusive
[02:07] <kyrofa> Oh... hmm yeah that doesn't seem arm exclusive
[02:08] <kyrofa> 96%...
[02:08] <sergiusens> kyrofa, working!
[02:08] <kyrofa> sergiusens, yes!
[02:08] <sergiusens> kyrofa, going downstairs for a bit
[02:08] <kyrofa> sergiusens, okay :)
[02:09] <sergiusens> kyrofa, I've documented the recipe, so I'll share later ;-)
[02:09] <kyrofa> sergiusens, sounds good
[02:14] <kyrofa> sergiusens, my cell# is in the directory if you need me and I'm not around
[02:23] <kyrofa> 100%!
[06:44] <snappy-user> kyrofa hello I am just testing :-)
[08:15] <fgimenez> good morning
[08:58] <opmodoro> good morning, in the webchat snapcraft example I see an `apps` directive usage, but in the source there is no mention about it. Where is the magic? :)  Thanks
[09:01] <elopio> pindonga: beuno: I'm dangerously close to get the xenial tests back to green. static, unit, integration and coveralls are working.
[09:01] <elopio> Just need to figure out why the examples started to fail yesterday. So ETA, one more day.
[09:21] <LefterisJP> guys for a user providing some extra configuration to a framework is there any standard way? What I can imagine is having a config file in the framework's writable location and then have the wrapper script of the service read that config file to see what args to use when launching the service.
[09:21] <LefterisJP> Then an extra binary to query/edit the config for the framework
[09:33] <JamesTait> Good morning all; happy Thursday, and happy Hugging Day! 😃
[09:50] <joeblew99> basic question. All applications in ubuntu core snappy run inside LXD. So can it run gui apps like Google chrome ?
[12:02] <kyrofa> Good morning
[12:09] <kyrofa> LefterisJP, might be a use for snappy config
[12:09] <kyrofa> LefterisJP, https://developer.ubuntu.com/en/snappy/guides/config-command/
[12:10] <kyrofa> joeblew99, that's not correct-- they don't run inside an LXD
[12:11] <kyrofa> joeblew99, however, supporting things like .desktop files is work that ongoing
[12:11] <kyrofa> joeblew99, so yes, eventually, but only in betas right now
[12:11] <kyrofa> joeblew99, https://rainveiltech.com/posts/prototype-a-gui-friendly-snappy
[12:19] <LefterisJP> kyrofa: looks interesting. So there should be a binary inside the app that can read and output yaml syntax. But seems there is no way to set specific config option from the CLI, just provide a new yaml file to replace the old one.
[12:21] <kyrofa> LefterisJP, yeah kinda. ogra_ may be your best resource here-- I know for certain he's used this. I'm not sure of its capabilities
[12:24] <LefterisJP> all right will wait for his input then
[12:25] <LefterisJP> one more question. I have been trying to turn a snappified directory project to a snapcraft project. How can I make a snapcraft, part of recipe for: 1) Clone repository 2)run specific commands on the repo to produce binaries 3) copy these binaries to the staging area.
[12:26] <LefterisJP> Also the various profiles and other data that go in the meta/ directory for a snappified directory app, how can they be included when creating a snap from snapcraft?
[12:27] <kyrofa> LefterisJP, alright let me make sure I understand
[12:28] <kyrofa> LefterisJP, you have a project with some sort of build system (even if it's just scripts). You want snapcraft to clone that project, run the build system, and include the binaries in the .snap?
[12:28] <kyrofa> LefterisJP, that sounds exactly like what snapcraft does. Am I missing something?
[12:29] <kyrofa> LefterisJP, but your build scripts also produce the meta/ stuff?
[12:30] <kyrofa> LefterisJP, sorry... I'm feeling a little dense this morning :P
[12:30]  * kyrofa pours his coffee
[12:34] <LefterisJP> hehe so let's see
[12:35] <LefterisJP> I currently have 1 project which is bassically a readymade directory on which I snappy build
[12:35] <LefterisJP> But I already have the binaries built and ready under bin/
[12:35] <kyrofa> Okay, with you so far. And you don't use snapcraft because... cross compiling?
[12:35] <LefterisJP> yes
[12:35] <kyrofa> Okay, continue
[12:36] <LefterisJP> But if the user has the appropriate libraries, I can actually make it cross-compilable, since this is a go-project and the developers have made a very handy makefile (which resorts to go build eventually)
[12:36] <LefterisJP> so I just want to clone the repo and run make with 2 different arguments
[12:36] <LefterisJP> and then take the 2 produced binaries
[12:37] <LefterisJP> and from then an on continue as I would with a normal snappy build
[12:37] <kyrofa> Hmm, and are these "appropriate libraries" available in the ubuntu repos for a given arch? Say amd64 or whatever you're running on
[12:39] <kyrofa> LefterisJP, or are they other things you need to clone and build?
[12:39] <LefterisJP> no they are there
[12:39] <LefterisJP> only need to clone this one repo
[12:39] <kyrofa> LefterisJP, ahh.... you just might be able to get this to work
[12:39] <kyrofa> LefterisJP, okay. Are these libs build-time dependencies then, not run-time?
[12:41] <LefterisJP> yes, since it's go everything is statically linked. I already do this manually, and have it working on a Raspberry Pi. Just wanted to automate it with snapcraft
[12:41] <kyrofa> LefterisJP, excellent. Automation is good
[12:43] <kyrofa> LefterisJP, can you add a target to the repo's makefile to run both make commands that you need?
[12:44] <kyrofa> LefterisJP, or is this a third-part repo you're cloning?
[12:45] <LefterisJP> I don't think this is an option
[12:45] <kyrofa> LefterisJP, alright, you need to do a bit more work then
[12:45] <LefterisJP> I saw there is a make plugin, but that seems to run only make
[12:45] <LefterisJP> (no args)
[12:46] <kyrofa> LefterisJP, with my limited understanding of what you're doing, I'd use `build-packages` to pull in those libs, and use the `make` plugin with `source: src` and in the src folder create a Makefile to clone your source and run the necessary commands
[12:47] <kyrofa> LefterisJP, essentially use the Makefile as a script
[12:47] <kyrofa> LefterisJP, keep in mind that the only targets the `make` plugin uses is `all` and `install`
[12:48] <kyrofa> And the `install` target is called with DESTDIR
[12:48] <LefterisJP> hmm is there a way to use a "script" plugin? Just write a script and call it as part of the preparation of building the snap?
[12:49] <kyrofa> LefterisJP, not included with snapcraft. But did you know you can actually include your own plugin in-tree?
[12:49] <kyrofa> And use it in the snapcraft.yaml?
[12:49] <LefterisJP> nope. That's funny though. There are so many plugins, I would expect one for a simple script to exist.
[12:50] <kyrofa> LefterisJP, I just use the `make` plugin when I want a simple script. How would you expect snapcraft to tell the script where to put stuff?
[12:51] <kyrofa> LefterisJP, all the other plugins have established ways to do that (make, autotools, cmake, go)
[12:51] <LefterisJP> call it with an argument which would be interpreted as a path I suppose
[12:52] <kyrofa> LefterisJP, yeah, that might be a useful addition. Feel like logging a bug?
[12:53] <kyrofa> LefterisJP, regarding custom plugins: https://github.com/ubuntu-core/snapcraft/blob/master/docs/plugins.md
[12:53] <LefterisJP> Sure, is it https://github.com/ubuntu-core/snapcraft?
[12:53] <kyrofa> LefterisJP, that's the src, but bugs are tracked here: https://bugs.launchpad.net/snapcraft/
[12:53] <LefterisJP> thanks for the link, will check it out right now.
[12:55] <kyrofa> LefterisJP, if you come up with a generic script plugin that you like feel free to propose it to snapcraft
[12:56] <LefterisJP> Would love to. So that would be as a Github PR?
[12:58] <kyrofa> LefterisJP, indeed. Bugs are tracked at LP, everything else on github
[13:01] <kyrofa> LefterisJP, check out the HACKING.md as well as the CONTRIBUTION.md
[13:02] <kyrofa> LefterisJP, it'll need some test coverage as well (see the other plugins for examples)
[13:04] <LefterisJP> noted, thank you. If I come up with something good in time I will send it back upstream.
[14:31] <elopio> kyrofa: there seems to be a problem in hangouts. Could you get in the call?
[14:32] <kyrofa> elopio, google has been annoying lately
[14:33] <kyrofa> elopio, want to try again later?
[14:34] <elopio> kyrofa: what if we try https://meet.jit.si/snapcraft ?
[14:34] <elopio> seems to work here.
[14:40] <kyrofa> Agh, elopio sorry got distracted. I'll be right there
[14:44] <kyrofa> elopio, that doesn't seem to be working for me either...
[14:46] <elopio> kyrofa: :) want to stand up here?
[14:46] <kyrofa> elopio, works for me!
[14:47] <kyrofa> elopio, your turn first
[14:49] <elopio> DONE: update integration tests working on snappy rpi2, coveralls reporting working again from travis lxd, attended the mqtt class and got the mosquito server and client working on rpi2 classic.
[14:49] <elopio> TODO: understand the examples errors in jenkins (when I put prints they stop raising an exception :@), make a snapcraft for mosquitto, more work on the jenkins snapcraft jobs.
[14:49] <elopio> kyrofa: your turn.
[14:49] <kyrofa> Awesome
[14:53] <kyrofa> DONE: Built owncloud package for amd64 and uploaded to store.
[14:53] <kyrofa> DONE build owncloud package for armhf but then realized I couldn't upload to the store
[14:53] <kyrofa> TODO: Removing amd64 version from the store, uploading new armhf version to replace it
[14:54] <kyrofa> TODO: Got emailed several papercut bugs last night. Turning them into real bugs and fixing the low-hanging fruit
[14:54] <kyrofa> elopio, ^^
[14:55] <elopio> thanks.
[15:16] <elopio> @fgimenez I think I need to go and pick up the car of a friend that's traveling, soon. So I might miss our standup.
[15:16] <nothal> elopio: No such command!
[15:16] <elopio> anything you would like to discuss today?
[15:16] <elopio> ahh, telegram is affecting me.
[15:17] <fgimenez> elopio, ok :) i have a couple of PRs and another one is coming, no rush at all anyway
[15:19] <elopio> fgimenez: I'll get to them soon.
[15:19] <fgimenez> elopio, thx also there was an error in the integration tests yesterday caused by with https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/autoupdate-msg_test.go#L53, could you take a look? if we can't rewrite it maybe it should be dropped, let me know what do you think
[15:19] <elopio> fgimenez: from my side, I had to trick travis using the same path in the container and in the host. Now the coveralls works again.
[15:20] <elopio> I tried everything I could think about to send the report from the container, and got every possible error.
[15:20] <fgimenez> elopio, great, it's working so \o/
[15:21] <elopio> fgimenez: well, now the problem are the examples tests. They raise and exception, but when I try to print the stderr, it's not raised.
[15:21] <elopio> damn it with travis.
[15:22] <fgimenez> elopio, let me know if i can be of any help
[15:22] <elopio> fgimenez: about that test, I would prefer to discuss with mvo about possible solutions. It was one of the first tests added after a UI change, so I wouldn't like to remove it.
[15:22] <elopio> I'm fond of it :)
[15:22] <elopio> fgimenez: is it failing often, or was it just one time weirness?
[15:22] <elopio> I can put it in a loop.
[15:23] <fgimenez> elopio, only once in a lot of executions
[15:26] <elopio> this is a great use for jenkins.
[15:26] <elopio> just loop running one test to get more info. I'll try to make the job soon, but I still owe a couple of things from yesterday.
[15:27] <elopio> like the dockers in the hub. I'll finish that first.
[15:27] <mvo> elopio: we make it a long operation by creating a fake os update first
[15:27] <mvo> elopio: well, longer - and also throttle the download of the fakestore
[15:28] <elopio> ahh, that's right. Now the update takes a lot less.
[15:28] <elopio> ok, going for the car. bbs.
[15:39] <elopio> that was a lot faster than what I thought.
[15:40] <elopio> and now I have a car for the rest of the week. No idea what to do with it, though.
[15:41] <kyrofa> elopio, hahaha
[16:02] <elopio> kyrofa: can you give me a hand debugging this? https://paste.ubuntu.com/14590836/
[16:02] <elopio> how can I see what causes make to exit != 0? is there a verbose flag or something?
[16:03] <kyrofa> elopio, that's the most unhelpful error message I've ever seen :P
[16:05] <mvo> jdstrand: thanks for your work on the squashfs-tools \o/
[16:05] <kyrofa> elopio, with cmake you can to VERBOSE=1
[16:05] <kyrofa> elopio, but the actual error should be above what you pasted...
[16:07] <jdstrand> mvo: sure. Now I need to see about different archs. I see some code about little endian vs big
[16:08] <mvo> jdstrand: iirc its nowdays (v4) all one endianess, that might be from the old v2 or v3 squashfs format. but mind you, I'm not an expert :)
[16:08] <jdstrand> mvo: oh, btw, kgunn needed a new os snap for the latest ubuntu-core-security when you have a chance. I don't hink he is blocked on it per se (perhaps he can comment)
[16:08] <jdstrand> mvo: we'll see! :)
[16:08] <mvo> jdstrand: sure, happy to update. amd64?
[16:08] <jdstrand> I think so
[16:08] <jdstrand> kgunn: ^ ?
[16:08] <mvo> ta
[16:08] <kyrofa> elopio, can I see more of that log?
[16:08] <kyrofa> elopio, is that in travis somewhere?
[16:09] <elopio> kyrofa: I tought python was swallowing the stderr, but it seems it just doesn't print anything.
[16:09] <elopio> ubuntu@xenial:/home/elopio/build/snapcraft/examples/ros/parts/catkin-tutorials/build/build_isolated/beginner_tutorials$ VERBOSE=1 make -j2 -l2 || echo $?
[16:09] <elopio> 139
[16:09] <elopio> kyrofa: yes, one second.
[16:10] <elopio> kyrofa: https://travis-ci.org/ubuntu-core/snapcraft/jobs/103794957
[16:10] <elopio> search for Failed to process package 'beginner_tutorials'
[16:15] <kyrofa> elopio, wow, that really is all it gave you
[16:15] <kyrofa> elopio, I have no idea what happened there. Yeah, try the verbose
[16:17] <elopio> kyrofa: but did you see my line with verbose above? It exits with 139, but prints nothing.
[16:17] <kyrofa> elopio, ...
[16:20] <kyrofa> elopio, I'm honestly clueless. I've never seen that
[16:20] <kyrofa> elopio, what are you testing here?
[16:21] <kyrofa> elopio, the only time I've seen anything similar was yesterday, when make was segfaulting for me
[16:21] <elopio> that's what I hate about this. I'm sure I saw it before, at some time. But I've seen so many travis errors this days that I'm confused.
[16:21] <elopio> kyrofa: I'm trying ot build from a xenial lxd.
[16:22] <elopio> at least now I can reproduce it on my local xenial lxd, so I don't have to wait for travis' output.
[16:22] <kyrofa> elopio, I'm so tired of ROS barfing on xenial
[16:23] <elopio> kyrofa: oh, but there are 7 tests failing with the same.
[16:23] <elopio> sorry, I picked you on ros because I thought you would magically tell me the solution :)
[16:23] <kgunn> mvo: jdstrand yep, amd64
[16:23] <kyrofa> elopio, hmm. You can reproduce on xenial though? Are they all `make` failures?
[16:24] <elopio> kyrofa: I'm trying that, but the costa rican archive is out of sync. So trying another mirror and goes even slower...
[16:24] <elopio> will know soon.
[16:25] <kyrofa> elopio, AH! mvo
[16:25] <kyrofa> elopio, mvo just installed make on my xenial lxc. IT SEGFAULTS!
[16:25] <kyrofa> elopio, I bet you $100 that's your problem
[16:25] <kyrofa> elopio, oh I'm so happy I'm not insane
[16:26] <mvo> kyrofa: ohhhh! so a real upstream make bug!
[16:26] <kyrofa> mvo, yeah!
[16:26] <kyrofa> mvo, dang. That's so upstream I don't even know where I'd log such a bug
[16:26] <elopio> oh come on, now also the main archive gives a hash mismatch.
[16:27] <elopio> kyrofa: what command are you running to get the segfault?
[16:27] <kyrofa> elopio, make -v :P
[16:27] <kyrofa> elopio, everything seems to segfault except make -h
[16:27] <elopio> oh, wow.
[16:28] <kyrofa> Yeah, terrible
[16:28] <elopio> it segfaults when I run it as root, but when I run it as user it doesn't say anything.
[16:28] <elopio> pindonga: I give up. Even make is failing on me.
[16:28] <kyrofa> elopio, yeah I went back to good-old trusty
[16:28] <kyrofa> trusty trusty
[16:28] <pindonga> elopio, :(
[16:29] <elopio> kyrofa: so, this happens only on xenial lxc, right? on your real xenial machine it works?
[16:29] <kyrofa> elopio, I fist experienced in on my rpi2 in classic, so no
[16:29] <kyrofa> Well wait
[16:29] <kyrofa> That's actually lxc too
[16:29] <kyrofa> right?
[16:30] <kyrofa> mvo, ^^
[16:30] <kyrofa> elopio, I don't actually have a xenial machine
[16:30] <mvo> kyrofa: not lxc, more like a chroot, it using unshare lightly but mostly a chroot
[16:40] <elopio> kyrofa: same version in real machine and in container. 4.1-2. It only fails in the container.
[16:41] <kyrofa> elopio, very interesting!
[16:45] <mvo> kgunn: I put an updated ubuntu-core snap into the edge channel, once I tested it I will promote to the other channels (I guess you will still get it because all images default to edge iirc currently)
[16:45] <kgunn> mvo: ta
[16:50] <mvo> yw
[16:56] <elopio> it works from gdb.
[16:56] <elopio> mvo: any idea who to ping about this make segfault?
[17:00] <elopio> https://paste.ubuntu.com/14591130/
[17:30] <kyrofa> elopio, easy review when you have a minute: https://github.com/ubuntu-core/snapcraft/pull/246
[17:31] <elopio> kyrofa: was the change in the indentation on purpose?
[17:32] <kyrofa> elopio, yeah, it's not valid markdown
[17:32] <kyrofa> elopio, and we have another PR that wants it done but it hasn't been updated in a while
[17:32] <kyrofa> elopio, so I figured I'd just tackle it here
[17:32] <elopio> so it was a trap!
[17:33] <elopio> simple, but I have to read it all :)
[17:33] <kyrofa> elopio, yeah, stupid git
[17:34] <elopio> don't worry, I'm on it.
[17:34] <kyrofa> elopio, if you trust me, I promise all I added was the build-packages
[17:35] <elopio> kyrofa: ok, I will trust you but just because I'm hungry ;)
[17:35] <kyrofa> elopio, mmm
[18:28] <mvo> elopio: did you got an anser already? do you have some more info? so it happens on amd64 in a lxc xenial env, right?
[18:32] <Lefteris`> kyrofa: I managed to automate it as I had planned with a nice local plugin for snapcraft.
[18:32] <Lefteris`> kyrofa: What does not work now is the framework's policy
[18:33] <Lefteris`> kyrofa: Before I had the framework policy in meta/
[18:34] <kyrofa> Lefteris`, you'll need to specify it in the snapcraft.yaml. Did you?
[18:34] <Lefteris`> same level as package.yaml, but now with snapcraft how do I do it?
[18:34] <Lefteris`> (no I did not write anything in snapcraft)
[18:36] <Lefteris`> in short everything I had in meta/ when I snapify a directory ... where should it be if I use snapcraft?
[18:41] <enoch85> kyrofa, here?
[18:41] <kyrofa> enoch85, yessir!
[18:44] <Lefteris`> hmm there is an integration test having `framework-policy: dir` inside a snapcraft yaml
[18:44] <Lefteris`> will go with that :)
[19:59] <elopio> mvo: sorry, late reply. I reported this: https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1536727
[20:06] <kyrofa> elopio, even easier than the last one: https://github.com/ubuntu-core/snapcraft/pull/248/files
[20:18] <kgunn> mvo: hmm, just pulled an image using core rolling --oem=generic-amd64/stable --channel edge...and system-image-cli -i shows it's from jan 12, expected?
[20:18] <kgunn> thot it might be updating soon..
[20:22] <mvo> kgunn: yes, we stopped updating using system image, please use http://people.canonical.com/~mvo/all-snaps/ for now, unfortuantely the ubuntu-device-flash in xenial is not updated there is a branch review pending still
[20:23] <kgunn> np, thanks mvo
[20:23] <mvo> kgunn: here is a bit of the background https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html
[21:17] <circ-user-edG3L> hi
[21:17] <circ-user-edG3L> how do i download xenial version of snappy?
[21:17] <circ-user-edG3L> or is that not available currently?
[21:17] <kyrofa> circ-user-edG3L, use http://people.canonical.com/~mvo/all-snaps/
[21:18] <circ-user-edG3L> kyrofa: k thx
[21:18] <circ-user-edG3L> kyrofa: are you at the ubucon?
[21:18] <kyrofa> circ-user-edG3L, note that it's under heavily development, though
[21:18] <kyrofa> circ-user-edG3L, unfortunately no. Too close to having a baby to leave!
[21:18] <circ-user-edG3L> kyrofa: oh.  congratulations!.
[21:18] <kyrofa> circ-user-edG3L, haha, thanks
[21:19] <circ-user-edG3L> kyrofa:  is mir spec for xenial ready yet? or still being modified?... is there a timeline for mir/xmir ?
[21:19] <kyrofa> circ-user-edG3L, kgunn is your man there
[21:19] <circ-user-edG3L> kyrofa: k thx
[21:19] <dbuellough> hello
[21:20] <circ-user-edG3L> kgunn: is mir spec for xenial ready yet? or still being modified?... is there a timeline for mir/xmir ?
[21:20] <circ-user-edG3L> dbuellough: hi
[21:23] <kyrofa> circ-user-edG3L, did you just see sergio and manik's talk?
[21:23] <ogra_> still running :)
[21:23] <circ-user-edG3L> kyrofa: im watching it now
[21:23] <kyrofa> circ-user-edG3L, the live stream is broken :(
[21:23] <circ-user-edG3L> kyrofa: https://www.youtube.com/watch?v=1C8T4Mp9aSM
[21:23] <circ-user-edG3L> kyrofa: it works
[21:24] <kyrofa> circ-user-edG3L, terrible audio here
[21:25] <circ-user-edG3L> kyrofa: :{
[21:25] <enoch85> I can confirm that audio is bad
[21:33] <camako> Trying to publish a snap on the store. It fails with "ERROR: manifest malformed: hooks/mir-server is empty...". How do I fix this?
[21:33] <camako> My snap -->  https://myapps.developer.ubuntu.com/dev/click-apps/share/4255e10a7324e99961bb6a15b0c4368692e318870c3e527339100387379a08c96802720a73162eabafce/
[21:42] <kgunn> circ-user-edG3L: i assume you're asking here so specific to snappy?
[21:43] <kgunn> we have it working, just worked thru sec profiles for mir recently with the sec team...so waiting for those to flow thru
[21:50] <circ-user-edG3L> kgunn: yes.
[21:52] <circ-user-edG3L> kgunn: ok.  so spec is finalized?
[21:55] <circ-user-edG3L> kgunn: or still tbd?
[21:55] <circ-user-edG3L> kyrofa: I recorded the demonstration if you want to see it
[21:57] <kyrofa> circ-user-edG3L, yes please
[21:59] <circ-user-edG3L> kyrofa: can i have your email address to send?
[21:59] <circ-user-edG3L> kyrofa: im uploading to youtube
[22:01] <kyrofa> circ-user-edG3L, just paste the url here if you don't mind, I'm sure other people would like to watch as well
[23:48] <aatchison> hello!
[23:49] <sergiusens> aatchison, http://people.canonical.com/~mvo/all-snaps/
[23:50] <sergiusens> utlemming, hey, I'm getting reports from aatchison that the vagrant images don't work. Are you still maintaining those?
[23:51] <utlemming> sergiusens: interesting...
[23:51] <utlemming> sergiusens: yup, looking
[23:52] <sergiusens> utlemming, also, out of the blue, do we have rolling/all snaps images for vagrant?
[23:53] <utlemming> sergiusens: I haven't checked since last week, but if that is the default for u-d-f, then yes
[23:53] <aatchison> I'll paste bin the results
[23:53] <sergiusens> utlemming, oh, it's not; it needs a non backwards compatible u-d-f
[23:54] <utlemming> sergiusens: then we do not
[23:55] <aatchison> http://paste.ubuntu.com/14593617/
[23:55] <sergiusens> utlemming, can we use a different u-d-f to set that up? Calling a different image creator?
[23:58] <utlemming> aatchison: windows/mac?
[23:58] <utlemming> sergiusens: can you send me the instructions on that? Better yet, file me a bug with the instructions and I can try to get to it.
[23:58] <aatchison> utlemming, Ubuntu 15.10
[23:59] <aatchison> ok
[23:59] <utlemming> aatchison: where did you procure your version of vagrant....this looks like a bug in Vagrant/Ruby, not in the image itself.
[23:59] <utlemming> aatchison: double checking