=== jamesh_ is now known as jamesh [07:00] morning [07:57] PR snapd#10074 opened: daemon: fix signing key validity timestamp in unit tests [08:02] mvo: hey [08:02] good morning mborzecki [08:03] mvo: i think that https://github.com/snapcore/snapd/pull/10074 should fix the model timestamp issue taht we occasionally see in the tests [08:03] PR #10074: daemon: fix signing key validity timestamp in unit tests [08:04] mborzecki: niiiiiiiice! [08:05] mborzecki: haha, nice catch [08:06] afaiu the model gets signed by the key with some timestamp, but we generate user assertions and as a dependency set up the account key only in the next call [08:09] yeah, it akes sense [08:11] if we used RFC3339Nano for the timestamps it would come up sooner ;) [08:14] morning [08:25] good morning pstolowski [08:25] mborzecki: haha, indeed [08:26] pstolowski: hey [08:28] mvo: i've restarted spread test job in https://github.com/snapcore/snapd/pull/10071 should we pull in the change that added 21.04 to spread.yaml too? (maybe in a separate pr?) [08:28] PR #10071: packaging: drop dh-systemd from build-depends on ubuntu-16.04+ (2.49) <âš  Critical> [08:30] mborzecki: a good question, probably [08:30] mborzecki: yeah, makes sense, gives us more confidence for the unit tests this way [08:33] PR snapd#10074 closed: daemon: fix signing key validity timestamp in unit tests [08:43] is prepare failing with: 2021-03-24T07:31:03.3664323Z rm: cannot remove '/var/lib/snapd': Directory not empty [08:43] 2021-03-24T07:31:03.3665576Z dpkg: error processing package snapd (--purge): [08:43] 2021-03-24T07:31:03.3666687Z installed snapd package post-removal script subprocess returned error exit status 1 [08:43] 2021-03-24T07:31:03.3667583Z Errors were encountered while processing: [08:43] something new? [08:43] I got it here: https://github.com/snapcore/snapd/pull/10040/checks?check_run_id=2182138789 [08:43] PR #10040: daemon: switch api_test.go to daemon_test and various other cleanups [08:44] pstolowski: can you take a look https://github.com/snapcore/snapd/pull/10059 ? [08:44] PR #10059: cmd/snap: use less aggressive client timeouts in unit tests [08:44] mborzecki: looking [08:45] thanks! [08:50] thank you guys, you rock [08:51] mborzecki: hi, #10067 looks good, there are mostly question whether we are missing some tests perhaps, #10054 we still need to think what to do with the check [08:51] Bug #10067: jigit: new changes from Debian require merging [08:51] PR #10067: overlord/snapstate: make sure that snapd current symlink is not removed during refresh [08:51] Bug #10054: gnome-gpg: new changes from Debian require merging [08:51] PR #10054: snapdtool, wrappers: add dependency on usr-lib-snapd.mount for services on core with snapd snap [08:52] #10068 needs 2nd reviews [08:52] Bug #10068: kbd-chooser: new changes from Debian require merging [08:52] PR #10068: o/configstate: don't pass --root=/ when masking/unmasking/enabling/disabling services [08:53] PR snapd#10059 closed: cmd/snap: use less aggressive client timeouts in unit tests [08:54] pedronis: i'm taking a look at the questions in 10067, and i think we should land it before 10054 [08:54] ok [08:55] #10070 also needs a 2nd review, it's trivial [08:55] Bug #10070: kdegraphics: new changes from Debian require merging [08:55] PR #10070: tests/core/fsck-on-boot: unmount /run/mnt/snapd directly on uc20 [08:56] looking [08:58] PR snapd#10037 closed: boot: export helper for clearing tried system state, add tests [08:58] mborzecki: ^ I merged that [08:58] pedronis: thanks! [08:59] mvo: #10035 is kind of ready to land, otoh maybe it should have run with nested ? [08:59] PR #10035: o/devicestate: split off ensuring next boot goes to run mode into new task [08:59] Bug #10035: camlimages: new changes from Debian require merging [09:02] pedronis: let me look. what is your opinion on 10068 for 2.49? it seems safe enough but it also changes how we disable rsyslog [09:02] pedronis: we could also pull it into 2.50 that would be okay still timeline wise (but 2.49 would be nicer from this POV) [09:03] mvo: we have spread tests for that I think, it doesn't seem very risky too me, but maybe pstolowski has input on this [09:03] pedronis: I will run 10035 here nested locally [09:03] pedronis: yeah, my feeling too [09:04] * pedronis quick errands [09:11] mvo: yes i think 10068 should be fine for 2.49 [09:11] assuming spread nested is happy [09:13] PR snapd#10069 closed: tests: fix cgroup-tracking test [09:15] pstolowski: thanks! can I squash merge 10048 ? or would you rather have the two commits? (would make backports easier) [09:16] mvo: it's fine to squash [09:28] mvo: nb i might have a fix for https://bugs.launchpad.net/snapd/+bug/1920773 today [09:28] Bug #1920773: Snapd crashes and fails to start when snap config dict and dict elememnts unset at the same time [09:28] alan_g: I think https://github.com/MirServer/snapd/pull/6 should resolve the remaining issues with the desktop-launch PR. There were a lot of unclosed review threads. [09:28] PR MirServer/snapd#6: More fixes based on review feedback [09:30] pstolowski: \o/ thank you [09:36] jamesh, thanks. Will take a look this PM (my time) [09:36] alan_g: thanks. No merges from master to confuse things this time [09:50] pedronis: i've updated #10067 [09:50] Bug #10067: jigit: new changes from Debian require merging [09:50] PR #10067: overlord/snapstate: make sure that snapd current symlink is not removed during refresh [10:13] pstolowski: I reviewed 100062 with a suggestion [10:14] pedronis: thanks! i didn't know that [10:25] oh well, i've a tentative fix for panic on nil map when unsetting the config, but when adding new tests i found another funny scenario where unsets followed by sets over same path don't give correct result at the end :( [10:27] pstolowski: sounds we have deeper problems? [10:27] or we broke something recently? [10:28] pedronis: don't think we broke, must be something that dates back to introduction of unset/nils [10:29] :/ [10:32] really an edge case i think, e.g. doc.x.a=1; commit; doc.x=nil doc.x.a=nil doc.x.a=1 -> doesn't set doc.x.a back, config remains nil (that's with my tentative fix as otherwise it would panic in the middle) [10:32] also, this works fine if commited in between, so only an issue when unsetting and then setting over same path in same transaction [10:33] and it's hard to comprehend what's going wrong :/ [10:35] pstolowski: sounds like Transaction.changes is not quite the right representation or we are holding it wrong [10:35] pedronis: or PatchConfig logic gets something wrong [10:37] yea, but at some if the code is hard to get right maybe the data structure is wrong [10:37] *some point [10:50] pedronis: should we unhide snap validate command now? [10:53] is the forum down? [10:57] not here, a bit slow [11:00] mborzecki: do you have a moment to take a look at https://github.com/snapcore/snapd/pull/10062 ? [11:00] PR #10062: tests: validation sets spread test [11:00] pstolowski: sure [11:03] pstolowski: for 2.50? yes, enforce is hidden right? [11:03] pedronis: been thinking about https://github.com/snapcore/snapd/pull/10054#pullrequestreview-616530057 a bit, and what zyga proposed is probably the only way that works correctly with run-from-snapd-snap [11:03] PR #10054: snapdtool, wrappers: add dependency on usr-lib-snapd.mount for services on core with snapd snap [11:04] mborzecki: I fear that but it feels a bit strange [11:06] pedronis: it would probably involve stat() grab major:minor of the device, inpect /sys/dev/block//loop/backing_file, not too hard but not simple either [11:07] mborzecki: we need this only for core18/20 right, though? not classic? [11:08] pedronis: yes, for 2.50. enforce is hidden but also entire command is hidden [11:08] yes, it's for 10054 which is relevant to core only [11:08] I mean the helper where is is now would need to be general, but our use case is core only [11:08] mborzecki: we can get the info from the model on core [11:09] we just need to pass it down somethow [11:10] pedronis: ah, so you mean rather than inspecting where snapd comes from, check whether the curernt model indicates core (or otherwise the need to usr-lib-snapd.mount)? [11:12] hm the services are written when linking the snap, so we could probably pass something down in LinkContext [11:25] mborzecki: another approach would be to check if usr-lib-snapd.mount exists [11:25] perhaps? [11:25] let me get you the diff, it's actually quite clean [11:28] pedronis: https://paste.centos.org/view/0c605d86 it's missing tests in snapstate [11:28] oh, and pastebinit does not work anymore (?), i'm getting `Failed to contact the server: HTTP Error 405: Method Not Allowed` [11:43] mborzecki: yes, it looks reasonable [11:45] mborzecki: we can discuss final naming in the PR [11:45] yup [12:13] pedronis: i've updated https://github.com/snapcore/snapd/pull/10054 [12:13] PR #10054: overlord/snapstate, wrappers: add dependency on usr-lib-snapd.mount for services on core with snapd snap [12:14] pedronis: I updated 9981 as discussed [12:14] pedronis: I could also chop it into smaller chunks (or try to), it grew over time :/ [12:16] mvo: I'll look in a bit [12:16] mborzecki: thanks, I'll look in a bit [12:17] back to that review i promised to pstolowski [12:18] pedronis: thanks! [13:10] mvo: I reviewed it, I think it needs re-reviews from the others too [13:53] morning [13:58] pedronis: great, thanks [15:40] mvo: hi! I updated snappy-debug today for 2.49.1, but it is failing to upload: https://launchpad.net/~jdstrand/+snap/snappy-debug/+build/1347999 ('Cannot upload new revisions for name=snappy-debug'). I reauthorized store uploads, but it didn't work. I don't have any visibility into this. can you (or someone else) help/advise? [15:42] mvo: also https://launchpad.net/~jdstrand/+snap/snappy-debug/+build/1348000 (this is amd64, the other is i386, the others haven't built yet) [15:43] hey jdstrand :) [15:43] it's so nice to see You here [15:43] hey zyga :) [15:43] nice to see you too :) [15:43] how do you find time to work on Snappy bits? I'm swamped with work myself? [15:44] zyga: I don't really. I am attending a virtual conference today and it didn't start til 10am local so I did something bite size :) [15:45] linaro connect by any chance? [15:45] no, that would be much earlier [15:45] no, it is a secure coding thing [15:45] oh, neat [15:46] I may find have some work time for some interface work to support some snaps at some point though [15:46] s/find/find I/ [15:46] I want to get back into _some_ snapd work that's actually aligned with my new day job [15:47] * jdstrand nods [16:13] mborzecki: I reviewed #9940, thanks [16:13] PR #9940: boot: cmd/snap-bootstrap: handle a candidate recovery system v2 [16:15] pedronis: fwiw, 9981 is updated again [16:18] mvo: re-reviewed [16:18] pedronis: \o/ thank you [16:21] maybe ijohnson or mborzecki can do a second review of 9981 of the last few commits, great that it's finally ready :) [16:29] PR snapcraft#3487 opened: cli: warn about migration if using core [16:47] mvo: sure I will add it to my queue [16:47] ta === ijohnson is now known as ijohnson|lunch [18:24] PR snapcraft#3488 opened: cli, repo: add support for UA tokens === ijohnson|lunch is now known as ijohnson [20:40] PR snapd#10075 opened: udisks2 2.8.4 needs to also lock /run/mount/utab