=== chihchun_afk is now known as chihchun [08:24] good morning [08:30] sergiusens: ping [08:31] morphis, pong? [08:31] morning [08:31] sergiusens: morning :-) [08:31] 5:30am here :-) [08:31] quite early [08:31] but wide awake due to jetlag [08:31] 11 hour time jumps can do that [08:31] even better ;) [08:32] sergiusens: with snapcraft on xenial I am currently getting: https://paste.ubuntu.com/15413380/ [08:32] sergiusens: nothing in snapcraft seem to create those two directories during the stage process [08:32] so I am wondering what goes wrong [08:32] loosk like snapcraft is adding them statically to CFLAGS [08:33] just creating both fixes the problem [08:33] morphis, interesting; this seems to be a snapcraft bug; it declares that include path (just in case) [08:33] thanks for pointing me out that inherited legacy code again :-) [08:33] morphis, can you file a bug? [08:33] sergiusens: sure, on github or launchpad? [08:34] and include your snapcraft.yaml [08:34] morphis, https://bugs.launchpad.net/snapcraft/+filebug [08:34] sergiusens: aye [08:45] ogra_, mvo: do you know who's responsible for the Mt7623 snap? [08:46] or who has access rights for it? [08:46] we received a request to change the logo [08:53] sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1558965 [08:53] Launchpad bug 1558965 in Snapcraft "Snap building fails due to missing include directory" [Undecided,New] [08:58] dholbach: I have no idea, probably best to ask in #u1-internal [09:00] dholbach, ogra_, if I'd want to create a snap from a .deb package, which is not on the archive, is there any snapcraft.yaml trick I can use to download the .deb from a URL, just as if it had been specified in 'stage-packages'? [09:02] dpm, can you put it in a PPA and use either the launchpad build or the LOCAL SOURCES trick? [09:02] dholbach, I was trying to avoid that, as sergiusens mentioned that LOCAL_SOURCES was rather deprecated [09:04] I think the official way we want to use is PPAs and LP builds [09:04] but for local testing, while it's still available in the code, I'd recommend the local sources trick [09:04] but maybe sergiusens has a different idea [09:05] dholbach, havent heard of that snap [09:05] dholbach, right, but is not PPAs = LOCAL_SOURCES? [09:05] or do can the LP builds somehow use external PPAs? [09:06] dpm, I have never used it yet, but I assume that it's like normal PPAs - you can make them depend on each other [09:07] dholbach, dpm just make sure it is in you local sources.list [09:07] I'm a bit confused now [09:07] so the package I'm trying to snap is both in a PPA and available as a downloadable .deb [09:08] so what's the recommended way to snap it if I just want to package the binaries, and not build them? [09:10] ogra_, [09:10] Mt7623 [09:10] MT7623 support package MT7623 OEM snap for IoT demo purpose [09:10] (https://developer.ubuntu.com/en/snappy/start/gadget-snaps/) [09:10] dholbach, see PM :) [09:10] gracias! [09:24] sergiusens: also looks a bit like snapcraft is not extracting all deb packages I put into stage-packages correctly [09:25] sergiusens: is there some condition around what gets extracted and what not? [09:25] sergiusens: https://paste.ubuntu.com/15413620/ [09:34] morphis, can you check in parts//install ? [09:35] sergiusens: sure [09:35] sergiusens: hm there it is [09:36] morphis, do you have a stage or snap entry in your snapcraft.yaml? [09:36] sergiusens: ah .. my fault :-) [09:36] I strip it from the list of staged files [09:36] morphis, I'm fixing this in a pkg-config branch I have [09:37] sergiusens: but looks like the build is referencing to stage/ somehow [09:37] morphis, so you won't be hit by this again and what you did might as well be correct in the future [09:37] good morning [09:37] * sergiusens starts getting breakfast ready [09:37] zyga: morning [09:38] sergiusens: you mean stripping it from files being staged affects the build through pkg-config? [09:40] sergiusens: https://paste.ubuntu.com/15413661/ is still what I get during the build, shouldn't the build only point to parts//install? [09:42] morphis, the problem is pkg-config can only have one SYSROOT at a time [09:42] pitti: you around? [09:42] morphis, I've been fixing that; but not there yet (missing some corner cases) [09:43] sergiusens: ok, got it, thanks [09:44] morphis, and then yes, you would use 'install' for the part and not need to stage if not needed [09:46] sergiusens: ok [11:27] mvo, is there a way to query snapd for all the metadata of an app? [11:31] dpm: I don't think we have this right now, you can query the status if it is a service. why do you ask, what do you need here? [11:37] I think it's returning outdated metadata, and I wanted to check [11:41] Good morning === devil is now known as Guest29525 [12:05] is there still a way with the new snappy stuff for 16.04 to let a snap being unconfined? like the security-template: unconfined switch we had with 15.04? [12:06] morphis, there is with old-security; look at the snapcraft examples [12:06] oh great [12:07] sergiusens: is that documented somewhere too? [12:07] morphis, that is an mvo question [12:08] sergiusens: basically I have a daemon I want to run unconfined [12:10] morphis, the only form of documentation I have on snapcraft's side are the examples and https://github.com/ubuntu-core/snapcraft/blob/master/schema/snapcraft.yaml#L57 [12:10] sergiusens: I see [12:10] morphis, I don't want to write more until the snappy guys get some ticks on interfaces themselves [12:11] morphis, and that lands from here https://github.com/ubuntu-core/snapcraft/blob/master/schema/snapcraft.yaml#L248 [12:11] morphis, which needs to ref'ed from `apps` in https://github.com/ubuntu-core/snapcraft/blob/master/schema/snapcraft.yaml#L185 [12:12] I see, so defining a plug I then use in my app [12:12] morphis, this https://github.com/ubuntu-core/snapcraft/blob/master/examples/ros/snapcraft.yaml and this https://github.com/ubuntu-core/snapcraft/blob/master/examples/busybox/snapcraft.yaml should get you the gist of it [12:15] sergiusens: so something like https://paste.ubuntu.com/15414149/ should do the trick [12:16] morphis, yes [12:16] lets see [12:16] morphis, I hope we did a good job with the schema to detect incompatible options/combinations [12:17] sergiusens: I must say I like snapcraft more and more, got quite more solid then when I used it the last time back in november last year [12:20] sergiusens: but yeah, that trick works [12:37] mvo: ping [12:46] kyrofa: awesome! Sorry I only see it now - will push the blog in a few minutes OK :D [12:46] thanks a lot [12:47] jospoortvliet, no problem! Good afternoon :) [12:47] now for putting them on a stick, so I can demo it at Chemnitzer Linux Tage (conference happening this weekend) ;-) [12:47] Ooo, good luck! [12:47] will be fun, np [12:48] Hello guys [12:49] I have some trouble with changing my apparmor. I think an issue in Snappy. here is the following error that I have. :http://pastebin.com/t87eZpjz [12:49] error: http://pastebin.com/t87eZpjz [12:49] Does somebody got any idea how I can fix it? [12:50] we talked about this before [12:50] this is possibly a bug in the ubuntu-core-launcher [12:50] jdstrand: Yes but can it be fixed? [12:51] jdstrand: In some later version? [12:51] /home/ubuntu/snaps/ad.sideload/LTKVlHMSjhpm/snaps/ is not a valid path that the launcher should be looking at [12:51] Maybe i can make that path so ... [12:51] noizer: please file a bug at https://bugs.launchpad.net/snappy/+filebug with steps to reproduce if you're sure you are setting up everything correctly [12:52] morphis: pong === devil is now known as Guest28469 [12:54] jdstrand: But you knows more about it what I'm trying to do and thats not in the filosofie of snappy [13:03] noizer: sure-- it might be you are not setting an env var correctly. you should look at how things are set in /snaps/bin to see why the last /snaps/ is being appended. only when you are sure that the launcher is doing the wrong thing, file the bug [13:05] noizer, yeah, check the $SNAP_USER_DATA variable [13:05] jdstrand: I will look into it and let you know for more advice [13:06] kyrofa: jdstrand Can i check it just over SSH to my raspi pi? [13:07] noizer, first off, I'm assuming this is a binary, not a daemon, right? [13:08] noizer, if yes, you can SSH in and check out the /snaps/bin/ wrapper. If it's a daemon, you can SSH in and check out the /etc/systemd/system/.service file [13:16] kyrofa, here's one for you https://github.com/ubuntu-core/snapcraft/pull/379 :-) [13:17] kyrofa, if you know of a stable snap on the staging server I can add an int test; I'm weary to add one otherwise [13:17] sergiusens, not really-- everything I've ever done on staging was temporary :P [13:18] sergiusens, though we have an upload test-- maybe couple them together a little? [13:18] jdstrand, hey, the sudo problem needs to be solved regardless of what dir we default to as one of the system components creates the dir layout and if it is the first run and sudo is involved we create a boo boo [13:18] * sergiusens speaks in loose terms since it is Friday after all [13:19] sergiusens has kids [13:23] just the one ;-) [13:24] nice coveralls is giving me nice messages now [13:27] sergiusens, explain this PR to me. How does the kernel needs snaps? [13:28] ogra_, kyrofa: you had issues with services not starting, i assume this is still the case? I am testing this right now [13:28] mvo, indeed-- they aren't activated on boot in 16.04 anymore [13:29] kyrofa, look at the kernel pr :-) [13:29] kyrofa: ok, let me try that [13:29] kyrofa, in summary, generic initrd [13:29] kyrofa: only when using u-d-f, right? [13:29] mvo, is there any other tool? [13:29] mvo, according to Chipaca and niemeyer I found out it isn't supposed to, though. Right, u-d-f [13:30] kyrofa: eh, wuut? [13:30] mvo, I learned that model assertions will be the way to do this [13:30] kyrofa: indeed and yet that should still activate them [13:30] kyrofa: plus we don't have them [13:30] mvo, so I ended up making a gadget snap with built-in to work for now (preinstalled doesn't work either) [13:30] sergiusens: I heard some talk about ubuntu-image ;) [13:30] mvo, indeed [13:30] kyrofa: but build-in does work? [13:30] mvo, blocked on generic initrd and model assertions ;-) [13:31] mvo, yeah, the gadget.go code parses that bit and activates on boot [13:31] kyrofa: ok [13:32] kyrofa: hm, hm, still awkward that we have --install in u-d-f and it does not work [13:32] kyrofa: I guess I kill that for now at least [13:32] mvo, yeah it's really hard to preinstall stuff now :P [13:32] mvo, I had to fork the entire rpi2 gadget [13:32] ogra_: you also had an issue with stuff not activated, was it the same? [13:32] kyrofa: that sucks (pardon my language) [13:32] mvo, btw, you may want to add StartLimitBurst= to the service units created; it would palliate the network requiring snaps a bit [13:32] kyrofa: actually I think we need to do something about this because webdm is something we want to preinstall [13:33] mvo, we could always add it to our gadgets if we don't want to support --install [13:33] mvo, right, the correct path for preinstalling is to define it in the model [13:33] mvo, but it is in a limbo state right now [13:33] sergiusens: no disagreement [13:33] sergiusens: I just don't like the limbo state, would be nice to be able to build images [13:33] sergiusens: so that people can use/test them [13:33] mvo, yeah, agreed [13:34] * mvo scratches head [13:34] mvo, of course; so many things have changed lately though that it is hard to unbreak everything :-) [13:35] sergiusens: yeah [13:35] sergiusens: I think we are very much in agreement :) [13:35] kyrofa, so the os.snap holds the generic initrd.img that ogra_ built; the intermediate plan is to compose a full initrd.img until snappy learns about N initrd's that can be chainloaded [13:35] jdstrand: kyrofa I got the following path [13:35] export SNAP_USER_DATA="$HOME/snaps/ad.sideload/LTKWTFRHRRWC" [13:35] kyrofa: did I hear correctly, model assertions are required for service start? [13:35] jdstrand, oh no, just pre-installing snaps in a generated image [13:35] mvo, I wish agreeing would magically fix things :-D [13:36] * sergiusens is in a very Friday mood [13:36] kyrofa: ok, I was going to say :) [13:36] jdstrand, starting to sweat? [13:37] noizer: I think what might be happening is when you call the scripts in /snaps/bin, your HOME is not /home/ubuntu, it is /home/ubuntu//snaps/ad.sideload/LTKWTFRHRRWC, so then the launcher looks at $HOME, tacks on /snaps and messes up [13:38] noizer: the fix is doing HOME=/home/`id -u` /snaps/bin/... [13:38] noizer: or similar (that won't work for root of course, but you get the idea) [13:38] sergiusens, ahh, okay I see now. So this is (hopefully) temporary, then? [13:38] err, id -un [13:38] sergiusens, the downloading, I mean [13:39] sergiusens, until we get them chained [13:39] kyrofa, yeah; but if we lived in a beatiful world this storeapi thing would be its separate project and we'd use it for ubuntu-image as well (to download snaps) [13:39] kyrofa, yes, until then [13:39] jdstrand: But I can't fix it right now? [13:40] sergiusens, that's not a bad idea. It might save us some work later, but it means facing the NEW queue [13:40] kyrofa, new queue is easy once you know the right people ;-) [13:40] sergiusens, ha! [13:40] sergiusens, what do you think then? Shall we extract it? [13:41] kyrofa, well now is not the time [13:41] Or even implement the API in ubuntu-image? [13:41] Okay [13:41] kyrofa, it's in snapcraft since you know what [13:42] Gotcha :) [13:54] noizer: this is in your code [13:54] noizer: you are calling /snaps/bin/... iirc [14:00] jdstrand: yes thats my code how can i fix it then? [14:02] heya folks! I installed ubuntu-snappy-cli on a xenial system and there's no "snappy try". How can I try a locally built snap? I do have the snappy-dev ppa enabled [14:02] Is there any preferred idiom for restarting one's self after a config change? Just use local config program to kill or something? No systemd poking or anything? [14:05] noizer: I told you: you need to reset HOME to /home/ubuntu (or /home/`id -un` or something else smarter) before you call /snaps/bin/... [14:05] HOME=/home/`id -un` /snaps/bin/... [14:06] jdstrand: sorry i was a little confused :s [14:07] np === chihchun is now known as chihchun_afk [14:19] jdstrand: I set my HOME to /home/ubuntu and it won't help [14:20] noizer: otoh not sure. look at the env vars being set in /snaps/bin/... (they are just shell scripts) and try to figure out what you need to do [14:22] kyrofa, elopio I'm at a coffee shop that just got loud, mind if we start 10' late so I run home? [14:22] sergiusens, sure thing [14:23] sergiusens, no rush [14:33] mvo, yeah, it was the same issue (webdm got unpacked in /snaps but no "current" link and no systemd services were created) [14:36] mvo, we also used to be able to just build images without defining kernel and os (the oem snap used to define which ones it needs) ... that was very convenient, could we have that back ? [14:38] ogra_: I pushed a branch that activates the installed snaps now, the other one is probably simple too, I need to look at an example, can't remeber the syntax that the gadget defines kernel/os [14:39] yeah, me neither, ricmm just pointed me to that yesterday, i'm alsready so used to define --os and --kernel :) [14:39] mvo, also, when do you plan to land the udf changes so people dont need to pull your binary ? [14:40] is there anything blocking ? [14:40] ogra_: well, ubuntu-image, but I suspect more and more that this is not going to happen before 16.04 so maybe we should go ahead. my branch was proposed ages ago [14:40] (looks stable to me after using it for more than a month) [14:40] ogra_: my branch for u-d-f [14:41] yeah, even if ubuntu-image happens we should have something that matches the current setup in the archive [14:41] mvo, +1 on landing [14:41] until u-image is done [14:42] mvo, we're still waiting on a number of things to happen before ubuntu-image anyway [14:42] * ogra_ would like to disable tarballs on cdimage ... which will break the system-image setup, so u-d-f shouldnt use it for 16.04 anymore [14:42] ogra_: hm, did ricmm point to the agreed syntax for kernel/os snap in gadget.yaml :) ? I can't find that right now [14:42] mvo, no, he just pointed out that it was possible with the old oem snaps ... [14:42] kyrofa: yeah, I think that makes sense [14:42] ogra_: right, well, hmmm [14:43] ogra_: we may need to wait until there is agreement on the syntax but in principle its a simple change I think [14:43] probably nobody thought about that and it isnt in the spec [14:43] (i personally hd completely forgotten about it :) ) [14:54] mvo: nevermind, solved the problem already [14:55] sergiusens, thanks for the cliffhanger btw ... looks like we might re-discuss merged initrds vs loop mounted modules :) [14:56] (which in case we decide for the latter means changing the partitioning scheme ) [14:57] * ogra_ will try to preapre a prototype [15:07] sergiusens, so looking at https://github.com/ubuntu-core/snapcraft/pull/379 ... why not just pull the deb from the archive ... seems like overkill to use the whole os snap just to extract the img file [15:12] ogra_, we can't know which OS and deb relate [15:12] as in no traceability [15:12] ogra_, this is jus temporary though as you now know ;-) [15:12] well, the generic initrd will have to come from somewhere [15:12] even in the future [15:13] ogra_, yeah, but the kernel plugin won't need to pull it down [15:13] how else would you get it then ? [15:13] ogra_, won't it be in the image? [15:14] kyrofa, it currently is ... but that wont help you if you build your arm kernel via snapcraft on your PC [15:15] then it would again need to pull the file from somewhere [15:16] (unless you limit it to only building in the classic dimension) [15:32] heya folks! I installed ubuntu-snappy-cli on a xenial system and there's no "snappy try". How can I try a locally built snap? I do have the snappy-dev ppa enabled [15:33] ogra_, I guess I'm not super clear on what the end goal is. I imagined the kernel snap having its own initrd and the OS having another one, and at boot they get chained together. Perhaps I've misunderstood? [15:33] mvo: ping. So, what should we use as the version of this deb we dput on changes to master? [15:33] I was thinking that the sha1 doesn't work because it's not increasing. [15:34] ogra_, i.e. they're independent [15:35] kyrofa, well, the discussion about the implementation is still ongoing (or ongoing again since yesterday), but yes, the generic part in either scenarion can then come from the os on boot [15:35] *scenario [15:36] sorry, i'm judging by waht we currently have :) [15:36] (which is "merge at build time") [15:38] davidcalle, you can set SNAPCRAFT_LOCAL_SOURCES as an environment variable and use what's in your /etc/apt/sources.list* [15:39] ogra_, right, same page. I guess we're just assuming that the end goal will be to have them completely independent at build time, so we just have this temporary workaround for now [15:39] davidcalle, that'd trump whatever snapcraft's using by default and you could work around the mirror which has a broken hashsum (or is in the middle of mirroring) [15:40] at some stage, sergiusens will make me pay for every time I mention the local sources trick [15:40] kyrofa, i learned to only trust end golas if the code exists ... i guess thats my prob :) [15:40] it looks like a few people need this after all [15:40] *goals [15:40] ogra_, heh [15:41] dholbach: perfect, thanks :) [15:45] elopio: ideally just whatever version we already have and we append ~ppaN (~ppa1, ~ppa2 etc) [15:45] elopio: the "~" is important to ensure the version is smaller [15:57] dholbach, I will make it default after I am done with this jdstrand: I uploaded another revision [15:57] dholbach, err https://github.com/ubuntu-core/snapcraft/pull/335 [15:57] not sure how that got copy/pasted ??? [15:57] darn xchat [15:57] heh [15:57] oooh, nice [15:58] thanks sergiusens! [15:58] dholbach, which will allow you to also mostly use build packages instead of stage packages for most things again [15:58] excellent [16:00] all rightie... I call it a day - have a good one everyone! [16:00] * mvo hugs dholbach [16:00] Bye dholbach! [16:00] * dholbach hugs mvo and kyrofa [16:00] mvo, email! :-) [16:01] see you! [16:12] mvo, how about we target next week to do an all-snaps 16.04 alpha release on cdimiage.u.c/ubuntu-snappy (independent of u-d-f being merged or my autosubmit of snaps from cdimage to the store i think we should have some recent image we can point people at in an official space)? [16:12] ogra_: absolutely, this is why dholbach was bugging me about "send this mail" [16:12] ah [16:13] how can I try a locally-built snap? [16:14] * ogra_ always uses a kvm image or if i build for arm i actually use the target device to try it [16:14] ogra_, yay for cdimage! [16:15] roadmr, i'm not sure that "snappy try" is working yet [16:15] s/that/if/ [16:15] ogra_: thanks! this is amd64 so a kvm image would work. I'm happy to be pointed to docs if there are any :) [16:16] roadmr, http://people.canonical.com/~mvo/all-snaps/amd64-all-snap.img.xz ... unxz that ... then: kvm -m 512 -redir :8022::22 amd64-all-snap.img. [16:17] (and you can ssh/scp to localhost at port 8022) [16:17] ogra_: yay, thanks! [16:25] kyrofa, did you consider giving your "split /writable to separate img" script snippets to zyga so he can include it in his ubuntu-image script ? [16:26] ogra_, no, but if you imagine it being more generally useful I totally can [16:26] i think it is, yeah [16:26] (for everyone wanting to have the payload on USB and boot on SD) [16:27] ogra_, yeah I have a custom version of his ubuntu-image as well, so I should upstream the whole thing [16:27] yeah [16:27] ogra_, I'll make a few PRs, thanks for the poke :) [16:27] thanks for the code :) [16:29] dpm, `snappy build` is going bye bye, might be better to say `snapcraft snap [DIR]` [16:29] sergiusens, https://github.com/ubuntu-core/snapcraft/pull/381 [16:30] elopio, ^^ [16:30] sergiusens, ah I've actually never used it, I've always used snapcraft so far. Any particular docs you've seen it mentioned? [16:30] dpm, the one you just shared in the call [16:30] sergiusens, ah, I see [16:30] updating it [16:30] dpm, you also mention 'clock' in there ;-) [16:30] dpm, I only have View; else I would of commented/suggested inside the doc :-) [16:31] sergiusens, updated permissions, you should be able to edit/comment now :) [16:31] thanks! [16:32] sergiusens, and now you own it ! [16:32] thanks [16:32] ogra_, nah [16:32] :) [16:32] dammit, it was worth a try :) [16:38] sergiusens, have any atom plugins to recommend? [16:39] kyrofa, you transitioned :-) [16:40] sergiusens, I'm taking it for a spin anyway [16:40] sergiusens, perhaps my combination of gedit vi and grep could be improved upon. Perhaps [16:40] gedit and vi ? [16:40] heh [16:41] kyrofa, atom-python-debugger, git-plus, linter (A Base Linter with Cow Powers), linter-flake8, linter-golinter, linter-gotype, linter-govet, linter-pep8 (although flake8 takes care of the same) and the best of all vim-mode [16:41] sergiusens, ah, it was watching your vim-mode that convinced me to try it out [16:41] kyrofa, I like "linter" most of all for the description [16:42] Hahaha [16:42] kyrofa, the reason I stopped using vscode was that its vim-mode wasn't that good [16:43] * kyrofa wonders how atom's ruby support is [16:44] sergiusens, what about python-tools? [16:54] davidcalle, I think the getting started doc is ready - if you want to have a quick review whenever you've got time, that'd be awesome [16:56] dpm, alright, on my end, I'm still trying to figure how to handle runtime deps [16:57] davidcalle, just put them all in :) [16:57] have you tried with "stage-packages"? [16:57] kyrofa, I just use the linter tools [16:58] kyrofa, btw https://owncloud.org/blog/wd-labs-raspberry-pi-owncloud-and-ubuntu/ [16:58] dpm: that's the "all in" part I'm running after. Things build, but always choke on some missing lib when I try to run them. I'm tempted to add ubuntu-desktop ;) [16:58] davidcalle, ah, I had that issue too, it's a bit of trial and error :) [16:59] dpm: any way to not have to redownload anything when you change stage-packages? [16:59] sergiusens, hey thanks! [17:00] davidcalle, I haven't tried that yet, but the last comment on bug 1550679 might work [17:00] bug 1550679 in Snapcraft "Allow selective cleanup" [Undecided,Incomplete] https://launchpad.net/bugs/1550679 [17:04] dpm: thanks, doesn't work (yet?), but nice to see it's planned [17:06] kyrofa, very nice [17:06] kyrofa, I'll start looking at your PR in a bit btw [17:40] sergiusens: hi, i've been trying to push this snapcraft PR along but keep hitting issues with the automated checks: [17:40] https://github.com/ubuntu-core/snapcraft/pull/364 [17:41] Hey mvo do we have a bug for the unversioned data directory? [17:42] sergiusens: do you know if that is a problem with the tools or my PR? [17:48] joc_, given that other PRs are testing fine I'd guess with your PR; elopio mind checking? [17:49] joc_, if you have vpn access just click on details to see [17:51] sergiusens: ah thanks, didnt have vpn enabled [17:55] sergiusens, okay I admit. Atom is an improvement [17:56] kyrofa, it is nice; I downloaded it for a test run and here I am still 8 months in [17:57] sergiusens, and it's light and fast. That's why I was using my previous solution-- everything was so slow [17:57] everything else, rather [17:58] kyrofa, what other things were you using? [17:59] vim wouldn't be slow, but package management and the packages can get slow/flaky [17:59] sergiusens, no that's what I mean-- vi and gedit are both super light. But like, eclipse for instance [18:08] joc_: http://paste.ubuntu.com/15416550/ [18:17] elopio: thanks, where did you get that output from? [18:18] elopio: i.e. can i get to it myself from the PR? [18:20] joc_: yes, just enable the vpn and go to the details link [18:20] http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/176/console [18:25] kyrofa, hahahaha (reading the blog article you linked) [18:25] "This brings a very familiar operating system to the device" [18:25] :D [18:25] ogra_, yeah I noticed that myself [18:26] Some people might be surprised [18:26] yeah [18:26] well, we need to promote the classic dimension more ... there we are actually a familiar choice ;) [18:26] * ogra_ wishes we had a "snappy enable-classic-with-snapcraft" [18:27] kyrofa, nontheless, awesome !!!! [18:28] ogra_, thanks! :) [18:30] Question: In Xenial, how do we run snappy-remote? [18:31] is it broken ? [18:31] * ogra_ never uses it [18:32] (being just a wrapper around two scp and ssh commands) [18:32] I try to install snappy-tools from the ppa, but it says unable to locate package. [18:32] This is on a xenial workstation. [18:33] there might not be a xenial build for it indeed ... since "snappy try" is actually supposed to replace it (but i think thats not complete yet) [18:33] I guess I could always just scp the .snap to the device and locally run snappy install, but I was hoping to do everything remote. [18:34] Heh, I tried snappy try on xenail and it said, "Unknown command `try', did you mean `activate'?" [18:34] sergiusens, ^^ any chance we could have a xenial build of snappy-tools (at least til snapcraft try works) [18:35] There's room for a Star Wars Easter egg there ;) [18:35] ogra_, just copy_package it into xenial if you want [20:00] Hi, used snapcraft to build a snap of a python CLI app, but when I try to install it (kvm) but fails with: "failed to install: Signature verification failed with exit status 14" [20:01] couldn't find anything regariding the exit status 14, any ideas what might be going on? [20:02] verterok, you need --allow-unauthenticated when installing [20:02] snappy install --allow-unauthenticated [20:03] verterok, only snaps in the store are signed [20:03] kyrofa: I'm using --allow-unauthenticated [20:03] verterok, oh [20:03] verterok, 15.04 or 16.04? [20:03] kyrofa: ubuntu-core/15.04/stable [20:04] kyrofa: following the docs on both: 1) how to build a snap and 2) get snappy running on kvm [20:04] verterok, is it a large snap? [20:04] kyrofa: 48M [20:05] I can upload it somewhere if it helps, but will take a bit with my current connection [20:05] verterok, how much RAM do you have in the VM? [20:06] kyrofa: 512 [20:06] should I bump it? [20:08] verterok, can you run debsig-verify -d on the snap manually? [20:09] It sounds like the code checks for a signature and then decides whether or not to ignore it [20:09] kyrofa: http://paste.ubuntu.com/15417537/ [20:09]