[02:42] PR snapd#10879 opened: gadget/ondisk.go: add listBlockDevices() to get all block devices on a system [05:54] morning [05:57] hi mborzecki [05:59] mardy: hey, finally tracked down that problem with tests on LP, it's ofc a race/timing problem, but it's weird, we specifically forced a delay in the code, but regardless of that mksquashfs produced identical files when building the package, as if debhelper would inject something that forced a specific time? [05:59] idk, maybe it's related to reproducible builds or sth, but it failed like this on 14.04 too, which i think is from before the reproducible builds effort was a real thing [06:32] PR snapd#10880 opened: overlord: fix generated snap-revision assertions in remodel unit tests <⚠ Critical> [06:34] Issue core18#182 opened: Removal of expired Let's Encrypt certificate [06:37] mvo: I haven't been looking at the LP issue yet; I'm still fighting with the cgroup scope, now I merged your branch, and it seems to have made things worse: before only the command "tests.session -u test exec /snap/bin/test-snapd-policy-app-consumer.block-devices" was failing, whereas "/snap/bin/test-snapd-policy-app-consumer.block-devices" was working. Now both don't work [06:38] mborzecki: oops, that was for you ^ (good morning, mvo! :-) ) [06:42] hey mardy, good morning! [06:45] mvo: hey, please take a look at https://github.com/snapcore/snapd/pull/10880 [06:45] PR #10880: overlord: fix generated snap-revision assertions in remodel unit tests <⚠ Critical> [06:45] mborzecki: sure [06:46] mborzecki: oh, sweet, thanks for finding this! [07:05] morning [07:06] good morning pstolowski [07:09] pstolowski: hi! [07:14] o/ [07:55] pstolowski: hey [07:59] mborzecki: I added a comment on https://github.com/snapcore/snapd/pull/10847 - it's mostly unrelated to the PR itself, but I wanted to get your opinion on that [07:59] PR #10847: cmd/snap-confine: die when snap process is outside of snap specific cgroup [07:59] mardy: let me see [08:01] mardy: which distro is this? [08:03] PR snapd#10877 closed: many: support an API flag system-restart-immediate to make snap ops proceed immediately with system restarts (2.52) [08:04] mborzecki: ubuntu 18.04 on spread [08:06] mardy: hm i'm missing something, have you added devices allowed by any chance? I don't see how systemd would not be able to add pids to a group it created, moreso how chmoding directories under /sys/fs/cgroup would fix that [08:07] unless systemd in 18.04 is truly broken 😕 [08:08] oh fun, we don't run this test on 20.04+ ? [08:18] mborzecki: no, I didn't touch anything on that machine. I think that the error message might be a bit misleading, maybe the error is not on adding the pids, but on creating the cgroup itself [08:18] mardy: i'm running the test now [08:34] mardy: ok, so what's the concern in 10877 then? [08:43] PR snapd#10881 opened: tests: merge coverage results [08:46] mborzecki: assuming you meant 10847, I don't have a concern with the PR itself, it LGTM. It was just a request for info :-) [08:48] PR snapd#10882 opened: tests/main/interfaces-many: run both variants on all possible Ubuntu systems [08:49] mardy: right, so we need it for cgroup v2 😉 but your observation is supported by evidence from spread runs in https://github.com/snapcore/snapd/pull/10860 [08:49] PR #10860: sandbox/cgroup: wait for start transient unit job to finish [08:49] tbh, that may be a bug in 18.04 systemd [08:53] mvo: shall we land https://github.com/snapcore/snapd/pull/10880 or we need another review? [08:54] PR #10880: overlord: fix generated snap-revision assertions in remodel unit tests <⚠ Critical> [09:40] mardy: ok, so fun stuff, running anything as a scope in user session fails on 18.04 [09:56] mardy: and focal cloud image fails this way too [10:03] PR snapd#10861 closed: snap-bootstrap: wait in `mountNonDataPartitionMatchingKernelDisk` [10:22] mborzecki: the error is "permission denied"? [10:26] mardy: yeah, strace shows there's EACCESS when wriiting the pid to cgroup.procs under /sys/fs/cgroup/unified and also mkdir in the pids hierarchy fails [10:29] mardy: fwiw it fails in ssh session, with the cloud image and desktop livecd image https://paste.ubuntu.com/p/nqSjZbPPqy/ [10:30] mardy: and more fun, it succeeds when i run it from a gnome terminal in a desktop session: https://paste.ubuntu.com/p/XjJ8mfxSXn/ [10:49] mborzecki: I guess the directory permissions are different? [10:50] mborzecki: ah, wait, I remember I saw a bug related to this in the systemd tracker, and IIRC it was fixed in 2018. Let me dig it out... [10:51] mborzecki: https://github.com/systemd/systemd/issues/3388 [10:54] mardy: thanks, i'll add a note under https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1946086 [10:54] Bug #1946086: systemd user daemon fails with Permission denied when creating transient scope [10:56] pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/10882 ? [10:56] PR #10882: tests/main/interfaces-many: run both variants on all possible Ubuntu systems [10:56] mborzecki: sure [11:07] pstolowski: thanks [11:07] mvo: can you land https://github.com/snapcore/snapd/pull/10882 ? [11:07] PR #10882: tests/main/interfaces-many: run both variants on all possible Ubuntu systems [11:13] PR snapd#10883 opened: o/snapstate, hookstate: print remaining hold time on snapctl --hold [11:23] PR snapd#10884 opened: tests/main: disable cgroup-devices-v1 and freezer tests on 21.10 [11:34] PR snapd#10885 opened: release: 2.52.1 [12:29] PR snapd#10886 opened: o/snapstate: test prereq update if started by old version [12:49] PR snapd#10885 closed: release: 2.52.1 [13:39] PR snapd#10887 opened: release: merge 2.52.1 changelog into master [14:00] if someone could review 10887 - that would be lovely [14:04] pstolowski: hey did we implement support for gate-auto-refresh hook being called for kernel/base refreshes too? or was that not done for the initial version ? [14:04] mvo: done [14:04] ijohnson[m]: \o/ [14:17] ijohnson[m]: technically auto refresh gating doesn't care and will consider all snaps that have gate-auto-refresh hook [14:19] pstolowski: what I mean is that if an app snap has a gate-auto-refresh hook, will that hook be called when the kernel snap is refreshed? [14:19] since the app snap is "affected" by the kernel snap refresh as the kernel snap refresh will reboot the system [14:23] ijohnson[m]: yes, that app's hook will be called and can hold the refresh of kernel for up to 48h. we also do that with gadget [14:23] pstolowski: perfect thanks for clarifying that [14:28] PR snapcraft#3586 opened: Ported font rendering fix from the desktop helpers. [14:44] PR snapd#10887 closed: release: merge 2.52.1 changelog into master [14:52] * mvo needs to switch network [15:34] PR snapd#10888 opened: tests: support running all spread tests with experimental features [16:20] PR snapd#10889 opened: release: 2.53 [17:15] PR snapd#10890 opened: tests: using test-snapd-curl snap instead of http snap [18:00] PR snapd#10889 closed: release: 2.53 [18:18] PR snapcraft#3587 opened: lifecycle: init with core20 (CRAFT-517) [18:30] PR snapd#10880 closed: overlord: fix generated snap-revision assertions in remodel unit tests <⚠ Critical> [19:33] PR snapcraft#3587 closed: lifecycle: init with core20 (CRAFT-517) [21:16] PR snapd#10891 opened: gadget: add mapping heuristic types