| seshu | zyga: Do you have the snapd documentation on snap refresh, first boot behavior. | 00:19 |
|---|---|---|
| mup | PR snapcraft#1054 closed: [WIP] snapcraft as a snap <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1054> | 00:50 |
| mup | PR snapcraft#1069 closed: snapcraft.yaml and building in snap directory <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1069> | 00:50 |
| === Mister_Q_ is now known as Mister_Q | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1125 opened: tests: fix the env vars passed to the docker container in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1125> | 01:38 |
| eeight | wow that much people, neat! | 01:52 |
| eeight | is it true that if i publish a snap on myapps.developer.ubuntu.com and send an update, people will get my update automagically after 24h? | 01:52 |
| eeight | also I don't see the documentation for plugs: ... (need to access the webcam) https://snapcraft.io/docs/reference/ | 02:01 |
| mup | Bug #1663091 opened: Mir interface does not auto-connnet <Snappy:New> <https://launchpad.net/bugs/1663091> | 02:02 |
| === markusfluer1 is now known as markusfluer | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | Bug #1663060 opened: Add a title field to snap metadata <Developer registration portal:New> <Snappy:New> <gnome-software (Ubuntu):New> <snapcraft (Ubuntu):New> <snapd (Ubuntu):Triaged> <snapd-glib (Ubuntu):New> <https://launchpad.net/bugs/1663060> | 03:33 |
| mup | Bug #1663103 opened: No snapd API to determine which plugs/slots an app uses <Snappy:New> <https://launchpad.net/bugs/1663103> | 03:36 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1117 closed: [wip] build and push the API docs to github pages <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1117> | 04:30 |
| mup | PR snapcraft#1122 closed: repo: cache stage packages for faster future use <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1122> | 04:52 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#2818 opened: Allow specifying another store via env variable for the download command <Created by morphis> <https://github.com/snapcore/snapd/pull/2818> | 06:05 |
| === durksauce_ is now known as durksauce | ||
| === om26er_ is now known as om26er | ||
| === mpontillo_ is now known as mpontillo | ||
| === thomi_ is now known as thomi | ||
| === eshlox_ is now known as eshlox | ||
| mup | Bug #1662817 changed: some snaps stop working after revert the core snap <Snappy:New> <https://launchpad.net/bugs/1662817> | 06:44 |
| Mirv | ogra_: we have arm64, since the general idea was vivid/armhf/click -> xenial/arm64/snap. of course, armhf would be only a click^Wsnap away in Launchpad. | 06:46 |
| Guest | hi all here | 06:49 |
| Guest | i'm found some new ubuntu-core ami on aws, but i cannot connect to instances via ssh | 06:51 |
| Guest | maybe i need some like `ssh_enabled: True` on instance user data? | 06:51 |
| === Guest is now known as p1gmale0n | ||
| === Dmitrii-Sh_ is now known as Dmitrii-Sh | ||
| liuxg | ogra_, so far, packageproxy works well. However, i find that it does not cache the packages for ppa:ci-train-ppa-service/stable-phone-overlay. when I build my app, this repository always re-downloaded. is this normal? thanks | 07:25 |
| === JanC_ is now known as JanC | ||
| mup | PR snapd#2816 closed: interfaces/builtin/core-support: Allow modifying logind configuration from the core snap <Created by ssweeny> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2816> | 07:52 |
| liuxg | ogra_, ping | 08:06 |
| ogra_ | liuxg, edit /snap/packageproxy/current/config.yaml and add an entry to the "repos" list there ... then restart packageproxy or reboot | 08:23 |
| liuxg | ogra_, really, I do not know the trick. thanks. let me try it :) | 08:24 |
| ogra_ | i.e. like: [ubuntu-overlay,http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu] | 08:24 |
| ogra_ | i must damit i never tried ppas, so no guarantee that it works ... but after all ppas are just archives | 08:25 |
| ogra_ | *admit | 08:25 |
| ogra_ | liuxg, in your sources.list on the client you then use something like: deb http://localhost:9999/ubuntu-overlay xenial main | 08:27 |
| liuxg | ogra_, so, I need to use two places, right? | 08:27 |
| mup | PR snapd#2819 opened: packaging/ubuntu-14.04: inform user how to extend PATH with /snap/bin <Created by vosst> <https://github.com/snapcore/snapd/pull/2819> | 08:28 |
| liuxg | ogra_, one is for the config.xml and the other is sources.list | 08:28 |
| ogra_ | well, like you always do ... on the client you use sources.list and on the server the config.yaml | 08:28 |
| liuxg | ogra_, ok. thanks | 08:29 |
| liuxg | ogra_, , one problem here, /snap/packageproxy/current/config.yaml is read only. | 08:30 |
| liuxg | ogra_, we cannot change the file mannually | 08:30 |
| ogra_ | oh, right, there is a writable version in SNAP_DATA | 08:31 |
| ogra_ | sorry, the above is indeed the wrong location | 08:31 |
| liuxg | ogra_, so, var/snap/packageproxy/current$ , this is the location. but I think it is good to add it to your app by default | 08:32 |
| liuxg | ogra_, so that everyone does not need to manually add it. what do you think? | 08:33 |
| ogra_ | well, once i fixed the config hooks you will just use "snap set" | 08:33 |
| liuxg | ogra_, yeah, I know. | 08:33 |
| ogra_ | this used to work in 15.04 with snappy config, i just havent ported that part yet | 08:33 |
| ogra_ | Mirv, i'd really appreciate that one click ;) i assume we might actually have some users using RPi's for kiosk apps or even with unity8 once it runs smooth | 08:55 |
| kalikiana | +1 | 09:01 |
| ogra_ | (it actualyl runs very smooth btw (i got it running here) it is just still awfully buggy) | 09:03 |
| kalikiana | Meanwhile I'll ask once more: does anyone know about snapcraft on Trusty? The package doesn't seem to be there. I kinda expected snapd and snapcraft to be like a monogamous couple that won't be separated | 09:04 |
| ogra_ | kalikiana, well, they are separate projects | 09:20 |
| ogra_ | kalikiana, ask sergiuens or kyrofa | 09:20 |
| mup | Bug #1663175 opened: chroot not allowed in devmode/strict <Snappy:New> <https://launchpad.net/bugs/1663175> | 09:20 |
| mup | Bug #1663177 opened: "Bad System Call" when using "dbus" snapd interface <Snappy:New> <https://launchpad.net/bugs/1663177> | 09:20 |
| ogra_ | (once they are up) | 09:21 |
| t1mp | kalikiana: I assume that even on trusty, the snaps run against the 16.04.1 ubuntu-core snap, so then they should be built on xenial? | 09:27 |
| kalikiana | Yeah, I guess they are, I tend to see it as part of the same meta thing. | 09:27 |
| === chihchun is now known as chihchun_afk | ||
| kalikiana | t1mp: Right, I would expect the sources for 16.04 to be used. | 09:28 |
| kalikiana | Note: I'm saying this with my user hat on. | 09:29 |
| kalikiana | It makes sense to my mind, but it could be blocking on some bugs. | 09:30 |
| t1mp | didrocks: are the desktop helpers are pulled in from github when building a snap? So then https://github.com/ubuntu/snapcraft-desktop-helpers/commit/82ebfb53afa897f32ac029fd46fe4b7453319037 is effective immediately when I build a snap now? | 09:30 |
| kalikiana | Try it. The answer should be evident? | 09:31 |
| === chihchun_afk is now known as chihchun | ||
| t1mp | right :) | 09:32 |
| didrocks | t1mp: indeed, it's effective immediately. Only if snapcraft.yaml definition changed you need to snapcraft update first | 09:32 |
| t1mp | didrocks: great, thanks. | 09:32 |
| didrocks | (or you will get older snapcraft.yaml content with newer git code) | 09:32 |
| didrocks | yw! | 09:32 |
| kalikiana | didrocks: Do you know if that'll be automated at one point? I find it confusing and potentially error-prone to have to 'snapcraft update' "in case something changed" | 09:33 |
| didrocks | kalikiana: I think it's something to discuss with sergio | 09:33 |
| didrocks | kalikiana: he wasn't against it latest time we did discussed about it | 09:34 |
| didrocks | and yeah, it's error-prone, I got caught myself once :) | 09:34 |
| mup | PR snapd#2820 opened: Add send/recv syscalls for upower-observe interface as required on ARM <Created by morphis> <https://github.com/snapcore/snapd/pull/2820> | 09:40 |
| mup | PR snapd#2821 opened: overlord/ifacestate: setup seccomp security on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/2821> | 09:44 |
| mup | PR snapd#2822 opened: Added a linux framebuffer interface <Created by femdom> <https://github.com/snapcore/snapd/pull/2822> | 09:54 |
| Mirv | ogra_: armhf platform snap now available in the store (candidate, beta and edge channels) | 10:12 |
| * ogra_ hugs Mirv | 10:13 | |
| ogra_ | (and his cat) | 10:13 |
| kalikiana | lol | 10:15 |
| tsdgeos | jdstrand: are you the one to talk about apparmor/snap socket() call accepting/rejecting ? | 10:25 |
| liuxg | ogra_, after I change the config.yaml and sources.list, it still fetches from the server. is there anything I did worngly? I have rebooted the machine. sources.list http://paste.ubuntu.com/23959907/, /var/snap/packageproxy/current/config.yaml http://paste.ubuntu.com/23959909/ | 10:27 |
| ogra_ | liuxg, looks all fine to me ... and you did apt update and removed the old ppa entries from the clients sources ? | 10:28 |
| ogra_ | liuxg, note that the ppa bits might be in sources.list.d/ | 10:30 |
| liuxg | ogra_, previously, I used "sudo add-apt-repository ppa:ci-train-ppa-service/stable-phone-overlay" to add the ppa. do you mean I need to use "sudo add-apt-repository -r" to remove it? | 10:30 |
| ogra_ | yeah | 10:31 |
| liuxg | ogra_, ok. I got it. thanks | 10:31 |
| ogra_ | as long as you have it in sources.list (or .d/ ) it will indeed be used | 10:31 |
| liuxg | ogra_, http://paste.ubuntu.com/23959927/, this is it. so I need to remove it, right? | 10:32 |
| ogra_ | right | 10:32 |
| ogra_ | and the next apt update should actually show it using ubuntu-overlay then | 10:33 |
| zyga | re | 10:34 |
| zyga | tsdgeos: hey, how can I help you | 10:37 |
| tsdgeos | zyga: so i'm trying to figure out if it's on purpose that we're denying this call without the network plug | 10:37 |
| tsdgeos | socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT); | 10:37 |
| zyga | definitely | 10:37 |
| tsdgeos | this is basically udev connecting to it's socket | 10:38 |
| tsdgeos | so it's not a network connection | 10:38 |
| tsdgeos | s/it's/its | 10:38 |
| zyga | tsdgeos: yes but before recently we didn't do argument filtering in seccomp | 10:38 |
| zyga | tsdgeos: even now I don't think we will allow this in the network interface | 10:38 |
| tsdgeos | zyga: why? | 10:38 |
| zyga | tsdgeos: there should be a dedicated netlink interface as netlink is rats nest of stuff | 10:38 |
| zyga | tsdgeos: netlink is privileged | 10:38 |
| tsdgeos | so basically any app using udev won't be functional? | 10:39 |
| zyga | tsdgeos: any app using netlink will need a correct interface | 10:39 |
| zyga | tsdgeos: (security is hard) | 10:39 |
| zyga | tsdgeos: what exactly do you need to do? | 10:39 |
| zyga | tsdgeos: often there's an easier solution | 10:39 |
| tsdgeos | no :D | 10:39 |
| tsdgeos | you know i'm using qml that uses the ubuntu-ui-toolkit that uses QtSystemInfo that uses udev | 10:39 |
| tsdgeos | and udev uses that socket | 10:40 |
| tsdgeos | sure i can rewrite the world | 10:40 |
| liuxg | ogra_, if I have another computer pointing to the server, does it need to have any authorization? I have not tried it yet. | 10:41 |
| zyga | tsdgeos: I see, this needs to be discussed with the security team, my rough feeling is that it may require patches to qt or a review of what is allowed once you have a netlink socket | 10:41 |
| zyga | tsdgeos: jdstrand is the right person for that, yes | 10:41 |
| tsdgeos | ok | 10:41 |
| ogra_ | liuxg, nope, it just acts like a http server | 10:41 |
| ogra_ | no auth required | 10:41 |
| tsdgeos | zyga: so what's the best way to discuss this? a bug? an email? if a bug, where, in launchpad? | 10:41 |
| ogra_ | but make sure your sources.list is correct indeed | 10:41 |
| liuxg | ogra_, so, is there any security issue?: ) | 10:41 |
| liuxg | yeah, I will have a try for it. thanks | 10:41 |
| zyga | tsdgeos: bug is a first idea, yes, file it on launchpad.net/snapd, tag it with #snapd-interface tag | 10:41 |
| ogra_ | well, some hacker could DOS your disk by downloading the whole archive i guess :) | 10:42 |
| tsdgeos | zyga: ok, will do, thanks | 10:42 |
| liuxg | ogra_, yeah, that is what I am thinking :) | 10:42 |
| ogra_ | but beyond that it is just a copy of deb packages in the end | 10:42 |
| ogra_ | no risk in that | 10:42 |
| tsdgeos | Mirv: meanwhile i guess you can patch qtsystems with my patch so we get reduced functionality instead of a crash :D | 10:42 |
| liuxg | ogra_, yeah, I got it. just joking :) | 10:43 |
| zyga | tsdgeos: I would love to know what happens after you have that netlink socket | 10:43 |
| zyga | tsdgeos: if you can add that to the code it would be fantastic | 10:43 |
| tsdgeos | reads from it afaics | 10:43 |
| zyga | tsdgeos: sure but what exactly is being looked for | 10:43 |
| tsdgeos | zyga: what do you mean? "what is being looked for" | 10:45 |
| zyga | tsdgeos: so you read from it, what happens then | 10:45 |
| zyga | tsdgeos: what information is being accessed | 10:45 |
| zyga | tsdgeos: what's the goal of QtSystemInfo | 10:45 |
| tsdgeos | gives you system info | 10:45 |
| zyga | which is what exactly? | 10:46 |
| tsdgeos | in this particular case it's telling us if you have keyboard/mouse attached | 10:46 |
| zyga | tsdgeos: thanks, please attach this to the bug as well | 10:49 |
| tsdgeos | will do | 10:51 |
| liuxg | ogra_, you are right. the second time is super fast! | 10:54 |
| ogra_ | ;) | 10:54 |
| liuxg | ogra_, previously, it took almost one hour to build it :( | 10:55 |
| ogra_ | wow, bad | 10:55 |
| liuxg | ogra_, yes, this is why your solution is super. I will try to use another machine to access it. | 10:55 |
| t1mp | didrocks: great, thanks. | 11:11 |
| t1mp | heh, I thought I sent that message 1.5h ago ;) | 11:11 |
| t1mp | why do I get DEPRECATED: Custom plugins should now be placed in 'snap/plugins'. | 11:12 |
| t1mp | when I don't have custom plugins? | 11:12 |
| t1mp | plugin: nil and plugin: dump don't seem custom to me. | 11:12 |
| kalikiana | t1mp: Do you have a folder parts/plugins? | 11:14 |
| t1mp | kalikiana: no | 11:14 |
| === chihchun is now known as chihchun_afk | ||
| kalikiana | Hmmm maybe something in a cloud part? | 11:15 |
| didrocks | could be, desktop helpers don't have though | 11:16 |
| didrocks | unsure about the other you get | 11:17 |
| t1mp | I use after: [desktop-ubuntu-app-platform] | 11:18 |
| t1mp | it has plugin:make | 11:18 |
| t1mp | but that doesn't sound like a "custom plugin" to me | 11:18 |
| kalikiana | Right, it's not | 11:20 |
| didrocks | yeah, there is no custom plugin in my helper | 11:23 |
| didrocks | could be a snapcraft bug, would be interesting to either report or retrace in the code what triggers it | 11:23 |
| didrocks | also, having the plugin name in the deprecation notice would worth a bug :) | 11:24 |
| didrocks | to see what it's complaining about | 11:24 |
| kalikiana | +1 | 11:29 |
| === hikiko is now known as hikiko|ln | ||
| === ronnie is now known as Guest72753 | ||
| Guest72753 | Hi guys, I am trying to find out why an electron-based app works in devmode but not in strict, the logs show that a config file can't be written within the snap: /home/osboxes/snap/linkbox/x14/.config/configstore/linkbox-log.json | 12:02 |
| Guest72753 | any clue on what i am missing here? | 12:02 |
| zyga | Guest72753: hey | 12:03 |
| mup | Bug #1663220 opened: Add support to Secret Service APIs <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1663220> | 12:04 |
| zyga | Guest72753: can you pastebin: dmesg | grep DENIED | 12:04 |
| Guest72753 | sure, just a sec | 12:04 |
| tsdgeos | zyga: took me a while but https://bugs.launchpad.net/snapd/+bug/1663221 | 12:04 |
| mup | Bug #1663221: snap/apparmor default confinement rejects socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT); <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1663221> | 12:05 |
| tsdgeos | zyga: anything else you'd like me to add? | 12:05 |
| zyga | Guest72753: and dmesg | grep type=1326 | 12:05 |
| liuxg | ogra_, if it works for pips, that would be fantastic :) | 12:05 |
| zyga | tsdgeos: thank you, that should be fine for now | 12:05 |
| Guest72753 | zyga: http://pastebin.com/nTTuJSRf | 12:06 |
| zyga | Guest72753: it seems that the writeful snap wants to run "ip", that is not allowed by the base policy | 12:07 |
| zyga | Guest72753: if you disable that do you see any other issues? | 12:08 |
| Guest72753 | how do I disable that? | 12:08 |
| zyga | Guest72753: it's your snap, don't ask me | 12:09 |
| Guest72753 | electron app are chromium based | 12:09 |
| zyga | Guest72753: is electron shelling out to run /bin/ip? | 12:09 |
| Guest72753 | so I don't really know why it needs ip | 12:09 |
| zyga | Guest72753: neither do I; you can use the network-observe plug on your app but it is reserved and your app will be blocked in store review | 12:09 |
| zyga | Guest72753: do you see anything in the second grep I asked for? | 12:10 |
| Guest72753 | no, that one is empty | 12:10 |
| ogra_ | zyga, why woulld it be locked ? will it not just be not connected by default ? | 12:11 |
| zyga | Guest72753: so that's the only problem | 12:11 |
| zyga | ogra_: it's marked as reserved | 12:11 |
| zyga | ogra_: there's a difference between not connecting and not allowing to have it | 12:11 |
| ogra_ | ah | 12:11 |
| zyga | ogra_: if you just don't connect it people will fall for simple sociological attacks "this is how you install my snap" | 12:11 |
| Guest72753 | zyga: so if I add the plug to network-observe plug it will work but not accepted in the store? | 12:11 |
| ogra_ | it will go into manual review | 12:12 |
| zyga | Guest72753: it will not go through automatic review, it will be flagged and will go to manual review | 12:12 |
| Guest72753 | ok | 12:12 |
| zyga | Guest72753: I'm not sure, maybe there's a better idea; I don't have experience with electron | 12:12 |
| zyga | sergiusens: ^^ any ideas (electron based app uses /bin/ip) | 12:12 |
| zyga | sergiusens: is that electron itself? | 12:12 |
| Guest72753 | I'll try doing that and see if it works at least | 12:12 |
| zyga | Guest72753: yeah, go ahead | 12:12 |
| zyga | Guest72753: don't forget to connect the plug | 12:12 |
| zyga | popey: hey, so apart from https://github.com/snapcore/snapd/pull/2815/files | 12:18 |
| mup | PR snapd#2815: release: don't force devmode on LinuxMint "serena" <Created by zyga> <https://github.com/snapcore/snapd/pull/2815> | 12:18 |
| zyga | popey: what else should we whitelist there? | 12:18 |
| zyga | popey: I saw you mention various distros in the os-release-zoo project but I'm not feeling very well and I wanted to confirm those with you | 12:18 |
| Guest72753 | zyga: still doesn't work, this is all the output since I started it: http://pastebin.com/4Y3JRVmG | 12:18 |
| zyga | Guest72753: hmm, so now it wants to ptrace an unconfined process | 12:19 |
| mup | PR snapcraft#1125 closed: tests: fix the env vars passed to the docker container in travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1125> | 12:19 |
| zyga | Guest72753: can you tell me if that's stock electron or is this the app itself? | 12:19 |
| zyga | Guest72753: ptrace is very powerful and ptracing unconfined processes is a clear no-go | 12:20 |
| zyga | Guest72753: also based on this output I don't think you did the plug correctly (maybe it's disconnected) because /bin/ip is still denied | 12:20 |
| zyga | Guest72753: or maybe this is a new feature of recent snapd, I'd have to check | 12:20 |
| zyga | Guest72753: but can you ensure that "snap interfaces" shows that your snap is using the new plug? | 12:21 |
| zyga | (and that it is connected) | 12:21 |
| zyga | popey: ideally, can you please open a bug for each distribution that you know should be whitelisted | 12:22 |
| Guest72753 | zyga: this is the app itself, and you're right the plug is still not there | 12:22 |
| Guest72753 | i'll try again | 12:22 |
| zyga | popey: a distribution should be whitelisted iff: it uses the ubuntu kernel, it uses ubuntu packages (snapd/snapp-confine/...) *without* rebuilding them from source (some decisions are compile time and distro-based) | 12:22 |
| zyga | Guest72753: just rebuild the snap and install it again | 12:23 |
| zyga | Guest72753: if you are in try mode | 12:23 |
| zyga | Guest72753: you need to uninstall/try again | 12:23 |
| zyga | AFAIR | 12:23 |
| zyga | (we should have --retry or something) | 12:23 |
| zyga | Chipaca: ^^ just an idea, have snap try --retry or just smarter try that updates meta/snap.yaml without dropping data) | 12:23 |
| zyga | popey: if you file those bugs please poke me with URLs | 12:24 |
| Chipaca | zyga, a bare "snap try" should work; doesn't it? | 12:24 |
| Chipaca | no uninstall needed | 12:25 |
| Chipaca | (granted it's a bit messy) | 12:25 |
| zyga | Chipaca: won't it artificially stack more "revisions" (which feels wrong) | 12:25 |
| zyga | right | 12:25 |
| Chipaca | well, yes it will, but why would it feel wrong? | 12:25 |
| zyga | maybe try should use a "xx" revison | 12:25 |
| zyga | Chipaca: people get into all kinds of mess with try | 12:25 |
| Chipaca | zyga, ? | 12:25 |
| zyga | Chipaca: you remove a directory and it's all wonky | 12:26 |
| Chipaca | `xx` as in not `x1`? | 12:26 |
| ogra_ | hmm ? does try actually bump the revision unconditionally ? | 12:26 |
| zyga | Chipaca: and the way to fix that is only sensible if you know how snapd works | 12:26 |
| Chipaca | ogra_, of course | 12:26 |
| * ogra_ wouldnt expect that | 12:26 | |
| zyga | Chipaca: yes, xx as a special-special revision | 12:26 |
| Chipaca | ogra_, just like snap install --dangeroos ./potato.snap | 12:26 |
| Guest72753 | zyga: this is it right? http://pastebin.com/1eHFpdzT | 12:26 |
| ogra_ | ah, i thought try just spawns the snap | 12:26 |
| Chipaca | ogra_, i'd love to know what spawning a snap means :-D | 12:27 |
| zyga | Guest72753: yes | 12:27 |
| zyga | "spawn more snaps" | 12:27 |
| ogra_ | dunno, execute it and stuff in it | 12:27 |
| zyga | ogra_: snaps are just zip files ;-) | 12:27 |
| ogra_ | without actually installing over | 12:27 |
| ogra_ | lies ! you cant unip them :P | 12:27 |
| zyga | (fancy zipfiles) | 12:27 |
| ogra_ | *unzip | 12:28 |
| Chipaca | ogra_, so, a snap is just a filesystem-in-a-file | 12:28 |
| Guest72753 | zyga: it does show but at the end of snap interfaces: - writefull:network-observe | 12:28 |
| ogra_ | yeah | 12:28 |
| Chipaca | ogra_, "snap try" uses the directory directly | 12:28 |
| Chipaca | as if it were mounted already (it does a bind mount) | 12:28 |
| ogra_ | right, so there is no reason to bump the revision every time | 12:28 |
| mup | PR snapcraft#924 closed: New plugin: jhbuild <Created by attente> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/924> | 12:28 |
| Chipaca | ogra_, there totally is | 12:28 |
| ogra_ | why is that ? if you end the try the revision is free again, no ? | 12:29 |
| Chipaca | yes | 12:29 |
| Chipaca | and revert of a try would be fun | 12:29 |
| ogra_ | so you could just re-use | 12:29 |
| zyga | Guest72753: you need to connect that now | 12:29 |
| zyga | Guest72753: snap connect writefull:network-observe | 12:29 |
| Chipaca | ogra_, yes, we could reuse, but that would involve a bunch of special-casing for something that is trying hard not to be that different from installing the snap | 12:30 |
| ogra_ | heh, k | 12:30 |
| Guest72753 | zyga: yeah, that works and the app works again | 12:31 |
| Guest72753 | zyga: will the user have to do this? | 12:31 |
| imexil | Hi, it's been about 6 month since I last was building a snap package. At the time there was an issue that if your snap depended on TeXLive you basically had to include it yourself which makes the snap quite big. Does any one know if there is now a way to make use of an existing TexLive installation? | 12:32 |
| ogra_ | we have a content sharing interface now so you could roll a texlive snap you can share ... | 12:32 |
| ogra_ | and there is a way to build classic snaps ... whihc are essantially debs in a new dress | 12:33 |
| imexil | could you point to some up to date docs on that sharing interface and how to use it? | 12:33 |
| imexil | oh the classic snap would be interesting too. | 12:34 |
| ogra_ | but that will only work on classic systems (ubuntu-server, ubuntu desktop etc) | 12:34 |
| imexil | ah right. | 12:34 |
| ogra_ | using the content sharing stuff would make it more future proof for running on an all-snap image later | 12:34 |
| ogra_ | i guess classic is a good quick start way though | 12:35 |
| imexil | well upstream has already switched to appimage (because of the texlive issue) | 12:35 |
| imexil | I was hoping to make them consider snap again if this TeXLive thing was fixed | 12:36 |
| ogra_ | to build a classic snap you can just use ""confinement: classic" in your snapcraft.yaml ... and make sure to not use any interfaces at all (they are not available in classic mode) | 12:36 |
| imexil | interface == plug? | 12:37 |
| mup | PR snapcraft#1115 closed: kernel plugin: fix kernel snap layout <Created by lool> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1115> | 12:37 |
| ogra_ | well, socket and plug ... | 12:38 |
| imexil | any doc you can link to? | 12:38 |
| ogra_ | or i think we call them "slot" not socket now | 12:38 |
| ogra_ | on the snpcraft side you only use plug though | 12:38 |
| ogra_ | https://docs.ubuntu.com/core/en/reference/interfaces/index | 12:39 |
| sergiusens | zyga: seems app specific | 12:39 |
| imexil | so documentation is still spread around snapcraft.io and docs.ubuntu and dev.*** ? ;-) | 12:40 |
| * sergiusens is not paying too much attention to irc these days as it is only open on one box, the one with fixed networking | 12:40 | |
| ogra_ | imexil, snapcraft docs are on snapcraft.io ... general docs are on docs.u.c | 12:40 |
| imexil | right. | 12:40 |
| imexil | But interfaces are a snap thing right? | 12:41 |
| ogra_ | https://snapcraft.io/docs/core/interfaces | 12:41 |
| imexil | OK thanks! | 12:41 |
| ogra_ | so you might want tostart with snapcraft.io ... for more detauls you have then docs.u.c | 12:41 |
| ogra_ | *details | 12:41 |
| Mirv | tsdgeos: your patch will land via https://bileto.ubuntu.com/#/ticket/2456 | 12:44 |
| === hikiko|ln is now known as hikiko | ||
| popey | zyga: https://bugs.launchpad.net/snapd/+bug/1663041 | 12:48 |
| mup | Bug #1663041: Snap packages install but can't be run on Zorin OS <snapd:New> <https://launchpad.net/bugs/1663041> | 12:48 |
| Guest72753 | does anyone know if there a way to automate `snap connect x:network-observe ` upon installation? | 12:49 |
| ogra_ | popey, geez, you hand people your pinky and they want the whole hand ! should be happy they can install them ! | 12:49 |
| ogra_ | </trump sound off> | 12:50 |
| popey | zyga: https://bugs.launchpad.net/snapd/+bug/1663226 | 12:51 |
| mup | Bug #1663226: Snap packages install but can't be run on Peppermint OS <snapd:New> <https://launchpad.net/bugs/1663226> | 12:51 |
| * popey builds a wall around ogra_ | 12:51 | |
| * ogra_ turns the music up | 12:51 | |
| imexil | ogra_: So I tried classic mode. But I have a conflicting ubuntu-core snap which snap won't remove. Any idea | 12:56 |
| imexil | http://pastebin.ubuntu.com/23960466/ | 12:57 |
| ogra_ | imexil, hmm, i thought that landed already, a new snapd should move you from "ubuntu-core" to "core" ... perhaps i'm wrong though and that version has not landed yet | 12:59 |
| imexil | "snapd is already the newest version (2.21)" | 13:00 |
| ogra_ | yeah, might be the one in -proposed that has this | 13:01 |
| ogra_ | iirc 2.23 | 13:01 |
| imexil | Well it looks like I'm fighting a lost fight here anyway. Upstream has a working cross-distro solution which only takes up 30 MB for the image and no duplicate minimal TeXLive installation required. There is probably no point in putting more energy into snap :-( | 13:02 |
| imexil | That's appimage based there. | 13:02 |
| ogra_ | well, 2.23 should be released this week (or latest next) | 13:03 |
| popey | the alternative is to remove snapd and reinstall | 13:03 |
| ogra_ | alternatively you coudl uninstall snapod and reinstall that ... | 13:03 |
| popey | which is what I did to switch from ubuntu-core to core, as I was in a hurry | 13:03 |
| ogra_ | but that makes you lose all existing snaps | 13:03 |
| popey | yeah | 13:03 |
| imexil | classic mode would not help since it means distro depending again which is kind of the opposite you want. | 13:03 |
| popey | classic mode isn't distro dependent | 13:04 |
| popey | you can install classic snaps on debian 9 | 13:04 |
| ogra_ | yeah | 13:04 |
| mup | PR snapcraft#1127 opened: Release changelog for 2.27 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1127> | 13:04 |
| imexil | well debian derivative dependent then | 13:04 |
| imexil | So I see classic mode now the nicer alternative to build something for deb like systems without having to do deb packaging. Which is nice but does not help when distributing cross distro. | 13:06 |
| popey | i only mentioned debian 9 because that is the only one I've tested. others may well work but i dont run them here | 13:06 |
| ogra_ | theoretically it has no distro limits | 13:06 |
| ogra_ | as long as the libs and binaries are on the host | 13:06 |
| jdstrand | zyga, Guest72753: fyi, in the advent of snap declarations, plugging (almost all) manually connected interfaces does not trigger a manual review | 13:06 |
| ogra_ | jdstrand, thats how i understood it initially ... is that true for "reserved2 too ? | 13:07 |
| ogra_ | *"reserved" | 13:07 |
| jdstrand | zyga: the 'Usage: reserved' stuff needs to get cleaned out. it is all in the base declaration now (I can do that) | 13:07 |
| jdstrand | ogra_: you too ^ | 13:08 |
| ogra_ | ah | 13:08 |
| imexil | ogra_, popey: yes. Well I might give classic a go when the next upstream version of Ipe comes out. For now the PR is send. Thanks again for the help. | 13:08 |
| jdstrand | Guest72753: as for electron using ip-- I have tested electron apps and none of them used ip. I'm not sure why yours is... | 13:08 |
| ogra_ | np | 13:08 |
| jdstrand | ogra_: there is no 'reserved' any more. it is all base declaration. there are only a handful of plugs that trigger a manual review because they are deemed 'super-privileged'. eg, docker-support, snapd-control. network-observe is not one of them | 13:10 |
| ogra_ | ah ! | 13:10 |
| ogra_ | thanks ! | 13:10 |
| jdstrand | np | 13:10 |
| Guest72753 | jdstrand, I think because we're trying to detect proxy though one of electron's packages | 13:10 |
| jdstrand | Guest72753: that would make sense. and with that, you should plug an appropriate interface that grants that | 13:11 |
| jdstrand | zyga: hey, so, on its own, https://github.com/snapcore/snapd/pull/2821 doesn't seem to fix anything because the seccomp profiles are always regenerated and that means they will be regenerated by the new snapd, which means the new policy that snap-confine may not understand. You mentioned a followup PR for compatible seccomp profiles. can you talk to me about that? | 13:12 |
| mup | PR snapd#2821: overlord/ifacestate: setup seccomp security on startup <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2821> | 13:12 |
| Guest72753 | jdstrand: I plugged network-observer as suggested by zyga, and that works, but I was wondering if the user will have to do this manually, or if there's an automated way to do this | 13:12 |
| ogra_ | the user has to do it | 13:13 |
| jdstrand | Guest72753: the user will have to do it manually because network-observe grants privileged access to network information | 13:13 |
| ogra_ | unless you use your snmap inside an all snap image (i.e. an IoT install or such) | 13:13 |
| jdstrand | Guest72753: a gadget snap could also do it | 13:13 |
| ogra_ | there you coudl define the pre-plugged interfaces in the gadget snap of the image | 13:13 |
| jdstrand | Guest72753: you might want to read https://github.com/snapcore/snapd/wiki/Interfaces | 13:14 |
| Guest72753 | jdstrand: thanks I did a few hours ago | 13:15 |
| Guest72753 | trying to figure out how everything works | 13:15 |
| tsdgeos | Mirv: should "Use eg example 1 from en blog 2016 11 16 snapping-qt-apps but with plugs: network" be "Use eg example 1 from en blog 2016 11 16 snapping-qt-apps but *without* plugs: network" | 13:17 |
| jdstrand | Guest72753: ah, there is a blog you might want to read. /me finds it | 13:17 |
| jdstrand | Guest72753: https://blog.labix.org/2016/04/22/snappy-interfaces | 13:17 |
| Mirv | tsdgeos: thank you | 13:18 |
| Mirv | tsdgeos: yes | 13:18 |
| zyga | jdstrand: o/ | 13:26 |
| zyga | jdstrand: noted, thank you | 13:26 |
| zyga | jdstrand: question, how would you feel if a snippet of the base declaration was in each interface? | 13:26 |
| zyga | jdstrand: right now it's a bit spread out | 13:26 |
| mup | Bug #1663175 changed: chroot not allowed in devmode/strict <Snappy:Invalid> <https://launchpad.net/bugs/1663175> | 13:28 |
| jdstrand | zyga: I like the way it is because you can see all of them in one place. it is 'the base declaration' that anyone can see and the tests are in one spot. I don't personally view it as a security backend. I also think we have much bigger fish to fry | 13:29 |
| zyga | not a backend, a dedicated thing | 13:30 |
| zyga | jdstrand: right now it is another thing that everyone has to patch in a secondary file, I wanted to streamline that to just the interface file | 13:30 |
| jdstrand | zyga: I know what you want :) you asked my opinion :) | 13:31 |
| zyga | jdstrand: ack, thanks | 13:31 |
| zyga | jdstrand: I really want to write a few tools like "snap internal policy-dump" or something like that (also for other built-in things) | 13:32 |
| mardy | pstolowski: hi! I updated my snapd with your latest changes to the iface hook branch, but now I'm getting this wehn I try to connect: http://paste.ubuntu.com/23960586/ | 13:33 |
| mardy | pstolowski: did I do something wrong when rebuilding snapd? | 13:34 |
| jdstrand | zyga: we do need that, but the base declaration feels different to me. it is something that snapd applies to interfaces | 13:34 |
| jdstrand | zyga: as opposed to something interfaces provide | 13:35 |
| zyga | jdstrand: kind of but you see why it is connected | 13:35 |
| pstolowski | mardy, no, there is a problem (I think it manifests itself if you used edge before) unrelated to my branch which is being adressed today. zyga can you take a look at that pastebin and confirm? | 13:35 |
| jdstrand | zyga: but, can we discuss https://github.com/snapcore/snapd/pull/2821 and the followup branch. I have a lot of concerns | 13:35 |
| mup | PR snapd#2821: overlord/ifacestate: setup seccomp security on startup <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2821> | 13:35 |
| jdstrand | zyga: first off-- you added quatactl-- that is bad. it was never there and is now granting far more than observe to mount-observe | 13:36 |
| zyga | pstolowski, mardy: known issue: https://bugs.launchpad.net/snapd/+bug/1662489 | 13:36 |
| mup | Bug #1662489: snap-confine failed with: hsearch_r failed: No such process <snapd:In Progress by zyga> <https://launchpad.net/bugs/1662489> | 13:36 |
| zyga | jdstrand: ah, thanks I can correct that quickly | 13:36 |
| zyga | jdstrand: thank you for looking at the current fire, I was about to ask for your review | 13:36 |
| jdstrand | zyga: but I'm quite concerned about the approach and where things are going | 13:36 |
| zyga | jdstrand: yes, let's discuss this now | 13:37 |
| zyga | jdstrand: do you know the context? right now snapd broke everywhere on edge | 13:37 |
| jdstrand | yes | 13:37 |
| zyga | ok | 13:37 |
| jdstrand | I discussed this at length with mvo and in fact triaged the issue to snap-confine vs policy diversion | 13:37 |
| jdstrand | so I'm up on it :) | 13:38 |
| zyga | jdstrand: not sure I follow | 13:38 |
| jdstrand | nm | 13:38 |
| jdstrand | I know the issue | 13:38 |
| zyga | jdstrand: the issue is that snapd runs snap-confine from the system, right? | 13:38 |
| zyga | jdstrand: and that's the old snap-confine | 13:38 |
| jdstrand | yes | 13:38 |
| jdstrand | yes | 13:38 |
| zyga | ok, just checking | 13:38 |
| * jdstrand understands the issue | 13:38 | |
| jdstrand | :) | 13:38 |
| jdstrand | so this is only an issue on classic | 13:39 |
| jdstrand | because on all-snaps, everything is in the os snap. you get the old stuff, or you get the new stuff | 13:39 |
| zyga | jdstrand: it is also an issue on core if you revert | 13:39 |
| zyga | (rollback) | 13:40 |
| ogra_ | yeah | 13:40 |
| ogra_ | writable is unversioned ... | 13:40 |
| jdstrand | (though on all-snaps, I think there is an issue of the policy not being updated on core refresh after reboot, but that is a separate thing) | 13:40 |
| pstolowski | mardy, i think the bug 1662817 which is a duplicate has a workaround | 13:40 |
| ogra_ | not a new prob ... | 13:40 |
| mup | Bug #1662817: some snaps stop working after revert the core snap <Snappy:New> <https://launchpad.net/bugs/1662817> | 13:40 |
| zyga | jdstrand: it's not that separate, see what I wrote on the internal channel | 13:40 |
| zyga | jdstrand: it's a required part of the fix in my eyes | 13:40 |
| jdstrand | zyga: so on core, to fix revert *and* updating policy on refresh, we need a way to say 'trigger policy regeneration for these affected snaps' | 13:41 |
| ogra_ | or have writable live in SNAP_DATA of the core snap ;) | 13:41 |
| zyga | jdstrand: we cannot do that cause the core you revert to doesn't know it should generate profiles and the current core cannot generate old security profiles | 13:42 |
| jdstrand | zyga: yes, I was typing the same thing as you were :) | 13:42 |
| zyga | jdstrand: I think it is fine if stuff is broken for a short while (e.g. rollback now breaks) but we need to plan the general fix | 13:42 |
| jdstrand | zyga: you can if it is designed | 13:42 |
| ogra_ | (that would just make updates really slow since you need to copy all of writable on upgrade) | 13:42 |
| zyga | jdstrand: right, I agree; I just mean that nothing we can do now makes old cores capable of doing this | 13:42 |
| zyga | (this is what I meant by a short while) | 13:42 |
| jdstrand | of course | 13:42 |
| zyga | jdstrand: ok, we're in agreement | 13:43 |
| jdstrand | zyga: but I suggest we talk about fixing core, and then see how fixing classic falls out of that | 13:43 |
| zyga | jdstrand: I think the right fix is to refresh profiles as I described in the card *and* run snap-confine from core | 13:44 |
| zyga | jdstrand: that's the generic solution that will always work when it lands | 13:44 |
| zyga | jdstrand: what I proposed now was a short-term way to unbreak edge | 13:44 |
| jdstrand | let me read the card | 13:44 |
| mvo | zyga: how will that fix the revert problem? | 13:44 |
| * mvo should also read the card | 13:44 | |
| zyga | jdstrand: let's chat over a HO | 13:45 |
| zyga | https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=1 | 13:45 |
| jdstrand | zyga: your approach is too heavy | 13:45 |
| jdstrand | especially when you add apparmor into the mix | 13:45 |
| jdstrand | cause every refresh/revert will unconditionally regenerate/recompile everything | 13:46 |
| jdstrand | this is not theoretical. we have to be very careful with apparmor policy regeneration on arm with lots profiles (eg, on Personal) | 13:47 |
| zyga | jdstrand: not really | 13:47 |
| zyga | jdstrand: we only do that if it is different | 13:47 |
| ogra_ | yeah, we have been bitten badly by that before | 13:47 |
| jdstrand | zyga: 'it' is the build id which is different for every refresh, no? | 13:47 |
| zyga | jdstrand: sorry, I'm in a hangout with mvo here; it would be easier to discuss this together | 13:48 |
| zyga | jdstrand: having two parallel conversations is too much for my head today | 13:48 |
| mardy | pstolowski: thanks! Do you know what are the concrete steps for restoring the seccomp profiles? | 13:50 |
| zyga | jdstrand: we lost you | 13:50 |
| pstolowski | mardy, nope, sorry. they live in /var/lib/snapd/seccomp/profiles but i'm not sure if they will be re-generated if removed manually. zyga will know | 13:52 |
| zyga | pstolowski: they will not, I will make that happen today though | 14:25 |
| zyga | jdstrand: can you re-review and hopefully adjust the outcome on https://github.com/snapcore/snapd/pull/2821 | 14:30 |
| mup | PR snapd#2821: overlord/ifacestate: setup seccomp security on startup <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2821> | 14:30 |
| zyga | jdstrand: I removed quotactl entirely | 14:30 |
| didrocks | sergiusens: hey! Do you have any idea on how I can avoid this workaround: https://github.com/ubuntu/booth-demo-manager/blob/master/snap/plugins/bower.py#L38 ? (with side-effects :/) | 14:31 |
| jdstrand | mvo: ok, fyi only, merged master for seccomp-mknod and pushed. My previous merge with master was 23 hours ago. fingers continue to be crossed :) | 14:33 |
| elopio | wililupy: ping, are you around to help me confirm that the change lool introduced fixes your problem? https://bugs.launchpad.net/snapcraft/+bug/1658177 | 14:34 |
| mup | Bug #1658177: snapcraft kernel plugin puts module and firmware under 15.04-era lib/ directory <Snapcraft:Fix Committed by lool> <https://launchpad.net/bugs/1658177> | 14:34 |
| lool | elopio: hi | 14:35 |
| lool | sergiusens, elopio: I have yet to test whether resulting kernels work as expected; I can say I fixed the layout of the resulting snaps though | 14:36 |
| ogra_ | lool, i think ppisati tried the fix | 14:37 |
| ogra_ | (but had other issues) | 14:37 |
| elopio | lool: /buffer #ubuntu-mir | 14:38 |
| elopio | sorry, wrong command :p | 14:38 |
| * ogra_ flushes #ubuntu-mir from lool again | 14:39 | |
| lool | ogra_: thanks | 14:41 |
| ogra_ | :) | 14:41 |
| elopio | ogra_: why is it that the official kernel snaps are not built using the snapcraft kernel plugin? Is there something you are missing from our side? | 14:41 |
| ogra_ | elopio, yes, and archive signing key :P | 14:42 |
| ogra_ | *an | 14:42 |
| lool | ppisati: just saw your debug on initrd boot with new kernel snap, did you find the issue? | 14:42 |
| ogra_ | elopio, we need the signed deb kernels for secureboot to work ... | 14:42 |
| lool | elopio: the main difference is that they are built from the original debs | 14:42 |
| ogra_ | elopio, so we cant build them from source | 14:42 |
| lool | instead of from source | 14:42 |
| lool | albeit I thought we had a plugin for that too | 14:42 |
| ogra_ | we have a snapcraft.yaml ansd Makefile the kernel team maintains | 14:43 |
| ogra_ | fvor the official kernels | 14:43 |
| elopio | I see. It would be nice to have a test that builds the official kernel from source, just to check our plugin. And that doesn't need signature. | 14:44 |
| ogra_ | you can surely do that as long as you dont upload them to the store under the same name | 14:44 |
| elopio | of course :D I'll make sure this just builds, the runner won't even have credentials. | 14:45 |
| ogra_ | note though that we also pull in extra binaries ... like the raspberry-pi wlan firmware package on the pi kernels and linux-firmware on the generic ones | 14:45 |
| elopio | ogra_: do you know where is the source for the debs? | 14:45 |
| mup | PR snapd#2820 closed: interfaces/builtin: add send/recv syscalls for upower-observe interface as required on ARM <Created by morphis> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2820> | 14:45 |
| ogra_ | the source for the debs or for the snap builds from debs ? | 14:45 |
| ogra_ | the git trees are on kernel.ubuntu.com if you mean that | 14:46 |
| ogra_ | ask the kernel team for the right branch etc though ... i never get that right :PÖ | 14:46 |
| elopio | yes, I meant that. Thanks ogra_, I'll ask. | 14:47 |
| elopio | ppisati: ping. Can you please tell us about the kernel issues you are still having? We are trying to make a release soon, and it would be great to have all of that fixed. | 14:49 |
| sergiusens | ogra_: to be fair you can do the same trick that's done with the deb but with the snap instead | 15:01 |
| ogra_ | ? | 15:01 |
| mup | PR snapd#2813 closed: tests: filter ubuntu-core systems for authenticated find-private test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2813> | 15:01 |
| ogra_ | trick ? | 15:01 |
| ppisati | elopio: loic: with loic's patch applied to snapcraft, i can build a correct kernel snap | 15:03 |
| sergiusens | ogra_: the signing | 15:03 |
| ogra_ | sergiusens, there is no trick | 15:03 |
| ppisati | elopio: loic: now i'm fixing the config of the 96boards's snapcraft snapcraft demos, sicne it was missing some required options | 15:04 |
| ogra_ | sergiusens, the ubuntu-archive key which only gets used during archive builds needs to be used | 15:04 |
| sergiusens | ogra_: I was told the deb was built, intercepted or pulled out of the archive, signed and resubmitted | 15:04 |
| ppisati | e.g. mmc_sdhci <- no mmc on boot | 15:04 |
| ogra_ | sergiusens, nope | 15:04 |
| sergiusens | ogra_: that's the summary steve gave me | 15:04 |
| ppisati | and apparently it's missing something else, but i think it's the ext4=m being the problem here | 15:04 |
| ppisati | elopio: lool: i'll send a patch to snapcraft once i'm done | 15:04 |
| ogra_ | sergiusens, i think you think about the way it is done if you need a *different* kernel | 15:04 |
| sergiusens | ogra_: it can still be signed with snapcraft by using an `install` scriptlet | 15:05 |
| ogra_ | sergiusens, how ? | 15:05 |
| lool | ppisati: ok, so board specific issues - cool | 15:05 |
| lool | ppisati: thanks for the update | 15:05 |
| ogra_ | sergiusens, you need *all* the binaries signed with a key you dont have access to | 15:05 |
| ogra_ | only the archive builders can use this key | 15:05 |
| ppisati | elopio: BTW, we have snapcraft.yaml in our kernel tree (at least for xenial) | 15:06 |
| ogra_ | so you need a deb built in the archive in any case ... sure you can loop that through with snapcraft somehow ... but why | 15:06 |
| ppisati | elopio: if you clone the xenial tree, git checkout the raspi2 or snapdragon branch | 15:06 |
| ppisati | elopio: you can rebuild a kernel snap from there | 15:06 |
| ogra_ | ppisati, oh, yeah, if you use ext4=m you need to include ext4 in the initrd with a snapcraft option | 15:10 |
| zyga | re | 15:10 |
| ogra_ | ppisati, can you file a bug, iirc your initrd was just hanging, we can add a check for /proc/filesystems and error out | 15:12 |
| ogra_ | that would have made this clearer and saved debugging | 15:12 |
| lool | didrocks: sorry, might have asked this recently already, but where's the most recent electron snap template I can hand someone? | 15:13 |
| lool | morphis_: hey, would you have a gadget.yaml example showing interface connections from gadget? | 15:14 |
| lool | (ideally of privileged interfaces) | 15:14 |
| didrocks | lool: I don't think we have any. I didn't tackle one myself and was told that all electron apps are different | 15:15 |
| didrocks | lool: I guess the telegram one from sergiusens could be handy | 15:15 |
| lool | didrocks: oh wow really | 15:15 |
| didrocks | sergiusens: did you see my question btw about the bower.py workaround? :) | 15:16 |
| lool | didrocks: hmm I dont see electron anywhere in the telegram snap, isn't it qt? | 15:16 |
| lool | (https://github.com/sergiusens/telegram-snap/blob/master/snapcraft.yaml) | 15:16 |
| didrocks | it's Qt, but I really thought it was electron-based | 15:17 |
| didrocks | my bad then | 15:17 |
| seb128 | Trevinho and flexiondotorg worked on electron examples I think | 15:17 |
| seb128 | Trevinho, flexiondotorg, ^ | 15:17 |
| Trevinho | lool: it's all qt... | 15:18 |
| Trevinho | lool: check this for an upstreamable version which... I already have | 15:18 |
| Trevinho | lool: https://github.com/3v1n0/telegram-snap/ | 15:18 |
| lool | this is to allow someone to create a webapp snap | 15:18 |
| lool | basically they have the URL/HTML and they need to ship a runtime around it | 15:18 |
| zyga | jdstrand: I've updated the PR as instructed | 15:19 |
| ogra_ | lool, why not https://github.com/fcole90/fcole-hexgl-webapp | 15:19 |
| ogra_ | (uses ubuntu-app-platform though) | 15:19 |
| mup | PR snapd#2815 closed: release: don't force devmode on LinuxMint "serena" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2815> | 15:19 |
| morphis_ | lool: what do you mean by that, a gadget with applications using plugs/slots or a gadget causing plugs/slot of certain snaps automatically connected? | 15:20 |
| lool | morphis_: a gadget preinstalling snaps and connecting them to the right plugs/slots | 15:21 |
| morphis_ | lool: you can't do both from a gadget | 15:23 |
| morphis_ | preinstalling snaps is a thing ubuntu-image/snap prepare-image does by setting up the seed.yaml in your image | 15:23 |
| lool | (in old snappys we used to be able to force certain snaps to remain installed, might be where my confusion comes from) | 15:24 |
| lool | morphis_: so I can preinstall snaps in my ubuntu-image call, and I can pre-connect them in the gadget yaml? | 15:25 |
| morphis_ | that is what you do via an validation assertion | 15:25 |
| morphis_ | no, no pre-connecitng in gadget.yaml | 15:25 |
| morphis_ | that is handled via snap-declaration | 15:25 |
| lool | so it has to be per snap | 15:25 |
| morphis_ | yes | 15:25 |
| lool | but it could potentially be in the image only and not the store | 15:25 |
| morphis_ | sure | 15:26 |
| morphis_ | the image is build with a set of assertions and a set of .snap files | 15:26 |
| lool | I guess we can add authorities to the image | 15:26 |
| lool | and sign the snap-declaration by whoever | 15:26 |
| morphis_ | lool: not sure about this, right now the assertions are signed by canonical | 15:28 |
| lool | https://github.com/3v1n0/electron-quick-start-snap/blob/master/snapcraft.yaml looks like a good electrn snap template | 15:28 |
| morphis_ | pedronis can comment on that maybe who is able to sign them | 15:28 |
| lool | morphis_: ok | 15:28 |
| lool | I think if it's per snap it can probably come from the store anyway | 15:28 |
| lool | even if it's preloaded | 15:28 |
| Trevinho | lool: I've probably to update it though | 15:29 |
| Trevinho | I've not touched it for some time | 15:29 |
| morphis_ | but as they express some kind of critical policy I guess its only the device maker or the store instance (canonical) | 15:29 |
| Trevinho | as per https://github.com/3v1n0/electron-quick-start-snap/issues/1 ... | 15:29 |
| Trevinho | probably the launcher should be better to be desktop-gtk2 though, | 15:31 |
| ppisati | ogra_: it was more than a single issue | 15:32 |
| ogra_ | ppisati, well, but missing ext4 is definitely one we can catch | 15:33 |
| ogra_ | and print a pretty message for you so you dont need to dig | 15:33 |
| ppisati | ogra_: the hang was due to missing mmc, it couldn't find it so it was hanging in "wait-for-root" - there are 3 calls, one in fixrtc, another in resize and the third was in the main ubuntu-core fs logic | 15:33 |
| ppisati | then there was ext4 | 15:33 |
| ppisati | and now i'm having a | 15:33 |
| === verterok` is now known as verterok | ||
| ogra_ | but wait-for-root has a timeout | 15:33 |
| ogra_ | it should have returned after 120sec | 15:33 |
| Trevinho | lool: actually 've just thested that exampla and still works, so... yeah, you can start from that if needed | 15:34 |
| ogra_ | or 180 or so | 15:34 |
| ppisati | "can't mount loop device: no space left on device" and i think it's the devloop min count too low ( = 8 atm) | 15:34 |
| lool | Trevinho: yeah, I actually think I handed it to some folks who told me it was working, wasn't sure it was this exact one | 15:34 |
| ogra_ | wow, never seen that one | 15:34 |
| ppisati | ogra_: yes, but there are 3 in a row, so if you don't wait long enough, you never land in busybox | 15:34 |
| Trevinho | lool: that is the one I did long time ago, I've updated it some time ago to use desktop launchers, but it should work | 15:34 |
| ogra_ | yeah | 15:35 |
| ppisati | ogra_: i'm piling up config changes for the snapcraft kernel pluigin example | 15:35 |
| ogra_ | i guess 180sec are also quite long ... | 15:35 |
| ogra_ | even a spinning disk should be ready in less than 1min | 15:35 |
| ppisati | i put some prints inside initrd scripts to see where it was hanging | 15:35 |
| Blu2_ | Out of curiosity, are (graphics) drivers snappable? | 15:38 |
| ogra_ | Blu2_, tricky since they usually have a kernel side component ... | 15:41 |
| lool | jdstrand: do we have an official position on a realtime interface for pthread_setschedparam()? | 15:43 |
| lool | outside of "just do it and that's privileged and needs a snap-declaration" | 15:44 |
| ogra_ | Blu2_, but i.e. in case of a whole image it is easily possible ... i.e. the RPi images we have ship the vc4 driver in the kernel snap and snaps that include gallium can use DRM/KMS and GLES | 15:44 |
| ogra_ | so it depends a bit on the context the snap is used in | 15:45 |
| Blu2_ | hm.. would be awesome to use for example Open drivers for the desktop and proprietary for specific apps | 15:46 |
| ogra_ | if that would be possible from a driver POV ... then you could already do it with debs :) | 15:46 |
| ogra_ | if certain HW is driven by an open driver you wont be able to use the prop. one at the same time with it ... | 15:47 |
| ogra_ | thats not snap specific though | 15:47 |
| Blu2_ | Having multiple drivers installed and only grant one access to a snap or something | 15:47 |
| ogra_ | just a limitation of HW and drivers | 15:47 |
| flexiondotorg | seb128 Yes, I'm working on electron stuff. They are a bit variable in terms of what is required. | 15:47 |
| Blu2_ | I don't know, I'm not too knowledgable about this topic | 15:48 |
| flexiondotorg | electron is still using GTK2+ despite lots of requests to move to GTK3+ | 15:48 |
| ogra_ | Blbut if the HW is already being used by one of them, how do you make the snap use the other ? | 15:48 |
| lool | Blu2_: what you can do is have two kernels snaps and chose one or the other | 15:49 |
| ogra_ | yeah, but not dynamically | 15:49 |
| lool | or a kernel snap with a config/cli to swap, likely with reboot | 15:49 |
| ogra_ | that isnt how garphics hardware works | 15:49 |
| ogra_ | *graphics too | 15:49 |
| nacc | right the hw (lowest layer) seems like it wouldn't support non-exclusive usage | 15:50 |
| nacc | at least that i know of | 15:50 |
| ogra_ | yep | 15:50 |
| ogra_ | i guess you could make it work in SW if you had access to the source of the proprietary driver ... you could split out the common parts and make the higher level switchable ... | 15:51 |
| ogra_ | but then you have two open drivers in the end :) | 15:52 |
| ogra_ | (or two closed ones and a vendior that sues you :P ) | 15:52 |
| ogra_ | (because you broke your NDA) | 15:52 |
| Blu2_ | Hopefully Valve and the community push open drivers further | 15:53 |
| Blu2_ | btw, no steam snap yet :P | 15:53 |
| ogra_ | go ahead ! | 15:53 |
| * ogra_ would use it | 15:53 | |
| elopio | joc: ping. The plainbox provider snap fails to build now. https://travis-ci.org/elopio/snapcraft-de-noche/jobs/200009799 | 15:54 |
| elopio | do you know about that? | 15:54 |
| Blu2_ | Maybe I'll give a try on the upcoming weekends | 15:55 |
| mup | PR snapd#2823 opened: interface/seccomp: sort combined snippets <Created by zyga> <https://github.com/snapcore/snapd/pull/2823> | 15:55 |
| joc | elopio: hi, sorry i've been away for a week, i saw i had a few more comments so i'll check it all | 15:55 |
| jdstrand | lool: pthread_setschedparam isn't a syscall so I'm going to assume that it is using varous sched_* syscalls. 2.23 will allow snaps to modify the scheduler for the calling process. process-control added several syscalls for adjust the scheduler for anything. so, it is available in process-control when you need more than what is in the template | 15:57 |
| lool | jdstrand: yes, it's sched_set_params syscall I think | 15:59 |
| jdstrand | lool: yes, that was one that was added to template and process-control | 15:59 |
| jdstrand | (template for limited use, process-control for anything) | 15:59 |
| elopio | ogra_: this one is for you: https://travis-ci.org/elopio/snapcraft-de-noche/jobs/200009811 We will make sure that snapcraft master builds your kernels every night. | 16:00 |
| lool | jdstrand: I dont understand the "added as a template" part | 16:00 |
| lool | I see it in interfaces/seccomp/template.go | 16:00 |
| lool | and in interfaces/builtin/process_control.go | 16:00 |
| jdstrand | lool: you can use sched_setparam(0, ...) in default template, sched_setparam(anything, ...) in process-control | 16:00 |
| lool | oh ok | 16:01 |
| lool | I need to find what value RR is | 16:01 |
| elopio | joc: hey, but this is not related to your branch :) It's the one in git.launchpad.net/~checkbox-dev/plainbox-provider-snappy | 16:01 |
| jdstrand | lool: again, this is 2.23 | 16:01 |
| lool | ack | 16:01 |
| ryebot | Is there any interface that will give a snap access to /proc/self/cgroup? | 16:02 |
| ogra_ | elopio, sexy ! | 16:03 |
| mup | PR snapcraft#1128 opened: tests: support bzr branches for external tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1128> | 16:04 |
| joc | elopio: aah got you, didn't read that closely enough :) | 16:05 |
| joc | elopio: we don't maintain the packaging repo you are using anymore I'm afraid, we now have a dedicated project here: https://code.launchpad.net/checkbox-snappy | 16:06 |
| elopio | joc: oh, good. I'll update the script. I think I will just build your master branch nightly, unless you think it would be good to build the others too. | 16:07 |
| elopio | ppisati: sorry, I was in a meeting and missed your pings. I'm scrolling back and reading... | 16:08 |
| joc | elopio: well we are building master/edge and beta on every landing, and now have release flow for candiate and stable, so up to you | 16:09 |
| ppisati | lool: there's a bug in the "moving modules and firmare around" fix | 16:10 |
| ppisati | lool: http://paste.ubuntu.com/23961221/ - there are two fw directories now | 16:11 |
| ppisati | elopio: our xenial kernel tree contains a snapcraft.yaml, checkout raspi2 or snapdragon and it should be there | 16:11 |
| ppisati | elopio: so you can rebuild a kernel.snap from there, althougjh it will be slightly different from what we have in the store | 16:12 |
| ppisati | elopio: but it might be a good test for the kernel pluging | 16:12 |
| elopio | ppisati: I see it \o/ http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/snapcraft.yaml Just what I was missing. | 16:14 |
| ogra_ | ppisati, are you sure thats not from inside the dragonboard fw tarball ? | 16:14 |
| elopio | ppisati: the default branch is for the pc image? | 16:14 |
| ogra_ | iirc you unpack a tarball at snap build tiome in this case | 16:15 |
| ppisati | elopio: yep | 16:15 |
| ppisati | ogra_: yep, that come sfrom the firmware tarball, but if we move the /lib/firmware, we should move everything | 16:15 |
| ppisati | ogra_: else wifi won't work | 16:16 |
| ogra_ | yes, but thats nothing the plugin can handle ... should it ? | 16:16 |
| ogra_ | it will just untar | 16:16 |
| ppisati | ogra_: yep, what i mean | 16:16 |
| ppisati | ogra_: before we moved /lib/fw to /fw everything was in one place | 16:16 |
| ppisati | ogra_: ah | 16:16 |
| ppisati | ... | 16:16 |
| ppisati | destination: lib/firmware | 16:17 |
| ppisati | i didn't see that | 16:17 |
| ppisati | f*ck me | 16:17 |
| ogra_ | :) | 16:17 |
| ppisati | ok | 16:17 |
| elopio | :D | 16:17 |
| ppisati | https://github.com/snapcore/snapcraft/pull/1129 | 16:17 |
| mup | PR snapcraft#1129: 96boards: fix the dragonboard example <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1129> | 16:17 |
| ppisati | this fixes the dragonboard example | 16:18 |
| ppisati | mines the fw destination that i just noticed | 16:18 |
| ppisati | *minus | 16:18 |
| mup | PR snapcraft#1129 opened: 96boards: fix the dragonboard example <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1129> | 16:19 |
| elopio | ogra_: before I forget to remind you, tomorrow 16UTC, bring your nice clothes. | 16:21 |
| ogra_ | yeah, i'll iron them ! | 16:21 |
| elopio | you are going the extra mile! so nice of you. | 16:22 |
| mup | Bug #1663303 opened: Running snapcraft on Ubuntu 14.04 fails with a traceback <isv> <Snappy:New> <https://launchpad.net/bugs/1663303> | 16:29 |
| Cynerva | we're trying to snap kubelet and hitting a lot of permissions problems, anyone available to look at these? https://gist.github.com/Cynerva/9150f379cdf1d41aac9ae233597c1f64 | 16:48 |
| Cynerva | lotta cgroup stuff, and a couple others | 16:49 |
| Cynerva | i'm not seeing any obvious interfaces we can pull in | 16:49 |
| Cynerva | any assistance would be appreciated :) | 16:49 |
| sborovkov | Hello, did anyone had an experience building a snap that's uysing python and girepository? I added python3-gi to stage-packages. But application using it fails at runtime | 16:55 |
| kyrofa | Cynerva, are you familiar with the snappy-debug tool? | 17:09 |
| elopio | sborovkov: what's your error? | 17:27 |
| sborovkov | elopio: ImportError: cannot import name GLib, introspection typelib not found | 17:52 |
| sborovkov | elopio: and this ImportError: cannot import name Gio, introspection typelib not found | 17:52 |
| sborovkov | elopio: not sure what it's missing, I see that it has $SNAP/usr/lib/python3/dist-packages/gi | 17:53 |
| zyga | Cynerva: today is a bad day for me but come back tomorrow, I'll help you out | 17:56 |
| Cynerva | kyrofa: i haven't tried snappy-debug, but i see it in the docs now - thanks! | 17:58 |
| Cynerva | zyga: will do, thanks | 17:58 |
| zyga | mwhudson: hey, around? I have a question | 18:01 |
| kyrofa | Cynerva, no problem, that will hopefully give you more helpful errors | 18:03 |
| mup | PR snapd#2821 closed: overlord/ifacestate: setup seccomp security on startup <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2821> | 18:10 |
| mup | PR snapd#2823 closed: interface/seccomp: sort combined snippets <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2823> | 18:10 |
| King_InuYasha | sergiusens: around? | 18:12 |
| elopio | sborovkov: can't you install glib from the deb? | 18:14 |
| sborovkov | elopio: error is that introspection typelib is not found though? And I added python3-gi to stage-packages and it's installed. I also added libglib2.0 to stage packages as well... | 18:16 |
| kalikiana | Hrm, I wish Unity didn't remove snaps whenever they're updated. No idea, though, if that's an issue with Unity or what snapd might be doing with the files. | 18:17 |
| kalikiana | s/snaps/launchers of snaps/ | 18:18 |
| kyrofa | kalikiana, I expect snapd is removing them when disabling, and generating new ones when activating | 18:18 |
| kyrofa | kalikiana, if you run `sudo snap disable <snap name>` do they also disappear? | 18:18 |
| kalikiana | kyrofa: Yep | 18:19 |
| elopio | sborovkov: I mentioned the debs because I remember something similar when I mixed debs and pip packages. But if you are using only debs, then scratch that. | 18:19 |
| kyrofa | kalikiana, please report that | 18:20 |
| kalikiana | Will do | 18:20 |
| elopio | sborovkov: so, I don't know. Feel free to share the snapcraft.yaml with us. If you think this is something that snapcraft is doing wrong, please file a bug in bugs.launchpad.net/snapcraft | 18:20 |
| kyrofa | It might make sense to remove them on disable, but not upgrade | 18:20 |
| sergiusens | King_InuYasha: yes | 18:21 |
| sborovkov | elopio: I actually found similar question https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg01513.html | 18:22 |
| King_InuYasha | sergiusens: did you have a chance to take a crack at refactoring the stage/build-packages backend over the weekend (you briefly mentioned to me last week you were going to take a stab at it) | 18:22 |
| sborovkov | elopio: going to try and see if that helps. | 18:22 |
| kyrofa | jdstrand, how would you feel about making ping available in the default profile? | 18:22 |
| sergiusens | King_InuYasha: I am going to get it signed off for next week as an official sprint task (yeah we are doing agile now :-/) | 18:22 |
| sergiusens | King_InuYasha: I tried to spike it this week but ran out of time | 18:22 |
| King_InuYasha | oh dear :( | 18:23 |
| sergiusens | it is light weight, but still don't like it | 18:23 |
| * King_InuYasha is not much of a fan of agile/scrum/sprint things | 18:23 | |
| kalikiana | kyrofa: Seems there's bug 1646912 for it already | 18:23 |
| mup | Bug #1646912: Snaps disapper from the launcher after an update <Snappy:New> <https://launchpad.net/bugs/1646912> | 18:23 |
| sergiusens | me neither | 18:23 |
| King_InuYasha | I'm one of those "informally agile" people | 18:23 |
| King_InuYasha | the moment you're putting fixed process cycles, it's not really "agile" in my opinion | 18:23 |
| mup | Bug #1646912 changed: Snaps disapper from the launcher after an update <snapd:New> <https://launchpad.net/bugs/1646912> | 18:27 |
| kalikiana | ogra_: FYI seems there's a snapcraft snap in the store now (oddly enough not the one I wrote) and bug 1663303 is kind of answering my question | 18:32 |
| mup | Bug #1663303: Running snapcraft on Ubuntu 14.04 fails with a traceback <isv> <Snappy:New> <https://launchpad.net/bugs/1663303> | 18:32 |
| kalikiana | Although I don't know how "sudo apt install snapcraft --classic --edge" is supposed to work | 18:33 |
| elopio | sborovkov: interesting. | 18:47 |
| ogra_ | kalikiana, ah ! | 18:47 |
| ogra_ | ssweeny, bah ... i did miss that your second case option misses the ;; | 18:48 |
| * ogra_ does a quick fix | 18:48 | |
| ssweeny | ogra_: I've seen the ;; left out after an exit before | 18:48 |
| ssweeny | I thought it was valid | 18:48 |
| kalikiana | fwiw even an actual "snap install --classic --edge" installs fine but doesn't run on Xenial either | 18:49 |
| ogra_ | ssweeny, nope, isnt | 18:49 |
| ogra_ | but at aleast all bits are there now | 18:49 |
| ssweeny | ogra_: ah, my apologies then | 18:49 |
| ogra_ | well, i reviewed it :P no need to apologize | 18:49 |
| kyrofa | Huh... I have a bug report some someone who seems to be unable to resolve domain names from within the snap. Has anyone run into that? | 18:53 |
| ogra_ | nope | 18:54 |
| zyga | kyrofa: yes | 18:55 |
| zyga | kyrofa: on 14.04 | 18:55 |
| ogra_ | ah | 18:55 |
| zyga | kyrofa: is that a classic confinement snap? | 18:55 |
| kyrofa | zyga, no, strict, and on 16.10 | 18:56 |
| kyrofa | Maybe it has something to do with 16.10, I'll fire up a VM | 18:56 |
| mup | PR snapd#2824 opened: overlord: make seeding work also on classic, optionally <Created by pedronis> <https://github.com/snapcore/snapd/pull/2824> | 18:57 |
| zyga | kyrofa: then no | 18:58 |
| zyga | kyrofa: strace would be useful | 18:58 |
| kyrofa | zyga, unfortunately that requires bundling that in the snap, which I have not :P | 18:58 |
| kyrofa | zyga, can't even ping. Figuring out the issue in the first place was awful | 18:58 |
| kyrofa | Still not completely sure that's the issue | 18:59 |
| zyga | kyrofa: building what? | 18:59 |
| zyga | kyrofa: just nsenter and strace ;) | 18:59 |
| kyrofa | zyga, wait... | 18:59 |
| kyrofa | Really? | 18:59 |
| zyga | kyrofa: strace is at /var/lib/snapd/hostfs/usr/bin/strace | 19:00 |
| ogra_ | alll this new fangled stuff | 19:00 |
| ogra_ | nsenter ... tsk | 19:00 |
| kyrofa | ogra_, I didn't know about nsenter either :P | 19:00 |
| ogra_ | yeah | 19:00 |
| ogra_ | zyga keeps all the secrets ! | 19:00 |
| zyga | ogra_: job security | 19:01 |
| zyga | I just have to stop spilling them on irc :) | 19:01 |
| kyrofa | snapd hides the magic, which is cool. I just wish we _also_ hid the magical debug tools | 19:01 |
| kyrofa | Hahaha | 19:02 |
| zyga | ogra_, kyrofa: nsenter -m/run/snapd/ns/$SNAP_NAME.mnt | 19:02 |
| zyga | just don't add space between -m and the path | 19:02 |
| zyga | annoging thing | 19:02 |
| zyga | that runs without confinement | 19:02 |
| ogra_ | stop spilling ! | 19:02 |
| zyga | if you want confinement just snap run --shell | 19:02 |
| zyga | and then fire away | 19:02 |
| zyga | you will need to copy strace somewhere first | 19:02 |
| zyga | but it will work | 19:02 |
| ogra_ | now all the hackers know our backdoors ! | 19:02 |
| zyga | same with gdb | 19:02 |
| zyga | ogra_: nah, WE HAVE FIREWALL ;) | 19:03 |
| ogra_ | great FIREWALL ? | 19:03 |
| zyga | don't you watch TV | 19:03 |
| zyga | it stops _everything_ | 19:03 |
| zyga | based on the evil bit | 19:03 |
| ogra_ | lol | 19:03 |
| kyrofa | zyga, I wish technology had more boring names for things. Then tv shows would actually have to make up the NAMES for the technology they fabricate as well | 19:04 |
| kyrofa | zyga, I want to hear one script that mentions iptables | 19:05 |
| * ogra_ is slightly scrated by TV recently ... there is that reality TV clown in the news all the time ... i stream though :) | 19:06 | |
| zyga | kyrofa: isn't that old-school, iptables got replaced by that ... thing | 19:06 |
| jdstrand | kyrofa: that is a long standing discussion point. it mostly had to do with the fact that it is setuid, therefore we had to allow certain things in the profile that weren't appropriate for the default profile. then there was setuid-less ping made possible by upstream kernel, but it needs distro support (tyhicks would have to comment). I was going to see if a combination of apparmor child profile and seccomp arg filtering might make it possible. that | 19:06 |
| ogra_ | *scared | 19:06 |
| kyrofa | zyga, you must be talking about ip6tables | 19:07 |
| kyrofa | zyga, in all seriousness, are you talking about ufw? It's just a pretty wrapper | 19:08 |
| jdstrand | actually, I think mr robot may have mentioned iptables | 19:08 |
| kyrofa | jdstrand, no way! | 19:08 |
| jdstrand | it may have just been on the screen, I can't remember | 19:08 |
| jdstrand | what would be cool is if mr robot used ufw :) | 19:09 |
| kyrofa | jdstrand, and yeah, ping makes sense. I would also be happy with getent | 19:09 |
| kyrofa | I love ufw | 19:10 |
| tyhicks | the setuid-less ping support has been in the kernel for a long time and support for the kernel feature was recently merged in upstream iputils | 19:10 |
| jdstrand | is getent missing? I think we could at least give it with network | 19:10 |
| kyrofa | jdstrand, seems to be | 19:10 |
| jdstrand | or maybe it too as a child profile, but I don't want too many child profiles. I could to sibling profiles... | 19:11 |
| tyhicks | there's a little bit of distro work needed to enable it but the more important piece of work to do is to understand what old features of setuid ping would regress | 19:11 |
| jdstrand | anyway, I'll think about it | 19:11 |
| tyhicks | setuid-less ping doesn't support everything | 19:11 |
| zyga | kyrofa: no, there's something more recent in the kernel | 19:12 |
| jdstrand | tyhicks: sorta thinking snapd could ship profile snap.ping {} # cool profile name! | 19:12 |
| zyga | kyrofa: something more generic | 19:12 |
| mwhudson | zyga: hello | 19:12 |
| zyga | mwhudson: hey! | 19:12 |
| jdstrand | tyhicks: then network could Px -> snap.ping | 19:12 |
| zyga | mwhudson: I think my question has resolved itself, just bad reading on my part, I incorrectly assumed Elf64_Word is a uint64_t, | 19:13 |
| jdstrand | tyhicks: and maybe, ust maybe I can do enough with seccomp arg filtering to make it work | 19:13 |
| mwhudson | zyga: ah haha | 19:13 |
| jdstrand | s/ust/just/ | 19:13 |
| zyga | mwhudson: silly elf defined that as uint32_t *because THAT's why* | 19:13 |
| tyhicks | jdstrand: do you think spending them time to do that work would be better than enabling setuid-less ping in the distro? | 19:13 |
| tyhicks | s/them time/the time/ | 19:13 |
| jdstrand | anyway, it is something I plan to play with whenlooking at policy for setuid with @euid and @ruid | 19:14 |
| jdstrand | tyhicks: well, the problem is that while it would be fantastic to have setuid ping in Ubuntu, other distros won't have it | 19:14 |
| jdstrand | tyhicks: but, it would be in our core. I guess we'd just need a new enough kernel. that isn't something new for snappy... | 19:15 |
| tyhicks | jdstrand: agreed but no other distros are using confinement | 19:15 |
| tyhicks | oh yeah, it would be in our core snap | 19:15 |
| jdstrand | tyhicks: today. I suspect by series 18 that will change (pending upstreaming work). Debian and suse should be able to just get it | 19:16 |
| zyga | jdstrand: it would be nice to have ping without the +s bit | 19:16 |
| tyhicks | true | 19:16 |
| jdstrand | zyga: it would | 19:16 |
| zyga | jdstrand: maybe just with the capability for the raw socket or maybe the special ping-something-socket (forgot) | 19:16 |
| jdstrand | we could supply an alternate ping too, but people would have to know to use it | 19:17 |
| tyhicks | jdstrand: on other distros that haven't enabled unpriv ping themselves, snapd would have to write to the special sysctl that sets up the guid's that are allowed to use the unpriv ping | 19:17 |
| jdstrand | on core we could update-alternatives it | 19:17 |
| jdstrand | anyway, lots of options | 19:17 |
| tyhicks | yeah | 19:17 |
| jdstrand | tyhicks: ah yes, I forgot that. that is semi-difficult, though possible with snap-confine understanding thing like @ruid and @euid | 19:18 |
| jdstrand | things* | 19:18 |
| * tyhicks nods | 19:18 | |
| zyga | jdstrand: hmm, yeah | 19:19 |
| tyhicks | zyga: fyi, it is just a special socket(2) domain although I can't remember the name of it right now | 19:19 |
| zyga | tyhicks: right, I recall something similar | 19:20 |
| zyga | just-for-ping | 19:20 |
| jdstrand | kyrofa: I'm sure you know this, but ping is in network-observe if you are blocked | 19:27 |
| kyrofa | jdstrand, oh no, not blocked, I'm sorry if I gave the impression | 19:28 |
| jdstrand | you didn't, I just wanted to make sure you weren't | 19:28 |
| kyrofa | jdstrand, I was trying to figure out what was wrong with someone else's system running my snap, and I realized I had no network debugging facilities! | 19:28 |
| kyrofa | jdstrand, it seems like their DNS isn't working from within the snap, so I'm investigating that on my own now, hopefully I can duplicate | 19:29 |
| sborovkov | elopio: yeah that export helped. Also had to export PYTHONPATH for some reason with path to the dir it install girepository to (for some reason it's in a separate directory from all other python packages but whatever). | 19:31 |
| sborovkov | Hi, what's the policy for naming dbus interfaces on core and on classic? I am getting this on core g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.36" is not allowed to own the service "org.screenly.playlist" due to security policies in the configuration file | 19:33 |
| jdstrand | sborovkov: use the "dbus" interface. see https://github.com/snapcore/snapd/wiki/Interfaces#dbus | 19:34 |
| jdstrand | sborovkov: you'll want to: | 19:35 |
| jdstrand | slots: | 19:35 |
| jdstrand | dbus: | 19:35 |
| sborovkov | jdstrand: yeah, but I am in devmode. Seems like I am being prevented from registering this on the system bus by some policy. So I was wondering what's the policy. And what's the policy on the core as we are just in process of migrating to core. | 19:35 |
| jdstrand | name: org.screenly | 19:36 |
| jdstrand | bus: system | 19:36 |
| sborovkov | jdstrand: thanks, and this would help me in devmode as well? | 19:37 |
| jdstrand | sborovkov: are you using 'bus: session' or bus: system' in your yaml? also, is it a session or system service? | 19:37 |
| sborovkov | jdstrand: I was not using anything, just trying to get it running in devmode first. Hmm, we just have daemon: simple so might be that I should register on a session bus? Sorry, last time I was using dbus was like 5 years ago and back then I did not expose any interfaces :-) | 19:38 |
| DedSec | quick question, so i have snap created for rclone but iam trying to have my launchpad auto build use the classic containment so rclone can write to disk for the config files located in the home directory. but as of right now Launchpad's auto build system wont even compile the snap if i use classic instead of strict or devmode | 19:39 |
| jdstrand | sborovkov: ok, if this is using 'daemon: simple', then you are running as root. that implies a system service, so you should use 'bus: system' | 19:39 |
| jdstrand | sborovkov: with devmode, you still need to specify the interface because the interface is what modifies the dbus bus policy | 19:39 |
| jdstrand | sborovkov: so while apparmor would allow it in devmode (it allows everything), dbus-daemon is still going to deny it. dbus-daemon has no concept of devmode, so you need to specify the interfac ein your yaml | 19:40 |
| * jdstrand updates the wiki for that point | 19:41 | |
| jdstrand | sborovkov: fyi, I updated https://github.com/snapcore/snapd/wiki/Interfaces#dbus for the devmode with system bus case | 19:46 |
| sborovkov | jdstrand: understood thanks | 19:47 |
| sergiusens | slangasek: hey, we added a new feature (plugin) in snapcraft that fails on zesty and it seems to be related to Qt itself and not snapcraft (https://github.com/snapcore/snapcraft/pull/1127). We are still running yakkety-armhf to verify this but I wanted to know what our options were | 19:51 |
| mup | PR snapcraft#1127: Release changelog for 2.27 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1127> | 19:51 |
| sergiusens | oh great, the yakkety one timed out... :-/ | 19:52 |
| sborovkov | jdstrand: I did not use not auto-connected interfaces before. So do I need to connect my snap to core:dbus after installation to make it work? | 19:56 |
| jdstrand | sborovkov: actually, no. if you read the page you'll see that the slot implementation uses 'slots' to provide the interface to other snaps | 19:58 |
| jdstrand | sborovkov: the slot side policy for the dbus snap allows you to bind to the well-known name without have to use snap connect | 19:58 |
| jdstrand | having* | 19:58 |
| sborovkov | jdstrand: ok, understood. was confused about that. | 19:58 |
| mup | PR snapd#2825 opened: osutil/build_id: add package for reading Build-ID <Created by zyga> <https://github.com/snapcore/snapd/pull/2825> | 19:59 |
| jdstrand | sborovkov: a client snap that uses: | 19:59 |
| jdstrand | plugs: | 19:59 |
| jdstrand | screenly: | 19:59 |
| jdstrand | interface: dbus | 19:59 |
| jdstrand | bus: system | 19:59 |
| zyga | mwhudson: would you have a moment to review the build_id branch ^^ | 19:59 |
| jdstrand | name: com.screenly | 19:59 |
| jdstrand | sborovkov: would need to 'snap connect foo:screenly screenly:dbus' | 20:00 |
| jdstrand | sborovkov: which allows 'foo' to talk to your screenly service | 20:00 |
| sborovkov | jdstrand: but that's not needed if both services are inside the same snap? | 20:00 |
| jdstrand | sborovkov: with 2.23, no | 20:01 |
| mup | PR snapd#2707 closed: overlord/snapstate: prepare for using snap-update-ns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2707> | 20:02 |
| mup | PR snapd#2776 closed: cmd: use per-snap mount profile to populate the mount namespace <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2776> | 20:02 |
| sborovkov | jdstrand: what if I wanted to make a call to dbus interface that is exposed by service not run as a snap? is that possible with this security implementation? | 20:03 |
| jdstrand | sborovkov: you'd have to be more specific. dbus is fully mediated by snaps and, like files, you need to use the proper interfaces to allow talking to the system dbus services or the services of other snaps | 20:04 |
| sborovkov | jdstrand: alright, understood. and if I have snapd 2.21 I need to use plugs:... code if client and server are both inside the same snap? | 20:05 |
| jdstrand | sborovkov: yes, you would need to plugs the slot you are providing. that is the normal case, but as it happens with dbus, 2.23 added a rule that says "any command within the snap can talk to any other command in the snap over dbus" | 20:07 |
| jdstrand | (caveat being the snap needs to use dbus interface or similar to bind to a well-known name) | 20:08 |
| sborovkov | jdstrand: thanks for assistance and have a good day :) | 20:08 |
| jdstrand | sborovkov: you too :) | 20:08 |
| DedSec | so iam kind of stuck with this snap i created for rclone, rclone uses an .rclone.conf file located in an users home directory be deafult, but whenever i try to configure an remote cloud service with rclone, i get 2017/02/09 20:14:27 Failed to save config file: open /root/.rclone.conf: permission denied. here is what iam using currently with launchbuild to | 20:19 |
| DedSec | automaitcally build and upload https://github.com/Dedsec1/rclone/blob/master/snapcraft.yaml | 20:19 |
| DedSec | i meant launchpad not launchbuild lol | 20:19 |
| zyga | jdstrand: can you please add this to your queue: https://github.com/snapcore/snapd/pull/2775/files | 20:25 |
| mup | PR snapd#2775: cmd: add functions to load/save fstab-like files <Created by zyga> <https://github.com/snapcore/snapd/pull/2775> | 20:25 |
| zyga | jdstrand: it's for snap-update-ns, not setuid critical | 20:25 |
| slangasek | sergiusens: what are you looking for options on? are you asking about releasing the sru before pushing to zesty-proposed? | 20:27 |
| jdstrand | zyga: added to queue. it won't be today though | 20:28 |
| kyrofa | jdstrand, if you have a minute, I could use some advice | 20:29 |
| kyrofa | jdstrand, I have a user of the nextcloud snap (strictly confined) on 16.10 who seems to have DNS issues only in the snap. I've reached that conclusion using only these tests: http://pastebin.ubuntu.com/23962576/ | 20:30 |
| kyrofa | jdstrand, do you agree with that conclusion? | 20:30 |
| jdstrand | kyrofa: the tracebacks at line 14 and 18 indicate something unrelated to dns. I'm not convinced that the traceback at 22 is dns | 20:41 |
| jdstrand | kyrofa: it could be, but it might not be | 20:42 |
| jdstrand | kyrofa: (ie, it could be a bad error message) | 20:42 |
| kyrofa | jdstrand, how would you explain how the traceback at 44 seems to have gotten out, then? | 20:42 |
| kyrofa | i.e. if it wasn't DNS-related, wouldn't it have a similar issue? | 20:43 |
| jdstrand | kyrofa: what if you stage-packages bind9-host and use 'host acme-staging.api.letsencrypt.org'? | 20:43 |
| kyrofa | jdstrand, I guess I could host that on people.canonical and have him give it a try | 20:44 |
| jdstrand | kyrofa: there are no security denials? | 20:45 |
| kyrofa | jdstrand, not unusual ones anyway (/proc/<pid>/mounts) | 20:45 |
| kyrofa | I get those as well and it works fine for me | 20:45 |
| jdstrand | kyrofa: it might be interesting to see the contents of /etc/resolv.conf and friends in the snap and outside | 20:45 |
| mwhudson | zyga: looking | 20:46 |
| jdstrand | kyrofa: since you mentioned 16.10, that implies classic vs all-snaps since we have no all-snaps 16.10 images. is this correct? | 20:46 |
| kyrofa | jdstrand, indeed | 20:46 |
| jdstrand | kyrofa: again, sure you know this, but the mounts stuff would go away if plug mount-observe | 20:47 |
| kyrofa | jdstrand, yeah it doesn't actually seem to hurt anything, so I've left that off | 20:47 |
| * jdstrand nods | 20:48 | |
| jdstrand | it is usually harmless | 20:48 |
| === JanC is now known as Guest72742 | ||
| === JanC_ is now known as JanC | ||
| kyrofa | jdstrand, alright thanks for giving me a few more directions... I wasn't sure where to go next there | 20:49 |
| kyrofa | I hate debugging stuff that I can't duplicate | 20:49 |
| zyga | mwhudson: thanks! | 20:58 |
| zyga | jdstrand: thanks, that's all right | 20:58 |
| mup | PR snapd#2826 opened: overlord: optional device registration and gadget support <Created by pedronis> <https://github.com/snapcore/snapd/pull/2826> | 20:59 |
| mterry | jdstrand: I'm trying to test all the corners of the unity8 plug interface, and I'm having a hard time understanding why I'm seeing an apparmor denial: http://pastebin.ubuntu.com/23962778/ | 21:07 |
| jdstrand | mterry: where did you put that rule? did you reload the apparmor profile? | 21:19 |
| mterry | that rule is from the /var/lib/snapd/apparmor/ file | 21:20 |
| jdstrand | mterry: which one? | 21:20 |
| mterry | /var/lib/snapd/apparmor/profiles/snap.webbrowser-app.webbrowser-app | 21:20 |
| mterry | I thought it was reloaded -- let me reconnect interface and restart apps | 21:21 |
| jdstrand | mterry: ok, if you are reconnecting and stuff, it blows away custom rules | 21:21 |
| * mterry does some testing | 21:22 | |
| jdstrand | mterry: the rule in the paste is correct for the 2nd denial | 21:23 |
| zyga | jjohansen: hey, do you know when can we expect the kernel with your fixes out in the wild (in ubuntu)? | 21:25 |
| jjohansen | zyga: 2 weeks | 21:25 |
| jjohansen | the kernel has a 3 week cadence | 21:26 |
| jjohansen | unless you are talking zesty, and then who knows, it could be sooner | 21:27 |
| mup | Bug #1545871 changed: Be able to query with multiple terms <Click Package Index:New> <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1545871> | 21:30 |
| mterry | jdstrand: ok yeah I was just being dumb -- thanks | 21:31 |
| jdstrand | mterry: np. it isn't obvious that changes are blown away on enable/disable/refresh/etc | 21:32 |
| zyga | jjohansen: thanks | 21:38 |
| mup | PR snapcraft#1130 opened: catkin plugin: produce build-ready staging area <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1130> | 21:38 |
| mup | PR snapd#2814 closed: cmd: add helpers for working with mount/umount commands <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2814> | 21:38 |
| mup | PR snapd#2827 opened: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827> | 21:38 |
| zyga | jdstrand: please add this to your queue: perhaps before the mount entry (and it's shorter): https://github.com/snapcore/snapd/pull/2827 | 21:40 |
| mup | PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827> | 21:40 |
| DedSec | anyone know if launchpad supports snap auto build with an snap using confinement: classic? | 21:47 |
| jdstrand | zyga: added | 21:50 |
| mup | PR snapcraft#1131 opened: lifecycle: hardcode test_core_snap's PATH <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1131> | 22:08 |
| kyrofa | DedSec, not yet, but it will in the next snapcraft release (early next week) | 22:08 |
| DedSec | oh cool | 22:18 |
| DedSec | but for now i can just build it manually and push when needed i guess | 22:19 |
| kyrofa | DedSec, indeed | 22:20 |
| kyrofa | DedSec, keep an eye out for the snapcraft 2.27 release announcement; you'll know to try again | 22:21 |
| DedSec | gotcha | 22:26 |
| DedSec | i mean, iam pretty certain i can get rclone to work fully if i can just get the home plug to allow it to read and write an .conf file to an users home directory | 22:27 |
| lutostag | if anybody can help, I've having trouble with launchpad building snaps for me on anything > xenial b/c of not being able to verify the gpg key... "NO_PUBKEY F1831DDAFC42E99D" https://code.launchpad.net/~lutostag/+snap/easy2fa/+build/21077/+files/buildlog_snap_ubuntu_yakkety_amd64_easy2fa_BUILDING.txt.gz | 22:59 |
| kyrofa | lutostag, we don't recommend doing that anyway-- we don't have a core snap that corresponds to anything other than xenial | 23:00 |
| lutostag | hmm, so if I want to snap with some stage packages > xenial, should I make a ppa for them instead? | 23:01 |
| kyrofa | lutostag, that's one way. Another would be to build them as another part | 23:04 |
| lutostag | I thought someone might say that... ;) | 23:05 |
| kyrofa | lutostag, there are a few issues here. One is that you'll be building with a newer libc than the one on which you'll be running | 23:05 |
| kyrofa | lutostag, another is that snapcraft uses the core snap corresponding to the release on which you're building to be smart and strip out libraries it knows are included in the core snap. But since there is no yakkety core snap, it won't remove anything | 23:06 |
| lutostag | kyrofa: ah, that's why I get the warnings for 'No libraries to exclude from this release', was curious about that | 23:11 |
| lutostag | (when built locally) | 23:11 |
| kyrofa | lutostag, yep, that's it | 23:11 |
| lutostag | kyrofa: ok, I'll see if I can build the prereqs as a part, thanks | 23:14 |
| kyrofa | lutostag, no problem. Give a shout if you need some help | 23:15 |
| snapster | Anyone used bluez snap? | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!