=== timchen1` is now known as timchen119 === chihchun_afk is now known as chihchun === bigcat_ is now known as bigcat [06:42] good morning [07:30] buongiorno all :) [07:40] hey mvo, who do I ping about Snappy Personal? [07:45] tedg, looks like snapcraft builds currently fail: https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily [07:48] dholbach: seb128 probably, not sure who else is wokring on this [07:49] 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] seb128, do you know who I could ping? willcooke and kgunn maybe? [07:50] lol [07:51] trying to make that fallback on me forced through managers? ;-) [07:51] no [07:51] that image is just unmaintained atm [07:51] I would just like to know who is working on it and what the state of things is [07:51] a quick answer is really enough [07:51] but talk to kgunn if you think it should have more resources assigned [07:51] nobody is [07:51] I wasn't after "hey, somebody fix my X, Y and Z issue" :) [07:51] I'll ping Kevin later on [07:51] thanks [07:51] that's basically what I said, it was lowered in priority and resources moved away afaik [07:52] seb128, it's just a question I'd like to have answered for a presentation on the weekend [07:52] ok [07:52] let me know what kevin says [07:52] will do [07:52] thanks [07:53] * dholbach relocates to the office, brb [08:01] Hi Chipaca, I wouldn't be pedantic, but any news about Bug #1496319 and udev rules? :) [08:01] bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 === dholbach_ is now known as dholbach [08:34] 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] Good morning all; happy Monday, and happy Clean Your Virtual Desktop Day! 😃 [09:06] 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] mvo, hmm [09:07] do you know how you actually triggered that ? [09:09] mvo, ogra_, did you see that ubuntu-snappy is still on 1.5 in wily because 1.6 fails to build? [09:09] unsure if that's something you want to fix before release [09:10] "release" heh [09:10] but yeah ... for the devs that use wily desktops that probably makes sense :) [09:10] ogra_: I removed system-a and system-b [09:10] :P [09:10] mvo, ah, so a typical usecase then :) [09:10] ogra_: *cough* [09:11] ogra_: this why I said "fyi" [09:11] did you leave writable intact ? [09:11] ogra_: it may become one, this is a system booting from a kernel snap [09:11] 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] ogra_: but like I said, could be a much older image [09:12] there might be a check missing [09:12] (i think the findfs runs only after the free space check and there might be nothing checking if it actually returned something [09:12] ) [09:13] ogra_: oh, fun - so something returns "-1" for size and parted assumes its a parameter :) ? [09:14] yeah, something like that .... i'll have to check the code, just a theory [09:14] 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] ah, no. wait-for-root for "writable" and findfs run first [09:17] so it isnt that [09:29] clobrano: that's not what "pedantic" means. And if it were my bug, I would've had less patience than you :) [09:29] good morning all [09:29] mvo: are we on github yet? [09:31] JamesTait: I am starting to suspect you're making up these Days [09:31] Chipaca, it's also Evaluate Your Life Day.... [09:32] dammit [09:32] Chipaca: I asked to wait 1 week, i.e. do the release with LLP [09:32] mvo: ahh, i missed that [09:32] mvo: that is entirely sensible! thanks [09:37] Chipaca: on a plus side it did trigger this as my tune for JamesTait day https://www.youtube.com/watch?v=WUOtCLOXgm8 [09:37] i'm going to need bigger speakers [09:39] Chipaca: virtual cleaning, with virtual woman, in a virtual environment, it was as close to virtual desktop as I could get :) [09:54] panic: can not set option description for "package name" [09:54] ... [09:55] FAIL launchpad.net/snappy/cmd/snappy 0.022s [09:55] mvo, Chipaca ^^^ thats the ubuntu-snapy FTBFS [09:55] (in wily) [09:55] ogra_: noice [09:56] https://launchpadlibrarian.net/218629818/buildlog_ubuntu-wily-amd64.ubuntu-snappy_1.6ubuntu1_BUILDING.txt.gz [09:57] ogra_: thanks [09:58] same failure on all arches but powerpc [09:59] interestingly, doing bzr-builddeb locally gives me a different ftbfs :) [10:00] bah. There's the same one also. [10:00] 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] Chipaca: the way we set the options is different between different version of flags [10:00] this build is old ... [10:00] Chipaca: for the other one you need a updated version of mux, its in the image ppa [10:00] so could well be that another FTBFS joined the party over time [10:01] ah [10:01] Chipaca: I wonder why its failing now, can't rmember changing the goflags code or the goflags package [10:04] ah, schroot builddeb has the ppa set up already, going with that one [10:05] sergiusens: mo'in! [10:09] mvo: got the same error in schroot. Also an error in one of the helper tests... [10:09] Chipaca: could you pastebin the other error please? [10:10] http://pastebin.ubuntu.com/12859201/ [10:13] Chipaca: heh, ok. that looks a lot like sbuild being special [10:14] mvo: oh yeah :) [10:16] probably need a .Skip() there [10:17] Chipaca, morning [10:17] sergiusens: you already answered a bit in the branch, but: would it be ok for u-d-f to use snapd? [10:18] directly, that is [10:18] or would you need a client library [10:18] Chipaca, only if snapd has SetArch or similar [10:19] 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] ExtractSnap? [10:21] Chipaca, this is where everything breaks btw. As this snapd on the host would need to support 15.04 and rolling builds [10:21] hey sergiusens [10:21] sergiusens: not necessarily [10:21] Chipaca, right now we do 'snappy.Install' to a fake location [10:22] 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] we'd need to have tests to that effect though [10:22] 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] 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] dholbach, for the last step? [10:26] sergiusens, we can do more if you like [10:26] 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] dholbach, I thought tedg was preparing something with cmake [10:27] dholbach, I do have a cmake/plugin override example in the works [10:27] sergiusens, ok cool - I'll leave the example around, just in case [10:27] sergiusens: sprint at mvo's, the last week of october \o/ [10:27] sergiusens: ie next week [10:28] 2015/10/19 11:26:18.407658 common.go:45: PANIC can not set option description for "package name" [10:28] mvo: ^ that is output in a *successful* test run [10:28] mvo: so it's a red herring [10:29] Chipaca, nah, at dholbach's, then yoiu guys cal also come to ubucon ;) [10:29] i'll disable log in that panic-checking test [10:29] *can [10:29] ogra_: +1 [10:29] aren't they, like, neighbours? [10:29] Chipaca, next week is too soon to get a good fare ;-) [10:29] 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] sergiusens: no no; fares dip this soon before [10:29] Chipaca, for american standards perhaps :) [10:30] * Chipaca remembers travelling 1Mm for an asado [10:30] dholbach, well if you do it from vivid no need to ship it :-P [10:30] Chipaca: yeah, the output is confusing its testing that its panicing if it can't find the option [10:30] (but then under that standard berlin lies next to paris too :) ) [10:30] dholbach, but I see your point [10:31] sergiusens, I'm happy either way - it might generally illustrate how to do and when to consider it [10:40] mvo: https://code.launchpad.net/~chipaca/snappy/skip-homedir-no-schroot/+merge/274870 [10:40] mvo: 1. skip that test in schroot; 2. turn off logs in that panic test [10:42] Chipaca: \o/ === willcooke_ is now known as willcooke [11:05] Chipaca, btw, did you see my messages from Friday about the megaMR and docopt? [11:05] sergiusens: megaMR? [11:05] sergiusens: wrt docopt, you linked me to docopt.go, is that the one you mean? otherwis eno [11:32] Chipaca, mega MR https://code.launchpad.net/~sergiusens/snapcraft/cleanup/+merge/274801 [11:33] 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] Chipaca, ugly as in the subcommand does a subprocess.call on a subcommand [11:34] Chipaca, e.g.; https://github.com/docopt/docopt/blob/master/examples/git/git.py [11:34] sergiusens: after pointing you at it i wondered about how/whether they'd support subcommands modularly [11:35] 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] mvo, hmm, looking at your initramfs-tools MP ... why the insmod ? mount should properly triger a modprobe event here [11:39] 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] thats surely a bug if it doesnt ... [11:41] mvo, if we cant get the kernel fixed we should add squashfs to the initramfs config instead of calling insmod though [11:41] Chipaca, I like this one, name clash and all, it is calling you http://click.pocoo.org/5/ [11:45] ogra_: let me try again [11:46] sergiusens: ugh. the "i just discovered decoraters they are the best!!1!one!" library [11:46] lol [11:47] Chipaca, then there's https://github.com/zyga/guacamole ;-) (the syntax is a bit more complicated but is the same without decorators) [11:48] mvo, also: http://paste.ubuntu.com/12859786/ [11:48] (not sure about loop, might be compiled int nowadays .... ) === chihchun is now known as chihchun_afk [11:50] ah, yeah, loop is builtin [11:50] 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] mvo, yeah, drop the loop line though (got that from casper) [11:51] ta [11:53] 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] ogra_: excellent suggesitons, thanks, will fix right after lunch [11:53] mvo: any idea why golint is suddenly mad at my branch? what changed in tarmac? [11:54] mvo, beyond that, the code looks fine to me, will approve then ;) [11:54] (indeed assuming it actually works :) ) [11:55] ogra_: heh :) it does for me, but I will double check after lunch again [11:55] i'll keep staring at it a bit, probably i find other nitpicks :) [11:56] oh [11:56] mount --move "$writable_mnt" "${rootmnt}/writable" [11:56] mvo: wrt lint, seems an updated golint is what happened [11:57] with the new way "$writable_mnt" is "${rootmnt}" already ... not sure this line is clever [11:58] (movind ourselves one level down ... ) [11:59] ah, no ignore that ... but there is something wonky here [11:59] * ogra_ will breed over it [12:02] hmm, we are essentially pullin out the carpet underneath ourselves with that line [12:02] mvo: updated the branch to pass lint again, care to give it a once-over? [12:19] 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] Chipaca, and snapd will run fine on ubuntu classic? [12:20] sergiusens: today now, because there isn't a way to setrootdir [12:20] s/now/no/ [12:20] sergiusens: but that's why i'm asking what's needed :) [12:21] 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] Chipaca, given all snaps, I don't know anymore [12:22] sergiusens: sounds like setrootdir, set arch, and a way to make apps not be sideloaded [12:22] s/apps/snaps/ [12:22] Chipaca, but if we forget about all snaps, install to alternate locations, inhibit hooks, set the release to query the store [12:22] Chipaca, apps coming from the store should not be marked as sideloaded though [12:22] Chipaca, I think that is an introduced bug [12:23] recent one [12:23] Chipaca, but yay, origin [12:23] 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] Chipaca, they shouldn't be sideloaded, right,because of what you just said ;-) [12:24] 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] sergiusens, tedg: I filed https://bugs.launchpad.net/snapcraft/+bug/1507573 [12:49] Launchpad bug 1507573 in Snapcraft "AttributeError: 'module' object has no attribute 'tests'" [Undecided,New] [12:50] dholbach, I was going to ask you what the heck that meant as bzr bd works just fine [12:52] sergiusens, let me see if I can reproduce it [12:53] dholbach, this is probably related to the test_suite='snapcraft.tests' line I added to setup.py [13:05] sergiusens, try with and without python3-autopilot [13:05] that might be the issue [13:06] yep [13:08] https://code.launchpad.net/~dholbach/snapcraft/1507573/+merge/274889 [13:11] sergiusens: dholbach: I finally got my ginac example working last night, but it required a fix, and ended up being autotools. [13:12] tedg, cool - are you going to present it later on? [13:14] dholbach: At the clinic, right? [13:15] yeah === balloons is now known as Guest77565 === Guest77565 is now known as balloons_ [13:28] mvo: hi! ping re snappy-debug [13:30] jdstrand: hi! ping re killing click-apparmor with fire :-p [13:30] jdstrand: uh, sorry, we plan a new snappy release for end of this week, I got a bit distracted because of this [13:31] Chipaca: I think I mentioned I would very much appreciate help with that ;) [13:31] Chipaca: but yes, it is definitely something we need to do [13:32] unfortunately, higher priority items keep getting added to our plate that trump that one [13:32] jdstrand: ok, here's the thing: i wouldn't know where to start :-/ [13:35] mvo: I'm not sure what you are communicating. do you want me to remove valgrind, fix up the packaging and upload? [13:36] 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] 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] jdstrand: +1 [13:43] jdstrand: and we add the other bits later [13:43] dholbach, why would I want python3-autopilot? Do we use anything from that at all? [13:44] dholbach, perhaps we should broach the topic in here instead with the rest of the team. [13:44] sergiusens, i don't know [13:45] dholbach, lol, it does not make sense :-) [13:45] sergiusens, it makes it work :) [13:45] dholbach, right, I don't have anything autopilot locally here [13:46] then one of its deps? [13:46] mvo: ok, I'll just do that then [13:46] dholbach, oh, maybe testutils [13:46] aha? [13:47] sergiusens, I'll investigate [13:49] dholbach, http://trac.10920.n7.nabble.com/Can-t-run-the-unit-tests-ImportError-No-module-named-tests-td31160.html [13:49] maybe that [13:52] mvo: ok, I created https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-debug [13:53] 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] sergiusens: Can you look at this before the clinic today? https://code.launchpad.net/~ted/snapcraft/autoreconf/+merge/274893 [13:57] sergiusens: Bugs found in making the demo :-) [14:01] tedg, you can add build packages to the yaml itself, but sure lets look at this [14:03] jdstrand: \o/ === balloons_ is now known as balloons [14:04] sergiusens: Oh, I thought that was only for plugins. [14:10] tedg, I guess all or mostly all of the autotools based projects will use libtools, not sure about bison [14:15] sergiusens: Yeah, makes sense. Let me refactor. [14:16] tedg, in trunk I think build-packages can even go into the part (instead of top level snapcraft.yaml) [14:17] sergiusens: Yup, verifying by building now. [14:30] 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] sergiusens: Curious if it should be "host-packages" or something. [14:31] sergiusens: Or handle build packages by installing them onces, but stage-packages twice. So then you only get some into stage [14:34] tedg, I see your point and yes it is confusing if you come from debian/control [14:34] tedg, I think of it as build-package just drives the build [14:34] tedg, stage-packages is anything you want in the part/snap (a -dev will bring in the lib which you would want). [14:34] sergiusens: Yeah, I think it would be nice though, just to make the snap smaller. [14:35] but certainly confusing [14:35] I worked around my line of thinking to get used to it [14:35] sergiusens: The current build-packages sucks because if you're using a different distro version from the host it won't work. [14:35] tedg, and no fileset usage I bet ;-) [14:40] oh noes [14:41] how does one recover from this: http://paste.ubuntu.com/12861487/ [14:41] this is on a bbb [14:41] jdstrand: uh, sorry - this is a transient bug [14:44] jdstrand: you need to manually rename the full named kernels in /boot/uboot/{a,b}/ to the short (vmlinuz) name [14:44] jdstrand: same for initrd [14:44] mvo: this is then fixed after this upgrade? [14:44] sergiusens: bison dropped [14:46] sergiusens, https://code.launchpad.net/~dholbach/snapcraft/1507573/+merge/274889 updated [14:47] jdstrand: yes, its a version of snappy that gets this wrong [14:47] tedg, if you drop bisons you have to add wombats ... thats an old rule :) [14:48] erf [14:48] I got past that, now: [14:48] 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] ogra_: Are you using the Alix board as a router and then putting a WAP on the other side? [15:06] oh, 1h early [15:06] * doctorSnappy i'm not a real doctor [15:09] any1 online? [15:09] tedg, added comment to your MP [15:10] sergiusens: morning, we've tested what we discussed last week [15:10] vmayoral, sdcard? [15:10] vmayoral, how did it go? [15:11] sergiusens: pretty much the same, no big changes [15:11] vmayoral, have you tried disconnecting everything from the usb bus as well? [15:12] yes, boot time reduces a bit ~15 seconds but the "snappy info" command takes the same [15:13] the issue that we saw with the autopilot (for the drones) remains active [15:13] vmayoral, so even disconnecting everything from the bus (wifi, vide camera, etc) has no impact? [15:13] * sergiusens invokes ogra [15:14] sergiusens: yes, tests have been made with only Erle-Brain 2 (RPi2 + shield with power electronics for actuators) [15:14] vmayoral, what about just the rpi2 with no shield? [15:15] dholbach, I have bad news, my network connection seems to be degrading [15:15] sergiusens: haven't tried that but i doubt that's the issue since Debian FS works perfectly with the shield [15:15] dholbach, I'll keep you posted [15:15] thanks sergiusens [15:15] vmayoral, snappy info takes long for you ? [15:16] sergiusens: Done. bug 1507648 [15:16] bug 1507648 in Snapcraft "Autotools doesn't work without autogen.sh" [Undecided,New] https://launchpad.net/bugs/1507648 [15:16] ogra_: in the tests, the first time it took 16 seconds, following attempts about 4 seconds each [15:16] I'm going to upgrade my openwrt. [15:16] I might be away for a month. Wish me luck. [15:17] (RaspberryPi2)ubuntu@localhost:~$ time snappy info|grep real [15:17] real 0m0.495s [15:17] this is on an unmodified snappy RPi2 image [15:18] QUESTION: Can i have my private snappy app store? [15:18] so it must be related to some changes you make [15:18] Guest42341, you are early [15:18] oh, thanks sergiusens [15:18] :)) [15:18] how much early? [15:18] Guest42341, 40' [15:18] * sergiusens restarts router again [15:19] phew [15:20] 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] 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] 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] personal is also not a project atm ... that image build was a one-off test thing [15:22] vmayoral, well, the snappy fs isnt slow as you can see above ... [15:23] so there must be something with your changes that snappy doesnt get along with [15:23] ogra_: not saying it's Snappy, probably we're doing something wrong [15:23] well, or snappy is [15:23] :) [15:24] the point is that a default snappy isntall flies (oh the pun) on RPi [15:24] ok, i've got to go out for a bit, will bbl [15:25] ogra_: what really confuses me is that the same config produces a kernel on De [15:25] 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] *produces a kernel that works perfectly in Debian and gets issues in Snappy [15:25] t [15:25] vmayoral, well, you cant really compare the two [15:26] actually i'm trying to reproduce running qt snap application on snappy personal. [15:26] different userspace ... kernel options might be missing between them etc [15:27] kgunn, can you help shuduo ? [15:27] is the Mir snap supposed to work ? [15:31] shuduo: I don't think the mir snap will work on personal. [15:31] Personal I believe has Mir bundled into the core. [15:32] 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] shuduo: virtual machine of ubuntu core (not personal) [15:36] shuduo: ubuntu personal image has not had the work/attention to support snap as a mir client download/installation [15:37] mvo: fyi, bbb is back in action [15:39] 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] mvo: so, snappy-debug was set as a framework. is this so one doesn't have to type 'snappy-debug-snappy-security'? [15:39] problem is currently the running of the mir client snaps (on top of that) [15:39] kgunn: hmm, i managed to run a recompiled mir snap on qemu now. but failed with virtualbox [15:39] mvo: wouldn't an alias in the store do the same thing? [15:40] shuduo: i can only speak to the vm i used [15:40] mvo: or am I misremembering that point? [15:40] * kgunn gets on the phone so responses will be slower [15:41] jdstrand: yes, just for that, just for the short names to work [15:41] 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] jdstrand: a alias will mean you need to type "snappy-debug.strace" which is probably a good thing [15:41] jdstrand: yeah, I agree [15:41] kgunn: i'm curious what vm you are using. can you see graphics screen show up with a big mouse cursor? [15:42] 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] shuduo: virtual machine manager which can download from the sw store [15:43] https://virt-manager.org/ [15:43] and yes, i can see the big mouse cursor [15:43] kgunn: yes, i'm using vmm now and i can see graphic screen with a mouse cursor [15:43] jdstrand: :) [15:44] shuduo: right, and there is a problem with running of mir client on that demo do some install pathing changes i believe [15:44] and tbh, i am thinking we need to move our effort over to snapcraft [15:44] 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] *no actual [15:50] we are going to start the broadcast on ubuntuonair.com in about 10 mins [15:51] dholbach: Do you have an URL for that? [15:51] genii, http://ubuntuonair.com :) [15:51] Heh, OK [15:52] https://youtu.be/0Ma4Wvppzcs [16:03] does the video work? everything working fine so far? [16:03] dholbach: yes [16:03] if you have questions, please prefix them with QUESTION: [16:03] so we can more easily pick them up :) [16:11] 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] nice evening everyone o/ [16:17] any questions so far? [16:18] http://www.ginac.de/ [16:19] QUESTION:Do plugins shipped with snapcraft or we can make it ourselfs? [16:20] Rlyeh, you can indeed create your own like sergiusens just demonstarated [16:20] *demonstrated [16:20] you have an error [16:20] Thanks, i have some delay, sorry [16:21] no worries :) [16:21] we'll answer it on the hangout in a sec as well, just to be sure [16:21] QUESTION: why do you need -dev packages for runtime deps ? [16:24] QUESTION:would you please describe how to define architecture? I defined "armhf", but the package built for amd64(my pc) [16:24] kgunn: sorry install mir.mvp-demo can be processed. pls ignore prev msg [16:26] 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] ? [16:27] http://paste.ubuntu.com/12862605/ [16:27] (sorry i may be laggy) [16:27] QUESTION: If I undestand well, to build snaps for rp2, you have to develop them on the rp2? [16:28] LarreaMikel, you have to develop them on armhf [16:29] 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] ogra_ thanks ;) [16:29] LarreaMikel, if you use go you can cross compile out of the box [16:30] more or less [16:30] well, snapcraft doesnt support it [16:30] as sergio just explains :) [16:32] what does EINFUGEN means? [16:32] INSERT [16:32] :) [16:32] thanks :D === shuduo is now known as shuduo-akf === shuduo-akf is now known as shuduo-afk [16:36] sorry [16:36] I hit the wrong button [16:36] np [16:37] is really over? [16:37] QUESTION: If you do "snap run" on the rp2, it tries also to run on an emulator? [16:37] dockydo: Just a sec, dholbach hit the wrong button. [16:37] * ogra_ expects them to come back :) [16:37] dockydo, no, technical issues with hangouts [16:37] sorry [16:37] np :)) [16:37] will come back in a minutes [16:37] minute [16:37] LarreaMikel, you mean snapcraft run ? [16:37] ok them, time to check for ota7 [16:38] LarreaMikel, I'll answer that one in the hangout ;-) [16:38] ogra_: yes, sorry [16:38]