| mup | PR snapcraft#733 opened: Add the go-buildtags property to the go plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/733> | 00:16 |
|---|---|---|
| mup | PR snapcraft#724 closed: In travis, install the static checkers with pip <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/724> | 01:59 |
| mup | PR snapcraft#729 closed: Dump plugin: Don't remove install directory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/729> | 02:50 |
| mup | PR snapcraft#732 closed: Remove store dispute logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/732> | 02:53 |
| lpotter | :( Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing. | 03:19 |
| === 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 | ||
| liuxg | 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:23 |
| wimzei | Hello are snappy avaliable for rpi3? | 06:30 |
| liuxg | does anyone know how to invoke the "stop command" in a snap application? thanks | 06:50 |
| liuxg | 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 | 06:54 |
| didrocks | liuxg: you need to use systemctl for this | 07:03 |
| didrocks | liuxg: I don't think snap reimplemented an easy way to start/stop command yet | 07:03 |
| liuxg | didrocks, yes, that is currently what I am doing. still I want to try the stop command to get it working | 07:04 |
| liuxg | didrocks, I think it is more direct from user point of view. | 07:04 |
| didrocks | 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 |
| liuxg | didrocks, what is the correct syntax to invoke a stop command. | 07:04 |
| didrocks | liuxg: use the "systemctl stop" command (as you are currently doing, right?) | 07:05 |
| liuxg | didrocks, do you mean that "systemctrl stop" will invoke the "stop" command? | 07:05 |
| didrocks | liuxg: hum, it seems you don't know this command, what did you mean with "that is currently what I am doing"? | 07:06 |
| liuxg | 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:06 |
| didrocks | liuxg: it's to enable having systemd stopping your daemon using that command | 07:07 |
| didrocks | instead of just killing it | 07:07 |
| didrocks | liuxg: ok, so to use systemctl, you need to have the name of the generated .service file | 07:08 |
| didrocks | for this, ls /etc/systemd/system/*<yoursnapname>* | 07:08 |
| liuxg | 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 |
| didrocks | -> you will get a .service filename | 07:08 |
| didrocks | then, systemctl stop <thisservicefilename> | 07:08 |
| didrocks | right, so: | 07:08 |
| didrocks | if you don't mention a stop-command, systemd will just kill your process | 07:08 |
| didrocks | to "stop" it | 07:08 |
| didrocks | sometimes, some services needs to do better cleanup | 07:09 |
| didrocks | like closing a database and such | 07:09 |
| didrocks | and they have a different command to stop itself | 07:09 |
| didrocks | in that case, use stop-command to point to this command | 07:09 |
| didrocks | and systemctl stop <…> will just invoke this command to stop the daemon | 07:09 |
| liuxg | 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 |
| didrocks | (and kill it after a timeout) | 07:09 |
| didrocks | (if it didn't get kill) | 07:09 |
| didrocks | liuxg: that's what I just answered above $ | 07:09 |
| liuxg | 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:11 |
| didrocks | 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 |
| didrocks | you* | 07:12 |
| liuxg | didrocks, got it. thanks! | 07:12 |
| didrocks | yw :) | 07:12 |
| liuxg | didrocks, did you successfully build a snap project using "snapcraft cleanbuild" command? I did not succeed it. | 07:15 |
| didrocks | liuxg: it works for me | 07:20 |
| didrocks | liuxg: see my answer above about your issue | 07:20 |
| liuxg | 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:21 |
| didrocks | liuxg: apart from lxd init, nothing, and the container starts for you, so it's not this | 07:34 |
| * kalikiana <3 snapcraft cleanbuild | 08:51 | |
| kalikiana | 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 | 09:16 |
| === chihchun is now known as chihchun_afk | ||
| zyga | icu aka "I grok unicode" | 09:17 |
| zyga | sadly the alternative is "I live in the 80s" | 09:17 |
| kalikiana | 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:18 |
| kalikiana | the "good old" exuberant ctags in the archives isn't using it either | 09:19 |
| zyga | perhaps, my comment was generic, icu is just large but we have to live with it | 09:19 |
| kalikiana | yeah, for cases where it is more or less the only option it's unfortunate | 09:19 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | reading /kernel.img | 09:51 |
| ogra_ | ** Unable to read file /kernel.img ** | 09:51 |
| ogra_ | reading /initrd.img | 09:51 |
| ogra_ | ** Unable to read file /initrd.img ** | 09:51 |
| ogra_ | Bad Linux ARM zImage magic! | 09:51 |
| ogra_ | :( | 09:52 |
| * zyga hugs ogra | 09:53 | |
| ogra_ | no mvo :( | 09:53 |
| ogra_ | seems tonights auto-upgrade did completely unset snap_kernel in my bootloaders | 09:54 |
| ogra_ | zyga, do you know if he is off today ? | 10:01 |
| zyga | ogra_: he's around, he's away for a few hours now | 10:01 |
| stokachu | zyga: awesome thanks man | 10:11 |
| zyga | 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 |
| zyga | stokachu: I will do 1.0.40 release in a moment and work on the SRU with mvo | 10:12 |
| stokachu | zyga: understood | 10:13 |
| zyga | stokachu: if you want you can try to build it now and test that it fixes the issue | 10:14 |
| zyga | stokachu: take master and packaging from https://code.launchpad.net/~snappy-dev/snap-confine/+git/snap-confine/+ref/16.04 | 10:14 |
| stokachu | zyga: ok, ill do a local build and give it a run | 10:15 |
| zyga | (packaging will change a little when mvo is back, we want to integrate his packaging work that was never committed) | 10:15 |
| zyga | I'll keep you posted :) | 10:15 |
| mvo | zyga: hey | 10:16 |
| stokachu | zyga: great, thanks! | 10:16 |
| zyga | mvo: hey, welcome back :-) | 10:16 |
| zyga | 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 |
| ogra_ | 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:17 | |
| ogra_ | (seems they did their auto-upgrade ... when i rebooted them all _kernel vars were completely unset) | 10:18 |
| ogra_ | mvo, i suspect there is some quoting issue | 10:18 |
| mvo | ogra_: yeah, same bug, I do new image | 10:19 |
| mvo | s | 10:19 |
| mvo | ogra_: let me do that rightnow | 10:19 |
| zyga | mvo: ping me on telegram when you have a moment to help me with the SRU process for snap-confine | 10:19 |
| zyga | (in private so that I get notified please) | 10:19 |
| ogra_ | mvo, seems when i change the script like: http://paste.ubuntu.com/23064119/ it doesnt fall over | 10:19 |
| zyga | Son_Goku: hey, still no selinux support, spent last night fire-fighting, I'm doing package builds and uploads now | 10:19 |
| ogra_ | (using test -n and no quoting for teh vars, the hush shell in uboot is very picky about such stuff IIRC) | 10:20 |
| zyga | Son_Goku: when I'm dong with snap-confine uploads I will try to integrate fedora into upstream CI | 10:20 |
| ogra_ | hmm, no, i take that back | 10:20 |
| ogra_ | it works exactly for one boot | 10:21 |
| ogra_ | so there is something else | 10:21 |
| ogra_ | (nontheless that script variant is cleaner :) ) | 10:21 |
| === chihchun is now known as chihchun_afk | ||
| * zyga uploads snap-confine to rawhide :) | 10:23 | |
| mvo | ogra_: hm, ok | 10:25 |
| mvo | ogra_: can you dump the environment when it fails? | 10:25 |
| zyga | Son_Goku: I'd like to get a neutered version of snapd reviewed, without active systemd units | 10:26 |
| ogra_ | mvo, well, the change is that snap_kernel is completely nonexistant then | 10:26 |
| zyga | Son_Goku: and initially just for f23 where systemd is not confined with selinux | 10:26 |
| zyga | Son_Goku: then work on making initial selinux changes for snapd.socket | 10:26 |
| mvo | ogra_: snap_kernel="" or not there at all? | 10:26 |
| zyga | Son_Goku: that should unblock f24 and f25 | 10:26 |
| ogra_ | not there at all | 10:26 |
| zyga | Son_Goku: and then apply for the remaining permissions | 10:26 |
| zyga | Son_Goku: let me know if this makes sense to you | 10:27 |
| mvo | ogra_: interessting, let me check the code | 10:27 |
| Son_Goku | zyga, you should apply for all of the branches anyway | 10:27 |
| Son_Goku | keep in mind you can build for all of the targets without actually submitting something as an update | 10:28 |
| zyga | Son_Goku: ack, I meant that initially just f23 will work | 10:28 |
| zyga | oh, that's true! | 10:28 |
| Son_Goku | those are two separate actions for a reason | 10:28 |
| ogra_ | 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 |
| ogra_ | ubuntu@dragonboard:~$ fw_printenv |grep ^snap_ | 10:28 |
| ogra_ | snap_kernel=dragonboard-kernel_1.snap | 10:28 |
| ogra_ | ubuntu@dragonboard:~$ | 10:28 |
| Son_Goku | zyga, adding branches later requires you to go through re-reviews, which are annoying :P | 10:29 |
| mvo | ogra_: meh, indeed, I think I found the issue | 10:29 |
| Son_Goku | so just add them now, and once you're happy, you can submit an update for F24 | 10:29 |
| zyga | ok | 10:29 |
| mvo | 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 |
| ogra_ | mvo, didnt leos setup have reboot tests ? perhaps we can use that for the moment | 10:30 |
| Son_Goku | zyga, I would just submit to all branches and everything, and just not do fedpkg update until you're ready | 10:31 |
| mvo | ogra_: yeah, I explore that a bit | 10:32 |
| zyga | Son_Goku: yep, I'll do that, just doing the macaroon and snap-confine work now | 10:33 |
| ogra_ | seb128, hmmm ... | 10:34 |
| seb128 | ogra_, hey, issues with my livecd-rootfs upload? | 10:34 |
| ogra_ | 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 |
| ogra_ | (it is good that you land it in yakkety for completeness though) | 10:35 |
| seb128 | ogra_, well, trunk first ... but thanks for pointing it out, who do I bribe to get that ppa updated? | 10:35 |
| ogra_ | me or mvo | 10:36 |
| ogra_ | i'll take a look in a moment | 10:36 |
| seb128 | who wants beer in octobre? ;-) | 10:36 |
| seb128 | danke! | 10:36 |
| ogra_ | haha | 10:36 |
| ogra_ | 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:39 |
| ogra_ | seb128, if you remove the "cat <<EOF" then you need to at least add an echo or some such ... | 10:40 |
| RoninDev_ | Hello! Please, tell me, can I run script before autotools plugin run? e.g. ./bootstrap.sh? | 10:40 |
| ogra_ | ubuntu@dragonboard:~$ apt | 10:40 |
| ogra_ | Ubuntu Core does not use apt-get, see 'snappy --help'! | 10:40 |
| ogra_ | ubuntu@dragonboard:~$ cat /usr/local/bin/no-apt | 10:40 |
| ogra_ | #!/bin/sh | 10:40 |
| ogra_ | cat <<EOF | 10:40 |
| ogra_ | Ubuntu Core does not use apt-get, see 'snappy --help'! | 10:40 |
| seb128 | ogra_, that was a dupliucate EOF | 10:41 |
| seb128 | code now is | 10:41 |
| seb128 | cat >$PREFIX/usr/local/bin/no-apt <<EOF | 10:41 |
| seb128 | #!/bin/sh | 10:41 |
| seb128 | Ubuntu Core does not use apt-get, see 'snappy --help'! | 10:41 |
| seb128 | EOF | 10:41 |
| seb128 | oh | 10:41 |
| ogra_ | :) | 10:41 |
| seb128 | you are right | 10:41 |
| seb128 | shrug | 10:41 |
| seb128 | sorry about that ;-) | 10:41 |
| seb128 | if you want to fix it feel free | 10:42 |
| ogra_ | there is definitely a bug that the EOF is missing in the resulting script | 10:42 |
| seb128 | I can fix for trunk after lunch | 10:42 |
| seb128 | just add the echo | 10:42 |
| ogra_ | but apparnely cat doesnt really care at runtime :) | 10:42 |
| ogra_ | 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:43 |
| seb128 | the xdg one is fine | 10:44 |
| seb128 | the goal is to generate a file on disk | 10:44 |
| seb128 | cat >$PREFIX/usr/local/bin/xdg-open <<EOF | 10:45 |
| seb128 | #!/bin/sh | 10:45 |
| seb128 | dbus-send --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"\$1" | 10:45 |
| seb128 | EOF | 10:45 |
| ogra_ | right, i just wonder how it got like that | 10:45 |
| seb128 | if you sh that you get the 3 lines writen to $PREFIX/usr/local/bin/xdg-open | 10:45 |
| ogra_ | seems it was just a blind copy of the no-apt one | 10:45 |
| seb128 | right | 10:45 |
| seb128 | well the new version works I tested it | 10:45 |
| seb128 | dbus-send is a cmd | 10:45 |
| seb128 | but you are right about the other one missing the echo | 10:46 |
| seb128 | lunch now, bbiab | 10:46 |
| Son_Goku | zyga, uhh what did you do?! | 10:49 |
| Son_Goku | patches aren't supposed to be recorded in sources | 10:50 |
| Son_Goku | they go into git itself | 10:50 |
| Son_Goku | no one can read anything in the binary repo | 10:50 |
| Son_Goku | zyga, did you approve my co-maintainer request for snap-confine? | 10:52 |
| Son_Goku | https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/ | 10:52 |
| zyga | oooh | 10:53 |
| zyga | Son_Goku: I didn't see the request yet, looking now | 10:54 |
| zyga | Son_Goku: how should I record the patch? | 10:54 |
| Son_Goku | git add? | 10:54 |
| zyga | Son_Goku: I see, let me correct that quickly | 10:54 |
| zyga | done (commit access) | 10:55 |
| Son_Goku | zyga, also, delete from "sources" the entry for the patch file | 10:56 |
| Son_Goku | you don't want that there | 10:56 |
| mup | PR snapd#1690 opened: partition: ensure that snap_{kernel,core} is not overriden with an empty value <Created by mvo5> <https://github.com/snapcore/snapd/pull/1690> | 10:56 |
| Son_Goku | and you'll want to bump the changelog for the spec too | 10:56 |
| Son_Goku | since you can't rebuild in koji without doing that | 10:56 |
| zyga | Son_Goku: yep, should I bump the spec file for that? | 10:56 |
| zyga | ah | 10:56 |
| zyga | ok | 10:56 |
| Son_Goku | oh, and in the changelog | 10:57 |
| Son_Goku | do "%%license" instead of "%license" | 10:57 |
| Son_Goku | because otherwise, it'll process it and weird things happen | 10:57 |
| Son_Goku | like this: "- Use GPLv3 instead of %doc for COPYING" | 10:57 |
| zyga | Fixed | 10:57 |
| zyga | ooh | 10:58 |
| zyga | %%license but %doc? why? | 10:58 |
| zyga | Son_Goku: like this? | 10:59 |
| zyga | -%license COPYING | 10:59 |
| zyga | +%%license COPYING | 10:59 |
| Son_Goku | yes | 10:59 |
| Son_Goku | no | 10:59 |
| zyga | :D | 10:59 |
| Son_Goku | not in the actual %files list | 10:59 |
| Son_Goku | in the changelog, it's actually processing the %license macro (which evaluates to the License field in the preamble) | 10:59 |
| zyga | ahh | 10:59 |
| Son_Goku | the files list is fine | 11:00 |
| zyga | so the changelog entry can look like | 11:00 |
| Son_Goku | but the changelog isn't | 11:00 |
| zyga | - Use %%license instead of %%doc | 11:00 |
| Son_Goku | yep | 11:01 |
| zyga | k, thanks for spotting that! | 11:01 |
| zyga | Son_Goku: pushed to master, let me know if this is good for fedpkg build | 11:02 |
| Son_Goku | zyga, no prob | 11:02 |
| Son_Goku | looks good to me | 11:03 |
| Son_Goku | merge it into all your other branches and go forth and build :) | 11:04 |
| mvo | ogra_: fwiw, branch pushed with fix for your bug | 11:05 |
| zyga | yep, do I need to fedpkg update again? | 11:05 |
| zyga | Son_Goku: I need a break, I'll do subsequent updates depending on your answer when I'm back from a walk | 11:08 |
| Son_Goku | ok | 11:08 |
| mup | PR snapd#1598 closed: interfaces: implement a fuse interface <Blocked> <Reviewed> <Created by stgraber> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1598> | 11:10 |
| Son_Goku | zyga, I'm going to just modify your existing update to use snap-confine-1.0.30-2.fc23 | 11:16 |
| Son_Goku | zyga, you should submit snap-confine to F24 and F25 as updates, too | 11:20 |
| Son_Goku | there's no reason not to | 11:20 |
| kalikiana | 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 |
| kalikiana | Those same scripts work perfectly if I "sh foobar" them | 11:32 |
| Chipaca | kalikiana, you want to change the interpreter | 11:43 |
| Chipaca | i mean, the shebang | 11:43 |
| Chipaca | jdstrand, is there a reason not to allow /usr/bin/env in the default profile? | 11:43 |
| Chipaca | kalikiana, just for the record with very few exceptions you should be shipping the interpreter also | 11:44 |
| Chipaca | kalikiana, the exceptions might begin and end with "sh" | 11:44 |
| Chipaca | 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:44 |
| kalikiana | In this instance I'm indeed using "!/usr/bin/env sh" | 11:45 |
| kalikiana | 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:46 |
| kalikiana | 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:47 |
| kalikiana | by nature nvim is extensible so I have to ultimately find something that allows on demand installing | 11:48 |
| Chipaca | 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:51 |
| Chipaca | 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 |
| Chipaca | kalikiana, optional modules sounds like something for the content interface | 11:52 |
| kalikiana | 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:53 |
| Chipaca | kalikiana, wat | 11:56 |
| Chipaca | kalikiana, #!, right? | 11:56 |
| kalikiana | Yes, sorry, I typed it here by hand | 11:57 |
| Chipaca | kalikiana, #!/bin/sh certainly should work | 11:57 |
| kalikiana | It doesn't | 11:57 |
| Chipaca | i mean, hello-world uses that | 11:57 |
| kalikiana | lemme copy a script in there and try | 11:57 |
| kalikiana | Hmmm it does indeed | 11:59 |
| kalikiana | Is hello-world unconfined? | 11:59 |
| kalikiana | Hmm no it's not according to "snap list" | 12:00 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | kalikiana, any denials in syslog ? | 12:03 |
| stokachu | 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:07 |
| stokachu | minus the deb package of course | 12:08 |
| kalikiana | ogra_: http://paste.ubuntu.com/23064305/ Several of the second one with different /proc/*/cmdline | 12:08 |
| ogra_ | mvo, do you mind if i switch it to "test -n" instead of '!= ""' ? | 12:09 |
| arges | 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 |
| mup | Bug #1612362: [SRU] 2.12 <verification-needed> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1612362> | 12:09 |
| kalikiana | ogra_: Chipaca Aha! It works if the script is in $SNAP_USER_DATA but not if it's in $HOME | 12:10 |
| kalikiana | Despite having the 'home' interface | 12:10 |
| ogra_ | 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 |
| ogra_ | system-observe or some such | 12:11 |
| ogra_ | or process-observe ... i forgot the exact mname | 12:11 |
| stokachu | is it possible to install a systemd service during snap install? | 12:12 |
| ogra_ | stokachu, snapd does that, based oon the info you give it in snapcraft.yaml | 12:13 |
| ogra_ | you cant randomly copy unit files in place though | 12:13 |
| stokachu | ogra_: i basically want to convert https://github.com/Ubuntu-Solutions-Engineering/openstack-deb | 12:13 |
| kalikiana | ogra_: the first one is 'home' isn't it? the same script can be opened and run by hand with "sh ./able" | 12:14 |
| stokachu | ogra_: and have that bridge setup during install | 12:14 |
| mvo | ogra_: sure, thats fine | 12:14 |
| ogra_ | stokachu, so creat bridge start and stop scripts and add app entries (with daemon line) into your snapcraft.yaml that points to them | 12:14 |
| ogra_ | kalikiana, home only allows file access ... not execution of random binaries ;) | 12:15 |
| stokachu | ogra_: ok, will the bridge be uninstalled on snap remove? | 12:15 |
| stokachu | as long as i have the stop app in there? | 12:15 |
| mvo | 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 |
| mvo | arges: I will ask our QA team to do the verification | 12:15 |
| kalikiana | ogra_: Hrm. Well, I could copy and run the same file - so I'm not sure I see the effective difference. | 12:15 |
| ogra_ | stokachu, not sure, thats a question for Chipaca i guess ... iirc we stop all services on removal though | 12:15 |
| stokachu | ok | 12:16 |
| ogra_ | kalikiana, run ? how ? | 12:16 |
| kalikiana | ogra_: As I said prepending "sh" or "python3" in case of Python works perfectly | 12:16 |
| kalikiana | ogra_: Or copy and run as-is | 12:17 |
| ogra_ | that actually sounds like a slight security hole | 12:17 |
| kalikiana | ogra_: How would executing the script only after copying it into $SNAP_USER_DATA be more secure? | 12:17 |
| kalikiana | It certainly is inconsistent | 12:17 |
| ogra_ | well, the home interface only gives you access ... allowing the exec is a general thing when it happens inside the confined space | 12:18 |
| ogra_ | which home doesnt belong to | 12:18 |
| kalikiana | I guess I should be symlinking my script folder into the snap? | 12:19 |
| ogra_ | i guess the home interface should block "sh $HOME/myscript.sh" | 12:19 |
| ogra_ | which is why i think there is a bug | 12:19 |
| ogra_ | jdstrand, ^^ | 12:20 |
| stokachu | how can i clear snapcrafts apt cache? | 12:23 |
| ogra_ | snapcraft clean | 12:23 |
| stokachu | doesnt work :( | 12:23 |
| ogra_ | huh ? | 12:23 |
| ogra_ | that definitely wipes it | 12:24 |
| stokachu | https://www.irccloud.com/pastebin/5eZy8hNO/ | 12:24 |
| stokachu | ogra_: ^ | 12:24 |
| zyga | Son_Goku: thanks for bumping bodhi tasks | 12:24 |
| Son_Goku | zyga, you still need to make the updates for F24 and F25 | 12:25 |
| Son_Goku | I could do it, but I figured you'd want to | 12:25 |
| Chipaca | stokachu, yes, systemd services are stopped on snap removal | 12:25 |
| ogra_ | stokachu, i see it running apt-get update there | 12:25 |
| stokachu | Chipaca: cool thanks | 12:25 |
| Chipaca | stokachu, asked to stop, then made to stop | 12:25 |
| ogra_ | stokachu, looks more like a server side issue | 12:25 |
| stokachu | Chipaca: how will it know to run bridgestop on removal? https://www.irccloud.com/pastebin/saEdO7ro/ | 12:26 |
| ogra_ | i.e. like the server is just regenerating its Packages file | 12:26 |
| stokachu | ogra_: ok ill give it a few | 12:26 |
| Son_Goku | zyga, by the way, you can change the positive karma number to be lower | 12:26 |
| Son_Goku | I usually set positive karma to be "1" rather than "3" for new packages | 12:27 |
| zyga | Son_Goku: ack, noted | 12:27 |
| zyga | Son_Goku: I'll do that for subsequent updates | 12:27 |
| ogra_ | stokachu, i guess it will run both ... "bridge.start stop" and "bridge.stop stop" | 12:27 |
| Chipaca | stokachu, stop-command and stop-timeout | 12:27 |
| Son_Goku | zyga, you can edit the update in bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2016-939c94b72e | 12:27 |
| stokachu | Chipaca: do i need to set that somewhere? | 12:27 |
| ogra_ | stokachu, you should work it into a single script that understandds the systems start/stop events | 12:27 |
| ogra_ | *systemd's | 12:27 |
| Son_Goku | zyga: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5556c3bef | 12:28 |
| stokachu | ogra_: ah | 12:28 |
| Son_Goku | there should be an edit button if you're logged in | 12:28 |
| Chipaca | stokachu, without looking i don't remember; what happens if you try to stop without having that there? | 12:28 |
| zyga | trying | 12:28 |
| Chipaca | stokachu, in any case, you *can* set those, next to "command", you add "stop-command" | 12:28 |
| Son_Goku | and you can modify the conditions of the update :) | 12:28 |
| stokachu | Chipaca: actually haven't ran it yet :) waiting for apt packages to work again | 12:28 |
| Son_Goku | as well as the update description and other things | 12:28 |
| ogra_ | Chipaca, well, he has one start service and one stop service ... and both will receive a stop event on uninstall | 12:28 |
| Son_Goku | 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 |
| zyga | I see it, changed to stable karma: 1 | 12:29 |
| Chipaca | stokachu, having a stop service seems weird | 12:29 |
| ogra_ | 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 |
| Chipaca | stokachu, i suspect it's not what you want | 12:29 |
| ogra_ | Chipaca, he wants the firewall settings the script applies system wide reverted on uninstall | 12:30 |
| stokachu | Chipaca: ok, i was trying to port over https://github.com/Ubuntu-Solutions-Engineering/openstack-deb/blob/master/debian/openstack.service | 12:30 |
| Chipaca | stokachu, that is, i suspect you want a single bridge: \n command: bridge.start \n stop-command: bridge.stop | 12:30 |
| ogra_ | yeah | 12:30 |
| stokachu | ohhh | 12:30 |
| zyga | Son_Goku: thanks :) | 12:30 |
| Son_Goku | 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 |
| stokachu | Chipaca: this look correct? https://www.irccloud.com/pastebin/4PAbzoN3/ | 12:31 |
| zyga | Son_Goku: I'd like to merge those packages whenever we have a moment | 12:31 |
| Chipaca | stokachu, maybe. Is "bridge.start" really a "simple", and not a "oneshot"? | 12:34 |
| Chipaca | 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 |
| Chipaca | and again and again and | 12:34 |
| stokachu | Chipaca: ah ok | 12:34 |
| Son_Goku | zyga, so what do you need to get snapd in good shape? | 12:34 |
| Chipaca | stokachu, and again :-op | 12:35 |
| stokachu | Chipaca: :D | 12:35 |
| zyga | Son_Goku: I need to figure out how to build against the macaroon before it ships in stable | 12:35 |
| Son_Goku | build against rawhide for now | 12:35 |
| zyga | Son_Goku: I'd like to simplify the package to strip the services that need permissions to be in fedora | 12:35 |
| Son_Goku | everything is just there | 12:35 |
| Son_Goku | when doing mock builds, just attach "-r fedora-rawhide-x86_64" | 12:36 |
| Son_Goku | before the name of the SRPM | 12:36 |
| zyga | Son_Goku: I need to fix systemd selinux as we talked about, that will eat most of my time I suspect | 12:36 |
| zyga | Son_Goku: ok | 12:36 |
| zyga | Son_Goku: thanks, I'll try that | 12:36 |
| zyga | Son_Goku: I'll update COPR first so that I have a feeling for everything mostly working | 12:36 |
| Son_Goku | once rawhide resyncs and the mirrors have your new builds, that should work | 12:36 |
| zyga | Son_Goku: just having lunch now :) (mushrooms all week) | 12:37 |
| Son_Goku | as for your copr, you can probably get away with deleting all the golang packages now | 12:38 |
| Son_Goku | since they've all shipped to stable | 12:38 |
| Son_Goku | so the only thing in your copr you'll need is the new golang package (macaroon), snap-confine, and snapd | 12:39 |
| zyga | Son_Goku: yep, I was planning on doing that | 12:39 |
| Son_Goku | though, if I give snap-confine karma, it'll just go through, probably :P | 12:39 |
| zyga | Son_Goku: copr can stay for snap* packages but I doubt it will need much more | 12:39 |
| zyga | heh :) | 12:40 |
| zyga | (just do it ;) | 12:40 |
| Son_Goku | technically, I need to wait for it to sync to updates-testing first | 12:40 |
| Son_Goku | otherwise it won't get marked for stable when I give it karma | 12:41 |
| stokachu | Chipaca, ogra_: this is the error im getting when attempting to install https://www.irccloud.com/pastebin/WbQ5M6Ke/ | 12:41 |
| Son_Goku | though, I think that might be fixed now... | 12:41 |
| Son_Goku | I'll wait a few hours before doing it | 12:41 |
| zyga | Son_Goku: sounds good | 12:42 |
| zyga | Son_Goku: we can try the same for macaroon | 12:42 |
| stokachu | Chipaca: do i need an actual systemd service file? | 12:43 |
| Son_Goku | did you edit the macroon updates to require lower karma? | 12:43 |
| zyga | mvo: quick question, are you busy now? I would like to do the snap-confine SRU with you to learn the process | 12:43 |
| zyga | dSodoing that now | 12:43 |
| mvo | zyga: probably best we wait for the currently pending sru first, or we need to go back to the 7 day wait time | 12:43 |
| zyga | Son_Goku: done | 12:44 |
| zyga | mvo: noted | 12:44 |
| mvo | zyga: but happy to do it once we have the next slot | 12:45 |
| zyga | mvo: thank you! | 12:47 |
| Chipaca | stokachu, no, you don't need a systemd service file | 12:48 |
| stokachu | ok | 12:48 |
| stokachu | i think i know whats wrong, i dont have /sbin/ip or /sbin/iptables in my snap | 12:48 |
| ogra_ | err | 12:49 |
| ogra_ | how would that work | 12:49 |
| ogra_ | you cant exec either of them | 12:49 |
| Chipaca | stokachu, journalctl should tell you what to do | 12:49 |
| Chipaca | stokachu, i mean, it should have a log | 12:49 |
| Chipaca | stokachu, journalctl -u snap.conjure-up.bridge.service | 12:49 |
| ogra_ | stokachu, i assume thats the first install of the package ... where nnone of the interfaces are connected | 12:49 |
| ogra_ | so you cant have any access to /sbin/ip or /sbin/iptables | 12:50 |
| ogra_ | only after you connected the firewall interface that will work | 12:50 |
| stokachu | Aug 17 12:40:21 riddick systemd[1]: snap.conjure-up.bridge.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing. | 12:50 |
| ogra_ | what you should do is to make the script exit gracefully here | 12:50 |
| Chipaca | ahh, that also: if your services need interfaces to work, you need to make them handle not having the interface yet | 12:50 |
| Chipaca | that is: if they need interfaces that don't auto-connect | 12:51 |
| stokachu | yea im creating a custom bridge in the bridge.start script | 12:51 |
| ogra_ | (not sure if we allow snapd to show a message you can print from the script or some such) | 12:51 |
| stokachu | so do i just need to add the firewall-control plug? | 12:54 |
| zyga | stokachu: there's also network-control or something like that | 12:55 |
| zyga | AFAIR | 12:55 |
| stokachu | so far ive got network-control, network-bind, firewall-control | 12:55 |
| ogra_ | yeah, ip needs network-control, iptables needs firewall-control i guess | 12:55 |
| ogra_ | and i think neither of them is auto-connecting | 12:55 |
| stokachu | do i still need to include those binaries directly? | 12:55 |
| ogra_ | i dont think so | 12:56 |
| stokachu | and how do i handle the interfaces that aren't auto-connecting ? | 12:56 |
| ogra_ | but you need to use snap connect to connect them after install | 12:56 |
| stokachu | is that left up to the user or can i do that in my snap installation? | 12:56 |
| ogra_ | and your script should check if it can exec the binaries and if not print a message and exit gracefuly | 12:56 |
| ogra_ | thats up to the user | 12:56 |
| stokachu | so once the user does a 'snap connect' those oneshot scripts will be run again? | 12:57 |
| ogra_ | all dangerous interfaces are manual connect thingies | 12:57 |
| ogra_ | not sure, i think you might need to start it with systemctl | 12:57 |
| stokachu | so this brings me back to is it possible to create and start a custom network bridge via snap install? | 12:58 |
| ogra_ | not without the user allowing access to the interfaces, no | 12:58 |
| stokachu | ugh | 12:58 |
| mup | PR snapd#1691 opened: many: add `snap download` command that downloads into /var/lib/snapd/download <Created by mvo5> <https://github.com/snapcore/snapd/pull/1691> | 12:58 |
| ogra_ | they need snap install ; snap connct ... and restart the services | 12:58 |
| ogra_ | *connect | 12:59 |
| ogra_ | s/restart/start/ ? | 12:59 |
| ogra_ | (not sure abot that one) | 12:59 |
| stokachu | so that defeats my user experience | 12:59 |
| stokachu | of just doing 'snap install conjure-up' and having everything work | 12:59 |
| ogra_ | yeah, not if you use interfaces that could potentially be harmful | 12:59 |
| ogra_ | we want the user to have full control here | 13:00 |
| stokachu | but i define those plugs in my snapcraft.yaml | 13:00 |
| ogra_ | so such stuff will never auto apply | 13:00 |
| stokachu | shouldnt that tell the user we want access to those interfaces? | 13:00 |
| ogra_ | sure, but they are not auto-connect interfaces | 13:00 |
| ogra_ | how would he know without looking at your source | 13:00 |
| ogra_ | i guess eventually there will be UI that asks | 13:00 |
| ogra_ | but thats not there atm | 13:00 |
| stokachu | this is a huge blocker for me then | 13:01 |
| * ogra_ imagines at some point snapd will do something like "the snap you install wants to access firewall control, do you want to allow it [Y/N]" during the install process | 13:03 | |
| ogra_ | but thats further down the rodamap | 13:03 |
| ogra_ | so for now you need to tell your users to use snap connect to connect the interfaces | 13:03 |
| stokachu | so where is this defined on the roadmap? | 13:08 |
| stokachu | like when could i expect that to be implemented | 13:08 |
| jdstrand | Chipaca: re env> no, in fact it is already allowed: /{,usr/}bin/env ixr, | 13:09 |
| jdstrand | kalikiana: ^ | 13:09 |
| ogra_ | stokachu, i'm pretty sure it isnt in the very near term roadmap ... there are to many other things to solve first | 13:10 |
| stokachu | ogra_: can you reply to my email on snapcraft list then stating that? | 13:11 |
| stokachu | b/c im going to be asked why i can't implement this software as a snap | 13:11 |
| ogra_ | stokachu, there is surely a way to ship your own apparmor profile and having your snap go through manual review for every upload though ... | 13:11 |
| ogra_ | for "trusted snaps" thats definitely a possibility | 13:11 |
| stokachu | ogra_: but then im back to having to wait on someone else to approve it | 13:12 |
| ogra_ | yes | 13:12 |
| stokachu | ogra_: might as well just do it the regular way | 13:12 |
| ogra_ | well, but the regular way is to tell your users to use snap connact $plug $interface | 13:12 |
| stokachu | no the regular way i mean going through the debian process | 13:13 |
| ogra_ | and to restart the services that use them | 13:13 |
| stokachu | one of the major points of doing a snap was so I didnt have to go through all those processing tasks | 13:13 |
| stokachu | that's how it was told to us | 13:13 |
| ogra_ | well, the major point should still be that you are completely independent from the host system version :) | 13:14 |
| stokachu | ogra_: that's fine but i dont remember you being at the sprint and hearing how it was told to us | 13:14 |
| ogra_ | well, i wasnt invited to the CDO sprint :) | 13:15 |
| ogra_ | perhaps you guys have worked out a way to allow "trusted snaps" to go through the store without manual approval | 13:15 |
| ogra_ | no idea about that one | 13:15 |
| stokachu | ev ^ | 13:15 |
| jdstrand | stokachu: network-control allows you to set up the bridge. it does not allow you to add systemd units | 13:15 |
| stokachu | is this something that you can flag so i don't have to go through a review process everytime? | 13:16 |
| ogra_ | i'm just telling you what every normal snap packager needs to go through ... there are surely special cases possible for canonical maintained snaps | 13:16 |
| jdstrand | stokachu: but, snappy gives you a systemd unit for every 'daemon: ...' command. so you can do that yourself | 13:16 |
| ogra_ | jdstrand, thats not the issue ... on first install the manual-connect interfaces wont be there | 13:16 |
| stokachu | ogra_: right, well thats the issue of telling me im not a normal target case | 13:16 |
| ev | stokachu: you can absolutely have a snap in devmode | 13:16 |
| ogra_ | so the systemd usints the snap creates wont run | 13:16 |
| stokachu | ev: this doesn't work in devmode either | 13:17 |
| stokachu | jdstrand: i responded to your email about where im at | 13:17 |
| stokachu | jdstrand: there doesn't seem to be a way to allow a bridge to be started during a snap install | 13:17 |
| morphis | jdstrand, zyga: I am wondering if we're doing anything to avoid apps in the same snap talking to each other over abstract unix sockets when I've installed the snap in devmode | 13:17 |
| jdstrand | stokachu: (basically what ogra already said. /me is reading backscroll and just catching up) | 13:17 |
| ogra_ | jdstrand, stokachu is bothered about the manual connecting | 13:17 |
| ogra_ | (and having to manually start/restart the units then) | 13:18 |
| zyga | morphis: no, in devmode apparmor won't be in the way | 13:18 |
| zyga | morphis: do you see anything odd? | 13:18 |
| morphis | zyga: yes | 13:18 |
| ogra_ | i.e. there are two more steps after snap install | 13:18 |
| morphis | zyga: but I am wondering if there is anything else but I saw snap-confine is just doing a clone(CLONE_NEWNS) and nothing else | 13:19 |
| ogra_ | stokachu, it doesnt work in devmode ? that would be a bug | 13:19 |
| zyga | morphis: oh, interesting, i wonder if that affects abstract sockets | 13:19 |
| stokachu | ogra_: no i still have to do those additional steps | 13:19 |
| ogra_ | in devmode interfaces shouldnt matter much | 13:19 |
| morphis | zyga: I would say it doesn't as that is what CLONE_NEWIPC is for | 13:19 |
| ogra_ | right, file a bug about that | 13:19 |
| zyga | morphis: that's good to know, thanks | 13:19 |
| ogra_ | devmode should make it behave not different from a deb in that regard | 13:19 |
| jdstrand | kalikiana: 'home' interface gives you 'rwk', not 'i' (inherited exec) to non-hidden files in your home directory. this is by design | 13:20 |
| morphis | zyga: if I am right CLONE_NEWNS is just the mount namespace | 13:20 |
| zyga | morphis: and what do you observe in practice? no connection? | 13:20 |
| jdstrand | kalikiana: but with an interpreted script, yes you get to run it, sure | 13:20 |
| stokachu | ogra_: ok | 13:20 |
| stokachu | ogra_: eventually i do need this to work in strict mode | 13:20 |
| jdstrand | kalikiana: the home interface is transitional | 13:21 |
| morphis | zyga: yes | 13:21 |
| ogra_ | stokachu, well, only after there is some UI then i guess | 13:21 |
| morphis | zyga: https://paste.ubuntu.com/23064472/ | 13:21 |
| stokachu | ogra_: k thats fine, i can wait on that as long as devmode will work | 13:21 |
| morphis | zyga: basically I am running an lxc container and trying to attach to it with lxc-attach | 13:21 |
| ogra_ | right ... you didnt talk about devmode above :) | 13:21 |
| morphis | zyga: but the lxc_monitor process doesn't get connected to the abstract socket the container creates | 13:22 |
| zyga | morphis: is that reproducible in a simpler test case? | 13:22 |
| morphis | zyga: can create one | 13:22 |
| stokachu | ogra_: i absolutely did talk about it, https://www.irccloud.com/pastebin/WbQ5M6Ke/ | 13:22 |
| zyga | morphis: if you can that would help, we could run in in snap-confine regression Ci | 13:22 |
| morphis | zyga: sounds good | 13:23 |
| jdstrand | morphis: we don't do CLONE_NEWIPC so abstract sockets should be ok | 13:23 |
| === chihchun is now known as chihchun_afk | ||
| morphis | jdstrand: good to know | 13:23 |
| ogra_ | stokachu, so the first one is clear there (the unit isnt there before installing so it can not be stopped) ... the second one says "invalid argument" ... perhaps an issue in the script ? | 13:23 |
| stokachu | the error is from systemd unit | 13:23 |
| kalikiana | jdstrand: Right, I see now how this works. In the long run I wouldn't even plan to use it, it was just the best I could think of - what I really need is the ability to execute other snaps that contain those scripts and toolchains | 13:23 |
| stokachu | ogra_: Aug 17 12:40:21 riddick systemd[1]: snap.conjure-up.bridge.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing. | 13:24 |
| stokachu | that is the error | 13:24 |
| ogra_ | stokachu, did you paste the "systemctl status snap.conjure-up.bridge.service" output above already ? | 13:24 |
| morphis | jdstrand, zyga: maybe stgraber can help me, as they may ran into the same problem already with the lxd snap | 13:24 |
| jdstrand | kalikiana: you might be interested in the content interface | 13:24 |
| zyga | morphis: yep, try it | 13:24 |
| seb128 | ogra_, new livecd-rootfs uploaded to yakkety, I also changed the message to not recommend "snappy --help" but "snap --help" ;-) | 13:24 |
| ogra_ | stokachu, hmm, iirc that was a bug in old snapd ... | 13:24 |
| stokachu | ogra_: https://www.irccloud.com/pastebin/PuwB6zeQ/ | 13:24 |
| ogra_ | seb128, cool, sorry didnt get to push it to the PPA yet ... next on my list | 13:25 |
| stokachu | ogra_: running snapd 2.0.10 | 13:25 |
| seb128 | ogra_, no hurry, thanks! | 13:25 |
| ogra_ | stokachu, uuh | 13:25 |
| ogra_ | update :) | 13:25 |
| jdstrand | morphis: I'd be interested in what you find out from stgraber | 13:25 |
| morphis | jdstrand: will share with you :-) | 13:25 |
| stokachu | ogra_: same error | 13:27 |
| stokachu | running snapd 2.11+0.16.04 | 13:27 |
| stokachu | that service file is left behind do i need to manually remove it? | 13:28 |
| ogra_ | stokachu, well, it was fixed in 2.11 | 13:28 |
| ogra_ | - wrappers: map "never" restart condition to "no." | 13:28 |
| kalikiana | jdstrand: Are there any docs I could check? | 13:28 |
| ogra_ | https://launchpad.net/ubuntu/+source/snapd/2.11+0.16.04 | 13:28 |
| stokachu | ogra_: so do i need to do anything special once upgrading snapd? | 13:28 |
| ogra_ | not that i know of | 13:29 |
| morphis | stgraber: ping | 13:30 |
| stokachu | ogra_: yea it's still failing | 13:32 |
| jdstrand | kalikiana: all I know of it https://github.com/snapcore/snapd/blob/master/docs/interfaces.md, but you can also read tests/main/interfaces-content | 13:32 |
| jdstrand | s/it/is/ | 13:32 |
| stokachu | ogra_ https://www.irccloud.com/pastebin/4KYGeCzl/ | 13:32 |
| jdstrand | kalikiana: basically one side exports a directory (or more) and the other side can import it if from the same publisher | 13:35 |
| ogra_ | stokachu, well, i dont know then | 13:40 |
| ogra_ | stokachu, perhaps Chipaca knows more ... (or someone else from the core team) | 13:40 |
| stokachu | k | 13:41 |
| stokachu | jdstrand: https://github.com/conjure-up/conjure-up/tree/patch-add-bridge-to-snap/snapcraft should this work in --devmode? or am I missing something? | 13:41 |
| morphis | jdstrand, zyga: hm, looks like its not such a problem but more a relocation one | 13:48 |
| mup | Bug #1610292 changed: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1610292> | 13:56 |
| jdstrand | stokachu: you need to use 'confinement: devmode' to install in devmode I think | 13:56 |
| stokachu | jdstrand: even if i pass --devmode? | 13:57 |
| jdstrand | ie, you need both sides-- the yaml to say it and to specify --devmode | 13:57 |
| ogra_ | jdstrand, if he uses --devmode on cmdline ? | 13:57 |
| ogra_ | i thought the commandline was mandatoory | 13:57 |
| jdstrand | I thought that was what the design was. it wasn't always the case, but maybe it changed? | 13:57 |
| jdstrand | the command line is mandatory | 13:57 |
| jdstrand | what I'm saying is that I thought we changed to the yaml also being mandatory. maybe I'm misremembering | 13:58 |
| jdstrand | stokachu: it is easy to see if you are in devmode. what does 'sudo aa-status' say about the apparmor profile? if in devmode, it should show the apparmor profile in complain mode | 13:59 |
| stokachu | jdstrand https://www.irccloud.com/pastebin/nPRjExPU/ | 14:00 |
| jdstrand | stokachu: but to answer your question-- I would expect that yaml ('confinement' notwithstanding) to work once the snap is installed in devmode, yes | 14:00 |
| stokachu | it's still giving me the same systemd error about Restart= | 14:00 |
| jdstrand | so yes, you are in devmode | 14:00 |
| stokachu | Aug 17 13:53:25 riddick systemd[1]: snap.conjure-up.bridge.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing | 14:00 |
| stokachu | how can i see what that service file looks like? | 14:01 |
| jdstrand | I don't know what that error is, but I'm also not the one who implemented the systemd part | 14:01 |
| jdstrand | stokachu: /etc/systemd/system | 14:01 |
| stokachu | https://www.irccloud.com/pastebin/kfc74oFx/ | 14:02 |
| stokachu | ogra_ ^ | 14:02 |
| jdstrand | stokachu: see my email to the list. I think you want to leverage the hooks work. aiui, that will restart the service after interface connect | 14:03 |
| stokachu | jdstrand: ah ok | 14:04 |
| jdstrand | I've not used it or even looked at it yet though | 14:04 |
| jdstrand | let me see if I can fine the PR | 14:04 |
| stokachu | the very least oneshot shouldn't have restart=on-failure i would think | 14:05 |
| stokachu | should just run and fail or succeed | 14:06 |
| jdstrand | it seems like there are many PRs in this area and that kyrofa is involved in many of them | 14:06 |
| * kyrofa jerks awake | 14:06 | |
| jdstrand | stokachu: that sounds like a very reasonable request | 14:06 |
| jdstrand | kyleN: context is stokachu has a systemd unit that he wants to run when interfaces are connected | 14:07 |
| stokachu | https://github.com/snapcore/snapd/blob/da9fa3774fcf56464dc3d8446f47b2c1eb3943e0/tests/lib/snaps/data-writer/meta/snap.yaml can i set that restart-condition in snapcraft.yaml? | 14:07 |
| jdstrand | and I thought that work has been done in this area | 14:07 |
| kyrofa | jdstrand, stokachu ah interesting, we were just discussing interface hooks | 14:07 |
| sergiusens | kyrofa indeed I am | 14:08 |
| * zyga plays with snapd 2.11 on fedora :) | 14:08 | |
| jdstrand | stokachu: yes, see docs/meta.md. specifically: `restart-condition`: (optional) if specified, use the given restart condition. Can be one of `on-failure` (default), `never`, `on-success`, `on-abnormal`, `on-abort`, and `always`. See `systemd.service(5)` (search for `Restart=`) for details. | 14:08 |
| ogra_ | zyga, and who wins ? | 14:08 |
| stokachu | jdstrand: lemme try that | 14:09 |
| arges | zyga: bugs 1612120 1612291 1612684 : are these fixed in yakkety? | 14:09 |
| mup | Bug #1612120: $SNAP_USER_DATA is no longer created by snap-confine but is not yet created by snapd <verification-done> <Snappy Launcher:Fix Committed by zyga> <snap-confine (Ubuntu):Confirmed> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1612120> | 14:09 |
| jdstrand | kyleN: sorry, that was for kyrofa | 14:09 |
| kyleN | ack | 14:09 |
| stokachu | jdstrand: so the interface hooks can be run after a snap connect? | 14:09 |
| stokachu | kyrofa: ^ | 14:10 |
| * jdstrand defers to kyrofa | 14:10 | |
| zyga | ogra_: everyone! | 14:10 |
| zyga | arges: let me check | 14:10 |
| ogra_ | hah | 14:10 |
| kyrofa | stokachu, that's the idea, but they're still in the design phase | 14:11 |
| stokachu | ok | 14:12 |
| jdstrand | kyrofa: curious if you might do 'restart-condition: on-interface-connect' which would (perhaps) set 'never' and then on connect something else (though people still might want to set what that something else is, so not this exactly) | 14:12 |
| kyrofa | stokachu, all of the hook work so far has been the underlying machinery for hooks, not the hooks themselves | 14:12 |
| zyga | arges: no, although all of them are fixed in master; I will release snap-confine soon and ask mwhudson and slangasek to upload that | 14:12 |
| stokachu | so I got my snap to install now with restart-condition: never | 14:12 |
| stokachu | what are the steps to manually bring up the bridge now? | 14:12 |
| stokachu | snap connect conjure-up:firewall-control? | 14:12 |
| jdstrand | snap connect conjure-up:firewall-control ubuntu-core:firewall-control | 14:13 |
| ogra_ | snap connect conjure-up:firewall-control ubuntu-core:firewall-control | 14:13 |
| jdstrand | (do that for each manually connected interface | 14:13 |
| ogra_ | *snap* | 14:13 |
| arges | zyga: ok great, once that's done we cna get that released then start processing the next snap-confine in teh queue | 14:13 |
| ogra_ | :) | 14:13 |
| jdstrand | then restart the unit | 14:13 |
| kyrofa | stokachu, can you explain your use-case a little? What is the service you want to fire up upon interface connection? | 14:13 |
| ogra_ | jdstrand, zyga, we should really not require the ubuntu-core: by default imho | 14:13 |
| jdstrand | stokachu: some day simply: s/ubuntu-core:firewall-control/:firewall-control/ | 14:14 |
| jdstrand | it's know | 14:14 |
| stokachu | kyrofa: https://github.com/conjure-up/conjure-up/tree/patch-add-bridge-to-snap/snapcraft | 14:14 |
| jdstrand | known | 14:14 |
| ogra_ | "snap connect conjure-up:firewall-control firewall-control" should understand that i mean the system level interface | 14:14 |
| stokachu | jdstrand: ok | 14:14 |
| ogra_ | ah | 14:14 |
| stokachu | kyrofa: i have a custom lxd bridge i want to start when someone runs snap install conjure-up | 14:14 |
| stokachu | or snap connect i guess in this case | 14:15 |
| zyga | arges: yep, I'll release upstream in a moment | 14:15 |
| kyrofa | stokachu, is that actually a long-running service though? | 14:15 |
| zyga | arges: I just wanted to test it on fedora | 14:15 |
| stokachu | kyrofa: nah it just a oneshot to setup the bridge | 14:15 |
| kyrofa | Or just "something that needs to happen upon connection" | 14:15 |
| jdstrand | ogra_: aiui, the design is :firewall-control such that if the snap is not specified, use an implied core snap interface | 14:15 |
| stokachu | yea just on connection i think | 14:15 |
| kyrofa | stokachu, ah, then we can ignore the systemd side completely and you can just implement a normal interface hook as soon as we have them | 14:15 |
| arges | zyga: cool | 14:15 |
| stokachu | kyrofa: ok cool, that still in design phase though? | 14:16 |
| ogra_ | jdstrand, fine as well i guess | 14:16 |
| kyrofa | stokachu, just so you have it in the back of your mind: hooks go in meta/hooks/ (snapcraft will expose this soon). They are named according to their purpose, in your case, perhaps something like <interface>-connect and <interface>-disconnect | 14:16 |
| jdstrand | ogra_: zyga may even have a branch floating around. I don't know if there is a bug | 14:16 |
| kyrofa | stokachu, they'll be called by snapd just by being named correctly | 14:17 |
| stokachu | kyrofa: ah nice | 14:17 |
| jdstrand | kyrofa: curious, how does that work if you need two interfaces connected to work? | 14:17 |
| kyrofa | stokachu, you can just put your scripts in there | 14:17 |
| jdstrand | kyrofa: or does your script logic need to account for that | 14:17 |
| jdstrand | ? | 14:17 |
| kyrofa | jdstrand, the logic will likely have to account for that, interfaces aren't all connected up at one time anyway | 14:18 |
| stokachu | would it also be possible to turn on ip forwarding in those scripts? | 14:19 |
| stokachu | or is that left up to the user | 14:19 |
| kyrofa | stokachu, if the scripts need plug, then you can declare them in the YAML requesting them | 14:19 |
| kyrofa | stokachu, so assuming you have a plug that lets you do that | 14:19 |
| stokachu | ok | 14:19 |
| stokachu | kyrofa: is there a plug that will let me do that? :) | 14:19 |
| kyrofa | stokachu, heh, I must bounce you back to the venerable jdstrand | 14:20 |
| kyrofa | jdstrand, I'd like to hear about the use-case you had in mind about the multiple interfaces thing though | 14:21 |
| jdstrand | kyrofa: I don't see documentation on these hooks in meta.md or anywhere else in docs/. Can we add that there? is this documented somewhere else? | 14:21 |
| sergiusens | kyrofa can you quickly check my comment on snapcraft/733 | 14:21 |
| sergiusens | ? | 14:21 |
| kyrofa | jdstrand, not yet-- everything that has landed so far is all machinery that is completely transparent to the end users | 14:21 |
| jdstrand | kyrofa: well, it is actually stokachu's. he plugs both network-control and firewall-control. that would be common for a router too. | 14:21 |
| kyrofa | jdstrand, and the same thing needs to happen upon connection/disconnection for both interfaces? | 14:22 |
| jdstrand | stokachu: firewall-control lets you set ip forwarding | 14:22 |
| jdstrand | kyrofa: well, it is more that "there is no point starting anything until both these things are connected" kind of thing | 14:22 |
| stokachu | jdstrand: ok cool | 14:23 |
| kyrofa | sergiusens, sure, if you'd learn to ref them right so I can click on a link: snapcraft#733 maybe | 14:24 |
| mup | PR snapcraft#733: Add the go-buildtags property to the go plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/733> | 14:24 |
| kyrofa | jdstrand, stokachu so does a service need to be started as a result of the interface connection, then? | 14:24 |
| kyrofa | I thought we determined no | 14:24 |
| stokachu | for me its just a oneshot type of thing | 14:25 |
| stokachu | runs a couple of commands to create a network bridge | 14:25 |
| stokachu | then removes it on uninstall | 14:25 |
| kyrofa | stokachu, no coordination needed between interfaces? | 14:26 |
| jdstrand | kyrofa: I can imagine a scenario for this, yes | 14:26 |
| stokachu | kyrofa: just as long as I have access to `ip` and `iptables` commands | 14:26 |
| stokachu | so they can be connected in any order | 14:26 |
| kyrofa | jdstrand, yeah, running a service based in hooks isn't something I had considered | 14:27 |
| ogra_ | seb128, livecd-rootfs uploaded ... i'll trigger a new ubuntu-core for the edge channel once it built | 14:27 |
| seb128 | ogra_, thanks! | 14:27 |
| kyrofa | stokachu, good deal, you should be set as soon as this stuff lands. Keep an eye on pstolowski, he's starting to work on those | 14:27 |
| stokachu | kyrofa: ok sweet! | 14:27 |
| jdstrand | kyrofa: as implemented, how I would probably do thing is in the <interface>-connect commands I would create a config file. eg, foo-connect creates SNAP_DATA/config FOO_CONNECTED=yes. bar-connect add BAR_CONNECTED=yes. then my daemon: oneshot script looks at SNAP_DATA/config and chooses to run or not | 14:27 |
| stokachu | kyrofa, jdstrand: this is how i would get this to work today https://www.irccloud.com/pastebin/XyWnLsQi/ | 14:28 |
| jdstrand | kyrofa: but that requires a lot of work on my end | 14:28 |
| jdstrand | kyrofa: something in the yaml that say 'just don't run if all the interfaces aren't connected' would be great for this sort of thing | 14:29 |
| kyrofa | jdstrand, right now the oneshot would run upon install, probably fail dramatically, and then your hooks would run when the interfaces were connected. We need some logic to ask the service to fire back up | 14:29 |
| kyrofa | jdstrand, yeah that seems fair | 14:29 |
| jdstrand | stokachu: fyi, network-bind is autoconnected | 14:29 |
| kyrofa | jdstrand, and doable, I think. Even today, ignoring hooks | 14:29 |
| stokachu | jdstrand: ah ok | 14:29 |
| kyrofa | jdstrand, might be worth a bug or a ML thread about that, if we can get it designed in the YAML I don't think the implementation would be that difficult. | 14:30 |
| jdstrand | I think setting ip forwarding also makes sense for network-control. /me adds a todo | 14:31 |
| kyrofa | jdstrand, but I don't think it involves hooks | 14:31 |
| jdstrand | if it was in the yaml, right-- wouldn't need an hooks | 14:31 |
| jdstrand | the hooks is just a way to get there today | 14:32 |
| kyrofa | jdstrand, snapd keeps internal track of what plugs are connected. It just needs to know to fire the service up if they're all green | 14:32 |
| kyrofa | jdstrand, yeah, hooks are not there today I'm afraid | 14:32 |
| kyrofa | jdstrand, lots of things have landed, as you noted, but they're not usable just yet | 14:32 |
| jdstrand | kyrofa: oh, do you mean meta/hooks/firewall-control-connect doesn't work today? | 14:33 |
| kyrofa | jdstrand, indeed | 14:33 |
| jdstrand | I thought I heard you say it did | 14:33 |
| jdstrand | ah | 14:33 |
| jdstrand | ok | 14:33 |
| kyrofa | jdstrand, ah, I'm sorry for misleading you! No: the machinery behind hooks is very nearly complete. But the hooks themselves are a different story | 14:34 |
| kyrofa | jdstrand, it's like the machinery behind interfaces versus the interfaces themselves | 14:34 |
| stokachu | ah i can't just run systemctl restart snap.conjure-up.bridge.service since those $snap vars aren't set | 14:34 |
| stokachu | do i need to execute that with snap run? | 14:34 |
| kyrofa | stokachu, hmm... they should be | 14:35 |
| kyrofa | stokachu, check the unit file, they should all be defined right thre | 14:35 |
| jdstrand | kyrofa: gotcha, no worries | 14:36 |
| ogra_ | yeah, in the environment | 14:36 |
| stokachu | ah ok they are | 14:36 |
| ogra_ | (i think theyx had them in the paste you showed me) | 14:36 |
| stokachu | ah ok it's just not configuring my interface | 14:37 |
| kyrofa | stokachu, note that you should never need to use `snap run`. Soon it will be used instead of all that environment in the unit file, but it'll just be run by the unit (or by the files in /snap/bin) | 14:37 |
| stokachu | i need to include both sbin/ip and sbin/iptables into my snap? | 14:37 |
| stokachu | kyrofa: ack | 14:37 |
| bergkatten_ | Just read: "Your first snap" :) | 14:39 |
| bergkatten_ | Is there any way for a newby to create own snap repo on localhost? | 14:39 |
| === j is now known as Guest92652 | ||
| ogra_ | bergkatten_, wekll you can just "snap install /path/to/snap" ... why waste effort and time for a repo | 14:41 |
| ogra_ | (there are ways to run local snap stores, but that will lack features vs the real store (unless you implement them)) | 14:42 |
| ogra_ | see https://uappexplorer.com/app/snapstore-example.noise for a snapstore snap :) | 14:43 |
| bergkatten_ | would like create an internal store with not so public inhouse packages | 14:43 |
| mreed | nessita, ping | 14:47 |
| ogra_ | noise][, you should link a howto from the description ^^^ iirc there is an env var needed to make snapd use your store ? | 14:47 |
| noise][ | https://github.com/noise/snapstore | 14:49 |
| nessita | mreed, hi | 14:49 |
| ogra_ | bergkatten_, ^^ | 14:49 |
| mreed | nessita, hi :-) by chance can you review my snap? https://myapps.developer.ubuntu.com/dev/click-apps/5726/rev/1/ | 14:49 |
| zyga | Pharaoh_Atem: https://bugzilla.redhat.com/show_bug.cgi?id=1367825 | 14:50 |
| zyga | Pharaoh_Atem: feel free to request dropping of systemd units | 14:50 |
| zyga | Pharaoh_Atem: or for the presets at least | 14:50 |
| Pharaoh_Atem | the units are fine | 14:51 |
| zyga | Pharaoh_Atem: I figured it is better to have you do a review first before I go around and strip everything | 14:51 |
| Pharaoh_Atem | it's the presets that are an issue | 14:51 |
| Pharaoh_Atem | one sec | 14:51 |
| zyga | Pharaoh_Atem: sure, I'm happy to remove those | 14:51 |
| nessita | mreed, looking. So your snap does not provide any binary at all? | 14:52 |
| mreed | nessita, it should generate a dbench binary | 14:52 |
| mreed | nessita, I am not sure if I have that set up correctly | 14:52 |
| nessita | mreed, seems like is not? the review failed with | 14:52 |
| nessita | Could not find compiled binaries for architecture 'amd64' lint-snap-v2_architecture_specified_needed (amd64) | 14:52 |
| nessita | elopio, do we have any documentation on the above, or who would be the best person to assist mreed? | 14:53 |
| kyrofa | nessita, I got it. mreed, can I see your YAML? | 14:56 |
| mup | Bug #1613971 opened: using oneshot results in failed service <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1613971> | 14:56 |
| mreed | kyrofa, sure | 14:57 |
| bergkatten_ | ogra_: tnx, testing it on my machine | 14:57 |
| nessita | kyrofa, oh thank you! kyle to the rescue | 14:58 |
| kyrofa | mreed, feel free to ping me directly if it's not public, by the way | 14:59 |
| mup | Bug #1612909 changed: Unable to install snappy in Fedora <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1612909> | 14:59 |
| mup | Bug #1614134 opened: need a way to start daemon only if all interfaces are connected <Snappy:New> <https://launchpad.net/bugs/1614134> | 15:02 |
| ogra_ | mvo, so wheer is that branch you talked about above (to not make snap_kernel/_core being unset if only one is upgraded) was that a snapd change ? | 15:03 |
| ogra_ | i dont see any change in snappy-hub | 15:04 |
| ogra_ | mvo, also, you probably want the fixes from seb128 for xdg-open and friends that i just pushed to the PPA in your promoted ubuntu-core | 15:05 |
| ogra_ | since they affect classic directly | 15:05 |
| Pharaoh_Atem | zyga: I left a comment on the snapd review | 15:05 |
| * ogra_ is waiting for the PPA publisher to actually release the change before triggering a new ubuntu-core | 15:06 | |
| zyga | Pharaoh_Atem: thanks, looking | 15:06 |
| mvo | ogra_: its a snapd fix | 15:06 |
| ogra_ | ah, k | 15:06 |
| mvo | ogra_: cool, yeah, once the other fix lands I can do new images | 15:06 |
| ogra_ | ok, publisher done, building a new ubuntu-core | 15:09 |
| === JanC is now known as Guest40946 | ||
| === JanC_ is now known as JanC | ||
| jdstrand | kyrofa: ok, fyi bug 1614134 | 15:09 |
| mup | Bug #1614134: optionally start daemon only if all interfaces are connected <Snappy:New> <https://launchpad.net/bugs/1614134> | 15:09 |
| jdstrand | that took longer than I expected to capture | 15:09 |
| kyrofa | jdstrand, that's lovely, thank you for taking the time! | 15:11 |
| jdstrand | np | 15:11 |
| jdstrand | mvo: hi! https://github.com/snapcore/snapd/pull/1598 should no longer have the Blocked tag. I think Reviewed should be reviewed too so a snappy team member can review it (I +1'd it) | 15:14 |
| mup | PR snapd#1598: interfaces: implement a fuse interface <Reviewed> <Created by stgraber> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1598> | 15:14 |
| jdstrand | mvo: oh | 15:14 |
| jdstrand | nm | 15:14 |
| mvo | jdstrand: :) | 15:15 |
| jdstrand | mvo: but that actually brings up the question on these labels | 15:15 |
| jdstrand | mvo: are how they are used by the team documented somewhere? | 15:16 |
| jdstrand | mvo: (I can't change them, which is ok, but I don't know when to ask for them to be removed) | 15:16 |
| mvo | jdstrand: not sure if they are documented. can you add/remove them? if so, feel free to adjust as needed, i.e. when you are done and its no longer blocked, jus trmeove it | 15:16 |
| jdstrand | (or added) | 15:16 |
| mvo | jdstrand: yeah, I think niemeyer needs to add you so that you can edit the labels, I think you should definitely be able to do that | 15:16 |
| niemeyer | Huh.. I'd expect that to be the case already | 15:17 |
| niemeyer | jdstrand: Try now.. | 15:18 |
| niemeyer | jdstrand: You were not in the committers team, which is an error on my end | 15:18 |
| jdstrand | niemeyer: I have a gear icon now | 15:19 |
| jdstrand | thanks! | 15:19 |
| niemeyer | It's a bit funny that this is the case.. | 15:20 |
| niemeyer | Why would people need write access to the repository just to be able to change a label on an issue? | 15:20 |
| jdstrand | yeah, those seem quite different things indeed | 15:20 |
| niemeyer | jdstrand: I mean, you should have write access regardless, but I can see many other cases where simply having the person as part of the project should be enough | 15:21 |
| * jdstrand nods | 15:21 | |
| jdstrand | I also find it curious that some things in the githug interface update without a reload, but others do not | 15:22 |
| jdstrand | haha, githug | 15:22 |
| jdstrand | github* | 15:22 |
| jdstrand | eg, Open -> Merged. why does that need a reload? | 15:23 |
| * jdstrand shrugs | 15:23 | |
| sergiusens | jdstrand I see your are now showing the love for git ;-) | 15:23 |
| jdstrand | apparently :) | 15:24 |
| jdstrand | seriously though-- I really like git's branching | 15:24 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| * zyga is stuck on %patch0 | 15:52 | |
| zyga | Pharaoh_Atem: want to help me figure out why a patch (which works perfectly fine) doesn't apply with %patch0 -p1 | 15:55 |
| mup | PR snapd#1691 closed: many: add `snap download` command that downloads into /var/lib/snapd/download <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1691> | 15:55 |
| Pharaoh_Atem | zyga: fuzz is zero by default | 15:55 |
| Pharaoh_Atem | if you need a different fuzz value, you'll need to override it | 15:56 |
| zyga | no, the patch should apply perfectly | 15:56 |
| zyga | I have no idea why it behaves this way | 15:56 |
| mup | PR snapcraft#718 closed: Fix bug lp:1586546 allowing setup.py to work on some projects <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/718> | 15:56 |
| zyga | I unpacked the tarabll, git added everyting | 15:56 |
| zyga | tweaked one line and exported the commit | 15:56 |
| zyga | the same tatics worked with snap-confine | 15:56 |
| zyga | why does pastebin doesn't work on fedora | 15:57 |
| bergkatten_ | noise, I have snapstore on my localhost:5000 :) is there a builtin way to control who can access it? | 16:00 |
| noise][ | bergkatten_: nope! | 16:00 |
| noise][ | it's super dumb and simple :) | 16:00 |
| noise][ | no batteries included | 16:00 |
| bergkatten_ | true :) | 16:01 |
| mup | PR snapcraft#682 closed: Extending the created yaml from `snapcraft init` <Created by wandrewkeech> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/682> | 16:02 |
| mup | PR snapcraft#727 closed: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <https://github.com/snapcore/snapcraft/pull/727> | 16:02 |
| zyga | Pharaoh_Atem: http://paste.ubuntu.com/23064997/ | 16:07 |
| zyga | Pharaoh_Atem: the actual patch is http://paste.ubuntu.com/23065021/ | 16:08 |
| Pharaoh_Atem | you really should move those service files and stuff | 16:08 |
| zyga | Pharaoh_Atem: snap-confine is done, snapd is next | 16:09 |
| zyga | Pharaoh_Atem: perhaps I should just ship them separately for now | 16:09 |
| zyga | Pharaoh_Atem: this is how the build fails http://paste.ubuntu.com/23065052/ | 16:10 |
| Pharaoh_Atem | what happens when you run patch with fuzz=0 by hand? | 16:10 |
| Pharaoh_Atem | does it work? | 16:10 |
| Pharaoh_Atem | it should fail | 16:10 |
| * zyga checks | 16:11 | |
| zyga | it works okay | 16:11 |
| zyga | I suspect there's something in how I run %setup that makes it broken | 16:11 |
| zyga | but I cannot guess what, catting the file just before %patch showed expected content | 16:12 |
| qengho | What's the state of snappy on a rasp pi 3 these days? I'd like to have snappy on classic, if possible. | 16:27 |
| ogra_ | not sure there are classic pi3 images beyond the mate ones (which arent really official) | 16:28 |
| qengho | http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz | 16:28 |
| ogra_ | we have pi3 all-snap images in the works though ... just follow mvo's instructions from the ML and use the ubuntu-device-flash snap | 16:29 |
| ogra_ | qengho, i doubt that has a pi3 uboot | 16:29 |
| ogra_ | (kernel and rootfs should work though ) | 16:29 |
| zyga | Pharaoh_Atem: I'll ignore the patch, I have no idea why it fails | 16:32 |
| zyga | Pharaoh_Atem: I'll just copy the service file into the package | 16:32 |
| Pharaoh_Atem | yeah, you could have distro specific service files as extra sources and just copy them in that way | 16:33 |
| zyga | Pharaoh_Atem: I'll use a patch for now (hopefully a patch to a new file will work ok) | 16:34 |
| zyga | Pharaoh_Atem: I'll work on fixing this upstream next | 16:35 |
| zyga | Pharaoh_Atem: and perhaps they will be required for selinux later on | 16:35 |
| Pharaoh_Atem | yeah | 16:36 |
| Pharaoh_Atem | by the way, if you want to shortcut on patch application, you can use %autopatch -p1 | 16:36 |
| Pharaoh_Atem | or use %autosetup -p1 in place of %setup | 16:36 |
| Pharaoh_Atem | if you'd rather have git apply the patches, you can use -S git instead of "-p1" and add "BuildRequires: /usr/bin/git" | 16:37 |
| zyga | yep, that worked | 16:38 |
| zyga | yeah, I know about autosetup :-) I remember hrw blogging about it | 16:38 |
| Pharaoh_Atem | %autosetup / %autopatch will apply the patches in the order listed in PatchXX | 16:38 |
| Pharaoh_Atem | hrw blogged about it after I asked about because I didn't know about it :P | 16:39 |
| zyga | my goal as both upstream and pacakger is to have less patches :) | 16:39 |
| * zyga is so cold today | 16:39 | |
| zyga | it's raining *again* | 16:39 |
| Pharaoh_Atem | it's 81F/27C here and partly cloudy with no rain | 16:39 |
| zyga | it's probably around 10C now | 16:40 |
| zyga | and windy | 16:40 |
| zyga | *holidays* :D | 16:40 |
| zyga | Pharaoh_Atem: one more fix and I will ask you for a re-review | 16:42 |
| Pharaoh_Atem | okay | 16:42 |
| Pharaoh_Atem | by the way, don't forget to file a bug against fedora-release: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=fedora-release | 16:44 |
| zyga | yep, I'll do that shortly | 16:44 |
| zyga | where should I upload patches that go along my spec files? | 16:44 |
| Pharaoh_Atem | that's why you make SRPMs :) | 16:44 |
| Pharaoh_Atem | so that people can download everything and look at it | 16:44 |
| Odd_Bloke | I'm trying to switch from the copy plugin to the dump plugin, and I'm getting: "[Errno 39] Directory not empty: '/root/parts/git-deps/install'" just after Building starts. What does this mean? | 16:45 |
| zyga | Pharaoh_Atem: ah | 16:45 |
| zyga | right :) | 16:45 |
| zyga | uploading -5 srpm now | 16:45 |
| Odd_Bloke | sergiusens: (Perhaps you can help with my above question?) | 16:46 |
| === nacc_ is now known as nacc | ||
| Odd_Bloke | OK, I've shelved fixing that, now I'm just trying to release what I have. | 17:09 |
| qengho | ogra_: What's with the "sudo" in every ubuntu-device-flash execution I've ever seen? | 17:09 |
| Odd_Bloke | I've done a `snapcraft push --release edge <file>` but I'm now getting "- Download snap "git-deps" (1) from channel "edge" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/MlfzKnSBHbOsx7wuOxnTsflAEQEU3mjA_1.snap)" when I run `snap install --edge git-deps`. | 17:10 |
| Odd_Bloke | Is there a step I'm missing to make this publicly available? | 17:10 |
| Odd_Bloke | (And, also, I think I'm logged-in, so shouldn't I be able to install it regardless?) | 17:10 |
| mup | PR snapcraft#695 closed: Add process-dependency-links option to Python plugins <Created by OddBloke> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/695> | 17:17 |
| mup | PR snapcraft#734 opened: python plugins: add process-dependency-links option <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/734> | 17:17 |
| mhall119 | zyga: where are the docs for defining a plug using an interface with parameters? | 17:17 |
| sergiusens | Odd_Bloke hey, speaking of the devil, was just refactoring to get your constraints stuff in | 17:19 |
| * sergiusens reads | 17:19 | |
| sergiusens | Odd_Bloke means you want to wait for 2.15 (or use master) wrt dump/copy | 17:20 |
| sergiusens | Odd_Bloke 401 probably means you need to `sudo snap install` or to login | 17:21 |
| zyga | mhall119: I don't think there are any | 17:23 |
| zyga | mhall119: I'm looking at updating the docs as we discussed but I didn't get around to do it yet | 17:24 |
| dobey | how can i found if an installed snap package is removable or not? | 17:24 |
| sergiusens | qengho sudo ubuntu-device-flash because kpartx | 17:24 |
| dobey | err, s/found/find out/ | 17:25 |
| dobey | also, where does the value for "series" come from exactly? | 17:29 |
| dobey | since it doesn't appear to match what's in /etc/lsb-release exactly | 17:29 |
| mhall119 | zyga: can you give me a quick example of how to define a plug for my arduino snap that passes a path to the "serial-port" interface? | 17:31 |
| zyga | mhall119: serial port has no attribute on the plug side, only on the slot side | 17:32 |
| zyga | mhall119: currently there is no way to use the serial-port on classic distributions | 17:33 |
| zyga | mhall119: technicaly the syntax requires the extended form of slot definition, you can see how it looks like here: | 17:33 |
| zyga | https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port_test.go#L53 | 17:35 |
| mhall119 | zyga: ok, so I want to help fix serial-port on classic desktops, where does that work need to be done, in snapd or in ubuntu-core snap? | 17:35 |
| zyga | mhall119: it's not broken, there's no definition on how it would work on classic today; that's definitely snapd but also udev and other parts, definitely would require major features to support | 17:37 |
| zyga | mhall119: sorry :/ | 17:37 |
| zyga | mhall119: this is the dynamic slot problem, we have no solution for that, either in snapd or in a 3rd party snap today | 17:37 |
| mhall119 | so, not as simple as just adding /dev/ttyS* to a snap's apparmor profile? | 17:37 |
| zyga | no | 17:38 |
| zyga | that's not a solution, that's equivalent to --devmode | 17:38 |
| zyga | just use devmode for now | 17:38 |
| mhall119 | but devmode makes it harder to get from the store | 17:38 |
| sergiusens | dobey maybe this can help https://github.com/snapcore/snapd/blob/master/docs/rest.md#v2system-info | 17:39 |
| mhall119 | at least with an interface the user could just connect it manually after install | 17:39 |
| zyga | mhall119: there's no such interface today | 17:39 |
| mhall119 | how is serial-port used today then? Only with gadget snaps? | 17:40 |
| dobey | sergiusens: ah thanks. what about determining if a package is removable or not? getting the details for ubuntu-core doesn't seem to show any value which would relate to being removable | 17:40 |
| zyga | mhall119: you could define a "all-serial-ports" interface or something but please discuss this with jdstrand, the problem is really dynamic plug/slot that has no support in snapd today, then you have to bridge this with monitoring hardware events (perhaps in snapd, perhaps in something that talks to it) and connect/disconnect, etc | 17:40 |
| zyga | mhall119: nobody is using it today in classic | 17:40 |
| zyga | mhall119: it was designed for all-snap systems | 17:40 |
| zyga | mhall119: and there it only supports static devices | 17:41 |
| mhall119 | jdstrand: ping, see above, I'd like to help make serial ports available to confined snaps | 17:41 |
| mhall119 | popey: ^^ might be more complicated than we though | 17:41 |
| zyga | mhall119: jdstrand won't change the facts I menitoned above, this is not even designed yet | 17:41 |
| mhall119 | s/might/definitely/ | 17:41 |
| zyga | mhall119: security side is easy (you got it right actually) but it's not the security that is the problem | 17:41 |
| sergiusens | dobey that is a more complicated question; the only thing I can think of is checking the model assertion, I would delegate this question to mvo | 17:41 |
| popey | aww | 17:42 |
| mhall119 | zyga: what specifically is the problem? | 17:42 |
| sergiusens | dobey my plain gut reaction is, if type == app then it is removable (unless stated by the model that it shouldn't) | 17:42 |
| sergiusens | popey why? | 17:42 |
| zyga | mhall119: as i said above, snapd doesn't have any support for dynamic slots or plugs yet | 17:43 |
| mhall119 | zyga: btw, this is me dogfooding community contributions to interfaces, so please forgive all the questions | 17:43 |
| zyga | mhall119: so nothing can monitor the hardware | 17:43 |
| jdstrand | mhall119 (cc zyga): fyi, there is some work in this area with https://github.com/snapcore/snapd/pull/1669 | 17:43 |
| mup | PR snapd#1669: interface: add usb device support to serial-port <Created by jocave> <https://github.com/snapcore/snapd/pull/1669> | 17:43 |
| zyga | mhall119: so nothing can react to serial port hardware being pulugged and unplugged | 17:43 |
| zyga | mhall119: etc etc etc | 17:43 |
| popey | sergiusens: my awww was @ mhall119 | 17:43 |
| jdstrand | I haven't reviewed it all yet and it hasn't gone through the interfaces team yet, so, just fyi | 17:43 |
| jdstrand | I plan on looking that this afternoon | 17:44 |
| sergiusens | popey ah :-) | 17:44 |
| zyga | jdstrand: that's just a hack IMHO, I don't see any serious attempt at fixing this yet | 17:44 |
| sergiusens | kyrofa or josepht mind looking at https://github.com/snapcore/snapcraft/pull/734 ? | 17:44 |
| mup | PR snapcraft#734: python plugins: add process-dependency-links option <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/734> | 17:44 |
| zyga | jdstrand: it is equivalent to just doing "gimme all /dev/ttyUSB* + a few others" | 17:44 |
| zyga | jdstrand: at least IMHO, I always assumed snapd will do device discovery like udev | 17:45 |
| sergiusens | kyrofa josepht the commit made by myself only if tight on time ;-) | 17:45 |
| dobey | sergiusens: hmm, i'm looking for something approximately equal to the "_removable" field in the click manifest of an installed package | 17:45 |
| mhall119 | zyga: if it's not auto-connected, is it so bad? | 17:45 |
| zyga | jdstrand: if snapd had an api for dynamic plugs and slots one could write a snap that exposes serial ports by looking at netlink | 17:46 |
| jdstrand | zyga: re discovery, sure. when we hung out I said mentioned this shouldn't conflict with that | 17:46 |
| jdstrand | but I've not looked at the implementation yet | 17:46 |
| zyga | mhall119: I'm not sure this is related | 17:46 |
| zyga | mhall119: what is needed is design decision | 17:47 |
| zyga | mhall119: there are many ways to get it to "work" | 17:47 |
| zyga | mhall119: depending on how you want to evolve snapd and how plugs and slots and interfaces are expected to work | 17:47 |
| * jdstrand -> food | 17:48 | |
| dobey | sergiusens: hmm, should i file a bug maybe? it seems like for a fully snap based system we'll want to be able to flag certain snaps as not removable, beyond the base os snap, including some apps/scopes perhaps | 17:52 |
| ogra_ | i thought thats a feature of the seed.yaml | 17:52 |
| ogra_ | (though thats just an assumption) | 17:53 |
| sergiusens | dobey yes, that would be controlled by the model assertion, but an api to query would be good | 17:53 |
| dobey | ok | 17:58 |
| mup | PR snapcraft#733 closed: Add the go-buildtags property to the go plugin <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/733> | 18:20 |
| mup | Bug #1614212 opened: Invalid character in ubuntu-core mount name breaks etckeeper <Snappy:New> <https://launchpad.net/bugs/1614212> | 18:22 |
| mhall119 | zyga: jdstrand: if I'm reading this diff right, it will allow snap apps to connect to pre-defined paths like /dev/ttyS0 if the core snap provides a slot for it, or it lets the snap connect to a device by vendor/product id without it having to be defined in the core snap, both of which seem like good approaches to me at least, and would allow for my use case | 18:24 |
| zyga | mhall119: the core snap will never provide this slot | 18:25 |
| mhall119 | zyga: then I can use the vendor/product id for arduino boards | 18:25 |
| mhall119 | which doesn't require a pre-defined slot, if I understand this patch | 18:26 |
| sergiusens | josepht this needs updating https://github.com/snapcore/snapcraft/pull/705 | 18:35 |
| mup | PR snapcraft#705: parser - Remove namespacing and subparts <Created by josepht> <Conflict> <https://github.com/snapcore/snapcraft/pull/705> | 18:36 |
| josepht | sergiusens: yeah, I'm working on improving the coverage, should be ready soon. | 18:36 |
| sergiusens | josepht sounds good :-) | 18:38 |
| mup | PR snapd#1692 opened: asserts: add serial-proof device assertion <Created by matiasb> <https://github.com/snapcore/snapd/pull/1692> | 18:48 |
| dobey | elopio: are you "Leo Test" ? | 18:48 |
| flyingHorde | Hey all | 18:50 |
| flyingHorde | is there anyone here ? | 18:50 |
| flyingHorde | I wanted to ask about deduplication | 18:50 |
| flyingHorde | We can use hash algorithms for all binaries, store them in central folder with the hash as their file name and use hard link from that folder to the isolated folder of the application | 18:51 |
| mup | PR snapcraft#664 closed: New plugin: Script (runs bash scripts) <Created by monsterjamp> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/664> | 19:02 |
| ssweeny | zyga, you left a comment in my udisks PR that /media is bind-mounted with snap-confine. How can I be sure I'm using snap-confine with my snaps? I have ubuntu-core 16.-4.1 rev 230 on my raspberry pi right now and I'm still getting "read-only filesystem" errors | 19:16 |
| stgraber | jdstrand: I posted a generic-ish response to the bug. Would be good to have him confirm that he's in devmode (so no blocked syscalls or sendmsg being denied by confinement) and ideally get an strace to confirm that he did manage to grab a handle to the right netns | 19:19 |
| stgraber | jdstrand: in theory, so long as you can open /proc/PID/ns/net, you should be able to setns into the network namespace of the task (you need to be root or also attach to the user namespace first) and the netlink interface to move devices between network namespaces is supposed to use the same check in kernel | 19:21 |
| stgraber | jdstrand: what typically gets in the way is: being able to actually see and open the handle, being allowed to call the right syscalls and having the right capabilities (at least net_admin but I suspect sys_admin too) | 19:22 |
| zyga | ssweeny: do you have /usr/lib/snap-confine? | 19:27 |
| zyga | ssweeny: snap-confine aka ubuntu-core-launcher is used by all snaps | 19:28 |
| ssweeny | zyga, nope | 19:28 |
| ssweeny | though I do have /usr/share/doc/snap-confine | 19:28 |
| ssweeny | so some version of it should be installed | 19:28 |
| zyga | ssweeny: I bet you have snap-confine or ubuntu-core-launcher (u-c-l is the old name) | 19:28 |
| zyga | ssweeny: I don't know which version you have though, sorry | 19:29 |
| ssweeny | zyga, is there some other way I can test with snap-confine? | 19:31 |
| zyga | ssweeny: ion classic systems you can have reasonably up-to-date snap-confine | 19:32 |
| zyga | ssweeny: the core snap is built automatically too but probably in the non-stable channel | 19:32 |
| ssweeny | zyga, the core snap I'm using id from the edge channel | 19:32 |
| zyga | ssweeny: on an all-snap system /media is always read only | 19:33 |
| zyga | ssweeny: my remark was for classic | 19:33 |
| qengho | What means "all-snap"? | 19:33 |
| ssweeny | ah | 19:33 |
| zyga | ssweeny: I'm sorry | 19:33 |
| zyga | qengho: a distribution that is meade entirely from snaps | 19:34 |
| ssweeny | zyga, is that a deliberate choice or just that no one's come up with a compelling reason to do otherwise yet? :) | 19:35 |
| jdstrand | stgraber: thanks for the feedback. I'm going to play with it a bit and may have some other questions | 19:38 |
| zyga | ssweeny: on an all-snap image everyting is comprised of snaps, there are very few writable "holes", /media is not one of them; | 19:40 |
| sergiusens | elopio is this bad news https://github.com/snapcore/snapcraft/pull/734 ? | 19:41 |
| mup | PR snapcraft#734: python plugins: add process-dependency-links option <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/734> | 19:41 |
| sergiusens | elopio the immediate fail? | 19:41 |
| ssweeny | zyga, fair enough | 19:42 |
| sergiusens | kyrofa mind adding your resulting discussion to https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1607459 and mark the bug appropriately? | 19:44 |
| mup | Bug #1607459: type:os should prevent adding "confinement" to the snap.yaml <Snapcraft:Triaged by kyrofa> <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1607459> | 19:44 |
| ssweeny | zyga, related question: I recently noticed that trying to mount a directory (in /run/media/...) silently fails when doing so from inside a snap. No errors in any logs that I can see, and udisks seems to think that it worked but the "mounted" directory is empty and nothing shows up for it in /proc/mounts | 19:44 |
| kyrofa | sergiusens, right yes of course, thanks for the reminder | 19:44 |
| ssweeny | zyga, just running mount from the command line works | 19:44 |
| ssweeny | but the snap is calling the system mount AFAICT. there's no mount command inside the snap | 19:45 |
| === ljp is now known as lpotter | ||
| zyga | ssweeny: because snaps run in a mount namespace | 19:47 |
| ssweeny | ah, crap | 19:48 |
| zyga | ssweeny: those mounts are visible only to the process that performed them | 19:48 |
| zyga | ssweeny: you could use a specially designed bind mount to overcome this | 19:48 |
| zyga | ssweeny: because of shared subtrees and a little bit of magic | 19:48 |
| zyga | ssweeny: http://www.zygoon.pl/2016/08/snap-execution-environment.html | 19:49 |
| ssweeny | zyga, thanks! I'll look into it | 19:53 |
| jdstrand | sergiusens: how do I use the dump plugin to replace copy? I have something in ./bin, do I did: | 19:54 |
| jdstrand | parts: | 19:54 |
| jdstrand | wrapper: | 19:54 |
| jdstrand | plugin: dump | 19:54 |
| jdstrand | source: bin/ | 19:54 |
| jdstrand | sergiusens: that didn't seem to work: [Errno 2] No such file or directory: '/home/jamie/bzr-pulls/snap-netns-test/prime/bin/sh' | 19:54 |
| zyga | jdstrand: question, how would you feel if interfaces had a way to drop symlinks into hostfs (derived from what interface code says and $SNAP_NAME) | 19:56 |
| zyga | jdstrand: use case is to have snaps integrate into classic distros | 19:56 |
| jdstrand | zyga: can you give an example? | 19:57 |
| jdstrand | sergiusens: I guess a tar file is the only way? | 19:57 |
| sergiusens | jdstrand did the stuff in bin get dumped into the prime directory (sans bin)? | 19:57 |
| zyga | jdstrand: dropping a symlink to an .xml file in /usr/share/gnome-something-something/ for wallpapers | 19:57 |
| jdstrand | sergiusens: it did | 19:58 |
| qengho | jdstrand: I've seen similar error when not snapping from scratch. I think the dependency tree is broken. | 19:58 |
| jdstrand | I guess bin/bin? | 19:58 |
| sergiusens | jdstrand yes, or maybe use organize as give it some miles :-) | 19:58 |
| sergiusens | organize:\n sh: bin/sh\n | 19:58 |
| sergiusens | iirc that should work | 19:58 |
| jdstrand | zyga: so /usr/share/gnome-something-something/snap.some.wallpaper -> /snap/some/current/wallpaper (or similar)? | 19:59 |
| elopio | sergiusens: is this the same problem as the one in telegram? | 19:59 |
| sergiusens | elopio yes | 19:59 |
| jdstrand | sergiusens: ok, thanks! | 19:59 |
| zyga | jdstrand: yes, (with .xml extension) | 19:59 |
| sergiusens | elopio seems to be running now after enought retries | 19:59 |
| zyga | jdstrand: (that would be in interface code) | 19:59 |
| zyga | jdstrand: it would be something that the core snap would have a slot for on classic, the interface would auto-connect | 20:00 |
| zyga | jdstrand: in all snap systems the interface could do something else that is still meaningful | 20:00 |
| jdstrand | zyga: I'm not opposed to the concept. iirc relying on symlinks is somewhat frowned upon within snappy, but if niemeyer is signs off on it, that's fine. the only thing wrt security is that snaps are providing data that is being fed to unconfined processes | 20:02 |
| jdstrand | zyga: and that can be scary. but that can be disussed on an interface by interface basis | 20:02 |
| zyga | jdstrand: the interface here is wallpapers, I agree this is tricky | 20:03 |
| zyga | jdstrand: symlinks because the location is hardcoded | 20:03 |
| zyga | jdstrand: and because there's no apps there, just content | 20:03 |
| jdstrand | this gets to the heart of the classic desktop is not designed for untrusted apps/data | 20:04 |
| jdstrand | (from a security standpoint) | 20:04 |
| zyga | jdstrand: yes but this is something that people do already, there's nothing new here | 20:04 |
| jdstrand | I suspect wallpapers is 'ok'. if there are flaws in image libraries we would want to fix them in USNs | 20:05 |
| jdstrand | zyga: sure but we want to be better not 'nothing new' :) | 20:05 |
| zyga | jdstrand: get better by getting adoption, people already google for wallpapers and get them from random websites; | 20:06 |
| jdstrand | I understand that. that is why I made my comment about USNs | 20:06 |
| zyga | jdstrand: get them on snaps first :) | 20:06 |
| zyga | jdstrand: USN is CVE for ubuntu? | 20:06 |
| jdstrand | Ubuntu Security Notice. it is a *fix* for a CVE in Ubuntu | 20:07 |
| zyga | ah, I see | 20:07 |
| zyga | +1 on that :) | 20:07 |
| jdstrand | if a snap provides a crafted file that does bad stuff, we want to fix that image library in a USN | 20:07 |
| jdstrand | cause that bad stuff could happen in libreoffice, the browser, etc | 20:08 |
| sergiusens | elopio or here, are you happy with https://github.com/snapcore/snapcraft/pull/734 ? | 20:32 |
| mup | PR snapcraft#734: python plugins: add process-dependency-links option <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/734> | 20:32 |
| elopio | sergiusens: yes | 20:36 |
| sergiusens | thanks | 20:37 |
| mup | PR snapcraft#734 closed: python plugins: add process-dependency-links option <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/734> | 20:38 |
| mhall119 | zyga: sergiusens: are we still waiting for snapd to support snaps defining runtime environment variables? | 20:49 |
| zyga | mhall119: yes | 21:02 |
| sergiusens | robert_ancell hi there, do you think you will have time to look into https://github.com/snapcore/snapcraft/pull/670 | 21:04 |
| mup | PR snapcraft#670: Remove .la files generated by autotools <Created by robert-ancell> <https://github.com/snapcore/snapcraft/pull/670> | 21:04 |
| sergiusens | mhall119 I am glad zyga responded, I am waiting still but also have bigger plans for this | 21:05 |
| robert_ancell | sergiusens, ok | 21:05 |
| qengho | What's the bug tag to report a problem with seccomp filter? "snappy-interface"? | 21:12 |
| kyrofa | qengho, snapd-interface, I believe | 21:13 |
| mup | Bug #1614269 opened: tor package on ARMHF crashes on filtered syscall "personality" <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1614269> | 21:14 |
| mup | PR snapd#1689 closed: spread: disable re-exec to always test development tree <Created by kyrofa> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1689> | 21:17 |
| zyga | Pharaoh_Atem: done :) | 21:19 |
| zyga | mhall119: though it is much closer now, I believe we can switch to snap-exec within the next release | 21:20 |
| mup | PR snapcraft#735 opened: Load the remote parts only when needed <Created by elopio> <https://github.com/snapcore/snapcraft/pull/735> | 21:20 |
| Pharaoh_Atem | zyga: btw, you probably should ship in /etc/sysconfig/snapd the environment config value to turn off the self-update/re-exec thing that snapd can do | 21:20 |
| zyga | Pharaoh_Atem: is there something special I need to do with files in /etc? | 21:21 |
| la_juyis` | anyone awake? :) | 21:21 |
| zyga | Pharaoh_Atem: I can make that change easily, will that file be read by systemd and passed to snapd environment? | 21:21 |
| zyga | la_juyis`: always | 21:21 |
| Pharaoh_Atem | yes | 21:21 |
| la_juyis` | zyga, yes! | 21:21 |
| zyga | Pharaoh_Atem: let me try that :) | 21:22 |
| Pharaoh_Atem | %config(noreplace) %{_sysconfdir}/sysconfig/snapd | 21:22 |
| Pharaoh_Atem | that goes in %files | 21:22 |
| zyga | Pharaoh_Atem: thanks! | 21:22 |
| la_juyis` | anyone knows if there's problems with the snap store? Download snap "snappy-debug" (22) from channel "stable" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/DVAzG29Avl1Cn5s1nLXGzyQ0vi9v87Jw_22.snap) | 21:22 |
| zyga | what does noreplace mean? | 21:22 |
| Pharaoh_Atem | it means that the default behavior switches from backing up the existing config to .rpmsave files and writing a new one to installing the new config as .rpmnew | 21:23 |
| stgraber | jdstrand: ok, so I think I figured out what's going on in https://bugs.launchpad.net/snappy/+bug/1611444 | 21:23 |
| mup | Bug #1611444: Cannot share a namespace between apps in a SNAP <Snappy:New> <https://launchpad.net/bugs/1611444> | 21:23 |
| Pharaoh_Atem | then when someone runs a tool like rpmconf, it'll give people the option of handling it | 21:23 |
| Pharaoh_Atem | this only matters if the user/admin modifies the config | 21:23 |
| Pharaoh_Atem | otherwise, it works like any other file | 21:23 |
| stgraber | jdstrand: it's the same issue we ran into with lxcfs & lxd, the separate mntns prevents openvswitch from seeing the other network namespaces as those are referenced through bind-mounts under /run/netns. | 21:24 |
| stgraber | jdstrand: so the first app creates the path in /run/netns and sets up the bind-mount. Second app can see /run/netns/<name> but it sees it as an empty file rather than as the magic netns reference that should be mounted over it. | 21:24 |
| zyga | Pharaoh_Atem: I see, thanks | 21:25 |
| zyga | Pharaoh_Atem: modified locally, testing to see that it ends up where I expect | 21:29 |
| mup | PR snapcraft#736 opened: Disable internet access during unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/736> | 21:35 |
| zyga | Pharaoh_Atem: disabled | 21:36 |
| Pharaoh_Atem | zyga: we're having an interesting argument about /snap on #fedora-devel | 21:37 |
| Pharaoh_Atem | care to pop in? | 21:37 |
| Pharaoh_Atem | the /snap path is a problem, and figuring out a resolution is tough | 21:38 |
| zyga | Pharaoh_Atem: sure | 21:38 |
| la_juyis` | zyga, care to take a look at http://pastebin.ubuntu.com/23065630/ and maybesuggest something?:) | 21:39 |
| zyga | la_juyis`: in a moment | 21:39 |
| la_juyis` | zyga, sure | 21:39 |
| jdstrand | stgraber: interesting | 21:46 |
| jdstrand | stgraber: how did you fix it with lxd and lxcfs? | 21:46 |
| stgraber | jdstrand: instead of using multiple daemons, we just define one which is a long ugly shell script that starts everything | 21:47 |
| jdstrand | hrmm | 21:48 |
| stgraber | jdstrand: sucks in that we can't have proper monitoring and restart of the different bits we care about, but we could always solve that by bundling our own copy of systemd and spawning that from the wrapper script | 21:48 |
| jdstrand | stgraber: another way to fix it would be to enter the same mount namespace | 21:48 |
| jdstrand | (for snapd) | 21:49 |
| stgraber | jdstrand: right, but you'll run into some problems then | 21:49 |
| jdstrand | stgraber: talking about commands within the same snap | 21:49 |
| jdstrand | stgraber: there was a request for that with a shared /tmp | 21:49 |
| jdstrand | stgraber: what kind of problems? | 21:49 |
| stgraber | jdstrand: my understanding was that interfaces could define bind-mounts and so that was why you wouldn't just have the launcher recycle the same mntns for all apps within the snap | 21:50 |
| * jdstrand notes he never liked the private mount and preferred everyone set TMPDIR | 21:50 | |
| jdstrand | stgraber: we do have the content sharing interface. that makes it so one snap can export a dir read or rw and have it bind mounted into another snap's app-specific area (actually, rw is broken last I heard) | 21:51 |
| jdstrand | we also do other bind mounts into the snap on classic | 21:52 |
| jdstrand | but that is different | 21:52 |
| jdstrand | stgraber: I'm not sure how I see the problem | 21:52 |
| jdstrand | that was phrased weird | 21:53 |
| jdstrand | stgraber: I still don't see what the problem is. can you elaborate? | 21:53 |
| stgraber | so the problem is if you have multiple apps defined within your snap, some using such interfaces (leading to bind-mounts being setup by the launcher) and some which aren't | 21:56 |
| stgraber | right now, they all get to see a view of the filesystem which matches what's declared. If they're using such an interface, the content is there, if they're not, then it's not | 21:56 |
| stgraber | if you have the launcher share the mntns between all apps within a snap, you'll get the same result (as far as mount structure) as if all the apps were using all the interfaces | 21:57 |
| jdstrand | if we got rid of the private mount they'd have access to the imported dir even if it didn't declare it | 21:58 |
| jdstrand | right | 21:58 |
| jdstrand | that's interesting, and may not be a big deal with 'content' but might be with others | 21:58 |
| stgraber | oh yeah, I'm absolutely not advocating for removing the private mount | 21:58 |
| stgraber | my initial thought was to allow for ns reuse in the launcher and setup some kind of ordering so I could say that lxd is to be started after lxcfs. In that case the launcher would re-use the lxcfs mount namespace, unshare it, undo anything that's specific to lxcfs and then apply the lxd-specific mounts. Allowing lxd to see the lxcfs mounts. | 22:01 |
| stgraber | but that design wouldn't work for openvswitch since the daemons will keep creating mounts after startup | 22:01 |
| stgraber | which then wouldn't be visible to the second daemon since you unshared | 22:02 |
| stgraber | so in their case, they do need to use the exact same mount namespace for both (can't use a descendant). They can either do that by just running everything as one "app" or by having the launcher have some way to reuse existing mntns. | 22:03 |
| * jdstrand nods | 22:04 | |
| jdstrand | stgraber: so I guess one option would be to add an argument to snapcraft.yaml to share the mmntns. | 22:04 |
| jdstrand | stgraber: and then document what that means for the snap. perhaps conflicting with any interfaces that use .fstab mounts (eg, content) | 22:05 |
| stgraber | jdstrand: yep, ideally with a way to tell it which should be using a shared mntns. No need for the client tool to be using the shared mntns, but the daemons should have a way to opt into that. | 22:05 |
| jdstrand | stgraber: why wouldn't we extend that to non-daemon commands? | 22:06 |
| stgraber | jdstrand: not saying that we should restrict it to daemons, but that if this is going to conflict with some interfaces, we shouldn't make it a snap level knob, but an app level one. | 22:07 |
| jdstrand | oh I see what you're saying, yes, that makes sense | 22:07 |
| stgraber | jdstrand: so I could say that daemon1, daemon2 and command1 in my snap are using a share mntns, but daemon3 and command2 aren't (meaning that I could then use .fstab mounts stuff for those two) | 22:08 |
| jdstrand | stgraber: ok, I'll capture all this in the bug | 22:08 |
| jdstrand | stgraber: thanks for your help on this | 22:08 |
| stgraber | jdstrand: would be simple enough to even allow for things like: daemon1 and daemon2 use a shared mntns, daemon3 and command1 use a different shared mntns and daemon4 and command2 don't use shared mntns. But use cases for such a setup are likely not that common so a plain boolean knob may be enough :) | 22:09 |
| * jdstrand nods | 22:09 | |
| zyga | la_juyis`: it seems that mono is not aware of where it is running and wants to load files from /usr/lib/mono, try configuring mono for a different prefix (say, /sanp/$SNAP_NAME/current/usr) or teach it about $SNAP (the location of the snap) | 22:16 |
| zyga | la_juyis`: I'm sorry it's too late for me to give you more advice today | 22:16 |
| la_juyis` | zyga, thanks! yeah, i'm going to sleep too :) | 22:16 |
| qengho | On a all-snaps machine, there's no way to alter syslog rules, right? | 22:25 |
| dannf | hey - i created a snap for a sprinkler control app i run on my beaglebone black, but i just realized there are no 16.04 bbb images. can i expect that snap to work on the 15.04 bbb image, or have things evolved too much since then? | 22:39 |
| qengho | dannf: It won't work on 15.04. 15.everything isn't even supported any more, anywhere. | 22:40 |
| qengho | dannf: I have the same trouble. I have a pandaboard. | 22:41 |
| dannf | qengho: ah, ok. hm.. i wonder if should bother trying an elinux 16.04 image, installing snapd, and giving it a go | 22:44 |
| qengho | dannf: Worth a try, but not worth a lot of effort. I think I could foresee that elinux kernel lacking some security facility that snap depends on to be safe. | 22:46 |
| qengho | dannf: and, that rasp pi is pretty darned cheap. | 22:46 |
| dannf | yep - agreed | 22:47 |
| dannf | yeah, but i *have* the bbb + the control kit for it, and it works fine :) don't see throwing that out | 22:47 |
| jdstrand | niemeyer: fyi, for tomorrow, can you take look at bug 1611444? | 22:59 |
| mup | Bug #1611444: Cannot share a namespace between apps in a SNAP <Snappy:Confirmed> <https://launchpad.net/bugs/1611444> | 22:59 |
| jdstrand | niemeyer: it is going to need architect input. Please see all the comments-- the reporter is requesting even more than the initial report and that detail might influence the design/implementation | 23:00 |
| niemeyer | jdstrand: Heya | 23:01 |
| niemeyer | jdstrand: Can you ping me about it tomorrow for us to discuss it, or schedule a call? | 23:01 |
| jdstrand | ok | 23:02 |
| qengho | dannf: There's a beagleblack package, I see. I bet your hardware is supported. | 23:04 |
| niemeyer | jdstrand: Thanks.. the backlog is a bit wild at the moment, so that's the best chance of it not being delayed further | 23:05 |
| qengho | dannf: It's not new. Has a weird version number and owner. | 23:05 |
| dannf | qengho: cool, i'll take a look. right now i'm just trying a newer kernel/upgrade to xenial userspace to see if i can get it working in place | 23:06 |
| niemeyer | jdstrand: btw, | 23:07 |
| dannf | (which i hope means i can run snaps in devmode on ubuntu classic w/o the gadget layer) | 23:07 |
| niemeyer | https://www.irccloud.com/pastebin/x1y6Nkq7/ | 23:07 |
| marcoceppi | trying to use the scons plugin | 23:14 |
| mup | PR snapcraft#735 closed: Load the remote parts only when needed <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/735> | 23:14 |
| marcoceppi | I've got everything building but nothing is going into stage or prime | 23:15 |
| qengho | marcoceppi: Do you have any "stage" or "organize" sections in your YAML? | 23:15 |
| marcoceppi | no | 23:16 |
| marcoceppi | well, yes | 23:16 |
| marcoceppi | I added a stage, to no avail | 23:16 |
| marcoceppi | http://paste.ubuntu.com/23065874/ | 23:16 |
| qengho | marcoceppi: paste the output of building? | 23:16 |
| marcoceppi | everything get's built into parts/fceux/build/usr/ | 23:16 |
| marcoceppi | it | 23:16 |
| marcoceppi | it's pretty long, one second | 23:16 |
| qengho | I mean the stdout. | 23:17 |
| marcoceppi | qengho: running again to capture stdout | 23:17 |
| qengho | marcoceppi: that "--prefix=usr" worries me. | 23:18 |
| marcoceppi | qengho: without it, it tries to install to /usr/local | 23:18 |
| marcoceppi | and the snapcraft command fails | 23:19 |
| marcoceppi | so that puts allthe contents in usr under parts/fceux/build | 23:19 |
| qengho | With it, does it try to install to the install dir? | 23:19 |
| marcoceppi | qengho: http://paste.ubuntu.com/23065876/ | 23:19 |
| marcoceppi | qengho: nothing is in the install directory | 23:19 |
| qengho | marcoceppi: I don't know exactly what to put there, but I suspect it will be something like ../install | 23:20 |
| marcoceppi | qengho: really? there isn't like a magic $SNAP or something I should use? | 23:20 |
| qengho | marcoceppi: It's not magic, and I don't know scons. | 23:21 |
| marcoceppi | apparently no on does, since there's not scons in playpen | 23:21 |
| marcoceppi | I'm trying ../install | 23:21 |
| qengho | marcoceppi: Where it puts it isn't where it will eventually access it. If the build makes the assumption that writing-location == access location at run time, then bad things will happen. | 23:22 |
| marcoceppi | I'm guessing bad things will happen regardless at this point, butttt figured I would try | 23:22 |
| marcoceppi | welp, I got a snap this time | 23:22 |
| qengho | cool. | 23:23 |
| marcoceppi | fonts aren't loading, butt I think most of ti worked | 23:24 |
| qengho | Rock! | 23:24 |
| marcoceppi | it's a gtk app, will that mess things up in a anspa? | 23:24 |
| qengho | Nope. In fact, there may be a helper for fonts because of that. | 23:24 |
| marcoceppi | haha, sweet, I can load roms | 23:25 |
| marcoceppi | where would I find out about font helpers? | 23:25 |
| marcoceppi | qengho: I found this, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1584357 which is the error I got as well. I'll start there | 23:27 |
| mup | Bug #1584357: Snappy GTK applications <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1584357> | 23:27 |
| qengho | marcoceppi: In your YAML, in fceux: add a line after: [ desktop/gtk ] | 23:27 |
| qengho | marcoceppi: and change your command line to command: desktop-launcher $SNAP/bin/fceux | 23:28 |
| qengho | ...I think. | 23:28 |
| marcoceppi | Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'desktop/gtk'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache | 23:28 |
| marcoceppi | after a refresh it still fails | 23:28 |
| qengho | marcoceppi: Start fresh. snapcraft clean; sudo snap remove fceux-nes; ... | 23:30 |
| marcoceppi | qengho: all snapcraft commands against the yaml fail | 23:30 |
| marcoceppi | with the above error message | 23:30 |
| qengho | Oh, I missed that. | 23:30 |
| marcoceppi | is there a way to list parts? | 23:30 |
| marcoceppi | maybe desktop/gtk2 ? | 23:32 |
| nacc | marcoceppi: https://wiki.ubuntu.com/snapcraft/parts | 23:32 |
| nacc | ? | 23:32 |
| nacc | marcoceppi: looks to be gtk2, yeah | 23:33 |
| === JanC_ is now known as JanC | ||
| marcoceppi | qengho nacc much success, thanks! | 23:40 |
| qengho | marcoceppi: Awesome. Thanks for making a package! | 23:41 |
| marcoceppi | qengho: sadly the upstream doesn't seem to interested in it atm, but I'll publish it regardless | 23:42 |
| nacc | marcoceppi: nice! | 23:57 |
| marcoceppi | logically, for snaps that ship GTK applications, how do I present a .desktop file for users? | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!