[04:25] <mborzecki> morning
[04:39] <mardy> mborzecki: hi! I guess you too are not used to having this much sunshine in the room in the morning... :-)
[04:39] <mborzecki> mardy: hey, yes, it's already bit warm too
[06:07] <mborzecki> is github down again?
[06:09] <mborzecki> heh pushing doesn't work
[06:20] <zyga-mbp> good morning
[06:20] <zyga-mbp> it's already hot and it's just morning, uff
[06:21] <mborzecki> zyga-mbp: hey, well prefer that to it being cold all the time
[06:21] <zyga-mbp> mborzecki: I think you are at no risk of cold this week :)
[06:48] <mborzecki> i actually need to leave a tad earlier for my covid shot, so bbiab
[06:49] <zyga-mbp> o/
[07:13] <pstolowski> morning
[07:18] <mvo> good morning pstolowski 
[07:19] <pstolowski> mvo: hey, could you please merge https://github.com/snapcore/snapd/pull/10385 ?
[07:30] <zyga-mbp> mvo good morning
[07:43] <mardy> can some with more experience than me with snapcraft please advice on the best way to use a modified version of a part? https://github.com/ubuntu/microk8s/pull/2346/files
[07:44] <mardy> I've made the changes in my own fork or runc, but I wonder if it wouldn't be better to include the patches in the snap, and apply them on top of the upstream runc
[07:47] <zyga-mbp> mardy sorry, I never learned snapcraft much
[07:47] <zyga-mbp> most snaps I made were either test snaps or snaps where snapcraft was just so easy I didn't look deeper
[07:47] <mardy> zyga-mbp: no worries, thanks anyway :-)
[08:04] <pedronis> pstolowski: hi, I merged a couple of your PRs that were ready, there's also https://github.com/snapcore/snapd/pull/10413 but there is a conflict there now
[08:05] <pstolowski> pedronis: thanks
[08:06] <pedronis> thank you
[08:06] <mardy> mborzecki: you got some test failures on https://github.com/snapcore/snapd/pull/10423 (otherwise looks good to me)
[08:57] <pedronis> pstolowski: retry as usual are confusing:  https://github.com/snapcore/snapd/pull/10215#issuecomment-863878250
[09:06] <mborzecki> re
[09:07] <mborzecki> so far so good, the arm didn't fall of
[09:10] <pstolowski> pedronis: yes they are, thanks for the example. 
[09:12] <mborzecki> mardy: thanks, hmm the failure looks weird, filepwaht.walk is supposed to be deterministic
[09:31] <mborzecki> heh filepath.Walk changed slighly in go 1.10+
[09:35] <mborzecki> mvo: hi, can you take a look at https://github.com/snapcore/snapd/pull/10421 ?
[10:04] <mvo> mborzecki: sure, sorry, had meetings all morning but will look now
[10:04] <mborzecki> thanks!
[10:13] <mborzecki> anyne else finds the quoting chnges in https://github.com/snapcore/snapd/pull/10409 confusing?
[10:31] <mardy> mborzecki: I do, indeed
[10:40] <mardy> mborzecki: I'm now doing some tests, I think it should be possible to get rid of the extra quoting even without using external helper tools
[10:42] <mardy> I'm just not sure how to run these tests: spread -debug google:ubuntu-20.04-64:tests/nested/classic/hotplug
[10:42] <mardy> error: nothing matches provider filter
[10:47] <pstolowski> mardy: you need to used google-nested:...
[10:48] <pstolowski> mardy: it has special machines and setup for running nested VMs
[10:49] <mborzecki> mardy: i think cachio replied that the nested ' and " were being confused when using "$@"
[10:49] <mborzecki> perhaps that should have used $@ without "", so that no splitting occurs
[10:52] <mardy> pstolowski: mmm... I still don't find that test: spread -debug -list google-nested:ubuntu-20.04-64:tests/ | grep hotplug
[10:53] <mardy> mborzecki: yes, I saw the comment, but I suspect that there must be some error in quoting, "$@" usually works just fine (and the "" are needed)
[10:54] <pstolowski> mardy: try spread -debug -list google-nested:ubuntu-18.04-64:tests/nested/core/
[10:54] <pstolowski> mardy: and spread -debug -list google-nested:ubuntu-20.04-64:tests/nested/classic/
[10:55] <pstolowski> mardy: we might not be running it on all systems
[10:56] <mardy> pstolowski: oh, thanks, that did the trick
[10:57]  * pstolowski lunch
[11:49] <mardy> mborzecki: I think I got it, one just needs to quote the '|' (and maybe other special characters): https://github.com/snapcore/snapd/pull/10409#discussion_r654366403
[11:49] <mardy> though I'm not sure why | needs to be quoted
[11:51] <mborzecki> mardy: otherwise it becomes part of the current command?
[11:52] <mborzecki> mardy: what i mean is that `echo foo | bar` will echo foo and pipe that to bar, but `echo foo \| bar` will print `foo | bar`
[11:52] <mborzecki> confusing as hell nonetheless
[12:04] <jamesh> pstolowski: I've posted https://forum.snapcraft.io/t/a-desktop-notifications-client-api-for-snapd/25063
[12:04] <mardy> mborzecki: I'm still looking into it, but I start suspecting that the problem is in our retry python program
[12:05] <mborzecki> mardy: if you need to pass a | there, then the only way is to do `retry sh -c 'some | shell | script'`
[12:05] <pstolowski> jamesh: thank you, i'll be sure to check it out
[12:09] <mardy> mborzecki: I'm a bit lost, it's not clear to me why we need to quote the '|' in the spread; locally everything things to work fine without it (even the retry script seems ok)
[12:10] <cachio> ijohnson[m], hi, I see this error in some  tests
[12:10] <cachio> google:ubuntu-20.04-64 .../tests/main/snap-user-service-restart-on-upgrade# "$TESTSTOOLS"/snaps-state install-local test-snapd-user-service
[12:10] <cachio> error: cannot perform the following tasks:
[12:10] <cachio> - Make snap "test-snapd-user-service" (unset) available to the system (Post http://0/v1/service-control: dial unix /run/user/0/snapd-session-agent.socket: connect: connection refused)
[12:10] <cachio> any idea what we need to do to restore correctly to avoid that ?
[13:08] <zyga-mbp> cachio my guess is: you have a .socket and .service that are out of touch with what's in memory
[13:08] <zyga-mbp> we had this before
[13:08] <zyga-mbp> when you drop a .socket file and systemd creates the socket
[13:08] <zyga-mbp> editing the .socket file can have this result until the .socket or .service file (I don't recall which here) is reloaded
[13:09] <zyga-mbp> and we don't clean up systemd --user state between tests everywhere IIRC
[13:09] <zyga-mbp> I recall writing something related to that but I don't remember if we auto-restart everything everywhere
[13:09] <zyga-mbp> we hit this in pulseudio tests as well
[13:09] <zyga-mbp> when depending on prior tests, we could have a pulseaudio socket that didn't really work
[13:09] <zyga-mbp> and a pulseaudio.servie that started but had no socket
[13:41] <cachio> zyga-mbp, ah, nice
[13:41] <cachio> thanks for the explanation
[13:42] <cachio> I'll try to fix that test and then do something more generic to make sure the cleanup is done always it is needed
[13:52] <zyga-mbp> cool :)
[14:08] <mvo> cachio: I promoted core 2.51.1 to beta now
[14:08] <cachio> mvo, nice, thanks
[14:09] <mvo> cachio: unless I misread 2.51 is not in stable on all arches?
[14:10] <cachio> mvo, right I need to push to stable the other arches
[14:10] <cachio> I'll do it now
[14:10] <mvo> cachio: thank you
[14:17] <ijohnson[m]> cachio: yeah can't say I know more than zyga-mbp on that one, I have seen it but I would need to dig in and have other things to look at at the moment unfortunately
[14:17] <cachio> ijohnson[m], np, I'll try to fix it 
[14:23] <ijohnson[m]> mardy: how goes adjusting the quota group bits to check for disabled services? I'm updating one of my prs which conflicts with master now and it would be easy for me to fix that if you haven't already done so
[14:23] <ijohnson[m]> that's in https://github.com/snapcore/snapd/pull/10410 btw
[14:28] <mardy> ijohnson[m]: https://github.com/snapcore/snapd/pull/10430
[14:28] <mardy> (sorry, I saw your message just now)
[14:28] <ijohnson[m]> mardy: no worries let me review that now
[15:22]  * cachio lunch
[15:50] <pedronis> ijohnson[m]: should I remove quotaCreateImpl in 10429, or should we do it in a follow up?
[15:51] <ijohnson[m]> pedronis: probably fine to do in a followup
[15:52] <ijohnson[m]> pedronis: we have a bit of a problem that too many PR's are changing the same bits of code all at once so it's hard to land things without creating conflicts but oh well
[15:54] <pedronis> ijohnson[m]: what do you want me to do? can I help with this somehow?
[15:55] <ijohnson[m]> not sure tbh, but I think the problem should go down a bit now that mardy 's PR has landed, the next one though will have conflicts: https://github.com/snapcore/snapd/pull/10430 however
[15:57] <pedronis> ijohnson[m]: what's your preference, should we land that first or 10346
[15:58] <ijohnson[m]> pedronis: did you mean 10340 ?
[15:58] <ijohnson[m]> uh
[15:59] <ijohnson[m]> well in any case I would like to see mardy 's PR here landed first https://github.com/snapcore/snapd/pull/10430
[15:59] <ijohnson[m]> then I think your PR with servicestatetest / internal stuff can go in, then the next one after those is https://github.com/snapcore/snapd/pull/10410, but that doesn't have any reviews yet
[16:00] <ijohnson[m]> ah wait no, 10346 is a thing
[16:00] <ijohnson[m]> 🤦‍♂️ ok, let me just make a pastebin with the right ordering I think
[16:00] <pedronis> ijohnson[m]: no, I really meant https://github.com/snapcore/snapd/pull/10346
[16:01] <pedronis> 10340 is old and merged
[16:02] <ijohnson[m]> yeah sorry I got confused
[16:02] <ijohnson[m]> this is the order I think I would prefer: https://pastebin.ubuntu.com/p/rKKgK2mJZ6/
[16:03] <pedronis> ok
[16:03] <pedronis> ijohnson[m]: what about https://github.com/snapcore/snapd/pull/10425?
[16:04] <pedronis> ijohnson[m]: btw do you have a moment to chat what is left to do in this area?
[16:05] <ijohnson[m]> pedronis: I asked mvo to setup a meeting on monday to discuss, I think it would be best if all 3 of us were there, does the timeslot on Monday after SU work for you?
[16:05] <pedronis> yes, but I don't think it works for me, well it depends I suppose what we mean by after, there's pi-dtb meeting
[16:06] <pedronis> sorry
[16:06] <pedronis> for mvo
[16:06] <ijohnson[m]> pedronis: it should be 4 PM your time if I am doing the timezone math correctly, mvo already blocked off the time for 1-1 with me
[16:07] <ijohnson[m]> pedronis: also regarding 10425, my hope is that doesn't conflict with anything else open right now, though I suppose it may conflict with 10346 sadly
[16:08] <pedronis> yes, after as in 4pm should work
[16:10] <ijohnson[m]> cool
[16:12] <pedronis> hopefully we can land a few of these still today and a few Monday morning
[16:12] <pedronis> (my morning)
[16:12] <ijohnson[m]> yeah agreed
[16:13] <ijohnson[m]> my personal hopes are for 10430 and 10346 to be landed today
[17:01] <ijohnson[m]> 10430 is ready to land now, all green
[17:15] <pedronis> ijohnson[m]: landed, no obvious conflicts with https://github.com/snapcore/snapd/pull/10346
[17:29] <ijohnson[m]> pedronis nice thank you, it looks like the spread tests there are almost all happy too, just waiting on a couple ubuntus it seems 
[18:33] <pedronis> ijohnson[m]: I merged 10346 and updated https://github.com/snapcore/snapd/pull/10429
[18:41] <ijohnson[m]> pedronis: great thanks so much for this
[21:21]  * ijohnson[m] EOWs
=== mwhudson_ is now known as mwhudson