[06:42] <dholbach> good morning
[07:30] <clobrano> buongiorno all :)
[07:40] <dholbach> hey mvo, who do I ping about Snappy Personal?
[07:45] <dholbach> tedg, looks like snapcraft builds currently fail: https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily
[07:48] <mvo> dholbach: seb128 probably, not sure who else is wokring on this
[07:49] <seb128> not me, I worked on the image back then but it was lower in priority and I basically moved back to other things
[07:50] <dholbach> seb128, do you know who I could ping? willcooke and kgunn maybe?
[07:50] <seb128> lol
[07:51] <seb128> trying to make that fallback on me forced through managers? ;-)
[07:51] <dholbach> no
[07:51] <seb128> that image is just unmaintained atm
[07:51] <dholbach> I would just like to know who is working on it and what the state of things is
[07:51] <dholbach> a quick answer is really enough
[07:51] <seb128> but talk to kgunn if you think it should have more resources assigned
[07:51] <seb128> nobody is
[07:51] <dholbach> I wasn't after "hey, somebody fix my X, Y and Z issue" :)
[07:51] <dholbach> I'll ping Kevin later on
[07:51] <dholbach> thanks
[07:51] <seb128> that's basically what I said, it was lowered in priority and resources moved away afaik
[07:52] <dholbach> seb128, it's just a question I'd like to have answered for a presentation on the weekend
[07:52] <dholbach> ok
[07:52] <seb128> let me know what kevin says
[07:52] <dholbach> will do
[07:52] <dholbach> thanks
[07:53]  * dholbach relocates to the office, brb
[08:01] <clobrano> Hi Chipaca, I wouldn't be pedantic, but any news about Bug #1496319 and udev rules? :)
[08:34] <seb128> you guys are aware that https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.6ubuntu1 didn't migrate out of wily-proposed because it fails to build?
[09:01] <JamesTait> Good morning all; happy Monday, and happy Clean Your Virtual Desktop Day! 😃
[09:06] <mvo> ogra_: hi, I accidently triggered your initird partition resize in one of my image on wily, I get "parted: invalid option -- '1' in resize-writable.log. the image may be older, just wanted to let you know
[09:07] <ogra_> mvo, hmm
[09:07] <ogra_> do you know how you actually triggered that ?
[09:09] <seb128> mvo, ogra_, did you see that ubuntu-snappy is still on 1.5 in wily because 1.6 fails to build?
[09:09] <seb128> unsure if that's something you want to fix before release
[09:10] <ogra_> "release" heh
[09:10] <ogra_> but yeah ... for the devs that use wily desktops that probably makes sense :)
[09:10] <mvo> ogra_: I removed system-a and system-b
[09:10] <mvo> :P
[09:10] <ogra_> mvo, ah, so a typical usecase then :)
[09:10] <mvo> ogra_: *cough*
[09:11] <mvo> ogra_: this why I said "fyi"
[09:11] <ogra_> did you leave writable intact ?
[09:11] <mvo> ogra_: it may become one, this is a system booting from a kernel snap
[09:11] <mvo> ogra_: I did, I wanted to double check if my system keeps booting just from kernel/os snap and the resize was a bit of a unexpected thing (a nice one though)
[09:12] <mvo> ogra_: but like I said, could be a much older image
[09:12] <ogra_> there might be a check missing
[09:12] <ogra_> (i think the findfs runs only after the free space check and there might be nothing checking if it actually returned something
[09:12] <ogra_> )
[09:13] <mvo> ogra_: oh, fun - so something returns "-1" for size and parted assumes its a parameter :) ?
[09:14] <ogra_> yeah, something like that .... i'll have to check the code, just a theory
[09:14] <mvo> ok, not important, like I said, not relevant now, but might be a nice feature for 15.04->16.04 upgrades that your script can reclaim the space
[09:15] <ogra_> ah, no. wait-for-root for "writable" and findfs run first
[09:17] <ogra_> so it isnt that
[09:29] <Chipaca> clobrano: that's not what "pedantic" means. And if it were my bug, I would've had less patience than you :)
[09:29] <Chipaca> good morning all
[09:29] <Chipaca> mvo: are we on github yet?
[09:31] <Chipaca> JamesTait: I am starting to suspect you're making up these Days
[09:31] <JamesTait> Chipaca, it's also Evaluate Your Life Day....
[09:32] <Chipaca> dammit
[09:32] <mvo> Chipaca: I asked to wait 1 week, i.e. do the release with LLP
[09:32] <Chipaca> mvo: ahh, i missed that
[09:32] <Chipaca> mvo: that is entirely sensible! thanks
[09:37] <davmor2> Chipaca: on a plus side it did trigger this as my tune for JamesTait day https://www.youtube.com/watch?v=WUOtCLOXgm8
[09:37] <Chipaca> i'm going to need bigger speakers
[09:39] <davmor2> Chipaca: virtual cleaning, with virtual woman, in a virtual environment, it was as close to virtual desktop as I could get :)
[09:54] <ogra_> panic: can not set option description for "package name"
[09:54] <ogra_> ...
[09:55] <ogra_> FAIL	launchpad.net/snappy/cmd/snappy	0.022s
[09:55] <ogra_> mvo, Chipaca ^^^ thats the ubuntu-snapy FTBFS
[09:55] <ogra_> (in wily)
[09:55] <Chipaca> ogra_: noice
[09:56] <ogra_> https://launchpadlibrarian.net/218629818/buildlog_ubuntu-wily-amd64.ubuntu-snappy_1.6ubuntu1_BUILDING.txt.gz
[09:57] <mvo> ogra_: thanks
[09:58] <ogra_> same failure on all arches but powerpc
[09:59] <Chipaca> interestingly, doing bzr-builddeb locally gives me a different ftbfs :)
[10:00] <Chipaca> bah. There's the same one also.
[10:00] <Chipaca> src/launchpad.net/snappy/daemon/daemon_test.go:87: d.router.Walk undefined (type *mux.Router has no field or method Walk)
[10:00]  * Chipaca pokes
[10:00] <mvo> Chipaca: the way we set the options is different between different version of flags
[10:00] <ogra_> this build is old ...
[10:00] <mvo> Chipaca: for the other one you need a updated version of mux, its in the image ppa
[10:00] <ogra_> so could well be that another FTBFS joined the party over time
[10:01] <Chipaca> ah
[10:01] <mvo> Chipaca: I wonder why its failing now, can't rmember changing the goflags code or the goflags package
[10:04] <Chipaca> ah, schroot builddeb has the ppa set up already, going with that one
[10:05] <Chipaca> sergiusens: mo'in!
[10:09] <Chipaca> mvo: got the same error in schroot. Also an error in one of the helper tests...
[10:09] <mvo> Chipaca: could you pastebin the other error please?
[10:10] <Chipaca> http://pastebin.ubuntu.com/12859201/
[10:13] <mvo> Chipaca: heh, ok. that looks a lot like sbuild being special
[10:14] <Chipaca> mvo: oh yeah :)
[10:16] <Chipaca> probably need a .Skip() there
[10:17] <sergiusens> Chipaca, morning
[10:17] <Chipaca> sergiusens: you already answered a bit in the branch, but: would it be ok for u-d-f to use snapd?
[10:18] <Chipaca> directly, that is
[10:18] <Chipaca> or would you need a client library
[10:18] <sergiusens> Chipaca, only if snapd has SetArch or  similar
[10:19] <sergiusens> Chipaca, and ExtractSnap for the gadget as that has all the information on how to setup partitions, which snaps to bring in, etc
[10:20] <Chipaca> ExtractSnap?
[10:21] <sergiusens> Chipaca, this is where everything breaks btw. As this snapd on the host would need to support 15.04 and rolling builds
[10:21] <dholbach> hey sergiusens
[10:21] <Chipaca> sergiusens: not necessarily
[10:21] <sergiusens> Chipaca, right now we do 'snappy.Install' to a fake location
[10:22] <Chipaca> sergiusens: need to think about it a bit, but, you can have multiple snapds and only one rest client, and things should work
[10:22] <Chipaca> we'd need to have tests to that effect though
[10:22] <dholbach> sergiusens, shall we talk through the clinic later on? or are we good to go? I think I'd just snappify something simple like ddate, do the introductions and relay questions if that's all right.
[10:24] <Chipaca> there isn't a set architecture, and there isn't a way to setrootdir to have an install work, but they should be easy to add as cmdline args
[10:25] <sergiusens> dholbach, for the last step?
[10:26] <dholbach> sergiusens, we can do more if you like
[10:26] <sergiusens> Chipaca, right, I think we need to have more than an irc discussion to get this going. I need to order my brain on all the permutations that we need to cover
[10:27] <sergiusens> dholbach, I thought tedg was preparing something with cmake
[10:27] <sergiusens> dholbach, I do have a cmake/plugin override example in the works
[10:27] <dholbach> sergiusens, ok cool - I'll leave the example around, just in case
[10:27] <Chipaca> sergiusens: sprint at mvo's, the last week of october \o/
[10:27] <Chipaca> sergiusens: ie next week
[10:28] <Chipaca> 2015/10/19 11:26:18.407658 common.go:45: PANIC can not set option description for "package name"
[10:28] <Chipaca> mvo: ^ that is output in a *successful* test run
[10:28] <Chipaca> mvo: so it's a red herring
[10:29] <ogra_> Chipaca, nah, at dholbach's, then yoiu guys cal also come to ubucon ;)
[10:29] <Chipaca> i'll disable log in that panic-checking test
[10:29] <ogra_> *can
[10:29] <Chipaca> ogra_: +1
[10:29] <Chipaca> aren't they, like, neighbours?
[10:29] <sergiusens> Chipaca, next week is too soon to get a good fare ;-)
[10:29] <dholbach> sergiusens, or do ddate in a bit more detail, then quickly explain how fatcat is done (although that's probably not the best example as we have to have it ship its own libstdc++6) - not sure... what do you think?
[10:29] <Chipaca> sergiusens: no no; fares dip this soon before
[10:29] <ogra_> Chipaca, for american standards perhaps :)
[10:30]  * Chipaca remembers travelling 1Mm for an asado
[10:30] <sergiusens> dholbach, well if you do it from vivid no need to ship it :-P
[10:30] <mvo> Chipaca: yeah, the output is confusing its testing that its panicing if it can't find the option
[10:30] <ogra_> (but then under that standard berlin lies next to paris too :) )
[10:30] <sergiusens> dholbach, but I see your point
[10:31] <dholbach> sergiusens, I'm happy either way - it might generally illustrate how to do and when to consider it
[10:40] <Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/skip-homedir-no-schroot/+merge/274870
[10:40] <Chipaca> mvo: 1. skip that test in schroot; 2. turn off logs in that panic test
[10:42] <mvo> Chipaca: \o/
[11:05] <sergiusens> Chipaca, btw, did you see my messages from Friday about the megaMR and docopt?
[11:05] <Chipaca> sergiusens: megaMR?
[11:05] <Chipaca> sergiusens: wrt docopt, you linked me to docopt.go, is that the one you mean? otherwis eno
[11:32] <sergiusens> Chipaca, mega MR https://code.launchpad.net/~sergiusens/snapcraft/cleanup/+merge/274801
[11:33] <sergiusens> Chipaca, and docopt, it looks really nice but there is no i18n support (dev allude that all cli's are in English) and implementing subcommands is rather ugly
[11:33] <sergiusens> Chipaca, ugly as in the subcommand does a subprocess.call on a subcommand
[11:34] <sergiusens> Chipaca, e.g.; https://github.com/docopt/docopt/blob/master/examples/git/git.py
[11:34] <Chipaca> sergiusens: after pointing you at it i wondered about how/whether they'd support subcommands modularly
[11:35] <sergiusens> Chipaca, after seeing the presentation I really wanted that one to be the one (would of been a prince charming Disney story if so) :-)
[11:38] <ogra_> mvo, hmm, looking at your initramfs-tools MP ... why the insmod ? mount should properly triger a modprobe event here
[11:39] <mvo> ogra_: I don't know why, sorry, it did not figure it out automatically for me, but I can re-test and see if it was a one-time fluke
[11:39] <ogra_> thats surely a bug if it doesnt ...
[11:41] <ogra_> mvo,  if we cant get the kernel fixed we should add squashfs to the initramfs config instead of calling insmod though
[11:41] <sergiusens> Chipaca, I like this one, name clash and all, it is calling you http://click.pocoo.org/5/
[11:45] <mvo> ogra_: let me try again
[11:46] <Chipaca> sergiusens: ugh. the "i just discovered decoraters they are the best!!1!one!" library
[11:46] <mvo> lol
[11:47] <sergiusens> Chipaca, then there's https://github.com/zyga/guacamole ;-) (the syntax is a bit more complicated but is the same without decorators)
[11:48] <ogra_> mvo, also: http://paste.ubuntu.com/12859786/
[11:48] <ogra_> (not sure about loop, might be compiled int nowadays .... )
[11:50] <ogra_> ah, yeah, loop is builtin
[11:50] <mvo> ogra_: it looks like I don't need it anymore, I removed the insmod and it seems to be still happy. thanks for the diff, I addd it now
[11:51] <ogra_> mvo, yeah, drop the loop line though (got that from casper)
[11:51] <mvo> ta
[11:53] <ogra_> mvo, also in line 80 (root="LABEL=writable") you might want to use $writable_label instead of hardcoding the name (you use $writable_mnt in that function too, so it would be good to have all in variables)
[11:53] <mvo> ogra_: excellent suggesitons, thanks, will fix right after lunch
[11:53] <Chipaca> mvo: any idea why golint is suddenly mad at my branch? what changed in tarmac?
[11:54] <ogra_> mvo, beyond that, the code looks fine to me, will approve then ;)
[11:54] <ogra_> (indeed assuming it actually works :) )
[11:55] <mvo> ogra_: heh :) it does for me, but I will double check after lunch again
[11:55] <ogra_> i'll keep staring at it a bit, probably i find other nitpicks :)
[11:56] <ogra_> oh
[11:56] <ogra_> mount --move "$writable_mnt" "${rootmnt}/writable"
[11:56] <Chipaca> mvo: wrt lint, seems an updated golint is what happened
[11:57] <ogra_> with the new way "$writable_mnt" is "${rootmnt}" already ... not sure this line is clever
[11:58] <ogra_> (movind ourselves one level down ... )
[11:59] <ogra_> ah, no ignore that ... but there is something wonky here
[11:59]  * ogra_ will breed over it 
[12:02] <ogra_> hmm, we are essentially pullin out the carpet underneath ourselves with that line
[12:02] <Chipaca> mvo: updated the branch to pass lint again, care to give it a once-over?
[12:19] <Chipaca> sergiusens: wrt snapd and u-d-f, what i'm thinking is of making it easy for u-d-f to start snapd using systemd-activate and talking to it over a pipe or whatever is simplest in that scenario
[12:20] <sergiusens> Chipaca, and snapd will run fine on ubuntu classic?
[12:20] <Chipaca> sergiusens: today now, because there isn't a way to setrootdir
[12:20] <Chipaca> s/now/no/
[12:20] <Chipaca> sergiusens: but that's why i'm asking what's needed :)
[12:21] <sergiusens> Chipaca, right, if it runs fine in ubuntu classic and you don't forget to push the debs to tools-proposed, it's all going to be good
[12:21] <sergiusens> Chipaca, given all snaps, I don't know anymore
[12:22] <Chipaca> sergiusens: sounds like setrootdir, set arch, and a way to make apps not be sideloaded
[12:22] <Chipaca> s/apps/snaps/
[12:22] <sergiusens> Chipaca, but if we forget about all snaps, install to alternate locations, inhibit hooks, set the release to query the store
[12:22] <sergiusens> Chipaca, apps coming from the store should not be marked as sideloaded though
[12:22] <sergiusens> Chipaca, I think that is an introduced bug
[12:23] <sergiusens> recent one
[12:23] <sergiusens> Chipaca, but yay, origin
[12:23] <Chipaca> ah, of course, you don't sideload them, you tell snappy to install them (or do actually sideload, in which case you *want* them to be sideloaded)
[12:23] <sergiusens> Chipaca, they shouldn't be sideloaded, right,because of what you just said ;-)
[12:24] <Chipaca> sergiusens: apps coming from the store aren't marked as sideloaded. If you've found a case when that happens, drop everything and let me know :)
[12:49] <dholbach> sergiusens, tedg: I filed https://bugs.launchpad.net/snapcraft/+bug/1507573
[12:50] <sergiusens> dholbach, I was going to ask you what the heck that meant as bzr bd works just fine
[12:52] <dholbach> sergiusens, let me see if I can reproduce it
[12:53] <sergiusens> dholbach, this is probably related to the test_suite='snapcraft.tests' line I added to setup.py
[13:05] <dholbach> sergiusens, try with and without python3-autopilot
[13:05] <dholbach> that might be the issue
[13:06] <dholbach> yep
[13:08] <dholbach> https://code.launchpad.net/~dholbach/snapcraft/1507573/+merge/274889
[13:11] <tedg> sergiusens: dholbach: I finally got my ginac example working last night, but it required a fix, and ended up being autotools.
[13:12] <dholbach> tedg, cool - are you going to present it later on?
[13:14] <tedg> dholbach: At the clinic, right?
[13:15] <dholbach> yeah
[13:28] <jdstrand> mvo: hi! ping re snappy-debug
[13:30] <Chipaca> jdstrand: hi! ping re killing click-apparmor with fire :-p
[13:30] <mvo> jdstrand: uh, sorry, we plan a new snappy release for end of this week, I got a bit distracted because of this
[13:31] <jdstrand> Chipaca: I think I mentioned I would very much appreciate help with that ;)
[13:31] <jdstrand> Chipaca: but yes, it is definitely something we need to do
[13:32] <jdstrand> unfortunately, higher priority items keep getting added to our plate that trump that one
[13:32] <Chipaca> jdstrand: ok, here's the thing: i wouldn't know where to start :-/
[13:35] <jdstrand> mvo: I'm not sure what you are communicating. do you want me to remove valgrind, fix up the packaging and upload?
[13:36] <mvo> jdstrand: if you could do that, that would rock, sorry for being not clear, I just tried to say that I had not had time to work on this yet :/
[13:39] <jdstrand> mvo: I'm wondering if I should just upload it without gdb, etc since it would be nice if this was available on arm
[13:43] <mvo> jdstrand: +1
[13:43] <mvo> jdstrand: and we add the other bits later
[13:43] <sergiusens> dholbach, why would I want python3-autopilot? Do we use anything from that at all?
[13:44] <balloons_> dholbach, perhaps we should broach the topic in here instead with the rest of the team.
[13:44] <dholbach> sergiusens, i don't know
[13:45] <sergiusens> dholbach, lol, it does not make sense :-)
[13:45] <dholbach> sergiusens, it makes it work :)
[13:45] <sergiusens> dholbach, right, I don't have anything autopilot locally here
[13:46] <dholbach> then one of its deps?
[13:46] <jdstrand> mvo: ok, I'll just do that then
[13:46] <sergiusens> dholbach, oh, maybe testutils
[13:46] <dholbach> aha?
[13:47] <dholbach> sergiusens, I'll investigate
[13:49] <sergiusens> dholbach, http://trac.10920.n7.nabble.com/Can-t-run-the-unit-tests-ImportError-No-module-named-tests-td31160.html
[13:49] <sergiusens> maybe that
[13:52] <jdstrand> mvo: ok, I created https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-debug
[13:53] <jdstrand> mvo: that has what is in the store. I will now remove the non snappy-security bits, commit and upload to the store. that way, it'll be easy to revert and pick up later
[13:57] <tedg> sergiusens: Can you look at this before the clinic today? https://code.launchpad.net/~ted/snapcraft/autoreconf/+merge/274893
[13:57] <tedg> sergiusens: Bugs found in making the demo :-)
[14:01] <sergiusens> tedg, you can add build packages to the yaml itself, but sure lets look at this
[14:03] <mvo> jdstrand: \o/
[14:04] <tedg> sergiusens: Oh, I thought that was only for plugins.
[14:10] <sergiusens> tedg, I guess all or mostly all of the autotools based projects will use libtools, not sure about bison
[14:15] <tedg> sergiusens: Yeah, makes sense. Let me refactor.
[14:16] <sergiusens> tedg, in trunk I think build-packages can even go into the part (instead of top level snapcraft.yaml)
[14:17] <tedg> sergiusens: Yup, verifying by building now.
[14:30] <tedg> sergiusens: So this looks a little weird, I mean libfoo-dev seems like it shoudl be a "build-package" but yet, that doesn't seem like what we want.
[14:30] <tedg> sergiusens: Curious if it should be "host-packages" or something.
[14:31] <tedg> sergiusens: Or handle build packages by installing them onces, but stage-packages twice. So then you only get some into stage
[14:34] <sergiusens> tedg, I see your point and yes it is confusing if you come from debian/control
[14:34] <sergiusens> tedg, I think of it as build-package just drives the build
[14:34] <sergiusens> tedg, stage-packages is anything you want in the part/snap (a -dev will bring in the lib which you would want).
[14:34] <tedg> sergiusens: Yeah, I think it would be nice though, just to make the snap smaller.
[14:35] <sergiusens> but certainly confusing
[14:35] <sergiusens> I worked around my line of thinking to get used to it
[14:35] <tedg> sergiusens: The current build-packages sucks because if you're using a different distro version from the host it won't work.
[14:35] <sergiusens> tedg, and no fileset usage I bet ;-)
[14:40] <jdstrand> oh noes
[14:41] <jdstrand> how does one recover from this: http://paste.ubuntu.com/12861487/
[14:41] <jdstrand> this is on a bbb
[14:41] <mvo> jdstrand: uh, sorry - this is a transient bug
[14:44] <mvo> jdstrand: you need to manually rename the full named kernels in /boot/uboot/{a,b}/  to the short (vmlinuz) name
[14:44] <mvo> jdstrand: same for initrd
[14:44] <jdstrand> mvo: this is then fixed after this upgrade?
[14:44] <tedg> sergiusens: bison dropped
[14:46] <dholbach> sergiusens, https://code.launchpad.net/~dholbach/snapcraft/1507573/+merge/274889 updated
[14:47] <mvo> jdstrand: yes, its a version of snappy that gets this wrong
[14:47] <ogra_> tedg, if you drop bisons you have to add wombats ... thats an old rule :)
[14:48] <jdstrand> erf
[14:48] <jdstrand> I got past that, now:
[14:48] <jdstrand> error from system-image-cli: [Errno 2] No such file or directory: '/etc/system-image/archive-master.tar.xz'
[14:49]  * jdstrand copies from /writable/cache/system/etc/system-image/
[15:00] <tedg> ogra_: Are you using the Alix board as a router and then putting a WAP on the other side?
[15:06] <doctorSnappy> oh, 1h early
[15:06]  * doctorSnappy i'm not a real doctor
[15:09] <cmk> any1 online?
[15:09] <sergiusens> tedg, added  comment to your MP
[15:10] <vmayoral> sergiusens: morning, we've tested what we discussed last week
[15:10] <sergiusens> vmayoral, sdcard?
[15:10] <sergiusens> vmayoral, how did it go?
[15:11] <vmayoral> sergiusens: pretty much the same, no big changes
[15:11] <sergiusens> vmayoral, have you tried disconnecting everything from the usb bus as well?
[15:12] <vmayoral> yes, boot time reduces a bit ~15 seconds but the "snappy info" command takes the same
[15:13] <vmayoral> the issue that we saw with the autopilot (for the drones) remains active
[15:13] <sergiusens> vmayoral, so even disconnecting everything from the bus (wifi, vide camera, etc) has no impact?
[15:13]  * sergiusens invokes ogra
[15:14] <vmayoral> sergiusens: yes, tests have been made with only Erle-Brain 2 (RPi2 + shield with power electronics for actuators)
[15:14] <sergiusens> vmayoral, what about just the rpi2 with no shield?
[15:15] <sergiusens> dholbach, I have bad news, my network connection seems to be degrading
[15:15] <vmayoral> sergiusens: haven't tried that but i doubt that's the issue since Debian FS works perfectly with the shield
[15:15] <sergiusens> dholbach, I'll keep you posted
[15:15] <dholbach> thanks sergiusens
[15:15] <ogra_> vmayoral, snappy info takes long for you ?
[15:16] <tedg> sergiusens: Done. bug 1507648
[15:16] <vmayoral> ogra_: in the tests, the first time it took 16 seconds, following attempts about 4 seconds each
[15:16] <elopio> I'm going to upgrade my openwrt.
[15:16] <elopio> I might be away for a month. Wish me luck.
[15:17] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ time snappy info|grep real
[15:17] <ogra_> real    0m0.495s
[15:17] <ogra_> this is on an unmodified snappy RPi2 image
[15:18] <Guest42341> QUESTION: Can i have my private snappy app store?
[15:18] <ogra_> so it must be related to some changes you make
[15:18] <sergiusens> Guest42341, you are early
[15:18] <Guest42341> oh, thanks sergiusens
[15:18] <Guest42341> :))
[15:18] <Guest42341> how much early?
[15:18] <sergiusens> Guest42341, 40'
[15:18]  * sergiusens restarts router again
[15:19] <Guest42341> phew
[15:20] <ogra_> vmayoral, can you prefix the snappy info with "time" like i did above, so we can see if it is slow in user or sys time (sys would actually point to IO)
[15:21] <cmk> how to install apps on snappy personal desktop so that they appear in the UX/appbar?
[15:22]  * ogra_ doubts you can yet 
[15:22] <vmayoral> ogra_: can't put time into it now but will do. Ehat really concerns me is the issue with the autopilot binary in the Snappy FS
[15:22] <ogra_> personal is also not a project atm ... that image build was a one-off test thing
[15:22] <ogra_> vmayoral, well, the snappy fs isnt slow as you can see above ...
[15:23] <ogra_> so there must be something with your changes that snappy doesnt get along with
[15:23] <vmayoral> ogra_: not saying it's Snappy, probably we're doing something wrong
[15:23] <ogra_> well, or snappy is
[15:23] <ogra_> :)
[15:24] <ogra_> the point is that a default snappy isntall flies (oh the pun) on RPi
[15:24] <Chipaca> ok, i've got to go out for a bit, will bbl
[15:25] <vmayoral> ogra_: what really confuses me is that the same config produces a kernel on De
[15:25] <shuduo> i am tring to install mir.mvp-demo on a snappy instance from virtual machine but it always fails with "something went wrong :(". can anyone confirm it's expected or not?
[15:25] <vmayoral> *produces a kernel that works perfectly in Debian and gets issues in Snappy
[15:25] <vmayoral> t
[15:25] <ogra_> vmayoral, well, you cant really compare the two
[15:26] <shuduo> actually i'm trying to reproduce running qt snap application on snappy personal.
[15:26] <ogra_> different userspace ... kernel options might be missing between them etc
[15:27] <ogra_> kgunn, can you help shuduo ?
[15:27] <ogra_> is the Mir snap supposed to work ?
[15:31] <tedg> shuduo: I don't think the mir snap will work on personal.
[15:31] <tedg> Personal I believe has Mir bundled into the core.
[15:32] <shuduo> tedg, ogra_, kgunn, i refer to a doc "Snappy GUI Anyone?" but it's out of date. but it says mir snap works with virtual machine.
[15:35]  * Guest42341 live in 25 min
[15:35] <kgunn> shuduo: virtual machine of ubuntu core (not personal)
[15:36] <kgunn> shuduo: ubuntu personal image has not had the work/attention to support snap as a mir client download/installation
[15:37] <jdstrand> mvo: fyi, bbb is back in action
[15:39] <kgunn> shuduo: fwiw, i can confirm the mir.mvp-demo installs/runs fine on ubuntu core in vm or booted from thumb drive even
[15:39] <jdstrand> mvo: so, snappy-debug was set as a framework. is this so one doesn't have to type 'snappy-debug-snappy-security'?
[15:39] <kgunn> problem is currently the running of the mir client snaps (on top of  that)
[15:39] <shuduo> kgunn: hmm, i managed to run a recompiled mir snap on qemu now. but failed with virtualbox
[15:39] <jdstrand> mvo: wouldn't an alias in the store do the same thing?
[15:40] <kgunn> shuduo: i can only speak to the vm i used
[15:40] <jdstrand> mvo: or am I misremembering that point?
[15:40]  * kgunn gets on the phone so responses will be slower
[15:41] <mvo> jdstrand: yes, just for that, just for the short names to work
[15:41] <jdstrand> mvo: I really don't like this being a framework-- it isn't. there are no services, no framework-policy, no apps will consume it
[15:41] <mvo> jdstrand: a alias will mean you need to type "snappy-debug.strace" which is probably a good thing
[15:41] <mvo> jdstrand: yeah, I agree
[15:41] <shuduo> kgunn: i'm curious what vm you are using. can you see graphics screen show up with a big mouse cursor?
[15:42] <jdstrand> mvo: ok, so I'll remove the framework bit. maybe some thought needs to be put around something that is an app but with binaries with short name? I'm not sure. it is easy to commit to thinking about it though :)
[15:43] <kgunn> shuduo: virtual machine manager which can download from the sw store
[15:43] <kgunn> https://virt-manager.org/
[15:43] <kgunn> and yes, i can see the big mouse cursor
[15:43] <shuduo> kgunn: yes, i'm using vmm now and i can see graphic screen with a mouse cursor
[15:43] <mvo> jdstrand: :)
[15:44] <kgunn> shuduo: right, and there is a problem with running of mir client on that demo do some install pathing changes i believe
[15:44] <kgunn> and tbh, i am thinking we need to move our effort over to snapcraft
[15:44] <shuduo> kgunn: let me try install mir.mvp-demo again. i'm trying to reproduce what Darren Landoll did as he said he managed to make QT app snap working with snappy personal
[15:46]  * ogra_ points out again that there is no actuallyy snappy personal image ... it was an experimental proof of concept thing to prove it can be built 
[15:47] <ogra_> *no actual
[15:50] <dholbach> we are going to start the broadcast on ubuntuonair.com in about 10 mins
[15:51] <genii> dholbach: Do you have an URL for that?
[15:51] <dholbach> genii, http://ubuntuonair.com :)
[15:51] <genii> Heh, OK
[15:52] <cmk> https://youtu.be/0Ma4Wvppzcs
[16:03] <dholbach> does the video work? everything working fine so far?
[16:03] <jeffesquivels> dholbach: yes
[16:03] <dholbach> if you have questions, please prefix them with QUESTION:
[16:03] <dholbach> so we can more easily pick them up :)
[16:11] <shuduo> kgunn: i installed a fresh new instance on vm. it still got failure on install mir from store as before. i wonder the command line 'snappy install mir' output 'package not found' even it can be search out.
[16:11] <fgimenez> nice evening everyone o/
[16:17] <dholbach> any questions so far?
[16:18] <tedg> http://www.ginac.de/
[16:19] <Rlyeh> QUESTION:Do plugins shipped with snapcraft or we can make it ourselfs?
[16:20] <ogra_> Rlyeh, you can indeed create your own like sergiusens just demonstarated
[16:20] <ogra_> *demonstrated
[16:20] <dockydo> you have an error
[16:20] <Rlyeh> Thanks, i have some delay, sorry
[16:21] <dholbach> no worries :)
[16:21] <dholbach> we'll answer it on the hangout in a sec as well, just to be sure
[16:21] <ogra_> QUESTION: why do you need -dev packages for runtime deps ?
[16:24] <Rlyeh> QUESTION:would you please describe how to define architecture? I defined "armhf", but the package built for amd64(my pc)
[16:24] <shuduo> kgunn: sorry install mir.mvp-demo can be processed. pls ignore prev msg
[16:26] <kgunn> QUESTION: so with the stage packages, when you pull, you only need to call out the first level of dependencies? it'll grab all the sub-deps...
[16:26] <kgunn> ?
[16:27] <tedg> http://paste.ubuntu.com/12862605/
[16:27] <kgunn> (sorry i may be laggy)
[16:27] <LarreaMikel> QUESTION: If I undestand well, to build snaps for rp2, you have to develop them on the rp2?
[16:28] <ogra_> LarreaMikel, you have to develop them on armhf
[16:29] <ogra_> LarreaMikel, that can as well be a qemu-static-arm chroot (built via qemu-deboostrap) on your PC ... sadly that doesnt work for all languages (i.e. go and .net wouldnt work) which is why we cant make a wrapper as default thing for it
[16:29] <LarreaMikel> ogra_ thanks ;)
[16:29] <mattyw> LarreaMikel, if you use go you can cross compile out of the box
[16:30] <mattyw> more or less
[16:30] <ogra_> well, snapcraft doesnt support it
[16:30] <ogra_> as sergio just explains :)
[16:32] <dockydo> what does EINFUGEN means?
[16:32] <ogra_> INSERT
[16:32] <ogra_> :)
[16:32] <dockydo> thanks :D
[16:36] <dholbach> sorry
[16:36] <dholbach> I hit the wrong button
[16:36] <dockydo> np
[16:37] <dockydo> is really over?
[16:37] <LarreaMikel> QUESTION: If you do "snap run" on the rp2, it tries also to run on an emulator?
[16:37] <tedg> dockydo: Just a sec, dholbach hit the wrong button.
[16:37]  * ogra_ expects them to come back :)
[16:37] <sergiusens> dockydo, no, technical issues with hangouts
[16:37] <dholbach> sorry
[16:37] <dockydo> np :))
[16:37] <sergiusens> will come back in a minutes
[16:37] <sergiusens> minute
[16:37] <ogra_> LarreaMikel, you mean snapcraft run ?
[16:37] <dockydo> ok them, time to check for ota7
[16:38] <sergiusens> LarreaMikel, I'll answer that one in the hangout ;-)
[16:38] <LarreaMikel> ogra_: yes, sorry
[16:38] <ogra_> (it might try to, havent checked :) )
[16:39] <ogra_> dockydo, the phone will notify you anyway ;)
[16:40] <dockydo> ogra_: i know but it can't help myself :))
[16:40] <ogra_> haha
[16:40] <dholbach> sorry, we're back on https://ubuntuonair.com/ now
[16:40] <dholbach> http://www.youtube.com/watch?v=a0yK8ZeYcZg
[16:40] <ogra_> popey, ^^^ we need to put some tetris into the check for updates dialog on the phone ;)
[16:40] <dholbach> you might have toload the ubuntuonair.com page
[16:41] <dockydo> that would be nice :))
[16:41]  * ogra_ reloads
[16:41] <ogra_> "Starting soon..."
[16:42] <ogra_> someone take away these buttons from dholbach !
[16:42] <dockydo1> snappy remove buttons
[16:42] <dholbach> :-)
[16:43] <dockydo1> any plans for ubuntu home routers? (i'll buy 3)
[16:43] <ogra_> sergiusens, you can do it in a chroot easily (install snapcraft on rpi snappy)
[16:44] <ogra_> dockydo1, jdstrand has an experimental ufw snap already ... so you should eb able to easily build one
[16:44] <elopio> dockydo1: +1 or 2 here.
[16:45] <dockydo1> ogra_: first i have to figure it out how to install ubuntu snappy on my router :D
[16:45] <ogra_> dockydo1, http://pcengines.ch/ i like to use these for servers and routers etc
[16:45] <dholbach> developer.ubuntu.com/snappy/
[16:45] <dholbach> developer.ubuntu.com/snappy/snapcraft/
[16:45] <ogra_> i have one here running snappy realyl happily
[16:45] <dockydo1> thanks ogra_
[16:46] <ogra_> (the ALIX boards/systems)
[16:46] <dholbach> any more questions so far? :)
[16:49] <LarreaMikel> QUESTION: Maybe this is a silly question, but what will be the proper way to develop with snapcraft for the rp2? I mean, to develop and install the snap in the rp2?
[16:51] <nullagent__> QUESTION: which day was the ROS workshop?
[16:51] <dholbach> thanks a bunch everyone!
[16:51] <Rlyeh> QUESTION: Is it possible to write apps in c++?
[16:51] <sergiusens> LarreaMikel, hey, I'm just noticing your question, not sure it was answered, was it?
[16:51] <dholbach> nullagent__, we'll send out an email on the list about it and on the @ubuntudev social media accounts
[16:51] <dholbach> Rlyeh, sure
[16:51] <sergiusens> Rlyeh, what tedg demo'd was a c++ app
[16:51] <elopio> thank you.
[16:51] <tedg> nullagent__: Roughly two weeks
[16:52] <sergiusens> nullagent__, eagerly wait for the announcement from dholbach ;-)
[16:52] <dholbach> Rlyeh, you can use whatever's in Ubuntu - no matter if it's python or c++, go or java or anything else
[16:52] <nullagent__> Awesome thanks, using an overly complicated approach for ROS today can't wait to see what you guys came up with
[16:52] <Rlyeh> I think i missed it, I have to review the video, Thank you all, very useful
[16:53] <LarreaMikel> sergiusens: if you have answered it, i didn't realize... sorry
[16:53] <dholbach> and sign up for the mailing list here: https://lists.ubuntu.com/mailman/listinfo/snappy-app-devel
[16:53] <dholbach> it's low-traffic and you should be able to get answers for your questions there
[16:54] <ogra_> thanks guys !!!
[16:54] <dholbach> and sorry about me pressing the wrong button
[16:55] <dholbach>  /o\
[16:55] <ogra_> boys and buttons ... :)
[16:57] <popey> ogra_: I certainly believe we need more easter eggs in the phone :)
[16:57] <ogra_> :)
[17:06] <jdstrand> mvo: fyi, ok, see email on snappy-debug (both in the thread and on snappy-app-devel). I also filed https://bugs.launchpad.net/snappy/+bug/1507693 for adding the removed tools back. I did a preliminary triage; please reassign/adjust as necessary
[17:15] <dholbach> all right my friends - I call it a day - see you all tomorrow! :)
[17:30] <mvo> thanks jdstrand
[17:55] <sergiusens> elopio, any chance in looking at https://code.launchpad.net/~sergiusens/snapcraft/cleanup/+merge/274801
[17:55] <elopio> sergiusens: sure.
[18:40] <sergiusens> Chipaca, can you check if the two latest commits to https://code.launchpad.net/~sergiusens/snapcraft/cleanup/+merge/274801 satisfy your comments please?
[18:51] <sergiusens> elopio, hey, when you say hard to ready
[18:51] <sergiusens> elopio, is it the one liner or the longer paragraph?
[18:52] <sergiusens> elopio, your text proposal does not fit one line btw ;-)
[19:06] <elopio> it's the one liner.
[19:07] <elopio> I mean, it's to replace the one liner + the paragraph for just one line.
[19:08] <elopio> sergiusens: yes, what you pushed seems nice to me.
[19:11] <sergiusens> elopio, I edited to make it fit thought ;-)
[19:31] <sergiusens> elopio, if it is ok, a +1 would be great ;-)
[19:35] <elopio> sergiusens: I +1'ed 25 minutes ago
[19:43] <sergiusens> elopio, I didn't get the email :-) sorry
[20:00] <sergiusens> elopio, I didn't ask you yet, but what do you think about http://click.pocoo.org/5/ ?
[20:00] <sergiusens> elopio, and https://github.com/zyga/guacamole
[20:00] <sergiusens> elopio, I discarded docopt as it has no translations nor easy support for subcommands
[20:03] <kgunn> sergiusens: tedg so the clinic was timely for me, i was going to use my afternoon to get my mir dependencies sorted...so is it correct that the cmake snapcraft plugin
[20:04] <kgunn> is actually only using the stuff in the stage area to check for dependencies ?
[20:04] <kgunn> like, if i have all the dependencies for building mir on my machine...it won't think "ok"
[20:04] <sergiusens> kgunn, pkconfig and such? mostly yes
[20:04] <sergiusens> kgunn, if not it should be a bug
[20:04] <kgunn> sergiusens: nope, was just double checking my thinking
[20:05] <kgunn> thanks!
[20:05] <sergiusens> kgunn, it is rather hard to separate it, so there are corner cases where the system stuff is picked up but mostly a problem when doing python
[20:05] <kgunn> sergiusens: ok, i'll keep an eye out for it
[20:06] <kgunn> sergiusens: so i was using mir's debian/control file as a guide for dependencies....is that ok-ish or wrong ?
[20:06] <kgunn> as i end up adding a lot of -devs
[20:06] <kgunn> and i noticed someone say in ted's example that was naughty
[20:07] <sergiusens> kgunn, naughty? why?
[20:07] <kgunn> dunno
[20:07] <kgunn> :)
[20:07] <sergiusens> kgunn, Ideally, all your libs will be parts in the future
[20:07] <kgunn> sergiusens: you mean instead of pulling with apt ?
[20:07] <sergiusens> kgunn, and those parts will live in the wiki and you would just get 'build-packages'
[20:08] <sergiusens> kgunn, right, so for libraries it is mostly fine to use stage-packages as they don't have complex debian hooks running
[20:08] <sergiusens> but I do want to think that using debs is an intermediate solution to get there faster
[20:08] <kgunn> yeah i see what you mean
[20:09] <kgunn> it does feel like a crutch a little
[20:10] <tedg> sergiusens: I'm not sure that's the right message, I think that we should focus on debs being there for dependencies you want shared maintenance of.
[20:10] <tedg> sergiusens: And then you can use parts for dependencies you want to track yourself.
[20:20] <sergiusens> tedg, that's ok, but you buy into all the cruft debs bring in too
[20:20] <sergiusens> you can't fine tune the build and have to use the lib with all the config flags turned on
[20:21] <sergiusens> reason I consider it a shortcut
[20:21] <kgunn> sergiusens: just to confirm, there's a list i notice when i run stage called "blacklisted from manifest packages:"
[20:22] <kgunn> what's that about ?
[20:22] <tedg> sergiusens: Sure, and I think that if you want all the config flags turned on, you have a dependency that you care enough about to track.
[20:23] <tedg> kgunn: It's about the core level packages that are mostly taken care of by core. Like you don't need your own init daemon.
[20:23] <tedg> kgunn: It does need some fine tuning though. If you find one you think you need, tell us.
[20:23] <sergiusens> kgunn, those are depending packages that if installed, will create havok; you can explicitly call them out if wanted
[20:24] <sergiusens> kgunn, most of what is in that list comes from deb2snap
[20:24] <sergiusens> kgunn, the only important one is libc, we can't bundle that one without breaking things
[20:27] <kgunn> sergiusens: tedg i noticed libstdc++6 is in the list...i thot c++ stuff wasn't in the core (as i learned last week) ?
[20:27] <kgunn> or will you say, it is, but you can't link to it
[20:27] <kgunn> ?
[20:29] <tedg> I think that you end up pulling the one from teh build system in that case. But that's probably a bug in snapcraft.
[20:31] <tedg> Hmm, it didn't seem to get pulled into my ginac snap.
[20:33] <sergiusens> kgunn, tedg you indeed need libstdc++
[20:34] <tedg> Uhg, it's grabbing the system one: http://paste.ubuntu.com/12866379/
[20:36] <sergiusens> tedg, right, we saw that issue with dholbach last Friday
[20:36] <sergiusens> tedg, we indeed need to remove that from the list
[20:37] <tedg> jdstrand: Does the apparmor policy allow read access to /usr/lib/* or do we whitelist specific libraries?
[20:38] <tedg> Seems like we should match a white list in the apparmor profiles and the list in snapcraft.
[20:40] <sergiusens> tedg, we have a bug for that already
[20:41] <sergiusens> tedg, the review tools will whitelist libc dangling symlinks
[20:41] <sergiusens> all else is supposed to be in the snap
[20:41] <sergiusens> the, 'copy from the system' thing is to ease development
[20:41] <sergiusens> but that fails if working on wily and deploying to vivid
[20:42] <tedg> That's for the review tools, but it seems also that the apparmor profiles shouldn't allow reading the other libs that are in core to support core stuff.
[20:43] <sergiusens> tedg, it is allowed today, not sure about plans to block it
[20:46] <jdstrand> tedg: apparmor policy in the default template use the base abstraction (/etc/apparmor.d/abstractions/base). that allows, among other things, read access to /usr/lib/* and mmap for libraries under /usr/lib
[20:47] <jdstrand> we have no plans to block it currently. we allow a whole bunch of (safe) stuff in /usr/bin for shell scripting
[20:48] <jdstrand> and that will use various libs
[20:48] <jdstrand> (for example)
[20:49] <sergiusens> jdstrand, we could start blocking python2/3 soon though (not without previous agreement but it is a posibility)
[20:49] <jdstrand> we could list specific libraries, but that is going to be very hard to maintain and will create an antagonistic relationship with ddevelopers
[20:49] <jdstrand> yes
[20:49] <jdstrand> we could drop the python abstraction and the interpreter
[20:49] <jdstrand> same for perl
[20:50] <jdstrand> I would caution you to not do it in 15.04 though
[20:50] <jdstrand> unless you want to break people
[20:50] <jdstrand> or don't mind it
[20:53] <sergiusens> jdstrand, I do not want to break people, no :-)
[20:53] <sergiusens> elopio, simple one, not sure if the right thing, but I prefer it https://code.launchpad.net/~sergiusens/snapcraft/lifecycle/+merge/274947
[20:55] <jdstrand> sergiusens: other than my already expressed but reiterating now 'forcing bundling python adds 40M to the snap per arch', if the snappy folks feel like removing it from the policy is the way to go, file a bug and I'll do it
[20:55] <jdstrand> it would be a shame to have ufw be a 120MB package though
[20:55] <jdstrand> maybe it is 30M, not 40. still
[20:57] <sergiusens> jdstrand, well python was on its way out of the image, at least a desire for a while now
[20:57] <jdstrand> yes, I understand
[20:59] <jdstrand> sergiusens: but note previous conversation between me and Chipaca from earlier today
[20:59]  * sergiusens runs lastlog
[20:59]  * sergiusens guesses its about timeframe for appamor click
[21:02] <jdstrand> sergiusens: well, the move can be tied to the go absorption of policy generate (ie, no more python) or not (just get click compat off the image)
[21:03] <jdstrand> sergiusens: considering resources, I'll (once again) try to get it off the image, then snappy devs can rewrite it whenever it makes sense
[21:07] <kgunn> sergiusens: tedg so back to the pulling stage-packages, is the thinking that you'd really only do that once for a project (at least until you wanted to get "new" packages)
[21:08] <kgunn> like you wouldn't think people would regularly pull and rebuild their snap
[21:22] <tedg> kgunn: Generally yes, I'm not sure many people will build their snaps regularly themselves when we have support for builders.
[21:22] <tedg> kgunn: I think they'll only do that when testing various things, otherwise they'll align a builder to branch and have it do it.
[23:40] <elopio> sergiusens: $ sudo snappy install licensed.canonical
[23:40] <elopio> Installing licensed.canonical
[23:40] <elopio> licensed failed to install: snappy package not found
[23:47] <sergiusens> elopio, it might have been blocked, let me check
[23:48] <elopio> I think you tricked me :p
[23:50] <sergiusens> elopio, try now
[23:51] <elopio> sergiusens: thanks!
[23:51] <sergiusens> elopio, mind looking at https://code.launchpad.net/~sergiusens/snapcraft/maven/+merge/274964
[23:51] <sergiusens> elopio, it is pretty simple ;-)
[23:52] <elopio> sergiusens: looks good, but no test.
[23:56] <sergiusens> elopio, that is a hard one; integration or unit?
[23:57] <sergiusens> both are hard, first one implies a pom which I need to figure out, unit is, well, maybe unit ;-)
[23:58] <elopio> sergiusens: I'd say integration. But at this moment I'm only concerned about coverage, so make the one that gives you more confidence in preventing regressions.