[05:06] <mborzecki> morning
[06:08] <pstolowski> morning
[06:41] <zyga> good morning
[06:43] <mborzecki> pstolowski: zyga: hey
[06:45] <zyga> happy Friday guys :)
[06:46] <mvo> happy friday zyga 
[07:07] <mvo> pstolowski: good morning and thanks for your review for 10514!
[07:07] <pstolowski> mvo: hey, yw!
[07:35] <mborzecki> heh, i have so many tabs open that i can't find the ones with half done reviews
[07:35] <mborzecki> and the other half is about bpf :/
[07:35] <mvo> mborzecki: haha and good morning!
[07:35] <mborzecki> mvo: hey
[07:49]  * pstolowski physio
[08:53] <pstolowski> re
[10:40] <ijohnson[m]> morning folks
[10:42] <pstolowski> hej ijohnson[m] 
[10:42] <ijohnson[m]> o/
[10:42] <ijohnson[m]> mvo: pedronis: can y'all sudo land https://github.com/snapcore/snapd/pull/10437 ? 
[10:44] <pedronis> ijohnson[m]: done
[10:44] <ijohnson[m]> \o/ yay thanks pedronis 
[10:54] <pstolowski> heh, --proceed outside of hooks is more surprising than i originally thought, i had 3 ohhhh...a-ha! moments already. fun
[11:11] <pstolowski> and it's here https://github.com/snapcore/snapd/pull/10515
[11:14] <mardy> hi!
[11:14] <ijohnson[m]> hey mardy 
[11:17] <mardy> ijohnson[m]: FYI: https://github.com/snapcore/snapcraft/pull/3545
[11:18] <ijohnson[m]> mardy: nice looks good! You might want to mention in that PR the PR which added support to snapd and what major version number we expect to see snap_microk8s support released in
[11:27] <mardy> ijohnson[m]: which is... 2.52?
[11:28] <ijohnson[m]> mardy: mmm yes I think so, 2.52 hasn't been branched yet
[11:33] <ijohnson[m]> it seems that refresh-delta fails pretty much 100% of the time on amazon-linux2 and centos-7, which is weird if the store was returning incorrect data, wouldn't it return it for all systems?
[11:47] <pedronis> ijohnson[m]: maybe it's an issue with the log searching instead?  fwiw they say they don't support --sync
[11:47] <pedronis> not sure why/what would have changed though
[11:47] <pedronis> recently
[11:47] <ijohnson[m]> ohhh good point tbh I didn't read the failures I just assumed it was related
[11:47]  * ijohnson[m] goes to actually read the failures
[11:51] <ijohnson[m]> pedronis: no it is actually failing to apply the delta: https://pastebin.ubuntu.com/p/j3yjkNX2Mf/
[11:51] <ijohnson[m]> well it says "failed to remove partial delta target", not sure exactly what that means
[11:52] <pedronis> it sounds weird,  anyway other option is the version of xdelta ?
[11:52] <ijohnson[m]> yeah could be maybe
[11:54] <pedronis> but it's also weird because it doesn't seem to happen all the times, no?
[11:54] <ijohnson[m]> it seems to happen all the time on prs I want to land :-(
[11:55] <pedronis> maybe it is happening all the time, anyway next thing to check would be to check xdelta3 version and run the xdelta3 manually I suppose
[11:55] <pedronis> on those two, and for comparison on one of the passing ones
[11:55] <ijohnson[m]> yes, I can take a look this afternoon at it
[11:56] <ijohnson[m]> pedronis: in other news, the failures on https://github.com/snapcore/snapd/pull/10165 are unrelated, can you land it? I made the change you suggested
[11:56] <pedronis> ijohnson[m]: will do, thx
[11:57] <ijohnson[m]> there was an errant failure of the uc20-recovery test after I made that change, but it was just when it didn't come back after the reboot and it went away after a retry so I don't think it's related to the systemctl chmod change I made
[12:00] <pedronis> I suppose, it's the issue that pinning the hardware better would solve I suppose that sergio mentioned a long while ago? but needs no spread option keys
[12:00] <pedronis> s/no spread/new spread/
[12:01] <ijohnson[m]> maybe, I'm not sure anyone has deep dived into why sometimes uc20 doesn't come back after a reboot in gce since you need serial access which only sergio has afair
[12:01]  * ijohnson[m] quick break
[12:05] <pedronis> pstolowski: I didn't really review it yet, but I noticed the TODO in description: https://github.com/snapcore/snapd/pull/10515#issuecomment-877136959
[12:08] <pstolowski> pedronis: ah, ok, i misremembered, thanks
[12:49] <pedronis> ijohnson[m]: you planned to re-review https://github.com/snapcore/snapd/pull/10438, correct? I gave a +1 but did not look at tests
[13:36] <ijohnson[m]> pedronis: yes I will re-review it today
[13:36] <pedronis> thx
[13:43] <mborzecki> heh, 3rd thunderstorm today
[13:45] <ijohnson[m]> should send some of those over here, we could use the extra rain
[13:57] <ijohnson[m]> degville: re the gpio unexport, indeed upon disconnection when this service is stopped (the systemd backend for interfaces will start the service mentioned here and stop it when it is disconnected) which triggers an unexport: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/gpio.go#L119
[13:58] <degville> ijohnson[m]: that's fantastic - thanks so much!
[14:02] <ijohnson[m]> np
[14:18] <ijohnson[m]> mardy: pedronis re-reviewed the snap start PR, lgtm
[15:30] <mardy>  \o/
[15:38] <zyga-mbp> futuretim in which sense?
[16:13] <futuretim> zyga-mbp: there are clearly a lot of "behind the scenes" things that happen that are not specified in APIs.. like perhaps closed APIs and/or closed UIs.
[16:15] <futuretim> even API docs for things that aren't for public consumption would be awesome. :)
[16:15] <futuretim> seems unlikely but no is definitely the answer if you don't ask!
[16:17] <zyga-mbp> futuretim: I don't know of any documentation for the store APIs
[16:17] <zyga-mbp> your best bet is snapcraft and snapd source code
[16:18] <futuretim> zyga-mbp: well these are things that wouldn't be covered by open source, trust me I've used those extensively!
[16:18] <zyga-mbp> futuretim ?
[16:18] <zyga-mbp> what kind of APIs are you talking about then
[16:19] <futuretim> like if I make someone a collaborator on a snap, what happens in the store to make that happen, i don't think I can discover that in source code
[16:20] <futuretim> there are many, many things.. need to reboot, brb
[23:00] <futuretim> what does it mean in snapd's REST API for system-info "managed: true if able to manage user accounts (?)."
[23:02] <futuretim> this is in the context of console_conf, so it's possible that is running where users aren't being managed by snapd?
[23:04] <futuretim> and I guess every core has its own build of snap?
[23:35] <ijohnson[m]> futuretim im already EOW but ask on Monday and I can explain 
[23:35] <futuretim> ijohnson[m]: thanks, if I still have the question Monday I'll let you know, thanks1
[23:37]  * ijohnson[m] forgot to unlunch himself