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:00 |
---|---|---|
zyga | mvo, good morning | 06:53 |
mvo | good morning zyga | 06:55 |
mborzecki | morning | 07:21 |
mvo | good morning mborzecki | 07:21 |
mvo | mborzecki: how are you? | 07:22 |
mborzecki | mvo: hey | 07:24 |
mborzecki | mvo: are you working ona fix for in 9603? | 07:30 |
mborzecki | mvo: cherry picked your patch from 9600 to 9603 | 07:33 |
mvo | mborzecki: sure, I did not even see that this is failing yet | 07:37 |
mvo | mborzecki: thanks for pushing it! | 07:38 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
zyga | I think this should be merged | 07:55 |
zyga | just get the reviews it needs | 07:55 |
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:03 |
mvo | good morning pstolowski | 08:29 |
pstolowski | o/ | 08:35 |
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> | 08:56 |
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:05 |
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:09 |
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:19 |
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:21 |
pedronis | mborzecki: no, because activated is true | 09:25 |
pedronis | mborzecki: we need to understand a bit better the secboot function error behavior, I don't remember the details | 09:26 |
mborzecki | hmm heh, it does look confusing | 09:27 |
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:29 |
pedronis | mborzecki: I think so, looking at secboot | 09:30 |
mborzecki | pedronis: ok, refactored that code a little bit and will push an update | 09:38 |
pedronis | thx | 09:38 |
mborzecki | mvo: do you think we could trim the standup doc? it makes my firefox very unhappy | 10:01 |
mvo | mborzecki: +1 | 10:02 |
mborzecki | thanks! | 10:02 |
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:05 |
pedronis | jamesh: thanks | 10:11 |
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:12 |
pedronis | mborzecki: reviewed | 10:35 |
mborzecki | pedronis: thanks! | 10:37 |
mvo | looks like 9604 can be merged? | 11:29 |
mborzecki | mvo: does it show up correctly for you? | 11:43 |
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:44 |
zyga | re | 11:52 |
mvo | mborzecki: sorry, was in a meeting | 12:00 |
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:01 |
mborzecki | mvo: yes, i pushed a tweak that pedronis suggested | 12:06 |
mborzecki | duh, wrong window :P | 12:06 |
mvo | ta | 12:09 |
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:22 |
mup | PR snapd#9606 opened: tests: Use systemd-run on tests part2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9606> | 12:37 |
pedronis | mborzecki: mvo: I made a comment there now, can be a follow up | 12:52 |
ijohnson | hey folks | 12:59 |
ijohnson | how are we doing this morning | 12:59 |
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:04 |
mborzecki | correction, 2 have landed now | 13:05 |
ijohnson | As meatloaf would say, 2/3 ain't bad :-) | 13:05 |
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:06 |
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:07 |
ijohnson | thanks mborzecki | 13:08 |
* tobias_ waves | 13:11 | |
pedronis | mborzecki: ijohnson: hi, is 9600 ready for re-reviews or there is more to do there? | 13:25 |
mborzecki | pedronis:i think it's ready | 13:27 |
pedronis | ok | 13:27 |
ijohnson | Yes it should be ready | 13:28 |
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:32 |
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:33 |
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:45 |
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:48 |
mvo | mborzecki: \o/ | 14:50 |
mvo | mborzecki: needs a second +1 from pedronis and then this one can go in and I can update the client | 14:51 |
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:48 |
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:51 |
ijohnson | pedronis: so regarding your comment on 9600 re the copyUbuntuDataAuth and friends, what did you mean by that? | 15:52 |
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:53 |
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:54 |
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:55 |
pedronis | ijohnson: also since the standup I have been thinking, should we organize degraded.json as {"disk-name": state-dict, ..., "error-log": ...} perhaps ? | 15:57 |
* cachio lunch | 15:59 | |
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:04 |
pedronis | ijohnson: it feels a bit more future-proof to me (and also slightly nicer) | 16:12 |
ijohnson | pedronis: let's do it | 16:12 |
niemeyer | Curious.. why was the tomb.Wait removed at the end of daemon.Stop? | 16:13 |
pedronis | niemeyer: I need to dig, don't remember (also in a meeting atm) | 16:14 |
niemeyer | pedronis: Cool, no rush.. just curious as it might imply the Loop goroutine can stay alive | 16:15 |
niemeyer | pedronis: Nevermind, it wasn't removed.. it was moved | 16:23 |
pedronis | niemeyer: ah, thanks for double-checking | 16:27 |
niemeyer | np, sorry for the false alarm | 16:27 |
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:24 |
* ijohnson was also hoping to EOD soon too | 17:25 | |
ijohnson | ok I got it in good shape I think now | 18:18 |
ijohnson | just need to have lunch and update 7 unit tests | 18:19 |
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:44 |
* cachio afk | 18:45 | |
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:09 |
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:10 |
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:42 |
mup | PR snapcraft#3358 opened: Fix colcon v1 workspace sourcing <Created by artivis> <https://github.com/snapcore/snapcraft/pull/3358> | 19:57 |
zyga | ijohnson hey | 22:02 |
zyga | ijohnson did you EOD today or are you still working? I'd like to reboot spread worker host for kernel upgrade | 22:03 |
ijohnson | zyga: hey I'm EOD so go for it | 22:05 |
zyga | great, thanks | 22:05 |
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:06 |
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:25 |
zyga | kernel upgrade completed, workers are starting asynchronously now | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!