[00:04] <Trevinho> thurston: mhmh, you need to get something more by using XGetErrorText
[00:18] <thurston> i'll check that out thanks
[00:18] <Trevinho> thurston: in case, you can still avoid the crash by using the trapping...
[00:19] <Trevinho> thurston: for example, something like https://code.launchpad.net/~3v1n0/bamf/trap-x-errors/+merge/192980
[00:21] <thurston> for the record,  i'm only getting this error when running from the snap installed on my system.   my own executable binary runs just dandy on just about every system i've tried it on
[06:23] <mup> PR snapd#1584 closed: asserts: introduce new parseHeaders <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1584>
[06:55] <mup> Bug #1583250 opened: upstream use of build-time defined DATADIR incompatible with snaps relocation <snap-desktop-issue> <Snapcraft:New> <Snappy:New> <snapcraft (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1583250>
[08:02] <mup> PR snapcraft#550 closed: Add python package dependencies to setup.py <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/550>
[08:07] <balloons> "There has been a problem while analyzing the snap, check the snap and try to push again."
[08:08] <balloons> Anyone have insights into why I may be seeing this error? The snap itself installs and runs fine
[08:24] <ogra_> balloons, when do you see that ?
[08:26] <mwhudson> is it possible to run an all-snap / ubuntu core image in lxd?
[08:26] <mup> PR snapcraft#579 closed: Add new plugin: rust <Created by mariogrip> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/579>
[08:27] <ogra_> think about the technology ....
[08:27] <balloons> ogra_, sorry. Trying to push my snap. snapcraft push *.snap
[08:27] <ogra_> mwhudson, the main bits of preparing the rootfs happen in the initrd ...
[08:27] <mwhudson> ogra_: heh fair enough
[08:28] <ogra_> mwhudson, kvm is fine though
[08:28] <mwhudson> then i guess i want something as easy to use as lxd but using kvm underneath
[08:28] <mwhudson> i hate qemu's command line with a burning passion
[08:28] <mwhudson> and i'm not massively keener on libvirt
[08:29] <mup> PR snapcraft#685 closed: Release changelog for 2.13.2 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/685>
[08:30] <ogra_> mwhudson, kvm -m 512 -redir :8022::22 /path/to/img
[08:30] <ogra_> let it boot ...
[08:30] <ogra_> then: ssh -p 8022 ubuntu@localhost
[08:31] <mwhudson> oh it's that easy?
[08:31] <ogra_> if you feel like, put -nographics in the cmdline
[08:31] <ogra_> yeah
[08:31] <ogra_> note that you need to define the -m option (no idea why there is no sane default)
[08:37] <mup> Bug #1606813 opened: create-user gives nonsensical error when passed invalid email address <Snappy:New> <https://launchpad.net/bugs/1606813>
[08:37] <mup> Bug #1606815 opened: create-user leaves new user's .ssh owned by root <Snappy:New> <https://launchpad.net/bugs/1606815>
[08:42] <imexil> Hi, I'm trying to find the repository with some example snap yaml files. I've heard popey talking about it on the podcast but I just can't remember the name of that github place.
[08:44] <sergiusens> balloons you will get an email from the store with the link to request a review
[08:48] <balloons> sergiusens, I don't have any mails
[08:54] <trijntje> imexil: snappy playpen probably
[08:55] <imexil> trijntje: yes that's it! Thanks.
[08:55] <trijntje> https://github.com/ubuntu-core/snapcraft/tree/master/demos
[08:55] <trijntje> https://github.com/ubuntu/snappy-playpen
[09:02] <mwhudson> ogra_: where has http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/ gone?
[09:02] <ogra_> mwhudson, deleted on "upper mgmt" request
[09:03] <mwhudson> ogra_: so i get to roll my own?
[09:03] <ogra_> mwhudson, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ still has the snaps
[09:03] <mwhudson> ah ok
[09:04] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/ should only have the resulting img files once ubuntu-image is ready
[09:04] <mwhudson> wait
[09:04] <mwhudson> how do i actually download the snap from this page?
[09:05] <ogra_> you click on "Successfully built" for the arch you want
[09:06] <mwhudson> the largest 'built file' for amd64 is 15kb
[09:06] <ogra_> oh, crap ... looks like they got deleted
[09:06] <ogra_> they were next to the manifest files
[09:07] <mwhudson> hooray
[09:07] <ogra_> https://code.launchpad.net/~ogra/+snap/os-snap-test has the latest builds but they are still haunted by bug 1605903
[09:07] <mup> Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903>
[09:08] <ogra_> you could grab them from there, unsquashfs them and make /home/ubuntu owned by UID 1000 ... then just call snapcraft snap squashfs-root to re-squash them
[09:10] <drizztbsd> hi, is mvo5 here?
[09:10] <ogra_> drizztbsd, he is at a sprint and probably busy in real-life, so i wouldnt expect him much around this week
[09:11] <mwhudson> ogra_: alternatively is there some way i can run live-build locally and have it install this one extra package as part of the build?
[09:11] <drizztbsd> ogra_: so maybe you can answer :P yesterday he tagged snapd 2.11, but last version was 2.0.11 and the new tag is not signed
[09:11] <drizztbsd> is it a new versioning scheme?
[09:12] <drizztbsd> wrt https://github.com/snapcore/snapd/releases/tag/2.11
[09:13] <mwhudson> uh this involves a private ppa, never mind!
[09:13] <ogra_> mwhudson, push your package to a PPA ... bzr branch lp:~ogra/+junk/os-snap-test ... then add your PPA to ENV in the Makefile ... and call snapcraft in the toplevel dir
[09:13] <ogra_> oh, your package is private ?
[09:14] <mwhudson> yeah
[09:15] <ogra_> well, then the good old ... unsquashfs ... mount /proc and /sys ... chroot and dpkg -i will help ... afterwards just "snapcraft snap squashfs-root" again
[09:15] <mwhudson> yeah
[09:19] <tempuser> hi
[09:20] <tempuser> can anyone lend me a hand with building a snap package? I'm growing wrestless as I don't have much experience with python language and I need to build a package for a python2
[09:22] <tempuser> I'm getting parts/cumulus/install/usr/bin/pip2': [Errno 2] No such file or directory
[09:23] <tempuser> is anyone seeing what I'm writing btw?
[09:23] <dholbach> yes
[09:23] <tempuser> ok, thanks
[09:23] <trijntje> tempuser: can you post your snapcraft.yaml file?
[09:23] <dholbach> did you try running "snapcraft clean" and then trying again?
[09:24] <tempuser> yup
[09:24] <dholbach> it's http://askubuntu.com/questions/801388/how-do-you-build-a-python-application-using-snapcraft
[09:24] <dholbach> right?
[09:24] <joc_> Does anyone know when the parts service will be updated to snapcraft 2.13.1 (which i see has been SRUed)? It also seems to have not run for a couple of hours.
[09:25] <tempuser_> sorry disconnected
[09:25] <dholbach> it's http://askubuntu.com/questions/801388/how-do-you-build-a-python-application-using-snapcraft
[09:25] <tempuser_> wireless randomly disconnects
[09:25] <dholbach> right?
[09:25] <tempuser_> yes
[09:25] <tempuser_> it is
[09:25] <dholbach> ok
[09:25] <dholbach> trijntje, ^
[09:26] <Son_Goku> morning all
[09:26] <tempuser_> I actually didnt done a clean after chaning the yaml, i'll do it now and come back
[09:26] <dholbach> cool
[09:28] <tempuser_> nope, same issue
[09:29] <tempuser_> in the directory indeed pip2 is missing I have pip / pip3 / pip3.5
[09:29] <dholbach> mh, that's weird
[09:30] <Spads> Is there a good way to make the autotools plugin cd into a subdir of the source archive before running?
[09:30] <trijntje> tempuser_: you might want to use pip directly, instead of git
[09:31] <trijntje> tempuser_: like this http://pastebin.com/V79SGYJX
[09:31] <trijntje> it will use pip to get the specified packages
[09:31] <Spads> I tried using source-subdir: to limit to a subdir, but that actually REMOVED all the essential stuff that was a parent of that
[09:32] <tempuser_> I see
[09:32] <tempuser_> ok I'll give it a shot :)
[09:32] <mup> PR snapcraft#660 closed: Fix python2 compile cache removal <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/660>
[09:33] <Spads> I just filed https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1606833 after looking at the plugin source and coming to the conclusion that there's nothing to do this
[09:33] <mup> Bug #1606833: Need to build from subdir of source without removing rest of repo <amd64> <apport-bug> <xenial> <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1606833>
[09:34] <ogra_> Spads, well, worst case you could use the make plugin and have a toplevel Makefile from where you call the autofoo commands and then cd into the right dir
[09:34] <ogra_> as a workaround
[09:34] <Spads> ogra_: how do I "have" that makefile?  It's an upstream source archive
[09:36] <ogra_> you have it next to your snapcraft.yaml
[09:36] <Spads> Hm, and I do something to copy it into the source thing?
[09:37] <ogra_> this is my build of the debian upstream git tree of approx: https://github.com/ogra1/packageproxy/blob/master/Makefile
[09:37] <Spads> hm
[09:37] <Spads> so I replace EVERYTHINg with this makefile?
[09:37] <ogra_> you could as well just run *any* command in such a makefile
[09:38] <Spads> like, why didn't you keep sources in the snapcraft.yaml?
[09:38] <Spads> ah, source .
[09:38] <ogra_> because then the local makefile is ignored
[09:38] <Spads> yikes
[09:39] <ogra_> but effectively you can always use a makefile like a script
[09:39] <Spads> okay thanks that's a good workaround
[09:39] <Spads> but I suspect that's not the way they'd want to do this in future ☺
[09:39] <ogra_> indeed, fixing your bug is the right thing long term
[09:39] <Spads> 💪🐸
[09:39] <ogra_> but til thats there you can use other ways to roll your snap ;)
[09:41] <Spads> yep thanks
[09:42] <ogra_> (the makefile thing is really nice if you need to apply extra patches and dont want to maintain a whole forked git tree btw ... )
[09:49] <Spads> yeah saw that
[09:49] <Spads> heh
[10:01] <mwhudson> ogra_: so i unsquashed your rootfs, ran enable.sh and then apt update did this:
[10:01] <mwhudson> 0% [1 InRelease gpgv 94.5 kB] [2 InRelease 43.1 kB/247 kB 17%]Couldn't create tempfiles for splitting up /var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_xenial-security_IErr:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
[10:01] <mwhudson>   Could not execute 'apt-key' to verify signature (is gnupg installed?)
[10:01] <ogra_> mwhudson, oh, did you copy a working resolv.conf in place ?
[10:02] <mwhudson> ogra_: yes
[10:02] <ogra_> hmm
[10:03] <mwhudson> not before something else broke, of course :-)
[10:08] <mwhudson> ogra_: strace from outside sez 20661 open("/tmp/apt.sig.VSyu5J", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
[10:08] <mwhudson> ogra_: which doesn't make masses of sense
[10:08] <ogra_> check the permissions of tmp
[10:08] <mup> PR snapd#1591 opened: spread.yml, .travis.yml: read store credentials from environment and pass them encrypted to travis <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1591>
[10:08] <ogra_> it does in the light of Bug #1605903
[10:08] <mup> Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903>
[10:09] <mwhudson> oh hehe
[10:09] <mwhudson> drwxr-xr-x 2 root root 4096 Jul 27 10:00 /tmp
[10:09] <ogra_> yeh :/
[10:09]  * mwhudson tries to remember what chmod flags he needs
[10:09] <ogra_> i hope i can get some help from the snapcrafters soon to get this fixed
[10:12] <mwhudson> yeah, that's an ugly one
[10:12] <ogra_> and probably easy to fix if you know the code (just skip ebverything but the copy) but i cant really find my way around the prime stage code
[10:23] <Spads> Ah!
[10:23] <Spads> Okay, it looks like I just had some noise in there
[10:23] <Spads> source-subdir: does indeed dow hat I want
[10:23] <ogra_> ha
[10:30] <Spads> are there any good examples of passing include/lib dirs from one part as args to another part?
[10:30] <Spads> I'm mostly thinking about how I refer to the directory
[10:30] <Spads> I mean I could do a lot of ../../../.. stuff, but...
[10:48] <mup> PR snapd#1457 closed:  snapstate: drop revisions after "current" on refresh <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1457>
[10:49]  * Spads links a snapcraft.yaml from his bug to illustrate
[10:54] <Odd_Bloke> I'm looking at snapping something which ships scripts containing underscores; snapcraft won't parse my snapcraft.yaml if I use them in application names.
[10:55] <Odd_Bloke> Is this expected behaviour, or should I file a bug?
[10:59] <mwhudson> so...
[10:59] <Chipaca> Odd_Bloke, "^[a-zA-Z0-9](?:-?[a-zA-Z0-9])*$"
[10:59] <Chipaca> Odd_Bloke, valid app names match that
[10:59] <mwhudson> i have this service that runs on first boot
[11:00] <Chipaca> Odd_Bloke, no underscores for you i'm afraid
[11:00] <mwhudson> and it's crashing and systemd restarts it before i can see the traceback
[11:00] <mwhudson> any way i can see the traceback?
[11:00] <Chipaca> mwhudson, journalctl -u $unit ?
[11:01] <mwhudson> Chipaca: how can i run that though?
[11:01] <Chipaca> mwhudson, what do you mean?
[11:01] <mwhudson> Chipaca: the service i am debugging is running on tty1
[11:02] <Chipaca> mwhudson, I'm missing something, probably something obvious, here
[11:02] <mwhudson> Chipaca: i'm probably explaining myself really badly
[11:02] <Chipaca> so many questions actually :-)
[11:02] <Chipaca> mwhudson, how are you running a service on tty1
[11:02] <Chipaca> ?
[11:02] <mwhudson> Chipaca: it's a systemd unit
[11:02] <Chipaca> mwhudson, or do you mean it's run before getty?
[11:03] <mwhudson> that disables getty in it's preexec
[11:03] <Chipaca> ahh
[11:03] <Chipaca> mwhudson, 1 sec
[11:03] <Chipaca> mwhudson, grub system?
[11:03] <mwhudson> i think so
[11:04] <Son_Goku> zyga, any luck iterating through the fedora-review report for snap-confine?
[11:04] <mwhudson> Chipaca: ah, i remembered finally how to switch to tty2
[11:05] <Chipaca> mwhudson, oh it only disabled getty on tty1?
[11:05] <mwhudson> yeah
[11:05] <Chipaca> oh
[11:05] <Chipaca> then yeah, alt+FN, or alt-left,right
[11:05] <mwhudson> unfortunately the output is not in journalctl
[11:06] <Chipaca> otherwise from grub add systemd.debug-shell to the boot commandline
[11:06] <Odd_Bloke> Chipaca: ;.;
[11:06] <Chipaca> Odd_Bloke, how important are the underscores?
[11:06] <Odd_Bloke> Not very.
[11:06] <mwhudson> ah haha i fail at regular expressions
[11:06] <Chipaca> mwhudson, ...?
[11:06] <mwhudson> Chipaca: i found a log file and my bug
[11:06] <Odd_Bloke> Just talked to sergiusens, so I understand the reasons behind it.
[11:07] <Chipaca> mwhudson, :-)
[11:07] <mwhudson> Chipaca: thanks for being a rubber duck :-)
[11:07] <Chipaca> mwhudson, http://i.imgur.com/eTic1wS.jpg
[11:07] <mwhudson> :-)
[11:07] <ogra_> queck !
[11:08] <zyga> Son_Goku: yes, some, also still sprinting and more meetings
[11:08] <zyga> Son_Goku: I will find a quiet spot to do that today
[11:09] <Son_Goku> cool
[11:25] <mwhudson> does snapcraft by any change have an option to compress less but snap faster?
[11:29] <mup> Bug #1606893 opened: snap find fails with an empty query error but the help suggests query is optional <Snappy:New> <https://launchpad.net/bugs/1606893>
[11:47] <mup> PR snapd#1592 opened: many: update code for the new snap_mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/1592>
[12:15] <qengho> mwhudson: No
[12:21] <mup> PR snapcraft#689 opened: kernel plugin: kernel targets depending on debarch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/689>
[12:28] <qengho> mwhudson: Also, we want reproducable snaps. So options are bad. A snapcraft.yaml with stable sources should, one day, produce the same snap file, bit for bit.
[13:12] <mup> PR snapcraft#690 opened: Preserve file ownership for 'os' snaps <Created by josepht> <https://github.com/snapcore/snapcraft/pull/690>
[13:26] <mup> PR snapd#1593 opened: asserts,many: start supporting structured headers using the new parseHeaders <Created by pedronis> <https://github.com/snapcore/snapd/pull/1593>
[13:42] <mup> Bug #1606932 opened: snapd tests fail on snapd 2.11 on Arch Linux <Snappy:New> <https://launchpad.net/bugs/1606932>
[13:44] <josepht> sergiusens: I created a bug for removing the namespacing of remote parts.  Please update with anything I missed.  https://bugs.launchpad.net/snapcraft/+bug/1606933
[13:44] <mup> Bug #1606933: parser - Make all parts top-level parts <Snapcraft:New for joetalbott> <https://launchpad.net/bugs/1606933>
[13:48] <kyrofa> stevebiscuit, you still around?
[13:48] <Spads> sergiusens: okay, so what do I do if the makefile builds, but has no install target? ☺
[13:49] <Spads> sergiusens: the make plugin runs make install after building 😆
[13:49] <kyrofa> Spads, do you know what needs to go into the snap?
[13:49] <Spads> kyrofa: yeah but unfortunately the build step bombs out
[13:50]  * Spads expects he'll have to make a custom make plugin 
[13:50] <Spads> that's two custom plugins in one snap!
[13:50] <kyrofa> Spads, of course. Snapcraft assumes the presence of the install rule since it has no other way of knowing what needs to go into the snap
[13:50] <Spads> sure
[13:50] <Spads> but maybe I want to make the build and then copy the install
[13:50] <kyrofa> Spads, so yes, you'll need to write a local plugin that just calls make and copies stuff instead
[13:50] <Spads> ¯\(°_o)/¯
[13:51] <kyrofa> Spads, if you know what needs to be installed, may I suggest proposing an install rule upstream as well?
[13:51] <Spads> yeah well upstream is pretty quiet
[13:51] <Spads> and clearly aren't following common practice on a lot of things
[13:51] <Spads> but I'm so close to finishing this I'm not bovvered
[13:51] <kyrofa> Yeah that makes things more difficult :( . But hopefully you can get by with local plugins!
[13:53] <Spads> kyrofa: I feel like "use this other thing for install" would have been a nice option on the make one tho
[13:54] <kyrofa> Spads, what "other thing." Another part?
[13:55] <kyrofa> Spads, note also: if upstream is quiet, another option may be to fork it, add install rules, and package that
[13:57] <Spads> heh
[13:57] <Spads> I kind of wish I had a step to append text to the Makefile
[13:57] <stevebiscuit> kyrofa: pong
[13:58] <kyrofa> Spads, but then we'd need to figure out some way to do that for cmake projects that don't have install rules, etc.
[13:58] <Spads> right
[13:58] <Spads> I wouldn't make it part of the build plugins
[13:58] <Spads> but like, being able to chuck diffs at this would be p.sweet
[13:59] <kyrofa> Spads, you mean like a patch step?
[13:59] <Spads> yeah
[13:59] <kyrofa> stevebiscuit, since go has a few different dependency management solutions, a more scalable approach is probably to make different plugins. I actually have a godeps one and will be proposing it first thing. I know you're EOD, but will you take a look tomorrow?
[14:00] <stevebiscuit> kyrofa: I can look at it today seeing as I'm back in the UK
[14:00] <kyrofa> stevebiscuit, that prevents the go plugin from having to grow support for everything
[14:00] <kyrofa> Oh!
[14:01] <kyrofa> Spads, you're not the first to request such a feature. I think it will probably happen, but needs some thoughtful design
[14:01] <Spads> yeah
[14:02] <kyrofa> stevebiscuit, okay, I'll ping you
[14:02] <stevebiscuit> kyrofa: sweet
[14:04] <ogra_> kyrofa, yo !
[14:05] <kyrofa> Hey ogra_!
[14:05] <kyrofa> Got home safely?
[14:05] <ogra_> kyrofa, could i drag your attention towards bug 1605903 ... ? it kind of blocks moving forward with os snap bulds atm ...
[14:05] <mup> Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903>
[14:05] <ogra_> kyrofa, yeah, you too i guess ?
[14:05] <ogra_> how is the jetlag ? :)
[14:06] <ogra_> i would cook up a patch, but the prime stage is really hard to understand by just reading the code
[14:06] <kyrofa> ogra_, sure, I'll take a look :)
[14:06] <ogra_> thanks !!
[14:07] <kyrofa> ogra_, well, it was really hard to get up for standup at 6am this morning, so I must be doing better!
[14:07] <ogra_> i guess it is effectively just needing an "if type = os then skip the world and just copy"
[14:07] <ogra_> hah, yeah
[14:07] <mhall119> sergiusens: when is snapcraft getting that new feature to add runtime env vars?
[14:07] <mhall119> also, are the automated tests broken? Things are failing on my pull request that I haven't touched
[14:09] <didrocks> hey kyrofa!
[14:09] <kyrofa> didrocks, hey man!
[14:09] <didrocks> seeing you are catching up on jetlag, good :)
[14:09] <kyrofa> mhall119, sergiusens is still sprinting this week
[14:10] <kyrofa> mhall119, I can take a look at the tests, though
[14:10] <mhall119> oh, is zyga also sprinting?
[14:10] <mhall119> thanks kyrofa
[14:10] <ogra_> yeah, everyone is sprinting apparently
[14:11]  * mhall119 is just sitting at home snapping stuff
[14:11] <ogra_> we should have a sprint to discuss all that sprinting !
[14:11] <kyrofa> mhall119, yup :P
[14:11] <mhall119> ogra_: isn't that what the manager sprints are?
[14:12] <ogra_> hah
[14:12] <timothy> a meta-sprint
[14:13] <timothy> One Sprint to rule them all.
[14:14] <mhall119> Like some kind of Ultmate Decisions Sprint?
[14:14] <mhall119> we could do one every 6 months
[14:15] <kyrofa> mhall119, the integration tests seem unable to find npm. Since npm is grabbed via the tar source, it may be caused by your change
[14:16] <mhall119> oh, hmmm....
[14:16] <kyrofa> mhall119, try running the shout demo
[14:16] <kyrofa> mhall119, does it work for you?
[14:16] <mhall119> kyrofa: what's the command to do that?
[14:16] <kyrofa> mhall119, just cd into demos/shout and run snapcraft
[14:17] <kyrofa> mhall119, I re-ran the test just to be sure
[14:17] <ogra_> mhall119, Ultmate Decisions Sprint? i like that ... but we should shorten that somehow UlDeS ? or some such ? :)
[14:17] <ogra_> hah, now we scared olli
[14:19] <mhall119> kyrofa: trying it in a cleanbuild now
[14:19] <mhall119> oh wait, that won't get the changes
[14:21] <ahoneybun> heyo
[14:21] <mhall119> ogra_: it fails on npm install -g shout, which I believe is after snapcraft has unpacked the tarball
[14:22] <mhall119> kyrofa: ^^ not ogra_
[14:22] <mhall119> also other pull requests are failing on the same test
[14:23] <ahoneybun> o/ mhall119
[14:24] <ahoneybun> errors: http://pastebin.ubuntu.com/21044760/
[14:24] <ahoneybun> yaml: http://pastebin.ubuntu.com/21044876/
[14:46] <mup> PR snapd#1594 opened: daemon: always mock release info in tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/1594>
[14:54] <sergiusens> mhall119 ogra_ cloud sprint
[14:54] <sergiusens> kyrofa hey! mind looking into the shebangs PR?
[14:54] <sergiusens> or are you going to pull the snap card on me? ;-)
[14:55] <ogra_> sergiusens, well, eventually it will rain ... then the clouds are gone and you can take vacation ;)
[14:55] <sergiusens> josepht will update that bug in a bit
[14:58] <sergiusens> mhall119 wrt environment, that just landed today in snap-confine... should be added to the next release
[14:58] <ogra_> did snap-confine even make it into the archive yet ?
[14:58] <ogra_> last time i checked it was sitting in proposed
[14:59] <ogra_> (i mean in general, not a specific version)
[14:59] <sergiusens> ogra_ yeah, right, there was a regression and mvo pushed another package, could be soon though (as soon as all the adt tests pass)
[14:59] <ogra_> cool
[15:00] <seb128> is there a vcs or something where one can look at the changes done to the ubuntu-core snap?
[15:01] <mup> Bug #1606961 opened: snapd tests: checking for nogroup breaks Fedora, Arch Linux and maybe other distributions <Snappy:New> <https://launchpad.net/bugs/1606961>
[15:01] <ogra_> seb128, not yet ...
[15:01] <seb128> hum, k :-/
[15:02] <seb128> is there anywhere to download the snap from different channels?
[15:02] <ogra_> seb128, i'm just completely re-working the build setup (switching from cdimage to snapcraft) ... there used to be people.canonical.com/~ogra/core-image/stats
[15:02] <timothy> sorry for my bunch of bugreports
[15:02] <seb128> I don't even know if the snap is different between channels
[15:02] <ogra_> seb128, i plan to have something similar again after the switch
[15:02] <seb128> ok
[15:02] <ogra_> it isnt different
[15:02] <ogra_> it will be though
[15:03] <seb128> ogra_, so being more specific, do you know if the SafeLauncher/xdg-open wrapper ever landed?
[15:03] <seb128> mvo did https://github.com/snapcore/snapd/pull/1167
[15:03] <mup> PR snapd#1167: interfaces: add  com.canonical.UrlLauncher.XdgOpen to unity7 interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1167>
[15:03] <ogra_> thats pretty old, it should
[15:03] <seb128> well I can't find it
[15:03] <seb128> the only reference in ubuntu-core (according to grep) is in the unity7 interface
[15:04] <seb128> at the time it landed mvo said it was in the beta(?) channel
[15:04] <ogra_> sigh, i wish copy/paste would work in unity8
[15:04] <ogra_> (in hexchat)
[15:04] <seb128> I guess I would need mvo...
[15:04] <seb128> where is he hidding? ;-)
[15:05] <ogra_> https://wiki.ubuntu.com/QATeam/OSSnapPromotionPipeline
[15:05] <ogra_> thats how the snaps and channels are supposed to work together in the future
[15:05] <seb128> k
[15:05] <seb128> in any case I guess I need mvo
[15:05] <seb128> I don't know if I'm looking at the wrong channel/version
[15:05] <seb128> or if the thing is named differently
[15:05] <seb128> or if never landed
[15:06] <seb128> +it
[15:06] <ogra_> the ubuntu-core snap is currently the same in all channels
[15:06] <seb128> k
[15:06] <ogra_> so there is nothign to look at
[15:06] <seb128> well either it's missing
[15:06] <mup> PR snapd#1595 opened: many: make seed.yaml on firstboot mandatory and include sideInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/1595>
[15:06] <seb128> or it's named differently that what I'm looking for
[15:06] <ogra_> if it isnt in the current one then it isnt in
[15:07] <seb128> well maybe it is
[15:07] <ogra_> i suspect mvo is locked into some room for sprint discussions
[15:07] <seb128> but I don't know how the tool is supposed to be named
[15:07] <ogra_> i wouldnt count on seeing him much in here this week
[15:07] <seb128> or in what location it's supposed to be stored
[15:07] <seb128> who would know about that who isn't locked down in a dungeon? ;-)
[15:07] <ogra_> probably Chipaca
[15:08] <Chipaca> *always* chipaca
[15:08] <Chipaca> what?
[15:08] <seb128> Chipaca, ^ do you have any idea about that?
[15:08] <Chipaca> seb128: from where on? that's a lot of backlog :-)
[15:08] <seb128> Chipaca, do you know if the script/code corresponding to https://github.com/snapcore/snapd/pull/1167 landed somewhere and where
[15:08] <mup> PR snapd#1167: interfaces: add  com.canonical.UrlLauncher.XdgOpen to unity7 interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1167>
[15:08] <ogra_> Chipaca, did https://github.com/snapcore/snapd/pull/1167 land yet
[15:08] <seb128> yes
[15:08] <seb128> that landed
[15:08] <seb128> but it's only the interface permission
[15:08] <seb128> we need an actual xdg-open script or something which does that call
[15:09] <ogra_> ah
[15:09] <Chipaca> I think the xdg-open thing is in the ppa
[15:09] <ogra_> i guess that would be in snap-confine though
[15:09] <seb128> ppa?
[15:09] <seb128> ah
[15:09] <Chipaca> and in /usr/local in the image
[15:09] <seb128> I looked in ubuntu-core
[15:09] <ogra_> which should be in poroposed
[15:09] <ogra_> Chipaca, dude ! /usr/local ?
[15:10] <Chipaca> I think so?
[15:11] <seb128> doesn't seem to be in snap-confine
[15:11] <seb128> nor ubuntu-core snap
[15:11] <seb128> not in /usr/local/bin either in a mounted snap
[15:11] <didrocks> yeah, see the message on the ML
[15:11] <seb128> or rather an installed snap starting a bash
[15:11] <seb128> didrocks, "the"? which one?
[15:12] <didrocks> someone had that issue yesterday
[15:12] <ogra_> the right one indeed :)
[15:12] <didrocks> and I asked for the status, I don't find it in ubuntu-core
[15:12] <didrocks> (ccing mvo)
[15:12] <Chipaca> yeah, mvo will know more. sorry :-(
[15:12] <didrocks> I think last time he told me that it's in an ubuntu-core snap which isn't released
[15:13] <seb128> didrocks, right, I saw your message, but seems like your status is the same as mine
[15:13] <seb128> which is why I was trying to get info here ;-)
[15:13] <seb128> looks like we need to wait for mvo
[15:13] <ogra_> check https://lanuchapd.net/~ogra/+snap/os-test-snap/+build/1889
[15:13] <ogra_> if you find it in there
[15:14] <seb128> lanuchapd
[15:14] <ogra_> (thats todays build)
[15:14] <ogra_> heh, sorry
[15:14] <mhall119> sergiusens: will you have a chance this week to look at the test failures in the snapcraft pull requests?
[15:14] <ogra_> i'm in a unity8 session with a liberting hexchat ... cant copy/paste
[15:14] <mhall119> https://github.com/snapcore/snapcraft/pull/688 is currently blocking easy builds of the Arduino IDE
[15:14] <mup> PR snapcraft#688: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>
[15:16] <tedg> jdstrand: Looking at your dbus name branch, don't want to bike shed there, but we probably need a "user" field vs. system and session. Not sure if it should replace session or not. But since we're moving to a user bus should probably be in snapd.
[15:19] <seb128> didrocks, ogra_, right, https://launchpadlibrarian.net/275283297/buildlog_snap_ubuntu_xenial_i386_os-snap-test_BUILDING.txt.gz has "usr/local/bin/xdg-open"
[15:19] <mup> Bug #1592901 changed: gvfs confinement issues <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1592901>
[15:20] <ogra_> seb128, my prob now is that i cant upload the snap you are looking at until bug 1605903 is fixed or worked around :/
[15:20] <seb128> ogra_, that's a new ubuntu-core? how come the content is different from the current one?
[15:21] <mup> PR snapd#1596 opened: osutil: support both "nobody" and "nogroup" for grpnam tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/1596>
[15:21] <ogra_> seb128, check the version of the currently published one (there is a date stamp in it)
[15:22] <ogra_> it is simply outdated
[15:22] <ogra_> and i had to shut down cdimage builds for $reasons
[15:22] <seb128> ogra_, what's the master? like where was that xdg-open thing added?
[15:22] <mup> Bug #1593957 changed: VLC snap Segmentation fault <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1593957>
[15:22] <mup> Bug #1594318 changed: pulseaudio interface is missing permissions <snapd-interface> <Snapcraft:Invalid> <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1594318>
[15:22] <ogra_> i dont know where mvo added it
[15:23] <ogra_> me goes to a machine where he can actually copy/paste ... sigh
[15:23] <seb128> well what sources/vcs is the builder pulling from?
[15:24] <ogra_> seb128, https://wiki.ubuntu.com/QATeam/OSSnapPromotion
[15:24] <ogra_> se dont have a seed for core
[15:24] <ogra_> *we
[15:24] <mup> PR snapd#1583 closed: snap: remove meta/kernel.yaml again <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1583>
[15:24] <mup> PR snapd#1593 closed: asserts,many: start supporting structured headers using the new parseHeaders <Created by pedronis> <https://github.com/snapcore/snapd/pull/1593>
[15:24] <ogra_> there is a list of packages set inside livecd-rootfs' config
[15:25] <ogra_> (which usually doesnt change and i didnt see an upload from mvo)
[15:25]  * zyga runs off to have more meetings
[15:25] <ogra_> my assumption is that he added it to one of the PPA packages
[15:25] <kyrofa> sergiusens, yep, I've got it
[15:25] <seb128> ah
[15:25] <seb128> https://launchpad.net/ubuntu/+source/livecd-rootfs/2.411
[15:25] <seb128> ogra_, ^
[15:25] <seb128>   * system-image: add /usr/local/bin/xdg-open dbus helper
[15:26] <ogra_> thats yakkety
[15:26] <ogra_> for which we dont build anything
[15:26] <ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
[15:26] <ogra_> thats the livecd-rootfs used for xenial builds
[15:26] <ogra_> but i guess that code is in there
[15:27] <ogra_> (we usually forward port from the PPA into yakkety, not the other way round)
[15:27] <seb128> the wrapper is in there
[15:27] <ogra_> yeah, it is in there ... since may 26
[15:27] <seb128> so yeah
[15:27] <seb128> weird
[15:28] <seb128> the ubuntu-core version is from may 31
[15:28] <ogra_> and the last core snap was released on july 14
[15:28] <mup> Bug #1579790 changed: Please support content-sharing interface <snapd-interface> <Snappy:Fix Released by mvo> <https://launchpad.net/bugs/1579790>
[15:28] <mup> Bug #1597259 changed: Access to /lib/ denied <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1597259>
[15:28] <seb128> hum
[15:28] <seb128> so why is that script missing?
[15:29] <ogra_> ogra@anubis:~/tmp$ ls squashfs-root/usr/local/bin/
[15:29] <ogra_> apt  apt-cache  apt-get  no-apt  xdg-open
[15:29] <ogra_> it isnt
[15:30] <ogra_> i just pulled the edge snap
[15:30] <ogra_> oh, sorry, i pulled i386
[15:30]  * ogra_ checks amd64 instead
[15:30] <seb128> well I'm on i386 :p
[15:30] <ogra_> heh, well, it shoudl eb in there
[15:30] <seb128> $ ls /usr/local/bin/
[15:30] <seb128> apt  apt-cache	apt-get  no-apt
[15:31] <seb128> that's in a .bash cmd from a snap using current xenial
[15:31] <ogra_> whats the revision that snap list shows ?
[15:31] <seb128> ubuntu-core     16.04+20160531.11-55  123  canonical  -
[15:31] <ogra_> uuuh
[15:32] <ogra_> thats from may
[15:32] <seb128> yeah
[15:32] <mup> PR snapd#1587 closed: store: deal with 404 froms the SSO store properly <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1587>
[15:33] <seb128> there goes the promise of regular updates in snappy world :p
[15:33] <ogra_> seb128, i rememkber mvo saying something about the re-exec logic that would break if we used newe core snaps in stable ...
[15:33] <timothy> Chipaca: with your 2 pull requests, snapd 2.11 tests finished successfully on archlinux
[15:33] <ogra_> seb128, nah, we are just not there yet
[15:34] <seb128> ogra_, so there are different core versions in different channels?
[15:34] <ogra_> seb128, right
[15:34] <seb128> I though you said ubuntu-core was the same in all channels earlier
[15:34] <ogra_> i thought it was
[15:34] <ogra_> i didnt know we stopped promotion
[15:34] <seb128> k, makes sense now
[15:34] <mup> Bug #1570432 changed: Desktop example scummvm is broken <snapd-interface> <snappy-examples> <Snappy:Fix Released> <https://launchpad.net/bugs/1570432>
[15:34] <mup> Bug #1584178 changed: OpenGL interface doesn't work <opengl> <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1584178>
[15:34] <seb128> can I install ubuntu-core from another channel for testing on my xenial?
[15:34] <ogra_> as i said though ... there will be a new system soon https://wiki.ubuntu.com/QATeam/OSSnapPromotion ...
[15:35] <seb128> or is that going to make things grumpy?
[15:35] <ogra_> you could try
[15:35] <seb128> but...
[15:35] <ogra_> snap install ubuntu-core --edge ?
[15:35] <ogra_> dunno if snapd is clever enough
[15:35] <seb128> error: cannot install "ubuntu-core": snap "ubuntu-core" already installed
[15:36] <seb128> can't remove it either
[15:36] <ogra_> Chipaca, is there a way to force it ^^^ ?
[15:36] <seb128> refresh --edge seems to work
[15:36] <timothy> sudo snap refresh ubuntu-core --edge ?
[15:36] <seb128> let's see
[15:36] <seb128> timothy, thanks, just tried that as well ;-)
[15:36] <ogra_> yay
[15:37] <ogra_> yup, that gets me 138 here
[15:37] <ogra_> i386 should get 139
[15:39] <mhall119> hey, so I was using 'snap try ./prime' on a local snap build, and then I ran 'snapcraft clean' before 'snap remove', and now snapd doesn't know what to do, how do I fix this?
[15:39] <mhall119> zyga: ^^ ?
[15:40] <mhall119> kyrofa: ^^ ?
[15:41] <kyrofa> mhall119, now you've got snapd whining about mounted snaps?
[15:41] <kyrofa> mhall119, first of all, that's supposed to be fixed. Maybe it hasn't been released yet, but are you sure you're up-to-date?
[15:41] <mhall119> mounted snaps that aren't there anymore
[15:41] <mhall119> update-manager just ran 30 minutes ago
[15:42] <kyrofa> mhall119, ah, must not have been released yet, then
[15:42] <kyrofa> mhall119, try unmounting the tried snap from /snap. Does that change anything?
[15:42] <mhall119> is there a --force or something that I can use to make snapd remove it all
[15:43] <mhall119> nope
[15:43] <kyrofa> mhall119, eh... I'm not sure how snapd tracks that stuff. I know there's a way to recover from this, but I'm not sure what it is. Worst case, reboot
[15:44] <mhall119> kyrofa: http://paste.ubuntu.com/21152275/
[15:44] <seb128> ogra_, didrocks, so with "snap refresh ubuntu-core --edge" xdg-open works from inside the snap and correctly open the given url to my open firefox ;-)
[15:44] <seb128> GNOME apps don't work though
[15:44] <ogra_> yay
[15:44] <seb128> but I guess it's because mimetype handlers are not set
[15:45] <seb128> so a bit more work needed there
[15:45] <kyrofa> mhall119, ah, but after unmounting, does it still show up in snap list and make it generally unusable?
[15:45] <mhall119> kyrofa: it wasn't in snap list even before I unmounted
[15:46] <mhall119> as soon as ./prime was gone, it didn't show in snap list
[15:46] <kyrofa> mhall119, ah very good. Well, is it still complaining about the mounted snap?
[15:46] <mhall119> yup, can't snap remove or snap try
[15:46] <mhall119> for that particular snap
[15:46] <kyrofa> Not being able to snap remove makes sense since it's not there, can you pastebin what it says when you attempt the snap try?
[15:47] <kyrofa> mhall119, did you also unmount revision x1, by the way?
[15:47] <mhall119> no, just x2
[15:48] <kyrofa> mhall119, try unmounting x1 as well
[15:48] <mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/snaps/git-playpen/logic$ snap try ./prime
[15:48] <mhall119> error: cannot perform the following tasks:
[15:48] <mhall119> - Mount snap "logic" (cannot find installed snap "logic" at revision x2)
[15:48] <kyrofa> (I'm assuming that was also snap tried)
[15:49] <kyrofa> mhall119, yeah... you've reached the extent of my snapd plumbing capabilities. I'm left with the reboot suggestion. I'm sure niemeyer, mvo, or zyga could help you, but I doubt any of them are available at the moment
[15:49] <mhall119> thanks anyway kyrofa
[15:50] <kyrofa> mhall119, sorry :(
[15:50] <mhall119> not your fault, I should be more careful what I clean up
[15:50] <kyrofa> mhall119, hardly, snapd needs to clean that up
[15:50] <mhall119> (also snapcraft/snapd should prevent this, but that sounds like a fix in progress)
[15:50] <kyrofa> mhall119, and it will! Just... not yet I guess :P
[15:51] <mhall119> we really should make these desktop launchers leaner
[15:51] <mhall119> (tangent)
[15:52] <kyrofa> mhall119, more finely grained?
[15:53] <kyrofa> mhall119, how would you distinguish between then?
[15:53] <mhall119> not sure, all I know is that they're bigger than the app I'm snapping, and that doesn't make sense
[15:54] <mhall119> the gtk2 launcher, for example, pulls in like 40MB of just icons
[15:54]  * ogra_ hugs mhall119 
[15:54] <didrocks> seb128: sweet! :)
[15:54] <ogra_> now tell didrocks
[15:54] <ogra_> :)
[15:55] <didrocks> mhall119: well, content sharing man! you do want theming in your app, right?
[15:55] <didrocks> seems like ogra_ isn't interested into well integrating apps
[15:55] <ogra_> lol
[15:55] <didrocks> mhall119: the launcher has the minimum (and even too minimum if you listen to vlc) set of deps
[15:55] <mhall119> didrocks: theming yes, all the icons, not necessarily
[15:55] <mhall119> actually, maybe not even always theming
[15:56] <didrocks> like vlc doesn't integrate well on mate, or gnome shell or kubuntu
[15:56] <didrocks> mhall119: this is the package dependencies, they are certainly there for a reason
[15:56] <mhall119> didrocks: maybe there should be separate "launcher" and "integration" parts?
[15:56] <didrocks> mhall119: they can be overriden through snapcraft
[15:56] <didrocks> so if you don't like the list of stage-packages, you can override them
[15:56] <didrocks> and have your own set
[15:56] <seb128> +1 on having working defaults
[15:57] <didrocks> but in that case, you will lose the benefit of having theming and icons integrated with default themes
[15:57] <seb128> those who want to optimize then can do it
[15:57] <didrocks> right
[15:57] <didrocks> like ogra who don't want to contribute to the common set and keep ranting on the launcher :p
[15:57] <ogra_> HAHAHAHA
[15:57] <ogra_> i'm so evil
[15:57] <didrocks> seriously, this is getting tiring
[15:58] <ogra_> well, i'm not alone it seems
[15:58] <didrocks> and why don't you just override the stage-packages then?
[15:58] <didrocks> at some point, you will then get complains that your apps don't work/integrate well with X
[15:58] <didrocks> and readd those deps :p
[15:58] <didrocks> but you are free to do so
[15:58] <ogra_> i dont need to atm ... my snaps all work fine, as soon as i snap a new desktop app i'll try that
[15:59] <didrocks> nice then, not even sure you keep jumping on any occasion there then or what it does contribute to the discussion
[15:59] <ahoneybun> did anyone look at those pastebins?
[16:00] <ogra_> didrocks, well, like mhall119 i dont understand why we cant split these bits a bit finer grained
[16:00] <didrocks> what is finer grained?
[16:00] <didrocks> like "I don't want to have themes under Unity, or Mate or… ?)
[16:00] <seb128> it's going to be as complex then than opting out from the stage-package you don't want today
[16:00] <didrocks> or I don't want to have gsettings?
[16:00] <ahoneybun> theme packs?
[16:00] <ogra_> i might not want fonts in java apps which hardcode and ship their own ... so fonts might make sense to have in a separate part that the launcher can pull in ... same goes for themes or icons
[16:01] <didrocks> ahoneybun: that's once we have content sharing working with our runtime snaps
[16:01] <seb128> ogra_, keep in mind that those wrapper are not meant to be a proper solution
[16:01] <didrocks> ogra_: sounds like you want debian packages granularity
[16:01] <seb128> they just bridge a gap until we get content sharing and proper snaps
[16:01] <didrocks> yeah, if only we had the interfaces upstream, this wouldn't be needed
[16:01] <ahoneybun> mm I was working on Franz and I was getting some gtk-message errors
[16:01] <ogra_> didrocks, i want just some granulatrity
[16:02] <ogra_> not necessarily on a debian level
[16:02] <ahoneybun> yet I added desktop/gtk3 and gtk2
[16:02] <seb128> ahoneybun, what error do you get?
[16:02] <didrocks> ahoneybun: that's maybe other errors?
[16:02] <mhall119> didrocks: how do I strip files out that are being pulled in from desktop/gtk?
[16:02] <didrocks> ogra_: it's on github, feel free to contribute there :)
[16:02] <ahoneybun> http://pastebin.ubuntu.com/21044760/
[16:02] <ahoneybun> errors
[16:02] <ahoneybun> http://pastebin.ubuntu.com/21044876/ : yaml
[16:02] <didrocks> mhall119: same, on your part, just use snap: [-path]
[16:03] <mhall119> didrocks: so partA can remove files that are installed from partB?
[16:03] <ogra_> mhall119, other way around
[16:03] <didrocks> mhall119: no, you override partA
[16:03] <ogra_> but since you define the launcher most likely via "after:" thats fine
[16:03] <mup> PR snapd#1588 closed: tests: added spread find private test <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1588>
[16:03] <didrocks> mhall119: http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
[16:04] <didrocks> ogra_: wrong
[16:04] <ogra_> ?
[16:04] <didrocks> mhall119: look at "composing"
[16:04] <didrocks> ogra_: one part can only remove files from their own parts
[16:04] <seb128> ahoneybun, the warnings about the modules not loading can be ignored
[16:04] <didrocks> it's not a common set
[16:04] <seb128> unsure what the real error is though
[16:05] <ogra_> didrocks, hmm, how would mhall119 then remove his icons ?
[16:05] <didrocks> ogra_: see the link above
[16:05] <didrocks> and the "composing" dir
[16:05] <didrocks> as I told you multiple times, you can override piece of cloud parts
[16:05] <ahoneybun> seb128: https://github.com/imprecision/franz-app/releases
[16:05] <didrocks> you can even remove the stage-packages you don't want to by redefining it
[16:06] <didrocks> that way you can remove packages
[16:06] <mhall119> didrocks: so in my "upstream" part, which has after: [desktop/gtk2], I can use the snap: -/usr/share/icons/ to remove them?
[16:06] <ahoneybun> it has electron or something based
[16:06] <didrocks> until people yells it's brorken :)
[16:06] <didrocks> mhall119: not that
[16:06] <didrocks> you use after: [desktop/gtk2]
[16:06] <didrocks> than, you add another part:
[16:06] <ogra_> mhall119, no, it is more complex
[16:06] <didrocks> desktop/gtk2:
[16:06] <didrocks> which has snap: [-/usr/share/icons]
[16:06] <didrocks> for instance
[16:07] <didrocks> it will override the cloud part as if this one would ship those
[16:07] <mhall119> hang on, if my snapcraft.yaml has a desktop/gtk2 part, then it's not using the one from the part store, right?
[16:07] <didrocks> apparently, it's smart enough to merge both
[16:07] <mhall119> or does snapcraft have fancy part inheritance if the name is the same/
[16:07] <ogra_> you still use after:
[16:07] <didrocks> as per the blog post I listed above
[16:07] <ogra_> so it first pulls the desktop remote part
[16:07] <ogra_> then applies your local change
[16:07] <mhall119> didrocks: the block post you listed doesn't use parts from the part store
[16:08] <mhall119> it uses only local parts entirely defined in the snapcraft.yaml
[16:08] <ogra_> mhall119, the example overrides the source: line
[16:08] <ogra_> you just need to adapt the concept
[16:08] <didrocks> mhall119: http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/?
[16:08] <didrocks> it does
[16:08] <mhall119> right, this use canse needs to be better documented then, because currently I don't  know to do what didrocks is telling me to do, and will have to experiment
[16:08] <didrocks> "curl" is a cloud part
[16:09] <mhall119> oh, I see
[16:10] <mhall119> so as long as (A) the part name matches and (B) I don't specify a plugin, it will inherit from the cloud part
[16:11] <didrocks> right!
[16:11] <ogra_> exactly
[16:11] <mhall119> ok, I get it now
[16:15] <mhall119> next topic
[16:16] <mhall119> whenver I install an x2 snap that uses the desktop launcher, I get this:
[16:16] <mhall119> ln: failed to create symbolic link '/home/mhall/snap/saleae/x2/.themes/themes': Read-only file system
[16:16] <mhall119> doesn't happen on x1
[16:18] <didrocks> oh, that might me a bug!
[16:18] <didrocks> I think I know what's happening
[16:18] <didrocks> mind filing it?
[16:18] <ogra_> its not the first time i see it mentioned ...i bet we try to link before mkdir
[16:18] <didrocks> no
[16:19] <didrocks> the issues is the we try to symlink naming the dest dir
[16:19] <mhall119> didrocks: against what?
[16:19] <ogra_> oh
[16:19] <didrocks> so second time, as the data are copied over, we try to nest into the symlink
[16:19] <ogra_> yeah
[16:19] <didrocks> which is a symlink to some $SNAP/something
[16:19] <didrocks> ro
[16:19] <ogra_> right
[16:19] <didrocks> mhall119: the desktop-launcher github project (you already filed something against it, IIRC)
[16:20] <didrocks> ogra_: others paths are versionned,so it's not an issue, but this one is…
[16:20] <ogra_> didrocks, indeed
[16:20] <mup> PR snapd#1591 closed: spread.yml, .travis.yml: pass store credentials encrypted to travis and read them from environment <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/1591>
[16:20] <ogra_> seb128, how did you actually test that links work ? i cant get them to open from the telegram snap or my gitter snap
[16:21] <mhall119> didrocks: https://github.com/ubuntu/snapcraft-desktop-helpers/issues/4
[16:21] <seb128> ogra_, started a .bash cmd to be in a snap env and xdg-open http://www.ubuntu.com
[16:21] <ogra_> heh, ok
[16:21] <seb128> ogra_, as said earlier the gnome app lacks some mimetype handler definition to work
[16:22] <seb128> I'm going to look at that
[16:22] <ogra_> so it only works if the app is actually xdg aware
[16:23] <ogra_> which probably rules out such web apps ...
[16:23] <didrocks> mhall119: thanks! I'll tackle this tomorrow :)
[16:31] <timothy> - Download snap "hello" (20) from channel "stable" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/mVyGrEwiqSi5PugCwyH7WgpoQLemtTd6_20.snap)
[16:35] <seb128> hum
[16:35] <seb128> so I upgraded ubuntu-core to the edge channel version
[16:35] <seb128> using refresh --edge
[16:35] <seb128> do you have any idea how to revert to the stable one?
[16:36] <seb128> refresh --stable tels me that rev 123 is already installed
[16:36] <seb128> can't remove it
[16:36] <didrocks> and there is no more set command to force a rev
[16:36] <didrocks> hum… ogra_ ^
[16:37] <kyrofa> flexiondotorg, you around?
[16:37] <seb128> he's going to bounce to Chipaca I'm sure ;-)
[16:42] <ogra_> seb128, just snap revert ubuntu-core
[16:43] <ogra_> (at least this *should* work)
[16:44] <popey> I have a snap which plays no audio, it prints an alsa error on launch (http://paste.ubuntu.com/21159662/) - any ideas? I have the pulseaudio plug (and devmode anyway).
[16:45] <popey> it's an electron app fwiw
[16:45] <ogra_> seb128, though there was a reson why mvo held back promotion if the new core snap ...
[16:46] <ogra_> perhaps rollback will break
[16:46]  * ogra_ goes afk for a bit
[16:58] <Chipaca> sergiusens, you around?
[16:59] <kyrofa> stevebiscuit, https://github.com/kyrofa/snapcraft/tree/feature/1595981/godeps
[17:00] <kyrofa> stevebiscuit, it's still a little rough, but I gave it a quick test on snapweb and it seems to work
[17:05] <Chipaca> sergiusens, nm, figured it out
[17:07] <Chipaca> jdstrand, wrt your email about "namespace between commands"
[17:08] <Chipaca> jdstrand, isn't the error the person is seeing due to them trying to call one wrapped command from another?
[17:08] <Chipaca> jdstrand, that is, they're trying to call /snaps/bin/foo from inside /snaps/bin/bar
[17:08] <Chipaca> jdstrand, AIUI that didn't work (yet)
[17:08] <Chipaca> jdstrand, but it would work if they did called the binary directly (e.g. $SNAP/bin/bar.forrealz)
[17:14] <jdstrand> Chipaca: oh, if that is the issue then you are correct. Maybe I missed something. /me re-reads
[17:14] <stevebiscuit> kyrofa: could GodepsPlugin inherit from GoPlugin? Also, I think the `go get -t -d ./...` bit could be skipped? It would force *all* imported dependencies to be specified in the godeps-file
[17:15] <stevebiscuit> kyrofa: in the docstring the "This plugin uses the common plugin keywords" bit is repeated
[17:15] <kyrofa> stevebiscuit, yeah, docs are broken right now
[17:16] <kyrofa> stevebiscuit, regarding inheritance, yes, but the go plugin has functionality that godeps won't use, so it would just override everything
[17:17] <stevebiscuit> kyrofa: inheriting would be pointless then, np
[17:17] <kyrofa> stevebiscuit, so when one uses godeps, one never uses go get?
[17:18] <kyrofa> stevebiscuit, rather, you're saying they _shouldn't_ ?
[17:19] <kyrofa> Easy change
[17:20] <stevebiscuit> kyrofa: snapd and snapweb both use godeps and we never do a `go get` for the dependencies
[17:20] <kyrofa> stevebiscuit, good deal
[17:21] <popey> wat... anyone seen this before:- 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128)
[17:22] <popey> when running "snapcraft cleanbuild"
[17:27] <timothy> popey: fix your locale
[17:27] <popey> uhm
[17:27] <timothy> do you have an UTF-8 locale?
[17:28] <popey> yup
[17:28] <timothy> uhm so it's strange
[17:28] <timothy> it seems that python doesn't like your locale
[17:28] <popey> this is inside an lxc container
[17:28] <popey> so maybe not my host locale
[17:28] <popey> but I haven't changed anything and this used to work
[17:28] <timothy> ok, so it's the same problem I fixed on snapd tests
[17:29] <popey> oh?
[17:31] <timothy> if you read a string that includes an utf-8 character without a working utf-8 locale python doesn't like it
[17:31] <jdstrand> Chipaca: ok, responded. still not sure if that was what he was asking, but I addressed that just in case
[17:32] <popey> i see no strange characters in my yaml
[17:33] <popey> this only affects one snap
[17:33] <popey> other snaps build fine.
[17:33] <timothy> cat -A of your yaml file?
[17:33] <timothy> maybe some strange character
[17:33]  * popey learned a new thing today!
[17:34] <timothy> https://github.com/snapcore/snapd/pull/1468/commits/b66d3ea328ee42d3d4f56ed9736c315833dee67d this is how I fixed that in tests
[17:34] <mup> PR snapd#1468: Fix ./run-checks --static <Created by drizzt> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1468>
[17:34] <Chipaca> jdstrand, thanks! normally i would've butted in myself, but gmail is acting up on over here
[17:34] <timothy> by force reading of file with utf-8
[17:35] <popey> timothy: http://paste.ubuntu.com/21165798/ look okay to you?
[17:35] <popey> (that's the output of cat -A snapcraft.yaml)
[17:35] <jdstrand> Chipaca: np at all :)
[17:36] <Chipaca> popey, is the - between [ and usr from cat, or from the yaml? in stage: and snap: at the bottom
[17:37] <timothy> the character it doesn't like is an http://www.fileformat.info/info/unicode/char/29f8/index.htm
[17:37] <timothy> but I can't see that in your pastebin
[17:37] <Chipaca> haha
[17:37] <Chipaca> ha
[17:37] <popey> timothy: indeed, which is what's odd
[17:37] <Chipaca> oh man
[17:37] <popey> Chipaca: yeah, the - is in the yaml
[17:37] <Chipaca> that BIG SOLIDUS is my fault :-D
[17:37] <Chipaca> but yes, it is the locale
[17:38] <popey> oh?
[17:38] <Chipaca> snapcraft transforms parts that have / in them (sub-parts?) to have BIG SOLIDUS so it can mkdir it
[17:38] <Chipaca> or something like that :-)
[17:38] <timothy> Chipaca: maybe you should use codecs and open the file in utf-8
[17:38] <Chipaca> oh, i didn't write the code
[17:38] <timothy> to avoid locale madness
[17:38] <Chipaca> i'm just the idea man
[17:38] <timothy> oh ok
[17:38] <timothy> I don't have ubuntu here, so :P
[17:39] <popey> so the fix is? (given this is lxc, building on host is fine)
[17:39] <timothy> popey: configure locale in lxc
[17:39] <Chipaca> popey, can you install locales inside the lxc?
[17:39] <popey> ah
[17:39] <popey> i can add it to build packages?
[17:39] <Chipaca> ah, perhaps
[17:40] <Chipaca> not sure if that'll be early enough, but try
[17:40]  * popey tries that
[17:40] <popey> snapcraft-painfully-epigrammatic-jonathon
[17:40] <popey> lxc names always amuse
[17:40] <timothy> you need to uncomment the correct locale in /etc/locale.gen, launch locale-gen command and set LANG=you_locale
[17:41] <popey> inside my lxc?
[17:41] <popey> It's a pre-built container
[17:41] <timothy> yep
[17:41] <popey> I dont see how (or that) I'd want/like to do that
[17:41] <timothy> it's scriptable
[17:41] <popey> this seems needlessly odd
[17:41] <popey> it should "just work"
[17:41] <popey> I shouldn't be messing with the config of packages inside the container
[17:41] <timothy> so someone should fix the code to use codecs
[17:41] <popey> that's madness
[17:41] <popey> ok
[17:41] <popey> good, SEP
[17:41] <timothy> like I did on tests, https://github.com/snapcore/snapd/pull/1468/commits/b66d3ea328ee42d3d4f56ed9736c315833dee67d
[17:41] <mup> PR snapd#1468: Fix ./run-checks --static <Created by drizzt> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1468>
[17:42] <popey> ok, guess I'll file a bug on snapcraft then :)
[17:42] <popey> thanks for your valuable time chaps :)
[17:44] <popey> https://bugs.launchpad.net/snapcraft/+bug/1607015
[17:44] <mup> Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:New> <https://launchpad.net/bugs/1607015>
[17:44] <popey> \o/
[18:11] <mup> PR snapd#1592 closed: many: update code for the new snap_mode <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1592>
[19:48] <kyrofa> jdstrand, what's the current status of seccomp argument filtering?
[20:00] <mup> PR snapcraft#675 closed: Allow godeps to fetch Go dependencies <Created by stevenwilkin> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/675>
[20:00] <mup> PR snapcraft#691 opened: Add godeps plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/691>
[20:01] <kyrofa> josepht, elopio ^^ could use a review
[20:02] <kyrofa> Note that I'm adding a demo for it now
[20:02] <kyrofa> Nah... an integration test actually
[20:03] <jdstrand> kyrofa: waiting on snap-confine 1.0.39 to land in xenial
[20:04] <kyrofa> jdstrand, awesome. Will that automatically unblock setpriority, or do we also need profile changes in snapd?
[20:04] <jdstrand> kyrofa: actually this is fine too: 1.0.38-0ubuntu0.16.04.3
[20:04] <jdstrand> kyrofa: once that lands it will unblock me to fix things like setpriority
[20:05] <kyrofa> jdstrand, alright
[20:05] <kyrofa> Thanks for the update!
[20:05] <jdstrand> I didn't want to land that stuff in snapd cause it lands a whole lot faster in the archive than snap-confine and then snapd would be blocked on the snap-confine landing
[20:05] <jdstrand> so, waiting patiently :)
[20:08] <josepht> kyrofa: that PR looks good to me.  Needs more double quotes ;)
[20:08] <LBo> I had some problems with snapcraft
[20:08] <kyrofa> josepht, I can't. elopio bruised the fingers I use to press that button
[20:08] <LBo> Whenever I built something with snapcraft I got this error: execv failed: Permission denied
[20:09] <LBo> After some triaging it seems that my umask is the problem
[20:09] <kyrofa> jdstrand, understood, no rush! I was just curious where we were there
[20:09] <kyrofa> LBo, yeah that may cause issues
[20:09] <LBo> The default umask is 0002, then the snap works
[20:10] <LBo> kyrofa: ah, thanks. I was pulling my hairs
[20:10] <LBo> Is this documented somewhere?
[20:10] <LBo> Another user on IRC had the same problems a few days ago
[20:10] <LBo> Same error message, but nobody had an answer
[20:11] <jdstrand> kyrofa: oh, I want to that thing landed in xenial so I can run with the arg filtering policy! :)
[20:11] <LBo> Is it a bug, or just something by design?
[20:11]  * jdstrand is chomping at the bit for that
[20:11] <kyrofa> jdstrand, you'll have fun actually testing that stuff with the new re-exec stuff
[20:12] <kyrofa> LBo, wait, I'm not sure I understand. You're getting those issues when running an installed snap?
[20:13] <LBo> kyrofa: yeah, exactly
[20:13] <LBo> http://paste.ubuntu.com/21186127/
[20:14] <LBo> Well, when running the snap built with a specific umask
[20:15] <kyrofa> LBo, if you change the umask after you create a snap that works, does it stop working?
[20:15] <kyrofa> i.e. build the snap, change the umask, then install and run
[20:16] <LBo> Then it works
[20:16] <LBo> http://paste.ubuntu.com/21186621/
[20:17] <kyrofa> LBo, okay so actually creating the snap isn't the problem?
[20:17] <kyrofa> Rather, the snap works regardless of the umask when built
[20:19] <LBo> No, the other way around
[20:19] <LBo> Built with 0022 it always runs, with whatever umask
[20:20] <LBo> Built with 0077 it only runs as root
[20:20] <LBo> When I ls the snaps the permissions of the snap directories are "wrong"
[20:20] <kyrofa> Huh... I thought squashfs got rid of that issue...
[20:21] <LBo> Not-working snap: drwx------  5 root root   50 jul 27 22:07 usr
[20:21] <LBo> Working snap: drwxrwxr-x  5 root root   50 jul 27 22:07 usr
[20:22] <kyrofa> To clarify, you tried the umask the other way around? Restrictive when building and permissive when running?
[20:22] <LBo> Yes
[20:22] <LBo> In the last paste: http://paste.ubuntu.com/21186621/
[20:22] <LBo> umask 0002 when building, 0077 when installing & running
[20:23] <kyrofa> That seems to work fine, no?
[20:23] <LBo> I'm sorry
[20:23] <LBo> That was the other way around
[20:23] <LBo> I will do a new one: 0077 when building, 0002 when running
[20:24] <kyrofa> Yes, please do that
[20:24] <kyrofa> Sorry for the confusion-- I don't typically utilize umask
[20:24] <LBo> This is what you meant: http://paste.ubuntu.com/21187624/
[20:26] <LBo> ls -hal /snap/xcape/{x10,x11}/
[20:26] <LBo> total 4,5K
[20:26] <LBo> drwxrwxr-x  4 root root   67 jul 27 22:16 .
[20:26] <LBo> drwxr-xr-x 13 root root 4,0K jul 27 22:24 ..
[20:26] <LBo> -rwxr-xr-x  1 root root  299 jul 27 22:16 command-xcape.wrapper
[20:26] <LBo> drwxrwxr-x  2 root root   32 jul 27 22:16 meta
[20:26] <LBo> drwxrwxr-x  5 root root   50 jul 27 22:16 usr
[20:26] <LBo> ls: cannot open directory '/snap/xcape/x11/': Permission denied
[20:28] <LBo> I don't know if it has anything to do with versions, but to be complete: snapd = 2.0.10, snapcraft = 2.13.1
[20:29] <jdstrand> zyga: fyi, I think the last "RE: How do I share a namespace between snap commands?" may be due to how the bind mounts are setup
[20:30] <jdstrand> zyga: (on snapcraft@, and hi! :)
[20:33] <Pharaoh_Atem> does anyone know where the firefox snapcraft.yaml is?
[20:34] <kyrofa> LBo, set your umask restrictive and install the hello-world snap. Do you have the same issues?
[20:35] <LBo> No, that works fine: http://paste.ubuntu.com/21189027/
[21:27] <zyga> jdstrand: hey
[21:27] <zyga> jdstrand: checking now
[21:29] <zyga> jdstrand: so it looks like the problem is the mount namespace
[21:29] <zyga> jdstrand: I'm too tired to analyze this in detail
[21:29] <zyga> jdstrand: I will have a "nice" backlog of things to work on after this sprint sprint
[21:37] <mup> Bug #1607067 opened: Add a dotfiles / hidden files interface <snapd-interface> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607067>
[21:45] <jdstrand> zyga: sure, np, it's late there! I just wanted you to be aware of the issue. thanks and goodnight! :)
[21:58] <LBo> What can I do to resolve this? Received 403: 'Developer has not signed agreement.'
[22:04] <Chipaca> LBo: https://bugs.launchpad.net/snapcraft/+bug/1596777
[22:04] <mup> Bug #1596777: trying to upload a snap without signing the agreement prints the error twice <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1596777>
[22:05] <Chipaca> LBo: is that your issue?
[22:05] <LBo> Chipaca: no, I just had to login to https://myapps.developer.ubuntu.com and register
[22:05] <LBo> But it wasn't obvious at first what I had to sign
[22:05] <Chipaca> LBo: sounds like the error should be a lot clearer
[22:05] <Chipaca> yeah
[22:06] <LBo> I thought at first I had to sign the code of conduct
[22:06] <LBo> Got it working now!
[22:06] <Chipaca> noise][: ^ not sure what component it is, but AIUI it's closer to things you have competence in than me
[22:06] <tsimonq2> o/
[22:07] <Chipaca> tsimonq2: o/
[22:07] <Chipaca> bbiab, need to shut down this box to add a hard drive
[22:11] <noise][> Chipaca: LBo: we have an open task to improve that and a bunch of other err messages
[22:12] <LBo> noise][: awesome, thanks!
[22:12] <noise][> things got a bit convoluted in the rush to 16.04 and other recent improvements
[22:13] <mup> Bug #1603018 opened: snap create-user gets bad username <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1603018>
[22:40] <tianon> jdstrand: I know I'm horrible and it's been forever, but when you've got a sec I'm finally ready for pointers about "docker" interfaces in snapd -- I've started looking at what's going to need to happen, and it _seems_ like we'll need an interface for the daemon (to confine it properly so it doesn't need --devmode), and a separate interface for the client (to talk to the daemon over the unix socket), …
[22:40] <tianon> …but I can't seem to find any example of service confinement in interfaces/builtin to back up my theory O:) (they all appear to be only for handling/managing the client-side, not worrying about daemon constraints)
[22:41] <tianon> I'm also happy to post to the list instead if that's easier to compile/discuss the topic :) (especially if it needs to be slightly more async)
[22:42] <tianon> (figured I'd start here since you did ask me to prod you when I was ready O:) )
[22:51] <tianon> "connected" vs "permanent" is what I'm currently exploring :)
[22:57] <mwhudson> uh huh why does this image i'm building not dhcp by default
[23:07] <tianon> permissions are hard, let's go ride bikes :)
[23:18] <tianon> it would appear that "plug" profiles are for the client half, "slot" profiles are for the daemon, "permanent slot" is bits the daemon has all the time, and "connected slot" is the bits the daemon gets when a client/plug is actually hooked up?  might be way off base :D
[23:28] <mup> Bug #1607121 opened: snap create-user creates user with silly gecos field <Snappy:New> <https://launchpad.net/bugs/1607121>
[23:50] <mup> Bug #1607129 opened: snap create-user does not check that sso user has ssh keys <Snappy:New> <https://launchpad.net/bugs/1607129>