[01:37] PR snapd#8304 opened: usersession/userd: add zoommtg url support [06:41] morning [07:06] hey :) [07:06] coffee [07:06] I'm a bit tired today [07:06] cannot stop working till NaN o clock [07:13] yawn [07:31] I need a break today [07:31] I'll be back later [07:31] I just need to rest [07:34] zyga: fwiw it's officially spring now [07:57] hmm broke snapd somehow [08:00] oh spring [08:01] too bad we cannot leave home [08:02] I need to burn overtime [08:05] mornings [08:05] hey pstolowski [08:05] and good morning mborzecki [08:08] pstolowski: mvo : hey! [08:08] hey mvo and pawel [08:08] o/ [08:08] mvo: I filed for the day off, I just need to slow down and not work till 22 [08:08] plus, it's spring as maciek told me [08:31] PR snapd#8251 closed: overlord: remove unneeded overlord.MockPruneInterval() mocks [08:31] PR snapd#8302 closed: interfaces/greengrass-support: fix typo [08:31] PR snapd#8303 closed: interfaces/greengrass-support: fix typo [09:05] zyga: do you know if the focal can be safely updated now? [09:42] pstolowski: snap-preseed -reset in actually in beta now I think [09:44] pedronis: but they need the deb for snap-preseed command (or build it themselves) [09:44] pstolowski: yes, just pointing out that is not just in edge [09:46] pedronis: i see, ok, i'll send an update, core from beta + ppa for snap-preseed [09:51] pedronis, pstolowski it's in 2.44 which is in focal right now if that helps [09:53] I suppose it might not, but mostly to show some progress in releasing this [09:53] pstolowski: yes it can [09:53] mvo: that's nice, thanks, i suppose they need xenial though [09:53] I just fixed my laptop [09:53] (nonetheless i'll mention this) [09:53] zyga: ack, ty [09:59] pstolowski: yah, now back in graphical mode [09:59] if you need to fix but don't have a bootable helper [09:59] you can enable debug shell [09:59] set static IP address over eth0 [10:00] and upgrade libcrypt [10:00] then it works [10:03] zyga: i just upgraded, didn't have to do anything (but i haven't updated for a while, had ~250 packages to upd) [10:12] pstolowski: it was only bad if you upgraded over that weekend when it was broken [10:12] zyga: yeah, i just avoided a bad package [10:19] PR snapd#8305 opened: cmd/snap-recovery-chooser: add recovery chooser [10:19] mvo: ^^ [10:20] time to tweak do the tweaks in 8298 [10:22] PR snapd#8200 closed: [RFC] cmd/snap-chooser-ui-demo: a demo of recovery chooser UI [10:24] mborzecki: thank you [10:27] #8208 still needs a 2nd review [10:27] PR #8208: boot_test: add many boot robustness tests for UC20 kernel MarkBootSuccessul and SetNextBoot [10:32] hey bdx have you seen https://github.com/snapcrafters/sentry/issues/29 ? [10:32] pedronis: looking at this now [10:48] PR snapd#8208 closed: boot_test: add many boot robustness tests for UC20 kernel MarkBootSuccessul and SetNextBoot [10:53] I'm technically off today but +1 on https://github.com/snapcore/snapd/pull/8242 - let's land it [10:53] PR #8242: many: improve environment handling, fixing duplicate entries

[10:54] I have a moment while lucy is sleeping [10:54] shall I just merge it? === pedronis_ is now known as pedronis [10:57] zyga: it has two +1 so should be fine [10:57] ok [10:57] squashing and merging [10:57] thanks! [10:58] I *love* fixing bugs [10:58] PR snapd#8242 closed: many: improve environment handling, fixing duplicate entries

[11:06] mvo: about cloud-init and u-i, are you thinking of making --cloud-init work somehow for 20, at least for dangerous? [11:07] I'm not quite sure what it does for 16/18 [11:08] hi, when an automated snap refresh fails, does hook stdout/stderr get logged somewhere? [11:20] PR snapd#8306 opened: snap-bootstrap: add partition creation helper [11:36] mvo: master has formatting issues now, I think the env pr had still those test off so we didn't notice: https://travis-ci.org/github/snapcore/snapd/jobs/664797858?utm_medium=notification&utm_source=github_status [11:40] hi, does anyone have any idea if this is a snap bug or a snapd bug ? https://github.com/snapcrafters/sentry/issues/30 [11:48] pedronis: uh, ok. is someone on it already or should I do a quick PR? [11:50] axino, snaps can only access shm files under /dev/shm/$SNAP_NAME.* [11:50] axino, snapcraft-preload can help there [11:51] axino, https://github.com/sergiusens/snapcraft-preload [11:56] PR snapd#8307 opened: snap: run gofmt -s [12:01] mvo: thanks, I was having lunch [12:02] pedronis: me too [12:06] cjwatson: ah, thanks for confirming! hey mwhudson, we weren't too far off :) [12:19] PR snapd#8307 closed: snap: run gofmt -s === Facu is now known as facubatista [13:16] hello folks [13:17] PR snapcraft#2987 opened: spread tests: set appropriate default base in snapcraft.yamls [13:26] ijohnson: hi [13:32] hey pedronis [13:32] you were up pretty late last night :-) [13:32] indeed I was [13:33] any more thoughts on what else might be triggering snapd/snap things to run in early boot? [13:33] as I mentioned in the SU doc, I don't think it's necessarily the autoimport, because with the removal of that it still took a long time to boot, suggesting that there's something else that needs lots of entropy from 2.44 in early boot [13:33] ijohnson: I think really early boot was probably "snap auto-import", after that I would say any snap service [13:34] because of the implied snap run [13:34] ijohnson: the syslog thing would tell us for sure [13:34] I see you have a branch in the SU doc, shall I try that one? [13:35] ijohnson: yes, that's the real fix I would do for 2.44 , if it still works [13:35] it might not, depending [13:35] should I do that before the syslog branch then? [13:35] in any case, probs won't get results til after SU, I have to re-reserve the system [13:36] ijohnson: I thought you needed help for the syslog one, whatever order works best for you [13:37] well for the syslog branch if I add that with the removal of the autoimport, the system does eventually boot, so I think we should be able to get the data there, it just will take a while [13:38] ijohnson: ah, yes combining would work well, we should be able to see what is the first requester [13:38] knowing that otherwise it would be one of the auto-import [13:39] yes, but I also need to turn on persistent logs, because I noticed from the auto-import system journal logs I added to the SU doc that they didn't go all the way back [13:39] ok [13:40] ijohnson: anyway as I said in the SU doc, it's good we have likely a fix, but it would be also good to understand the full problem because other it might get back later [13:40] ijohnson: also mvo is pursuing seeing if the kernel can help, because we control snapd, but other things might start wanting entropy early [13:44] PR snapcraft#2988 opened: tests: add two more workers to the 18.04 systems [14:00] PR snapd#8308 opened: tests: umount partitions which are not umounted after remount gadget [14:57] pedronis: still waiting for that syslog change + no autoimport to boot, been like 20 minutes now so it should be any minute now, but it also could be racy that the no autoimport change from yesterday booted :-/ [15:05] ijohnson: worse case we can mix my full fix and logging [15:07] yes [15:07] ijohnson: I can propose something if you want [15:07] if you want to sure, but I think I'll give it some more time [15:30] ijohnson: https://github.com/pedronis/snappy/tree/randutil-syslog-fixed-sim-2.44 [15:38] pedronis: yeah the boot failed, I gave up on it, I'm gonna retry one more time [15:38] then I'll try your branch [16:10] pstolowski: fyi #8277 is now green and I have applied your comments [16:11] PR #8277: asserts,o/devicestate: support model specified alternative serial-authority [16:11] pedronis: ok [16:29] it would be great to land #8308 asap, since a number of open PR's are hitting the issued fixed there [16:29] PR #8308: tests: umount partitions which are not umounted after remount gadget <⚠ Critical> === ijohnson is now known as ijohnson|lunch [16:47] PR snapd#8308 closed: tests: umount partitions which are not umounted after remount gadget <⚠ Critical> [16:55] PR snapd#8309 opened: o/configcore: implement Apply method for early configuration of core === ijohnson|lunch is now known as ijohnson [17:17] ijohnson, hey, iptables is not included in the core20 snap, is that a bug? [17:18] ijohnson, firewall-control gives permissions to use it [17:18] abeato: yes sounds like a bug, perhaps xnox can fix that easily [17:19] core20 is also on github if you wanted to take a look you're self and file a MP [17:19] abeato: https://github.com/snapcore/core20 [17:19] ijohnson, thanks, I'll create an issue there [17:24] Issue core20#27 opened: iptables is missing [17:30] hm https://github.com/snapcore/core20/issue/27 is 404 for me?! [17:31] Issue core20#27: iptables is missing [17:31] oh [17:31] can we fix mup? [17:31] it needs to be "issues" not "issue" [17:33] xnox: I've mentioned it before to niemeyer [17:34] We can.. I've been working on mup in the last couple of weeks.. that will certainly be addressed [17:35] I'm replacing the whole database backend.. that's why it's taking a bit.. apologies for that [18:06] PR snapd#8310 opened: randutil: ask for less entrop during boot <⚠ Critical> [18:20] PR snapcraft#2989 opened: tests: only run catkin based snap on 16.04 [19:39] mvo, hey, is cloud init PR already merged? [19:39] mvo, or it is #8299 ? [19:40] PR #8299: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <⛔ Blocked> [19:43] cachio: #8278 was merged, but that just disables cloud-init for uc20, 8299 as you see is the PR which supports cloud-init from the ubuntu-seed partition [19:44] PR #8278: devicestate: disable cloud-init by default on uc20 [19:45] ijohnson, any idea when it is going to be merged? [19:45] because the user assertion alternative is taking to much time [19:45] cachio: I think it is close, afaik just needs pedronis to approve the new dir [19:46] cachio: although maybe we need to wait for the cloud folks to approve the new dir location, not sure [19:46] ijohnson, ah, ok [19:46] i.e. rharper and company [20:08] cachio: unfortunately not yet, it pending [20:11] PR snapd#8311 opened: randutil: don't consume kernel entropy at init, just mix more info to try to avoid fleet collisions [20:11] mvo: ijohnson: ^ [20:11] thanks looking now [20:13] pedronis: \o/ [20:13] pedronis: looking [20:18] pedronis: added a small question, looks very good [20:19] mvo: I answered [20:20] pedronis: aha, so seed is cumulative? it does not reset the state of the crng (sorry if that is a stupid question)? [20:20] mvo: the contrary, it resets it [20:20] but we use a value derived from the old one to make the new one [20:21] pedronis: aha, of course, sorry, misread the code. makes perfect sense [20:22] mvo: and to be clear I'm not doing all this in init because I don't want by chance to slow down snap run [20:22] which shouldn't care [20:22] pedronis: +1 [20:38] mvo: cachio: I don't we should be blocked on the cloud people, they just need to be aware of the slightly different location, the other one was anyway different from 16/18 [20:38] *I don't think [20:38] mvo: cachio: but I need to re-review it, which I will first thing Monday [20:39] sure [20:39] pedronis, is it any way to workaroud it while I am testing the new smoke suite executen in a nested uc20? [20:40] pedronis, I mean, using cloudinit [20:40] pedronis: thanks, enjoy your weeknd [20:42] mvo: I'm still around, waiting for the other results, but I don't think I can reviews right now [20:53] PR snapd#8310 closed: randutil: ask for less entropy during boot <⚠ Critical> [23:27] PR snapcraft#2989 closed: tests: only run catkin based snap on 16.04