[02:23] <liuxg> can anyone tell me why the "hello-world" example snap does not have the wrapper files after installation?
[02:27] <liuxg> elopio, ping
[04:32] <mup> Bug #1604964 opened: huge download for nothing - snap does not exist <Snappy:New> <https://launchpad.net/bugs/1604964>
[05:49] <zyga> good morning
[05:53] <e^1> good morning :)
[05:54] <e^1> zyga: looks like you are closer to my TZ
[05:55]  * e^1 reboots
[06:05] <didrocks> good morning
[07:06] <dholbach> hey hey
[08:43] <zyga> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1360199 :)
[08:49] <lpotter> :)
[08:51] <Son_Goku> zyga: check it again :)
[08:52] <zyga> Son_Goku: I just saw, thank you :)
[08:52] <zyga> Son_Goku: btw, you are up early ;)
[08:52] <zyga> Son_Goku: are you jetlagged?
[08:52] <Son_Goku> yep
[08:53] <Son_Goku> my coworkers were all freaked because I was cheery as hell when I got in at 9am
[08:53] <Son_Goku> because I'm usually more sour in the morning
[08:53] <Son_Goku> looks like it'll be the same today...
[08:53] <ogra_> lol, thats awesome !
[08:59] <Son_Goku> zyga, I think I've addressed all the things I noticed in the ticket
[09:00] <Son_Goku> so take a stab at resolving them, please :)
[09:02] <zyga> Son_Goku: with pleasure
[09:13] <Son_Goku> zyga, more feedbacks :)
[09:14] <zyga> Son_Goku: THANK YOU, the feedback you get is immensly valuable
[09:14] <zyga> Son_Goku: let me spend some time on iterating now
[09:15] <zyga> Son_Goku: snap-confine is "easy" but the C conventions for packaging are a new thing there
[09:15] <Son_Goku> :)
[09:15] <dpm> hi Son_Goku, did you get back home allright? :)
[09:15] <Son_Goku> yep
[09:15] <dpm> excellent
[09:15] <Son_Goku> €160 poorer due to emergency taxi to FRA, but managed it :)
[09:16] <dpm> argh, glad you made it in any case
[09:16] <Son_Goku> thank god I had the foresight to enable my credit cards in Europe
[09:16] <Son_Goku> otherwise I would have been really screwed
[09:17] <dpm> good thinking :)
[09:18] <Son_Goku> only reason I needed to do it was because I woke up too late :/
[09:18] <Son_Goku> I missed my shuttle and the next one would have been far too late
[09:18] <Son_Goku> made it to the plane with 10 minutes left on the clock
[09:18] <cking> hi there, how long does it take for a snap name registration to take to be reviewed? I've had one pending review since yesterday
[09:21] <Son_Goku> I definitely enjoyed being in Germany for the sprint though
[09:36] <Son_Goku> zyga, in regards to C conventions for packaging, at least for RPM based distros as long as you're using the correct macros, it should just "agree"
[09:37] <Son_Goku> SUSE defines %_libexecdir as /usr/lib, while Mageia defines it as %_libdir
[09:37] <Son_Goku> provided you pass the macro parameters to snapd, it should agree with snap-confine
[09:42] <zyga> Son_Goku: I revertee back to just plain %configure for now
[09:42] <zyga> Son_Goku: we can change it once it actually matters
[09:42] <Son_Goku> right
[09:43] <Son_Goku> afaik, plain %configure should define --libexecdir
[09:44] <Son_Goku> then your autoconf stuff can just automatically install to the subdirectories it creates in %_libexecdir
[09:46] <Son_Goku> yep, rpm -E %configure indicates as much
[09:55] <sergiusens> cking registering snap names should be instant
[09:56] <sergiusens> cking uploads of snaps can get blocked
[09:56] <sergiusens> cking or did you claim a name
[09:56] <cking> I claimed a name
[09:56] <cking> and that's "pending review"
[09:57] <cking> considering it's a package that I own anyhow in Debian and Ubuntu, I thought it would be trivially fast to get it reviewed and accepted
[09:59] <noise][> cking: I can look into that for you, we are still ironing out processes around these things
[09:59] <cking> noise][, ok, thanks!
[10:01] <noise][> cking: approved!  sorry for the delay
[10:02] <cking> thanks \o/
[10:07] <stgraber> zyga: https://bugs.launchpad.net/snappy/+bug/1606510
[10:07] <mup> Bug #1606510: Interfaces for LXD <Snappy:New> <https://launchpad.net/bugs/1606510>
[10:07] <mup> PR snapd#1577 closed: daemon, cmd/snap: refresh --devmode <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1577>
[10:07] <mup> Bug #1606510 opened: Interfaces for LXD <Snappy:New> <https://launchpad.net/bugs/1606510>
[10:31] <hades|2> can i upgrade my ubuntu core 15.04 kernel to 16.04 ?
[10:31] <hades|2> using ubuntu-core-upgrader ?
[10:42] <hades|2> is it possible to use ubuntu-core-upgrader to upgrade an existing ubuntu-corehost using  an img file ?
[10:45] <ogra_> hades|2, nope
[10:46] <ogra_> hades|2, snapd manages upgrades of snap packages ... upgrading the system is just "snap refresh"
[10:46] <ogra_> that will upgrade all snap packages including kernel and rootfs
[10:47] <Chipaca> what is ubuntu-core-upgrader?
[10:48] <ogra_> that package that carries do-release-upgrade
[10:48] <ogra_> (update-manager for headless systems)
[10:48] <hades|2> my host doesnt have snap refresh
[10:49] <Chipaca> ogra_, is it anything to do with snap?
[10:49] <ogra_> nope
[10:49] <Chipaca> sigh
[10:49] <ogra_> it is for classic installs
[10:49] <hades|2> starting from 16.04 ?
[10:50] <ogra_> Chipaca, would be trivial to make it call "snap refresh" at the end of the upgrade though :)
[10:50] <ogra_> but i guess thats kind of pointless given snaps refresh themselves
[10:50] <Chipaca> ogra_, 15.04 is so long ago, i'm pretty sure 'snap refresh' wasn't a thing then
[10:51] <hades|2> what about old ubuntu-core based on vivid/15.04 , how to upgrade to 16.04 ?
[10:51] <ogra_> oh, i missed the 15.04 part above
[10:51] <ogra_> (just rebooted to switch my session to unity8 ... backklog slipped through)
[10:51] <ogra_> hades|2, you cant
[10:51] <Chipaca> hades|2, wait, are you asking about *snappy* ubuntu core, or classic ubuntu core?
[10:51] <hades|2> snappy
[10:52] <ogra_> the image setup has changed in incompatible ways
[10:52] <Chipaca> and we don't have blessed core images yet anyway
[10:52] <ogra_> (as has the snap format and other things)
[10:52] <ogra_> right, there are no 16.04 images yet ...
[10:53] <hades|2> ok thx
[10:54] <ogra_> i assume that wont happen anymore though ... series 16 snap images should be upgradeable to series 18 snap installs later on
[10:54] <ogra_> 15.04 was kind of special in that regard, nothing was really finalized back thn
[10:54] <ogra_> *then
[10:55] <mup> PR snapd#1580 closed: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1580>
[10:55] <mup> PR snapd#1586 opened: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by chipaca> <https://github.com/snapcore/snapd/pull/1586>
[10:55] <ogra_> uh... bamf ... thats still alive ?
[10:56] <Chipaca> ogra_, as much as unit7 is
[10:56] <Chipaca> :-)
[10:56] <ogra_> heh
[10:56] <hades|2> ill reflash a host using a series 16 img then
[10:56] <Chipaca> ogra_, I think we do want to support 15.04->16 upgrades, but it's definitely not there yet
[10:57] <Chipaca> hades|2, there are no official 16 core images yet
[10:57] <ogra_> Chipaca, yeah, i was talking about 16->18 :)
[10:57] <hades|2> so is it safe to keep my current snappy 15.04 host ?
[10:58] <ogra_> until we announce official 16 series images you should better keep it, yeah
[10:59] <hades|2> using snappy update / snap refresh i might be ablke later on to upgrade "safely" too ?
[11:00] <Chipaca> hades|2, that is the plan as i understand it
[11:00] <Chipaca> hades|2, no reverts of that refresh though
[11:01] <Chipaca> hades|2, or in 15.04 parlance, no rollbacks of that upgrade
[11:01] <Chipaca> *update
[11:01] <Chipaca> :-)
[11:01] <hades|2> it should be fine for me although
[11:17] <kalikiana> Hrm. What is normally supposed to update snaps? Because of a blog post I "snap refresh"ed vlc, it evidently didn't update automatically. Am I missing some package for that?
[11:18] <ogra_> nope, there is a system service (systemd timer) that does the automated snap refresh runs
[11:19] <ogra_> not sure on what schedule that runs on classic installs though
[11:19] <ogra_> Chipaca, might know
[11:37] <mup> PR snapd#1529 closed: snap: rework the output after a snap operation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1529>
[11:45] <stokachu> sergiusens: could we invoke any parts this way before the npm install takes place? https://www.irccloud.com/pastebin/5m23iw2R/
[11:46] <stokachu> the hook could be preinstall
[11:47] <Cavan> I disconnected so I dont know if my messege sent (Sorry if It did): I still cant get Karaf to write to files, my wrapper is '#!/bin/sh set -e set -x  export KARAF_DATA="$SNAP_DATA" export KARAF_HOME="$SNAP"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances" if ! [ -d $KARAF_DATA/conf ]; then     cp -rd $KARAF_HOME/karaf-conf $KARAF_DATA/conf fi  LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH $KARAF_HOME/bin/karaf r
[11:50] <ogra_> Cavan, $SNAP_DATA is not user writable, is that a service or a binary a user would execute ?
[11:51] <ogra_> in case of the second you would have to use SNAP_USER_DATA
[11:51] <ogra_> (also setting HOME to SNAP if your app tries to write to its home wont work, $SNAP is readonly)
[11:58] <mup> PR snapd#1563 closed: Interfaces: hardware-observe <Created by cwayne18> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1563>
[12:04] <Cavan> ogra_, So is this how it should be? 'export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_DATA"'
[12:05] <ogra_> i would point both to SNAP_USER_DATA actually
[12:05] <ogra_> if thats an enduser app that a user executes
[12:14] <Cavan> ogra_, Im still getting 'mkdir: cannot create directory ‘/snap/karaf/x17/data/log’: Read-only file system' any idea what I could do?
[12:15] <ogra_> thats $SNAP
[12:15] <ogra_> so whatever you use in that mkdir should point to $SNAP_USER_DATA
[12:15] <ogra_> (and your config shoul point to that dir)
[12:19] <mup> PR snapcraft#686 opened: Add missing dependencies <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/686>
[12:27] <Cavan> ogra_, so like this? export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_USER_DATA"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances"
[12:27] <ogra_> yeah
[12:28] <Cavan> ogra_, anychance you could check out my stack overflow quickly if I link it?
[12:29] <ogra_> sure, just paste it on paste.ubuntu.com
[12:30] <Cavan> ogra_, thanks http://paste.ubuntu.com/20997635/
[12:31] <Cavan> ogra_, it hasnt been updated since you told me thye should both have SNAP_USER_DATA, so assume they're there
[12:31] <ogra_> heh
[12:31] <ogra_> i thoght you had a stak to look at, sorry
[12:32] <ogra_> that wouldnt have needed a pastebin :)
[12:32] <Cavan> Ah right aha, also I just noticed my wrapper is more up to date than that now 'set -e set -x  export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_USER_DATA"   mkdir -p "$KARAF_DATA/data/logs" mkdir -p "$KARAF_DATA/instances" if ! [ -d $KARAF_DATA/conf ]; then     cp -rd $KARAF_HOME/karaf-conf $KARAF_DATA/conf fi  LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH exec "$SNAP/bin/karaf" "$@"'
[12:32] <mup> PR snapd#1587 opened: store: deal with 404 froms the SSO store properly <Created by mvo5> <https://github.com/snapcore/snapd/pull/1587>
[12:34] <ogra_> Cavan, have a look at https://github.com/ogra1/jtiledownloader
[12:34] <ogra_> that ships a wrapper script
[12:35] <ogra_> (though this executes a jar )
[12:36] <ogra_> so far your wrapper looks ok though
[12:36] <ogra_> so what happens if you try to run it ?
[12:42] <ogra_> zyga, uuuh, is the base snap still public in the store ? can you please unpublish it ?
[12:42] <Cavan> ogra_, basically when I try to run the ./karaf I get
[12:42] <Cavan> mkdir: cannot create directory ‘/snap/karaf/x18/data/log’: Read-only file system WARN: can't update etc/config.properties with the generated command shutdown. We advise to manually add the karaf.shutdown.command property. Unable to update instance pid: Unable to create directory /snap/karaf/x18/instances /snap/karaf/x18/data/log/karaf.log (No such file or directory) Unable to update instance pid: Unable to create directory /snap/kar
[12:43] <ogra_> when you run ./karaf ?
[12:43] <ogra_> you mean you execute something inside $SNAP manually ?
[12:43] <ogra_> that cant work
[12:44] <ogra_> you need to use /snap/bin/karaf ... or just karaf ... (since /snap/bin should be in your PATH(
[12:44] <Cavan> I go into the /bin and execute karaf? I thought you had to boot it the normal way after the snap is installed, in the directory of course
[12:44] <ogra_> else you miss one layer of wrappers
[12:45] <ogra_> well, try /snap/bin/karaf ... see what that does
[12:45] <mup> PR snapd#1579 closed: snapstate: add daemon-reload to fix autopkgtest on yakkety <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1579>
[12:46] <Cavan> ogra_, I get the same result
[12:54] <ogra_> Cavan, well, the mkdir errors look like your wrapper has not been updated
[12:55] <ogra_> the mkdir seems to still point to the wrong dir
[12:56] <ogra_> Cavan, are you use the karaf binary actually uses these $KARAF_* vars at all ?
[12:57] <ogra_> or does it just try to write to ./ by default
[12:57] <ogra_> then you would need to add a "cd $SNAP_USER_DATA" to your wrapper before the exec line
[12:58] <Cavan> ogra_, If i go into the bin folder there is a setenv file which has the '# export EXTRA_JAVA_OPTS # Additional JVM options # export KARAF_HOME # Karaf home folder # export KARAF_DATA # Karaf data folder # export KARAF_BASE # Karaf base folder # export KARAF_ETC  # Karaf etc  folder' so I assumed thye would be the binaries?
[12:59] <ogra_> well, the binary doesnt seem to use the vars ...
[12:59] <ogra_> try the cd ... that might work around it
[13:00] <Cavan> ogra_, Okay, do I literally put it the line before the exec?
[13:00] <ogra_> a line above the exec line, yes
[13:06] <Cavan> ogra_, again same result. But for a test I ran the wrapper in /bin and I got '+ export KARAF_DATA= + export KARAF_HOME= + mkdir -p /data/logs mkdir: cannot create directory ‘/data’: Permission denied' If that is any help?
[13:07] <ogra_> well, that is if you execute /snap/bin/karaf ?
[13:07] <ogra_> (literally that string)
[13:07] <Cavan> No, thats if I execute /snap/bin/wrapper
[13:07] <ogra_> uh
[13:07] <ogra_> dont
[13:08] <ogra_> and how did wrapper get into /snap/bin ?
[13:08] <ogra_> your wrapper should live inside your snap ... not in the /snap/bin system dir of your host system
[13:09] <Cavan> When I've looked at online examples a few have created wrappers in the /bin, is that incorrect?
[13:09] <ogra_> as i said before, when you install the snap there are more layers of wrappers added automatically
[13:09] <ogra_> the top level wrapper (according to your snapcraft.yaml) will be /snap/bin/karaf
[13:10] <ogra_> and only that is what you should ever execute
[13:10] <mup> PR snapd#1582 closed: debian: move snapd.refresh.timer into timers.target <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1582>
[13:10] <ogra_> do not exec anything in /snap/karaf/$version/ directly
[13:10] <ogra_> that can not work
[13:12] <Cavan> So where should I install the wrapper? Also to atempty to run karaf I go /snap/karaf/current/bin/karaf Should I not be doing that aswell?
[13:12] <ogra_> you should install the wrapper where your snapcraft.yaml expects it
[13:13] <ogra_> looking at your stackoverflow post it is all correct
[13:13] <ogra_> just leave it like that
[13:13] <ogra_> just dont try to runanything else but /snap/bin/karaf
[13:14] <Cavan> If I do that I get this though '/snap/bin/karaf: No such file or directory'
[13:15] <ogra_> that cant really be ... your snapcraft.yaml defines it
[13:15] <ogra_> if you built your snap with that snapcraft yaml and snap installed it this commmand must be there
[13:16] <Cavan> i'll install it again to make sure
[13:16] <ogra_> oh
[13:16] <ogra_> wait !
[13:16] <Cavan> Okay
[13:16] <ogra_> why do you define "daemon: simple"
[13:16] <ogra_> thats for system daemons ... and will definitely not create the user binary in /snap/bin
[13:16] <Cavan> What should I do instead?
[13:16] <ogra_> but will instead create a systemd unit and install it
[13:17] <ogra_> just drop that one line
[13:17] <ogra_> and rebuild your snap
[13:17] <ogra_> (unless indeed ... your app is actually a system daemon)
[13:17] <ogra_> (but then you cant start it ... systemd will handle it)
[13:17] <ogra_> s/start/run it as a user/
[13:18] <Cavan> So I'm re-installing it back to my Stackoverflow post and dropping that one line correct?
[13:18] <ogra_> yes
[13:19] <ogra_> if karaf is actually something a user can run then thats the right way
[13:32] <Cavan> ogra_, okay now I'm getting 'Error: Could not find or load main class org.apache.karaf.main.Main' when typing /snap/bin/karaf
[13:32] <ogra_> you might need to set some app options then ...
[13:33] <ogra_> you said something about EXTRA_JAVA_OPTS  above
[13:33] <mup> Bug #1606574 opened: SSH Interface is missing <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606574>
[13:33] <ogra_> so whatever java needs (i'm really not a java specialist, i know how to make it exec a .jar ... thats about it)
[13:34] <Cavan> should I get the MakeFile to install the .jar?
[13:34] <ogra_> well, if you have a jar, just look at my jtiledownloader branch (linked above)
[13:34] <ogra_> that should get you going
[13:35] <Cavan> ogra_, thanks so much for your help, although you'll probably be hearing from me soon with another problem aha
[13:36] <ogra_> heh, well, good luck for now
[13:40] <Chipaca> jdstrand: on #1592696 I think you meant 16.04 not 14.04 :-)
[13:40] <mup> Bug #1592696: snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Invalid> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu Xenial):Confirmed> <ubuntu-core-launcher (Ubuntu
[13:40] <mup> Xenial):Incomplete> <https://launchpad.net/bugs/1592696>
[13:41] <timothy> I think it's fixed on new snap-confine
[13:42] <Chipaca> timothy: so do i :-) and jdstrand says as much in his latest update to that bug; i'm pointing out a typo in that comment, is all
[13:44] <mup> PR snapd#1585 closed: store, daemon, client, cmd/snap, docs/rest.md: adieu search grammar <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1585>
[13:52] <ogra_> hmm
[13:53] <ogra_> so how do i access any packages owned by the shared store account now that it is locked
[13:53] <ogra_> i know all packages were shared with me ...
[13:53] <ogra_> but i dont see them in my myapps.d.u.c page
[14:00] <zyga> ogra_: I cannot, I didn't publish it
[14:00] <ogra_> zyga, crap ... and i cant see it and the shared account is locked down
[14:01] <ogra_> zyga, is mvo anywhere near you ? he might know
[14:05] <zyga> ogra_: I bet he did it
[14:05] <ogra_> did what ? unpublish ?
[14:05] <ogra_> i still find it with snap find
[14:05] <Pharaoh_Atem> morning all
[14:06] <ogra_> zyga, i'm happy to do the unpublishing if someone tells me how we access the shared packages now ... we all should be able to since heidelberg
[14:06] <ogra_> but my myapps page simply doesnt show it
[14:09] <mup> PR snapd#1588 opened: tests: added spread find private test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1588>
[14:09] <mup> Bug #1605003 changed: cannot communicate with server - openSUSE Tumbleweed <Snappy:Invalid by zyga> <openSUSE:Confirmed for zyga> <https://launchpad.net/bugs/1605003>
[14:10] <jdstrand> Chipaca: yes, thanks
[14:12] <zyga> ogra_: I'm sorry, I don't know that; I never used the shared account
[14:12] <ogra_> zyga, well ...
[14:12] <zyga> jdstrand: hey, we will need to have snapd manage groups and users
[14:12] <zyga> jdstrand: for the case of lxd
[14:13] <zyga> jdstrand: so that ldx snap will be able to create the ldx socket that is not world writable
[14:13] <zyga> jdstrand: I'm just letting you know
[14:14]  * ogra_ vomits 
[14:14] <ogra_> so mvo tied all the shared packages to ogra@canonical.com ... which is not assigned to my U1 account at all
[14:15] <Pharaoh_Atem> O.o
[14:15] <ogra_> trying to add the new address to U1 while being in a unity8 session breaks because launchpad is to dumb to show me the capcha !!!
[14:16] <ogra_> (it considers the webbrowser appp as not capable to use captchas ... sigh)
[14:16] <ogra_> so silly
[14:19]  * Pharaoh_Atem sighs
[14:20] <Pharaoh_Atem> zyga: looks like F25 branching is starting
[14:20] <Pharaoh_Atem> you accidentally don't have F25 commit power: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-mvo5-goconfigparser/
[14:21]  * Pharaoh_Atem sighs
[14:21] <Pharaoh_Atem> time to prepare for messages about my entire world branching for F25...
[14:24] <chile> hi snappers
[14:25] <Cavan> orga_, How would I extract org.apache.karaf.main-4.0.5.jar fromthe make file, when I try it just places the file instead of extracting it
[14:25] <sergiusens> ogra_ heh, oSoMoN has a bug for that already
[14:26] <ogra_> great
[14:27] <ogra_> hmpf ... so i see a "core" package that was shared with all of us ... but there is no "base" package anywhere
[14:27] <ogra_> and that core package is also unpublished properly
[14:28] <ogra_> MVOOOOO !!!
[14:29] <ogra_> Cavan, well, you dont want to extract it ... look at my jtiledownloader snap
[14:29] <ogra_> (i gave you the github url above)
[14:29] <ogra_> just copy the exec line and replace my jar with yours in there
[14:31] <jdstrand> zyga: I saw that. note that in 15.04 what we did instead as a quick workaround was to add the lxd group to the system
[14:31] <jdstrand> zyga: tyhicks and I should be involved in the designs surrounding adding groups to the system via snaps
[14:31] <ogra_> uh
[14:32] <jdstrand> zyga: and possibly a memnber of foundations (slangasek or someone he assigns)
[14:32] <ogra_> adding system groups sounds slightly scary with libnss-extrausers in place and using a readonly /etc/groups
[14:33] <ogra_> (how do you make sure the GID doesnt clash if somme package added the same GID to the readonly side at core snap build time)
[14:34] <ogra_> (it would just come with the next oos snap update)
[14:34] <ogra_> *os
[14:34] <jdstrand> it indeed sounds scary since it would be easy for a snap to pick a group to add (eg, 'ogra')
[14:34] <ogra_> well, not only that
[14:34] <ogra_> you dont know what comes down the drain from the store
[14:34] <jdstrand> so maybe it wouldn't be arbitrary groups, but rather, the snappy interface says (ok, we'll set up this group)
[14:34] <ogra_> so you cant really predict if a GID will clash
[14:34] <Pharaoh_Atem> ogra_: mvo isn't even here, so he can't really hear you.... :/
[14:35] <ogra_> Pharaoh_Atem, there are enough people at his sprint ... i guess he is stuck in some session ;)
[14:35]  * Pharaoh_Atem shrugs
[14:35]  * ogra_ relies on mouth propaganda with that one ;) 
[14:36] <chile> any body
[14:36] <chile> with some idea on native apps in jquery+php+html experience
[14:37] <ogra_> jdstrand, well, i guess we'd need to define some range that cant get touched by image builds ... iirc we already define that system groups have to be below 1000 ... so we'd need a range ... say 1000-2000 that gets reserved for extra groups ... and make sure that user accounts only get created from 2000 onwards ... or something like that
[14:38] <ogra_> but thats fiddly to implement for sure
[14:45] <chile> any body with ubuntu cloud here
[14:58] <zyga> Pharaoh_Atem: hey
[14:58] <zyga> Pharaoh_Atem: why do you have two IRC nicknames
[14:58] <Pharaoh_Atem> zyga: yo
[14:58] <Pharaoh_Atem> this self is my workstation at work
[14:58] <Pharaoh_Atem> my other self (Son_Goku) is my laptop
[14:58] <zyga> Pharaoh_Atem: I've updated the snap-confine.spec
[14:59] <zyga> Pharaoh_Atem: pushed updates to fedorapeople
[14:59] <Pharaoh_Atem> this guy is persistent, the other one shows up when I'm away :)
[14:59] <zyga> Pharaoh_Atem: magic :)
[14:59] <zyga> Pharaoh_Atem: should I just indicate the changes on the bug report?
[14:59] <Pharaoh_Atem> yes
[14:59] <Pharaoh_Atem> always do that, as it's for the benefit of me, you, and others potentially watching
[14:59] <zyga> Pharaoh_Atem: you can also check what I did by looking at github (for all the real details)
[14:59] <zyga> ok, will do
[14:59] <Pharaoh_Atem> right
[15:05] <zyga> Pharaoh_Atem: I could use a hint that tells me how to do a fedkpg build against something from koji (the gopkg.in/check.v1 thing)
[15:07] <Pharaoh_Atem> you need to create the buildroot override
[15:07] <Pharaoh_Atem> https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages
[15:07] <Pharaoh_Atem> it would automatically be in effect for builds you do from your user with koji (via fedpkg)
[15:08] <Pharaoh_Atem> you should be able to build from F25 and Rawhide with no problems, though
[15:08] <Pharaoh_Atem> since both will have check in there already
[15:10] <elopio> stevebiscuit: why don't you ship your patched go plugin in snapweb in parts/plugin/x-go.py ?
[15:10] <elopio> that way we don't have to wait for a new release.
[15:12] <Pharaoh_Atem> zyga: I've approved snap-confine
[15:13] <zyga> Pharaoh_Atem: I'll do the change to the remaining two pkgconfig files
[15:13] <zyga> Pharaoh_Atem: I'm somewhat exhausted by the sprint and I'm very glad and I very much appreciate your detailed review
[15:14] <stevebiscuit> elopio: that's an option, I'd already mentioned godeps to kyrofa and he created the bug on LP
[15:17] <Pharaoh_Atem> zyga: that's why we do these in Fedora :)
[15:17] <Pharaoh_Atem> one more set of eyes tends to help at times
[15:18] <zyga> Pharaoh_Atem: I hope to get more so that we can have a day off sometime ;)
[15:22] <zyga> Pharaoh_Atem: I'll work on fedpkg builds now
[15:22] <zyga> Pharaoh_Atem: but it does look like we are down to snapd now :)
[15:22] <zyga> Pharaoh_Atem: I didn't check go-flags yet, is the update also going to f23+?
[15:22] <Pharaoh_Atem> yes
[15:22] <Pharaoh_Atem> it's going everywhere
[15:22] <zyga> that's good then
[15:23] <zyga> We had a release just now, 2.11 :)
[15:23] <Pharaoh_Atem> zyga: https://bodhi.fedoraproject.org/updates/?packages=golang-github-jessevdk-go-flags
[15:23] <zyga> I'll do COPR but I'm super happy I will be moving closer to fedora :)
[15:23] <Pharaoh_Atem> you can try out those packages and see if they work
[15:23] <zyga> Pharaoh_Atem: nice, I see
[15:23] <Pharaoh_Atem> and leave feedback :)
[15:23] <zyga> Pharaoh_Atem: yes, I will download them
[15:23] <zyga> Pharaoh_Atem: is there a better way rather than just to get them from bodhi?
[15:24] <zyga> Pharaoh_Atem: I will build against it in my local repo
[15:24] <Pharaoh_Atem> http://koji.fedoraproject.org/koji/packageinfo?packageID=20509
[15:25] <Pharaoh_Atem> you grab them from Koji
[15:25] <Pharaoh_Atem> looks like an override is already in place for go-flags
[15:25] <Pharaoh_Atem> it might "Just Work"
[15:25]  * Pharaoh_Atem shrugs
[15:34] <ahoneybun> tsimonq2, heard of KDE Connect?
[15:34] <tsimonq2> ahoneybun: no clue what it is
[15:35] <ahoneybun> you can send and recieve files between phone and PC
[15:35] <ahoneybun> also control mouse and keyboard
[15:35] <ahoneybun> it pulls a lot in from KDE in Libs
[15:35] <ahoneybun> so it would be cool to snap it
[15:45] <Cavan> ogra, I did exec $SNAP/org.apache.karaf.main-4.0.5.jar (Which I'm hoping is what you meant before) and I keep getting '/snap/karaf/x23/org.apache.karaf.main-4.0.5.jar: 1: /snap/karaf/x23/org.apache.karaf.main-4.0.5.jar: Syntax error: word unexpected (expecting ")")''  '
[15:46] <qengho> ogra_: WAT
[15:48] <qengho> I mean, not ogra_.
[15:48] <qengho> Cavan: That is very very wrong.
[15:49] <Cavan> qengho, which part, the exec?
[15:49] <Cavan> or the return im getting from the terminal?
[15:49] <qengho> Cavan: A jar file is a kind of zipfile that is specific to Java. You can't ask the linux kernel to just execute it. It's not a java virtual machine.
[15:49] <qengho> Cavan: So, "exec jarfile" is wrong.
[15:51] <qengho> Cavan: you probably want to read up on what to do with the jarfile, and how one runs karaf. It's joing to have something to do with the program "java", though.
[15:53] <Cavan> qengho, Yeah I figured, I'm trying to figure out where its meant to go, ogra gave me fantasic advice earlier but im to terrible at this to figure it out aha
[15:55] <qengho> Cavan: I am guessing you should have in your snapcraft "command: wrappernamesomethingyouinvented", and in your wrapper, a shell script, you set up some variables and execute  java -Dhomesomethingsomething -classpath $SNAP/something jarfilesomething classnametobootstrap
[15:57] <qengho> Cavan: stop with the snap part for a while. Figure out how you run that. Once you have a firm grasp how it NORMALLY starts up, come put those commands in a snap.
[15:57] <mup> PR snapd#1581 closed: asserts: remove/disable comma separated lists and their uses <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1581>
[15:58] <qengho> Cavan: You only have problems that have nothing to do with snappy so far. We're going to be terrible at answering those. :(
[15:59] <Cavan> qengho, ah thats fair enough, I'll give it a good go aha, thanks!
[16:01] <qengho> Cavan: We'd love to help. Don't be shy about questions, but realize I have never even heard of karaf before your questions.
[16:02]  * qengho Zzzz
[16:08] <ogra_> Cavan, https://github.com/ubuntu/snappy-playpen/blob/master/jtiledownloader/launcher
[16:08] <ogra_> Cavan, see the last line
[16:08] <ogra_> you want that
[16:08] <ogra_> (indeed with a path to *your* .jar
[16:08] <ogra_> )
[16:14] <zyga> Pharaoh_Atem: so what is the "there might be more..." comment about
[16:14] <zyga> Pharaoh_Atem: is there anything I should fix in snap-confine packaging?
[16:14] <Pharaoh_Atem> forgot to run fedora-review
[16:14] <Pharaoh_Atem> it has a checklist of things
[16:14] <zyga> oh, I will do it
[16:14] <zyga> thank you
[16:21] <zyga> Pharaoh_Atem: I must say fedora-review -n seems to assume SRPMs are in ~/rpmbuild/SPECS which is odd, I'll try it with the bug number
[16:24] <Pharaoh_Atem> zyga: I have to run it, and I posted the results in the bug
[16:24] <Pharaoh_Atem> though it's useful for you to do while crafting the spec
[16:26] <zyga> Pharaoh_Atem: I have a call now, I'll review it after that
[16:27] <Pharaoh_Atem> okay
[16:28] <zyga> I just saw the report, very useful!
[16:35] <Pharaoh_Atem> zyga: yeah, unfortunately I can't run it for golang stuff because it throws too many errors to be useful
[16:35] <Pharaoh_Atem> but it's a good blueprint regardless
[16:36] <Pharaoh_Atem> we make too many exceptions for golang that we do reviews for those differently
[16:43] <kyrofa> elopio, stevebiscuit indeed, sorry for moving slowly on the godeps plugin. I actually have one locally, but I need to clean it up and push. There were some things that needed to happen before then, but Fridays are my only snapcraft days currently so things take a sad amount of time
[17:10] <stevebiscuit> kyrofa, elopio: grand, I'll remind you about it during Friday's standup ;)
[17:26] <wililupy> Are there plans to have a docker snap?
[18:17] <mhall119> zyga: how do give a snap access to certain hardware?
[18:17] <mhall119> I'm getting Log: apparmor="ALLOWED" operation="open" profile="snap.arduino.arduino" name="/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial" pid=18376 comm="java" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[18:17] <mhall119> File: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial (read)
[18:17] <mhall119> Suggestion:
[18:17] <mhall119> * use gadget hardware assign to access '/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/serial'
[18:18] <mhall119> also in the arduino IDE: can't open device "/dev/ttyACM0"; Permission denied
[18:31] <ahoneybun> mm I'm wondering about getting code from git
[18:33] <ahoneybun> mhall119, I'm thinking about making a snap on KDEConnect
[18:47] <jdstrand> mhall119: I think you want to use the serial-port interface
[18:47] <jdstrand> mhall119: you might be the first user of that interface so please file 'snapd-interface' bugs if you see them
[18:50] <Dubstar_04> Is there anynew on a fix for running OpenGL snaps on Nvidia systems?
[18:50] <Dubstar_04> *news
[19:05] <timothy> Dubstar_04: for example? on which distro? with nvidia or nouveau?
[19:07] <Dubstar_04> timothy: I'm on 16.04, snaps work with nouveau but no with Nvidia.
[19:07] <Dubstar_04> this is the output: http://paste.ubuntu.com/21041858/
[19:08] <timothy> using the snap-confine from proposed worked to me
[19:13] <ahoneybun> mm franz does not want to launch as a snap
[19:13] <ahoneybun> tsimonq2, ^
[19:13] <Croepha> so, on the ubuntu site, it says that Snappy uses delta's to reduce bandwidth, how does that work? like does it use vcdiff? does the server have all the diffs handy?
[19:16] <timothy> iirc it's need to be re-added
[19:17] <Croepha> timothy, the functionality was there, but isn't now
[19:17] <Croepha> ?
[19:17] <timothy> Croepha: http://askubuntu.com/a/789634
[19:19] <Croepha> timothy: thanks
[19:19] <Dubstar_04> timothy: i have installed that. now I am getting: multiple nvidia drivers detected, this is not supported
[19:20] <timothy> maybe you have multiple nvidia drivers installed?
[19:21] <Dubstar_04> Umm, I have been switching between nouveau and nvidia while testing snaps. maybe something got messed up.
[19:22] <ahoneybun> let's try this again
[19:23] <mhall119> jdstrand: is serial-port interface in snapd on xenial?
[19:24] <mhall119> because I don't see it in `snap interfaces`
[19:27] <jdstrand> mhall119: it is and has been for a long time. I'm not sure why it doesn't show up. that may be one of the bugs (it was implemented a very long time ago)
[19:28] <Croepha> if I deployed with 16/rolling/edge would there be a clear upgrade path once 16 comes out as stable? without having to reflash?
[19:28] <mhall119> jdstrand: where do I file bugs for it? has that moved to github too?
[19:29] <jdstrand> bugs are still LP
[19:29] <mhall119> jdstrand: lp:snappy ?
[19:29] <jdstrand> https://bugs.launchpad.net/snappy/+filebug
[19:29] <ahoneybun> could anyone look at these errors http://pastebin.ubuntu.com/21044760/
[19:29] <jdstrand> add the 'snapd-interface' tag
[19:30] <ahoneybun> it's complaining about gtk but I have desktop gtk in the yaml
[19:30] <Dubstar_04> timothy: I only have one nvidia driver installed
[19:30] <ahoneybun> yaml: http://pastebin.ubuntu.com/21044876/
[19:32] <jdstrand> mhall119: a super-cursory reading of the test code indicates that slot implementation should define the serial ports and then you would plugs what it exports. that doesn't sound like it will do what you are looking for since classic and the os snap don't do any of that atm
[19:33] <jdstrand> s/test code/serial_port*.go code/
[19:33] <jdstrand> I think this was implemented thinking a gadget snap would 'slots: ...' and then snaps would plug into that
[19:33] <jdstrand> (which would make sense)
[19:34] <jdstrand> and/or the os/core snap would auto-detect these ports and supply implied slots
[19:34] <jdstrand> (which would also make sense)
[19:35] <jdstrand> but that today, there is no gadget snap on classic and snapd is not detecting the serial ports to provide an implied slot
[19:35] <jdstrand> I *think* the hooks work may in part be for this sort of thing, but would need zyga to confirm
[19:35] <mup> Bug #1606674 opened: Unable to drive Adruino over USB from Arduino IDE snap <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606674>
[19:36] <mhall119> jdstrand: https://bugs.launchpad.net/snappy/+bug/1606674
[19:36] <mup> Bug #1606674: Unable to drive Adruino over USB from Arduino IDE snap <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1606674>
[19:36] <jdstrand> I see that, thanks
[19:37] <jdstrand> zyga, can you take a look at bug #1606674 when you have a moment?
[19:37] <mhall119> otherwise my arduino IDE snap is fully functional
[19:37] <mhall119> with the exception of being able to, you know. function :)
[19:38] <jdstrand> that interface is absolutely what you should be using
[19:39] <timothy> mhall119: I think you can access /dev/ttyACM0 without using snap :P
[19:39] <jdstrand> but I think the implementation hasn't been revisited since classic was a focus and other things got prioritized over the gadget/all snaps finishing touches
[19:39] <jdstrand> timothy: well, he can also use --devmode
[19:40] <timothy> "However, it is unable to access the board, even in devmode."
[19:40] <jdstrand> ah, I didn't read the bug yet. that is weird
[19:41] <jdstrand> mhall119: what are the permissions on /dev/ttyACM0 ?
[19:42] <jdstrand> mhall119: I suspect devmode isn't working right cause of that. /dev is listed as a source mount in snap-confine, so that shouldn't be it (are you using snap-confine from proposed?)
[19:44] <jdstrand> mhall119: is the output the same regardless of if you are in devmode or not or is the output different? if different, you should list that in the bug. I suspect there are two different bugs
[19:44] <timothy> mhall119: can you do an ls /dev/ttyACM0? maybe it's using some acl, that you can see with getfacl /dev/ttyACM0
[19:45] <timothy> ls -l*
[19:47] <mhall119> jdstrand: from within the snap, or normally?
[19:47] <mhall119> crw-rw---- 1 root dialout 166, 0 Jul 26 14:15 /dev/ttyACM0
[19:47] <mhall119> oh, hangon, I seem to recall needing to make my user part of the dialout group to use the arduino ide
[19:48] <timothy> yes, you need dialout group
[19:48] <timothy> sudo gpasswd -a $USER dialout
[19:49] <jdstrand> right
[19:49] <jdstrand> so that should make it work in devmode
[19:49] <timothy> yep
[19:49] <jdstrand> (please comment in the bug if it does)
[19:49] <timothy> ofc you need to reload or to do su - $USER
[19:56] <mhall119> sure enough, getting into the dialout group lets it work in --devmode
[19:56] <ahoneybun> tsimonq2, did you see the links?
[19:57] <tsimonq2> ahoneybun: what links?
[19:57] <ahoneybun> I'm trying to work on Franz snap anyway
[19:57] <ahoneybun> getting some gtk errors when running it
[19:59] <mup> Bug #1574114 opened: snapd should not conflic with mediaplayer snappy <amd64> <apport-bug> <xenial> <One Hundred Papercuts:Confirmed for mvo> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed for mvo> <https://launchpad.net/bugs/1574114>
[20:00] <ahoneybun> this darn connection today is back
[20:01] <timothy> let's try apparmor with confinement on archlinux with nvidia drivers :)
[20:01] <timothy> s/apparmor/snap/
[20:02] <Dubstar_04> Anyone using snappy with Nvidia cards?
[20:03] <Dubstar_04> I have purged all nvidia drivers and I still get this message: http://paste.ubuntu.com/21048959/
[20:03] <timothy> Dubstar_04:
[20:03] <timothy> ls /usr/lib/nvidia-[1-9][0-9][0-9]
[20:04] <Dubstar_04> timothy: how do i remove those?
[20:05] <timothy> did you installed those by installing the driver by hand?
[20:05] <Dubstar_04> http://paste.ubuntu.com/21049367/
[20:06] <Dubstar_04> I have only ever installed through ubuntu drivers, I think
[20:06] <Dubstar_04> can i just rm -rf /usr/lib/nvidia*
[20:07] <timothy> dpkg -S /usr/lib/nvidia-346/libnvidia-fbc.so.1
[20:07] <dz0ny> Dubstar_04: purge will not help since it rewrites gl load paths
[20:08] <Dubstar_04> Its working!!!
[20:08] <Dubstar_04> timothy: thanks!!
[20:08] <Dubstar_04> My snap works at last!!
[20:08] <timothy> you're welcome, you are like I studied snap-confine last week :P
[20:08] <timothy> lucky*
[20:08] <ahoneybun> Dubstar_04, I have NVIDIA but it's using the Intel atm
[20:09] <ahoneybun> I'm just trying snaps today
[20:09] <ahoneybun> first time working with snapcraft lol
[20:09] <Dubstar_04> I might try and reboot and reinstall nvidia drivers before i get too excited...
[20:10] <ahoneybun> I have Intel and NVIDIA
[20:10] <ahoneybun> but I have not install the driver for the Nivida
[20:10] <mup> PR snapd#1589 opened: interfaces: miscelleneous policy updates for default, mount-observe, opengl and unity7 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1589>
[20:12] <Dubstar_04> Are there snap channels, like alpha, beta, stable?
[20:14] <timothy> http://snapcraft.io/ search for channels
[20:15] <Dubstar_04> timothy: perfect, thanks.
[20:18] <timothy> Dubstar_04: works?
[20:18] <Dubstar_04> I switched back to Nvidia drivers and i'm still getting the opengl errors
[20:18] <Dubstar_04> :(
[20:21] <timothy> sorry I have to go
[20:58] <mhall119> sergiusens: you around?
[21:14] <mup> PR snapcraft#687 opened: Enable integration tests to run in the production store <Created by elopio> <https://github.com/snapcore/snapcraft/pull/687>
[21:23] <mup> PR snapcraft#688 opened: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>
[21:29] <ahoneybun> wonders
[21:39] <mup> PR snapd#1590 opened: interfaces: add process-control interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1590>
[23:17] <thurston> I'm getting this error in my Snap package:
[23:17] <thurston> X Error: BadValue
[23:17] <thurston> Request Major code 154 (GLX)
[23:17] <thurston> Request Minor code 3 ()
[23:17] <thurston> Value 0x0
[23:17] <thurston> Error Serial #23
[23:17] <thurston> Current Serial #24
[23:22] <thurston> any help?