[05:23] <mborzecki> morning
[05:53] <mardy> hi!
[05:57] <mborzecki> mardy: hey
[06:39] <zyga-mbp> good morning
[06:48] <mborzecki> zyga-mbp: heya
[06:49] <zyga-mbp> mborzecki sleepy today, lucy woke me up at 4AM 
[07:09] <pstolowski> morning
[07:22] <mborzecki> pstolowski: hey
[07:25] <mborzecki> looked at https://github.com/snapcore/snapd/pull/10347 tasks are hard :/
[07:26] <mborzecki> pstolowski: related to https://github.com/snapcore/snapd/pull/10359 have you looked at other places too?
[07:30] <pstolowski> mborzecki: not yet, will do today
[08:29] <pedronis> mborzecki: hi, I tweaked a bit your suggestion: https://github.com/snapcore/snapd/pull/10345/commits/5c1260da7fa5fee6f686ccf871dd2084138f25b8
[08:29] <mborzecki> pedronis: saw that, thank you!
[08:37] <mborzecki> heh ` [  230.815821] xdelta3 invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=-900`
[08:51] <mardy> While I study about the group creation story in snapd, do you think that fixing this would be a good task to start with? https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1840375/comments/11 Or is there something bigger blocking it?
[09:25] <ogra> mardy, oh, that would be lovely and helpful to finally get fixed
[09:28] <pedronis> mardy: no, that would be useful, you probably want to sync with mvo when he's around though, he worked in that area before
[09:30] <pedronis> mborzecki: is xdelta3 getting out of memory? there are some memory usage options but I don't know if they are relevant in the decompressing mode
[09:30] <pedronis> we would need to research
[09:31] <pstolowski> pedronis: i've rebased https://github.com/snapcore/snapd/pull/10358
[09:31] <mborzecki> pedronis: this, and local snap install, i looked briefly at io.Copy & friends, file and http request handling, it's unclear why snapd seems to die there
[09:31] <pedronis> pstolowski: thx
[09:31] <mborzecki> pedronis: fwiw, io.copy uses 32kb internal buffer
[09:31] <mardy> meanwhile, this is ready for a re-review: https://github.com/snapcore/snapd/pull/10266
[09:32] <mborzecki> and file implements ReaderFrom which would invoke sendfile(), but afaict it does not work between socket fd and file fd so, we're likely not hitting this path
[09:32] <pedronis> mardy: I'll look at it today
[09:32] <pedronis> it's in my queue
[09:35] <pstolowski> pedronis: the test case for holding we talked about is already covered in TestHoldRefreshHelperMultipleTimes - "holding for a shorter time is fine too" comment
[10:59] <mborzecki> hmm snap-builds job is failing occasionally
[11:37] <pedronis> mardy: I reviewed https://github.com/snapcore/snapd/pull/10266
[11:54] <mardy> pedronis: thanks!
[12:13] <mardy> here's a simple one to review (though it needs some decision): https://github.com/snapcore/snapd/pull/10363
[12:57] <mardy> pedronis: I'll also move the systemd.MockSystemctl() function to the new systemdtest package, right?
[13:22] <pedronis> mardy: you can't, that one is using private bits I think
[13:26] <mborzecki> cachio_: that pastebin looks like a similar problem to one we had before
[13:33] <mborzecki> need to run an errand, bbl
[15:21] <ijohnson> pedronis: regarding the question about cloud-init priority, I thought about that a bit, but honestly I don't know which should be higher priority, I can see use cases for both being higher priority, so I was thinking if we didn't rename any files, that would allow someone to pick the file prefix they want and then they can control the priority
[15:27] <pedronis> ijohnson: I understand the temptation to go that way, but some things have actually hard coded priorities already
[15:27] <ijohnson> pedronis: I suppose we could just ask TPE in the bug what they need and just go with that and change it when someone comes to complain they need the other way
[15:59] <ijohnson> bbiab, trying out the matrix libera.chat bridge
[16:14] <ijohnson[m]> hello again, can folks see my messages here ?
[16:15] <pstolowski> ijohnson[m]: no
[16:16] <ijohnson[m]> haha nice
[16:16] <ijohnson[m]> hmm my irc nick is still ijohnson[m] though it seems
[16:18] <ijohnson[m]> meh oh well, good enough for now, at least I will be able persistently connected again (hopefully)
[16:19] <mvo> ijohnson[m]: nice
[19:34] <zyga-mbp> cachio_ FYI https://forum.ostc-eu.org/t/lava-and-spread-in-all-scenarios-os-ci-loop/50/4