[04:53] morning [07:05] morning [07:07] pstolowski: hey [07:19] mborzecki: need any other reviews? [07:20] pstolowski: i think i'm good right now [07:21] pstolowski: anything in your validation sets branches that needs looking at? [07:22] mborzecki: no, i'm good for now as well, thanks [07:22] PR snapd#10982 opened: i/b/common_test: refactor AppArmor features test [07:26] mardy: hi, i've commented in https://github.com/snapcore/snapd/pull/10918#pullrequestreview-790768022 does this answer the questions you had? [07:26] PR #10918: osutil/disks: add methods to replace gadget/ondisk functions [08:12] mardy: need reviews in any particular order? [08:23] pstolowski: this one would help, because then I rebase the sysmodule capability on top of it: https://github.com/snapcore/snapd/pull/10918 [08:23] PR #10918: osutil/disks: add methods to replace gadget/ondisk functions [08:24] mardy: i approved it yesterday already [08:27] pstolowski: sorry, wrong link :-) https://github.com/snapcore/snapd/pull/10982 [08:27] PR #10982: i/b/common_test: refactor AppArmor features test [08:28] ok [08:33] hey, I'm a bit out-of-touch right now but I do see some 18.04 related lxd failures in some of the recent spread runs, does anyone know more what's up here? is someone looking :) ? [08:33] (also 20.04 it seems?) [08:34] * mvo has some vague memory this was talked about but can't remember [08:36] mvo: afair mborzecki said that lxd from candidate (that we reported a bug for) was promoted to stable regardless [08:36] but maybe it's something else now? [08:36] pstolowski: ok, I will see if I can find osmething out from the lxd ppl [08:36] mborzecki: 10980 looks like it's good to go? [08:37] mvo: yes, if there are no futher comments then we should land it and the kylen try it [08:38] mvo: also, https://github.com/snapcore/snapd/pull/10947 can land too [08:38] PR #10947: tests: run spread tests on debian 11 [08:40] mborzecki: do you know about that lxd issue ^? is this the same you looked at earlier this week [08:41] pstolowski: the nested one failing? yeah, according to guys in mm it shoudl be fixed in edge now [08:42] PR snapd#10947 closed: tests: run spread tests on debian 11 [08:42] PR snapd#10980 closed: o/devicestate: copy timesyncd clock timestamp during install [08:47] PR snapd#10983 opened: spread: run lxd tests with version from latest/edge [09:27] PR snapd#10982 closed: i/b/common_test: refactor AppArmor features test [09:29] mborzecki: I just added a comment to the same PR, I think that the +1 is correct but I still don't get why we don't subtract StartLBA [09:34] mardy: yeah, i think there's some confusion about the purpose or the kind of the size information returned there [09:35] in certain scenarios (eg. layout) we need to know the actual block device size [09:35] while in other cases we only need to know the usable size (eg. expanding ubuntu-data) [09:36] mardy: sorry, i was going to review 10982 but was in a meeting, and now it landed (with 1 review?) [09:42] pstolowski: np, I was was a bit surprised that the button was green, but since it affects the tests only I thought it was safe to merge. But of course you can comment if you see something wrong, I will address them in a follow up [09:43] pstolowski: that at least unblocked me to update https://github.com/snapcore/snapd/pull/10933 (which also needs a re-review, BTW :-) ) [09:43] PR #10933: interfaces: suppress denial of sys_module capability [09:43] mardy: no worries, i'm a bit surprised you could land it yourself, i didn't know it would work with 1 review [10:07] pstolowski: simple selinux policy fix https://github.com/snapcore/snapd/pull/10984 [10:07] PR #10984: data/selinux: allow snap-confine to read udev's database [10:08] PR snapd#10984 opened: data/selinux: allow snap-confine to read udev's database [15:19] PR snapd#10985 opened: o/hookstate: print cohort with snapctl refresh --pending [16:22] PR pc-amd64-gadget#54 closed: Classic experiments