=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:37] PR snapd#1457 opened: snapstate: drop revisions after "current" on refresh [05:41] PR snapd#1534 closed: tests: add system-observe interface spread test [06:04] PR snapd#1520 closed: tests: add locale-control interface spread test [06:04] PR snapd#1522 closed: Introduce a simple key-value store for user-specific data [06:05] PR snapd#1512 closed: overlord: initial work on renaming core snap [06:11] 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] PR snapd#1519 closed: Add Qt5 indicator support in unity7 interface === chihchun_afk is now known as chihchun [07:03] hey hey [07:03] hey hey hey! [07:45] Is that just me https://github.com/ubuntu/snappy-playpen/issues/176 [07:51] dz0ny, what if you open https://reviewable.io/reviews/ubuntu/snappy-playpen/166? [07:51] I agree that reviewable clutters up the normal pull request views [07:52] 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] https://reviewable.io/reviews#- is a very clear overview for me [07:53] 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] dholbach: I totally not saw that button! I just looked at the "published" state at the top. Thanks a lot! [07:55] anytime [07:56] I'm not sure if you can configure it to auto-publish - I seem to remember there was something like that [07:57] dholbach: butterflies fly around following my mouse and each button hover shows 3 options :) [07:57] tsimonq2, hello [07:58] mmm I guess is too late for you... [07:58] 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] 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] do I need something like \n at the end? [08:01] pbek, no idea, sorry [08:02] thx ^_^ [08:02] pbek, but you can ask in #launchpad [08:02] I wanted, but the one who knows everything (you) wasn't online there :D [08:02] 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] dz0ny, I never quite understood that - is that a comment which requires your attention? :-) [08:12] dholbach: do you rly have to click all "eyes" http://i.imgur.com/qiIMeC0.png next to change to make pr "resolved" [08:13] dholbach: also did you delete comments? or where they are? [08:15] dz0ny, at the top there's also a "mark as reviewed" button [08:16] no, I didn't delete them, they're just folded away ("Resolved - show 4 comments") [08:20] dholbach: where's that button? I only have this http://i.imgur.com/lT9Q3m9.png [08:21] 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] :D [08:29] PR snapd#1540 closed: spread.yaml, tests: replace hello-world with test-snapd-tools [08:49] whatsup guys [08:51] what are ops [08:51] ? [08:51] am on xchat and it says 2 ops [08:51] 2 ops and 242 total [08:54] snappy and snap are different ? [08:54] join #ubuntu [09:29] PR snapd#1541 closed: snap-exec: add proper integration test for snap-exec [09:41] hikiko, can you check the PR again - dpm said network-bind might be necessary as a plug? [09:42] PR snapd#1501 closed: client: existing JSON fixtures uses tabs for indentation [09:42] yes dholbach I didn't finish it I am adding icons too as dplanella said [09:42] ok cool [09:42] just too many things to learn [09:43] thanks for your comments :) +the patience... [09:44] PR snapd#1515 closed: asserts,daemon: cross checks for account and account-key assertions [09:44] hikiko, thanks for your great work on this! [09:46] thanks hikiko! [09:56] 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] hikiko, sorry, I meant network-bind as a plug, not as a build-package [09:59] oops [09:59] sorry dholbach [10:05] 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] hikiko, you can just run `snapcraft clean` and then `snapcraft`. That will build your snap [10:06] hikiko, then install the snap with `sudo snap install *.snap` [10:06] hikiko, and once it's installed, you can just open the dash to check if the icon appears there and launch hexchat [10:08] dpm, thank you! I am going to try it [10:10] np :) [10:23] 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] sorry dpm, I just did, I am going to merge it right now [10:27] PR snapd#1542 opened: cmd/snap,cmd/snap-exec: support running hooks via snap-exec [10:30] great [10:31] PR snapd#1450 closed: tests: extend refresh test to talk to the staging and production stores [10:38] PR snapd#1391 closed: overlord/snapstate, daemon, client, cmd/snap: devmode override (aka confined) [10:53] 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] 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] trijntje, you might also want to look at a couple of other .jar snap examples: [10:54] 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] https://githowto.com/resolving_conflicts [10:56] trijntje, here's one example: https://github.com/filebot/filebot/tree/master/installer/snappy [10:57] trijntje, here's another one: https://github.com/dplanella/snappy-playpen/tree/jtiledownloader/jtiledownloader and an alternative: https://github.com/ogra1/jtiledownloader [10:58] 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] mm that's what I did, I don't know much git either [10:59] it seems to have the changes but I think I merged the master too accidentally afterwards [11:00] PR snapd#1543 opened: store & many: a mechanical branch shortening store names [11:04] 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] glad it worked out in the end! :) [11:05] dpm: thanks for the feedback, I'll also have a look at the snaps you listed. [11:05] no worries, I hope it helps [11:05] hikiko, have you been in touch with hexchat upstream about your snap? [11:07] no dpm should I? [11:08] is there some process I have to follow for every snap? [11:11] 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] 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] hikiko, yeah, I saw that, good work [11:13] 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] but we can look at it once the review for the playpen has finished [11:19] 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 === chihchun is now known as chihchun_afk === hikiko is now known as hikiko|ln [11:49] PR snapd#1544 opened: overlord/snapstate: kill flagscompat === chihchun_afk is now known as chihchun [11:54] PR snapd#1545 opened: snappy: what snappy [12:08] PR snapd#1544 closed: overlord/snapstate: kill flagscompat [12:09] PR snapd#1545 closed: snappy: what snappy [12:19] PR snapd#1543 closed: store & many: a mechanical branch shortening store names [12:20] sergiusens: so the java thing is trickier; we have maven for instance that also installs packages [12:20] so it kind of bubbles up etc. [12:30] PR snapd#1494 closed: tests: add content sharing interface spread test [12:33] trijntje, http://paste.ubuntu.com/19358043/ ... that gets me a runnable snap [12:34] (not sure why you have that gazillion of fonts in your snapcraft.yaml :) ) === hikiko|ln is now known as hikiko [12:37] 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] trijntje, well, it stearts on my laptop when i build it with the patch above [12:39] (surely could still need some additional optical adjustment, but it runs fine at least) [12:44] ogra: your version works for me as well, thanks a million [12:47] trijntje, add "touch $SNAP_USER_DATA/_aptx_configuration_file" to your wrapper too ... then it stops complaining about the missing config [12:49] nice one ogra! [12:50] 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] (specifically when changing the fonts) [12:51] 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] hmm, on the upstrram page it is actually suggested to use the default config file they provide [12:53] *upstream [12:53] so you should probably ship that and copy it in place from the launcher === chihchun is now known as chihchun_afk [12:56] ogra: would that be the preferred way, copy the config file to $SNAP_USER_DATA every time the snap is started? [12:57] [ -e "$SNAP_USER_DATA/_aptx_configuration_file" ] || cp _aptx_configuration_file $SNAP_USER_DATA/ [12:57] trijntje, add that line ... then it only copies it on first start [12:58] hmm [12:58] [ -e "$SNAP_USER_DATA/_aptx_configuration_file" ] || cp $SNAP/_aptx_configuration_file $SNAP_USER_DATA/ [12:58] thats bettr :) [13:01] 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] why would that be rude ? [13:01] as long as you pick sane defaults i wouldnt think it is rude [13:02] thats the freedom of being a packager ... :) [13:02] (picking propoer defaults) [13:02] *proper [13:04] fair enough, I wasn't planning on going crazy anyway ;) [13:05] :) [13:17] 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] well, you will need to update the link if the version changes upstream ... [13:18] but the download only happens at build time, so nothing that is already in the store will break [13:18] 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] PR snapd#1539 closed: tests: improve snap run symlink tests [13:19] and you can perhaps convince upstream more easily to take it if it comes down to only a snapcraft.yaml and wrapper [13:20] 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] yeah [13:21] as i said, there is still some issue with the font selection ... but you can fix that iteratively later :) [13:24] 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] Hi! Had anyone a problem with qt systray and snapd /tmp ? [13:24] trijntje, next time post your tree as first thing ;) [13:25] guessin by error message takes way longer than just trying out existing code ;) [13:31] trijntje: compiled binaries should be never in git repo [13:31] just one of cardinal rules [13:33] PR snapd#1542 closed: cmd/snap,cmd/snap-exec: support running hooks via snap-exec [13:34] szszsz, what kind of problem? The only one I know about is a broken icon [13:37] 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] kyrofa: could you share link to bug? [13:38] kyrofa: correction, systray is shown but with default icon [13:38] szszsz, #1600136 [13:38] Bug #1600136: App indicator does not show icon for Qt apps [13:38] dz0ny: its too late now, unless there is a way to re-write history on a github repository [13:38] when runned without snappy it works correctly [13:38] szszsz, sound about right? Your instincts were spot on there, by the way (due to the use of /tmp) [13:39] 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] kyrofa: mup nice, thanks! I could not have found this one in google today [13:40] szszsz, mup is a bot that listens for bugrefs and other things [13:40] trijntje, there's always a way to rewrite history [13:40] trijntje, but it's not typically nice to your users [13:40] kyrofa: Ahh, I see :) [13:41] 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] unless thats forbidden on github? [13:42] trijntje, you can do that all from git [13:42] trijntje, oh not at all. I can help you do this without touching github-- you can do it all from git [13:43] trijntje, can I have a link to the repo? [13:44] https://github.com/Redmar-van-den-Berg/archaeopteryx [13:44] trijntje, oh yeah, this'll be easy [13:46] trijntje, what are you trying to remove? [13:47] trijntje, or have you commited a removal already? [13:47] trijntje, the jar? [13:49] kyrofa: no, the jar is still in the repository now [13:49] 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] kyrofa: I want to remove the jar, and replace it with a copy from the download link in the yaml file [13:50] trijntje, ah ha [13:50] this one: https://googledrive.com/host/0BxMokdxOh-JRM1d2azFoRnF3bGM/download/forester_1041.jar [13:52] trijntje, run this: `git rebase -i 44b29958d14a2b690fd6a4f062fe1e0b28090c50` [13:52] 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] trijntje, change the "pick" to "edit" [13:52] (only on that single line) [13:52] Then save and exit [13:53] Now your terminal will drop to the shell and allow you to alter that commit however you like [13:53] Remove the jar and update the YAML. Give it a test, make sure it works the way you had in mind [13:53] Once you're happy with it, make sure you've `git add`ed everything, and run `git rebase --continue` [13:55] trijntje, err, you need to `git commit --amend` before you `git rebase --continue` though [13:55] Sorry [13:57] ok, i'm trying to build the new snap now [14:01] PR snapd#1508 closed: cmd/snap,cmd/snap-exec: support running hooks via snap-exec [14:05] PR snapd#1530 closed: asserts: add cross checks for snap asserts [14:23] kyrofa: I did all the commands, but now the wrapper is also back to an earlier version [14:24] trijntje, did you run the `git rebase --continue` command? [14:25] kyrofa: I did http://pastebin.com/eaL3HDGM [14:26] I ran it again: http://pastebin.com/6Yn7D0ca [14:26] trijntje, huh, so the changes you made completely negated that commit? [14:28] kyrofa: I dont think so, I changed the yaml file, but I didn't touch the wrapper at all [14:29] hmm .. do we have any interface that gets me acces to /dev/fuse ? [14:32] zyga, ^^ do you know ? [14:33] ogra: re [14:34] ogra: no we don't have one [14:34] ogra: is fuse something that could be tagged with an udev rule? [14:34] ah, i'll file a whishlist bug then ... [14:34] ogra: if so it should be relativelt simple to do the mechanics of granting permissions [14:35] well, as long as a user has fuse access he usually can mount/unmount all fuse based filesystems unprivileged [14:35] that sounds like th perfect thing for snaps [14:35] (i'm playing with a tool to do an automatic sshfs mount of my ubuntu phone... ) [14:36] ogra: hmm, mount is probaby a no-go [14:36] ogra: with enough mount you can escape [14:36] ogra: but I'll let security guys comment on hat [14:36] it isnt mount ... it is fusermount [14:36] ogra: we can probably figure something out, maybe via a trusted helper [14:36] you cant mount/umount aything relevant [14:36] is fusermount a different system call? [14:36] could be ... [14:38] http://paste.ubuntu.com/19368313/ ... doesnt look like it needs special syscalls [14:38] * ogra tries devmode ... [14:39] ogra: add "/dev/fuse rw," to the apparmor profile [14:40] ogra: and reload with apparmor_parser -r /path/to/profile [14:40] ogra: you should nail it faster this way [14:40] hmm [14:40] http://paste.ubuntu.com/19368550/ ... [14:40] devmode blocks too [14:40] the user needs to be in the fuse group (which i am) ... i wonder if that gets handed through to the launcher [14:41] ogra: I think so [14:41] ogra: we don't drop groups [14:41] k [14:41] ogra: so it does require mount [14:41] then it is something else [14:41] ogra: I think we could do something around that given that the argumennts are something apparmor can control [14:41] i can run the script from the snapcraft dir just fine [14:42] so something else is blocking additionally here [14:42] ogra: well, I see you are in devmode already [14:42] in tezh second paste i'm in devmode [14:43] yep [14:43] ogra: let's talk about this next week, :) I need to fix snap-confine [14:43] k [14:49] PR snapcraft#657 opened: Add constraints to python2 plugin === chihchun_afk is now known as chihchun [14:53] PR snapd#1531 closed: many: present user with a choice of payment backends [14:55] Bug #1603113 opened: add fuse filesystem interface [15:00] PR snapd#1546 opened: store: kill setUbuntuStoreHeaders [15:08] looking at popey's snapcraft screencast I was wondering if there also exits a snap for simplescreenrecorder [15:11] ogra@styx:~/Devel/packages/snaps/phonemount$ snap find screen recorder [15:11] Name Version Developer Notes Summary [15:11] vlc daily caldav - Read, capture, broadcast your multimedia streams [15:11] doesnt look like it ... [15:11] go ahead and package it ;) [15:11] I was afraid that would be the answer ;-) [15:11] haha [15:12] surely some good finger training :) [15:16] I think that was asciinema [15:17] well, but having a gui recorder would be nice too [15:18] sure, just saying [15:25] PR snapcraft#658 opened: parser - Return non-zero code for wiki errors [15:39] 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] SamYaple not really [15:40] yea i thought not. thats fine, im just worried about total size being an issue [15:41] ~20 different services all at 200MB... ouch [15:41] not to mention the build time, though thats less of an issue [15:41] SamYaple, it might be best to bundle them all in one snap... you can do multiple apps in one snap [15:42] 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] they are different apps [15:43] 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] Croepha: do you have any links so I can evaluate that? [15:44] via /snap/othersnap/current/... [15:44] not really, sorry [15:44] not a problem at all [15:45] i'm not even sure that is a supported use case, i just found that out by playing around [15:45] since I am new to snappy, im unsure where /snap/othersnap/current would come into play [15:45] its a path on the filesystem [15:45] oh.. i see what youre saying [15:45] yea im not a fan of that [15:46] ill get a total size of the packages and see [15:46] I can save alot of space in each service by cherry-picking files [15:46] if you do bundle them all as one snap, then it might be best to do a periodic release strategy [15:46] maybe that will eb enough [15:47] 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] like 2016.7 2016.8 ... 2016.12 for each month? [15:47] I do agree that should that be required, periodic would be best [15:48] you do have the benefit of differential updates too, so what is common between versions wont have to be downloaded again [15:50] differential between individual packages? [15:50] 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] ... program to finish compiling. [15:50] no, differential between versions of the same package [15:50] PR snapd#1547 opened: many: remove all traces of channel from the buying codepath [15:50] Croepha: right thats what i was asking. ok thats good to know [15:51] SamYaple: it might be worth checking if some kind of layers like support is in the issue tracker [15:52] I will [15:52] to be honest, im kind of glad there are no layers. layers add complication [15:53] i didnt really like them when i built them into kolla (the openstack in docker containers project) [15:53] 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] 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] that sucks Croepha [15:55] iliv, look as the snapcraft clean options ... [15:56] ha, I was just about to highlight you ogra and ask to chime in on this matter [15:56] iliv: also, you know about --try right? [15:56] you can clean different stages [15:56] PR snapd#1548 opened: many: add new `snap weld` command [15:56] PR snapd#1549 opened: docs: add payment methods documentation [15:56] Croepha, know but I'll look into it [15:57] ogra, right, I use clean --step build a lot [15:58] 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] SamYaple, that sounds correct [15:59] 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] 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] 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] iliv, well, just use --step stage ... [16:02] iliv: strange then. i have all packages in build-packages and yet there are libs in teh stage folder [16:03] i _want_ those libs there, but im wondering if that is snappy being clever, or be not understanding something [16:15] Hi [16:16] Sorry I have basic questions regarding snapcraft if possible? [16:17] SamYapleL I think Snappy tries to be clever, using ldd (or more?) to do things like that [16:17] SamYaple doesn't work well with dload though... [16:17]