[05:37] <mup> PR snapd#1457 opened:  snapstate: drop revisions after "current" on refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/1457>
[05:41] <mup> PR snapd#1534 closed: tests: add system-observe interface spread test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1534>
[06:04] <mup> PR snapd#1520 closed: tests: add locale-control interface spread test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1520>
[06:04] <mup> PR snapd#1522 closed: Introduce a simple key-value store for user-specific data <Created by stevenwilkin> <Conflict> <https://github.com/snapcore/snapd/pull/1522>
[06:05] <mup> PR snapd#1512 closed: overlord: initial work on renaming core snap <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1512>
[06:11] <trijntje> Good morning all, I'm still strugling with my first snap. If someone could look at it (https://github.com/Redmar-van-den-Berg/archaeopteryx) and the errors I get  http://pastebin.com/PLNdH3yM I would be grateful
[06:13] <mup> PR snapd#1519 closed: Add Qt5 indicator support in unity7 interface <Created by didrocks> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1519>
[07:03] <dholbach> hey hey
[07:03] <tsimonq2> hey hey hey!
[07:45] <dz0ny> Is that just me https://github.com/ubuntu/snappy-playpen/issues/176
[07:51] <dholbach> dz0ny, what if you open https://reviewable.io/reviews/ubuntu/snappy-playpen/166?
[07:51] <dholbach> I agree that reviewable clutters up the normal pull request views
[07:52] <dholbach> but I feel that it makes it much easier to keep track of what exactly still needs to be resolved in a list of PRs where some get stale and sit there and you never know which one you still need to look at
[07:52] <dholbach> https://reviewable.io/reviews#- is a very clear overview for me
[07:53] <dholbach> pbek, https://myapps.developer.ubuntu.com/dev/click-apps/5374/rev/5/ is "ready to publish" - so I guess you need to hit the "publish" button yourself still - just in case if you were wondering
[07:55] <pbek> dholbach: I totally not saw that button! I just looked at the "published" state at the top. Thanks a lot!
[07:55] <dholbach> anytime
[07:56] <dholbach> I'm not sure if you can configure it to auto-publish - I seem to remember there was something like that
[07:57] <dz0ny> dholbach: butterflies fly around following my mouse and each button hover shows 3 options :)
[07:57] <hikiko> tsimonq2, hello
[07:58] <hikiko> mmm I guess is too late for you...
[07:58] <pbek> dholbach: btw. do you know if I can trigger a snappy build process from the command line on launchpad after I `git push` the snapcraft to the launchpad repo?
[07:59] <hikiko> dholbach, how do we wrap the description in 80 characters? does a special 80th character does that or just wraping the lines in the text snapcraft.yaml file is enough?
[07:59] <hikiko> do I need something like \n at the end?
[08:01] <dholbach> pbek, no idea, sorry
[08:02] <pbek> thx ^_^
[08:02] <dholbach> pbek, but you can ask in #launchpad
[08:02] <pbek> I wanted, but the one who knows everything (you) wasn't online there :D
[08:02] <dholbach> hikiko, no, just a normal new line - you should be able to just copy/paste what I put in the review at https://reviewable.io/reviews/ubuntu/snappy-playpen/171
[08:03] <dholbach> dz0ny, I never quite understood that - is that a comment which requires your attention? :-)
[08:12] <dz0ny> dholbach: do you rly have to click all "eyes" http://i.imgur.com/qiIMeC0.png next to change to make pr "resolved"
[08:13] <dz0ny> dholbach: also did you delete comments? or where they are?
[08:15] <dholbach> dz0ny, at the top there's also a "mark as reviewed" button
[08:16] <dholbach> no, I didn't delete them, they're just folded away ("Resolved - show 4 comments")
[08:20] <dz0ny> dholbach: where's that button? I only have this http://i.imgur.com/lT9Q3m9.png
[08:21] <dholbach> maybe it doesn't see you as a reviewer in this PR, that's why it's "mark as reviewed" is greyed out for you?
[08:21] <dz0ny> :D
[08:29] <mup> PR snapd#1540 closed: spread.yaml, tests: replace hello-world with test-snapd-tools <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1540>
[08:49] <commander_> whatsup guys
[08:51] <commander_> what are ops
[08:51] <zyga> ?
[08:51] <commander_> am on xchat and it says 2 ops
[08:51] <commander_> 2 ops and 242 total
[08:54] <commander_> snappy and snap are different ?
[08:54] <commander_> join #ubuntu
[09:29] <mup> PR snapd#1541 closed: snap-exec: add proper integration test for snap-exec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1541>
[09:41] <dholbach> hikiko, can you check the PR again - dpm said network-bind might be necessary as a plug?
[09:42] <mup> PR snapd#1501 closed: client: existing JSON fixtures uses tabs for indentation <Created by stevenwilkin> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1501>
[09:42] <hikiko> yes dholbach I didn't finish it I am adding icons too as dplanella said
[09:42] <dholbach> ok cool
[09:42] <hikiko> just too many things to learn
[09:43] <hikiko> thanks for your comments :) +the patience...
[09:44] <mup> PR snapd#1515 closed: asserts,daemon: cross checks for account and account-key assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1515>
[09:44] <dholbach> hikiko, thanks for your great work on this!
[09:46] <dpm> thanks hikiko!
[09:56] <trijntje> Good morning all, I'm still strugling with my first snap. If someone could look at it (https://github.com/Redmar-van-den-Berg/archaeopteryx) and the errors I get  http://pastebin.com/PLNdH3yM I would be grateful
[09:58] <dholbach> hikiko, sorry, I meant network-bind as a plug, not as a build-package
[09:59] <hikiko> oops
[09:59] <hikiko> sorry dholbach
[10:05] <hikiko> dholbach, dpm I write a hexchat.desktop file following the qcomicbook example and I was wondering how could I test it works locally? (I still can't run cleanbuild)
[10:06] <dpm> hikiko, you can just run `snapcraft clean` and then `snapcraft`. That will build your snap
[10:06] <dpm> hikiko, then install the snap with `sudo snap install *.snap`
[10:06] <dpm> hikiko, and once it's installed, you can just open the dash to check if the icon appears there and launch hexchat
[10:08] <hikiko> dpm, thank you! I am going to try it
[10:10] <dpm> np :)
[10:23] <dpm> hikiko, I'm not sure you've seen the PR I sent earlier against your playpen repo on github. I added a couple of changes more (specifying the right version, using the unity7 plug, removing dh-autoreconf)
[10:27] <hikiko> sorry dpm, I just did, I am going to merge it right now
[10:27] <mup> PR snapd#1542 opened: cmd/snap,cmd/snap-exec: support running hooks via snap-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/1542>
[10:30] <dpm> great
[10:31] <mup> PR snapd#1450 closed: tests: extend refresh test to talk to the staging and production stores <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1450>
[10:38] <mup> PR snapd#1391 closed: overlord/snapstate, daemon, client, cmd/snap: devmode override (aka confined) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1391>
[10:53] <dpm> trijntje, a couple of comments: I think you might be better off asking on the mailing list for this one, as I'm not sure if there are any java experts around atm.
[10:53] <dpm> trijntje, Another thing: rather than including the .jar file in your repo, you can specify a remote source for the `copy` plugin, that is https://googledrive.com/host/0BxMokdxOh-JRM1d2azFoRnF3bGM/download/forester_1041.jar directly
[10:53] <dpm> trijntje, you might also want to look at a couple of other .jar snap examples:
[10:54] <hikiko> dpm, I think I messed it up :p I am not sure I merged your branch and not something else.. I tried to resolve/commit/merge following the git instructions here:
[10:55] <hikiko> https://githowto.com/resolving_conflicts
[10:56] <dpm> trijntje, here's one example: https://github.com/filebot/filebot/tree/master/installer/snappy
[10:57] <dpm> trijntje, here's another one: https://github.com/dplanella/snappy-playpen/tree/jtiledownloader/jtiledownloader and an alternative: https://github.com/ogra1/jtiledownloader
[10:58] <dpm> hikiko, unfortunately, I'm not a git expert, so I'm not sure I can help. What I generally do is to do `git merge`, then manually edit the files that have the conflict to resolve it, and then `git commit`
[10:58] <hikiko> mm that's what I did, I don't know much git either
[10:59] <hikiko> it seems to have the changes but I think I merged the master too accidentally afterwards
[11:00] <mup> PR snapd#1543 opened: store & many: a mechanical branch shortening store names <Created by chipaca> <https://github.com/snapcore/snapd/pull/1543>
[11:04] <hikiko> ouch dpm, I merged mine to yours and master to mine, I now merged the merged yours to mine and it seems fixed :) I have to add the desktop and done... dpm thanks a lot!
[11:04] <dpm> glad it worked out in the end! :)
[11:05] <trijntje> dpm: thanks for the feedback, I'll also have a look at the snaps you listed.
[11:05] <dpm> no worries, I hope it helps
[11:05] <dpm> hikiko, have you been in touch with hexchat upstream about your snap?
[11:07] <hikiko> no dpm should I?
[11:08] <hikiko> is there some process I have to follow for every snap?
[11:11] <dpm> hikiko, no worries, I was just wondering if you'd been in touch with them. I think he important thing is to get the snap running well first
[11:11] <hikiko> dpm, I did a merge proposal though because there was a compile error in hexchat and I sent a fix which isn't merged yet
[11:12] <dpm> hikiko, yeah, I saw that, good work
[11:13] <dpm> hikiko, so once the snap is working, we encourage folks to submit their snapcraft code upstream. Here are some guidelines: https://github.com/ubuntu/snappy-playpen/wiki/Upstreaming#forwarding-your-work-upstream
[11:13] <dpm> but we can look at it once the review for the playpen has finished
[11:19] <jacekn> Croepha: thanks. Would you have more detaila bout adding scripts to the environment? I can't do it inside my software because it's the build itself that's failing
[11:49] <mup> PR snapd#1544 opened: overlord/snapstate: kill flagscompat <Created by chipaca> <https://github.com/snapcore/snapd/pull/1544>
[11:54] <mup> PR snapd#1545 opened: snappy: what snappy <Created by chipaca> <https://github.com/snapcore/snapd/pull/1545>
[12:08] <mup> PR snapd#1544 closed: overlord/snapstate: kill flagscompat <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1544>
[12:09] <mup> PR snapd#1545 closed: snappy: what snappy <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1545>
[12:19] <mup> PR snapd#1543 closed: store & many: a mechanical branch shortening store names <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1543>
[12:20] <asac> sergiusens: so the java thing is trickier; we have maven for instance that also installs packages
[12:20] <asac> so it kind of bubbles up etc.
[12:30] <mup> PR snapd#1494 closed: tests: add content sharing interface spread test <Reviewed> <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1494>
[12:33] <ogra> trijntje, http://paste.ubuntu.com/19358043/ ... that gets me a runnable snap
[12:34] <ogra> (not sure why you have that gazillion of fonts in your snapcraft.yaml :) )
[12:37] <trijntje> ogra: because I kept finding references to font troubles when I tried to google the errors I got. I figured I'd remove all of them once I got the snap running
[12:38] <ogra> trijntje, well, it stearts on my laptop when i build it with the patch above
[12:39] <ogra> (surely could still need some additional optical adjustment, but it runs fine at least)
[12:44] <trijntje> ogra: your version works for me as well, thanks a million
[12:47] <ogra> trijntje, add "touch $SNAP_USER_DATA/_aptx_configuration_file" to your wrapper too ... then it stops complaining about the missing config
[12:49] <dpm> nice one ogra!
[12:50] <ogra> note that you might still need to ship some fonts and some more fontconfig magic ... i see crashes when i fiddle with the options in the app
[12:51] <ogra> (specifically when changing the fonts)
[12:51] <dpm> trijntje, you might want to submit it as a snappy playpen example too: https://github.com/ubuntu/snappy-playpen (just as a suggestion and to get more eyes on it, we've now got another jar example already)
[12:53] <ogra> hmm, on the upstrram page it is actually suggested to use the default config file they provide
[12:53] <ogra> *upstream
[12:53] <ogra> so you should probably ship that and copy it in place from the launcher
[12:56] <trijntje> ogra: would that be the preferred way, copy the config file to $SNAP_USER_DATA every time the snap is started?
[12:57] <ogra> [ -e "$SNAP_USER_DATA/_aptx_configuration_file" ] || cp _aptx_configuration_file $SNAP_USER_DATA/
[12:57] <ogra> trijntje, add that line ... then it only copies it on first start
[12:58] <ogra> hmm
[12:58] <ogra> [ -e "$SNAP_USER_DATA/_aptx_configuration_file" ] || cp $SNAP/_aptx_configuration_file $SNAP_USER_DATA/
[12:58] <ogra> thats bettr :)
[13:01] <trijntje> ogra: thanks. I was also thinking about modifying the default configuration file, but I guess that would be considered rude if I were to publish this snap to the store
[13:01] <ogra> why would that be rude ?
[13:01] <ogra> as long as you pick sane defaults i wouldnt think it is rude
[13:02] <ogra> thats the freedom of being a packager ... :)
[13:02] <ogra> (picking propoer defaults)
[13:02] <ogra> *proper
[13:04] <trijntje> fair enough, I wasn't planning on going crazy anyway ;)
[13:05] <ogra> :)
[13:17] <trijntje> ogra: one final question, if I submit it to the playpen, should I add the .jar file as well? _dpm suggested I should use the download link in the snapcraft file, but I'm worried that will change and break snap with the next release
[13:18] <ogra> well, you will need to update the link if the version changes upstream ...
[13:18] <ogra> but the download only happens at build time, so nothing that is already in the store will break
[13:18] <dpm> yeah, and I'm not sure we want to have huge binary files in the repo
[13:19]  * ogra doesnt care, but using the download is definitely more elegant ... 
[13:19] <mup> PR snapd#1539 closed: tests: improve snap run symlink tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1539>
[13:19] <ogra> and you can perhaps convince upstream more easily to take it if it comes down to only a snapcraft.yaml and wrapper
[13:20] <trijntje> download link it is then, and I'll also remove the gazillion font package I added in a bit of cargo cult madness
[13:21] <ogra> yeah
[13:21] <ogra> as i said, there is still some issue with the font selection ... but you can fix that iteratively later :)
[13:24] <trijntje> ogra: thanks again for looking into it for me, I was about to give up after doing 53 revisions without getting it to even start ;)
[13:24] <szszsz> Hi! Had anyone a problem with qt systray and snapd /tmp ?
[13:24] <ogra> trijntje, next time post your tree as first thing ;)
[13:25] <ogra> guessin by error message takes way longer than just trying out existing code ;)
[13:31] <dz0ny> trijntje: compiled binaries should be never in git repo
[13:31] <dz0ny> just one of cardinal rules
[13:33] <mup> PR snapd#1542 closed: cmd/snap,cmd/snap-exec: support running hooks via snap-exec <Created by mvo5> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1542>
[13:34] <kyrofa> szszsz, what kind of problem? The only one I know about is a broken icon
[13:37] <szszsz> kyrofa: For Qt5 it is not shown at all. I have found  that Qt creates png image in /tmp directory. Maybe App has no access there?
[13:37] <szszsz> kyrofa: could you share link to bug?
[13:38] <szszsz> kyrofa: correction, systray is shown but with default icon
[13:38] <kyrofa> szszsz, #1600136
[13:38] <mup> Bug #1600136: App indicator does not show icon for Qt apps <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1600136>
[13:38] <trijntje> dz0ny: its too late now, unless there is a way to re-write history on a github repository
[13:38] <szszsz> when runned without snappy it works correctly
[13:38] <kyrofa> szszsz, sound about right? Your instincts were spot on there, by the way (due to the use of /tmp)
[13:39] <kyrofa> szszsz, but slightly backwards-- the snap can put stuff in /tmp, but its /tmp actually ends up being in the system's /tmp/snap.foobar/, and the indicator looks for it in /tmp
[13:39] <szszsz> kyrofa: mup nice, thanks! I could not have found this one in google today
[13:40] <kyrofa> szszsz, mup is a bot that listens for bugrefs and other things
[13:40] <kyrofa> trijntje, there's always a way to rewrite history
[13:40] <kyrofa> trijntje, but it's not typically nice to your users
[13:40] <szszsz> kyrofa: Ahh, I see :)
[13:41] <trijntje> kyrofa: the good news is I dont have any users yet. I'll just remove the repository from github and add it again without the binary file
[13:42] <trijntje> unless thats forbidden on github?
[13:42] <kyrofa> trijntje, you can do that all from git
[13:42] <kyrofa> trijntje, oh not at all. I can help you do this without touching github-- you can do it all from git
[13:43] <kyrofa> trijntje, can I have a link to the repo?
[13:44] <trijntje> https://github.com/Redmar-van-den-Berg/archaeopteryx
[13:44] <kyrofa> trijntje, oh yeah, this'll be easy
[13:46] <kyrofa> trijntje, what are you trying to remove?
[13:47] <kyrofa> trijntje, or have you commited a removal already?
[13:47] <kyrofa> trijntje, the jar?
[13:49] <trijntje> kyrofa: no, the jar is still in the repository now
[13:49] <kyrofa> trijntje, indeed, and that's what you want to remove? It's used in your YAML... how do you plan on removing it?
[13:50] <trijntje> kyrofa: I want to remove the jar, and replace it with a copy from the download link in the yaml file
[13:50] <kyrofa> trijntje, ah ha
[13:50] <trijntje> this one: https://googledrive.com/host/0BxMokdxOh-JRM1d2azFoRnF3bGM/download/forester_1041.jar
[13:52] <kyrofa> trijntje, run this: `git rebase -i 44b29958d14a2b690fd6a4f062fe1e0b28090c50`
[13:52] <kyrofa> trijntje, it will bring up your editor. You'll see a few lines there, one of which is "pick 25a4443 Added wrapper and the jar file"
[13:52] <kyrofa> trijntje, change the "pick" to "edit"
[13:52] <kyrofa> (only on that single line)
[13:52] <kyrofa> Then save and exit
[13:53] <kyrofa> Now your terminal will drop to the shell and allow you to alter that commit however you like
[13:53] <kyrofa> Remove the jar and update the YAML. Give it a test, make sure it works the way you had in mind
[13:53] <kyrofa> Once you're happy with it, make sure you've `git add`ed everything, and run `git rebase --continue`
[13:55] <kyrofa> trijntje, err, you need to `git commit --amend` before you `git rebase --continue` though
[13:55] <kyrofa> Sorry
[13:57] <trijntje> ok, i'm trying to build the new snap now
[14:01] <mup> PR snapd#1508 closed: cmd/snap,cmd/snap-exec: support running hooks via snap-exec <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1508>
[14:05] <mup> PR snapd#1530 closed: asserts: add cross checks for snap asserts <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1530>
[14:23] <trijntje> kyrofa: I did all the commands, but now the wrapper is also back to an earlier version
[14:24] <kyrofa> trijntje, did you run the `git rebase --continue` command?
[14:25] <trijntje> kyrofa: I did http://pastebin.com/eaL3HDGM
[14:26] <trijntje> I ran it again: http://pastebin.com/6Yn7D0ca
[14:26] <kyrofa> trijntje, huh, so the changes you made completely negated that commit?
[14:28] <trijntje> kyrofa: I dont think so, I changed the yaml file, but I didn't touch the wrapper at all
[14:29] <ogra>  hmm .. do we have any interface that gets me acces to /dev/fuse ?
[14:32] <ogra> zyga, ^^ do you know ?
[14:33] <zyga> ogra: re
[14:34] <zyga> ogra: no we don't have one
[14:34] <zyga> ogra: is fuse something that could be tagged with an udev rule?
[14:34] <ogra> ah, i'll file a whishlist bug then ...
[14:34] <zyga> ogra: if so it should be relativelt simple to do the mechanics of granting permissions
[14:35] <ogra> well, as long as a user has fuse access he usually can mount/unmount all fuse based filesystems unprivileged
[14:35] <ogra> that sounds like th perfect thing for snaps
[14:35] <ogra> (i'm playing with a tool to do an automatic sshfs mount of my ubuntu phone... )
[14:36] <zyga> ogra: hmm, mount is probaby a no-go
[14:36] <zyga> ogra: with enough mount you can escape
[14:36] <zyga> ogra: but I'll let security guys comment on hat
[14:36] <ogra> it isnt mount ... it is fusermount
[14:36] <zyga> ogra: we can probably figure something out, maybe via a trusted helper
[14:36] <ogra> you cant mount/umount aything relevant
[14:36] <zyga> is fusermount a different system call?
[14:36] <ogra> could be ...
[14:38] <ogra> http://paste.ubuntu.com/19368313/ ... doesnt look like it needs special syscalls
[14:38]  * ogra tries devmode ... 
[14:39] <zyga> ogra: add "/dev/fuse rw," to the apparmor profile
[14:40] <zyga> ogra: and reload with apparmor_parser -r /path/to/profile
[14:40] <zyga> ogra: you should nail it faster this way
[14:40] <ogra> hmm
[14:40] <ogra> http://paste.ubuntu.com/19368550/ ...
[14:40] <ogra> devmode blocks too
[14:40] <ogra> the user needs to be in the fuse group (which i am) ... i wonder if that gets handed through to the launcher
[14:41] <zyga> ogra: I think so
[14:41] <zyga> ogra: we don't drop groups
[14:41] <ogra> k
[14:41] <zyga> ogra: so it does require mount
[14:41] <ogra> then it is something else
[14:41] <zyga> ogra: I think we could do something around that given that the argumennts are something apparmor can control
[14:41] <ogra> i can run the script from the snapcraft dir just fine
[14:42] <ogra> so something else is blocking additionally here
[14:42] <zyga> ogra: well, I see you are in devmode already
[14:42] <ogra> in tezh second paste i'm in devmode
[14:43] <zyga> yep
[14:43] <zyga> ogra: let's talk about this next week, :) I need to fix snap-confine
[14:43] <ogra> k
[14:49] <mup> PR snapcraft#657 opened: Add constraints to python2 plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/657>
[14:53] <mup> PR snapd#1531 closed: many: present user with a choice of payment backends <Created by pete-woods> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1531>
[14:55] <mup> Bug #1603113 opened: add fuse filesystem interface <Snappy:New> <https://launchpad.net/bugs/1603113>
[15:00] <mup> PR snapd#1546 opened: store: kill setUbuntuStoreHeaders <Created by chipaca> <https://github.com/snapcore/snapd/pull/1546>
[15:08] <imexil> looking at popey's snapcraft screencast I was wondering if there also exits a snap for simplescreenrecorder
[15:11] <ogra> ogra@styx:~/Devel/packages/snaps/phonemount$ snap find screen recorder
[15:11] <ogra> Name  Version  Developer  Notes  Summary
[15:11] <ogra> vlc   daily    caldav     -      Read, capture, broadcast your multimedia streams
[15:11] <ogra> doesnt look like it ...
[15:11] <ogra> go ahead and package it ;)
[15:11] <imexil> I was afraid that would be the answer ;-)
[15:11] <ogra> haha
[15:12] <ogra> surely some good finger training :)
[15:16] <dholbach> I think that was asciinema
[15:17] <ogra> well, but having a gui recorder would be nice too
[15:18] <dholbach> sure, just saying
[15:25] <mup> PR snapcraft#658 opened: parser - Return non-zero code for wiki errors <Created by josepht> <https://github.com/snapcore/snapcraft/pull/658>
[15:39] <SamYaple> new to snappy here. Does snappy have a way to share layers similiar to docker/rkt? I am packaging openstack in snappy but I spend alot of time building the same python packages over and over
[15:40] <Croepha> SamYaple not really
[15:40] <SamYaple> yea i thought not. thats fine, im just worried about total size being an issue
[15:41] <SamYaple> ~20 different services all at 200MB... ouch
[15:41] <SamYaple> not to mention the build time, though thats less of an issue
[15:41] <Croepha> SamYaple, it might be best to bundle them all in one snap... you can do multiple apps in one snap
[15:42] <SamYaple> Croepha: I am considering that, but that limits flexibility in version selection. not all of the services package/tag at the same time
[15:43] <SamYaple> they are different apps
[15:43] <Croepha> I'm not exactly recommending this as a course of action, but i think it is technically possible for one snap to reference content from another snap
[15:44] <SamYaple> Croepha: do you have any links so I can evaluate that?
[15:44] <Croepha> via /snap/othersnap/current/...
[15:44] <Croepha> not really, sorry
[15:44] <SamYaple> not a problem at all
[15:45] <Croepha> i'm not even sure that is a supported  use case, i just found that out by playing around
[15:45] <SamYaple> since I am new to snappy, im unsure where /snap/othersnap/current would come into play
[15:45] <Croepha> its a path on the filesystem
[15:45] <SamYaple> oh.. i see what youre saying
[15:45] <SamYaple> yea im not a fan of that
[15:46] <SamYaple> ill get a total size of the packages and see
[15:46] <SamYaple> I can save alot of space in each service by cherry-picking files
[15:46] <Croepha> if you do bundle them all as one snap, then it might be best to do a periodic release strategy
[15:46] <SamYaple> maybe that will eb enough
[15:47] <SamYaple> well asuming this packing goes well ill be throwing this into an openstack offical project, but it would almost certainly need to be seperate rather than a bundle
[15:47] <Croepha> like 2016.7 2016.8 ... 2016.12 for each month?
[15:47] <SamYaple> I do agree that should that be required, periodic would be best
[15:48] <Croepha> you do have the benefit of differential updates too, so what is common between versions wont have to be downloaded again
[15:50] <SamYaple> differential between individual packages?
[15:50] <iliv> I added a few interfaces for apps in snapcraft.yml and it seems like the only way for this change to come to life is to rebuild all associated parts. Is there a way to do this without rebuilding source code? In my case it is a bit a lengthy process so not much fun just sitting here waiting for a ...
[15:50] <iliv> ... program to finish compiling.
[15:50] <Croepha> no, differential between versions of the same package
[15:50] <mup> PR snapd#1547 opened: many: remove all traces of channel from the buying codepath <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1547>
[15:50] <SamYaple> Croepha: right thats what i was asking. ok thats good to know
[15:51] <Croepha> SamYaple: it might be worth checking if some kind of layers like support is in the issue tracker
[15:52] <SamYaple> I will
[15:52] <SamYaple> to be honest, im kind of glad there are no layers. layers add complication
[15:53] <SamYaple> i didnt really like them when i built them into kolla (the openstack in docker containers project)
[15:53] <SamYaple> you always had to make compromises about what would be in both and it tied all the packages together more than i liked
[15:55] <Croepha> iliv: I don't know the answer to that question... but from my experience  you pretty much have to do a full clean for most snapcraft.yaml changes, but you might want to try building outside of snapcraft and then copying back in, thats what I have resolved to doing
[15:55] <iliv> that sucks Croepha
[15:55] <ogra> iliv, look as the snapcraft clean options ...
[15:56] <iliv> ha, I was just about to highlight you ogra and ask to chime in on this matter
[15:56] <Croepha> iliv: also, you know about --try right?
[15:56] <ogra> you can clean different stages
[15:56] <mup> PR snapd#1548 opened: many: add new `snap weld` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/1548>
[15:56] <mup> PR snapd#1549 opened: docs: add payment methods documentation <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1549>
[15:56] <iliv> Croepha, know but I'll look into it
[15:57] <iliv> ogra, right, I use clean --step build a lot
[15:58] <SamYaple> what is the difference between build-packages and stage-packages? are stage-packages included in the final snap and build-packages are nto?
[15:59] <iliv> SamYaple, that sounds correct
[15:59] <Croepha> iliv: my usual iteration loop is sudo snap remove my-app; snapcraft clean && snapcraft prime && snapcraft try --devmode prime/  (and that is after I have built the binaries externally and in my snapcraft.yaml is just a copy)
[15:59] <iliv> SamYaple, build-packages are required for compiling/building your application. stage-pacakges are sort of like dependecies that are included in the resulting snap package.
[16:01] <iliv> Croepha, I've been doing it similarly but I'm happy with a complete snap package. Install it, test it and see what doesn't work and the adjust snapcraft.yml and rebuild.
[16:02] <ogra> iliv, well, just use --step stage ...
[16:02] <SamYaple> iliv: strange then. i have all packages in build-packages and yet there are libs in teh stage folder
[16:03] <SamYaple> i _want_ those libs there, but im wondering if that is snappy being clever, or be not understanding something
[16:15] <vidasov> Hi
[16:16] <vidasov> Sorry I have basic questions regarding snapcraft if possible?
[16:17] <Croepha> SamYapleL I think Snappy tries to be clever, using ldd (or more?) to do things like that
[16:17] <Croepha> SamYaple doesn't work well with dload though...
[16:17] <kyrofa> vidasov, ask away!
[16:19] <SamYaple> Croepha: it seems to keep around all the of header files and manpage docs
[16:20] <Croepha> from stage-packages?
[16:20] <SamYaple> from build-packages
[16:20] <SamYaple> i have no stage-packages
[16:20] <Croepha> huh, i wouldn't have expected that, maybe some experts here can chime in
[16:21] <vidasov> yes thanks, I started this morning with snapcraft and went trough ubuntu page tutorial which is the same thing as in snapcraft.io but it didn't work for me and looks lilke snapcraft doesn't apply changes is yaml file is changed
[16:22] <ogra> SamYaple, where does it keep them around ? build-packages should definitely not be copied into the final snap
[16:22] <ogra> (they surely stay around in youtr build tree until you call "snapcraft clean")
[16:22] <dz0ny> SamYaple: build-packages are host packages, stage-are those that are bundled into your snap
[16:22] <Croepha> vidasov, snapcraft clean ?
[16:23] <mup> PR snapd#1550 opened: tests: base security spread tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1550>
[16:23] <SamYaple> ogra: /usr/include/* has a whole lotta header files from packages like libc6-dev
[16:23] <kyrofa> vidasov, indeed, snapcraft is slowly gaining those types of features
[16:23] <ogra> vidasov, you need to clean first before running a new snapcraft build, else it will just copy the existing bits from the parts/*/install dirs
[16:24] <SamYaple> ogra: i never explicitly installed libc6-dev, it was building in by build-essential (or maybe python-dev)
[16:24] <Croepha> SamYaple, but what about prime/usr/include ?
[16:24] <kyrofa> vidasov, until it gets smarter you need to clean between changes. You can clean individual steps though instead of cleaning entirely
[16:24] <SamYaple> Croepha: same
[16:24] <ogra> SamYaple, that is in your installed snap (under /snap/$packagename/current/) ?
[16:24] <dz0ny> I kindo don't like that it picks libs from host at all
[16:25] <dz0ny> when i started i assumed it would start from ubuntu-core
[16:25] <SamYaple> ogra: its in the squashfs of the snap, i havent installed it, but i mounted teh squashfs
[16:25] <ogra> weird, i have never seen that happen here
[16:25] <SamYaple> maybe its because build-essential is a meta package?
[16:25] <ogra> since ... if you dont use cleanbuild ... the dev packages are all installed on your host machine ...
[16:25] <Croepha> SamYaple:  which package? if you dont mind
[16:26] <ogra> and bits from the host machine can technically not really end up inside the snap
[16:26] <SamYaple> let me try to clean this entirely out
[16:26] <dz0ny> ogra: they can :)
[16:26] <ogra> using meta packages is fine
[16:26] <ogra> dz0ny, they shouldnt
[16:26] <dz0ny> snpacraft is not isolated from host system
[16:27] <ogra> how would they end up insdie the build tree
[16:27] <vidasov> OK thanks for your clarification, sound good for beginning, so I did a workaround prepared everything in one shot and compiles ok, this webcam tutorial so how to check if it works actually? it looks i cant run new app from command line
[16:27] <ogra> given they get installed in the host and not in the "parts" staging area
[16:27] <dz0ny> LD_*
[16:27] <ogra> only bits under parts/ end up in the snap
[16:28] <SamYaple> rebuilding now, clean parts folder and all
[16:28] <Croepha> vidasov: When you do a snap install, it adds special commands to your system path, look for a command that starts with your snap name
[16:28] <dz0ny> but when you compile something it's picked from host (header files,libs etc)
[16:28] <ogra> you would have to have symlinks or bindmounts into that dir to have them end up in prime/ or stage/
[16:28] <dz0ny> no
[16:28] <dz0ny> ogra: I have a test
[16:29] <vidasov> yes and when I do snap list, I see app, but when I try to run it nothing
[16:29] <Croepha> vidasov, like no output, and no error?
[16:29] <vidasov> like no app at all
[16:30] <ogra> did you check syslog ?
[16:30] <ogra> there should be errors if it didnt start
[16:30] <dz0ny> ogra: https://github.com/ubuntu/snappy-playpen/pull/166 try this one on system without ffmepg libs in normal paths
[16:30] <mup> PR ubuntu/snappy-playpen#166: Add champ snap <Created by dz0ny> <https://github.com/ubuntu/snappy-playpen/pull/166>
[16:31] <Croepha> vidasov: this is the webcam example?
[16:31] <dz0ny> it does build on docker+travis but not in isolated machine
[16:31] <vidasov> yes, webcam
[16:31] <dz0ny> if it has ffmpeg isntalled
[16:32] <SamYaple> yep, totally clean rebuild the final snap squashfs has a bunch of headers in /usr/include
[16:32] <ogra> dz0ny, not really sure whast you mean with "ld" ... ld always comes from ubuntu-core at runtime
[16:33] <vidasov> if syslog and ffmpeg were meant for me, thanks but I cant even run app and it is listed as installed
[16:33] <ogra> vidasov, syslog was meant for you,. yes ... watch it when you try to start the app or when yiou install the snap (in case it has a service and not an enduser app inside)
[16:34] <SamYaple> ok well im going to go to lunch, ill dig into this more when i get back. if anyone has more suggestions for me to try, just ping me. thanks!
[16:34] <Croepha> vidasov: ok, I think that installs as a daemon, so that wont be in your $PATH, do you get anything when you do "systemctl --all | grep webcam"
[16:36] <vidasov> ok this tells something: snap.webcam-webui.webcam-webui.service                                                      loaded    inactive dead
[16:37]  * ogra would just open an additional terminal and run "tail -f /var/log/syslog" and then uninstall and re-install the snap 
[16:37] <ogra> that should give you all errors
[16:37] <vidasov> ok, will do
[16:37] <Croepha> there is also journalctl -u snap.webcam-webui.webcam-webui.service
[16:38] <ogra> doesnt the webcam demo need the camera inetrface ?
[16:38] <ogra> i thnk that one needs manual connecting after installing the snap
[16:39] <ogra> something like: "sudo snap connect $yourpackage:camera ubuntu-core:camera"
[16:44] <vidasov> ok, does that mean that "$yourpackage:camera" is app on ubuntu and "ubuntu-core:camera" is app which I need to install in ubuntu core
[16:44] <vidasov> as a snap
[16:47] <vidasov> so little bit confuzed
[16:50] <kyrofa> vidasov, ubuntu-core is a snap that is a prerequisite for all other snaps. You should see it in the `snap list` output
[16:50] <kyrofa> vidasov, it provides the slot side of many interfaces
[16:50] <kyrofa> vidasov, including the camera
[16:50] <vidasov> ok, I saw it
[16:50] <kyrofa> vidasov, but as ogra mentioned, that interface it not connected by default, so you'll need to connect it manually using the command he gave
[16:51] <vidasov> good, I'll try
[16:51] <vidasov> thnx
[17:06] <kyrofa> sergiusens, elopio bug planning today, or no?
[17:20] <josepht> kyrofa: sergiusens is out today and tomorrow
[17:21] <kyrofa> josepht, ah ha
[17:21] <kyrofa> josepht, thanks for letting me know!
[17:21] <josepht> kyrofa: np :)
[17:21] <kyrofa> elopio, what is YOUR excuse?
[17:49] <mup> PR snapd#1551 opened: systemd,wrappers: map "never" restart condition to "no." <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1551>
[17:55] <wililupy> Is it possible for me to do a git checkout from snapcraft.yaml?
[17:55] <mup> PR snapcraft#659 opened: Support "never" as a daemon restart condition <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/659>
[17:58] <kyrofa> wililupy, of course
[17:59] <kyrofa> wililupy, provide the git URL to the source. Depending on what the URL looks like you may also need to specify source-type: git
[17:59] <wililupy> kyrofa: \o/
[17:59] <kyrofa> wililupy, you can also specify source-branch or source-tag
[17:59] <kyrofa> wililupy, `snapcraft help sources` for more info
[18:00] <wililupy> kyrofa, perfect, that is what I was looking for.
[18:01] <wililupy> kyrofa: For source-branch, can I use the first 7 chars from the hash or do I need to full hash?
[18:02] <wililupy> kyrofa, git specific
[18:02] <wililupy> ly
[18:02] <kyrofa> wililupy, you should be able to use the short
[18:03] <wililupy> kyrofa, excellent. I'm going to give it a shot. Thanks!
[18:05] <kyrofa> wililupy, sure thing
[18:46] <mup> PR snapd#1549 closed: docs: add payment methods documentation <Created by pete-woods> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1549>
[18:58] <mup> PR snapcraft#596 closed: Preserve the ordering of the wiki entries <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/596>
[19:04] <kyrofa> elopio, josepht mind taking a look at #659?
[19:04] <kyrofa> snapcraft#659 maybe?
[19:04] <mup> PR snapcraft#659: Support "never" as a daemon restart condition <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/659>
[19:05] <vidasov> hi, does snappy has bluetooth interface, looks like not?
[19:15] <josepht> kyrofa: done
[19:31] <ali1234> which tarball do i need to make a development chroot?
[19:31] <ali1234> ubuntu-core or ubuntu-base?
[19:46] <mup> PR snapcraft#660 opened: Fix python2 compile cache removal <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/660>
[20:05] <elopio> kyrofa: reviewed. And replying to the previous ping, my excuse is that I had to my swimming lessons. I need to apply myself if I want to beat all my elder classmates :)
[20:12] <ali1234> hmm.. well that totally failed
[20:15] <vidasov> sorry, question please: can snappy app connect to bluetooth as to interface? Or is it possible to have snappy communicate over bluetooth?
[20:16] <ali1234> i'm sure it will be possible eventually
[20:16] <ali1234> i don't know if it is possible now
[20:17] <vidasov> thanks, I was afraid of it. :-) but let us be patient.
[20:22] <ali1234> looks like the ubuntu raspberry pi image doesn't have drm support or something
[20:25] <mup> PR snapd#1546 closed: store: kill setUbuntuStoreHeaders <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1546>
[20:25] <mup> PR snapd#1546 closed: store: kill setUbuntuStoreHeaders <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1546>
[20:30] <SamYaple> do all of the binaries go to /snap/bin ? what about those that are located in usr/bin/* in the snap?
[20:30] <SamYaple> i suppose my question is, what is _meant_ to be in /snap/bin ?
[20:35] <Croepha> vidasov: if you want to access something that isn't supported, just run with devmode enabled for now until its supported, and you should probably also file a bug outlining what you want access to
[20:37] <Croepha> SamYaple: /snap/bin is just shell scripts that act as entry points into files stored in /snap/.../current/bin/...
[20:37] <vidasov> ok, thanks Croepha, that is nice to hear that is possible, after all :-)
[20:38] <Croepha> SamYaple: you only get files in /snap/bin if you set them as apps in your snapcraft.yaml file
[20:40] <ali1234> okay i've got a challenge for anyone who is bored... snap a Qt5 app so that it runs on the raspberry pi without a windowing system, using the eglfs platform, and having full accelerated graphics
[20:40] <ali1234> this is how you do it on raspbian: https://wiki.qt.io/RaspberryPi2EGLFS
[20:41] <Croepha> ali1234 I did that the other day
[20:41] <ali1234> great. how?
[20:41] <Croepha> well, i got it running on amd64
[20:41] <Croepha> sec
[20:41] <ali1234> doing it on amd64 is trivial
[20:41] <ali1234> to do it on raspberry pi you need: Qt >= 5.6 (not available in ubuntu)
[20:42] <ali1234> you also need the raspberry pi EGL libs from this ppa: https://launchpad.net/~ubuntu-raspi2/+archive/ubuntu/ppa
[20:42] <Croepha> huh ok, nvm then, i don't remember it being trivial, I had to set all kinds of variables for alsa and gstreamer to know where to load their modules and stuff
[20:43] <ali1234> you also need to fix the raspberry pi ubuntu kernels so that DRM works
[20:43] <ali1234> it's trivial in comparison
[20:43] <ali1234> whatever you needed to do, you need to do all that stuff on top ^
[20:44] <Croepha> ok, i still can't figure out how to build a 16 ubuntu-core image
[20:44] <ali1234> i've done that
[20:44] <Croepha> let alone put a custom kernel in it
[20:45] <ali1234> ubuntu-device-flash builds the image
[20:45] <ali1234> but at the moment i'm working with the server image
[20:45] <ali1234> so not ubuntu-core
[20:46] <ali1234> i'm trying to build a custom qt to see if it makes drm work, but i'm not holding my breath
[20:46] <Croepha> can you point me to a doc? something more up-to-date than this: https://developer.ubuntu.com/en/snappy/guides/porting/ ?
[20:46] <ali1234> something like this http://people.canonical.com/~mvo/all-snaps/make-rpi2-all-snap.sh
[20:46] <ali1234> although that might be out of date
[20:50] <Croepha> this looks promising: http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/
[20:50] <Croepha> except for the fact that im starting with kernel debs instead of the source
[20:51] <Croepha> i'll have to look at that tomorrow
[20:52] <Croepha> its weird that they woundn't build the rpi kernel with DRM
[20:52] <ali1234> yes
[20:52] <ali1234> maybe it's some other problem, i don't know
[20:52] <Croepha> thats like what 200Kb more?
[20:52] <ali1234> the problem is the raspberry pi libs aren't in the main repo
[20:53] <ali1234> so they can't build anything against them
[20:53] <ali1234> i don't know if that matters for the kernel though
[20:53] <ali1234> maybe the raspi stuff isn't upstreamed
[20:53] <ali1234> i guess i'll have to just keep using raspbian for now (again)
[20:54] <ali1234> even ./configure on qtbase has taken like 20 minutes so far
[20:54] <Croepha> ali1234 are you crosscompiling ?
[20:54] <ali1234> no
[20:54] <ali1234> i cross compiled it for raspbian
[20:54] <Croepha> that will probably take days
[20:55] <ali1234> but i wanted to see how long it will take native
[20:55] <ali1234> it should not take days, qtbase is not that big any more now everything is modular
[20:55] <ali1234> actuallyi can probably just push my cross compiled version to ubuntu
[20:56] <ali1234> it will probably work right? right?
[20:56] <ali1234> configure says:      EGLFS Raspberry Pi . no
[20:56] <ali1234> so that not gonna work :/
[20:57] <Croepha> its a shame there is no https://launchpad.net/~beineri/+archive/ubuntu/opt-qt57-xenial for rpi
[20:57] <ali1234> yes, i already tried that
[20:58] <ali1234> maybe i need some magic config option
[21:00] <Croepha> might be easier just to give up on QT
[21:00] <ali1234> lolno
[21:00] <ali1234> it would be easier to just use raspbian
[21:00] <Croepha> right
[21:00] <ali1234> i can't give up on qt, there is literally nothing else as good
[21:01] <ali1234> and it works perfectly on raspbian... 60FPS, no tearing, touch screen works perfectly
[21:01] <Croepha> can you just copy out all the QT binaries from raspian?
[21:02] <ali1234> i could do yes, but i would not expect them to work
[21:02] <Croepha> it will probably work, with some elbo-grease
[21:02] <ali1234> except it wont, if drm is missing
[21:02] <ali1234> let me try it, hang on
[21:03] <Croepha> right, if DRM is missing then thats a stopper
[21:03] <Croepha> ok, can you copy the kernel from rasbian ?
[21:04] <ali1234> hang on testing qt first
[21:04] <ali1234> if i copy the kernel and the user space i might as well just use raspbian at that point :)
[21:05] <Croepha> well, the advantage of snappy, is that you will be able to do transactional updates
[21:05] <Croepha> but yea, the work will probably not be worth it
[21:06] <Croepha> atleast for first movers
[21:08] <ali1234> hmm egl library problems
[21:08] <ali1234> libraspberrypi0 from the ppa installs it in /usr/lib and it conflicts with mesa
[21:08] <Croepha> hmm
[21:09] <Croepha> im not sure what libraspberrypi0 is, but if it provides a mesa implementation, then you should probably link with that instead of what ever is default
[21:09] <ali1234> you don't link against it directly
[21:09] <ali1234> mesa implementations are interchangable
[21:09] <ali1234> the problem is i can't get it top open the thing
[21:10] <Croepha> well, snappy sets the LD_LIBRARY_PATH, so that stuff in your snap gets loaded first
[21:12] <ali1234> yeah qt built for raspbian doesn't work on ubuntu
[21:12] <ali1234> This application failed to start because it could not find or load the Qt platform plugin "eglfs"
[21:12] <ali1234> the plugin is definitely there, it just won't load
[21:14] <Croepha> i know this one
[21:14] <ali1234> HAH
[21:14] <ali1234> i know why none of this works
[21:14] <Croepha> you need a export QT_PLUGIN_PATH=/snap/$your_app/usr/lib/x86_64-linux-gnu/qt5/plugins/
[21:14] <ali1234> i'm not running it in a snap
[21:15] <ali1234> i'm running it from /usr/local
[21:15] <Croepha> ahh ok
[21:15] <ali1234> it doesn't work
[21:15] <ali1234> anyway the qt source has this handy little test program for eglfs-brcm
[21:16] <ali1234> it fails to build on ubuntu, hence why it doesn't work
[21:16] <Croepha> in order to get my QT working in snap, I had to set these variables:  XDG_DATA_HOME XDG_CONFIG_HOME QT_PLUGIN_PATH GST_PLUGIN_SYSTEM_PATH_1_0 GIO_MODULE_DIR GSETTINGS_SCHEMA_DIR
[21:16] <Croepha> oh and ALSA_CONFIG_PATH
[21:17] <ali1234> so here's a revised version of my challenge. snap this: http://paste.ubuntu.com/19414877/
[21:17] <ali1234> it's only 11 lines of code, should be easy right?
[21:17] <Croepha> you have to do it in devmode, because there is no interface for it
[21:18] <Croepha> but assuming there is /dev/drm it should be easy
[21:40] <mup> PR snapd#1532 closed: release: fix Elementary support <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1532>
[21:40] <mup> PR snapd#1552 opened: release: work around elementary mistake <Created by chipaca> <https://github.com/snapcore/snapd/pull/1552>
[23:25] <mup> PR snapcraft#661 opened: Added a test Jenkinsfile <Created by elopio> <https://github.com/snapcore/snapcraft/pull/661>
[23:55] <mup> PR snapcraft#659 closed: Support "never" as a daemon restart condition <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/659>