[05:33] morning [06:50] mvo: hey [06:51] hey mborzecki [06:52] mvo: an interesting bug https://bugs.launchpad.net/snapd/+bug/1890046 [06:52] Bug #1890046: Handle SOURCE_DATE_EPOCH for SquashFS [06:55] mborzecki: uh, looking [06:56] mborzecki: hm, doing this for the snapd snap should be easy, core is a bit harder. i wonder if we should just sru squashfs-tools [07:01] morning [07:02] pstolowski: hey [07:03] good morning pstolowski [07:03] mvo: there's probably some concerns about the review-tools/store side of things? [07:05] mborzecki: yeah, probably something to talk to jamie about [07:09] mborzecki: hm, the bug report talks about reproducible builds, this is exactly what we want too I guess [07:11] mvo: right, common goals may make sru'ing squashfs-tools a bit easier ;) [07:11] :) [07:12] need to go and drop some paperwokr at my accountant [08:17] re [08:39] mvo: pstolowski: hi, have we prepared backports for snap debug seeding stuff ? [08:44] pedronis: afaiu mvo was going to look at the commits yesterday so i haven't do anything about that. i'm happy to take this over if not started yet [08:45] pstolowski: it seems like we need to add preseed code to all interfaces backends no? [08:45] pstolowski: I have not started yet, if you have capacity for this, that would be great [08:45] pedronis: nb, we may have an issue with udev though, see mattermost chat [08:46] pedronis: yep, udev backend [08:46] pstolowski: yes, that's why my comment about interfaces backends [08:46] pstolowski: well, we need to look at all backends and see which one can trigger external programs/services [08:46] pedronis: yes [08:46] and see which one don't work in a chroot [08:47] and see what to do [08:47] mvo, pedronis i've doctor appointment in 15, shouldn't take long, will be back on this afterwards [08:47] ok [08:48] pstolowski: not super urgent, no worries. see you [08:52] * pstolowski bbiab [08:59] good morning [08:59] * zyga came to check if 2.45.3.1 built fine for suse [09:05] zyga: hey, how are you feeling today? [09:15] mborzecki: much better [09:15] stronger than before [09:15] zyga: yay, that's great [09:15] zyga: koza sends regards ;) [09:15] oh cool [09:15] I wonder how he is doing [09:21] back [09:21] hey zyga! [09:22] hey Pawel! [09:23] last day off [09:23] I can walk more each day [09:23] I think tomorrow I could do two hour standing sessions interspaced with one hour in-bed sessions [09:23] and intermixed with prescribed exercise [09:56] mvo: can you take a look at https://github.com/snapcore/snapd/pull/9078 ? [09:56] PR #9078: [RFC] boot: fancy marshaller for modeenv values [09:57] mvo: and i'll poke ijohnson too when he's online, it'd be nice to land it soonish [10:01] mborzecki: yes [10:01] mvo: thanks! [10:21] hey mvo [10:22] I was just chatting with Pawel [10:22] I will take a break now, I'll come back later [10:34] pedronis: do you have a moment for #9088 ? [10:34] PR #9088: cmd/snap-preseed: use snapd from the deb if newer than from seeds

[10:51] pstolowski: do you have a question? or do you need a review? [10:52] pedronis: review [10:52] ah, no, I confused it with a different PR [10:52] I put it in my queue (having lunch break atm) [10:52] thanks, enjoy [11:18] PR snapd#9090 closed: cmd/snap/debug/seeding: use unicode for proper yaml <⚠ Critical> [11:18] mvo: ^ I forced merged that one, we have a problem with debian-sid atm, it will need a backport [11:43] pedronis: ok [11:43] pstolowski: reviewed, made some maybe slightly annoying comments, and also a very different suggestion in: https://github.com/snapcore/snapd/pull/9088#discussion_r465666390 [11:43] PR #9088: cmd/snap-preseed: use snapd from the deb if newer than from seeds

=== benfrancis0 is now known as benfrancis [11:54] pedronis: thanks, will take a look [11:55] pstolowski: I think the suggestion is simpler than either current or what I suggested, if a bit less clean, but probably clean enough [12:03] moving back home [12:15] morning folks [12:16] mvo: I did a pass on #8982, looks good, left some comments. It needs new reviews though because it has changed quite a bit [12:16] PR #8982: snapshots: export of snapshots [12:17] pedronis: thank you so much [12:18] PR snapd#9092 opened: interfaces/udev: Do not reload udevadm rules when preseeding

[12:18] ^ i need to check other backends, will address them separately if needed [12:27] ouch https://www.engadget.com/honda-recalls-608000-minivans-and-suvs-with-fault-software-issues-121511778.html [12:27] shoud have auto-refresh enabled ;) [12:30] pstolowski: I reviewed that [12:32] ty [12:32] what's the situation with the udev backend and preseeding ? [12:33] pedronis: 8946 got a review from Graham, he +1 but also mentioend to add a period at the end of each sentence. I guess I will just add the "." and push and once tests are good merge ? or do you think the extra spread run is not needed? [12:35] ijohnson: I got past the mount issue on xenial, but then it failed as apparently udevadm was triggered by some interface in the seeded snaps (see my standup notes) [12:35] * ijohnson looks [12:36] mvo: not, needed but the tool needs changes [12:36] as well [12:37] mvo: I can also look into that today [12:37] mvo: doing cherry-picks for 2.45 is probably more urgent [12:38] pstolowski: interesting, perhaps we should try seeding other snaps which have other interfaces [12:38] err preseeding [12:38] ijohnson: I asked to look at all backends [12:38] ijohnson: i'm going to check other backends [12:38] sorry I just meant as a spread test [12:38] since we may change things over time in the backends setup [12:38] yes [12:39] but a bit unclear how to do that, we mostly need to cover backends more than interfaces, but backends might vary. We have a snap with all possible interfaces [12:39] but not sure it would play well with preseeding [12:40] also the issue is that snap with all possible interfaces doesn't have store decls, does it ? [12:40] exactly [12:40] we would need store assertions for the backends to actually run when interfaces are connected [12:40] also connecting them doesn't always make sense [12:40] mmm [12:41] I mean, with things like some of the support interfaces it gets messy [12:41] I mean I don't think is sensible to have such set of store declarations [12:41] I think we need just enough to cover our bases [12:41] agreed [12:41] sensibly [12:42] maybe there's a why to write backends that would make this kind of issue easier to track [12:43] mvo: I'll take care of 8946 today [12:46] pedronis: thank you [12:52] mvo: pushed, please double check my last changes when you have a moment [12:53] kmod backend needs the same treatment [12:55] pstolowski: systemd as well I think [12:55] pedronis: just looking at it.. yes [12:58] i forgot about all these corners [13:40] ijohnson: can you take a look at https://github.com/snapcore/snapd/pull/9078 later today? [13:40] PR #9078: [RFC] boot: fancy marshaller for modeenv values [13:41] sure [13:41] ijohnson: thanks, it'd be nice to land it to unblock the horrors in modeenv [13:41] * ijohnson read it as "unlock the horrors" and I imagine it's not actually too far off [13:58] hm damn build tags [14:23] PR snapd#9093 opened: interfaces/kmod: don't load kernel modules in kmod backend when preseeding [14:27] should #9041 be tagged for 2.45 as well? [14:27] PR #9041: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* [14:28] pstolowski: no not necessary for 2.45, as it's blocked on security [14:29] ack [14:46] * cachio lunch [15:07] pstolowski: I just landed #9091 [15:07] PR #9091: cmd/snap: display the error in snap debug seeding if seeding is in error

[15:08] ack, ty [15:09] PR snapd#9091 closed: cmd/snap: display the error in snap debug seeding if seeding is in error

[15:09] pstolowski: so I think with that all the debug seeding PR are on master [15:12] pedronis: yes; i'll look at backporting now [15:12] thank you [15:24] PR snapd#8946 closed: client: move all error kinds into errors.go and add doc strings [15:25] degville: mvo: I did the merge: https://github.com/snapcore/snapd/commit/a777978c1102ea95f0a820e174ee066e6efcbcb4 [15:25] pedronis: thank you! [15:27] pedronis: thanks! I'll update the API page accordingly. [15:27] thank you [15:39] PR snapd#9094 opened: corecfg: add "system.hostname" setting to the system settings [16:01] so everything re seeding debug backported cleanly, except for spread tests & their helper scripts :}, a bit of a mess there [16:22] PR snapcraft#3197 closed: experimental extension support [16:44] PR snapd#9083 closed: tests: new parameters for nested execution [17:12] PR snapcraft#3239 opened: lxd: update connectivity check url [17:26] ijohnson, cmatsuoka hi, someone could please take a quick look to this one? #8942 [17:26] PR #8942: tests: support different images on nested execution [17:27] it needs a second review [17:27] I need that merged to start pushing a new set of improvements for nested [17:27] thanks [17:38] cachio: sure I can take a look [17:46] ijohnson, tx+ [18:19] cachio: did you try that branch with the cloud-init nested spread tests ? [18:20] all the tests are executed with cloud init [18:20] cachio: no I mean did you run the specific tests/nested/manual/cloud-init-* spread tests with this branch ? [18:20] ijohnson, not sure if I am understanding whe question [18:20] I imagine those tests would fail with your change [18:21] because now when we call start_nested_vm_unit the image file modifications previously done in those tests/nested/manual/cloud-init-* tests would be undone and thus cause those tests to break [18:22] well, they are going to be executed as part of the github actions tests [18:22] let me check the results [18:23] ok, but I still think that bit of changes would break those tests [18:23] I'll make a review now to see [18:23] if those tests still pass then perhaps the tests are written poorly [18:23] thank you [18:23] ij [18:24] ijohnson, it should work [18:24] because in this pr after the manual test we clean the images [18:24] so it is not a problem [18:24] your concern if fixed in the following one, because the manual tests haev a specific name in the images [18:25] and the images are not cleaned anymore [18:25] so they can be reused [18:25] does it make sense? [18:25] cachio: no what I mean is that in the tests/nested/manual/cloud-init-nocloud-not-vuln test, we manually call `start_nested_core_vm_unit` [18:26] yes, all the manual tests do that [18:26] so now when that is called on line 150 of that task.yaml, your code will overwrite the image file that was used earlier in the test when we called start_nested_core_vm on line 40 [18:26] cachio: sorry I think the point I'm trying to make is that we have tests where start_nestec_core_vm_unit is called multiple times during one test [18:26] ah, ok, got it, let me see [18:29] ijohnson, so the problem is that we do [18:29] cp "$IMAGE_DIR/$IMAGE_NAME" "$CURRENT_IMAGE" [18:29] yes that will overwrite the CURRENT_IMAGE used earlier in the test [18:30] when we start ther image and this overwrite the image right? [18:30] yes [18:30] ijohnson, ok, good point, I can fix that [18:30] thanks [18:31] thakns for the review!!! [18:32] np [18:37] ijohnson, I think it should be fised [18:37] fixed [18:40] let see the test results [18:40] ijohnson, I am going to the kinesiologist now [18:40] I'll be back in 1 hour [18:40] thanks for the review [18:40] cachio: ack I'll take a look at the test results when it's done [18:45] I had to leave the copy in the function start_nested_core_vm_unit because now the same of the image changes [18:49] * cachio afk -> kinesiologist [20:37] PR snapcraft#3239 closed: lxd: update connectivity check url [21:35] PR snapd#9085 closed: daemon,many: switch to use client.ErrorKind and drop the local errorKind [21:45] PR snapd#9095 opened: boot/bootstate20: unify commit method impls, rm bootState20MarkSuccessful [21:45] PR snapd#9096 opened: strutil: add ListsSame helper [21:45] PR snapd#9097 opened: boot/modeenv: add m.deepEquals, m.Origin helpers to simplify bootstate20 refactor