/srv/irclogs.ubuntu.com/2020/11/06/#snappy.txt

mupPR 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
zygamvo, good morning06:53
mvogood morning zyga06:55
mborzeckimorning07:21
mvogood morning mborzecki07:21
mvomborzecki: how are you?07:22
mborzeckimvo: hey07:24
mborzeckimvo: are you working ona fix for in 9603?07:30
mborzeckimvo: cherry picked your patch from 9600 to 960307:33
mvomborzecki: sure, I did not even see that this is failing yet07:37
mvomborzecki: thanks for pushing it!07:38
jameshzyga: 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 good07:49
mupPR #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
zygajamesh, thank you07:49
jameshzyga: snap-update-ns didn't like the trailing slashes on the mount entries, since they aren't considered clean paths07:50
zygaoh, good catch, yeah the spread test was badly needed here07:50
jameshThe 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
zygathat's fine07:51
zygadid you see any issues with non-abstract unix socket permission?07:51
zygaIIRC the X abstraction was not granting rights for non-abstract sockets07:51
zygaor perhaps I've missed that, I only saw permission with @ names07:52
jameshThe abstraction has "/tmp/.X11-unix/* rw,", which seems to be enough07:52
jameshthe "w" is apparently needed to connect to sockets07:52
zygaahh, I see07:52
zygathat's good then07:53
zygaso the test also exercises all of the confinement07:53
zygawhat do you think about an option to opt-out of this for the cases that Alan mentioned?07:53
jameshI think it is a good idea.  I don't know whether we want to mix it into the existing PR07:53
jameshwe're going to break his snaps anyway07:53
zygano, I think it should be separate07:54
zygaI wonder what's the indented behavior though,07:54
jameshyeah.  That's one reason I'd like to treat it as its own problem07:54
zygaI think this should be merged07:55
zygajust get the reviews it needs07:55
jameshzyga: 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
pstolowskimorning08:03
mvogood morning pstolowski08:29
pstolowskio/08:35
mupPR 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
jameshalan_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
mupPR #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
jameshalan_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 soon09:19
mborzeckipedronis: hm do you mean we should explicitly set the method to NotUnlocked here? https://github.com/snapcore/snapd/pull/9604/files/ba66a2342a1b3237c713044397f149f2b40d7912#r51860936809:21
mupPR #9604: secboot, many: return UnlockMethod from Unlock* methods for future usage <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9604>09:21
pedronismborzecki: no, because activated is true09:25
pedronismborzecki: we need to understand a bit better the secboot function error behavior, I don't remember the details09:26
mborzeckihmm heh, it does look confusing09:27
mborzeckipedronis: 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
pedronismborzecki: I think so, looking at secboot09:30
mborzeckipedronis: ok, refactored that code a little bit and will push an update09:38
pedronisthx09:38
mborzeckimvo: do you think we could trim the standup doc? it makes my firefox very unhappy10:01
mvomborzecki: +110:02
mborzeckithanks!10:02
jameshpedronis: 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 resolved10:05
mupPR #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
pedronisjamesh: thanks10:11
mborzeckipedronis: i've updated #960410:12
mupPR #9604: secboot, many: return UnlockMethod from Unlock* methods for future usage <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9604>10:12
pedronismborzecki: reviewed10:35
mborzeckipedronis: thanks!10:37
mvolooks like 9604 can be merged?11:29
mborzeckimvo: does it show up correctly for you?11:43
mborzeckimvo:  it's showing all spread jobs of the last run as failed (even though i canceled the run from the previous commit)11:44
zygare11:52
mvomborzecki: sorry, was in a meeting12:00
mvomborzecki: maybe something stale, I just reloaded the page and now it's running12:01
mborzeckimvo: yes, i pushed a tweak that pedronis suggested12:01
mborzeckimvo: yes, i pushed a tweak that pedronis suggested12:06
mborzeckiduh, wrong window :P12:06
mvota12:09
mupPR 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
mupPR snapd#9606 opened: tests: Use systemd-run on tests part2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9606>12:37
pedronismborzecki: mvo: I made a comment there now, can be a follow up12:52
ijohnsonhey folks12:59
ijohnsonhow are we doing this morning12:59
mborzeckipedronis: thanks13:04
mborzeckiijohnson: not great not terrible i guess, one PR has landed, another one is waiting for spread to finish13:04
mborzeckicorrection, 2 have landed now13:05
ijohnsonAs meatloaf would say, 2/3 ain't bad :-)13:05
ijohnsonNo points in guessing which one hasn't landed yet though I suppose13:06
mborzeckii'll update 9600 in a bit13:06
mupPR 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
ijohnsonthanks mborzecki13:08
* tobias_ waves13:11
pedronismborzecki: ijohnson: hi, is 9600 ready for re-reviews or there is more to do there?13:25
mborzeckipedronis:i think it's ready13:27
pedronisok13:27
ijohnsonYes it should be ready13:28
pedronismborzecki: mvo: ijohnson: this is the f32 forum post: https://forum.snapcraft.io/t/some-snaps-wont-run-anymore-due-to-permission-denied/2083314:32
mborzeckipedronis: same dconf log appears apparently on manjaro: https://forum.snapcraft.io/t/completely-broken-snapd-environment-in-manjaro-20-1-2/20900/1914:33
mborzeckimvo: pedronis: pushed tweaks to #953914:45
mupPR #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
pstolowskiarggh, 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
mvomborzecki: \o/14:50
mvomborzecki: needs a second +1 from pedronis and then this one can go in and I can update the client14:51
mupPR 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
zygapedronis, hey, do you think next week you will have some time to look at the remaining export manager patches?15:51
pedroniszyga: hopefully yes15:51
ijohnsonpedronis: so regarding your comment on 9600 re the copyUbuntuDataAuth and friends, what did you mean by that?15:52
ijohnsonpedronis: did you mean we should try to copy files even if we know we haven't mounted ubuntu-data at host ?15:53
pedronisijohnson: no, my question is what to do with the errors of the various copy errors if we have mounted it15:53
pedroniss/copy errors/copy methods/15:54
zygapedronis, great, I'm looking forward to that15:54
ijohnsonpedronis: 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
pedronisijohnson: yes, that's my question basically15:55
pedronisijohnson: it can be a follow up though I suppose15:55
ijohnsonyes I think that's a reasonable thing to do15:55
pedronisgiven that the PR is already big15:55
ijohnsonbut yes the PR is big so we could do that as a followup15:55
ijohnsonI'll do it as a follow-up15:55
pedronisijohnson: also since the standup I have been thinking, should we organize degraded.json as {"disk-name": state-dict, ..., "error-log": ...} perhaps ?15:57
* cachio lunch15:59
ijohnsonpedronis: hmm I suppose we could do something like that16:04
ijohnsonpedronis: 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 eventually16:04
pedronisijohnson: it feels a bit more future-proof to me (and also slightly nicer)16:12
ijohnsonpedronis: let's do it16:12
niemeyerCurious.. why was the tomb.Wait removed at the end of daemon.Stop?16:13
pedronisniemeyer: I need to dig, don't remember (also in a meeting atm)16:14
niemeyerpedronis: Cool, no rush.. just curious as it might imply the Loop goroutine can stay alive16:15
niemeyerpedronis: Nevermind, it wasn't removed.. it was moved16:23
pedronisniemeyer: ah, thanks for double-checking16:27
niemeyernp, sorry for the false alarm16:27
pedronisijohnson: I can try to have another look in my evening (in 2-3h) if it's ready for it otherwise Monday morning17:24
ijohnsonpedronis: 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.json17:24
* ijohnson was also hoping to EOD soon too17:25
ijohnsonok I got it in good shape I think now18:18
ijohnsonjust need to have lunch and update 7 unit tests18:19
mborzeckimvo: some store hiccups in https://github.com/snapcore/snapd/pull/953918:44
mupPR #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 afk18:45
ijohnsonmvo: 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 Monday19:09
ijohnsonif there are comments I might check back in late my PM or over the weekend,19:09
ijohnsonwe might have slight disagreements over the level of detail I am now putting into degraded.json19:10
ijohnsonI think it's nice because it's rich and we can just ignore stuff we don't care about or use19:10
ijohnsonanyways, have a nice weekend folks19:10
om26erijohnson ping re: https://forum.snapcraft.io/t/download-snap-and-assert-without-snap-download-command/20869/919:42
om26ercan you help with that ?19:42
mupPR snapcraft#3358 opened: Fix colcon v1 workspace sourcing <Created by artivis> <https://github.com/snapcore/snapcraft/pull/3358>19:57
zygaijohnson hey22:02
zygaijohnson did you EOD today or are you still working? I'd like to reboot spread worker host for kernel upgrade22:03
ijohnsonzyga: hey I'm EOD so go for it22:05
zygagreat, thanks22:05
zygaI noticed that there were no jobs running or queued so I thought it's safe but wanted to ask first22:06
zygabtw, was the release successful?22:06
ijohnsonzyga unfortunately not, will have to wait til Monday now22:25
zygaI'm sorry to hear that, I hope it's nothing serous and just stuff dragging into the weekend22:25
zygakernel upgrade completed, workers are starting asynchronously now22:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!