[00:16] PR snapcraft#733 opened: Add the go-buildtags property to the go plugin [01:59] PR snapcraft#724 closed: In travis, install the static checkers with pip [02:50] PR snapcraft#729 closed: Dump plugin: Don't remove install directory [02:53] PR snapcraft#732 closed: Remove store dispute logic [03:19] :( Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing. === JanC is now known as Guest33791 === JanC_ is now known as JanC === chihchun_afk is now known as chihchun === PatrizioQON is now known as pbek === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:23] has anyone used "snapcraft cleanbuild" to build a snap project? I tried to build a simple project. However, I got many errors like http://paste.ubuntu.com/23063560/, what could be the root cause of it? Should I set up LXD seperately? [06:30] Hello are snappy avaliable for rpi3? [06:50] does anyone know how to invoke the "stop command" in a snap application? thanks [06:54] I have a daemon app in my snap, I can use the app's name to launch the app. I also define a "stop-command" to stop the daemon. The problem is what is the correct syntax to invoke the "stop-command" to stop the deamon. thanks [07:03] liuxg: you need to use systemctl for this [07:03] liuxg: I don't think snap reimplemented an easy way to start/stop command yet [07:04] didrocks, yes, that is currently what I am doing. still I want to try the stop command to get it working [07:04] didrocks, I think it is more direct from user point of view. [07:04] liuxg: on the cleanbuild issue, it seems to me that your lxd apt database didn't apt update recently. I thought snapcraft cleanbuild would do that on each build, sergiusens ^ [07:04] didrocks, what is the correct syntax to invoke a stop command. [07:05] liuxg: use the "systemctl stop" command (as you are currently doing, right?) [07:05] didrocks, do you mean that "systemctrl stop" will invoke the "stop" command? [07:06] liuxg: hum, it seems you don't know this command, what did you mean with "that is currently what I am doing"? [07:06] didrocks, what I found was that I could use that to stop the daemon even if I did not specify the "stop-command". if that is the case, what is use of the definition of "stop-command"? [07:07] liuxg: it's to enable having systemd stopping your daemon using that command [07:07] instead of just killing it [07:08] liuxg: ok, so to use systemctl, you need to have the name of the generated .service file [07:08] for this, ls /etc/systemd/system/** [07:08] didrocks, I could use the "systemctrl stop snap.xxxx.xxx" to stop a daemon app in any case without defining the "stop-command". I am wondering what is the purpose of "stop-command" defined in the snapcraft.yaml. [07:08] -> you will get a .service filename [07:08] then, systemctl stop [07:08] right, so: [07:08] if you don't mention a stop-command, systemd will just kill your process [07:08] to "stop" it [07:09] sometimes, some services needs to do better cleanup [07:09] like closing a database and such [07:09] and they have a different command to stop itself [07:09] in that case, use stop-command to point to this command [07:09] and systemctl stop <…> will just invoke this command to stop the daemon [07:09] didrocks, my question is whether it will invoke my defined stop command "stop-command: bin/wrapper　stop" if I use "systemctrl stop xxx" [07:09] (and kill it after a timeout) [07:09] (if it didn't get kill) [07:09] liuxg: that's what I just answered above $ [07:11] didrocks, OK. so, if we do not define a "stop command", the daemon will be forcefully shut down. if it is defined, it will just call "stop command" to gracefully shut down by using the command "systemctrl stop". [07:12] liuxg: exactly! However, in the second case, if the daemon isn't shutdown by the "stop" command your provided after a $timeout time, it will force-kill it [07:12] you* [07:12] didrocks, got it. thanks! [07:12] yw :) [07:15] didrocks, did you successfully build a snap project using "snapcraft cleanbuild" command? I did not succeed it. [07:20] liuxg: it works for me [07:20] liuxg: see my answer above about your issue [07:21] didrocks, I am wondering whether it works out of the box, or I need to set sth up first before to get it working. [07:34] liuxg: apart from lxd init, nothing, and the container starts for you, so it's not this [08:51] * kalikiana <3 snapcraft cleanbuild [09:16] btw cleanbuild is also good for cases where a build system is "smart" and pulls in dependencies you didn't expect, my nvim suprisingly doubles in size with a 'regular' build because it pulls in libxml which drags icu in - if anyone is wondering about that, it's worth considering that causality === chihchun is now known as chihchun_afk [09:17] icu aka "I grok unicode" [09:17] sadly the alternative is "I live in the 80s" [09:18] it's not meaingful for the use case - universal-ctags is pulling it in and I'm pretty sure I don't require unicode there [09:19] the "good old" exuberant ctags in the archives isn't using it either [09:19] perhaps, my comment was generic, icu is just large but we have to live with it [09:19] yeah, for cases where it is more or less the only option it's unfortunate === chihchun_afk is now known as chihchun [09:51] reading /kernel.img [09:51] ** Unable to read file /kernel.img ** [09:51] reading /initrd.img [09:51] ** Unable to read file /initrd.img ** [09:51] Bad Linux ARM zImage magic! [09:52] :( [09:53] * zyga hugs ogra [09:53] no mvo :( [09:54] seems tonights auto-upgrade did completely unset snap_kernel in my bootloaders [10:01] zyga, do you know if he is off today ? [10:01] ogra_: he's around, he's away for a few hours now [10:11] zyga: awesome thanks man [10:12] stokachu: I talked to mvo about this and we're going to SRU this ASAP, we're also re-considering the chroot approach now, this is not a simple thing so don't expect a decision overnight (like the patch :) [10:12] stokachu: I will do 1.0.40 release in a moment and work on the SRU with mvo [10:13] zyga: understood [10:14] stokachu: if you want you can try to build it now and test that it fixes the issue [10:14] stokachu: take master and packaging from https://code.launchpad.net/~snappy-dev/snap-confine/+git/snap-confine/+ref/16.04 [10:15] zyga: ok, ill do a local build and give it a run [10:15] (packaging will change a little when mvo is back, we want to integrate his packaging work that was never committed) [10:15] I'll keep you posted :) [10:16] zyga: hey [10:16] zyga: great, thanks! [10:16] mvo: hey, welcome back :-) [10:17] mvo: FYI, I've modelled packaging after fedora-scm a little, I think the approach is great (branch per distro series) and simple to work with, the content is entirely up to us [10:17] mvo, all my boards fell apart today with no snap_kernel set at all after reboot [10:17] * zyga is working on fedora now [10:18] (seems they did their auto-upgrade ... when i rebooted them all _kernel vars were completely unset) [10:18] mvo, i suspect there is some quoting issue [10:19] ogra_: yeah, same bug, I do new image [10:19] s [10:19] ogra_: let me do that rightnow [10:19] mvo: ping me on telegram when you have a moment to help me with the SRU process for snap-confine [10:19] (in private so that I get notified please) [10:19] mvo, seems when i change the script like: http://paste.ubuntu.com/23064119/ it doesnt fall over [10:19] Son_Goku: hey, still no selinux support, spent last night fire-fighting, I'm doing package builds and uploads now [10:20] (using test -n and no quoting for teh vars, the hush shell in uboot is very picky about such stuff IIRC) [10:20] Son_Goku: when I'm dong with snap-confine uploads I will try to integrate fedora into upstream CI [10:20] hmm, no, i take that back [10:21] it works exactly for one boot [10:21] so there is something else [10:21] (nontheless that script variant is cleaner :) ) === chihchun is now known as chihchun_afk [10:23] * zyga uploads snap-confine to rawhide :) [10:25] ogra_: hm, ok [10:25] ogra_: can you dump the environment when it fails? [10:26] Son_Goku: I'd like to get a neutered version of snapd reviewed, without active systemd units [10:26] mvo, well, the change is that snap_kernel is completely nonexistant then [10:26] Son_Goku: and initially just for f23 where systemd is not confined with selinux [10:26] Son_Goku: then work on making initial selinux changes for snapd.socket [10:26] ogra_: snap_kernel="" or not there at all? [10:26] Son_Goku: that should unblock f24 and f25 [10:26] not there at all [10:26] Son_Goku: and then apply for the remaining permissions [10:27] Son_Goku: let me know if this makes sense to you [10:27] ogra_: interessting, let me check the code [10:27] zyga, you should apply for all of the branches anyway [10:28] keep in mind you can build for all of the targets without actually submitting something as an update [10:28] Son_Goku: ack, I meant that initially just f23 will work [10:28] oh, that's true! [10:28] those are two separate actions for a reason [10:28] mvo, if only one of snap_try_kernel or snap_try_core is set it seems the other one completely vanishes ... i just manually did set snap_mode try and snap_try_kernel and got: [10:28] ubuntu@dragonboard:~$ fw_printenv |grep ^snap_ [10:28] snap_kernel=dragonboard-kernel_1.snap [10:28] ubuntu@dragonboard:~$ [10:29] zyga, adding branches later requires you to go through re-reviews, which are annoying :P [10:29] ogra_: meh, indeed, I think I found the issue [10:29] so just add them now, and once you're happy, you can submit an update for F24 [10:29] ok [10:30] ogra_: I will work on a fix and see what can be done about automatic tests, we currently have no reboot spread test but maybe I can find something else [10:30] mvo, didnt leos setup have reboot tests ? perhaps we can use that for the moment [10:31] zyga, I would just submit to all branches and everything, and just not do fedpkg update until you're ready [10:32] ogra_: yeah, I explore that a bit [10:33] Son_Goku: yep, I'll do that, just doing the macaroon and snap-confine work now [10:34] seb128, hmmm ... [10:34] ogra_, hey, issues with my livecd-rootfs upload? [10:35] seb128, only that they wont affect any ubuntu-core builds :) ... we a) only build xenial and b) the livecd-rootfs we use lives in a build PPA [10:35] (it is good that you land it in yakkety for completeness though) [10:35] ogra_, well, trunk first ... but thanks for pointing it out, who do I bribe to get that ppa updated? [10:36] me or mvo [10:36] i'll take a look in a moment [10:36] who wants beer in octobre? ;-) [10:36] danke! [10:36] haha [10:39] seb128, hmm, i think your "no-apt" change is wrong (looking at http://launchpadlibrarian.net/279413400/livecd-rootfs_2.424_2.425.diff.gz) [10:40] seb128, if you remove the "cat < Hello! Please, tell me, can I run script before autotools plugin run? e.g. ./bootstrap.sh? [10:40] ubuntu@dragonboard:~$ apt [10:40] Ubuntu Core does not use apt-get, see 'snappy --help'! [10:40] ubuntu@dragonboard:~$ cat /usr/local/bin/no-apt [10:40] #!/bin/sh [10:40] cat < Ubuntu Core does not use apt-get, see 'snappy --help'! [10:41] ogra_, that was a dupliucate EOF [10:41] code now is [10:41] cat >$PREFIX/usr/local/bin/no-apt < #!/bin/sh [10:41] Ubuntu Core does not use apt-get, see 'snappy --help'! [10:41] EOF [10:41] oh [10:41] :) [10:41] you are right [10:41] shrug [10:41] sorry about that ;-) [10:42] if you want to fix it feel free [10:42] there is definitely a bug that the EOF is missing in the resulting script [10:42] I can fix for trunk after lunch [10:42] just add the echo [10:42] but apparnely cat doesnt really care at runtime :) [10:43] the xdg-open has a similar prob ... though there i dont understand the logic at all ... i wonder why it wants the cat in the script there [10:44] the xdg one is fine [10:44] the goal is to generate a file on disk [10:45] cat >$PREFIX/usr/local/bin/xdg-open < #!/bin/sh [10:45] dbus-send --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"\$1" [10:45] EOF [10:45] right, i just wonder how it got like that [10:45] if you sh that you get the 3 lines writen to $PREFIX/usr/local/bin/xdg-open [10:45] seems it was just a blind copy of the no-apt one [10:45] right [10:45] well the new version works I tested it [10:45] dbus-send is a cmd [10:46] but you are right about the other one missing the echo [10:46] lunch now, bbiab [10:49] zyga, uhh what did you do?! [10:50] patches aren't supposed to be recorded in sources [10:50] they go into git itself [10:50] no one can read anything in the binary repo [10:52] zyga, did you approve my co-maintainer request for snap-confine? [10:52] https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/ [10:53] oooh [10:54] Son_Goku: I didn't see the request yet, looking now [10:54] Son_Goku: how should I record the patch? [10:54] git add? [10:54] Son_Goku: I see, let me correct that quickly [10:55] done (commit access) [10:56] zyga, also, delete from "sources" the entry for the patch file [10:56] you don't want that there [10:56] PR snapd#1690 opened: partition: ensure that snap_{kernel,core} is not overriden with an empty value [10:56] and you'll want to bump the changelog for the spec too [10:56] since you can't rebuild in koji without doing that [10:56] Son_Goku: yep, should I bump the spec file for that? [10:56] ah [10:56] ok [10:57] oh, and in the changelog [10:57] do "%%license" instead of "%license" [10:57] because otherwise, it'll process it and weird things happen [10:57] like this: "- Use GPLv3 instead of %doc for COPYING" [10:57] Fixed [10:58] ooh [10:58] %%license but %doc? why? [10:59] Son_Goku: like this? [10:59] -%license COPYING [10:59] +%%license COPYING [10:59] yes [10:59] no [10:59] :D [10:59] not in the actual %files list [10:59] in the changelog, it's actually processing the %license macro (which evaluates to the License field in the preamble) [10:59] ahh [11:00] the files list is fine [11:00] so the changelog entry can look like [11:00] but the changelog isn't [11:00] - Use %%license instead of %%doc [11:01] yep [11:01] k, thanks for spotting that! [11:02] Son_Goku: pushed to master, let me know if this is good for fedpkg build [11:02] zyga, no prob [11:03] looks good to me [11:04] merge it into all your other branches and go forth and build :) [11:05] ogra_: fwiw, branch pushed with fix for your bug [11:05] yep, do I need to fedpkg update again? [11:08] Son_Goku: I need a break, I'll do subsequent updates depending on your answer when I'm back from a walk [11:08] ok [11:10] PR snapd#1598 closed: interfaces: implement a fuse interface [11:16] zyga, I'm going to just modify your existing update to use snap-confine-1.0.30-2.fc23 [11:20] zyga, you should submit snap-confine to F24 and F25 as updates, too [11:20] there's no reason not to [11:32] Question: Is there a known fix for "/usr/bin/env bad interpreter: Permission denied"? I don't know if I should be changing my shebangs to work within confined snaps or file a bug [11:32] Those same scripts work perfectly if I "sh foobar" them [11:43] kalikiana, you want to change the interpreter [11:43] i mean, the shebang [11:43] jdstrand, is there a reason not to allow /usr/bin/env in the default profile? [11:44] kalikiana, just for the record with very few exceptions you should be shipping the interpreter also [11:44] kalikiana, the exceptions might begin and end with "sh" [11:44] kalikiana, I do ship something that abuses things a little by using system's python3, but that's because I'm ok with it breaking [11:45] In this instance I'm indeed using "!/usr/bin/env sh" [11:46] python also appears to be functional - I haven't decided yet what to do with that wrt bundling, it would blow up the snap incredibly so I didn't upload a version with it enabled [11:47] also optional modules - I'm thinking a way to pull in modules to $HOME would be nice, but there's no obvious way to do that [11:48] by nature nvim is extensible so I have to ultimately find something that allows on demand installing [11:51] kalikiana, using env (which isn't guarnateed to be in /usr/bin, in fact only debian-derived have it there afaik) to find something that is guaranteed to be in /bin is a little twisted, just ftr [11:52] kalikiana, the question of why it isn't executable in the default apparmor profile is for jdstrand (i assume it's apparmor blocking this) [11:52] kalikiana, optional modules sounds like something for the content interface [11:53] Chipaca: fwiw "!/bin/sh" doesn't work either. I at one point got the impression that env would allow me to stop hard-coding executable paths - but then, if I don't know where env is, how can I possibly do that? [11:56] kalikiana, wat [11:56] kalikiana, #!, right? [11:57] Yes, sorry, I typed it here by hand [11:57] kalikiana, #!/bin/sh certainly should work [11:57] It doesn't [11:57] i mean, hello-world uses that [11:57] lemme copy a script in there and try [11:59] Hmmm it does indeed [11:59] Is hello-world unconfined? [12:00] Hmm no it's not according to "snap list" === chihchun_afk is now known as chihchun [12:03] kalikiana, any denials in syslog ? [12:07] jdstrand: re: the custom network bridge, normally I have a person install my debian package that sets up a systemd service with my bridge scripts, https://github.com/Ubuntu-Solutions-Engineering/openstack-deb, with the network-control interface am I able to do the same thing inside my snap? [12:08] minus the deb package of course [12:08] ogra_: http://paste.ubuntu.com/23064305/ Several of the second one with different /proc/*/cmdline [12:09] mvo, do you mind if i switch it to "test -n" instead of '!= ""' ? [12:09] mvo: whats the status on verifying bug 1612362 ? I think the postrm purge issue was fixed in teh latest upload, but it just hasn't been verified yet? [12:09] Bug #1612362: [SRU] 2.12 [12:10] ogra_: Chipaca Aha! It works if the script is in $SNAP_USER_DATA but not if it's in $HOME [12:10] Despite having the 'home' interface [12:11] kalikiana, the first one tries to exec something outside of the snap without having an interface for it ... and for the second one there is an interface iirc [12:11] system-observe or some such [12:11] or process-observe ... i forgot the exact mname [12:12] is it possible to install a systemd service during snap install? [12:13] stokachu, snapd does that, based oon the info you give it in snapcraft.yaml [12:13] you cant randomly copy unit files in place though [12:13] ogra_: i basically want to convert https://github.com/Ubuntu-Solutions-Engineering/openstack-deb [12:14] ogra_: the first one is 'home' isn't it? the same script can be opened and run by hand with "sh ./able" [12:14] ogra_: and have that bridge setup during install [12:14] ogra_: sure, thats fine [12:14] stokachu, so creat bridge start and stop scripts and add app entries (with daemon line) into your snapcraft.yaml that points to them [12:15] kalikiana, home only allows file access ... not execution of random binaries ;) [12:15] ogra_: ok, will the bridge be uninstalled on snap remove? [12:15] as long as i have the stop app in there? [12:15] arges: yeah, we just need to verify this one, the postrm changed got backed out again they will be properly fixed in the next upload [12:15] arges: I will ask our QA team to do the verification [12:15] ogra_: Hrm. Well, I could copy and run the same file - so I'm not sure I see the effective difference. [12:15] stokachu, not sure, thats a question for Chipaca i guess ... iirc we stop all services on removal though [12:16] ok [12:16] kalikiana, run ? how ? [12:16] ogra_: As I said prepending "sh" or "python3" in case of Python works perfectly [12:17] ogra_: Or copy and run as-is [12:17] that actually sounds like a slight security hole [12:17] ogra_: How would executing the script only after copying it into $SNAP_USER_DATA be more secure? [12:17] It certainly is inconsistent [12:18] well, the home interface only gives you access ... allowing the exec is a general thing when it happens inside the confined space [12:18] which home doesnt belong to [12:19] I guess I should be symlinking my script folder into the snap? [12:19] i guess the home interface should block "sh $HOME/myscript.sh" [12:19] which is why i think there is a bug [12:20] jdstrand, ^^ [12:23] how can i clear snapcrafts apt cache? [12:23] snapcraft clean [12:23] doesnt work :( [12:23] huh ? [12:24] that definitely wipes it [12:24] https://www.irccloud.com/pastebin/5eZy8hNO/ [12:24] ogra_: ^ [12:24] Son_Goku: thanks for bumping bodhi tasks [12:25] zyga, you still need to make the updates for F24 and F25 [12:25] I could do it, but I figured you'd want to [12:25] stokachu, yes, systemd services are stopped on snap removal [12:25] stokachu, i see it running apt-get update there [12:25] Chipaca: cool thanks [12:25] stokachu, asked to stop, then made to stop [12:25] stokachu, looks more like a server side issue [12:26] Chipaca: how will it know to run bridgestop on removal? https://www.irccloud.com/pastebin/saEdO7ro/ [12:26] i.e. like the server is just regenerating its Packages file [12:26] ogra_: ok ill give it a few [12:26] zyga, by the way, you can change the positive karma number to be lower [12:27] I usually set positive karma to be "1" rather than "3" for new packages [12:27] Son_Goku: ack, noted [12:27] Son_Goku: I'll do that for subsequent updates [12:27] stokachu, i guess it will run both ... "bridge.start stop" and "bridge.stop stop" [12:27] stokachu, stop-command and stop-timeout [12:27] zyga, you can edit the update in bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2016-939c94b72e [12:27] Chipaca: do i need to set that somewhere? [12:27] stokachu, you should work it into a single script that understandds the systems start/stop events [12:27] *systemd's [12:28] zyga: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5556c3bef [12:28] ogra_: ah [12:28] there should be an edit button if you're logged in [12:28] stokachu, without looking i don't remember; what happens if you try to stop without having that there? [12:28] trying [12:28] stokachu, in any case, you *can* set those, next to "command", you add "stop-command" [12:28] and you can modify the conditions of the update :) [12:28] Chipaca: actually haven't ran it yet :) waiting for apt packages to work again [12:28] as well as the update description and other things [12:28] Chipaca, well, he has one start service and one stop service ... and both will receive a stop event on uninstall [12:29] it's also possible to create updates from the bodhi web UI, which makes it easier to bundle a bunch of updates together in one update [12:29] I see it, changed to stable karma: 1 [12:29] stokachu, having a stop service seems weird [12:29] Chipaca, so i guess he wants a single script that simply can handle start and stop so on uninstall only stop is called (and on install or reboot start is called) [12:29] stokachu, i suspect it's not what you want [12:30] Chipaca, he wants the firewall settings the script applies system wide reverted on uninstall [12:30] Chipaca: ok, i was trying to port over https://github.com/Ubuntu-Solutions-Engineering/openstack-deb/blob/master/debian/openstack.service [12:30] stokachu, that is, i suspect you want a single bridge: \n command: bridge.start \n stop-command: bridge.stop [12:30] yeah [12:30] ohhh [12:30] Son_Goku: thanks :) [12:31] once you have snapd in Fedora, in the future when you update snapd and snap-confine at the same time, you can do it as a single update [12:31] Chipaca: this look correct? https://www.irccloud.com/pastebin/4PAbzoN3/ [12:31] Son_Goku: I'd like to merge those packages whenever we have a moment [12:34] stokachu, maybe. Is "bridge.start" really a "simple", and not a "oneshot"? [12:34] stokachu, if it does something and exits, and says it's a "simple", it'll get run again and again and again and again and again [12:34] and again and again and [12:34] Chipaca: ah ok [12:34] zyga, so what do you need to get snapd in good shape? [12:35] stokachu, and again :-op [12:35] Chipaca: :D [12:35] Son_Goku: I need to figure out how to build against the macaroon before it ships in stable [12:35] build against rawhide for now [12:35] Son_Goku: I'd like to simplify the package to strip the services that need permissions to be in fedora [12:35] everything is just there [12:36] when doing mock builds, just attach "-r fedora-rawhide-x86_64" [12:36] before the name of the SRPM [12:36] Son_Goku: I need to fix systemd selinux as we talked about, that will eat most of my time I suspect [12:36] Son_Goku: ok [12:36] Son_Goku: thanks, I'll try that [12:36] Son_Goku: I'll update COPR first so that I have a feeling for everything mostly working [12:36] once rawhide resyncs and the mirrors have your new builds, that should work [12:37] Son_Goku: just having lunch now :) (mushrooms all week) [12:38] as for your copr, you can probably get away with deleting all the golang packages now [12:38] since they've all shipped to stable [12:39] so the only thing in your copr you'll need is the new golang package (macaroon), snap-confine, and snapd [12:39] Son_Goku: yep, I was planning on doing that [12:39] though, if I give snap-confine karma, it'll just go through, probably :P [12:39] Son_Goku: copr can stay for snap* packages but I doubt it will need much more [12:40] heh :) [12:40] (just do it ;) [12:40] technically, I need to wait for it to sync to updates-testing first [12:41] otherwise it won't get marked for stable when I give it karma [12:41] Chipaca, ogra_: this is the error im getting when attempting to install https://www.irccloud.com/pastebin/WbQ5M6Ke/ [12:41]