[06:00] <mup> PR snapd#9601 closed: tests: using systemd-run instead of manually create a systemd unit - part 1 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9601>
[06:53] <zyga> mvo, good morning
[06:55] <mvo> good morning zyga
[07:21] <mborzecki> morning
[07:21] <mvo> good morning mborzecki
[07:22] <mvo> mborzecki: how are you?
[07:24] <mborzecki> mvo: hey
[07:30] <mborzecki> mvo: are you working ona fix for in 9603?
[07:33] <mborzecki> mvo: cherry picked your patch from 9600 to 9603
[07:37] <mvo> mborzecki: sure, I did not even see that this is failing yet
[07:38] <mvo> mborzecki: thanks for pushing it!
[07:49] <jamesh> 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] <mup> PR #9530: interfaces: share /tmp/.X11-unix/ from host or provider <Needs security review> <Squash-merge> <⚠ Critical> <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/9530>
[07:49] <zyga> jamesh, thank you
[07:50] <jamesh> zyga: snap-update-ns didn't like the trailing slashes on the mount entries, since they aren't considered clean paths
[07:50] <zyga> oh, good catch, yeah the spread test was badly needed here
[07:51] <jamesh> 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] <zyga> that's fine
[07:51] <zyga> did you see any issues with non-abstract unix socket permission?
[07:51] <zyga> IIRC the X abstraction was not granting rights for non-abstract sockets
[07:52] <zyga> or perhaps I've missed that, I only saw permission with @ names
[07:52] <jamesh> The abstraction has "/tmp/.X11-unix/* rw,", which seems to be enough
[07:52] <jamesh> the "w" is apparently needed to connect to sockets
[07:52] <zyga> ahh, I see
[07:53] <zyga> that's good then
[07:53] <zyga> so the test also exercises all of the confinement
[07:53] <zyga> what do you think about an option to opt-out of this for the cases that Alan mentioned?
[07:53] <jamesh> I think it is a good idea.  I don't know whether we want to mix it into the existing PR
[07:53] <jamesh> we're going to break his snaps anyway
[07:54] <zyga> no, I think it should be separate
[07:54] <zyga> I wonder what's the indented behavior though,
[07:54] <jamesh> yeah.  That's one reason I'd like to treat it as its own problem
[07:55] <zyga> I think this should be merged
[07:55] <zyga> just get the reviews it needs
[08:03] <jamesh> 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] <pstolowski> morning
[08:29] <mvo> good morning pstolowski
[08:35] <pstolowski> o/
[08:56] <mup> PR snapd#9603 closed: many: mv keys to ubuntu-boot, move model file, rename keyring prefix for secboot <Run nested> <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9603>
[09:05] <jamesh> 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] <mup> PR #9530: interfaces: share /tmp/.X11-unix/ from host or provider <Needs security review> <Squash-merge> <⚠ Critical> <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/9530>
[09:09] <alan_g> @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] <jamesh> 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] <mborzecki> 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] <mup> PR #9604: secboot, many: return UnlockMethod from Unlock* methods for future usage <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9604>
[09:25] <pedronis> mborzecki: no, because activated is true
[09:26] <pedronis> mborzecki: we need to understand a bit better the secboot function error behavior, I don't remember the details
[09:27] <mborzecki> hmm heh, it does look confusing
[09:29] <mborzecki> 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] <pedronis> mborzecki: I think so, looking at secboot
[09:38] <mborzecki> pedronis: ok, refactored that code a little bit and will push an update
[09:38] <pedronis> thx
[10:01] <mborzecki> mvo: do you think we could trim the standup doc? it makes my firefox very unhappy
[10:02] <mvo> mborzecki: +1
[10:02] <mborzecki> thanks!
[10:05] <jamesh> 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] <mup> PR #9530: interfaces: share /tmp/.X11-unix/ from host or provider <Needs security review> <Squash-merge> <⚠ Critical> <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/9530>
[10:11] <pedronis> jamesh: thanks
[10:12] <mborzecki> pedronis: i've updated #9604
[10:12] <mup> PR #9604: secboot, many: return UnlockMethod from Unlock* methods for future usage <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9604>
[10:35] <pedronis> mborzecki: reviewed
[10:37] <mborzecki> pedronis: thanks!
[11:29] <mvo> looks like 9604 can be merged?
[11:43] <mborzecki> mvo: does it show up correctly for you?
[11:44] <mborzecki> 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] <zyga> re
[12:00] <mvo> mborzecki: sorry, was in a meeting
[12:01] <mvo> mborzecki: maybe something stale, I just reloaded the page and now it's running
[12:01] <mborzecki> mvo: yes, i pushed a tweak that pedronis suggested
[12:06] <mborzecki> mvo: yes, i pushed a tweak that pedronis suggested
[12:06] <mborzecki> duh, wrong window :P
[12:09] <mvo> ta
[12:22] <mup> PR snapd#9605 opened: gadget, overlord/devicestate: validate that system supports encrypted data before install <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9605>
[12:37] <mup> PR snapd#9606 opened: tests: Use systemd-run on tests part2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9606>
[12:52] <pedronis> mborzecki: mvo: I made a comment there now, can be a follow up
[12:59] <ijohnson> hey folks
[12:59] <ijohnson> how are we doing this morning
[13:04] <mborzecki> pedronis: thanks
[13:04] <mborzecki> ijohnson: not great not terrible i guess, one PR has landed, another one is waiting for spread to finish
[13:05] <mborzecki> correction, 2 have landed now
[13:05] <ijohnson> As meatloaf would say, 2/3 ain't bad :-)
[13:06] <ijohnson> No points in guessing which one hasn't landed yet though I suppose
[13:06] <mborzecki> i'll update 9600 in a bit
[13:07] <mup> PR snapd#9604 closed: secboot, many: return UnlockMethod from Unlock* methods for future usage <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9604>
[13:08] <ijohnson> thanks mborzecki
[13:11]  * tobias_ waves
[13:25] <pedronis> mborzecki: ijohnson: hi, is 9600 ready for re-reviews or there is more to do there?
[13:27] <mborzecki> pedronis:i think it's ready
[13:27] <pedronis> ok
[13:28] <ijohnson> Yes it should be ready
[14:32] <pedronis> 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] <mborzecki> 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] <mborzecki> mvo: pedronis: pushed tweaks to #9539
[14:45] <mup> PR #9539: many: add /v2/system-recovery-keys API and client <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9539>
[14:48] <pstolowski> 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] <mvo> mborzecki: \o/
[14:51] <mvo> mborzecki: needs a second +1 from pedronis and then this one can go in and I can update the client
[15:48] <mup> PR snapd#9607 opened: o/devistate: fix chaining of tasks related to regular snaps when preseeding <Bug> <Run nested> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9607>
[15:51] <zyga> pedronis, hey, do you think next week you will have some time to look at the remaining export manager patches?
[15:51] <pedronis> zyga: hopefully yes
[15:52] <ijohnson> pedronis: so regarding your comment on 9600 re the copyUbuntuDataAuth and friends, what did you mean by that?
[15:53] <ijohnson> pedronis: did you mean we should try to copy files even if we know we haven't mounted ubuntu-data at host ?
[15:53] <pedronis> ijohnson: no, my question is what to do with the errors of the various copy errors if we have mounted it
[15:54] <pedronis> s/copy errors/copy methods/
[15:54] <zyga> pedronis, great, I'm looking forward to that
[15:54] <ijohnson> 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] <pedronis> ijohnson: yes, that's my question basically
[15:55] <pedronis> ijohnson: it can be a follow up though I suppose
[15:55] <ijohnson> yes I think that's a reasonable thing to do
[15:55] <pedronis> given that the PR is already big
[15:55] <ijohnson> but yes the PR is big so we could do that as a followup
[15:55] <ijohnson> I'll do it as a follow-up
[15:57] <pedronis> 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] <ijohnson> pedronis: hmm I suppose we could do something like that
[16:04] <ijohnson> 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] <pedronis> ijohnson: it feels a bit more future-proof to me (and also slightly nicer)
[16:12] <ijohnson> pedronis: let's do it
[16:13] <niemeyer> Curious.. why was the tomb.Wait removed at the end of daemon.Stop?
[16:14] <pedronis> niemeyer: I need to dig, don't remember (also in a meeting atm)
[16:15] <niemeyer> pedronis: Cool, no rush.. just curious as it might imply the Loop goroutine can stay alive
[16:23] <niemeyer> pedronis: Nevermind, it wasn't removed.. it was moved
[16:27] <pedronis> niemeyer: ah, thanks for double-checking
[16:27] <niemeyer> np, sorry for the false alarm
[17:24] <pedronis> 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] <ijohnson> 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] <ijohnson> ok I got it in good shape I think now
[18:19] <ijohnson> just need to have lunch and update 7 unit tests
[18:44] <mborzecki> mvo: some store hiccups in https://github.com/snapcore/snapd/pull/9539
[18:44] <mup> PR #9539: many: add /v2/system-recovery-keys API and client <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9539>
[18:45]  * cachio afk
[19:09] <ijohnson> 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] <ijohnson> if there are comments I might check back in late my PM or over the weekend,
[19:10] <ijohnson> we might have slight disagreements over the level of detail I am now putting into degraded.json
[19:10] <ijohnson> I think it's nice because it's rich and we can just ignore stuff we don't care about or use
[19:10] <ijohnson> anyways, have a nice weekend folks
[19:42] <om26er> ijohnson ping re: https://forum.snapcraft.io/t/download-snap-and-assert-without-snap-download-command/20869/9
[19:42] <om26er> can you help with that ?
[19:57] <mup> PR snapcraft#3358 opened: Fix colcon v1 workspace sourcing <Created by artivis> <https://github.com/snapcore/snapcraft/pull/3358>
[22:02] <zyga> ijohnson hey
[22:03] <zyga> ijohnson did you EOD today or are you still working? I'd like to reboot spread worker host for kernel upgrade
[22:05] <ijohnson> zyga: hey I'm EOD so go for it
[22:05] <zyga> great, thanks
[22:06] <zyga> I noticed that there were no jobs running or queued so I thought it's safe but wanted to ask first
[22:06] <zyga> btw, was the release successful?
[22:25] <ijohnson> zyga unfortunately not, will have to wait til Monday now
[22:25] <zyga> I'm sorry to hear that, I hope it's nothing serous and just stuff dragging into the weekend
[22:29] <zyga> kernel upgrade completed, workers are starting asynchronously now