[06:00] PR snapd#9601 closed: tests: using systemd-run instead of manually create a systemd unit - part 1 [06:53] mvo, good morning [06:55] good morning zyga [07:21] morning [07:21] good morning mborzecki [07:22] mborzecki: how are you? [07:24] mvo: hey [07:30] mvo: are you working ona fix for in 9603? [07:33] mvo: cherry picked your patch from 9600 to 9603 [07:37] mborzecki: sure, I did not even see that this is failing yet [07:38] mborzecki: thanks for pushing it! [07:49] zyga: I've pushed a few changes to #9530, adding a spread test. That showed up a few small problems that I've fixed, so I'm just waiting for another round of CI to make sure it's all good [07:49] PR #9530: interfaces: share /tmp/.X11-unix/ from host or provider

<⚠ Critical> <⛔ Blocked> [07:49] jamesh, thank you [07:50] zyga: snap-update-ns didn't like the trailing slashes on the mount entries, since they aren't considered clean paths [07:50] oh, good catch, yeah the spread test was badly needed here [07:51] The test is written with a few snaps running netcat, so it is testing real socket communication (although not real X servers or clients) [07:51] that's fine [07:51] did you see any issues with non-abstract unix socket permission? [07:51] IIRC the X abstraction was not granting rights for non-abstract sockets [07:52] or perhaps I've missed that, I only saw permission with @ names [07:52] The abstraction has "/tmp/.X11-unix/* rw,", which seems to be enough [07:52] the "w" is apparently needed to connect to sockets [07:52] ahh, I see [07:53] that's good then [07:53] so the test also exercises all of the confinement [07:53] what do you think about an option to opt-out of this for the cases that Alan mentioned? [07:53] I think it is a good idea. I don't know whether we want to mix it into the existing PR [07:53] we're going to break his snaps anyway [07:54] no, I think it should be separate [07:54] I wonder what's the indented behavior though, [07:54] yeah. That's one reason I'd like to treat it as its own problem [07:55] I think this should be merged [07:55] just get the reviews it needs [08:03] zyga: well, I've given my +1. The spread test was the main thing I was waiting for, and it's now in there. [08:03] morning [08:29] good morning pstolowski [08:35] o/ [08:56] PR snapd#9603 closed: many: mv keys to ubuntu-boot, move model file, rename keyring prefix for secboot [09:05] alan_g: are you happy if we address the x11 plug attribute idea discussed in https://github.com/snapcore/snapd/pull/9530 as a second PR? [09:05] PR #9530: interfaces: share /tmp/.X11-unix/ from host or provider

<⚠ Critical> <⛔ Blocked> [09:09] @jamesh, of course. As I've said a couple of times: snaps that run Xwayland and also connect to X11 are probably not needed by any important usecases. [09:19] alan_g: great. I've updated the PR to add some spread tests, which seem to be passing now. Assuming security is happy, hopefully we can get it merged soon [09:21] pedronis: hm do you mean we should explicitly set the method to NotUnlocked here? https://github.com/snapcore/snapd/pull/9604/files/ba66a2342a1b3237c713044397f149f2b40d7912#r518609368 [09:21] PR #9604: secboot, many: return UnlockMethod from Unlock* methods for future usage [09:25] mborzecki: no, because activated is true [09:26] mborzecki: we need to understand a bit better the secboot function error behavior, I don't remember the details [09:27] hmm heh, it does look confusing [09:29] pedronis: so for activated == true && err != nil, the only would be that it was activated with recovery key, meaning the later check would be unnecessary? [09:30] mborzecki: I think so, looking at secboot [09:38] pedronis: ok, refactored that code a little bit and will push an update [09:38] thx [10:01] mvo: do you think we could trim the standup doc? it makes my firefox very unhappy [10:02] mborzecki: +1 [10:02] thanks! [10:05] pedronis: I think https://github.com/snapcore/snapd/pull/9530 is in good shape now: the spread test showed a few problems that have now been resolved [10:05] PR #9530: interfaces: share /tmp/.X11-unix/ from host or provider

<⚠ Critical> <⛔ Blocked> [10:11] jamesh: thanks [10:12] pedronis: i've updated #9604 [10:12] PR #9604: secboot, many: return UnlockMethod from Unlock* methods for future usage [10:35] mborzecki: reviewed [10:37] pedronis: thanks! [11:29] looks like 9604 can be merged? [11:43] mvo: does it show up correctly for you? [11:44] mvo: it's showing all spread jobs of the last run as failed (even though i canceled the run from the previous commit) [11:52] re [12:00] mborzecki: sorry, was in a meeting [12:01] mborzecki: maybe something stale, I just reloaded the page and now it's running [12:01] mvo: yes, i pushed a tweak that pedronis suggested [12:06] mvo: yes, i pushed a tweak that pedronis suggested [12:06] duh, wrong window :P [12:09] ta [12:22] PR snapd#9605 opened: gadget, overlord/devicestate: validate that system supports encrypted data before install [12:37] PR snapd#9606 opened: tests: Use systemd-run on tests part2 [12:52] mborzecki: mvo: I made a comment there now, can be a follow up [12:59] hey folks [12:59] how are we doing this morning [13:04] pedronis: thanks [13:04] ijohnson: not great not terrible i guess, one PR has landed, another one is waiting for spread to finish [13:05] correction, 2 have landed now [13:05] As meatloaf would say, 2/3 ain't bad :-) [13:06] No points in guessing which one hasn't landed yet though I suppose [13:06] i'll update 9600 in a bit [13:07] PR snapd#9604 closed: secboot, many: return UnlockMethod from Unlock* methods for future usage [13:08] thanks mborzecki [13:11] * tobias_ waves [13:25] mborzecki: ijohnson: hi, is 9600 ready for re-reviews or there is more to do there? [13:27] pedronis:i think it's ready [13:27] ok [13:28] Yes it should be ready [14:32] mborzecki: mvo: ijohnson: this is the f32 forum post: https://forum.snapcraft.io/t/some-snaps-wont-run-anymore-due-to-permission-denied/20833 [14:33] pedronis: same dconf log appears apparently on manjaro: https://forum.snapcraft.io/t/completely-broken-snapd-environment-in-manjaro-20-1-2/20900/19 [14:45] mvo: pedronis: pushed tweaks to #9539 [14:45] PR #9539: many: add /v2/system-recovery-keys API and client [14:48] arggh, note to self, tasks need to be added to the change, otherwise TaskSnapSetup checks around them are not going to work (tests only problem) [14:50] mborzecki: \o/ [14:51] mborzecki: needs a second +1 from pedronis and then this one can go in and I can update the client [15:48] PR snapd#9607 opened: o/devistate: fix chaining of tasks related to regular snaps when preseeding [15:51] pedronis, hey, do you think next week you will have some time to look at the remaining export manager patches? [15:51] zyga: hopefully yes [15:52] pedronis: so regarding your comment on 9600 re the copyUbuntuDataAuth and friends, what did you mean by that? [15:53] pedronis: did you mean we should try to copy files even if we know we haven't mounted ubuntu-data at host ? [15:53] ijohnson: no, my question is what to do with the errors of the various copy errors if we have mounted it [15:54] s/copy errors/copy methods/ [15:54] pedronis, great, I'm looking forward to that [15:54] pedronis: ah I see what you mean, ok, so if we try to copy the files and if we fail, should we still fallback to copying the console-conf complete file and then mark something in degraded.json ? [15:55] ijohnson: yes, that's my question basically [15:55] ijohnson: it can be a follow up though I suppose [15:55] yes I think that's a reasonable thing to do [15:55] given that the PR is already big [15:55] but yes the PR is big so we could do that as a followup [15:55] I'll do it as a follow-up [15:57] ijohnson: also since the standup I have been thinking, should we organize degraded.json as {"disk-name": state-dict, ..., "error-log": ...} perhaps ? [15:59] * cachio lunch [16:04] pedronis: hmm I suppose we could do something like that [16:04] pedronis: I guess I haven't thought deeply about the format we should be using because we haven't really thought about or discussed what will actually consume this eventually [16:12] ijohnson: it feels a bit more future-proof to me (and also slightly nicer) [16:12] pedronis: let's do it [16:13] Curious.. why was the tomb.Wait removed at the end of daemon.Stop? [16:14] niemeyer: I need to dig, don't remember (also in a meeting atm) [16:15] pedronis: Cool, no rush.. just curious as it might imply the Loop goroutine can stay alive [16:23] pedronis: Nevermind, it wasn't removed.. it was moved [16:27] niemeyer: ah, thanks for double-checking [16:27] np, sorry for the false alarm [17:24] ijohnson: I can try to have another look in my evening (in 2-3h) if it's ready for it otherwise Monday morning [17:24] pedronis: ok, I'm hoping to wrap this up in the next hour or so, but it's a bit difficult to wrap my head around all the different states we are saving to the degraded.json [17:25] * ijohnson was also hoping to EOD soon too [18:18] ok I got it in good shape I think now [18:19] just need to have lunch and update 7 unit tests [18:44] mvo: some store hiccups in https://github.com/snapcore/snapd/pull/9539 [18:44] PR #9539: many: add /v2/system-recovery-keys API and client [18:45] * cachio afk [19:09] mvo: pedronis: mborzecki: I'm going to EOD now, but I will be back monday morning, I resolved almost all of pedronis' comments on the PR about checking unlocked vs cannot-find, I didn't get to add the additional unit tests around the unencrypted cases that pedronis mentioned, perhaps someone can work on adding those on Monday [19:09] if there are comments I might check back in late my PM or over the weekend, [19:10] we might have slight disagreements over the level of detail I am now putting into degraded.json [19:10] I think it's nice because it's rich and we can just ignore stuff we don't care about or use [19:10] anyways, have a nice weekend folks [19:42] ijohnson ping re: https://forum.snapcraft.io/t/download-snap-and-assert-without-snap-download-command/20869/9 [19:42] can you help with that ? [19:57] PR snapcraft#3358 opened: Fix colcon v1 workspace sourcing [22:02] ijohnson hey [22:03] ijohnson did you EOD today or are you still working? I'd like to reboot spread worker host for kernel upgrade [22:05] zyga: hey I'm EOD so go for it [22:05] great, thanks [22:06] I noticed that there were no jobs running or queued so I thought it's safe but wanted to ask first [22:06] btw, was the release successful? [22:25] zyga unfortunately not, will have to wait til Monday now [22:25] I'm sorry to hear that, I hope it's nothing serous and just stuff dragging into the weekend [22:29] kernel upgrade completed, workers are starting asynchronously now