[01:18] <mup> PR snapcraft#2828 opened: Appstream <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2828>
[01:42] <mup> PR snapd#7827 closed: tests: apply change on permissions to serial port on hotplug test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7827>
[06:30] <mborzecki> morning
[07:14] <sdhd-sascha> good morning
[08:04] <pstolowski> morning
[08:14] <mborzecki> pstolowski: mvo: morning guys
[08:15] <mvo> hey mborzecki and pstolowski ! good morning
[08:16] <mvo> mborzecki: how are you? and what did I miss :) ?
[08:17] <mborzecki> mvo: nothing special, fri/mon were rather slow
[08:17] <mvo> mborzecki: *nod* are tests ok ? or do they need investigation?
[08:18] <mborzecki> mvo: got 2 prs green this morning, so things seem ok
[08:19] <mvo> mborzecki: \o/
[08:20] <mvo> mborzecki: great! anything I can help with right away? otherwise I will just do the usual mail+check prs
[08:20] <mborzecki> mvo: yday there were some concerns about https://github.com/snapcore/snapd/pull/7743 regarding having a partition from the block device mounted at the time of bootstrapping
[08:20] <mup> PR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
[08:21]  * mvo looks
[08:22] <mvo> mborzecki: woah, nice find in 7824
[08:23] <mvo> mborzecki: do you happen to know if there is an upstream bugreport for mksquashfs? it sounds like worth asking for a "-strict" (or whatever) switch that would actually error in situations like this (it's hard for me to imagine when it's useful to *not* error by default)
[08:23] <zyga> good morning
[08:23] <mvo> mborzecki: anyway not super important, just an idle thought
[08:23] <mvo> zyga: good morning!
[08:24] <zyga> :)
[08:24] <zyga> mvo: yeah, thinks seem calm, just reviews and iteration
[08:24] <mborzecki> zyga: hey
[08:24] <mvo> zyga: how are you? jetlag better?
[08:24] <mborzecki> mvo: didn't check
[08:25]  * mvo was super tired this morning but otherwise feeling good
[08:25] <zyga> mvo: yeah :-) It's all over finally :)
[08:25]  * mvo just gets more tea and everything will be back to normal :)
[08:25] <mvo> zyga: yay!
[08:25] <zyga> mvo: I tried to record my first ubuntu core video
[08:25] <mvo> zyga: I read somewhere it take ~1day per hour timezone difference
[08:25] <zyga> mvo: more attempts today, it's a lot of work :D
[08:25] <mvo> zyga: that's so cool!
[08:29] <mvo> mborzecki: also - holly cow - 7821!
[08:29] <mvo> mborzecki: pretty impressive numbers
[08:29] <mup> PR snapd#7822 closed: devicestate: ensure system installation <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7822>
[08:29]  * mvo hugs mborzecki 
[08:30] <mup> PR snapd#7820 closed: boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7820>
[08:40] <pedronis> mvo: hi, a post-merge remark on #7820
[08:40] <mup> PR #7820: boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7820>
[08:45] <mvo> pedronis: thank you, on it
[08:45] <mvo> pedronis: uh, sorry, indeed, will fix right away
[08:56] <mvo> pedronis: I added a comment to 7823 (which is also shorter now that bits from master are merged)
[09:01] <pedronis> mvo: ok,  what should I review next?
[09:01] <pedronis> I mean for UC20
[09:02] <mvo> pedronis: 7823 would be nice, then I want to ponder about 7762, my gut feeling is that some of the partition finding could/should move to snap-bootstrap
[09:02] <mvo> pedronis: and then I want to update 7817 based on your feedback
[09:02] <mvo> pedronis: I hope this sounds sensible
[09:12] <pedronis> mvo: fwiw I had the same wondering at some point, about the partition finding
[09:20] <mvo> pedronis: in 7762 ?
[09:21] <pedronis> yes
[09:26]  * mvo nods and will have a look
[09:33] <mborzecki> hm master unit tests broken?
[09:35] <zyga> mborzecki: oh?
[09:35] <mborzecki> must be the devicemgr PR that landed
[09:35] <mborzecki> https://paste.ubuntu.com/p/sdjF7VJbfC/
[09:35] <zyga> indeed
[09:36] <zyga> mborzecki: are you pushing or shall I?
[09:36] <zyga> or better yet
[09:36] <zyga> mvo:  can you push a trivial directly to master/
[09:36] <zyga> https://www.irccloud.com/pastebin/PZj3DJ9C/
[09:37] <zyga> mvo: will save us an hour
[09:37] <mborzecki> hahah
[09:39] <zyga> I'll open a PR just in case
[09:40] <zyga> all this CI
[09:40] <zyga> ...
[09:40] <mvo> zyga: can do
[09:40] <zyga> mvo: thanks
[09:43] <mvo> zyga: should be fine now
[09:44]  * zyga thanks :)
[09:49] <mborzecki> pedronis: hi, i've updated #7821
[09:50] <mup> PR #7821: [RFC] interfaces/seccomp: parallelize seccomp backend setup <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
[09:53] <pedronis> mborzecki: thanks, queued
[09:57]  * zyga has some food poisoning this morning
[09:57] <mborzecki> pedronis: cool, thanks
[09:57] <zyga> if I'm not responsive, that's why :/
[10:06] <mup> PR snapd#7824 closed: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
[10:06] <mup> PR snapd#7830 opened: Include hooks in plug/slot apparmor label <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
[10:57] <niemeyer> Hellos
[10:57] <niemeyer> mvo: ping
[11:06] <mvo> hey niemeyer
[11:06] <niemeyer> mvo: Heya
[11:06] <niemeyer> mvo: Do you have a moment for a call?
[11:07] <niemeyer> mvo: I'm setting up mup and was going to ask about it, but actually it would be nice to have a quick sync call if you have a few spare minutes
[11:07] <mvo> niemeyer: yes, sure!
[11:07] <niemeyer> mvo: Nice, let me grab a cup of coffee quickly and will drop you a link
[11:08] <pstolowski> mborzecki: i think Sergio addressed your comments to https://github.com/snapcore/snapd/pull/7815 ; can we land it?
[11:08] <mup> PR #7815: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815>
[11:10] <mup> PR snapd#7815 closed: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7815>
[11:10] <pstolowski> ty!
[11:11] <zyga> mborzecki: hey
[11:11] <zyga> mborzecki: I moved the code we talked about to sandbox/cgroup
[11:11] <zyga> mborzecki: shall I push that to https://github.com/snapcore/snapd/pull/7825 ?
[11:11] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[11:17] <pstolowski> Chipaca: hey, question to you on https://bugs.launchpad.net/snapd/+bug/1838786
[11:18] <mup> Bug #1838786: Categories not returned in /v2/find results <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1838786>
[11:18] <Chipaca> pstolowski: yep, tks
[11:18] <pstolowski> Chipaca: i might have asked about it during my last triage duty ;)
[11:19] <pstolowski> if you update it, i'll stop asking ;)
[11:19] <Chipaca> pstolowski: i mean, there isn't a status for "started, will be completed, but not being worked on right now"
[11:19] <pstolowski> true, np, just comment on it
[11:22] <zyga> mborzecki: updated
[11:23]  * zyga returns to garden next branch in a moment
[11:30] <zyga> re
[11:31] <zyga> 15C in the office
[11:31] <zyga> no wonder I have a cold
[11:33] <mborzecki> zyga: you should really get a heater or sth
[11:33] <mborzecki> quick errand, back in 20
[11:33] <xnox> zyga:  i was off on monday. Reading backscross with cmatsuoka, in the initrd /dev is populated by multiple things: a) devtmpfs (ie. kernel itself) b) processing /lib/modules/{kver}/modules.devname by systemd-tmpfiles c) anything else statically created
[11:41] <zyga> xnox: aha
[11:41] <zyga> xnox: do you know what's the relationship between devtmpfs and in-kerenl kobj events
[11:42] <zyga> xnox: I can point you to specific lines in the kerenl
[11:42] <zyga> xnox: for instance when the block device layer drops and re-creates partitions
[11:42] <zyga> xnox: is that automatically reflected in devtmpfs?
[11:42] <zyga> mborzecki: the heater is on now
[11:44] <xnox> zyga:  no, and why should it be?
[11:44] <zyga> pstolowski: small suggestion for the label expr branch
[11:45] <zyga> xnox: I'm not yet sure about "should" vs "not should" - just trying to piece together my undersstanding
[11:45] <zyga> xnox: when the ioctl to rescan partition table is issued
[11:45] <xnox> kernel needs to be told to reload the partitions...... i.e. using kpartx, blockdev, etc.
[11:45] <zyga> xnox: the kernel removes and re-creates partition nodes
[11:45] <zyga> xnox: when this happens the kernel side is updated
[11:45] <zyga> xnox: but what about the filesystem?
[11:45] <zyga> xnox: I'm trying to understand what updates /dev/ itself
[11:46] <zyga> xnox: is that some minimal udev running in initrd or is that directly done by the kernel
[11:46] <xnox> kernel udev events are emitted, which udev processes, and does changes to.
[11:46] <xnox> not minimal, but full-fat udevd.
[11:46] <zyga> ah, so there is real udev there?
[11:46] <zyga> ah
[11:46] <xnox> in all of our initrds.....
[11:46] <zyga> ok, that explains everything I was wondering about
[11:46] <zyga> cool, thank you
[11:46] <xnox> but it may have different set of udev rules & helpers (i.e. raid/lvm/cryptsetup/dm-setup might be missing)
[11:46] <zyga> xnox: if you are interested in the backstory
[11:46] <xnox> or even versions
[11:46] <zyga> xnox: there was some discussion about this specific part:
[11:47] <xnox> for example, old initrd may have older systemd, and thus initrd symlinks/names might be different to the "booted" system.
[11:47] <zyga> https://github.com/snapcore/snapd/pull/7743
[11:47] <mup> PR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
[11:47] <zyga> xnox: that's interesting
[11:47] <zyga> xnox: (when I say interesting, I mean, how are we going to handle that)
[11:52] <zyga> pstolowski: your patch looks good, I suspect the failure shows something that is broken but was dormant before
[11:53] <pstolowski> zyga: i don't know, it's super weird.. opening { is missing, closing } is there. i don't see how this is possible
[11:54] <zyga> pstolowski: can you paste the line please
[11:56] <mborzecki> re
[11:56] <zyga> mborzecki: 18C now
[11:56] <zyga> mborzecki: +4 outside
[12:00] <mborzecki> zyga: showing 2C outside here, though it's sunny yay
[12:01] <ppd1990> Hi. Is there anyone here I can poke for a transfer request? My forum request is getting a little stale ;-) (https://forum.snapcraft.io/t/please-transfer-solvespace-to-solvespace-account/14342)
[12:02] <pstolowski> zyga: peer=(label="snap.core.}"),
[12:05] <zyga> ha
[12:05] <zyga> I ... know
[12:05] <zyga> pstolowski: do you see it?
[12:05] <zyga> https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR66
[12:06] <mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
[12:06] <zyga> it must only truncate if len(names) > 0
[12:06] <zyga> pstolowski: add a test for that please
[12:07] <zyga> pstolowski: in addition https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR45 may need to be dropped
[12:07] <zyga> and instead the name collection may have to move earlier
[12:07] <mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
[12:07] <zyga> pstolowski: so that the same if one {  } else if zero else { } flow can remain
[12:09] <pstolowski> zyga: ha, thanks for spotting
[12:17] <pstolowski> ok, i think i got it simplified, running the tests.. short break, going to collect my usb hub from post office
[12:17] <zyga> pstolowski: cool, good luck!
[12:22] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7825 again
[12:22] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[12:22] <zyga> mborzecki: I'll find those tests I wrote for some of the TODOs there
[12:22] <mborzecki> ok
[12:22] <zyga> mborzecki: but I did some structural changes you asked for
[12:58] <pedronis> mvo: #7823 looks fine afaict
[12:58] <mup> PR #7823: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7823>
[13:38] <pstolowski> zyga: is label="snap.core." same as label="snap.core.*" ?
[13:38] <zyga> pstolowski: no, it is not
[13:40] <pstolowski> zyga: is "snap.core." matching anything?
[13:41] <zyga> only the label "snap.core."
[13:41] <zyga> which nothing in our system will have
[13:43] <pstolowski> zyga: good
[13:43] <pstolowski> zyga: one more twist in that PR
[13:43] <pstolowski> (not pushed yet)
[14:04] <mup> PR snapd#7829 closed: tests: fix the channels checks done on nested tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7829>
[14:20] <jdstrand> pedronis: hey, amurray asked you to respond to https://forum.snapcraft.io/t/system-files-under-mozilla-native-messaging-hosts
[14:21] <jdstrand> pedronis: but per our conversation in Vancouver, I will
[14:22] <pedronis> jdstrand: thx
[14:23] <pedronis> jdstrand: #7768 needs a unit test fix
[14:23] <mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
[14:24] <jdstrand> pedronis: yep, hoping to get to that today. thanks
[14:24] <pedronis> zyga: jdstrand asked you to (re)review #7228
[14:24] <zyga> ack, will do
[14:24] <mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
[14:29] <mborzecki> cmatsuoka: you broke github ;) just got an email with '@cmatsuoka pushed 0 commits.'
[14:31] <roadmr> hmm... push --overwrite with an unchanged branch?
[14:31] <roadmr> er --force (sorry, too much bzr)
[14:31] <pedronis> pstolowski: let me know if we should have a chat about services tomorrow or later in the week
[14:31] <cmatsuoka> I'm pushing 0 commits all the time
[14:31] <zyga> brb, lunch
[14:32] <cmatsuoka> But yeah, I don't know what happened there, I'll check
[14:32] <mup> PR snapd#7831 opened: [RFC] gadget: extract and export new DiskFromPartition() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/7831>
[14:33] <pstolowski> pedronis: ok, thanks, will think a bit more and maybe tomorrow
[14:48] <mup> PR snapd#7832 opened: [RFC] snap-bootstrap: support auto-detect device in create-partitions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832>
[14:53] <pedronis> mvo: what's the relation of 7831 and 7832, does one need the other or are they exclusive?
[14:54] <mvo> pedronis: I think we want something like 7831 in any case, i.e. have just a single way to find a parent-disk from a partition
[14:54] <pedronis> ok
[14:55] <mvo> pedronis: with 7832 it goes one step further and move the business of finding that disk from devicemanager into the low-level of snap-boostrrap
[14:56] <mvo> pedronis: my feeling is that devceimanager is too high level for dealing with the low-level bits that are currently done there in 7762. but I could be wrong and this is why I want a second opinion :) and code seems to be the easiest way to express the question
[15:01] <mborzecki> cmatsuoka: mvo: for uc20, is the ubuntu-seed partition encrypted?
[15:03] <pedronis> mborzecki: no
[15:04] <pedronis> only -data and -save will be
[15:06] <mborzecki> pedronis: thx
[15:07] <mup> PR snapcraft#2817 closed: snapcraft/plugins: Add gomod plugin <Created by mhilton> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2817>
[15:18] <mup> PR snapd#7833 opened: HACKING.md: add nvidia options to configure example <Documentation> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7833>
[15:18] <ijohnson> degville: when you get a chance could you quick take a look at ^
[15:19] <ijohnson> also I created a new tag for PR's in snapd called "Documentation", I don't think we'll have many such PR's but seems nice to have
[15:19] <degville> ijohnson: will do - thank you!
[15:24] <cachio> mborzecki, hey, when you have few minutes could you please give a second round to #7826
[15:24] <mup> PR #7826: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7826>
[15:25]  * cachio lunch
[15:34] <pedronis> mvo: the approach in #7832 looks reasonable
[15:34] <mup> PR #7832: [RFC] snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832>
[15:34] <mvo> pedronis: \o/
[15:34] <mvo> pedronis: thanks for the feedback
[15:35] <pedronis> Chipaca: #7771 will need a re-review
[15:35] <mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
[15:35] <pedronis> but I asked for some changes
[15:35] <Chipaca> yep yep
[15:35] <pedronis> still
[15:35] <Chipaca> this thing might be interesting for a few of us: http://www.brendangregg.com/blog/2019-12-02/bpf-a-new-type-of-software.html
[16:07] <zyga> back from lunch
[16:07] <zyga> but need to take a break now
[16:07] <zyga> back in 2 hours to wrap up the day
[16:07] <zyga> Chipaca: I looked at that
[16:07] <zyga> Chipaca: it's really true in many ways
[16:08] <zyga> changes what needs to be done as a kernel patch
[16:54]  * Chipaca afk
[17:45] <mup> PR snapd#7834 opened: tests: move the watchdog timeout to 2s to make the tests work in rpi <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7834>
[17:49] <zyga> re
[17:49]  * zyga was sleeping 
[17:49] <zyga> back to work
[17:49] <zyga> with some tea to help
[17:54]  * Chipaca soft-EODs 
[17:55] <cmatsuoka> signal(SIGEOD, SIG_IGN)
[18:26]  * Chipaca feels ignored, now
[18:27]  * Chipaca might get used to this
[19:10]  * zyga hugs Chipaca 
[19:10] <zyga> I just discovered mold behind a whiteboard
[19:11] <zyga> "yay"
[19:14] <mup> PR snapcraft#2829 opened: store cli: push title and license on push-metadata <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2829>
[20:02] <jdstrand> noise][: hey, who would I talk to these days about the snap-store-proxy?
[20:04] <jdstrand> noise][: I see bloodearnest uploaded it last
[20:05] <jdstrand> bloodearnest: hey, curious why the snap-store-proxy is only available on amd64. I was going to try to configure it locally for an armhf device but can't...
[20:12] <roadmr> jdstrand: we just haven't built for other arches because who would want to host a store-proxy on a raspberry pi :)
[20:12] <roadmr> jdstrand: (I think - there may be a real reason behind it but the truth is the main audience would be enterprises which are more likely to host a beefy org-wide proxy on a big amd64 box)
[20:15] <jdstrand> roadmr: well, I was literally trying to do that. I wanted to use uc18 on an rpi3 on an hd. I figured the the proxy itself would not be resource intensive and just needs disk, which is easy enough to do
[20:16] <noise][> jdstrand: i think there was a reason … maybe one of the components we are using wasn't readily available on arm, but we'd have to have someone go poke at it again
[20:16] <roadmr> jdstrand: well it does need a postgres database
[20:16] <jdstrand> roadmr: personally, I do quite a bit of dev with quite a few devices and was getting tired of always reaching out to the store with refreshes, etc, etc
[20:16] <jdstrand> roadmr: it is already installed :)
[20:16] <roadmr> jdstrand: the rpi is probably 10x more powerful than the first server I set up a pg database on, so that should be covered, but it does sound odd to have that on a pi :)
[20:17] <jdstrand> roadmr: snap install postgresql10
[20:17] <roadmr> \o/
[20:17] <jdstrand> roadmr: it is literally begging to be used right now :)
[20:17] <roadmr> hehe
[20:17]  * cachio afk
[20:17] <jdstrand> I guess I am begging for it to be used too...
[20:17] <jdstrand> :)
[20:21] <jdstrand> roadmr: fyi, loadavg is nearly all 0s with 444M of ram free with pg running... figured this would actually be a nice use of the pi...
[20:22] <jdstrand> anyhoo, curious on the outcome of that
[20:22] <roadmr> jdstrand: I'll check with twom and bloodearnest tomorrow to see what the reason was
[20:23] <jdstrand> roadmr: thanks!
[20:27] <mup> PR snapd#7828 closed: tests: demand silence from check_journalctl_log <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7828>
[20:27] <bloodearnest> jdstrand: o/ it's just a matter of doing the work to support it - we have go services built, so if that can build for armhf, we should be able to. There's also a horrible LD_PRELOAD shim (due to https://forum.snapcraft.io/t/seccomp-filtering-for-setgroups/2109/10) that we'd need to build for armhf too, but it should be doable.
[20:28] <bloodearnest> everything else is python and archive packages
[21:00] <jdstrand> bloodearnest: well, we build a lot with go on arm, so that is hopefully not a problem. there is https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/lib.c that should work with setgroups
[21:01] <jdstrand> bloodearnest: as documented in https://forum.snapcraft.io/t/system-usernames/13386
[21:01] <jdstrand> bloodearnest: so, if this is something that you're interested in, you have a tester and a user :)
[21:02] <bloodearnest> jdstrand: thanks. I don't have an armhf device handy, but I'll add a trello card for it
[21:03] <jdstrand> bloodearnest: while I have you, I was a little surprised that snap-store-proxy didn't ship its own pg. I mean, I understand that snap-store-proxy might want to use an external pg, but also seemed like it might be nice to not be required to
[21:03] <jdstrand> bloodearnest: I think that is what the maas snap is doing (though I'm not sure)
[21:03] <jdstrand> bloodearnest: anyhoo, thanks!
[21:04] <bloodearnest> jdstrand: we want'd do, but postgresql has a hard coded if (uid != 0) { error() } type check. So we'd have to patch it and build our own to run it.
[21:05] <bloodearnest> Unless running as non-uid-zero users in a service are now a thing, and I missed that?
[21:05] <jdstrand> bloodearnest: it is now a thing: https://forum.snapcraft.io/t/system-usernames/13386
[21:06] <bloodearnest> jdstrand: well, hello there, that is nice. Ok, we might add that now :)
[21:06] <jdstrand> bloodearnest: you don't have the nicety of User=/Group= in the systemd unit yet, but you can solve that with a wrapper
[21:07] <bloodearnest> jdstrand: so the wrapper needs to su?
[21:07] <jdstrand> bloodearnest: I was actually wondering if maybe you wanted to run the proxy as snap_daemon, but didn't want to push my luck since you were so nice with the armhf question :)
[21:09] <bloodearnest> jdstrand: I totally would prefer to run all the services as snap_daemon, including a bundled pg. Does setgroups for snap_daemons gid work?
[21:09] <bloodearnest> I'll add some bugs to track these I think.
[21:10] <jdstrand> bloodearnest: I was thinking a C wrapper. su is allowed in the policy currently. runuser might work. let me try real quick
[21:11] <bloodearnest> we already wrap our servcies in a bash exec launcher, for various reasons, so su would be simpler
[21:11] <jdstrand> bloodearnest: setgroups still needs to use '0, NULL' as mentioned in the forum, but setgid and setuid and the whole family (setreuid, setresuid, etc) all work
[21:11] <jdstrand> err, su isn't* allowed in the policy currently. that won't work come to think of it cause of pam
[21:12] <bloodearnest> ah, yeah
[21:12] <bloodearnest> hmm
[21:12] <jdstrand> but let me try something with runuser
[21:12]  * jdstrand plays for a minute
[21:43] <jdstrand> bloodearnest: ok, so like su, runuser needs pam so no go. however, start-stop-daemon from dpkg can be used with an LD_PRELOAD. so I updated https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/lib.c to also handle initgroups and then can do: LD_PRELOAD=$SNAP_COMMON/wraplib.so ./start-stop-daemon --pidfile /dev/null --start --chuid snap_daemon --group snap_daemon --startas /bin/sh -- -c "sleep 300"
[21:44] <jdstrand> bloodearnest: that was within 'sudo snap run --shell test-snapd-daemon-user.drop' and cd'd into SNAP_COMMON and copied the wraplib.so and start-stop-daemon there
[21:45] <bloodearnest> jdstrand: thanks. That is more complex than I'd like - is User=/Group= support in systemd unit file on the roadmap?
[21:45] <jdstrand> bloodearnest: it isn't 'pretty', but if you are already compiling an LD_PRELOAD (which it sounds like you are), you need only stage-packages dpkg. that said, if you are already compiling an LD_PRELOAD, you could modify drop.c from that same branch
[21:47] <bloodearnest> jdstrand: right, we're just using the LD_PRELOAD for nginx, we run about 6 python services and a golang one too.
[21:47] <jdstrand> bloodearnest: isn't on the 'committed to do it for 20.04' roadmap, but it is queued in trello for whenever I can squeeze it in
[21:47] <bloodearnest> jdstrand: ack, thanks
[21:48] <jdstrand> bloodearnest: since you are doing it for nginx, you could set 'environment' in the snapcraft.yaml for anything that uses initgroups
[21:49] <jdstrand> I could write a 'runas' binary in that tree
[21:49] <ijohnson> bloodearnest, I made a postgres snap with snap_daemon
[21:50] <jdstrand> ijohnson: what did you do to drop?
[21:50] <jdstrand> ijohnson: and what is the name of that snap? I'd like to use yours instead of the one I have
[21:50] <jdstrand> :)
[21:50] <ijohnson> bloodearnest: jdstrand: https://github.com/anonymouse64/postgres-snap
[21:50] <bloodearnest>  jdstrand: re environment in snapcraft.yaml, can they now expand $SNAP{_DATA,_COMMON} and such in their value?
[21:50] <ijohnson> I used https://github.com/tianon/gosu.git to drop privileges
[21:50] <ijohnson> jdstrand: ^
[21:51] <bloodearnest> ijohnson: oh, nice, will take a look
[21:51] <ijohnson> jdstrand: although I don't remember I put it in the store or not, I didn't want to mess with the pre-existing postgres snaps and didn't have the time to engage with upstream
[21:52] <ijohnson> bloodearnest: the other tricky thing I ran into is auto-setting up a db that the other service used, cause you need to run various commands on install, but you want them to be run as snap_damon user
[21:52] <jdstrand> oh, setpriv
[21:52]  * jdstrand looks at that
[21:53] <ijohnson> a full example of using postgres as a service with something else that actually uses postgres is my kong snap: https://github.com/anonymouse64/kong-snap
[21:54] <bloodearnest> ijohnson: this is all useful info, looks like you've solved some tough problems there, which we can reuse - thanks!
[21:54] <ijohnson> bloodearnest: happy to see my work used :-)
[21:55] <bloodearnest> ijohnson:  what are your thoughts around SNAP_DATA vs SNAP_COMMON for the db files?  Having it in SNAP_DATA makes refresh a) slow and b) potentially irreversable w/o dataloss (if data was written to the new revisions $SNAP_DATA)
[21:58] <ijohnson> bloodearnest: hmm I guess I typically like to keep data in $SNAP_DATA so you can revert safely, I guess I'm not usually concerned with losing data on a revert, since almost all the times I've seen reverts is when something fails right after upgrading and so there's either no data or almost no data
[21:59] <ijohnson> if keeping all the data all the time is important then you probably need to use $SNAP_COMMON, and make sure you use epochs carefully to ensure that if the version of postgres changes or otherwise your db is incompatible with a future revision that you will step through snap revisions that can migrate back and forth safely
[21:59]  * ijohnson steps out for a minute
[22:01] <jdstrand> bloodearnest: ok, setpriv from util-linux works almost perfectly for this: LD_PRELOAD=$SNAP_COMMON/wraplib.so ./setpriv --clear-groups --reuid snap_daemon --regid snap_daemon -- sleep 300
[22:01] <bloodearnest> ijohnson: yep, it's tricky. I'd probably lean towards using tracks and an explicit copy/migrate step, rather than epochs. Firstly, because that's closer to typical production DB upgrades, and b) epochs are really quite hard to reason about.
[22:01] <bloodearnest> jdstrand: oh, that's much nicer
[22:02] <jdstrand> bloodearnest: --clear-groups uses setgroups in the portable manner, not the snapd required manner, hence the preload
[22:02] <jdstrand> bloodearnest: you can use --keep-groups and forego the preload, but, well, you have 0 in your list
[22:03]  * jdstrand documents setpriv in the forum
[22:05] <jdstrand> bloodearnest: ok, maybe between snap_daemon I did last cycle and the exploration, that is enough to consider the armhf build ;)
[22:05] <jdstrand> bloodearnest: seriously though, lemme know if you have issues with snap_daemon. I'd really like to add User=/Group= this cycle, but it won't be til late in the cycle
[22:07] <ijohnson> jdstrand: any thoughts on putting that wraplib.so inside snapcraft-preload?
[22:07] <bloodearnest> sjdstrand: right. FTR, the reason we still need LD_PRELOAD, AIUI, is that glib's initgroups (which is called by nginx) will *always* call setgroups with n>0 and a non-NULL pointer, and thus trip SECOMP up.
[22:07] <bloodearnest> jdstrand: I'll try see if we can schedule this,  but snap-proxy work is fairly low in the the list for next cycle
[22:08] <jdstrand> bloodearnest: sure, I understand
[22:08] <jdstrand> ijohnson: have had thoughts on that
[22:08] <jdstrand> :)
[22:09] <jdstrand> ijohnson: https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/snapcraft.yaml does show how to do this rather easily as well
[22:11] <jdstrand> (which is documented in https://forum.snapcraft.io/t/system-usernames/13386, but not a reason for it not to be in snapcraft-preload)
[22:19] <bloodearnest> jdstrand: FYI https://bugs.launchpad.net/snapstore-snap/+bug/1855005, https://bugs.launchpad.net/snapstore-snap/+bug/1855007, https://bugs.launchpad.net/snapstore-snap/+bug/1855008
[22:37] <ijohnson> jdstrand: yes that's simple enough, but we already end up needing to use snapcraft-preload for postgres anyways so having this in snapcraft-preload is one less thing to track and build
[22:40] <jdstrand> bloodearnest: thanks!
[22:41] <jdstrand> ijohnson: yeah. I think serguisens mentioned he was going to make it easier to contribute to
[22:41] <jdstrand> (snapcraft-preload)
[22:53] <ijohnson> great, that would be cool :-)
[23:13] <jdstrand> ijohnson: oh, I meant to say, really nice caching forum topic