=== chihchun is now known as chihchun_afk === JanC_ is now known as JanC [02:23] can anyone tell me why the "hello-world" example snap does not have the wrapper files after installation? [02:27] elopio, ping [04:32] Bug #1604964 opened: huge download for nothing - snap does not exist [05:49] good morning [05:53] good morning :) [05:54] zyga: looks like you are closer to my TZ [05:55] * e^1 reboots [06:05] good morning [07:06] hey hey === davidcalle|afk is now known as davidcalle [08:43] Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1360199 :) [08:49] :) [08:51] zyga: check it again :) [08:52] Son_Goku: I just saw, thank you :) [08:52] Son_Goku: btw, you are up early ;) [08:52] Son_Goku: are you jetlagged? [08:52] yep [08:53] my coworkers were all freaked because I was cheery as hell when I got in at 9am [08:53] because I'm usually more sour in the morning [08:53] looks like it'll be the same today... [08:53] lol, thats awesome ! [08:59] zyga, I think I've addressed all the things I noticed in the ticket [09:00] so take a stab at resolving them, please :) [09:02] Son_Goku: with pleasure [09:13] zyga, more feedbacks :) [09:14] Son_Goku: THANK YOU, the feedback you get is immensly valuable [09:14] Son_Goku: let me spend some time on iterating now [09:15] Son_Goku: snap-confine is "easy" but the C conventions for packaging are a new thing there [09:15] :) [09:15] hi Son_Goku, did you get back home allright? :) [09:15] yep [09:15] excellent [09:15] €160 poorer due to emergency taxi to FRA, but managed it :) [09:16] argh, glad you made it in any case [09:16] thank god I had the foresight to enable my credit cards in Europe [09:16] otherwise I would have been really screwed [09:17] good thinking :) [09:18] only reason I needed to do it was because I woke up too late :/ [09:18] I missed my shuttle and the next one would have been far too late [09:18] made it to the plane with 10 minutes left on the clock [09:18] 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] I definitely enjoyed being in Germany for the sprint though [09:36] 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] SUSE defines %_libexecdir as /usr/lib, while Mageia defines it as %_libdir [09:37] provided you pass the macro parameters to snapd, it should agree with snap-confine [09:42] Son_Goku: I revertee back to just plain %configure for now [09:42] Son_Goku: we can change it once it actually matters [09:42] right [09:43] afaik, plain %configure should define --libexecdir [09:44] then your autoconf stuff can just automatically install to the subdirectories it creates in %_libexecdir [09:46] yep, rpm -E %configure indicates as much [09:55] cking registering snap names should be instant === chihchun is now known as chihchun_afk [09:56] cking uploads of snaps can get blocked [09:56] cking or did you claim a name [09:56] I claimed a name [09:56] and that's "pending review" [09:57] 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] cking: I can look into that for you, we are still ironing out processes around these things [09:59] noise][, ok, thanks! [10:01] cking: approved! sorry for the delay [10:02] thanks \o/ === chihchun_afk is now known as chihchun [10:07] zyga: https://bugs.launchpad.net/snappy/+bug/1606510 [10:07] Bug #1606510: Interfaces for LXD [10:07] PR snapd#1577 closed: daemon, cmd/snap: refresh --devmode [10:07] Bug #1606510 opened: Interfaces for LXD [10:31] can i upgrade my ubuntu core 15.04 kernel to 16.04 ? [10:31] using ubuntu-core-upgrader ? [10:42] is it possible to use ubuntu-core-upgrader to upgrade an existing ubuntu-corehost using an img file ? [10:45] hades|2, nope [10:46] hades|2, snapd manages upgrades of snap packages ... upgrading the system is just "snap refresh" [10:46] that will upgrade all snap packages including kernel and rootfs [10:47] what is ubuntu-core-upgrader? [10:48] that package that carries do-release-upgrade [10:48] (update-manager for headless systems) [10:48] my host doesnt have snap refresh [10:49] ogra_, is it anything to do with snap? [10:49] nope [10:49] sigh [10:49] it is for classic installs [10:49] starting from 16.04 ? [10:50] Chipaca, would be trivial to make it call "snap refresh" at the end of the upgrade though :) [10:50] but i guess thats kind of pointless given snaps refresh themselves [10:50] ogra_, 15.04 is so long ago, i'm pretty sure 'snap refresh' wasn't a thing then [10:51] what about old ubuntu-core based on vivid/15.04 , how to upgrade to 16.04 ? [10:51] oh, i missed the 15.04 part above [10:51] (just rebooted to switch my session to unity8 ... backklog slipped through) [10:51] hades|2, you cant [10:51] hades|2, wait, are you asking about *snappy* ubuntu core, or classic ubuntu core? [10:51] snappy [10:52] the image setup has changed in incompatible ways [10:52] and we don't have blessed core images yet anyway [10:52] (as has the snap format and other things) [10:52] right, there are no 16.04 images yet ... [10:53] ok thx [10:54] i assume that wont happen anymore though ... series 16 snap images should be upgradeable to series 18 snap installs later on [10:54] 15.04 was kind of special in that regard, nothing was really finalized back thn [10:54] *then [10:55] PR snapd#1580 closed: wrappers: set BAMF_DESKTOP_FILE_HINT for unity [10:55] PR snapd#1586 opened: wrappers: set BAMF_DESKTOP_FILE_HINT for unity [10:55] uh... bamf ... thats still alive ? [10:56] ogra_, as much as unit7 is [10:56] :-) [10:56] heh [10:56] ill reflash a host using a series 16 img then [10:56] ogra_, I think we do want to support 15.04->16 upgrades, but it's definitely not there yet [10:57] hades|2, there are no official 16 core images yet [10:57] Chipaca, yeah, i was talking about 16->18 :) [10:57] so is it safe to keep my current snappy 15.04 host ? [10:58] until we announce official 16 series images you should better keep it, yeah [10:59] using snappy update / snap refresh i might be ablke later on to upgrade "safely" too ? [11:00] hades|2, that is the plan as i understand it [11:00] hades|2, no reverts of that refresh though [11:01] hades|2, or in 15.04 parlance, no rollbacks of that upgrade [11:01] *update [11:01] :-) [11:01] it should be fine for me although [11:17] 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] nope, there is a system service (systemd timer) that does the automated snap refresh runs [11:19] not sure on what schedule that runs on classic installs though [11:19] Chipaca, might know [11:37] PR snapd#1529 closed: snap: rework the output after a snap operation [11:45] sergiusens: could we invoke any parts this way before the npm install takes place? https://www.irccloud.com/pastebin/5m23iw2R/ [11:46] the hook could be preinstall [11:47] 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] Cavan, $SNAP_DATA is not user writable, is that a service or a binary a user would execute ? [11:51] in case of the second you would have to use SNAP_USER_DATA [11:51] (also setting HOME to SNAP if your app tries to write to its home wont work, $SNAP is readonly) [11:58] PR snapd#1563 closed: Interfaces: hardware-observe [12:04] ogra_, So is this how it should be? 'export KARAF_DATA="$SNAP_USER_DATA" export KARAF_HOME="$SNAP_DATA"' [12:05] i would point both to SNAP_USER_DATA actually [12:05] if thats an enduser app that a user executes [12:14] 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] thats $SNAP [12:15] so whatever you use in that mkdir should point to $SNAP_USER_DATA [12:15] (and your config shoul point to that dir) [12:19] PR snapcraft#686 opened: Add missing dependencies [12:27] 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] yeah [12:28] ogra_, anychance you could check out my stack overflow quickly if I link it? [12:29] sure, just paste it on paste.ubuntu.com [12:30] ogra_, thanks http://paste.ubuntu.com/20997635/ [12:31] ogra_, it hasnt been updated since you told me thye should both have SNAP_USER_DATA, so assume they're there [12:31] heh [12:31] i thoght you had a stak to look at, sorry [12:32] that wouldnt have needed a pastebin :) [12:32] 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] PR snapd#1587 opened: store: deal with 404 froms the SSO store properly [12:34] Cavan, have a look at https://github.com/ogra1/jtiledownloader [12:34] that ships a wrapper script [12:35] (though this executes a jar ) [12:36] so far your wrapper looks ok though [12:36] so what happens if you try to run it ? [12:42] zyga, uuuh, is the base snap still public in the store ? can you please unpublish it ? [12:42] ogra_, basically when I try to run the ./karaf I get [12:42] 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] when you run ./karaf ? [12:43] you mean you execute something inside $SNAP manually ? [12:43] that cant work [12:44] you need to use /snap/bin/karaf ... or just karaf ... (since /snap/bin should be in your PATH( [12:44] 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] else you miss one layer of wrappers [12:45] well, try /snap/bin/karaf ... see what that does [12:45] PR snapd#1579 closed: snapstate: add daemon-reload to fix autopkgtest on yakkety [12:46] ogra_, I get the same result [12:54] Cavan, well, the mkdir errors look like your wrapper has not been updated [12:55] the mkdir seems to still point to the wrong dir [12:56] Cavan, are you use the karaf binary actually uses these $KARAF_* vars at all ? [12:57] or does it just try to write to ./ by default [12:57] then you would need to add a "cd $SNAP_USER_DATA" to your wrapper before the exec line [12:58] 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] well, the binary doesnt seem to use the vars ... [12:59] try the cd ... that might work around it [13:00] ogra_, Okay, do I literally put it the line before the exec? [13:00] a line above the exec line, yes [13:06] 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] well, that is if you execute /snap/bin/karaf ? [13:07] (literally that string) [13:07] No, thats if I execute /snap/bin/wrapper [13:07] uh [13:07] dont [13:08] and how did wrapper get into /snap/bin ? [13:08] your wrapper should live inside your snap ... not in the /snap/bin system dir of your host system [13:09] When I've looked at online examples a few have created wrappers in the /bin, is that incorrect? [13:09] as i said before, when you install the snap there are more layers of wrappers added automatically [13:09] the top level wrapper (according to your snapcraft.yaml) will be /snap/bin/karaf [13:10] and only that is what you should ever execute [13:10] PR snapd#1582 closed: debian: move snapd.refresh.timer into timers.target [13:10] do not exec anything in /snap/karaf/$version/ directly [13:10] that can not work [13:12] 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] you should install the wrapper where your snapcraft.yaml expects it [13:13] looking at your stackoverflow post it is all correct [13:13] just leave it like that [13:13] just dont try to runanything else but /snap/bin/karaf [13:14] If I do that I get this though '/snap/bin/karaf: No such file or directory' [13:15] that cant really be ... your snapcraft.yaml defines it [13:15] if you built your snap with that snapcraft yaml and snap installed it this commmand must be there [13:16] i'll install it again to make sure [13:16] oh [13:16] wait ! [13:16] Okay [13:16] why do you define "daemon: simple" [13:16] thats for system daemons ... and will definitely not create the user binary in /snap/bin [13:16] What should I do instead? [13:16] but will instead create a systemd unit and install it [13:17] just drop that one line [13:17] and rebuild your snap [13:17] (unless indeed ... your app is actually a system daemon) [13:17] (but then you cant start it ... systemd will handle it) [13:17] s/start/run it as a user/ [13:18] So I'm re-installing it back to my Stackoverflow post and dropping that one line correct? [13:18] yes [13:19] if karaf is actually something a user can run then thats the right way [13:32] 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] you might need to set some app options then ... [13:33] you said something about EXTRA_JAVA_OPTS above [13:33] Bug #1606574 opened: SSH Interface is missing [13:33] 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] should I get the MakeFile to install the .jar? [13:34] well, if you have a jar, just look at my jtiledownloader branch (linked above) [13:34] that should get you going [13:35] ogra_, thanks so much for your help, although you'll probably be hearing from me soon with another problem aha [13:36] heh, well, good luck for now [13:40] jdstrand: on #1592696 I think you meant 16.04 not 14.04 :-) [13:40] Bug #1592696: snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied

Xenial):Incomplete> [13:41] I think it's fixed on new snap-confine [13:42] 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] PR snapd#1585 closed: store, daemon, client, cmd/snap, docs/rest.md: adieu search grammar [13:52] hmm [13:53] so how do i access any packages owned by the shared store account now that it is locked [13:53] i know all packages were shared with me ... [13:53] but i dont see them in my myapps.d.u.c page [14:00] ogra_: I cannot, I didn't publish it [14:00] zyga, crap ... and i cant see it and the shared account is locked down [14:01] zyga, is mvo anywhere near you ? he might know [14:05] ogra_: I bet he did it [14:05] did what ? unpublish ? [14:05] i still find it with snap find [14:05] morning all [14:06] 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] but my myapps page simply doesnt show it [14:09] PR snapd#1588 opened: tests: added spread find private test [14:09] Bug #1605003 changed: cannot communicate with server - openSUSE Tumbleweed [14:10] Chipaca: yes, thanks [14:12] ogra_: I'm sorry, I don't know that; I never used the shared account [14:12] zyga, well ... [14:12] jdstrand: hey, we will need to have snapd manage groups and users [14:12] jdstrand: for the case of lxd [14:13] jdstrand: so that ldx snap will be able to create the ldx socket that is not world writable [14:13] jdstrand: I'm just letting you know [14:14] * ogra_ vomits [14:14] so mvo tied all the shared packages to ogra@canonical.com ... which is not assigned to my U1 account at all [14:15] O.o [14:15] 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] (it considers the webbrowser appp as not capable to use captchas ... sigh) [14:16] so silly [14:19] * Pharaoh_Atem sighs [14:20] zyga: looks like F25 branching is starting [14:20] 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] time to prepare for messages about my entire world branching for F25... [14:24] hi snappers [14:25] 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] ogra_ heh, oSoMoN has a bug for that already [14:26] great [14:27] hmpf ... so i see a "core" package that was shared with all of us ... but there is no "base" package anywhere [14:27] and that core package is also unpublished properly [14:28] MVOOOOO !!! [14:29] Cavan, well, you dont want to extract it ... look at my jtiledownloader snap [14:29] (i gave you the github url above) [14:29] just copy the exec line and replace my jar with yours in there [14:31] 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] zyga: tyhicks and I should be involved in the designs surrounding adding groups to the system via snaps [14:31] uh [14:32] zyga: and possibly a memnber of foundations (slangasek or someone he assigns) [14:32] adding system groups sounds slightly scary with libnss-extrausers in place and using a readonly /etc/groups [14:33] (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] (it would just come with the next oos snap update) [14:34] *os [14:34] it indeed sounds scary since it would be easy for a snap to pick a group to add (eg, 'ogra') [14:34] well, not only that [14:34] you dont know what comes down the drain from the store [14:34] so maybe it wouldn't be arbitrary groups, but rather, the snappy interface says (ok, we'll set up this group) [14:34] so you cant really predict if a GID will clash [14:34] ogra_: mvo isn't even here, so he can't really hear you.... :/ [14:35] 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] any body [14:36] with some idea on native apps in jquery+php+html experience [14:37] 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] but thats fiddly to implement for sure [14:45] any body with ubuntu cloud here [14:58] Pharaoh_Atem: hey [14:58] Pharaoh_Atem: why do you have two IRC nicknames [14:58] zyga: yo [14:58] this self is my workstation at work [14:58] my other self (Son_Goku) is my laptop [14:58] Pharaoh_Atem: I've updated the snap-confine.spec [14:59] Pharaoh_Atem: pushed updates to fedorapeople [14:59] this guy is persistent, the other one shows up when I'm away :) [14:59] Pharaoh_Atem: magic :) [14:59] Pharaoh_Atem: should I just indicate the changes on the bug report? [14:59] yes [14:59] always do that, as it's for the benefit of me, you, and others potentially watching [14:59] Pharaoh_Atem: you can also check what I did by looking at github (for all the real details) [14:59] ok, will do [14:59] right [15:05] 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] you need to create the buildroot override [15:07] https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages [15:07] it would automatically be in effect for builds you do from your user with koji (via fedpkg) [15:08] you should be able to build from F25 and Rawhide with no problems, though [15:08] since both will have check in there already [15:10] stevebiscuit: why don't you ship your patched go plugin in snapweb in parts/plugin/x-go.py ? [15:10] that way we don't have to wait for a new release. [15:12] zyga: I've approved snap-confine [15:13] Pharaoh_Atem: I'll do the change to the remaining two pkgconfig files [15:13] Pharaoh_Atem: I'm somewhat exhausted by the sprint and I'm very glad and I very much appreciate your detailed review [15:14] elopio: that's an option, I'd already mentioned godeps to kyrofa and he created the bug on LP [15:17] zyga: that's why we do these in Fedora :) [15:17] one more set of eyes tends to help at times [15:18] Pharaoh_Atem: I hope to get more so that we can have a day off sometime ;) [15:22] Pharaoh_Atem: I'll work on fedpkg builds now [15:22] Pharaoh_Atem: but it does look like we are down to snapd now :) [15:22] Pharaoh_Atem: I didn't check go-flags yet, is the update also going to f23+? [15:22] yes [15:22] it's going everywhere [15:22] that's good then [15:23] We had a release just now, 2.11 :) [15:23] zyga: https://bodhi.fedoraproject.org/updates/?packages=golang-github-jessevdk-go-flags [15:23] I'll do COPR but I'm super happy I will be moving closer to fedora :) === dpm is now known as dpm-afk [15:23] you can try out those packages and see if they work [15:23] Pharaoh_Atem: nice, I see [15:23] and leave feedback :) [15:23] Pharaoh_Atem: yes, I will download them [15:23] Pharaoh_Atem: is there a better way rather than just to get them from bodhi? [15:24] Pharaoh_Atem: I will build against it in my local repo [15:24] http://koji.fedoraproject.org/koji/packageinfo?packageID=20509 [15:25] you grab them from Koji [15:25] looks like an override is already in place for go-flags [15:25] it might "Just Work" [15:25] * Pharaoh_Atem shrugs [15:34] tsimonq2, heard of KDE Connect? [15:34] ahoneybun: no clue what it is [15:35] you can send and recieve files between phone and PC [15:35] also control mouse and keyboard [15:35] it pulls a lot in from KDE in Libs [15:35] so it would be cool to snap it [15:45] 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] ogra_: WAT [15:48] I mean, not ogra_. [15:48] Cavan: That is very very wrong. [15:49] qengho, which part, the exec? [15:49] or the return im getting from the terminal? [15:49] 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] Cavan: So, "exec jarfile" is wrong. [15:51]