[05:14] <mborzecki> morning
[05:38] <mardy> mborzecki: hi!
[05:39] <mborzecki> mardy: heya
[05:55] <mardy> I see that there are two patterns for registering an interface: one is to initialize all params in the constructor, the other is to provide them to StaticInfo(). Which one is preferred? Or what is the difference?
[06:02] <mborzecki> hmm let me see
[06:06] <mborzecki> mardy: not quite sure, registerIface seems more concise I guess
[06:06] <mborzecki> also with commonInterface the hard bits are already handled
[07:01] <mborzecki> mvo: hi, can you take a look at https://github.com/snapcore/snapd/pull/10477 ?
[07:03] <pstolowski> morning
[07:04] <mvo> good morning mborzecki and pstolowski 
[07:04] <mvo> mborzecki: sure
[07:08] <mborzecki> pstolowski: hey
[07:09] <mborzecki> funny error i noticed in the lxd-mount-units test: `Error: Create restart (for start) operation: Instance is busy running a stop operation` that's when the test issues lxd.lxc restart ubuntu
[07:10] <pedronis> mvo: pstolowski: hi, did one of view restart tests in https://github.com/snapcore/snapd/pull/10475 ?
[07:10] <pedronis> *one of you
[07:12] <pstolowski> pedronis: i did, were you investigating something?
[07:13] <pedronis> pstolowski: no, but I did already a couple of runs and was about to merge it
[07:13] <pstolowski> pedronis: ah, ok, sorry
[07:13] <pedronis> I doubt it will turn green but who knows
[07:16] <mborzecki> pstolowski: trivial comment: https://github.com/snapcore/snapd/pull/10478#pullrequestreview-696900150
[07:21] <pstolowski> thx
[07:21] <mborzecki> mvo: i've added a TODO about /usr/etc/ssh in https://github.com/snapcore/snapd/pull/10474 i think we should leave it as it is now, and see if it actually breaks anyone
[07:22] <mvo> mborzecki: +1
[07:24] <pedronis> mborzecki: strange failures in https://github.com/snapcore/snapd/pull/10477/checks?check_run_id=2959970557
[07:25] <mborzecki> pedronis: heh that wget download log
[07:28] <mborzecki> hm not quit related, but it's also one of the only prs that ran with nested recently, let me try to run it manually
[07:53] <mborzecki> testing the fix for the preseed test, i'll open a PR in a bit
[07:54] <mborzecki> cloud images ship with core20 now, but the test snap we use (test-postgres-system-usernames) uses core18 still, we should probably rebuild it once ian is back
[08:11] <zyga-mbp> good morning 
[09:04] <pstolowski> hey zyga-mbp 
[09:33] <pstolowski> pedronis: which of your PRs need to be reviewed first?
[10:10] <pedronis> pstolowski: https://github.com/snapcore/snapd/pull/10420 needs a review and then https://github.com/snapcore/snapd/pull/10471
[10:11] <pstolowski> pedronis: ack
[10:56] <pstolowski> +1, would be great to land 10420 first and rebaes
[10:56] <pstolowski> *rebase
[11:04] <pedronis> pstolowski: I pushed tests as well: https://github.com/snapcore/snapd/pull/10420/commits/27276da13d65b051ab0b0fb2bef0f52b65bab023
[11:07] <pstolowski> pedronis: thank you, they lgtm
[11:09] <mborzecki> mvo: can you land this? https://github.com/snapcore/snapd/pull/10477
[11:16] <pedronis> mborzecki: I don't know if it's related to the v2 changes but I'm seeing intermitted freezing error on debian sid now: https://github.com/snapcore/snapd/pull/10468/checks?check_run_id=2960953222 could you look?
[11:17] <mborzecki> pedronis: sure, will do
[11:24] <mardy> quick question: do we have a method to convert an array of strings into a single string "one,two,three"?
[11:25] <pstolowski> mardy: strings.Join(array, ",")
[11:27] <mardy> pstolowski: dziękuję bardzo
[11:28] <pstolowski> yw :)
[11:30] <pstolowski> go can sometimes surprise with its standard library. that is, until you want to drop something from a list etc ;)
[11:32] <mborzecki> pedronis: i've opened https://github.com/snapcore/snapd/pull/10481
[11:47] <pedronis> mborzecki: couple of questions
[11:49] <mborzecki> pedronis: thanks, let me see
[12:18] <pstolowski> pedronis: do we want to support snapctl refresh --available (from the snap) in the first iteration?
[12:20] <pstolowski> cachio_: hi, can you take a look at https://github.com/snapcore/snapd/pull/10476 ?
[12:20] <cachio_> pstolowski, sure
[12:56] <pstolowski> cachio_: thanks for the review. i'm a bit unclear about the remark re snapcraft.yaml; is there a problem with snap.yaml & snap pack, followed by snapcraft upload (it's all manual anyway)>
[12:56] <pstolowski> ?
[13:37] <pedronis> pstolowski: mvo: I just squash-merged https://github.com/snapcore/snapd/pull/10468 , maybe we want to cherry-pick it
[13:40] <mvo> pedronis: will do
[13:46] <pstolowski> ty
[14:04] <mborzecki> so far so good, s-u-n i happy again
[14:15] <pedronis> mborzecki: I reviewed https://github.com/snapcore/snapd/pull/10481
[14:17] <mborzecki> pedronis: thanks
[14:31] <pedronis> pstolowski: degville: I made a suggestion that seems reasonable and is shorter in https://github.com/snapcore/snapd/pull/10478
[14:35] <degville> pedronis: thanks - looks good with a small comment.
[14:35] <pstolowski> sounds good to me too
[14:39] <pedronis> pstolowski: it shouldn't be blocked on me anymore
[14:42] <pedronis> mvo: feel free to land https://github.com/snapcore/snapd/pull/10370 tomorrow if you get to re-review it, we'll continue with the rest on monday
[14:42] <pstolowski> pedronis: thanks
[14:46] <mvo> pedronis: looking now
[14:53] <pedronis> mvo: thx, I will rebase the next one
[14:56] <pstolowski> pedronis: do we want 'snapctl refresh --proceed' from snap to trigger auto-refresh ASAP, or am I misreading the sentence from the spec: "Would this cover the case when a snap wants to decide when its refresh should happen"
[14:57] <pedronis> pstolowski: it should but it might be blocked by something else though
[14:57] <pstolowski> pedronis: blocked as "held"?
[14:58] <pedronis> pstolowski: yes, the snap requesting might be in principle held by something else
[14:58] <pstolowski> yep
[14:59] <pedronis> mvo: fyi, I rebased the next one https://github.com/snapcore/snapd/pull/10371
[14:59] <pstolowski> pedronis: one complication I just realized is that in this case --proceed also should mean the intent rather then immediate update of hold state as otherwise this would allow the snap to play the game of pushing hold time limit (again). this probably means a flag on holdInfo after all
[15:00] <pedronis> pstolowski: yes, it might get complicated, the sematincs are vaguer but easier inside the hook
[15:17] <mardy_2nd> I'ma bit confused: when should I implement SystemdConnectedPlug and when SystemdConnectedSlot?
[15:18] <mardy_2nd> I guess both are invoked when an interface gets connected, right?
[15:22] <pedronis> mardy_2nd: only if you are creating services on behalf on the interface
[15:22] <pedronis> which I don't think is something we need here
[15:25] <mardy_2nd> pedronis: I think I will create a mount unit, to handle persistent mounts
[15:25] <pedronis> mardy_2nd: as we said the interface doesn't create mounts immediately, we will mediate that via snapctl
[15:26] <pedronis> so those bits are not relevant I think
[15:28] <mardy_2nd> pedronis: mmm... the doc explicitly says "Persistent mounts will be supported by generating systemd mount units"
[15:28] <pedronis> mardy_2nd: the document is confusing then
[15:34] <mardy_2nd> pedronis: but if you don't use systemd mount units, how can you implement persistent mounts?
[15:36] <pstolowski> mborzecki: can you take another look at https://github.com/snapcore/snapd/pull/10478 ?
[15:59]  * cachio_ afk
[15:59] <cachio_> lunch
[16:22] <ijohnson[m]> pedronis: if you are interested, I left a couple little comments in the quota PR most recently landed: https://github.com/snapcore/snapd/pull/10458#pullrequestreview-697435122
[16:22] <ijohnson[m]> I'm taking a look at the open ones now
[16:53] <pedronis> ijohnson[m]: seems things you could apply in one of the follow ups
[16:58] <ijohnson[m]> pedronis: sure sounds good, do you have another PR for exposing the conflicts in the API like you mentioned in the last PR?
[18:04] <pedronis> ijohnson[m]: no, that bit is still missing
[19:31] <ijohnson[m]> pedronis: ack
[19:37] <pedronis> ijohnson[m]: the SetStatus fix took a bit including getting the needed reviews
[19:38] <ijohnson[m]> no worries