[00:58] <qengho> diddledan: seccomp could totally change for that. Please file a bug report on "snappy" and then tag the report with "snapd-interface".
[00:58] <qengho> $ ubuntu-bug snappy
[02:29] <goddard> how can i build my snappy package if it doesn't have the library version i need
[02:29] <goddard> it had a library i need from 14.04 but it isn't in 16.04
[02:32] <qengho> goddard: You can get the source, assuming it's still online.
[02:32] <goddard> qengho: and then with the source it can build the project an automatically find the library?
[02:33] <qengho> goddard: Library is another part. Get the source with a tag or branch name.
[02:33] <qengho> goddard: Try it!
[02:33] <goddard> qengho: ok so i have to get the source of the library as well?
[02:34] <qengho> goddard: I assume so!
[02:34] <qengho> goddard: An example from my project:  http://bazaar.launchpad.net/~privacy-squad/+junk/tor-middle-relay-snap/view/head:/snapcraft.yaml
[03:57] <qengho> .../qt5/qml/Ubuntu/Components/1.3/Icon.qml:113:5: QML QQuickImage: Failed to get image from provider: image://theme/back
[03:57] <qengho> Argh.
[03:58] <qengho> I need more tables to flip.
[05:31] <wililupy> I lost it in my emails, how do I install the ubuntu-classic snap?
[05:32] <wililupy> nm, found it.
[05:33] <qengho> wililupy: what is it? Someone will see your question.
[05:34] <wililupy> qengho: http://pastebin.ubuntu.com/20274792/
[05:35] <qengho> wililupy: thanks!
[05:38] <mup> PR snapd#1576 closed: interfaces/builtin: allow getsockopt for connected x11 plugs <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1576>
[05:51] <liuxg> when I use license in snapcraft.yaml, it says "DEPRECATED: 'license' defined in snapcraft.yaml". what is the correct way to use a license file? thanks
[05:58] <qengho> liuxg: I think you want something in meta/ dir.
[05:59] <liuxg> qengho, it seems to me that the document is outdated. do you have an specific example for it?
[06:00] <liuxg> qengho, meta/dir is the one generated during the snapcraft, right?
[06:00] <qengho> liuxg: I have snapcraft source code!
[06:00] <qengho> liuxg:  meta/license.txt
[06:00] <liuxg> qengho, OK. In a snap project, we should not create the meta directory.
[06:01] <qengho> liuxg: oh, wait.  setup/license.txt
[06:01] <liuxg> qengho, everything must be from the snapcraft.yaml. so we need find something defined there.
[06:01] <liuxg> qengho, it seems right :)
[06:01] <dholbach> hey hey
[06:02] <qengho> The Holbach. Good morning.
[06:02] <dholbach> :-)
[06:02] <dholbach> how are you all doing?
[06:03] <liuxg> qengho, I just moved it to the "setup" directory, however, it seems it is still the same.
[06:03] <qengho> Okay. The Qt app I'm working on has inexplicable failure.
[06:03] <qengho> liuxg: remove "license" from your YAML.
[06:04] <liuxg> qengho, then how about the other fields like "license-agreement"?
[06:04] <liuxg> qengho, license-version?
[06:06] <liuxg> qengho, I did it at your suggestion, when I installed it, it did not prompt me to accept the license file.
[06:06] <qengho> liuxg: I think you need those. They are copied straight to snap YAML.
[06:07] <liuxg> qengho, i need them in the snapcraft.yaml?
[06:09] <qengho> liuxg: Yes, license-agreement and license-version .
[06:10] <qengho> license-agreement: true  ?
[06:10] <qengho> Not sure.
[06:11] <liuxg> qengho, http://paste.ubuntu.com/20278290/, is this right?
[06:14] <qengho> wo bu zhidao
[06:21] <liuxg> qengho, thanks!
[07:20] <kgunn> robert_ancell: https://bugs.launchpad.net/snappy/+bug/1574851
[07:20] <mup> Bug #1574851: libgl not found on nvidia machines (so far) <Snappy:Triaged> <nvidia-graphics-drivers-361 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574851>
[07:26] <mup> PR snapd#1571 closed: tests: add network-observe interface spread test <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1571>
[07:28] <mup> PR snapcraft#677 opened: playing with caching <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/677>
[07:34] <mup> PR snapcraft#676 closed: Special handling for pc files for conflicts <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/676>
[09:14] <mup> PR snapcraft#678 opened: Release debian/changelog for 2.13 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/678>
[09:16] <seb128> sergiusens, hey, it was nicer when snapcraft changelog had a summary of the changes, more exciting as an user
[09:16] <seb128> the new format doesn't motivates me to update
[09:16] <seb128> like I don't see anything fancy/useful listed and I'm like "bah"
[09:28]  * kalikiana wonders how to get rid of manpages and include files: snapcraft always fails when using "stage" to drop folders from parts/*/install
[09:31] <didrocks> zyga: http://paste.ubuntu.com/20290323/
[09:32] <qengho> kalikiana: I see that sometimes too.  :(
[09:32] <qengho> kalikiana: I think, anyway. What is your error message?
[09:35] <kalikiana> stage:
[09:35] <kalikiana>     - -share/man
[09:35] <kalikiana> [Errno 2] File or folder doesn't exist: '/home/cris/bau/neovim/stage/share/man/man1/nvim.1'
[09:42] <qengho> kalikiana: is that during a clean build, or an update?
[09:43] <qengho> kalikiana: I think we need a report of that bug. Do you mind filing it?  $ ubuntu-bug snapcraft  #probably
[09:43] <qengho> (Distro agnosticism is making support harder.)
[09:50] <kalikiana> qengho: Either one, makes no difference
[09:50] <kalikiana> Well, ubuntu-bug should  be snapped, problem solved ;-)
[09:54] <qengho> kalikiana: You are a genius.
[09:55] <kalikiana> https://bugs.launchpad.net/snapcraft/+bug/1605164
[09:55] <mup> Bug #1605164: Errors due to "missing" files using "stage:" <Snapcraft:New> <https://launchpad.net/bugs/1605164>
[10:08]  * qengho hugs kalikiana.
[10:22] <Cavan> Whats a simple run command for an snap I've created?
[10:23] <kalikiana> SNAPNAME.APPNAME or SNAPNAME if SNAPNAME==APPNAME
[10:23] <kalikiana> That's the formula
[10:24] <kalikiana> And if it's a service it becomes snap.SNAPNAME.APPNAME
[10:26] <qengho> Cavan: so, it's your defined command block name, or cavansnapname dot commandname if they're different.
[10:27] <Cavan> I created a generic randomly named command in the .yaml and when I try to snap I get the error 'The specified command 'zep' defined in the app 'zep' does not exist or is not executable'
[10:27] <Cavan> qengho*
[10:33] <qengho> Cavan: $ find prime -type f -name zep |sed -e s,^prime/,,
[10:35] <Cavan> qengho, nothing visable happens on the terminal after i type the command
[10:37] <qengho> Cavan: then inside your snap result, you are not making something called "zep". Explore that "prime" tree.
[10:37] <qengho> $ find prime |more
[10:38] <Cavan> qengho, basically I'm trying to snap Apache Zeppelin, but I cant figure out how to run the snap. It only seems to run as a service when Its a Deamon and wont let me run it as a executable
[10:39] <qengho> Cavan: Check the tree I said^. You're either not compiling what you think, or it's not called what you think.
[10:40] <qengho> Cavan: Er, wait, it's running in one command block and not in another? Same name?
[10:42] <Cavan> quengho, Originally it looked like this 'apps:  zeppelin:    command: bin/wrapper    daemon: simple    plugs: [network-bind]' And the service ran fine, but I cant do anything else with it. SO I tried changing it to this 'apps:  zep:    command: zep    plugs: [network-bind]' to see if I can run it but now it does nothing
[10:43] <qengho> Cavan: You had a program called /bin/wrapper. It worked. Now you're trying to run /zep and it's not working. It's because /zep inside the snap is not a program
[10:44] <qengho> Cavan, maybe you should look at bin/wrapper to see what it runs.
[10:45] <Cavan> quengho, Can I paste the wrappen in chat so you can have a look if you dont mind?
[10:46] <qengho> Cavan: Did you look?
[10:47] <Cavan> qengho, Yeah there is a frew exports with file paths
[10:47] <qengho> Cavan: The short of it is after "command: " is a real live file inside snap, and you can't just invent a name to put there. It has to be something that exists.
[10:48] <Cavan> qengho, that makes sense aha, I'm very new to this
[10:48] <qengho> Cavan: The short of it is, after "command: ", is a real live file inside the snap, and you can NOT just invent a name to put there. It has to be something that exists.
[10:51] <qengho> Cavan: The name after "apps:", that begins the next block IS a name that you invent. It can be anything. The command: part coming after that is the name of somethign on disk, and you have no liberty there.
[11:56] <ILoveArchLnx> Got some haters in the #ubuntu chat... pretty quick to ban/kick... no jesting allowed? do we have senses of humor in this room? How's everyone doing today/tonight?
[11:57] <ILoveArchLnx> Not looking to troll, just want to participate in some chatting
[11:57] <timothy> ILoveArchLnx: good nick
[11:57] <sborovkov> Hi. So any ideas what I could do about getpwuid() failing on classic? should I file a bug?
[11:57] <ILoveArchLnx> thank you timothy!
[11:57] <ILoveArchLnx> If I ask the wrong question though I might get banned... I was really honestly looking to find out more about Snappy packages but I asked if they are newer than normal LTS and poof.. ban hammer.
[11:58] <ILoveArchLnx> probably that question plus my nick... probably looked like trolling so I understand but garsh it was quick
[11:59] <davmor2> ILoveArchLnx: snapcraft.io will tell you most of what you want to know
[11:59] <ILoveArchLnx> thanks davmor2 ! You are amazing.
[12:00] <ILoveArchLnx> whoa snaps on the Arch!?
[12:00] <ILoveArchLnx> ... holy awesome?
[12:00] <timothy> yes, I maintain it
[12:00] <ILoveArchLnx> timothy I love you man, you are my hero.
[12:01] <ILoveArchLnx> I only maintain a couple AUR packages but I would love to one day help contribute to something bigger than myself such as this. Are the snaps pretty much "on-par" with normal Arch packages as far as "in-line" with developer stable releases??
[12:02] <ILoveArchLnx> "more in-line" I should say. Still takes maintainers but yes, are Snaps pretty "fresh" so to speak?
[12:02] <timothy> it depends, snap are only a "cointainer". people can put it anything they want
[12:02] <timothy> for example we have vlc "daily" snaps
[12:02] <ILoveArchLnx> oh... like a jail or chroot? or more so like a Docker/rkt container?
[12:03] <ILoveArchLnx> does it use lvm or some form of virtualized file-system and fs manager?
[12:03] <timothy> it uses squashfs images + something to do containment
[12:03] <ILoveArchLnx> or kernel level?? I'm excited sorry for the crazyness and I haven't slept and coffee lol
[12:03] <timothy> in http://snapcraft.io/ you'll find any information
[12:03] <ILoveArchLnx> nice, I've heard of squashfs but haven't read much into it
[12:04] <ILoveArchLnx> Oh ok, thanks bud! I'll do some reading. I might be back later to talk someone's ear off if they have one they want talked off :) I like to conversate. Learning from books is awesome and so is learning from people.
[12:04] <ILoveArchLnx> love love love learning!
[12:04] <ILoveArchLnx> thanks everyone! see you all around sometime!
[12:05] <ILoveArchLnx> you rock timothy !!
[12:05] <Cavan> how do I stop a service?
[12:06] <sborovkov> zyga: I don't see real /etc/passwd actually in ubuntu-core on classic. It's very similar file but has no ubuntu user for instance. Same with /etc/group, /etc/shadow. They are a bit different from real one
[12:07] <zyga> sborovkov: you must be running an older version of snap-confine then
[12:07] <ogra_> there should never be an ubuntu user inside /etc/passwd ... it should be in var/lib/extrausers
[12:07] <zyga> sborovkov: the one coming out of the sru will be okay
[12:07] <zyga> ogra_: this is classic )
[12:08] <sborovkov> sru?
[12:08] <ogra_> zyga, i thought he looks at the ubuntu-core snap under classic
[12:08] <qengho> Cavan: Use "systemctl".
[12:08] <mup> Bug #1605216 opened: cups-control interface doesn't allow printing <Snappy:New> <https://launchpad.net/bugs/1605216>
[12:09] <sborovkov> ogra_: well it'ubuntu user is in /etc/passwd. From what zyga told me I should see the real one in ubuntu-core. And that's where I saw the difference
[12:09] <sborovkov> so what's sru?
[12:09] <ogra_> a stable release update
[12:09] <ogra_> (of a package)
[12:11] <sergiusens> seb128 it was an SRU team requirement for me to do the changelog this way
[12:11] <seb128> ?!
[12:12] <seb128> who in the SRU team?
[12:12] <seb128> also SRU rules don't apply to yakkety :p
[12:13] <zyga> sborovkov: you see the non-real one in /snap/ubuntu-core/current/etc/passwd
[12:13] <zyga> sborovkov: run a shell inside a snap and see again
[12:13] <zyga> sborovkov: sudo snap installl snapd-hacker-toolbelt
[12:13] <tsimonq2> sergiusens: it owuld be nice to land my debian/control changes as well ;)
[12:13] <zyga> sborovkov: snapd-hackert-toolbelt.busybox sh
[12:13] <tsimonq2> *would
[12:13] <Cavan> qengho, is there any specific command or help I can type to terminate the service, Cant seem to find it through that
[12:14] <sergiusens> seb128 yeah, but I use the same changelog for each
[12:14] <qengho> Cavan: "systemctl |grep yourservicename", "servicectl stop fullservicename"
[12:16] <seb128> sergiusens, who in the SRU team told you that you can't describe what is new in the update?
[12:16] <seb128> I want to talk to them
[12:16] <sergiusens> seb128 -> slangasek
[12:16] <seb128> that's nonsense
[12:16] <seb128> sergiusens, thanks
[12:16] <sergiusens> seb128 it is common practice in other packages though, isn't it?
[12:17] <seb128> slangasek, hey, can you explain why a snapcraft SRU couldn't have its changelog to use " * new upstream version (lp...)\n-new option\n-nicer log\n-updated manpages"?
[12:17] <MonkeyDust> hi, trying snappy for the first time, in a ubuntu 16.04 chroot ... when typing 'snap list', it returns this error ... hint & tips please ... http://paste.ubuntu.com/20301926/
[12:18] <seb128> sergiusens, it's not uncommon but I tend to have "- ..." subitems describing the most interesting changes so users know what they get
[12:18] <seb128> also most SRUs are not version updates but specific changes and those are detailed
[12:19] <seb128> sergiusens, see e.g https://launchpad.net/ubuntu/+source/unity/7.4.0+16.04.20160715-0ubuntu1
[12:20] <Cavan> qengho, I ran both commands and the service is still running?
[12:20] <qengho> Cavan: How can you tell?
[12:20] <Cavan> qengho, systemctl list-unit-files '*snap*'
[12:21] <qengho> Cavan: does that say if it's running? I don't think so.
[12:22] <Cavan> qengho, ah yeah sorry, the local host has stopped aswell, thanks!
[12:22] <qengho> Cavan: If it is, you have your daemon misconfigured. See the "daemon: VALUE" in your snapcraft YAML.
[12:24] <dholbach> tsimonq2, https://www.youtube.com/watch?v=nPFMcZLdmog ← nice work
[12:24] <dholbach> ^ dpm, davidcalle, didrocks, popey, mhall119
[12:25] <tsimonq2> hey woah dholbach that talks about my PR being merged being in the past tense
[12:25] <tsimonq2> dholbach: not really ready to show everyone yet :P
[12:26] <dholbach> ok, I won't share it on @snapcraftio just yet then :-)
[12:26] <dholbach> I thought your PR had already landed
[12:26] <tsimonq2> hold your horses :)
[12:26] <sborovkov> zyga: indeed. there is ubuntu when I do it that way. Does that mean that getpwuid fails because of some other reason?
[12:27] <tsimonq2> dholbach: and btw my video is actually decent? :D
[12:27] <dholbach> tsimonq2, very much so
[12:27] <dholbach> nice work
[12:28] <dholbach> let me know when I can share it publicly :)
[12:44] <kalikiana> qengho: Wrt bug 1605164 I saw another yaml using "snap" instead of stage/prime as "snapcraft help plugins" suggests and tried that. That seems to work - I still don't get the behavior of "stage" but it does what I need.
[12:44] <mup> Bug #1605164: Errors due to "missing" files using "stage:" <Snapcraft:New> <https://launchpad.net/bugs/1605164>
[12:46] <qengho> kalikiana: Right, that changes which step omits that file from copying. It should work either place.
[12:47] <kalikiana> qengho: I added the info to the bug. Me thinks the documentation here is lacking.
[12:47] <kalikiana> Whatever stage does I cannot figure out at all
[12:47] <qengho> Thx.
[12:48] <kalikiana> Shaved 1M off my snap thanks to dropping unnecessary docs and headers :-D
[12:48] <qengho> Nice.
[12:49] <qengho> I need to do the same. I'll follow your lead.
[12:53] <kalikiana> Grrr I really think "snap install/remove" should tell me if it finds running instances of commands from a snap, it's annoying that it's getting stuck all the time.
[12:55] <qengho> kalikiana: I reported that already. https://bugs.launchpad.net/snappy/+bug/1587676
[12:55] <mup> Bug #1587676: forked, background processes can prevent "snap remove" with unhelpful message <Snappy:New> <https://launchpad.net/bugs/1587676>
[12:58] <kalikiana> qengho: Oh, nice, thanks
[13:06] <MonkeyDust> hi, trying snappy for the first time, in a ubuntu 16.04 chroot ... when typing 'snap list', it returns this error ... hint & tips please ... http://paste.ubuntu.com/20301926/
[13:08] <qengho> MonkeyDust: "chroot"?
[13:09] <MonkeyDust> qengho  are you not familiar with chroot?
[13:10] <qengho> MonkeyDust: snappy is snapd, and a kernel that has special security and filesystem features. I don't know what you're doing with chroot, but I would be astonished if it were enough.
[13:10] <MonkeyDust> qengho  ok, then that's it, cannot be done in a chroot, thanks
[13:10] <qengho> MonkeyDust: it's not just a bunch of files on disk. I don't think chroot will do it.
[13:11] <MonkeyDust> qengho  then let that be my first 'snappy lesson'
[13:12] <qengho> MonkeyDust: Your kernel might be enough. I don't know how you're going to hook to the main systemd, though, and that message looks like snapd isn't running.
[13:14] <kalikiana> Interesting, all my terminals now hang indefinitely while "snap install" is stuck spinning "security profiles"
[13:15] <mup> Bug #1605250 opened: the snap of the interface is combined with that of the only issue with the theme ambiance <Snappy:New> <https://launchpad.net/bugs/1605250>
[13:21] <tsimonq2> sergiusens: can you take another look at snapcraft#619 ?
[13:21] <mup> PR snapcraft#619: Add source-checksum option <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
[13:21] <qengho> kalikiana: I bet "lsof |grep /snap" will illuminate you.
[13:22] <tsimonq2> dholbach: snapcraft#619 is my PR ;)
[13:24] <liuxg> sergiusens, I have tried your telegram app, which is cool. A shortcoming is that it does not support Chinese though I have tried to install the Chinese fonts by modifying it. Now, the new snapcraft.yaml looks like http://paste.ubuntu.com/20307314/ what could be the problem for it? thanks
[13:26] <zyga> sborovkov: which version of snap-confine or ubuntu-core-launcher are you using?
[13:39] <mup> Bug #1605258 opened: SNAPD_DEBUG_HTTP should print HTTP headers <Snappy:New> <https://launchpad.net/bugs/1605258>
[13:40] <kalikiana> qengho: "all my terminals hang indefinitely" ;-) After having rebooted my guess is snapd ate all my RAM
[13:41] <mup> PR snapcraft#679 opened: add multiple generator script options to autotools <Created by apachelogger> <https://github.com/snapcore/snapcraft/pull/679>
[13:41] <sborovkov> zyga: snapd 2.0.10, ubuntu-core-launcher 1.0.27.1
[13:46] <mhall119> zyga: I won't be able to make our weekly call today, but I figure you're busy this week too :)
[13:46] <mhall119> shall we catch up next week?
[13:50] <mup> PR snapcraft#678 closed: Release debian/changelog for 2.13 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/678>
[13:54] <Cavan> I snapped Zeppelin but when I run the local host its connecting after install?
[13:55] <kalikiana> If it's a service, yes
[13:57] <mhall119> zyga: kyrofa: would it make sense for $HOME to be /home/$USER/ when a snap is connected to the "home" interface?
[13:57] <mhall119> otherwise things like opening files in Geany become tedious
[14:01] <Cavan> I snapped Zeppelin but when I run the local host its not* connecting after install?
[14:02] <Cavan> misstype
[14:18] <zyga> mhall119: maybe, we talked about it as something to explore for the caja snap
[14:18] <zyga> mhall119: but then again we wanted the home interface to be provisional and temporary
[14:19] <dholbach> didrocks, https://travis-ci.org/ubuntu/snappy-playpen/builds/146207147 - could it be that we need to add 'git' to the docker image?
[14:19] <zyga> mhall119: yes, let's catch up next week (I'll be sprinting again but I'll try to make it)
[14:19] <zyga> sborovkov: you probabyl want 1.0.38 for snap-confine
[14:19] <zyga> sborovkov: wait for the SRU or try proposed
[14:20] <sborovkov> zyga: proposed as in not stable version yet? How do I upgrade to it
[14:29] <diddledan> ergh @ wrong package: https://bugs.launchpad.net/ubuntu/+source/snappy-player/+bug/1605273
[14:29] <mup> Bug #1605273: Seccomp should allow fchown() with current userid/groupid <amd64> <apport-bug> <snapd-interface> <xenial> <snappy-player (Ubuntu):New> <https://launchpad.net/bugs/1605273>
[14:29] <diddledan> sorry, can someone let me know what the correct package should be? snappy-player was automatic
[14:30] <Cavan> Cant get the snapped Zeppelin to run in local host, any ideas?
[14:31] <jdstrand> diddledan: I fixed it
[14:31] <diddledan> thankyou
[14:55] <slangasek> seb128, sergiusens: I did not say that the SRU changelog can't describe the contents of the update; I said that a package that has an SRU exception shouldn't include extra bug references in the changelog
[14:57] <Cavan> How would I reference a spark plugin through the .yaml?
[14:59] <dholbach> Cavan, is this a plugin you wrote?
[15:00] <dholbach> http://snapcraft.io/docs/build-snaps/plugins
[15:01] <boghison> Can someone please take a look? https://github.com/snapcore/snapcraft/pull/579
[15:01] <mup> PR snapcraft#579: Add new plugin: rust <code-conflict> <Created by mariogrip> <Conflict> <https://github.com/snapcore/snapcraft/pull/579>
[15:02] <Cavan> dholbach, I didnt use that but I'm about to
[15:02] <dholbach> Cavan, nice
[15:02] <seb128> slangasek, sergiusens, ha, that makes more sense to me ;-)
[15:03] <dholbach> boghison, everybody's at a sprint right now, so code reviews could take a bit longer this week
[15:03] <josepht> boghison: there are still conflicts in that PR
[15:03] <boghison> josepht: Last message
[15:04] <josepht> boghison: did you push to the correct branch?
[15:06] <boghison> josepht: What do you mean? This is a commit in master in my fork of the OP's fork. I just want to fix those test issues and then the commit can be merged (he's still the author)
[15:25] <josepht> boghison: sorry, I was confused.  I'll take a look in a bit.
[15:25] <seb128> is that a known issue?
[15:25] <seb128> "ecryptfs_dir_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-13]"
[15:25] <seb128> snaps refuse to start on my xenial I think due to that error
[15:25] <seb128> jdstrand, ^ do you know about that?
[15:25] <boghison> josepht: No worries :)
[15:28] <jdstrand> I think that is likely fixed in the ucl that is trying to find its way in xenial. add this to /etc/apparmor.d/usr.bin.ubuntu-core-launcher : http://paste.ubuntu.com/20187635/, then do sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher
[15:28] <seb128> jdstrand, thanks, I tried the proposed version and it fails on another issue, "cannot bind mount /media to /tmp/snap.rootfs_TOuoFW/media. errmsg: Permission denied"
[15:28] <seb128> [  179.919020] audit: type=1400 audit(1469114803.329:42): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/tmp/snap.rootfs_TOuoFW/media/" pid=6392 comm="ubuntu-core-lau" srcname="/media/" flags="rw, rbind"
[15:29] <seb128> let me go back to the previous version with your change
[15:29] <jdstrand> zyga: fyi ^
[15:29] <jdstrand> I saw /mdeia/ changes go through when I was on holiday
[15:30] <seb128> things were working a week ago
[15:30] <seb128> unsure what changed/regressed
[15:30] <seb128> I hope it doesn't mean we got a regression/snappy not working on ecryptfs in .1
[15:30] <jdstrand> xenial still has 1.0.27.1
[15:30] <jdstrand> that has the ecryptfs fix
[15:30] <seb128> that's the version I have
[15:30] <seb128> Paramétrage de ubuntu-core-launcher (1.0.27.1) ...
[15:31] <seb128> $ gnome-logs-udt.bash
[15:31] <seb128> failed to create user data directory. errmsg: Permission denied
[15:31] <jdstrand> I fixed the ecryptfs policy a long time ago but with the snap-confine rename, etc, it never made it to sru
[15:31] <jdstrand> so, when you upgraded, you would have gotten the ecryptfs change, but there was that /media/ issue. downgrading would have reverted the ecryptfs fix and you'd need the workaround again
[15:32] <seb128> k
[15:32] <SamYaple> reviews and merges for PRs in snapcraft seem to take a while. anything I can do to help with that?
[15:32] <seb128> but things were working on that machine a week ago
[15:32] <SamYaple> I have some week old PRs I would like to see merged
[15:32] <seb128> I wonder why that just started being an issue
[15:32] <jdstrand> seb128: I'm fairly certain I gave you the work around policy before
[15:32] <jdstrand> so it would've been working
[15:32] <seb128> oh, maybe I had it for a long time and forgot about it
[15:32] <jdstrand> right
[15:32] <seb128> k
[15:32] <seb128> thanks jdstrand
[15:33] <jdstrand> like I said, this sru has been many weeks
[15:33]  * jdstrand will be glad when it lands
[15:33] <seb128> well I didn't have the snap-confine binary before now
[15:33] <seb128> so I wonder what reverted my local change
[15:33] <seb128> but doesn't matter much
[15:33] <jdstrand> SamYaple: I think one of those is on my todo-- I was on holiday until yesterday
[15:34] <jdstrand> the upgrade would've removed the ubuntu-core-launcher profile and the reinstall would've put it back
[15:34] <mup> Bug #1589527 changed: Debug option for http requests <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1589527>
[15:34] <SamYaple> jdstrand: no rush, I just want to make sure whoever is goign to review it isn't waiting on me for anything
[15:34] <jdstrand> SamYaple: also, most snappy devs are sprinting this week
[15:34] <SamYaple> jdstrand: im trying to get the python2 and python3 plugins into shape so I can start packaging openstack
[15:35] <seb128> jdstrand, back to a working system, thanks!
[15:35] <SamYaple> jdstrand: does that mean more or less PR attention?
[15:35] <jdstrand> SamYaple: anything that is needed from you should show up in the pr, so you should be fine
[15:36] <jdstrand> SamYaple: not sure-- that sounds like something for the snapcraft devs (also sprinting)
[15:36] <SamYaple> alrighty. well thanks for the info
[15:38] <SamYaple> i believe someone mentioned being able to use a single snap but launching different daemons from it, i havent been able to figure that out yet
[15:38] <SamYaple> can anyone point me in the right direction?
[15:41] <jdstrand> SamYaple: if I understand your question, if you have 3 services you want to start on boot, you just do:
[15:41] <jdstrand> apps:
[15:41] <jdstrand>   foo:
[15:41] <jdstrand>     command: ...
[15:41] <jdstrand>     daemon: simple
[15:41] <jdstrand>   bar:
[15:41] <jdstrand>     command: ...
[15:42] <jdstrand>     daemon: simple
[15:42] <jdstrand>   baz:
[15:42] <jdstrand>     command: ...
[15:42] <jdstrand>     daemon: simple
[15:42] <SamYaple> not quite, in your example I have tree services foo, bar, baz, they _can_ all run with the snap, but they should also be able to run without eachother
[15:42] <jdstrand> you can have as many entries in 'apps' as you want. drop 'daemon: simple' for something you want exposed in /snap/bin
[15:43] <SamYaple> so foo is on node1 and bar is on node2
[15:43] <SamYaple> s/tree/three/
[15:44] <SamYaple> so if a snap has multiple daemons, I want to be able to only run a subset of those, is that possible?
[15:44] <jdstrand> SamYaple: otoh one was to solve that would be ship foo, bar and baz, but not expose them in 'apps', and create a manager application that is exposed via 'apps'. the manager application starts/stops foo, bar and baz based on communications with other nodes
[15:45] <jdstrand> SamYaple: yes, you can ship all kinds of things in your snap including internal binaries, then you can control what runs when via something that is external (ie, in 'apps')
[15:47] <jdstrand> SamYaple: another way to do it would be to expose foo, bar and baz in 'apps', but have all of them honor a config file that something else manages
[15:47] <SamYaple> jdstrand: right thats what I was thinking
[15:47] <SamYaple> but rather a manager like you suggested first
[15:47] <SamYaple> i think that can work
[15:48] <SamYaple> jdstrand: i think im following you. let me play around with ti for a bit and see if can make it do what im thinking
[15:48] <jdstrand> SamYaple: note, if you are starting and stopping services yourself, you can't tie those services into the systemd boot (ie, the manager app owns all parts of the lifecycle for those)
[15:49] <SamYaple> jdstrand: ok thats what I thought. so if I lay down a service file and tell it to run foo.service1 and seperate one for foo.service2 then i should be good?
[15:49] <jdstrand> the managing of config files would allow those to tie into systemd. it all depends on what you need
[15:50] <SamYaple> i think im with you. ill just need some testing to fully wrap my brain around it
[15:51] <jdstrand> SamYaple: well, no-- that is what I was saying won't work. the only way you get service files is through daemon declarations in 'apps' (and you can only control the contents of those via the yaml directives-- you can't supply a service file).
[15:52] <jdstrand> SamYaple: so if you try the first approach (manager launches things), you need to have all tha launching and management logic in the manager. if you use the second approach (all are daemons declared in 'apps' but they consult a config file you control on whether to actually start or not), then you can use systemd
[15:52] <jdstrand> and the manager just manages the config files
[15:53] <SamYaple> jdstrand: hmm should that not work though through systemd? lets say something simple like a uwsgi api, i can just launch `/snap/bin/foo.uswgi /path/to/config`?
[15:53] <jdstrand> sure that would work
[15:54] <SamYaple> ok thats what I was thinking of doing.
[15:54] <jdstrand> I thought you implied corrdination via nodes, which is why I tossed the manager in there
[15:54] <SamYaple> nah there is outside corrdination, the service itself is unaware
[15:54] <lfaraone> During a `plugin: python2` part, are `stage-packages` supposed to be made available during the Snap build? I'm having issues building a snap that depends on `psycopg2` -- it fails with "    Error: You need to install postgresql-server-dev-X.Y for building a server-side extension or libpq-dev for building a client-side application.", but both
[15:54] <lfaraone> `postgres-server-dev-all` and `ligpq-dev` are listed in `stage-packages`.
[15:55] <SamYaple> lfaraone: that should be build-packages no?
[15:55] <lfaraone> that sounds more correct, yes. :)
[15:55] <jdstrand> SamYaple: make sure the config is in $SNAP_DATA somewhere (ie, the writable area), then the admin or whatever can adjust it
[15:56] <SamYaple> jdstrand: im new here, im not sure what $SNAP_DATA is refering too? (or maybe I am but I am confused)
[15:57] <jdstrand> SamYaple: an environment variable. you can see all the env vars by install hello-world then doing: hello-world.env |grep SNAP
[15:58] <SamYaple> ok will check
[15:58] <jdstrand> SamYaple: or play around with hello-world.sh which gives you a shell running under confinement
[16:05] <SamYaple> jdstrand: so question here. for an explict example, I am using snappy to package openstack keystone and the replace a baremetal installed keystone service, its configs are located at /etc/keystone and I am hardcoding that into the snap, is this wrong?
[16:09] <Cavan> Still having problems getting Apache Zepplin to work, just wont load into the localhost
[16:13] <jdstrand> SamYaple: yes-- snaps have readable and writable areas available to them separate from each other and the system
[16:14] <jdstrand> SamYaple: you'll want to put things that don't change in $SNAP (the install directory) and things that will change in $SNAP_DATA (the data directory)
[16:15] <SamYaple> up until now i was just backing in the config for testing, but i think this might be an issue. the config needs to stay in /etc/keystone (not be moved to $SNAP_DATA)
[16:15] <SamYaple> thats not possible is it?
[16:15] <jdstrand> SamYaple: davidcalle and/or dholbach should be able to point you at up-to-date docs to help you. There is https://developer.ubuntu.com/en/snappy/guides/ but some of that is for series 15.04 and not series 16
[16:16] <jdstrand> SamYaple: that is not allowed, no. you'll need to adjust your code to use /var/snap/keystone/current/etc/keystone or honor $SNAP_DATA (ideally the latter)
[16:19] <SamYaple> well thats a real shame. thats a limitation im not going to be able to work around. for just about anything I would want to use snappy for
[16:20] <jdstrand> SamYaple: why? it shouldn't be hard to adjust code to check the env var? that said, you might be interested in https://bugs.launchpad.net/snapcraft/+bug/1577514
[16:20] <mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
[16:21] <jdstrand> SamYaple: once implemented, that would allow you to declare what paths should be mapped without code changes
[16:21] <jdstrand> SamYaple: eg, the code would use /etc/keystone, but you'd declare to map /etc/keystone to $SNAP_DATA/etc/keystone
[16:24] <SamYaple> jdstrand: to answer your first question, no I can't adjust code to use an env variable, nor would I want to adjust code to be specific for a packing tool
[16:24] <SamYaple> once what you are describing is implemented I can revisit the issue. its a pretty hard stop for me right now. im rackign my brain for other solutions
[16:28] <SamYaple> hmm even if thats implemented, sharing sockets still won't be possible will it?
[16:28] <SamYaple> well. maybe. i guess it would depend on the implementation
[16:34] <jdstrand> SamYaple: a named socket should be doable using the same technique. anonymous sockets are allowed today and abstract sockets will be when bug #1604967 is implemented
[16:34] <mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
[16:35] <jdstrand> SamYaple: another approach would be adding interfaces for openstack
[16:35] <jdstrand> SamYaple: (I might also mention that /etc isn't allowed in part because /etc is mounted readonly on all-snaps systems)
[16:48] <jdstrand> SamYaple: ok, I noticed https://bugs.launchpad.net/snapcraft/+bug/1577514 didn't have a lot of detail so I tried to give some and asked for clarity on the priority and implementation. would you mind describing your use case and that the lack of this feature is a showstopper for you?
[16:48] <mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
[16:49] <Croepha> anyone here get pulseaudo to work on ubuntu-core? im trying to run it in a chroot, but udev isn't reporting back any sound cards
[16:51] <jdstrand> niemeyer: hey, would you mind looking at https://bugs.launchpad.net/snapcraft/+bug/1577514/comments/6 (and (potentially) later comments) and ask JamieBennett (not on irc now) to take a look too? maybe you can have a hallway conversation to get the priority sorted (it came up again today in the context of openstack)
[16:51] <mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
[16:57] <Cavan> If the bin/ doesnt have a wrapper what should I direct it to? The snaps I've made have all had wrappers so I'm a tad confused
[17:10] <SamYaple> jdstrand: its a showstopper for _me_ because I dont have the ability to control the config files locations. more accurately the projects I am attempting to integrate snappy with only use /etc/* folders for config files
[17:11] <SamYaple> jdstrand: from a technical perspective, it should be doable. from a practicle perspective, not being able to pull in /etc/* configs is a sever limitation
[17:12] <SamYaple> though there is always that occasion program that was coded poorly and hard codes a /etc/* conf into the source code too
[17:17] <boghison> josepht: Any news?
[17:23] <josepht> boghison: none yet
[17:33] <iliv> I accidentally ran snap remove for a package that was mounted. snap was trying to remove it but it couldn't succeed for a long time so I interrupted its execution with Ctrl-C. Now when I try to run remove or install I get this error message:
[17:33] <iliv> error: cannot remove "PKGNAME": snap "PKGNAME" has changes in progress
[17:33] <iliv> how do I clean up this mess?
[17:33] <balloons> open question -- does anyone know why after installing a snap, I don't get the binary in my PATH? How can I add snap binaries back to my path?
[17:34] <iliv> balloons, what is your PATH/
[17:34] <iliv> ?
[17:35] <iliv> balloons, also, are you invoking your command in this format: pkgname.command ?
[17:35] <balloons> iliv, /home/nskaggs/.local/share/umake/nodejs/nodejs-lang/bin:/home/nskaggs/.node_modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/bin:/home/nskaggs/projects/go/bin
[17:35] <iliv> for example, mypackage.telnet
[17:36] <iliv> balloons, this is what I have on my system:
[17:36] <iliv> $ env |grep PATH
[17:36] <iliv> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
[17:36] <balloons> iliv, see for example: http://paste.ubuntu.com/20333336/
[17:36] <iliv> not the /snap/bin at the end of the line
[17:37] <balloons> iliv, that was the ticket, ty. I'm just not sure why I didn't get it added
[17:38] <iliv> balloons, if memory serves, I didn't have to do anythign myself for it to be added to PATH
[17:41] <iliv> balloons,
[17:41] <iliv> $ grep "export PATH" /snap/hello/current/command-hello.wrapper
[17:41] <iliv> export PATH="$SNAP/bin:$SNAP/usr/bin:$PATH"
[17:45] <balloons> jdstrand, so I rebuilt my snap using the /var/snap path, and I'm trying to add unix addr="@/var/snap/@{SNAP_NAME}/**" as suggested. But it's not parsing the apparmor rule after I do it. What should it look like? http://paste.ubuntu.com/20334627/
[17:47]  * balloons facepalms
[17:47] <balloons> I missed a comma, sorry
[17:50] <iliv> balloons, that happens more often that you'd think ;)
[18:06] <balloons> what do you do in general with looking for config files in XDGDataHome?
[18:19] <balloons> hmm.. looks like using a bash script to launch
[19:48] <renatu> guys I created a interface for the calendar app, but I am getting this error: - Setup snap "ubuntu-calendar-app" (unset) security profiles (cannot setup mount for snap "ubuntu-calendar-app": cannot obtain mount security snippets for snap "ubuntu-calendar-app": unknown security system)
[19:48] <renatu> and the dbus connection is not working when running app
[21:21] <gustavopadre> hi guys, I'm really excited about snaps, could someone do a snap file of https://github.com/Aluxian/Whatsie
[21:29] <josepht> gustavopadre: there's a gulp plugin that would likely be helpful.  http://snapcraft.io/create/  We're happy to help
[21:31] <gustavopadre> josepht, I don't know how to program at all, is there any snaps that emulates whatsapp web available already?