[01:18] PR snapcraft#2828 opened: Appstream [01:42] PR snapd#7827 closed: tests: apply change on permissions to serial port on hotplug test === arnatious_ is now known as arnatious [06:30] morning [07:14] good morning [08:04] morning [08:14] pstolowski: mvo: morning guys [08:15] hey mborzecki and pstolowski ! good morning [08:16] mborzecki: how are you? and what did I miss :) ? [08:17] mvo: nothing special, fri/mon were rather slow [08:17] mborzecki: *nod* are tests ok ? or do they need investigation? [08:18] mvo: got 2 prs green this morning, so things seem ok [08:19] mborzecki: \o/ [08:20] mborzecki: great! anything I can help with right away? otherwise I will just do the usual mail+check prs [08:20] 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] PR #7743: snap-bootstrap: force partition table operations [08:21] * mvo looks [08:22] mborzecki: woah, nice find in 7824 [08:23] 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] good morning [08:23] mborzecki: anyway not super important, just an idle thought [08:23] zyga: good morning! [08:24] :) [08:24] mvo: yeah, thinks seem calm, just reviews and iteration [08:24] zyga: hey [08:24] zyga: how are you? jetlag better? [08:24] mvo: didn't check [08:25] * mvo was super tired this morning but otherwise feeling good [08:25] mvo: yeah :-) It's all over finally :) [08:25] * mvo just gets more tea and everything will be back to normal :) [08:25] zyga: yay! [08:25] mvo: I tried to record my first ubuntu core video [08:25] zyga: I read somewhere it take ~1day per hour timezone difference [08:25] mvo: more attempts today, it's a lot of work :D [08:25] zyga: that's so cool! [08:29] mborzecki: also - holly cow - 7821! [08:29] mborzecki: pretty impressive numbers [08:29] PR snapd#7822 closed: devicestate: ensure system installation [08:29] * mvo hugs mborzecki [08:30] PR snapd#7820 closed: boot: add boot.Modeenv.Kernel support [08:40] mvo: hi, a post-merge remark on #7820 [08:40] PR #7820: boot: add boot.Modeenv.Kernel support [08:45] pedronis: thank you, on it [08:45] pedronis: uh, sorry, indeed, will fix right away [08:56] pedronis: I added a comment to 7823 (which is also shorter now that bits from master are merged) [09:01] mvo: ok, what should I review next? [09:01] I mean for UC20 [09:02] 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] pedronis: and then I want to update 7817 based on your feedback [09:02] pedronis: I hope this sounds sensible === Girtablulu_ is now known as Girtablulu [09:12] mvo: fwiw I had the same wondering at some point, about the partition finding [09:20] pedronis: in 7762 ? [09:21] yes [09:26] * mvo nods and will have a look [09:33] hm master unit tests broken? [09:35] mborzecki: oh? [09:35] must be the devicemgr PR that landed [09:35] https://paste.ubuntu.com/p/sdjF7VJbfC/ [09:35] indeed [09:36] mborzecki: are you pushing or shall I? [09:36] or better yet [09:36] mvo: can you push a trivial directly to master/ [09:36] https://www.irccloud.com/pastebin/PZj3DJ9C/ [09:37] mvo: will save us an hour [09:37] hahah [09:39] I'll open a PR just in case [09:40] all this CI [09:40] ... [09:40] zyga: can do [09:40] mvo: thanks [09:43] zyga: should be fine now [09:44] * zyga thanks :) [09:49] pedronis: hi, i've updated #7821 [09:50] PR #7821: [RFC] interfaces/seccomp: parallelize seccomp backend setup <⛔ Blocked> [09:53] mborzecki: thanks, queued [09:57] * zyga has some food poisoning this morning [09:57] pedronis: cool, thanks [09:57] if I'm not responsive, that's why :/ [10:06] PR snapd#7824 closed: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap [10:06] PR snapd#7830 opened: Include hooks in plug/slot apparmor label [10:57] Hellos [10:57] mvo: ping [11:06] hey niemeyer [11:06] mvo: Heya [11:06] mvo: Do you have a moment for a call? [11:07] 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] niemeyer: yes, sure! [11:07] mvo: Nice, let me grab a cup of coffee quickly and will drop you a link [11:08] mborzecki: i think Sergio addressed your comments to https://github.com/snapcore/snapd/pull/7815 ; can we land it? [11:08] PR #7815: tests: reduce the complexity of the test-snapd-sh snap [11:10] PR snapd#7815 closed: tests: reduce the complexity of the test-snapd-sh snap [11:10] ty! [11:11] mborzecki: hey [11:11] mborzecki: I moved the code we talked about to sandbox/cgroup [11:11] mborzecki: shall I push that to https://github.com/snapcore/snapd/pull/7825 ? [11:11] PR #7825: many: use transient scope for tracking apps and hooks [11:17] Chipaca: hey, question to you on https://bugs.launchpad.net/snapd/+bug/1838786 [11:18] Bug #1838786: Categories not returned in /v2/find results [11:18] pstolowski: yep, tks [11:18] Chipaca: i might have asked about it during my last triage duty ;) [11:19] if you update it, i'll stop asking ;) [11:19] pstolowski: i mean, there isn't a status for "started, will be completed, but not being worked on right now" [11:19] true, np, just comment on it [11:22] mborzecki: updated [11:23] * zyga returns to garden next branch in a moment [11:30] re [11:31] 15C in the office [11:31] no wonder I have a cold [11:33] zyga: you should really get a heater or sth [11:33] quick errand, back in 20 [11:33] 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] xnox: aha [11:41] xnox: do you know what's the relationship between devtmpfs and in-kerenl kobj events [11:42] xnox: I can point you to specific lines in the kerenl [11:42] xnox: for instance when the block device layer drops and re-creates partitions [11:42] xnox: is that automatically reflected in devtmpfs? [11:42] mborzecki: the heater is on now [11:44] zyga: no, and why should it be? [11:44] pstolowski: small suggestion for the label expr branch [11:45] xnox: I'm not yet sure about "should" vs "not should" - just trying to piece together my undersstanding [11:45] xnox: when the ioctl to rescan partition table is issued [11:45] kernel needs to be told to reload the partitions...... i.e. using kpartx, blockdev, etc. [11:45] xnox: the kernel removes and re-creates partition nodes [11:45] xnox: when this happens the kernel side is updated [11:45] xnox: but what about the filesystem? [11:45] xnox: I'm trying to understand what updates /dev/ itself [11:46] xnox: is that some minimal udev running in initrd or is that directly done by the kernel [11:46] kernel udev events are emitted, which udev processes, and does changes to. [11:46] not minimal, but full-fat udevd. [11:46] ah, so there is real udev there? [11:46] ah [11:46] in all of our initrds..... [11:46] ok, that explains everything I was wondering about [11:46] cool, thank you [11:46] but it may have different set of udev rules & helpers (i.e. raid/lvm/cryptsetup/dm-setup might be missing) [11:46] xnox: if you are interested in the backstory [11:46] or even versions [11:46] xnox: there was some discussion about this specific part: [11:47] for example, old initrd may have older systemd, and thus initrd symlinks/names might be different to the "booted" system. [11:47] https://github.com/snapcore/snapd/pull/7743 [11:47] PR #7743: snap-bootstrap: force partition table operations [11:47] xnox: that's interesting [11:47] xnox: (when I say interesting, I mean, how are we going to handle that) [11:52] pstolowski: your patch looks good, I suspect the failure shows something that is broken but was dormant before [11:53] 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] pstolowski: can you paste the line please [11:56] re [11:56] mborzecki: 18C now [11:56] mborzecki: +4 outside [12:00] zyga: showing 2C outside here, though it's sunny yay [12:01] 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] zyga: peer=(label="snap.core.}"), [12:05] ha [12:05] I ... know [12:05] pstolowski: do you see it? [12:05] https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR66 [12:06] PR #7830: interfaces: include hooks in plug/slot apparmor label [12:06] it must only truncate if len(names) > 0 [12:06] pstolowski: add a test for that please [12:07] pstolowski: in addition https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR45 may need to be dropped [12:07] and instead the name collection may have to move earlier [12:07] PR #7830: interfaces: include hooks in plug/slot apparmor label [12:07] pstolowski: so that the same if one { } else if zero else { } flow can remain [12:09] zyga: ha, thanks for spotting [12:17] ok, i think i got it simplified, running the tests.. short break, going to collect my usb hub from post office [12:17] pstolowski: cool, good luck! [12:22] mborzecki: can you look at https://github.com/snapcore/snapd/pull/7825 again [12:22] PR #7825: many: use transient scope for tracking apps and hooks [12:22] mborzecki: I'll find those tests I wrote for some of the TODOs there [12:22] ok [12:22] mborzecki: but I did some structural changes you asked for === pedronis_ is now known as pedronis [12:58] mvo: #7823 looks fine afaict [12:58] PR #7823: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts [13:38] zyga: is label="snap.core." same as label="snap.core.*" ? [13:38] pstolowski: no, it is not [13:40] zyga: is "snap.core." matching anything? [13:41] only the label "snap.core." [13:41] which nothing in our system will have [13:43] zyga: good [13:43] zyga: one more twist in that PR [13:43] (not pushed yet) [14:04] PR snapd#7829 closed: tests: fix the channels checks done on nested tests === tinwood_ is now known as tinwood === ricab is now known as ricab|lunch [14:20] pedronis: hey, amurray asked you to respond to https://forum.snapcraft.io/t/system-files-under-mozilla-native-messaging-hosts [14:21] pedronis: but per our conversation in Vancouver, I will [14:22] jdstrand: thx [14:23] jdstrand: #7768 needs a unit test fix [14:23] PR #7768: interfaces: add raw-volume interface for access to partitions [14:24] pedronis: yep, hoping to get to that today. thanks [14:24] zyga: jdstrand asked you to (re)review #7228 [14:24] ack, will do [14:24] PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests [14:29] cmatsuoka: you broke github ;) just got an email with '@cmatsuoka pushed 0 commits.' [14:31] hmm... push --overwrite with an unchanged branch? [14:31] er --force (sorry, too much bzr) [14:31] pstolowski: let me know if we should have a chat about services tomorrow or later in the week [14:31] I'm pushing 0 commits all the time [14:31] brb, lunch [14:32] But yeah, I don't know what happened there, I'll check [14:32] PR snapd#7831 opened: [RFC] gadget: extract and export new DiskFromPartition() helper [14:33] pedronis: ok, thanks, will think a bit more and maybe tomorrow [14:48] PR snapd#7832 opened: [RFC] snap-bootstrap: support auto-detect device in create-partitions [14:53] mvo: what's the relation of 7831 and 7832, does one need the other or are they exclusive? [14:54] 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] ok [14:55] 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] 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] cmatsuoka: mvo: for uc20, is the ubuntu-seed partition encrypted? [15:03] mborzecki: no [15:04] only -data and -save will be [15:06] pedronis: thx [15:07] PR snapcraft#2817 closed: snapcraft/plugins: Add gomod plugin [15:18] PR snapd#7833 opened: HACKING.md: add nvidia options to configure example [15:18] degville: when you get a chance could you quick take a look at ^ [15:19] 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] ijohnson: will do - thank you! [15:24] mborzecki, hey, when you have few minutes could you please give a second round to #7826 [15:24] PR #7826: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 1 === ricab|lunch is now known as ricab [15:25] * cachio lunch [15:34] mvo: the approach in #7832 looks reasonable [15:34] PR #7832: [RFC] snap-bootstrap: support auto-detect device in create-partitions [15:34] pedronis: \o/ [15:34] pedronis: thanks for the feedback [15:35] Chipaca: #7771 will need a re-review [15:35] PR #7771: o/hookstate/ctlcmd: snapctl is-connected command [15:35] but I asked for some changes [15:35] yep yep [15:35] still [15:35] 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 === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [16:07] back from lunch [16:07] but need to take a break now [16:07] back in 2 hours to wrap up the day [16:07] Chipaca: I looked at that [16:07] Chipaca: it's really true in many ways [16:08] changes what needs to be done as a kernel patch [16:54] * Chipaca afk [17:45] PR snapd#7834 opened: tests: move the watchdog timeout to 2s to make the tests work in rpi [17:49] re [17:49] * zyga was sleeping [17:49] back to work [17:49] with some tea to help === heather is now known as hellsworth [17:54] * Chipaca soft-EODs [17:55] signal(SIGEOD, SIG_IGN) === ijohnson is now known as ijohnson|lunch [18:26] * Chipaca feels ignored, now [18:27] * Chipaca might get used to this === ijohnson|lunch is now known as ijohnson [19:10] * zyga hugs Chipaca [19:10] I just discovered mold behind a whiteboard [19:11] "yay" [19:14] PR snapcraft#2829 opened: store cli: push title and license on push-metadata [20:02] noise][: hey, who would I talk to these days about the snap-store-proxy? [20:04] noise][: I see bloodearnest uploaded it last [20:05] 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] jdstrand: we just haven't built for other arches because who would want to host a store-proxy on a raspberry pi :) [20:12] 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] 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] 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] jdstrand: well it does need a postgres database [20:16] 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] roadmr: it is already installed :) [20:16] 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] roadmr: snap install postgresql10 [20:17] \o/ [20:17] roadmr: it is literally begging to be used right now :) [20:17] hehe [20:17] * cachio afk [20:17] I guess I am begging for it to be used too... [20:17] :) [20:21] 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] anyhoo, curious on the outcome of that [20:22] jdstrand: I'll check with twom and bloodearnest tomorrow to see what the reason was [20:23] roadmr: thanks! [20:27] PR snapd#7828 closed: tests: demand silence from check_journalctl_log [20:27] 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] everything else is python and archive packages [21:00] 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] bloodearnest: as documented in https://forum.snapcraft.io/t/system-usernames/13386 [21:01] bloodearnest: so, if this is something that you're interested in, you have a tester and a user :) [21:02] jdstrand: thanks. I don't have an armhf device handy, but I'll add a trello card for it [21:03] 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] bloodearnest: I think that is what the maas snap is doing (though I'm not sure) [21:03] bloodearnest: anyhoo, thanks! [21:04] 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] Unless running as non-uid-zero users in a service are now a thing, and I missed that? [21:05] bloodearnest: it is now a thing: https://forum.snapcraft.io/t/system-usernames/13386 [21:06] jdstrand: well, hello there, that is nice. Ok, we might add that now :) [21:06] 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] jdstrand: so the wrapper needs to su? [21:07] 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] 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] I'll add some bugs to track these I think. [21:10] bloodearnest: I was thinking a C wrapper. su is allowed in the policy currently. runuser might work. let me try real quick [21:11] we already wrap our servcies in a bash exec launcher, for various reasons, so su would be simpler [21:11] 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] err, su isn't* allowed in the policy currently. that won't work come to think of it cause of pam [21:12] ah, yeah [21:12] hmm [21:12] but let me try something with runuser [21:12] * jdstrand plays for a minute [21:43] 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] 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] jdstrand: thanks. That is more complex than I'd like - is User=/Group= support in systemd unit file on the roadmap? [21:45] 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] jdstrand: right, we're just using the LD_PRELOAD for nginx, we run about 6 python services and a golang one too. [21:47] 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] jdstrand: ack, thanks [21:48] bloodearnest: since you are doing it for nginx, you could set 'environment' in the snapcraft.yaml for anything that uses initgroups [21:49] I could write a 'runas' binary in that tree [21:49] bloodearnest, I made a postgres snap with snap_daemon [21:50] ijohnson: what did you do to drop? [21:50] ijohnson: and what is the name of that snap? I'd like to use yours instead of the one I have [21:50] :) [21:50] bloodearnest: jdstrand: https://github.com/anonymouse64/postgres-snap [21:50] jdstrand: re environment in snapcraft.yaml, can they now expand $SNAP{_DATA,_COMMON} and such in their value? [21:50] I used https://github.com/tianon/gosu.git to drop privileges [21:50] jdstrand: ^ [21:51] ijohnson: oh, nice, will take a look [21:51] 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] 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] oh, setpriv [21:52] * jdstrand looks at that [21:53] 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] ijohnson: this is all useful info, looks like you've solved some tough problems there, which we can reuse - thanks! [21:54] bloodearnest: happy to see my work used :-) [21:55] 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] 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] 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] 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] 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] jdstrand: oh, that's much nicer [22:02] bloodearnest: --clear-groups uses setgroups in the portable manner, not the snapd required manner, hence the preload [22:02] 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] bloodearnest: ok, maybe between snap_daemon I did last cycle and the exploration, that is enough to consider the armhf build ;) [22:05] 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] jdstrand: any thoughts on putting that wraplib.so inside snapcraft-preload? [22:07] 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]