| ogra | kyrofa, they go into edge daily and after manual testing into stable ... in the future we will have different builds for different channels, today edge is the same as stable, just untested | 00:27 |
|---|---|---|
| mup | PR snapcraft#757 opened: Export important project variables <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/757> | 01:05 |
| sergiusens | kyrofa https://github.com/snapcore/snapcraft/pull/757 tell me what you think | 01:52 |
| mup | PR snapcraft#757: Export important project variables <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/757> | 01:52 |
| sergiusens | elopio ^ | 01:52 |
| === JanC is now known as Guest36120 | ||
| === JanC_ is now known as JanC | ||
| liuxg | elopio | 02:15 |
| liuxg | elopio, ping | 02:15 |
| liuxg | previously, on 15.04 ubuntu core, I used the command "sudo snappy hw-assign piglow.sideload /dev/i2c-1" to assign the hw to access the i2c device. On the series 16, we need to use interface, how can I assign the hardware? thank | 02:17 |
| liuxg | does anyone know how to assign a hw on series 16? I used to do on 15.04 like "sudo snappy hw-assign piglow.sideload /dev/i2c-1". thanks | 02:21 |
| kyrofa | liuxg, no such capability exists right now. It will probably utilize hooks in some fashion, which also don't exist right now :) | 03:06 |
| kyrofa | liuxg, that said, you can access to some things via interfaces, as long as the paths don't change | 03:07 |
| liuxg | kyrofa, in that case, I cannot do anything for the moment. I want to get the piglow working. my app is running, but it does not access the hardwware. | 03:07 |
| liuxg | kyrofa, thanks for your reply on this. | 03:08 |
| kyrofa | liuxg, take a look here: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md | 03:09 |
| kyrofa | Do any of those cover your use-case? | 03:09 |
| liuxg | kyrofa, for the i2c-1 device, it seems that it is not covered there. also for the current raspberry pi 2 device, the interfaces are http://paste.ubuntu.com/23087199/. previously, on 15.04, it seems to be more dynamic. as long as the device is available, we can always do the assignment. | 03:12 |
| kyrofa | liuxg, yeah, we'll get there | 03:13 |
| liuxg | kyrofa, so, there will be a way to do that right? I think it should be generic instead of defining an interface for every device on the system. For example, I want to make use of the camera, the camera is there, but we cannot forecast how many more devices are there. on the contrary, the one on 15.04 is more flexible, and the command works for all | 03:14 |
| kyrofa | liuxg, I can't speak for the overall design, but things will definitely get more flexible with hooks | 03:16 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#738 closed: nodjs, gulp plugins: use http_proxy to connect npm registry <Created by m-shibata> <Closed by m-shibata> <https://github.com/snapcore/snapcraft/pull/738> | 05:47 |
| mup | PR snapd#1753 opened: asserts: Add an account-key-request assertion <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1753> | 06:51 |
| mup | PR snapd#1754 opened: tests: fix "tests/main/ack" to not break if asserts are alreay there <Created by mvo5> <https://github.com/snapcore/snapd/pull/1754> | 07:04 |
| mup | PR snapd#1754 closed: tests: fix "tests/main/ack" to not break if asserts are alreay there <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1754> | 07:34 |
| === ant_ is now known as Guest56195 | ||
| zyga | o/ | 08:51 |
| mwhudson | morning zyga | 08:56 |
| mup | PR snapd#1755 opened: tests: remove snap confine workaround <Created by mvo5> <https://github.com/snapcore/snapd/pull/1755> | 09:17 |
| ogra | ubuntu@dragonboard:~$ snap --version | 09:18 |
| ogra | snap 2.12+ppa199-1 | 09:18 |
| ogra | snapd 2.12+ppa199-1 | 09:18 |
| ogra | series 16 | 09:18 |
| ogra | ubuntu 16.04 | 09:18 |
| ogra | mvo, ^^^^ is that right ? | 09:19 |
| ogra | (i see 2.13+ppa206-1 on rpi) | 09:19 |
| zyga | mwhudson: good morning | 09:22 |
| zyga | mwhudson: I'm working on the namespace sharing feature in snap-confine | 09:22 |
| zyga | mwhudson: interested in reviewing the idea? | 09:22 |
| mvo | ogra: looks wrong, we should be on snapd 2.13 | 09:22 |
| mvo | ogra: I can have a look in a bit to ensure we really have 2.13 (or 2.13+something) | 09:23 |
| mvo | ogra: did the /etc/systemd/system.conf.d dir make it? | 09:23 |
| ogra | well, i just did an ubuntu-core rebuild since i thought it was a glitch in the edge PPA ... | 09:23 |
| ogra | yeah, the dirs are in | 09:23 |
| ogra | ("user" too) | 09:23 |
| mvo | ogra: yay! | 09:24 |
| mvo | ogra: thanks a bunch, plano people will love you for this | 09:25 |
| ogra | mvo, there you go https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 09:25 |
| ogra | doesnt build for all arches | 09:25 |
| ogra | (only amd64, armhf and i386) | 09:25 |
| mvo | ogra: oh, meh :( | 09:25 |
| ogra | mvo, i changed the arch list for that PPA, but s390x is missing yet ... (i guess i need to ping the LP team) | 09:28 |
| ogra | mvo, do you know how we can trigger a build ? | 09:28 |
| mvo | ogra: cool, I think thats not too terrible | 09:28 |
| ogra | mvo, oh, and btw, kernel snap builds work end to end too now, incvluding auto-upload and publishing (with a hacked snapcraft in the PPA though) | 09:30 |
| newcomer25 | The whole Law is fulfilled in one statement: ‘You’ll love your neighbour as much as yourself’ - Galatians 5:14 | 09:32 |
| newcomer25 | God bless you all and have fun using snappy! | 09:32 |
| ogra | what was that ? | 09:35 |
| mup | PR snapd#1756 opened: asserts: add some stricter checks around format <Created by pedronis> <https://github.com/snapcore/snapd/pull/1756> | 09:40 |
| mvo | ogra: yay | 09:42 |
| mup | Bug #1616833 opened: need new interface: time-hardware <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616833> | 09:50 |
| mup | Bug #1616834 opened: need new interface: time-adjust <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616834> | 09:50 |
| cpaelzer | is there a "show me the generated apparmor and seccomp profile" shortcut - like being in tempfiles or even a command to show them? | 09:52 |
| youmin | Hi, I tried to disable getty on tty1 with: systemctl disable getty@tty1.service but it doesn't work, of course, previously I remounted filesystem on write mode. Ideas? | 10:04 |
| youmin | sorry, but is anybody there | 10:15 |
| youmin | ? | 10:15 |
| mup | PR snapd#1755 closed: tests: remove snap confine workaround <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1755> | 10:16 |
| ogra | youmin, only 290 people, why ? | 10:20 |
| cpaelzer | youmin: sure there are, but most are busy hacking and only loock sometimes on chat :-) | 10:20 |
| youmin | ok, sorry... but I think I have a simple issue | 10:21 |
| youmin | when I disable getty on tty1 and I restart the system my configuration is lost, and of course I remounted the root partition | 10:21 |
| youmin | anybody has ideas about why? | 10:22 |
| cpaelzer | youmin: I can only speak for myself that I don't know the answer - sorry - how is that snap related, do you do that from "iniside" your snap? | 10:22 |
| youmin | yes, I'm using dell gateway with snap | 10:22 |
| cpaelzer | I'm afaraid you need to highlight a few more experienced users that can help or point you further - ogra zyga ^^ ? | 10:24 |
| ogra | cpaelzer, no idea about that, i would have to dig deep into ancient code, the dell gateways still run 15.04 i think | 10:24 |
| ogra | youmin, you could try to manually depete /etc/systemd/system/getty.target.wants/getty@tty1.service | 10:26 |
| ogra | *delete | 10:26 |
| youmin | orga: I did it, but I don't know why it appears again | 10:27 |
| ogra | elopio, can you trigger a snapd build in the edge channel, we just noticed it never built for all arches, i cahcnged that but dont know how to triggera build for the missing ones | 10:35 |
| philroche | I have created a snap for fswebcam (https://launchpad.net/ubuntu/+source/fswebcam) but it is a reserved name. I am not the project maintainer. Should I request the reserved name and transfer later if the maintainer wishes or use a new unique name like philroche-fswebcam? | 10:39 |
| Son_Goku | zyga: ping | 10:45 |
| mup | PR snapd#1746 closed: many: have AuthContext expose device store-id, serial and serial-proof signing to the store <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1746> | 10:59 |
| mup | PR snapd#1756 closed: asserts: add some stricter checks around format <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1756> | 11:00 |
| zyga | Son_Goku: hello | 11:04 |
| zyga | Son_Goku: I saw your review, thank you | 11:04 |
| zyga | Son_Goku: I will do an upstream release rather than to switch to a snapshot if I can avoid it | 11:04 |
| Son_Goku | zyga, also how are the patches coming for moving /snap? | 11:09 |
| zyga | Son_Goku: yes, all done, I just need to merge them upstream | 11:09 |
| Son_Goku | hit the green button already then :P | 11:10 |
| zyga | Son_Goku: then I'll combine them into one patch to ship before the next release | 11:10 |
| zyga | Son_Goku: we just released last night but not everthing landed yet | 11:10 |
| === hikiko is now known as hikiko|ln | ||
| zyga | Son_Goku: my patches are just for tests, everything else shoud be easy | 11:10 |
| zyga | Son_Goku: I need to look at snap-confine next, that is still a TODO | 11:10 |
| zyga | Son_Goku: but today I need to finish one feature (small but important), so I'm looking at snap-confine 1.0.41 and snapd 2.14 as the fedora target :) | 11:11 |
| Son_Goku | cool | 11:11 |
| === chihchun is now known as chihchun_afk | ||
| notadeveloper | hi | 11:22 |
| cpaelzer | notadeveloper: ho | 11:23 |
| notadeveloper | hi cpaelzer | 11:24 |
| mup | PR snapd#1743 closed: many: use make StripGlobalRootDir public <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1743> | 11:39 |
| mup | PR snapd#1738 closed: tests: the stable ubuntu-core snap has snap run support now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1738> | 11:43 |
| mup | PR snapd#1751 closed: tests: add workaround for u-d-f to unblock all-snap image tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1751> | 11:44 |
| === hikiko|ln is now known as hikiko | ||
| icey | I've uploaded a snap to myapps.developer.ubuntu.com (yesterday afternoon, 16 hours ago?) but can't snap install it yet; it's in devmode so I'm trying to install it with --beta but all I keep getting is snap not found | 12:15 |
| === plars_ is now known as plars | ||
| icey | how does one add dependencies (curl) to a plugin? | 12:25 |
| === mup_ is now known as mup | ||
| mup | PR snapd#1757 opened: asserts: authority-id and brand-id of serial must match <Created by pedronis> <https://github.com/snapcore/snapd/pull/1757> | 12:30 |
| ogra | icey, are you installing with --beta or with --devmode ? | 12:36 |
| icey | orga the snap is (I think) published on the beta channel | 12:36 |
| ogra | so you need both then | 12:37 |
| ogra | (you pshould know which channel you published to though ... the UI shows it on myapps...) | 12:37 |
| icey | ok, it finds it now, but I get a 401 when downloading :) | 12:37 |
| ogra | that sounds like a bug ... is it actually published ? | 12:38 |
| icey | myapps.delevelop.. says yes | 12:40 |
| icey | ogra: ^ | 12:41 |
| ogra | whats the package name ? | 12:41 |
| * ogra will try to confirm your error | 12:41 | |
| icey | ogra: rust-coreutils | 12:41 |
| === Tristit1a is now known as Tristitia | ||
| ogra | icey, looks fine to me http://paste.ubuntu.com/23088826/ | 12:43 |
| icey | ogra: maybe I just tried too fast? | 12:43 |
| ogra | (apart from the fact thet the daemon cant start) | 12:43 |
| icey | ogra: shouldn't be a daemon :) I'm working through my first snap :) | 12:43 |
| icey | gah I stillg et a 401 | 12:43 |
| ogra | well, the systemd units :) | 12:44 |
| ogra | are you behind a proxy ? | 12:44 |
| icey | ogra: https://paste.ubuntu.com/23088828/ | 12:44 |
| icey | shouldn't be behind a proxy | 12:44 |
| ogra | icey, hmm, are you logged in (note that i am not and used sudo) | 12:46 |
| ogra | perhaps thats the deifference | 12:46 |
| icey | I am logged in, and no sudo | 12:46 |
| icey | so almost exactly different :-P | 12:46 |
| icey | let me pop up a container | 12:46 |
| ogra | well, just use sudo | 12:47 |
| ogra | i guess that simply overrides the liogin | 12:47 |
| icey | seems happy when not logged in, as root | 12:49 |
| icey | ogra: | 12:49 |
| ogra | so there is something with the login credentials then i guess | 12:50 |
| ogra | not sure whom you need to poke for this | 12:50 |
| icey | ogra: I'll just raise a bug :) | 12:51 |
| ogra | yeah | 12:51 |
| morphis | niemeyer: ping | 12:51 |
| icey | that's why I'm snapping things anyway eh :) | 12:51 |
| mvo | pitti: can you help with a netplan question? https://github.com/snapcore/snapd/pull/1731/files#diff-52d12b07d34f6f20ac6190c87c325f8eR52 is the config what we generate (mwhduson to be precise), I use that and boot the system but no eth0 is coming up, how can I debug this? I fixed the verison:2 line? | 12:55 |
| mup | PR snapd#1731: firstboot: generate netplan config rather than ifupdown <Blocked> <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1731> | 12:55 |
| pitti | mvo: I already replied to mwhudson about that | 12:58 |
| mvo | pitti: oh, ok. where can I read that reply? | 12:58 |
| pitti | oh, he fixed the bad "dhcp4:" | 12:58 |
| pitti | mvo: oh, good point, that's another bug; "ethernets:" is on the same level as "version 2:" | 12:59 |
| pitti | mvo: easiest to just run "netplan generate" in the system and walk through the error messages | 13:00 |
| mvo | pitti: cool, thanks, that was all I needed | 13:00 |
| mvo | pitti: test is running now and will drop me in a debug shell in a minute, will figure it out, thanks for your help | 13:00 |
| mvo | pitti: yay, just the indent | 13:03 |
| pitti | mvo: Yet Another Moaning Language :) | 13:04 |
| ogra | switch to ini :P | 13:04 |
| mup | PR snapd#1758 opened: Use netplan <Created by mvo5> <https://github.com/snapcore/snapd/pull/1758> | 13:04 |
| pitti | ogra: and call them .network! | 13:05 |
| ogra | ! | 13:06 |
| zyga | jdstrand: hey | 13:06 |
| zyga | jdstrand: around? | 13:06 |
| zyga | tyhicks: or you? :) | 13:06 |
| ogra | mvo, that snapd package in the image PPA seems to come from some autobuild, do you know why ? | 13:06 |
| ogra | https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=snapd&field.status_filter=published&field.series_filter=xenial | 13:06 |
| mup | Bug #1614177 changed: Can not connect cups-control interface <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1614177> | 13:07 |
| ogra | mvo, that looks like dupplication since elopio already builds it in the edge PPA | 13:07 |
| jdstrand | zyga: yes | 13:07 |
| ogra | sergiusens, your link is 404 (from the mail you just sent) | 13:14 |
| ogra | oh, because fo the spasec | 13:15 |
| ogra | *spaces | 13:15 |
| zyga | jdstrand: I'd like to discuss the namespace sharing thing | 13:15 |
| ogra | how crazy is that .... | 13:15 |
| zyga | jdstrand: can we do it here on irc with you and gustavo? | 13:15 |
| zyga | jdstrand: https://docs.google.com/document/d/13OoZKmVC-u3N-RskWTZeeZaO8Oz7N857bKnNA2RN-VQ/edit | 13:17 |
| zyga | jdstrand: this is my idea of how we can do this | 13:17 |
| jdstrand | zyga: yes, but I think tyhicks will want to be present too. he comes online in ~45 minutes | 13:17 |
| zyga | jdstrand: that's fine, we can postpone until he is around | 13:17 |
| ogra | pitti, we have a bunch of boards with wlan only or with wlan and eth ... we dont ship NM on ubuntu-core. will netplan be able to handle that (we use wpa-supplicant via ifupdown there atm) | 13:18 |
| mvo | pitti: could you please add http://paste.ubuntu.com/23088949/ to nplan? that would help snapd | 13:19 |
| mvo | ogra: in a meeting right now, we can talk later | 13:19 |
| ogra | ok | 13:19 |
| pitti | ogra: not ATM, wlan/wwan was supposed to be handled by NM | 13:20 |
| ogra | :( | 13:20 |
| ogra | thats not really mebedded firendly | 13:20 |
| ogra | *embedded friendly | 13:21 |
| ogra | (where size matters a lot) | 13:21 |
| morphis | ogra: we have a network-manager snap ready in the store you can just use for that | 13:21 |
| ogra | morphis, i dont want to use NM | 13:21 |
| morphis | and modem-manager as well | 13:21 |
| pitti | ogra: well, these discussion results are never final -- we build netplan as we want/need it, so it's certainly worth to file a bug at least and I'll check with slangasek/rharper etc. | 13:21 |
| morphis | ogra: what is wrong with it? | 13:21 |
| ogra | and i guess 90% f the embedded devs that use core wont want to use NM either | 13:21 |
| ogra | morphis, overheard ... | 13:22 |
| pitti | I thought the general direction was "drop ifupdown" | 13:22 |
| ogra | *overhead | 13:22 |
| ogra | morphis, you have a constantly running dbus service etc | 13:22 |
| pitti | mvo: hm, shipping empty directories? I don't mind much, but how does that help OOI? | 13:22 |
| ogra | ram, and disk space might be very limited | 13:22 |
| morphis | ogra: that is a froth and back discussion, but in the end you want something which does some more management than just a few shells cripts | 13:22 |
| morphis | even on IoT devices | 13:23 |
| mvo | pitti: its about the writable path handling, we can workaround this if you want (or if you don't want the empty dir) | 13:23 |
| morphis | Nest is using connman for a very good reason on their devices | 13:23 |
| pitti | ogra: if you only need a static configuration, it might just be enough to drive wpasupplicant, not necessarily ifupdown or NM, I figure? | 13:23 |
| ogra | morphis, well, adding wpa-ssid and wpa-psk to /e/n/i is enough mgmt for such devices usually | 13:23 |
| pitti | ogra: i. e. some people actually do use networkd with wifi, it's just not very user friendly (no GUI etc.) -- but we don't care about that, and we don't have a gui with ifupdown either | 13:23 |
| pitti | mvo: oh, I see | 13:23 |
| mvo | pitti: for ubuntu-core we create a writable directory in the writable space and we need a mountpoint, this is why we need the dir, but I can workaround if needed | 13:24 |
| ogra | pitti, well, it isnt static usually but dhcp ... but yeah, indeed ssid and psk need to be seeded | 13:24 |
| mvo | pitti: one more hack in livecd-rootfs :) | 13:24 |
| morphis | ogra: that still does the case where you want a lot more extended features | 13:24 |
| * ogra cries a little reading mvo's last line | 13:24 | |
| morphis | ogra: but I agree, its a per use case decision | 13:24 |
| mvo | ogra: I cry a lot everytime I look at this code ;) | 13:24 |
| pitti | ogra: sorry, I meant "static" in the sense of "fixed config files with fixed AP and password" | 13:24 |
| ogra | morphis, right, i think netplan should support the non-NM case for wlan too | 13:24 |
| ogra | pitti, yeah | 13:25 |
| mvo | ogra: any concerns about the netplan landing? I'm keen to get it in today | 13:25 |
| pitti | drwxr-xr-x root/root 0 2016-08-19 19:10 ./etc/netplan/ | 13:25 |
| ogra | mvo, not beyond ... "hey, i'm just trying to SRU livecd-rootfs" :) | 13:25 |
| morphis | mvo, ogra, pitti: not sure, but did you do any testing with netplan and the nm snap to ensure both work fine together? | 13:25 |
| ogra | and the patch will be gigantic, infinity will hate me forever | 13:26 |
| pitti | mvo: https://git.launchpad.net/~netplan-developers/netplan/commit/?id=3ec75ae5 | 13:26 |
| ogra | morphis, not me | 13:26 |
| pitti | mvo: but I can't upload it right now due to beta freeze | 13:26 |
| mvo | pitti: \o/ - no worries | 13:26 |
| ogra | pitti, we have our own archive ;) | 13:26 |
| pitti | mvo, ogra: heh -- if you upload it to that, please don't call it 0.10, but 0.9something | 13:27 |
| ogra | (and are focused on xenial ... landing yakkety later is always fine) | 13:27 |
| pitti | oh | 13:27 |
| pitti | note that xenial's NM does NOT work with netplan | 13:27 |
| ogra | pitti, x.y.z-0ubuntuX+ppaX | 13:28 |
| ogra | is what we usually do | 13:28 |
| pitti | the package has Breaks: network-manager (<< 1.2.2-0ubuntu4~) for a good reason | 13:28 |
| ogra | ouch | 13:28 |
| pitti | so we need to backport a couple of fixes and adjustments for that | 13:28 |
| ogra | i doubt we can easily SRU the new NM ? | 13:28 |
| pitti | s_langasek mentioned yesterday that we want to do that | 13:28 |
| pitti | oh, we can | 13:28 |
| pitti | SMOP | 13:28 |
| ogra | heh, k | 13:28 |
| icey | any good documentation on the interfaces available to snaps, or ways to access more unrestricted things (without --devmode)? | 13:28 |
| pitti | it's nothing earthshattering, just a bug fix or two and adding support for /run/NetworkManager/ config files | 13:28 |
| zyga | icey: hey, you can look at docs/interfaces.md | 13:29 |
| pitti | ogra: well, not really "P"rogramming, more like "P"aperwork :) | 13:29 |
| zyga | icey: you can request any interface, right now that will block you in the store for a manaul review if the interface is too "powerful: | 13:29 |
| zyga | icey: I believe soon we will also use assertions for that | 13:29 |
| ogra | pitti, heh, yeah, i know what you mean ... tyring to SRUall of https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 13:29 |
| icey | zyga: the thing I'm trying to snap is the rust coreutils package, which ( I think) basically means it needs the world | 13:29 |
| mup | PR snapd#1750 closed: store: request device session macaroon from store <Critical> <Reviewed> <Created by matiasb> <Merged by matiasb> <https://github.com/snapcore/snapd/pull/1750> | 13:29 |
| pitti | ogra: can you please file a wishlist bug about wifi support? | 13:30 |
| pitti | this hasn't come up so far | 13:30 |
| zyga | icey: world? | 13:30 |
| zyga | icey: what does it need | 13:30 |
| ogra | pitti, netplan package or is there an upstream project ? | 13:30 |
| pitti | ogra: nplan package is fine; https://bugs.launchpad.net/netplan also exists | 13:30 |
| icey | zyga: look through the list of folders at https://github.com/uutils/coreutils/tree/master/src ; it's a cross platform implementation of all of those | 13:31 |
| ogra | ok | 13:31 |
| icey | so | 13:31 |
| pitti | but distro package is usually better, auto-closing of bugs and you knwo when it is really "in" | 13:31 |
| icey | complete filesystem access, for one | 13:31 |
| ogra | pitti, uuuh ... there is a binary called netplan (from petter's "plan" package), did you know that ? | 13:33 |
| pitti | ogra: I do, that's why the package is called "nplan" :( | 13:33 |
| ogra | https://launchpad.net/ubuntu/+source/plan | 13:33 |
| ogra | ah | 13:33 |
| zyga | icey: that can be done with a sufficiently strong interface | 13:34 |
| pitti | long discussion, executive decision etc. pp. | 13:34 |
| zyga | icey: but also, remember about the chroot | 13:34 |
| pitti | ogra: in the end it doesn't matter that much as nplan is installed by default | 13:34 |
| mup | Bug #1602845 changed: unity7 interface does not work with libnotify <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1602845> | 13:34 |
| ogra | yeah | 13:34 |
| ogra | i just remember all the issues we have with the snappy mediaplayer :) | 13:34 |
| icey | zyga: would it be possible for the command snapped to use something like $(pwd) as the run location? MOST of the coreutils act on either the specified location, or . | 13:34 |
| zyga | icey: http://www.zygoon.pl/2016/08/snap-execution-environment.html | 13:35 |
| zyga | icey: they all do | 13:35 |
| zyga | icey: but read that first please | 13:35 |
| icey | zyga will do :) | 13:35 |
| icey | I'm sure I'll be back in a bit :) | 13:35 |
| zyga | icey: one thing has changed since, we now chdir to /var/lib/snapd/void instead of refusing to run when we cannot preserve the working directory | 13:36 |
| zyga | icey: it's better in practice | 13:36 |
| * zyga -> coffee break | 13:38 | |
| ogra | pitti, bug 1616928 | 13:39 |
| mup | Bug #1616928: netplan should support managing wlan devices via wpasupplicant and ifupdown <nplan (Ubuntu):New> <https://launchpad.net/bugs/1616928> | 13:40 |
| pitti | ogra: I suppose ifupdown is not actually a requirement (I'd really rather not have that), just "get my effing wifi working" | 13:40 |
| ogra | pitti, yeah, just without any overhead | 13:40 |
| josvaz | question on snap daemons, how do you stop a daemon:forking snap from the command line? | 13:41 |
| ogra | (if you have only 128MB ram you really dont want to have NM and dbus running all the time | 13:41 |
| ogra | ) | 13:41 |
| josvaz | use the snap binary or systemd (I don't see my snap listed in services --all-status) | 13:41 |
| pitti | ogra: yep, agreed; I'll have a look how this can be made to work | 13:41 |
| pitti | little reason to have the ifupdown wrapper around it, it could just generate a wpasupplicant conf directly | 13:42 |
| ogra | josvaz, systemct ... | 13:42 |
| ogra | l | 13:42 |
| josvaz | ok | 13:42 |
| ogra | there used to be a "snap service" command, but that got dropped (i think it will return eventually, but is currently not there) | 13:43 |
| josvaz | thanks | 13:44 |
| icey | this doesn't even seem to be happy in devmode: http://pastebin.ubuntu.com/23089017/ | 13:45 |
| cking | can somebody review my "sluice" snap, it's been pending since monday | 13:51 |
| pitti | ogra: https://bbs.archlinux.org/viewtopic.php?id=178625 sounds promising -- apparently Arch has a wpasupplicant@<iface>.service which DTRT (we don't, but I can't imagine it is rocket science) | 13:59 |
| pitti | ogra: essentially, we just need to start it once the interface comes up, which can be done with a relatively simple udev rule even | 13:59 |
| pitti | Odd_Bloke: so, this seems doable indeed | 13:59 |
| pitti | Odd_Bloke: sorry, meant ogra | 14:00 |
| Odd_Bloke | pitti: :) | 14:00 |
| pitti | IRC <tab> clearly isn't clever enough -- what is all this talk about smart devices?? | 14:00 |
| sergiusens | ogra_ you can thank dekko from breaking urls ;-) | 14:01 |
| === al_ is now known as Guest37767 | ||
| Guest37767 | I have a question regarding the connection of my snap to a USB flash drive. With the "strict confinement" option, using the plugs "home", I can't access to the usb flash drive. Is there an other interface to connect to the usb ports ? | 14:29 |
| mup | PR snapd#1731 closed: firstboot: generate netplan config rather than ifupdown <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1731> | 14:31 |
| mup | PR snapd#1757 closed: asserts: authority-id and brand-id of serial must match <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/1757> | 14:31 |
| zyga | tyhicks, jdstrand: do you have a moment to discuss the ns sharing design | 14:33 |
| jdstrand | mhall119: hey, didrocks seems afk, is there someone who can look at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7 ? | 14:33 |
| mup | PR ubuntu/snapcraft-desktop-helpers#7: common/desktop-exports: don't dereference target symlink on upgrades <Created by jdstrand> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7> | 14:33 |
| tyhicks | zyga: yes, I'm reviewing the doc now | 14:34 |
| jdstrand | mhall119: feel free to direct me to whoever | 14:34 |
| zyga | tyhicks: thank you, we don't have to have a hangout or anything, just give me feedback and suggestions please | 14:34 |
| mhall119 | jdstrand: not sure I'm qualified to give a "looks good" on that, but your explanation of the issue and fix sounds reasonable | 14:35 |
| niemeyer | zyga: This is significantly more complex than what I hoped for | 14:38 |
| niemeyer | cc jdstrand tyhicks | 14:38 |
| zyga | niemeyer: ideas welcome, this is the most basic version that lets us share the mount namespace IMHO | 14:39 |
| jdstrand | zyga: can you make that a numbered list so it is easier to speak to? | 14:40 |
| zyga | yes, sure | 14:40 |
| zyga | ne | 14:40 |
| zyga | done | 14:40 |
| jdstrand | thanks | 14:41 |
| jdstrand | so the gist of this is 4 and 6 | 14:41 |
| jdstrand | 4 gets us what to give to 6 | 14:41 |
| zyga | correct | 14:41 |
| zyga | the rest is just implementation detail, apart from the fork that is mandatory | 14:42 |
| jdstrand | and the rest is how to get there safely and cleanup | 14:42 |
| zyga | (because of how the mount namespace is diffrent from other namespaces, apparently) | 14:42 |
| zyga | (i.e. you cannot just bind mount it directly unlike the others) | 14:42 |
| tyhicks | will snapd know which snaps need to share namespaces? | 14:44 |
| jdstrand | so, 1 is about creating the mountpoint in a non-racy way. if I am in 1b, what is the next step? | 14:44 |
| zyga | tyhicks: AFAIK the design is that all processes belonging to a given snap share a namespace, if desired this can be delegated to an interface later | 14:44 |
| zyga | jdstrand: if you "lose" you spin lock on the files you'd open in 6 to become symlinks and then proceed | 14:45 |
| zyga | jdstrand: we can switch from spinlock to anything that lets them coordinate | 14:45 |
| jdstrand | zyga: so, once symlink is there, go to step 6 | 14:46 |
| jdstrand | (might be nice to capture that) | 14:46 |
| zyga | jdstrand: correct, assuming 3.8 or more recent kernel | 14:46 |
| zyga | jdstrand: done | 14:46 |
| jdstrand | ah, well, 3.8-- there are 3.4 kernels out there-- maybe call that out in a comment as something that should be changed for 3.4 or to add a patch to the list for 3.4 backports | 14:47 |
| zyga | good point | 14:47 |
| zyga | jdstrand: hmm, which version of ubuntu had a 3.4 kernel? I'll use that for testing | 14:48 |
| cpaelzer | elopio: hi, just saw your feedback on PR 716 | 14:48 |
| jdstrand | I suspect you have to unshare() in a forked process because this is after this process' unshare() and unshare() twice is not allowed | 14:48 |
| cpaelzer | elopio: what do you suggest with "waf part in the wiki instead of putting it in our integration test" ? | 14:49 |
| cpaelzer | elopio: I surely can add stuff to the wiki, but I don't get the "instead of integration test" part of it yet | 14:49 |
| zyga | jdstrand: no, it is just because of how it doesn't work otherwise for the mount namespace, it you cannot bind mount /proc/self/ns/mnt unless under some extra conditions that are not captured by the manual page IMHO | 14:49 |
| zyga | jdstrand: I found this by googling and experimenting, | 14:49 |
| zyga | jdstrand: you have to be in another namespace | 14:49 |
| zyga | jdstrand: to do the bind mount | 14:50 |
| zyga | jdstrand: odd but ... well | 14:50 |
| zyga | jdstrand: so the parent is in the vanilla namespace, the child sits in the new namespace(s) and the parent does the bind mount | 14:50 |
| jdstrand | zyga: precise has 3.2. not sure otoh what had 3.4-- I don't think anything in Ubuntu iirc. android bsps of course (eg, touch kernels) | 14:50 |
| zyga | jdstrand: 3.2 is good | 14:50 |
| zyga | jdstrand: the pivot point is 3.8 | 14:50 |
| * zyga fetches precise | 14:51 | |
| mup | PR snapd#1757 closed: asserts: authority-id and brand-id of serial must match <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1757> | 14:51 |
| jdstrand | zyga: 2b should say 'waits to be killed in step 5' | 14:52 |
| jdstrand | I know I'm being pedantic, but trying to make sure we understand what each step is doing | 14:52 |
| mhall119 | what does the new browser-support interface provide? | 14:52 |
| jdstrand | mhall119: it's in docs/interfaces.md: "Can access files and IPC needed by modern browsers. This interface is | 14:54 |
| jdstrand | intended to be used when using an embedded Chromium Content API or using the | 14:54 |
| jdstrand | sandboxes in major browsers from vendors like Google and Mozilla. The | 14:54 |
| jdstrand | ``allow-sandbox`` attribute may be used to give the necessary access to use | 14:54 |
| jdstrand | the browser's sandbox functionality." | 14:54 |
| zyga | jdstrand: done | 14:54 |
| zyga | jdstrand: I'm very grateful for this! | 14:55 |
| jdstrand | mhall119: basically, electron works without specifying allow-andbox and people like google and mozilla can use it with allow-sandbox: true for chrome and firefox respectively | 14:55 |
| mhall119 | jdstrand: ah, ok | 14:55 |
| zyga | jdstrand, tyhicks: if you don't mind I'd like to change the directory a little to .../$SNAP_NAME/mnt so that we can have .../$SNAP_NAME/mutex explicitly | 14:56 |
| zyga | and use openat() easily | 14:56 |
| jdstrand | zyga: super pedantic: 'snap-confine parent waits for the eventfd event created in step 2b' | 14:56 |
| zyga | jdstrand: done | 14:56 |
| jdstrand | zyga: step 4: 'when the eventfd event is received, ... | 14:56 |
| * zyga would like to have "anhor references" so that 2b can be auto-numerated | 14:56 | |
| jdstrand | ' | 14:57 |
| zyga | jdstrand: done, correct me if anything is wrong (I think you can also do suggestions in the doc) | 14:57 |
| jdstrand | zyga: so, if step 2 fails, a losing process in 1b will spin forever? | 14:59 |
| zyga | jdstrand: yes | 15:00 |
| zyga | jdstrand: hmm | 15:00 |
| zyga | jdstrand: if only IPC was easy | 15:00 |
| jdstrand | well, that's what reviews are for | 15:00 |
| zyga | jdstrand: hmmm, maybe an IPC (dbus?) service for making namespaces? | 15:00 |
| zyga | jdstrand: then everone just calls a method on the bus and gets an FD back | 15:01 |
| zyga | jdstrand: or an error | 15:01 |
| jdstrand | I don't think we want dbus | 15:01 |
| zyga | jdstrand: sockets are good too :) | 15:01 |
| jdstrand | well | 15:01 |
| zyga | jdstrand: do we need that to stay reliable? | 15:01 |
| jdstrand | let me rephrase | 15:01 |
| tyhicks | I'd rather not have the setuid root snap-confine get as complicated as talking over dbus | 15:02 |
| jdstrand | adding dbus as a requirement means that 14.04 cloud images will pull in dbus | 15:02 |
| jdstrand | and they'd probably prefer not to do that | 15:02 |
| jdstrand | plus that | 15:02 |
| zyga | jdstrand: that's a fair point | 15:02 |
| * zyga thinks | 15:02 | |
| lazyPowe_ | lool o/ hey there | 15:02 |
| zyga | jdstrand: if 2 fails we could remove the mutex | 15:02 |
| zyga | jdstrand: and fail in that process | 15:02 |
| lool | lazyPowe_: Hi! | 15:02 |
| zyga | jdstrand: and other processes could restart the attempt | 15:03 |
| zyga | jdstrand: with inotify they could observe the directory | 15:03 |
| zyga | jdstrand: to know mutex is gone (no spinlock) | 15:03 |
| lool | lazyPowe_: the docker snap will likely not be sufficient for kubernetes | 15:03 |
| lool | lazyPowe_: it's WIP at https://github.com/snapcore/snapd/pull/1619 | 15:03 |
| mup | PR snapd#1619: Add initial "docker" interface based on some of 15.04's privileges <Blocked> <Created by tianon> <https://github.com/snapcore/snapd/pull/1619> | 15:03 |
| zyga | jdstrand: this could be done by snap-confine-ns, to have less stuff in snap-confine itself | 15:03 |
| zyga | jdstrand: which could be confined very strictly to do that one thing (share or setup the ns) | 15:04 |
| lazyPowe_ | lool - well, thats fine by me for now :) I was just noticing this is you https://github.com/lool | 15:04 |
| elopio | cpaelzer: hello. Have you seen https://wiki.ubuntu.com/snapcraft/parts ? You can put in there a part to be reused. I thought waf would be a good case for that. | 15:04 |
| lool | lazyPowe_: it is me, what did I do again? | 15:04 |
| lool | and before anyone ask, I certainly didn't reboot it | 15:04 |
| elopio | instead of copying the waf source in your snap, you would use: after: [waf], and snapcraft will bring it from the wiki. | 15:04 |
| jdstrand | removing the mutex and allowing losing process to try to win seems reasonable | 15:04 |
| lazyPowe_ | lool - i found this https://github.com/infosiftr/snap-docker/tree/docker-interface | 15:05 |
| zyga | tyhicks: how do you feel about the whole design? | 15:05 |
| lazyPowe_ | is this the snap and code in reference on the list / snapcore/snapd | 15:05 |
| elopio | ogra_: hey, answering the old ping. There is a button in launchpad called trigger build, do you mean that? | 15:06 |
| tyhicks | zyga: well, I don't prefer snap-confine having to do all of this work | 15:06 |
| lool | lazyPowe_: not sure what you mean with reference on the list / snapcore/snapd, but it's the only repo we use for docker snap; I believe master branch is the current series 16 one though | 15:06 |
| lazyPowe_ | ok, i was looking for some prelim work. I'd like to help collab/contribute | 15:06 |
| zyga | tyhicks: would you feel better if this was a separate executable? | 15:06 |
| zyga | tyhicks: it would still be running as root (via snap-confine) | 15:06 |
| ogra_ | elopio, i dont have it | 15:07 |
| jdstrand | zyga: perhaps: '2c. if 2, 2a or 2b fail, remove the mutex so losing processes in 1b can compete for 1a) | 15:07 |
| jdstrand | ' | 15:07 |
| tyhicks | zyga: I'm not against the design but it sure seems like it'd be nicer if snapd could prepopulate the namespace directories | 15:07 |
| zyga | tyhicks: hmmm | 15:07 |
| cpaelzer | elopio: I've seen that in the past, but it appeared to me a bit too "unofficial" and since I want to get an external project to use snaps I'd prefer to have waf "properly" in snapcraft | 15:07 |
| zyga | tyhicks: can we rely on this? snapd may not be up | 15:07 |
| zyga | jdstrand: ^ ? | 15:07 |
| lazyPowe_ | lool - i'm mostly interested in tracking the progress so I can maybe contribute whats needed to run k8s on top of a docker snap. Thanks for confirming that is the upstream | 15:08 |
| cpaelzer | elopio: I might not see the whole of it - could I use that mechanism to "just keep the integration test" in such a part, but let the rest be in "official" snapcraft? | 15:08 |
| tyhicks | zyga: oh... if that's true, then we probably can't rely on it | 15:08 |
| ogra_ | elopio, but it seems a new build is ongoing anyway now ... so no worries | 15:08 |
| lool | lazyPowe_: did you start with a k8s snap already? | 15:08 |
| zyga | tyhicks: I can move the code into any other process but it has to do the thing anyway, yes, we could pre-populate the namespaces a little but I suspect it's going to be more complex this way (what if the group allocation changes, etc) | 15:08 |
| jdstrand | tyhicks: doesn't the unshare() require root? | 15:09 |
| lool | lazyPowe_: so status is that it's mostly done, but there is some pending feedback on the interface and final tweaks to make; waiting on the pull request to be unblocked | 15:09 |
| jdstrand | tyhicks: in 2a | 15:09 |
| lazyPowe_ | lool - i've got the client snap completed, i'm now on to trying to stand up a stand-alone snap | 15:09 |
| tyhicks | jdstrand: yes, it does for certain namespaces | 15:09 |
| tyhicks | jdstrand: why do you ask? | 15:09 |
| jdstrand | tyhicks: I was trying to think through your suggestion of moving it somewhere else | 15:10 |
| tyhicks | (it definitely does for mount namespace) | 15:10 |
| lool | lazyPowe_: cool; would be happy to hear news on progress of this effort, and perhaps even contribute if I find the time :-) | 15:10 |
| lool | lazyPowe_: how do you use k8s BTW? | 15:10 |
| lazyPowe_ | lool - juju deploy kubernetes-core usually | 15:11 |
| tyhicks | jdstrand, zyga: I was just thinking that sorting out all of this lock contention stuff is a pain to get right and it'd be nice if something else had already populated the namespaces | 15:11 |
| jdstrand | I was thinking maybe snap run could do it, but then I said "no, it can't" | 15:11 |
| lool | lazyPowe_: BTW one thing we have been debating is location of docker socket for the snap; ISTR k8s has two docker daemons; it would be interesting to hear if you run into issues with this and the snap | 15:11 |
| tyhicks | jdstrand, zyga: however, that'd have to be done in early boot | 15:11 |
| jdstrand | well | 15:11 |
| jdstrand | lets take a step way back | 15:11 |
| zyga | tyhicks: whoever does it has to solve the same problem | 15:11 |
| jdstrand | the snap can't run unless the squashfs is mounted | 15:11 |
| jdstrand | snapd is mounting the snaps | 15:12 |
| zyga | tyhicks: that cannot be done in early boot because groups are dynamic and will change as snaps are added or removed | 15:12 |
| lazyPowe_ | lool - we would favor bins on disk over another engine bridge using the snap delivery method | 15:12 |
| jdstrand | after it mounts the snaps, couldn't it create what is needed for snap-confine to setns into? | 15:12 |
| zyga | jdstrand: that's not true, systemd does it | 15:12 |
| zyga | jdstrand: even withou snadp running on the next boot | 15:12 |
| jdstrand | eh | 15:12 |
| zyga | *without | 15:12 |
| lazyPowe_ | that primary bridge is used in 1 of 2 cases - to isolate the control plane, or to provide ancilliary components to the "workload" docker instance. Such as SDN through Flannel in a container. | 15:12 |
| zyga | *snapd | 15:12 |
| jdstrand | that's fine. a systemd unit could do it | 15:12 |
| jdstrand | I'm not saying it should. just talking here | 15:13 |
| zyga | ok | 15:13 |
| tyhicks | zyga: if a snap is installed, snapd could set up the namespaces before mounting the newly installed snap | 15:13 |
| zyga | tyhicks: that's true | 15:13 |
| zyga | tyhicks: snapd could manage all of this in /run/snapd/ns | 15:13 |
| tyhicks | zyga: if a snap is uninstalled, and there are no more users of the $SNAP_NAME group identifier, then the namespaces can be torn down after the last snap in the $SNAP_NAME group is unmounted | 15:14 |
| zyga | tyhicks: but we need something that pre-populates that after reboot | 15:14 |
| elopio | ogra_: https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+request-builds | 15:14 |
| zyga | tyhicks: I like how this gives us a nice way to clean up, yes | 15:14 |
| ogra_ | elopio, i developed that part :P i'm talking about https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages and the snapd package in there | 15:14 |
| zyga | tyhicks: and a way to correctly depend on the thing that creates those namespaces to run before snap-confine | 15:15 |
| ogra_ | elopio, (i do know how to trigger an ubuntu-core snap build :) ) | 15:15 |
| tyhicks | zyga: right - so then snap-confine just needs to look in /run/snapd/ns/$SNAP_NAME/* and start calling setns() | 15:15 |
| elopio | cpaelzer: the wiki is pretty official. You would keep the waf plugin in snapcraft, and a waf part in the wiki. The part will just contain the waf python files you are putting in the integration test. | 15:15 |
| niemeyer | zyga: Yes, I can surely have ideas.. I was hoping someone else would also have some of those so we could find something simple that works | 15:15 |
| tyhicks | zyga: there's no need to worry about locking and coordinating with other processes | 15:15 |
| jdstrand | the after reboot scenario could be handled by a systemd unit that runs before any of the snap mounts | 15:16 |
| tyhicks | correct | 15:16 |
| niemeyer | zyga: Let's park that change until someone can have more ideas, please | 15:16 |
| ogra_ | elopio, the prob was that the snapd package in the edge PPA was only built for x86 and armhf ... not for the other arches ... so they ended up with an old snapd | 15:16 |
| tyhicks | niemeyer: we're discussing another option right now | 15:16 |
| jdstrand | it just goes through all the installed snaps and sets up the namesapces. then snap install/remove handles while the system is running | 15:16 |
| niemeyer | tyhicks: Nice, thanks! | 15:16 |
| elopio | ogra_: :) now I understand you | 15:16 |
| ogra_ | :) | 15:16 |
| tyhicks | np | 15:17 |
| ogra_ | its all fine now | 15:17 |
| elopio | ogra_: it has 6 architectures selected. | 15:17 |
| ogra_ | (well, someone needs to request s390x for the edge PPA still ) | 15:17 |
| ogra_ | elopio, yes, i selected them today butt could not trigger a rebuild | 15:17 |
| jdstrand | so, one disadvantage of this is that you have namespaces setup with nothing going into them. this would only affect snaps with no daemons | 15:17 |
| cpaelzer | elopio: uh I see so it would only hold the extra stuff I've moved from the waf upstream into the integration test and that way "stay out of tree" | 15:18 |
| jdstrand | I'm not saying this is necessarily a problem, just that it should be called out | 15:18 |
| elopio | ogra_: and how did you solve it? I see the build queue has only 2 archs. | 15:18 |
| tyhicks | jdstrand: yes, I don't like that aspect of it | 15:18 |
| cpaelzer | elopio: I guess the integration test then is the one using the after [waf] - yeah if that works I'm good | 15:18 |
| zyga | jdstrand: yes, that's true, this brings me to my other point, if this was managed through interfaces then we could have more control over which processes share what | 15:18 |
| cpaelzer | elopio: I'm giving it a try til the next meeting starts | 15:18 |
| zyga | jdstrand: and perhaps, no lurking namespaces that are never used | 15:18 |
| zyga | (well, never is inaccurate) | 15:18 |
| elopio | cpaelzer: yes, thanks. | 15:18 |
| ogra_ | elopio, i didnt ... i enabled all the other arches i could (except for s390x for which we'll need domeone like cjwatson ) ... thats all ... now the daily build job seems to have kicked in | 15:18 |
| tyhicks | jdstrand: it parallels the fact that we have a ton of mounts set up that may not be in use but it is just adding to that problem... | 15:18 |
| ogra_ | *someone | 15:19 |
| zyga | tyhicks: technically snapd reads the meta file from all the snaps almost all the time | 15:19 |
| zyga | tyhicks: but I agree | 15:19 |
| jdstrand | zyga: well, niemeyer and I discussed the option of exposing this to the developer, but we felt this was a confusing choice of an implementation detail to have to deal with | 15:19 |
| ogra_ | elopio, so the "i can not trigger a build" issue has resolved itself due to the daily job | 15:19 |
| jdstrand | tyhicks: that is an extremely fair point | 15:20 |
| zyga | jdstrand: which developer? this would be an implementation detail in snapd interfaces, not something anyone can change willy nilly | 15:20 |
| elopio | ogra_: but I think we are still missing something: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+builds | 15:20 |
| jdstrand | tyhicks: this is a process though that needs to stick around, no? | 15:20 |
| jdstrand | zyga: but the developer has to know to opt into the interface | 15:20 |
| cjwatson | ogra_: https://answers.launchpad.net/launchpad for that kind of request | 15:20 |
| zyga | jdstrand: ah, understood, yes | 15:20 |
| tyhicks | hmmm | 15:20 |
| jdstrand | zyga: plus, this is trying to solve a devmode issue | 15:20 |
| zyga | jdstrand: as a counter point, will we ever have to share the mount namespace across snaps for any reason? | 15:20 |
| jdstrand | (as well as strict) | 15:21 |
| ogra_ | elopio, https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages i see armhf, arm64 and ppc64el binaries if i expand the snapd package ... and amd64/i386 waiting for a free buildd | 15:21 |
| elopio | ogra_: oh, scratch that. It's because the others already build. | 15:21 |
| tyhicks | zyga: does the process that created these namespaces have to stick around or can the namespaces persist without a process? | 15:21 |
| jdstrand | zyga: that would I think definitely need to be exposed in an interface | 15:21 |
| ogra_ | cjwatson, thx | 15:21 |
| zyga | tyhicks: well, they persist here | 15:21 |
| jdstrand | zyga: but there is no consensus on if we should support that | 15:21 |
| zyga | tyhicks: through the bind mount | 15:21 |
| tyhicks | right | 15:21 |
| tyhicks | ok | 15:21 |
| zyga | tyhicks: (here the child that created the process dies before we setns) | 15:21 |
| elopio | ogra_: great, you solved it and I just came late to make a mess. Please continue :) | 15:21 |
| ogra_ | lol | 15:22 |
| tyhicks | jdstrand: so no process needs to stick around after 10:17 < elopio> ogra_: it has 6 architectures selected. | 15:22 |
| tyhicks | bah | 15:22 |
| jdstrand | in fact, architects I've spoken to are leaning against sharing the mount namespace between snaps, even of the same publisher | 15:22 |
| tyhicks | copy and paste fail | 15:22 |
| zyga | jdstrand: ack, then we can use systemd and other units | 15:22 |
| zyga | jdstrand: hmm, will this be a problem for 14.04 support? | 15:22 |
| elopio | ogra_: for the record, the way I trigger a build is to push to the ppa. You can do that manually triggering http://162.213.35.179:8080/job/github-snapcraft-daily-ppa/ | 15:22 |
| * ogra_ feels honored, tyhicks picked my line for his paste error :D | 15:23 | |
| tyhicks | jdstrand: no process needs to stick around after /run/snapd/ns/$SNAP_NAME.NS is created | 15:23 |
| zyga | jdstrand: there are two actions that would have to happen if snap-confine just consumes pre-made namespaces | 15:23 |
| zyga | jdstrand: snapd would have to run a tool/service that creates/remvoes them on demand on install/remove | 15:23 |
| jdstrand | oh, huh. they persist through the bind mount. that clarifies something with ip netns for me | 15:23 |
| zyga | jdstrand: and the said tool would have to run with system startup before snapd itself is up | 15:23 |
| zyga | jdstrand: or more accurately, before the .mount units are preocessed) | 15:23 |
| ogra_ | elopio, aha, that was the button i was missing this morning ... noted for next time | 15:23 |
| zyga | jdstrand: (this will be interesting when we have snap name renames | 15:24 |
| zyga | ) | 15:24 |
| zyga | (perhaps it could be based on snap ids) | 15:24 |
| zyga | (but this is not a major point) | 15:25 |
| jdstrand | ok, then tyhicks' point re this is inline with all our bind mounts is even more salient | 15:25 |
| zyga | ohhhhhhhh | 15:25 |
| zyga | hmm, wait | 15:25 |
| zyga | it cannot fully inline with our bind mounts | 15:25 |
| zyga | because bind mount is just the persistence mechanism | 15:25 |
| zyga | setns is the actual thing, this would still be separate | 15:26 |
| jdstrand | that's note really what I meant | 15:26 |
| ogra_ | jdstrand, tyhicks zyga, i saw you guys talking about creating groups .... of thats user groups, please take into account that we have two group DBs when you design anything around it, one is readonly with static GIDs and the other is dynamic ... the static one might grow over time, so if you create dynamic groups, please leave a large enough gap | 15:26 |
| jdstrand | tyhicks was just saying having this extra thing laying around is not much different than having extra things hanging around elsewhere | 15:26 |
| tyhicks | ogra_: we're talking about groups of kernel namespaces | 15:26 |
| tyhicks | ogra_: that are shared among commands in snap | 15:27 |
| ogra_ | tyhicks, that doesnt relate to userspace groups ? | 15:27 |
| zyga | jdstrand: as in mounted snaps just being there? | 15:27 |
| tyhicks | ogra_: nope | 15:27 |
| ogra_ | (i,e /etc/group ) | 15:27 |
| ogra_ | ok | 15:27 |
| ogra_ | then ignore me :) | 15:27 |
| jdstrand | zyga: that, but more everything snap-confine sets up that the snap may not strictly need | 15:27 |
| tyhicks | ogra_: it was worth mentioning :) | 15:27 |
| zyga | jdstrand: right | 15:27 |
| zyga | jdstrand: so how can we simplify this | 15:27 |
| ogra_ | yeah, i have a mental highlight on such stuff :) | 15:27 |
| jdstrand | all I was saying is that if there is no process sticking around, I find this more compelling and am less bothered by this thing that is there | 15:28 |
| mup | PR snapd#1759 opened: asserts: fix GPG key generation parameters <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1759> | 15:28 |
| jdstrand | one could argue for the shared mount namespace pre-setup with the same logic as pre-mounting snaps | 15:29 |
| jdstrand | snap-confine *could* do the mounts of snaps if they aren't already there, but it doesn't | 15:29 |
| jdstrand | zyga: I'm not sure it needs to be simplified | 15:29 |
| qengho | So, when do snaps refresh? My small experimental set suggests it's automatic on snappy images and manual on snappy-on-classic. | 15:30 |
| zyga | jdstrand, tyhicks: have a look at the 2nd attempt below | 15:30 |
| zyga | qengho: look at the snapd.refresh.timer | 15:32 |
| jdstrand | zyga: in this manner, snap install doesn't have to do anything | 15:32 |
| zyga | jdstrand: correct | 15:32 |
| mup | PR snapd#1760 opened: overlord/state: prevent change ready => unready <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1760> | 15:32 |
| zyga | jdstrand: can the mount unit describe post-unmount actions | 15:32 |
| zyga | jdstrand: so that we can clean up those files? | 15:32 |
| jdstrand | maybe. let me look | 15:32 |
| tyhicks | zyga: hmm, I think there's still a race here :( | 15:33 |
| tyhicks | zyga: so this solved the race problem of the namespace creation and other processes joining the newly created namespace | 15:34 |
| jdstrand | https://www.freedesktop.org/software/systemd/man/systemd.mount.html | 15:34 |
| jdstrand | (not directly) | 15:34 |
| tyhicks | zyga: but now we have to solve the problem of actually setting up the mounts in the namespace | 15:34 |
| zyga | tyhicks: oh | 15:34 |
| zyga | tyhicks: fair point | 15:34 |
| zyga | tyhicks: actually, more complex | 15:34 |
| zyga | tyhicks: it's not just a race | 15:34 |
| zyga | tyhicks: it's a wtf do we do? | 15:34 |
| zyga | tyhicks: because some things are common across snaps | 15:35 |
| zyga | tyhicks: (and those should not be re-done) | 15:35 |
| zyga | tyhicks: but some depend on interfaces | 15:35 |
| tyhicks | zyga: I think this problem is present in both first and second attempt, right? | 15:35 |
| zyga | tyhicks: so now one process can change behavior based on the interfaces of another process | 15:35 |
| zyga | tyhicks: yes | 15:35 |
| zyga | tyhicks: but it's a very serious problem | 15:35 |
| zyga | tyhicks: (feature) | 15:35 |
| * tyhicks thinks | 15:36 | |
| zyga | tyhicks: so, going back to snap-confine-does-all idea, this is easy to make race-free | 15:36 |
| jdstrand | can one of you describe the problem with an example? (this may have already been considered) | 15:36 |
| zyga | jdstrand: sure, two things start up, they have the same mount namespace and then start to apply all the mounts and bind mounts that snap-confine does | 15:37 |
| zyga | jdstrand: so they cannot assume they start with a well-defined state | 15:37 |
| zyga | jdstrand: so they probably don't do what people intended | 15:37 |
| jdstrand | hmmm | 15:38 |
| zyga | let's get back to the original problem | 15:38 |
| zyga | what was desired? so that two processes share the filesystem | 15:38 |
| tyhicks | only one process should set up the bind mounts and others must wait before their snap command is started | 15:38 |
| zyga | can we unshare twice? | 15:38 |
| zyga | if we can setns() and then unshare() | 15:38 |
| zyga | we can do the rest with the fstab interface | 15:39 |
| jdstrand | right, so in the initial thoughts on this, it was 'if shared mount not there, set it up and do all the mounts, then pivot_root ; else, setns and pivot_root' | 15:39 |
| zyga | jdstrand: except that the two processes may have different .fstab files | 15:39 |
| zyga | files* | 15:39 |
| tyhicks | if they have different fstab files, they can't share the same mount namespace | 15:39 |
| zyga | or new conditions on the hostfs would result in different mounts (lxd quirk) | 15:39 |
| tyhicks | it is as simple as that | 15:39 |
| zyga | well, not entirely | 15:39 |
| jdstrand | zyga: wrt the content interface, we said it would necessarily have to be snap-global and that would be covered in documentation | 15:40 |
| zyga | but perhaps they can share a part they care about | 15:40 |
| zyga | jdstrand: oh, we did? I wasn't aware of that | 15:40 |
| jdstrand | yes, it should be in the bug | 15:40 |
| zyga | jdstrand: note that right now it is just the content interface but any future interface can use the mount backend | 15:40 |
| jdstrand | sure. I brought up content because we want to make sure we consider the future .fstab stuff | 15:41 |
| jdstrand | I think that .fstab ends up also being global, but I don't know everything we're thinking of putting there | 15:42 |
| zyga | jdstrand: what if we did this, setns(), unshare(), process all the stuff | 15:42 |
| zyga | would that be sufficient for the network thing | 15:42 |
| zyga | s/stuff/mounts/ | 15:43 |
| zyga | with a shared subtree at the right spot, they would see what they want | 15:43 |
| zyga | and fstab is still per process | 15:43 |
| zyga | (app) | 15:43 |
| zyga | mount namespace is not really fully 'unshared' because of shared subtrees and how that mixes everything up | 15:44 |
| tyhicks | how do you make sure that one snap's fstab doesn't stomp on the shared subtree with a mount that isn't in the other snap's fstab? | 15:45 |
| zyga | tyhicks: you don't but we control the fstabs, it's about how we make the sharing sensible | 15:45 |
| zyga | tyhicks: you can stump if that's the idea | 15:45 |
| tyhicks | zyga: ok, so it is handled by interface code reviews | 15:46 |
| tyhicks | that's acceptable | 15:46 |
| tyhicks | possibly error prone but still perfectly acceptable | 15:46 |
| zyga | jdstrand: how do you feel about this? | 15:46 |
| jdstrand | zyga: note from 'man ip-netns': http://paste.ubuntu.com/23089359/ | 15:46 |
| * zyga reads | 15:46 | |
| jdstrand | zyga: (that was in response to an earlier question) | 15:46 |
| zyga | by creating a mount namespace | 15:47 |
| zyga | and bind mounting all of the per network namespace configure files into | 15:47 |
| zyga | their traditional location in /etc | 15:47 |
| zyga | jdstrand: thanks, I see | 15:48 |
| zyga | jdstrand: so as long as we don't do funny stuff to /etc/netns or /etc, it would be OK | 15:48 |
| zyga | jdstrand: (we do bind mount /etc from the host) | 15:48 |
| zyga | jdstrand: but that mount won't be seen by the host (mount done by ip-netns) | 15:49 |
| zyga | jdstrand: and thus won't be seen by separate processes ran by snap-confine | 15:49 |
| zyga | jdstrand: so unless I'm mistaken, we have to share the actual namespace after it is initialized for this to work | 15:49 |
| jdstrand | well, I want to be sure we think about handling this for anything that might use a mount namespace. ip netns exec is just one thing | 15:49 |
| zyga | jdstrand: agreed | 15:49 |
| zyga | the fstab handling could be split into global and per-process, the global one would be shared by the namespace sharing | 15:50 |
| zyga | the local one could do anything extra needed | 15:50 |
| jdstrand | ok, so can someone clarify option #3 for me? | 15:50 |
| zyga | and the global one would have to be pre-made by the snap-namespace tool | 15:50 |
| zyga | jdstrand: option #? | 15:51 |
| * zyga is amazed that this all works in the kernel and it doesn't leak memory | 15:51 | |
| jdstrand | it sounds like you and tyhicks came up with a different variation | 15:51 |
| jdstrand | can you explain that variation? | 15:51 |
| zyga | tyhicks: can you just write your idea down in the sname doc | 15:52 |
| zyga | tyhicks: you can now edit | 15:52 |
| zyga | jdstrand: this also gets tricky | 15:53 |
| tyhicks | zyga: I didn't come up with an idea about how to handle the fstab processing race | 15:53 |
| zyga | jdstrand: whenever .fstab changes we have to invalidate | 15:53 |
| zyga | jdstrand: and more races show up | 15:53 |
| arges | hi. how long does the typical published snappy app take to show up via 'snap find' ? | 15:53 |
| tyhicks | arges: immediate in the snaps that I've published | 15:54 |
| arges | tyhicks: that's what i've been told. Trying to determine if I screwed something up. | 15:54 |
| zyga | arges: snap find doesn't look at snaps in channels other than stable AFAIK | 15:54 |
| arges | zyga: ah. yea i published to edge. | 15:54 |
| jdstrand | arges: do you have a link to the page in the store and I can look | 15:55 |
| jdstrand | arges: if it fails automated review, then it won't publish | 15:55 |
| jdstrand | arges: and a human needs to look at it | 15:55 |
| arges | jdstrand: it says 'published' and passed the reviews, but it may be because its in edge | 15:55 |
| jdstrand | ok | 15:55 |
| arges | but no idea how to install an edge snap from the store | 15:56 |
| tyhicks | arges: snap install --edge SNAP | 15:56 |
| arges | tyhicks: didn't work for me | 15:56 |
| jdstrand | --channel=edge ? | 15:56 |
| arges | jdstrand: nope | 15:56 |
| arges | : ) | 15:56 |
| arges | $ sudo snap install --channel=edge crash-arges | 15:57 |
| arges | error: cannot install "crash-arges": snap not found | 15:57 |
| jdstrand | arges: what is the name of the snap or the url in the store | 15:57 |
| arges | fwiw | 15:57 |
| jdstrand | ? | 15:57 |
| arges | https://myapps.developer.ubuntu.com/dev/click-apps/5771/ | 15:57 |
| ogra_ | arges, confinement strict or devmode ? | 15:57 |
| arges | ogra_: devmode | 15:57 |
| ogra_ | then add --devmode to that line | 15:57 |
| ogra_ | else it wont find it | 15:57 |
| arges | ogra_: magic. it works | 15:57 |
| ogra_ | ;) | 15:57 |
| jdstrand | zyga, tyhicks: ok, I'm kinda confused where we are | 15:58 |
| arges | jdstrand: tyhicks ogra_ zyga thanks all | 15:58 |
| zyga | jdstrand: I think I'm at the point where I see that it is more complex to correctly share the mount namespace (after it is configured) | 15:58 |
| jdstrand | what option are we talking about, what are we changing and why, how is it implemented? | 15:58 |
| zyga | jdstrand: so the simplistic snap-namespace idea from "2nd attempt" part of the document is not sufficient | 15:58 |
| jdstrand | zyga: can you explain why given the understanding that things like 'content' are snap-global? | 15:59 |
| zyga | jdstrand: because you have to start to invalidate those now as interface are changed | 15:59 |
| jdstrand | can you give a concrete example? | 15:59 |
| zyga | jdstrand: sure, we pre-share a namespace with (hypothetical) snap-namespace, and save the ns to a file as we were planning to, now processes are starting that are racing to open that file while you are racing to create a new namespace because of interface connection changes | 16:00 |
| zyga | (and replace the old one without stacking them forever, we have to unlink or unmount the old one) | 16:01 |
| tyhicks | so I understand the problem of racing on initial fstab processing but I don't know enough to reason about the interface connection changing problem | 16:03 |
| jdstrand | ok. so a snap plugs the content interface. snap-namespace creates the shared mount. the use disconnects the content interface, we have to handle the namespace created by snap-namespace while snap.app2 may be accessing it | 16:03 |
| sborovkov | Hi. Couple of questions - I noticed that snap login eventually expires. Is there recommended mechanism I am supposed to use to handle that? Also I have snap in edge channel - so I have to use snap --refresh --edge screenly - to update it - does that mean I should add cronjob to get new updates from store for it? | 16:03 |
| jdstrand | zyga: something like that ^ | 16:04 |
| zyga | jdstrand: actually I think the old namespace will run fine until the process quits, it is about /run/snapd/ns/foo/mnt that has to be unmounted / unlinked and re-created in a race-free way | 16:04 |
| zyga | jdstrand: though nothing today protects us from concurrent interface reconfigurations and snap-confine reading those files so maybe that's not a new problem | 16:05 |
| zyga | jdstrand: so my point is that the perceived simplification with out-of-bound setup is not really there | 16:06 |
| zyga | jdstrand: because that tool has to solve the same problem | 16:06 |
| zyga | jdstrand: and that tool has to process a large chunk of what snap-confine does now (set up all mounts) | 16:07 |
| tyhicks | it doesn't have to set up all the mounts | 16:07 |
| jdstrand | zyga: yeah. another option would be snapd would have to go in and setns() and umount | 16:07 |
| jdstrand | which also isn't easier | 16:07 |
| tyhicks | there could be a simple lock file that all snap-confine processes take before setting up the mounts | 16:08 |
| zyga | tyhicks: how much processing do you think is required there (in snap-namespace) given that snap-confine does pivot_root and a lot of mounts | 16:08 |
| zyga | tyhicks: can you detail how you'd see the initially (shared) namspace and the per-snap-confine mount operations to happen | 16:09 |
| zyga | tyhicks: what would each of those do? | 16:09 |
| elopio | ping mwhudson: what are the plans for go 1.7? will it get to xenial? yakkety? | 16:10 |
| tyhicks | zyga: well the locking problem is easy - have an advisory lock file that must be help before setting up the mounts | 16:10 |
| tyhicks | zyga: what I don't have an answer to is how to different between different fstab files | 16:10 |
| zyga | tyhicks: different fstab files can be ignored for now, how would the lock file help given the fact that we now start with a non-pristine mount envinronment? | 16:11 |
| zyga | tyhicks: can you write down how that would work, I bet I'm missing something you are thinking about | 16:11 |
| tyhicks | yes, give me a minute to think through the details | 16:12 |
| tyhicks | zyga: see the bottom of the dock | 16:17 |
| zyga | tyhicks: so that would be all-in snap-confine? | 16:19 |
| tyhicks | zyga: yes | 16:19 |
| tyhicks | heh... s/dock/doc/ all this container-like talk has docker in my head :) | 16:20 |
| tyhicks | zyga: it works with either "1st attempt" or "2nd attempt" | 16:21 |
| tyhicks | again, what it doesn't solve is differences in two fstab files | 16:21 |
| zyga | tyhicks: yep | 16:22 |
| zyga | tyhicks: that's fine | 16:22 |
| zyga | tyhicks: I think this is doable, I'd deal away with the .complete file | 16:22 |
| zyga | tyhicks: so that it just looks nicer in the FS | 16:22 |
| jdstrand | tyhicks: can you give a concrete example with two .fstab files? (I think this is covered by documenting these are snap-global) | 16:22 |
| zyga | tyhicks: but that's a minor point (the actual namespace file can be the complete file_ | 16:23 |
| zyga | ) | 16:23 |
| zyga | jdstrand: hmmm | 16:23 |
| tyhicks | zyga: I think you need .complete but we can talk about that later | 16:23 |
| zyga | tyhicks: one hole: the lxd quirk | 16:23 |
| zyga | tyhicks: look at quirks.c please | 16:23 |
| tyhicks | jdstrand: I don't know enough about snap-global to give you an answer | 16:24 |
| jdstrand | tyhicks: you misunderstand | 16:24 |
| jdstrand | tyhicks: what I mean by 'snap global' is that you don't differentiate between commands in a snap. all the commands get the same set of mounts. so if one command plugs content (a consumer of .fstab), all commands gets content | 16:25 |
| tyhicks | jdstrand: nice, so that solves that problem | 16:25 |
| jdstrand | tyhicks: so all the mounts are global to the snap. we simply document that | 16:25 |
| * tyhicks looks at quirks.c now | 16:25 | |
| zyga | tyhicks: this part specifically: https://github.com/snapcore/snap-confine/blob/master/src/quirks.c#L138 | 16:26 |
| zyga | tyhicks: if /var/lib/lxd didn't exist when we first start a process but gets created later, the mount namespace won't have that | 16:27 |
| zyga | tyhicks: if the fstab profile changes, we also have to invalidate the mount namespace (I guess snapd can do that by unlinking the file) | 16:27 |
| zyga | tyhicks: so we have to take that into account (the unlink) but I guess this is simple | 16:28 |
| tyhicks | zyga: the mount namespace is shared so wouldn't future processes see the bind mounted /var/lib/lxd? (depending on mount propagation, of course) | 16:28 |
| zyga | if we can open() we win and we got a fd for setns | 16:28 |
| zyga | tyhicks: no, because that if won't run initially | 16:28 |
| tyhicks | zyga: why not? | 16:29 |
| jdstrand | tyhicks: I think zyga's point is that a snd app invocation skips step 5 | 16:29 |
| jdstrand | s/snd/2nd/ | 16:29 |
| zyga | tyhicks: because if is is not there initially (/var/lib/lxd) then nothing will create the bind mount later | 16:29 |
| zyga | tyhicks: because in this design the .complete file says "the mount namespace is ready, just use it" | 16:30 |
| jdstrand | zyga: quirks could be handled as part of step 4-- it would just need to see if the quirked mount point is already mounted | 16:30 |
| zyga | tyhicks: and the namespace that was initially created may have been done some before (or worse, after) the directory changed the state of its existence | 16:30 |
| jdstrand | well, 4 and 6 | 16:31 |
| zyga | jdstrand: 4 in the new design? | 16:31 |
| jdstrand | but you get the idea | 16:31 |
| jdstrand | yes | 16:31 |
| zyga | jdstrand: hmm | 16:31 |
| tyhicks | man, I'm confused about the quirks problem | 16:31 |
| * zyga doesn't get the idea | 16:31 | |
| zyga | let me re-read | 16:31 |
| jdstrand | always try to run the quirks code | 16:31 |
| zyga | would that be safe? | 16:31 |
| jdstrand | zyga: imagine app 1 starts and a quirk is present, it gets mounted | 16:31 |
| zyga | we'd stack the quirk mount | 16:31 |
| jdstrand | that's easy | 16:31 |
| jdstrand | imagine app 1 starts and the quirk mount isn't present, ekip it | 16:32 |
| tyhicks | (if you two are close to identifying a solution for the quirks problem, it is probably better to work towards that instead of explaining the problem to me) | 16:32 |
| jdstrand | app 2 starts and the quirk mount point is present but not mounted. mount it | 16:32 |
| zyga | ah | 16:32 |
| zyga | jdstrand: so the idea is that quirks have to be aware of this | 16:32 |
| jdstrand | I guess you can put it that way | 16:33 |
| zyga | jdstrand: and do the right thing (whatever it is) in presence of the shared mount namespace | 16:33 |
| jdstrand | yes | 16:33 |
| zyga | jdstrand: e.g. it is not in /var/lib/lxd on the host, unmount it | 16:33 |
| jdstrand | ie, decouple quirks from the shared mount | 16:33 |
| zyga | jdstrand: and rmdir the thing | 16:33 |
| zyga | jdstrand: that's more complex but doable | 16:33 |
| zyga | jdstrand: but somewhat less nice because it would require code that runs very rarely and might be buggy | 16:34 |
| jdstrand | so long as the shared mount namespace is there, the quirks code can figure out something to do | 16:34 |
| jdstrand | well | 16:34 |
| jdstrand | we can think through other options wrt that, but I think this keeps the thorniest part, the locking, simple | 16:34 |
| zyga | jdstrand: I think we're back to the original plan with a few tweaks on locking but nothing major | 16:35 |
| tsimonq2 | a/or | 16:36 |
| tsimonq2 | whoops sorry | 16:36 |
| zyga | tyhicks, jdstrand: do you want me to prototype this? | 16:36 |
| zyga | or are we putting this back on the feature shelf | 16:37 |
| jdstrand | zyga: this is important | 16:37 |
| jdstrand | as evidenced by sabdfl's comments in the bug and to me | 16:38 |
| zyga | niemeyer: ^^ | 16:38 |
| jdstrand | we need to fix ip netns exec in devmode snaps. shared mounts is the path to do that | 16:38 |
| zyga | niemeyer: I'd like your ack to start working on this | 16:38 |
| jdstrand | (fyi, niemeyer is aware of the importance) | 16:38 |
| niemeyer | zyga: Ack on what? | 16:39 |
| jdstrand | but I think what would benefit a conversation with niemeyer is a cleaned up proposal with the new locking | 16:39 |
| jdstrand | (not to mention, JamieBennett said this was prioritized) | 16:39 |
| zyga | niemeyer: to work on the snap-confine changes required to implement mount namespace sharing as described by the "3rd attempt" in the docs | 16:39 |
| zyga | jdstrand: good point, let me do that | 16:39 |
| zyga | niemeyer: sorry to ask prematurely, I'll write a doc that describes what we discussed and how it would work | 16:40 |
| zyga | niemeyer: and aks you to review it then | 16:40 |
| jdstrand | zyga: also, why attempt #2 was rejected would be good | 16:40 |
| niemeyer | jdstrand: Yes, that'd be appreciated, thank you | 16:41 |
| niemeyer | zyga: Sounds good, thanks | 16:41 |
| zyga | jdstrand: I think we rejected it because it'd effectivly do much of what snap-confine does, and would not win us anything; what do you think? | 16:42 |
| zyga | and it had more complex locking | 16:42 |
| zyga | thouh 3rd attempt has yet to implement asynchronous invalidation done by snapd when interfaces are changed | 16:42 |
| zyga | ok, I'll start writing something | 16:44 |
| tyhicks | zyga: no matter what, a combination of (1 or 2) and 3 is needed | 16:45 |
| zyga | tyhicks: yeah, I think we agree on how this must work | 16:47 |
| zyga | tyhicks, jdstrand: thanks for your time | 16:47 |
| zyga | I'll write a new proposal and share it | 16:47 |
| jdstrand | zyga: one way to solve the async problem is for snap-confine to notice that if mnt.complete exists, see if anything is in the mount point. if nothing, tear it down and start anew. this has the advantage of not messing with running processes | 16:48 |
| mhall119 | mvo: ping, can I set runtime envvars for a snap yet? | 16:48 |
| jdstrand | that should probably be handled in a future commit | 16:48 |
| zyga | jdstrand: yes, essentially either we reach .complete and see the mnt file (and by see I mean we opened both) or we tear-and-restart | 16:48 |
| * jdstrand nods | 16:49 | |
| zyga | it's somewhat confusing in semantics as two processes can be in one snap and not share a namespace though | 16:49 |
| zyga | that is pretty annoying :/ | 16:49 |
| * zyga thinks if that means we're back to the drawing board | 16:49 | |
| jdstrand | this is precisely why for a system like snappy avoiding use of namespaces is a good thing. the mount one is arguably the easiest to deal with and look how hard it is! :) | 16:50 |
| zyga | 1: a mount namespace that cannot be invalidated; 2: a set of mounts to process that can be safely undone; that would let us still share one namespace across fstab changes | 16:50 |
| zyga | jdstrand: I fully agree | 16:50 |
| mup | PR snapd#1761 opened: integration-tests: remove them in favour of the spread tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1761> | 16:50 |
| zyga | jdstrand: and I bet I still don't grok shared subtrees with all their subtle details correctly | 16:50 |
| jdstrand | (ie, being in teh global namespace and mediating through other means is is way simpler) | 16:50 |
| jdstrand | zyga: who does? :P | 16:50 |
| zyga | jdstrand: don't you and tyhicks? :-) | 16:51 |
| jdstrand | I'll defer to tyhicks :) | 16:51 |
| zyga | the fact that you can bind mount *a symlink* over somewhere to share a namespace was my "o_O" moment of the day | 16:51 |
| jdstrand | I find myself always reminding myself with man pages, etc | 16:51 |
| zyga | or that you can bind mount over files to make symlinks | 16:51 |
| zyga | that's damn powerful | 16:51 |
| zyga | I'd love to see an atomic mount flag that unbinds anything present there | 16:52 |
| zyga | hmm | 16:52 |
| zyga | tyhicks: is that just MS_REMOUNT? | 16:52 |
| zyga | MS_REMOUNT|MS_BIND | 16:52 |
| tyhicks | zyga: that would probably work but we'd have to test | 16:54 |
| zyga | tyhicks: no worries, I'll explore this myself | 16:54 |
| zyga | cool stuff :) | 16:54 |
| mhall119 | jdstrand: I'm trying to snap qupzilla, a qtwebengine based browser, and I'm getting: http://paste.ubuntu.com/23089689/ | 16:54 |
| zyga | this is why I love this work :) | 16:55 |
| mhall119 | jdstrand: is that a problem with the browser-support sandboxing? | 16:55 |
| mhall119 | http://paste.ubuntu.com/23089692/ is the snap.yaml, I wasn't entirely sure how to set allow-sandbox:true | 16:56 |
| mvo | mhall119: almost, #1254 needs to land | 16:56 |
| mhall119 | mvo: ack, how close is that? | 16:56 |
| mvo | mhall119: it could land today, except there are test failures that need to be debugged | 16:57 |
| mvo | mhall119: but days | 16:57 |
| mhall119 | ok | 16:57 |
| mvo | mhall119: not weeks like before, the big pre-requiste (new ubuntu-core) has landed | 16:57 |
| jdstrand | mhall119: use either the 'allow-sandbox' attribute or launch with --disable-setuid-sandbox | 17:00 |
| mup | PR snapd#1735 closed: tests: fixes to make the ubuntu-core-16 image usable with -keep/-reuse <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1735> | 17:00 |
| jdstrand | mhall119: note that 'allow-sandbox: true' is going to require manual approval and is only meant as transitional policy for official upstream like mozilla and google until they modify their sandboxes to work with snappy | 17:01 |
| jdstrand | mhall119: qtwebengine may have some other way to disable it. I don't know | 17:02 |
| mhall119 | jdstrand: is my snap.yaml correct to set allow-sandbox: true? | 17:04 |
| zyga | jdstrand: unrelted question, is the apparmor process label in any way related to cgroups? | 17:04 |
| jdstrand | mhall119: yes | 17:05 |
| jdstrand | mhall119: oh, your snap doesn't have the sandbox as setuid | 17:05 |
| mhall119 | what does that mean? | 17:05 |
| jdstrand | mhall119: your only option is --disable-setuid-sandbox | 17:05 |
| jdstrand | mhall119: chromium uses a setuid sandbox to setup stuff | 17:06 |
| jdstrand | mhall119: snaps aren't allowed to ship setuid binaries | 17:06 |
| mhall119 | wasn't this interface created to support chromium's use case? | 17:06 |
| jdstrand | mhall119: I'm sure there is a configuration option for qtwebengine to compile without it. electron does this for example | 17:07 |
| jdstrand | mhall119: the interface was created to support mozilla and google's official browsers with their privileged sandbox mode, and the chromium content api without the privileged sandbox mode | 17:07 |
| jdstrand | mhall119: you should update to not use the privileged sandbox mode | 17:08 |
| jdstrand | mhall119: this is a transitional interface to block these companies while they adjust their implementations to work with snappy | 17:08 |
| jdstrand | err | 17:09 |
| jdstrand | to unblock* | 17:09 |
| jdstrand | mhall119: just do like electron and it'll be fine | 17:09 |
| mhall119 | jdstrand: where can I find how electron does it? | 17:09 |
| jdstrand | compile it without the setuid sandbox | 17:09 |
| jdstrand | that's all electron does | 17:10 |
| jdstrand | you'll have to look at qupzilla's build options | 17:10 |
| mup | PR snapd#1762 opened: Spread cups control <Created by mvo5> <https://github.com/snapcore/snapd/pull/1762> | 17:10 |
| mvo | ogra_: just fyi, I prepare new images currently - with the new netplan stuff and for the first time from the beta channel :) | 17:11 |
| mhall119 | jdstrand: it does say "Running without the SUID sandbox!" in the output...so maybe it's something else? | 17:13 |
| jdstrand | mhall119: I thought you were asking about the setuid sandbox. what is your question? | 17:14 |
| jdstrand | failed to execvp: | 17:15 |
| jdstrand | /snap/qupzilla/x1/usr/lib/x86_64-linux-gnu/qt5/libexec | 17:15 |
| mhall119 | jdstrand: trying to track down the error | 17:15 |
| mhall119 | yeah, just found that it was a bad envvar value | 17:15 |
| mhall119 | I have lots of other errors now, but at least that one is resolved :) | 17:16 |
| mhall119 | thanks jdstrand | 17:16 |
| jdstrand | cool :) | 17:16 |
| smoser | hey, i have an snapcraft.yaml that is building a nodejs thing happily. | 17:33 |
| smoser | however, i'd like to add a symlink as part of that build. | 17:33 |
| smoser | what i need to do is just execute: ln -s azure-cli bin/azure | 17:34 |
| zyga | jdstrand, tyhicks: can you please re-review the document I shared earlier | 17:39 |
| mhall119 | smoser: I think you can create the symlink first, put it in the same directory as your snapcraft.yaml, and then use a copy plugin to put it where you want it | 17:39 |
| smoser | but how do i "create the symlink first" | 17:39 |
| mhall119 | with your command above | 17:39 |
| zyga | jdstrand, tyhicks: I've switched the docs to comment mode, please feel free to comment or suggest changes | 17:40 |
| zyga | when you ack on it I will share it with gustavo again | 17:40 |
| tyhicks | zyga: I already left one comment | 17:40 |
| * tyhicks reviews the rest | 17:40 | |
| smoser | but that breaks the idea that you just run 'snapcraft' | 17:41 |
| cjwatson | ogra_: you said "all arches" but you didn't list powerpc and that's not currently enabled; do you want that too? | 17:41 |
| smoser | and probably breaks anything that would do that for me in an automated fashion | 17:41 |
| smoser | because i then have to tell it "run 'ln' first" | 17:41 |
| smoser | or maybe i'm missing something. | 17:42 |
| zyga | tyhicks: thinking about it, we could keep the .lock file global, if there are more namespaces to share we'll just use one file to protect them all | 17:43 |
| zyga | tyhicks: this feels better because we either use one set or anther set of namespaces, not some random collection from the first set and second set together | 17:43 |
| zyga | tyhicks: I won't make the change back unless you say so though | 17:44 |
| tyhicks | zyga: if we use a global lock file, how do we indicate that all namespaces are initialized? | 17:47 |
| zyga | tyhicks: you can only look for them when they are initialized | 17:48 |
| zyga | tyhicks: just set them up | 17:48 |
| tyhicks | ok | 17:49 |
| zyga | tyhicks: and then bind mount them | 17:49 |
| zyga | tyhicks: not before | 17:49 |
| zyga | tyhicks: you can set them up without that file being there | 17:49 |
| zyga | tyhicks: the only thing that can happen is snapd unmounting them as we do | 17:49 |
| zyga | tyhicks: but that's a failure case that brings us back to the "let's do everything separately and cache if I can with the lock held" problem | 17:49 |
| tyhicks | zyga: ok, you can change it back to a global lock | 17:50 |
| zyga | tyhicks: OK | 17:50 |
| zyga | done | 17:51 |
| tyhicks | zyga: ack from me | 17:51 |
| zyga | tyhicks: thank you! | 17:52 |
| tyhicks | zyga: thank you! | 17:52 |
| zyga | tyhicks: do you feel that we will support more namespaces as time progresses? | 17:54 |
| zyga | tyhicks: (that we will unshare more?) | 17:54 |
| tyhicks | zyga: I think it is something that we will need to be prepared to do | 17:54 |
| zyga | jdstrand: given tyler's ack I'll share this with gustavo | 18:00 |
| zyga | niemeyer: please re-review if you can (same URL, also linked from bug repott) | 18:01 |
| zyga | report* | 18:01 |
| tyhicks | zyga: there's one thing that I just realized I'm not clear on: how does snap-confine know when to set up the shared namespace? | 18:02 |
| zyga | tyhicks: when it cannot setns() one | 18:03 |
| tyhicks | zyga: so it will do this routine for every snap that gets launched? | 18:04 |
| tyhicks | I guess Design Requirement #1 makes that clear | 18:05 |
| tyhicks | I have no problem with that | 18:05 |
| tyhicks | I just wasn't clear | 18:05 |
| tyhicks | thanks | 18:05 |
| jdstrand | zyga: sorry got pulled aside. couple of typo/clarifications in the doc. ack from me | 18:22 |
| === mup_ is now known as mup | ||
| blackboxsw | hmm, is snappy-playpen supposed to be examples of best practices? Trying to run snapcraft v2.15.1 doesn't build for multiple qt-based example snaps such as texworks, 2048, qownnotes, vlc etc. Snapcraft chokes on the after clause containing a shared remote part desktop/* the slash causes processing to barf with \u29f8' in position 48: ordinal not in range(128) | 18:43 |
| blackboxsw | it seems in some cases (like game-2048) I'm able to replace the nasty '/' with a hyphen because there are not desktop-qt5 and desktop-qt4 shared remote parts published at https://wiki.ubuntu.com/snapcraft/parts | 18:45 |
| mup | PR snapcraft#758 opened: Add an integration test for parts with filesets <Created by jocave> <https://github.com/snapcore/snapcraft/pull/758> | 18:45 |
| qengho | blackboxsw: It's not Best, not necessarily. It lags behind snapcraft by a bit. | 18:45 |
| blackboxsw | shall we push changes to snappy-playpen to resolve these build issues for the time being? | 18:46 |
| qengho | blackboxsw: Yes. Or file bugs reports. | 18:46 |
| wililupy | Question: After I build my image and install it on my device, I run snap list and it doesn't show any snaps. Is this normal? | 18:46 |
| blackboxsw | qengho, I've been watching https://bugs.launchpad.net/snapcraft/+bug/1607015 in hopes that it'll get addressed, but I'm not certain when that would be. | 18:47 |
| mup | Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Confirmed> <https://launchpad.net/bugs/1607015> | 18:47 |
| qengho | blackboxsw: yep. Me either. | 18:47 |
| qengho | wililupy: I think you should see at least ubuntu-core package. :\ | 18:49 |
| wililupy | ubuntu@localhost:~$ snap list | 18:50 |
| wililupy | No snaps are installed yet. Try 'snap install hello-world'. | 18:50 |
| Pharaoh_Atem | zyga: how are you progressing on the removal of /snap? | 18:51 |
| === mup_ is now known as mup | ||
| ogra_ | cjwatson, no, i was referring to the arches snappy supports, sorry ... only s390x | 19:12 |
| qengho | blackboxsw: I don't know a lot here, or if this will help, but I think you should use parts as they're named in https://parts.snapcraft.io/v1/parts.yaml | 19:15 |
| blackboxsw | +1 qengho. I think so too, I *think* we probably need to remove the unusable desktop/* parts though as it seems like they cannot be sourced as a "remote part" in the after clause of snapcraft.yaml. It seems the desktop/(qt4|qt5|gtk2|gtk3) is replaced with a snapcraft parseable desktop-(qt4|qt5|gtk2|gtk3) etc. | 19:18 |
| ogra_ | qengho, blackboxsw see bug 1607015 | 19:20 |
| mup | Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Confirmed> <https://launchpad.net/bugs/1607015> | 19:20 |
| ogra_ | (thats the reason for the breakage) | 19:21 |
| blackboxsw | ogra_, I commented on that bug ;) | 19:21 |
| ogra_ | ah, that was you :) | 19:21 |
| blackboxsw | s/blackboxsw/Chad Smith/ :) | 19:21 |
| ogra_ | well, the playpen guys are most active on gitter | 19:21 |
| ogra_ | https://gitter.im/ubuntu/snappy-playpen to be precise | 19:22 |
| blackboxsw | yeah I had filed the duplicate https://bugs.launchpad.net/snappy/+bug/1612441 | 19:22 |
| mup | Bug #1612441: Cannot include wiki-defined part desktop/gtk2 in after clause <landscape> <Snappy:New> <https://launchpad.net/bugs/1612441> | 19:22 |
| blackboxsw | thx for the pointer ogra_ | 19:22 |
| ogra_ | :) | 19:22 |
| josepht | '/' is going to be deprecated in snapcraft 2.16. The wiki has been updated with the '-' version of those parts as has the origin repo. | 19:26 |
| mup | PR snapd#1763 opened: many: clarify/tie down model assertion <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1763> | 19:36 |
| mup | PR snapd#1760 closed: overlord/state: prevent change ready => unready <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1760> | 19:53 |
| mup | PR snapd#1722 closed: many: support install and remove by revision <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1722> | 20:04 |
| nacc | did anything change recently for local plugins? | 20:09 |
| nacc | (in 16.10's snapcraft, i guess) | 20:09 |
| nacc | i keep getting 'unknown plugin: glide', even though i have parts/plugins/glide.py ? | 20:10 |
| qengho | nacc: Did it work before? | 20:16 |
| nacc | qengho: similar syntax has worked before, yeah | 20:16 |
| nacc | the 'glide' plugin i have locally is a pretty trivial subclass of the go plugin | 20:17 |
| qengho | nacc: Try with "strace -e trace=file -f -o snapcraft.strace snapcraft". Then, "grep glide snapcraft.strace". | 20:17 |
| mup | PR snapd#1703 closed: tests: test all snap ubuntu core upgrade <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1703> | 20:20 |
| nacc | qengho: hrm, i see it looking (stat'ing) parts/plugins, but not even trying to open said file | 20:20 |
| qengho | nacc: I remember that the plugins were supposed to start with "x-". Maybe that matters? | 20:20 |
| nacc | qengho: just tried changing that locally, still no dice | 20:21 |
| nacc | qengho: x-glide.py and x-glide in yaml | 20:21 |
| qengho | Er, "glide" in yaml. "x-glide.py" on filesystem. | 20:21 |
| nacc | qengho: it must be a search thing, as i'm using cleanbuild and it's not even kicking off the container, it would be nice to know what it's searching for | 20:21 |
| nacc | qengho: oh really? | 20:21 |
| nacc | let me try that | 20:21 |
| nacc | qengho: still says 'unknown plugin' :/ | 20:22 |
| nacc | qengho: ah but that did change the strace! :) | 20:23 |
| qengho | nacc: pastebin that grep. | 20:23 |
| mup | PR snapd#1761 closed: integration-tests: remove them in favour of the spread tests <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1761> | 20:24 |
| nacc | qengho: http://paste.ubuntu.com/23090363/ | 20:24 |
| qengho | stat but no open. Huh. | 20:25 |
| nacc | yeah, weird | 20:25 |
| qengho | nacc: Now pastebin " | 20:29 |
| qengho | nacc: Now pastebin "grep plugins snapcraft.strace" | 20:30 |
| nacc | qengho: bah, i figured it out | 20:31 |
| nacc | qengho: it was a mistake in the import | 20:31 |
| nacc | qengho: but since importerrors are suppressed... | 20:31 |
| nacc | qengho: thanks for the help! | 20:31 |
| qengho | Ah hah. | 20:32 |
| nacc | this feels like a common thing (and python will raise a far more helpful ImportError than 'unknown plugin' :) | 20:33 |
| qengho | nacc: Yeah, maybe that ImportException suppression should check the stack depth. Mind filing a bug? | 20:33 |
| nacc | qengho: yep, will do | 20:33 |
| qengho | nacc: Thank you. | 20:33 |
| jcastro | rcj: Hey I could only get your cloudprint snap to work when I installed it in devmode | 20:34 |
| nacc | qengho: summarized at LP: #1617052 | 20:36 |
| mup | Bug #1617052: snapcraft: do not suppress ImportErrors for top-level exceptions with local plugins <Snapcraft:New> <https://launchpad.net/bugs/1617052> | 20:36 |
| jcastro | rcj: nm, I didn't read your instructions in the yaml file | 20:37 |
| mup | PR snapd#1764 opened: Mvo's snap-download2++ <Created by chipaca> <https://github.com/snapcore/snapd/pull/1764> | 20:38 |
| === al_ is now known as Guest94467 | ||
| Guest94467 | Hi ! I have a short question: Is it possible to access a mounted USB drive from a snap using a "strict" confinement ? | 20:43 |
| rcj | jcastro, good to hear that you got it working. sorry I didn't see this earlier to help you out | 21:11 |
| mup | PR snapd#1724 closed: snap: add `snap download` implementation <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1724> | 21:23 |
| mup | PR snapd#1763 closed: many: clarify/tie down model assertion <Critical> <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/1763> | 21:23 |
| jhobbs | i'm trying to package a snap made from two python2 parts, each of which includes some .so depenencies that are built during the packaging | 21:28 |
| jhobbs | some of the .so's are for the same packages and so are at the same path, but have some small differences in them, because they were built at different paths, and at different times maybe - non functional differences | 21:28 |
| jhobbs | I end up with an error like this "Parts 'tempest' and 'ceilometer' have the following file paths in common which have different contents:" | 21:29 |
| jhobbs | I would like to exclude those paths from one of the parts and keep it in the other - is filesets the right way to do that? | 21:29 |
| kyrofa | jhobbs, yes, though the real keywords you're looking for are stage and/or snap (which can use filesets if you like, but don't require them) | 21:33 |
| jhobbs | ah stage is doing it! yay! | 21:34 |
| jhobbs | thanks kyrofa | 21:34 |
| kyrofa | jhobbs, sure thing! | 21:37 |
| Guest94467 | To access to the USB ports from a snap (strict confinement), is there a way to create an interface (plug/slot) ? or something else ? | 21:43 |
| mwhudson | elopio: it's in yakkety already, i should think about making it the default soon i guess | 21:59 |
| mwhudson | elopio: not going to SRU it to xenial, you can add ppa:gophers/archive though | 21:59 |
| elopio | mwhudson: thanks! I wanted to make a snap that requires go1.7. snapcraft doesn't support PPAs yet, but today we were talking about adding build deps as parts instead. | 22:02 |
| elopio | mwhudson: would you be insterested in making parts for go? | 22:02 |
| mwhudson | elopio: i guess so, i'm not very familiar with how that end of things works | 22:05 |
| mwhudson | can you just download the deb and unpack it with dpkg-deb? :) | 22:06 |
| mwhudson | so i see a long conversation about netplan in the scrollback, i guess i should read it | 22:10 |
| elopio | mwhudson: we could, yes. That's the cool thing about the parts. We could have go1.7-from-deb, go1.7-from-archive, go1.7-build-from-source. If we do this nicely, then the part that depends on go could use them interchangeably. | 22:17 |
| elopio | it's late and I'm hungry. I'll bbs. | 22:18 |
| cjwatson | ogra_: ta | 22:41 |
| wililupy | How can I verify snap env variables? | 23:11 |
| wililupy | I think my $SNAP_APP_PATH and $SNAP_APP_DATA_PATH are incorrect for my startup script. | 23:11 |
| kyrofa | wililupy, those are 15.04 variables. Are you using 15.04? | 23:44 |
| wililupy | kyrofa: no, 16.04. I changed them in my script to $SNAP and $SNAP_DATA | 23:50 |
| wililupy | re-compiling and building now.... | 23:50 |
| kyrofa | wililupy, yeah that's what you need | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!