[00:01] <mup> PR snapcraft#1180 closed: tests: support snap directory in external tests <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1180>
[00:22] <mup> PR snapcraft#827 closed: Support setting build targets in the maven plugin. Make the maven plu… <Created by evandandrea> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/827>
[02:19] <mup> PR snapcraft#1181 opened: repo: fixup with python, not sed <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1181>
[02:19] <mup> PR snapcraft#1182 opened: meta: do not quote the command wrapper args <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1182>
[02:26] <Son_Goku> sergiusens: ping
[02:53] <sergiusens> mwhudson: hey, would this fix my problem https://github.com/lxc/lxd-pkg-ubuntu/pull/27 ?
[02:53] <mup> PR lxc/lxd-pkg-ubuntu#27: Quote $@ in the lxc wrapper <Created by sergiusens> <https://github.com/lxc/lxd-pkg-ubuntu/pull/27>
[02:53] <sergiusens> Son_Goku: pong, but you know I am more reliable on rocket ;-)
[02:53] <mwhudson> sergiusens: that looks more plausible yes
[02:54] <Son_Goku> mrrr
[02:54] <sergiusens> mwhudson: great, I guess I can propose for the use of environment and get rid of the wrapper in that branch too
[02:55] <mwhudson> sergiusens: in fact i said on the bug "This bug looks more like a $@ that should be quoted isn't rather than one that is quoted and shouldn't be." :-)
[02:55] <mwhudson> (this hasn't gone out in mail yet afaict)
[02:55] <sergiusens> ah, thanks, well I will invalidate the bug, thanks
[02:55] <mup> PR snapcraft#1182 closed: meta: do not quote the command wrapper args <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1182>
[02:55] <mwhudson> sergiusens: bash quoting is comletely insane
[02:55] <mwhudson> +p
[02:55] <sergiusens> mwhudson: when it comes to something stgraber did I sometimes just doubt myself too much :-)
[02:56] <mwhudson> haha
[07:16] <justinmcp> hey all, can I add gcc, et al., to a snap so that scripts in the snap can compile?
[07:30] <mup> PR snapd#2302 closed: asserts: implement snap-developer type <Created by emgee> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2302>
[07:46] <mup> PR snapcraft#1183 opened: First step; ruby support <Created by justincan> <https://github.com/snapcore/snapcraft/pull/1183>
[07:46] <mup> PR snapd#2752 closed: snap: add support user-sessions from snaps <Blocked> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2752>
[08:45] <mup> PR snapd#2938 closed: cmd/snap-update-ns: compute next action to transition mount profile <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2938>
[08:52] <mup> PR snapd#2782 closed: timeutil: a bunch of helpers for the scheduled refreshes <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2782>
[09:01] <mup> PR snapd#2787 closed: interfaces: add unity8 plug permissions <Created by mikix> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2787>
[09:47] <mup> PR snapd#2978 closed: cmd/snap-confine: use sc_do_umount everywhere <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2978>
[10:03] <mup> Bug #1590767 changed: Support snap installed completion scripts <isv> <snapd-interface> <Snapcraft:Triaged> <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1590767>
[10:20] <mup> PR snapd#2930 closed: tests: add systemd dependency loop failover test scenario <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2930>
[10:27] <mup> Bug #1671776 opened: snap install halt during installation <Snappy:New> <https://launchpad.net/bugs/1671776>
[10:36] <mup> Bug #1671778 opened: failover:emptysystemd test fails <Canonical System Image:New> <Snappy:New> <https://launchpad.net/bugs/1671778>
[11:22] <mup> PR snapcraft#1181 closed: repo: fixup with python, not sed <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1181>
[11:25] <mup> PR snapcraft#1011 closed: ci: use a named docker instance with proper working dir and env <Created by 3v1n0> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1011>
[11:54] <mup> PR snapd#2972 closed: cmd/libsnap: add sc_quote_string <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2972>
[12:00] <mup> PR snapd#2963 closed: interfaces: use MockInfo in tests <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2963>
[12:19] <mup> PR snapd#2986 closed: tests: specify the core version to be unsquashfs'ed in the failover tests <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2986>
[12:20] <mup> PR snapd#3008 closed: testutils: address review feedback from PR#2997 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3008>
[12:25] <mup> PR snapd#3006 closed: interfaces: updates for mir-kiosk in browser-support, mir, opengl, unity7 <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3006>
[12:31] <mup> Bug #1671776 changed: snap install halt during installation <Snappy:Invalid> <https://launchpad.net/bugs/1671776>
[13:09] <mup> PR snapd#2984 closed: interfaces: seccomp spec API tweaks for better tests <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2984>
[13:09] <pstolowski> niemeyer, thank you!
[13:10] <niemeyer> pstolowski: np, and thanks for pushing those!
[13:31] <mup> PR snapcraft#1164 closed: tests: run the master tests against the staging server <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1164>
[14:01] <elopio> didrocks: I think the title here is wrong, because they are not all desktop snaps: https://insights.ubuntu.com/2017/03/09/10-desktop-snaps-written-in-february
[14:03] <mup> PR snapd#3013 opened: cmd/libsnap: simplify sc_string_quote default case <Created by zyga> <https://github.com/snapcore/snapd/pull/3013>
[14:37] <mup> PR snapcraft#1184 opened: store: enable retries for store calls <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1184>
[14:45] <joedborg> thanks for bringing build.snapcraft.io to my attention popey
[14:47] <didrocks> elopio: agreed, I didn't write the content though, just hilighted the ones that should be in
[14:47] <didrocks> elopio: I'll pass the message, but now that it's published…
[14:49] <didrocks> elopio: thanks for noticing btw :)
[14:55] <coreycb> elopio, do you recall what the reason was for having to build python for classic python snaps?  just curious for my own knowledge.
[14:56] <stokachu> anyone know if there is a kpi dashboard for snap downloads?
[14:56] <mup> PR snapd#3014 opened: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014>
[14:57] <coreycb> stokachu, oh hey, maybe you know the answer to my question
[14:58] <stokachu> coreycb: hey! yea there was a reason i just dont remember it, lemme look through git logs
[14:58] <coreycb> stokachu, ok thanks, no big deal really, just curious
[14:59] <stokachu> coreycb: https://github.com/snapcore/snapcraft/issues/1080; https://github.com/snapcore/snapcraft/issues/1090
[14:59] <stokachu> think those were the 2 big ones
[15:00] <elopio> coreycb: I got lost there too. I just got that zyga has more details. Sergio can explain that too.
[15:00] <elopio> it seems both have migrated to rocket chat.
[15:03] <coreycb> stokachu, elopio: thanks.  they're not in here eh?
[15:42] <niemeyer> jdstrand: ping
[15:47] <jdstrand> niemeyer: hey, I saw all your PR pings
[15:47] <niemeyer> jdstrand: Heya
[15:47] <niemeyer> jdstrand: Yeah, was really about to see if you could do a run through today by any chance
[15:48] <jdstrand> niemeyer: I'm going to try my best to get to them today, but I need to attend to a high priority item before them
[15:48] <niemeyer> jdstrand: I did almost a full pass today, and there are quite a few low-hanging fruits in there
[15:48] <niemeyer> jdstrand: Thanks, appreciated!
[15:48] <jdstrand> niemeyer: my plan was: high priority item, go through low hanging fruits PRs and go to higher and higher hanging as have time :)
[15:51] <mup> Bug #1671855 opened: snap command should provide a way to display account ID <Snappy:New> <https://launchpad.net/bugs/1671855>
[15:52] <niemeyer> jdstrand: Sounds perfect, thanks!
[16:08] <jdstrand> niemeyer: I can say I did respond to the maliit one earlier
[16:09] <niemeyer> jdstrand: Sweet, I think that one is ready to merge
[16:11] <Trevinho> I'm running snapd in trusty (with xenial kernel backport)...
[16:11] <Trevinho> and after a reboot no snap seem to work
[16:11] <Trevinho> marco@tricky:~:✗ $ snap run hello
[16:11] <Trevinho> cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_BsULNe//dev: No such file or directory
[16:12] <mup> PR snapd#2793 closed: interfaces: add maliit input method interface <Created by Elleo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2793>
[16:18] <Trevinho> ok, for some reason I had core and multiple snaps marked as "broken"
[16:18] <Trevinho> now it works
[16:18] <Trevinho> check http://paste.ubuntu.com/24152298/
[17:18] <cachio> niemeyer, hi, I am trying to create 2 snaps which use the content interface, and it is not mounting as it would expected, do you know who could help we with that?
[17:19] <niemeyer> cachio: zyga is most familiar with those details.. we're aware of one bug that he's actually working on right now that might impact that exact case
[17:20] <niemeyer> cachio: What are the details?
[17:21] <cachio> basically, 1 snap is creating slots read and write and the other plugs those and it is trying to execute an executeble in the read section
[17:22] <cachio> niemeyer, but when I run the app, I make an ls inside it and I don0t see the directory  mounted where it should be
[17:22] <cachio> basically I should see a directory $SNAP/extra-bin and it is not there from the app context
[17:26] <cachio> niemeyer, should that be affected by that bug?
[17:27] <niemeyer> cachio: Might be.. try this: stop any daemons/processes running from that snap.. type "sudo rm /run/snapd/ns/<snap name>.*", then try again
[17:31] <cachio> niemeyer, getting rm: cannot remove '/run/snapd/ns/kpi-content-consumer-tests.mnt': Device or resource bus
[17:31] <cachio> y
[17:32] <cachio> niemeyer, and there are not any process/daemon running for that snap
[17:34] <niemeyer> cachio: That probably means something is still running from that snap
[17:35] <niemeyer> cachio: Sorry, you may need to umount it actually
[17:35] <niemeyer> cachio: sudo umount it
[17:38] <cachio> niemeyer, ok
[17:38] <cachio> cannot mount /snap/kpi-content-producer-tests/x14/bin at /snap/kpi-content-consumer-tests/x24/extra-bin with options bind,ro: No such file or directory
[17:38] <cachio> I should create the dir extra-bin first?
[17:42] <cachio> niemeyer, or snapd should do that?
[17:43] <niemeyer> cachio: That directory is read-only, so you need to provide it in your snap
[17:44] <cachio> niemeyer, ok, make sense
[18:01] <Fohlen-> heya there. Is it any way possible to use a virtualenv in a scriptlet?
[18:01] <Fohlen-> seems to be buggy as hell for me
[18:02] <Fohlen-> I do want to use conan which is installable via pip, but global install seems to be even more buggy
[18:03] <kyrofa> Fohlen-, hmm, and using `python-packages` isn't working?
[18:03] <kyrofa> Oh wait, conan is a build system huh
[18:03] <Fohlen-> kyrofa: nope.When using python from a scriptlet with the python plugin it falls back to the system python
[18:03] <Fohlen-> which is quiet annoying
[18:03] <kyrofa> Fohlen-, I've never tried with virtualenvs from scriptlets, but worst case you can write a custom plugin for it
[18:03] <Fohlen-> I probably have to
[18:03] <kyrofa> Fohlen-, yeah, that makes sense
[18:04] <kyrofa> Fohlen-, I think you've reached the limits of scriptlets, heh
[18:04] <Fohlen-> apparently I did :)
[18:04] <kyrofa> Fohlen-, just put the custom plugin in snap/plugins/, you can distribute it along with the snapcraft.yaml
[18:04] <Fohlen-> kyrofa: in that case I'd have to use env variables from snapcraft, would that be feasonable?
[18:05] <kyrofa> Fohlen-, I'm not sure what you mean
[18:05] <Fohlen-> consider this,       CONAN_USER_HOME=$SNAPCRAFT_PART_INSTALL/usr/local/games/inexor conan install . --build=missing
[18:05] <Fohlen-> as a plugin
[18:05] <Fohlen-> I'd need it to install the dependencies inside the snap, otherwise it breaks when packaging up
[18:05] <Fohlen-> :|
[18:06] <kyrofa> Oh certainly
[18:06] <kyrofa> Fohlen-, when you shell out to call conan, you can set the environment right there
[18:06] <Fohlen-> that was what I did initially, and it nicely broke up on another systm
[18:06] <Fohlen-> kyrofa: how'd I do that?
[18:06] <Fohlen-> and would that work out with a plugin?
[18:07] <Fohlen-> https://github.com/Fohlen/conan-snapcraft
[18:07] <Fohlen-> is what the plugin looks like
[18:08] <kyrofa> jdstrand, any idea what's happening here? https://askubuntu.com/questions/888497/snap-confine-refuses-to-launch-application-to-avoid-permission-attack
[18:11] <jdstrand> kyrofa: it looks like snap-confine is compiled for enforce mode and installed setuid but there is no apparmor profile for it
[18:11] <jdstrand> kyrofa: this is something zyga added recently
[18:11] <kyrofa> jdstrand, someone in rocket is getting that error claiming to be running normal Ubuntu 16.04. How could that happen?
[18:11] <kyrofa> Ah, hmm
[18:12] <jdstrand> kyrofa: perhaps the profile was unloaded?
[18:12] <jdstrand> kyrofa: eg, sudo aa-status | grep snap-confine
[18:13] <jdstrand> kyrofa: there is something mvo was working on that would run snap-confine from the core snap with a path to the profile from the core snap. not sure if that landed, but if it did and it is trying to run that snap-confine but that profile isn't loaded, the same thing would happen
[18:14] <kyrofa> jdstrand, oh interesting, although I expect that would break for everyone
[18:22] <kyrofa> jdstrand, of course, he left :(
[18:22] <kyrofa> jdstrand, well anyway, thanks for the info! Not sure what's happening here
[18:24] <cachio> niemeyer, working now, that umount that I have to do should be fixed whith that bug that you mentioned?
[18:24] <niemeyer> cachio: Right, it's supposed to work dynamically.. no need to do anything else other than connecting the interface
[18:24] <cachio> niemeyer, great, thanks
[18:24] <niemeyer> cachio: If you sit here in the channel in the next few days you'll hear about the term "update-ns".. that's what this is about
[18:25] <cachio> niemeyer, great
[18:26] <cachio> niemeyer, thanks for the help
[18:27] <lutostag> if somebody can review for snap id: N6CL1Ml1gj5SmGCmyy97CSvE3vzgjfb3, would be appreciated
[18:36] <mup> PR snapd#3015 opened: interfaces: alphabetize framebuffer in base decl and add it to all_test.go <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3015>
[18:50] <mup> PR snapcraft#1142 closed: state: asset tracking - store versions of stage-packages <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1142>
[18:50] <kyrofa> jdstrand, the user came back, saying the aa-status command you gave me produced no result, which I assume means the profile was unloaded somehow?
[18:58] <alecu> jhodapp: hi! I think there might be a markup mistake in this page, because code and prose sections seem to switch place towards the end of the document: https://docs.ubuntu.com/core/en/stacks/bluetooth/doc/overview
[18:58] <alecu> jhodapp: wanted to submit a patch, but I can't the bluetooth docs here: https://github.com/CanonicalLtd/ubuntu-core-docs/tree/master/en/stacks
[18:58] <alecu> am I looking at the right place?
[18:59] <jhodapp> alecu, the actual docs are part of the bluez snap
[18:59] <jhodapp> alecu, we keep them distributed and they get pulled in with repo
[18:59] <alecu> ah, that sounds better
[18:59] <jhodapp> that makes it much easier for developers to contribute docs
[18:59] <jhodapp> let me get you the link to the docs
[19:00] <jhodapp> alecu, here you go: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez/tree/doc/overview.md
[19:02] <alecu> jhodapp: seems to be be missing  ``` in line 199
[19:48] <alecu> jhodapp: https://code.launchpad.net/~alecu/snappy-hwe-snaps/+git/bluez/+merge/319613
[19:49] <jhodapp> alecu, nice
[19:49]  * jhodapp looks
[19:50] <alecu> took me a while to figure out git in lp :P
[19:50] <jhodapp> alecu, yes it's pretty different from the way most other git web systems work
[19:50] <jhodapp> we tried to fit a square peg in a round hole there ;)
[19:50] <alecu> hahah, right
[19:51] <jhodapp> alecu, good feedback on the docs too...we'll update the readme so that it's obvious that the stack documentation is distributed
[19:51] <alecu> jhodapp: btw, do you know if bluetooth is supported on the raspi3 with core? I can't seem to get it to work
[19:51] <alecu> perhaps I should ask ogra_ about that
[19:51] <jhodapp> alecu, ask morphis or koza...I'm not sure
[19:51] <alecu> sounds good, thanks
[19:51] <jhodapp> I only have a pi2 and dragonboard and can't remember off hand
[19:52] <alecu> right, pi2 does not have onboard bt
[19:52] <jhodapp> exactly
[19:52] <alecu> alright, thanks a bunch!
[19:53] <jhodapp> alecu, not a problem!
[20:07] <mup> PR snapd#3016 opened: interfaces: add kubernetes-support interface and adjust related interfaces (LP: #1664638) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3016>
[20:18] <alecu> jhodapp: and, here's another tiny fix: https://code.launchpad.net/~alecu/snappy-hwe-snaps/+git/bluez/+merge/319620
[20:20] <jhodapp> alecu, keep 'em coming :)
[20:20] <jhodapp> alecu, are you sure it needs that? konrad assured me we have the alias on the store side in place for that
[20:22] <alecu> jhodapp: well, after sshing into the raspi and installing the bluez snap, I can't find the bluetoothctl command
[20:22] <alecu> I do find bluez.bluetoothctl
[20:22] <alecu> perhaps I need a newer snap, or edge?
[20:22] <alecu> let me try that
[20:23] <jhodapp> alecu, you might and it may in fact be going out soon
[20:23] <jhodapp> alecu, try "snap aliases"
[20:24] <alecu> jhodapp: ah! the snap on edge is rev27. The one I had from stable is rev12 !!!
[20:24] <jhodapp> alecu, yup, that's the issue
[20:24] <alecu> jhodapp: I refreshed the snap, and now I can see the alias
[20:25] <jhodapp> awesome
[20:25] <alecu> wonderful :-)
[20:26] <alecu> and, now I've learned about aliases
[20:26] <jhodapp> quite an afternoon ;)
[20:26] <jhodapp> aliases are awesome
[20:27] <alecu> certainly useful for other snaps we are preparing...
[20:27] <jhodapp> absolutely
[20:29] <alecu> and, with the latest snap on the raspi, bluetoothctl still can't find the controller
[20:30] <alecu> so, I guess I'll bother ogra_ and morphis next week
[20:30] <alecu> jhodapp: thanks a bunch!
[20:30] <jhodapp> np
[20:41] <cachio> niemeyer, hey, quick question, I ma trying to create a file socket within a snap and > I get Bad system call (core dumped)
[20:41] <cachio> If I run the python code it works properly, but if failes when I call the snap app
[20:42] <cachio> niemeyer, any idea about what could be the reason? or where I could see the logs?
[20:51] <cachio> niemeyer, this is the only I see in the syslog http://paste.ubuntu.com/24153684/
[20:52] <kyrofa> cachio, that's a seccomp filter denial. You're probably missing the network plug
[20:52] <kyrofa> (or network-bind)
[20:52] <kyrofa> cachio, you could learn more by using snappy-debug
[20:52] <jdstrand> it would also tell you to use network-bind
[20:53] <kyrofa> cachio, and run `sudo snappy-debug.security scanlog` in one terminal while running your app in the other
[20:53] <jdstrand> $ scmp_sys_resolver 49
[20:53] <jdstrand> bind
[20:53] <kyrofa> jdstrand, did you actually run that, or do you have 49 memorized? ;)
[20:54] <jdstrand> you shouldn't have to use the network-bind interface to use a unix socket, but for now you do
[20:54] <jdstrand> kyrofa: I actually did have it memorized, but I double checked myself :)
[20:54] <cachio> kyrofa, jdstrand great, thanks for the info
[20:54] <kyrofa> jdstrand, haha, nice
[20:55] <cachio> kyrofa, jdstrand I am creating a file socket for process communication, should I use the networking plugin in that case too?
[20:56] <jdstrand> cachio: network-bind should be sufficient. use snappy-debug and it'll tell you for sure
[20:56] <cachio> jdstrand, ok, I'll do it, thanks
[20:58] <cachio> jdstrand, ERROR: Could not find '/snap/snappy-debug/27/policy/17'
[20:58] <mup> Bug #27: temporary test <iso-testing> <Baz (deprecated):Invalid> <https://launchpad.net/bugs/27>
[20:58] <cachio> snappy debug is giving me that
[20:58] <jdstrand> whoa
[20:59] <jdstrand> oh, what release are you on?
[20:59] <jdstrand> zesty?
[20:59] <cachio> zesty
[21:02] <cachio> jdstrand, snapd 2.22.7
[21:03] <jdstrand> cachio: can you do 'snap refresh snappy-debug --edge' and try again?
[21:04] <cachio> jdstrand, sure
[21:04] <cachio> jdstrand, it worked
[21:05] <cachio> jd tx
[21:05] <jdstrand> cachio: np
[21:50] <jdstrand> roadmr: hey, would you mind pulling r847 into the store? it isn't an emergency. next week is fine
[21:50] <roadmr> jdstrand: sure thing, I'll put it in the pipeline and check what the deployment status is
[21:51] <jdstrand> roadmr: oh, actualy, give me a second
[21:51] <roadmr> jdstrand: sure thing, I haven't proposed anything yet
[21:51] <jdstrand> I added the code to override but I didn't add the thing to override :)
[21:51] <roadmr> haha :) who overrides the overrider?
[21:54] <jdstrand> roadmr: ok, r848
[21:55] <jdstrand> heh
[21:56] <roadmr> jdstrand: did I hear something about snapd on trusty installing systemd which then makes $SOMETHING go crazy? this may be juju-related only :(
[21:57] <jdstrand> roadmr: snapd on trusty will install a special systemd, yes. I haven't heard about anything going crazy. if you are seeing something, please file a bug so the snappy team can take a look at it
[21:57] <roadmr> jdstrand: ok, I'll dig up the comment I saw.
[22:26] <mup> PR snapcraft#1185 opened: repo: add version support for build-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1185>
[23:05] <jdstrand> niemeyer: ok, I was able to get to everything you pinged my on except the mknod branch. mvo could answer on that, but I'd like to be around when that lands, so I will comment when I am back
[23:06] <jdstrand> pinged me*
[23:06] <niemeyer> jdstrand: Thanks so much!
[23:06] <jdstrand> np
[23:06] <niemeyer> jdstrand: I'll try to find some time over the weekend to merge what I'm able to
[23:07] <jdstrand> cool
[23:30] <jdstrand> niemeyer: actually, there was one I handed off to Tyler-- PR#2624
[23:31] <jdstrand> (pid-1 mount namespace)
[23:31] <jdstrand> so he'll follow through on that in my absence