[06:05] <mborzecki> morning
[06:18] <mardy> 'morning!
[06:26] <mborzecki> mardy: hey
[06:51] <mborzecki> hmm i have surprisingly few prs open, time to fix that
[06:59] <mborzecki> mvo: hey
[07:03] <pstolowski> morning
[07:04] <mborzecki> pstolowski: hey
[07:09] <mvo> good morning mborzecki and pstolowski 
[07:10] <mborzecki> anything intersting happened during the long weekend or yesterday?
[07:33] <mborzecki> mvo: do you have more info from pedronis about the lxd issue mwhudson had on thursday?
[07:34] <mborzecki> there seems to have been some confusion about / not being shared and the tricks that we do to fix it
[07:49] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/10338 ?
[07:49] <pstolowski> mborzecki: sure
[07:50] <mborzecki> thanks!
[07:53] <mborzecki> quick errand, back in 30
[08:45] <mborzecki> re
[09:19] <pedronis> mborzecki: hi, you saw I commented on golangci-lint again, my worry about goimports is when our current gofmt and goimports will disagree on new code
[09:20] <pedronis> mborzecki: I also created this:  https://github.com/snapcore/snapd/pull/10345
[09:21] <mborzecki> pedronis: yes thanks, i'll be looking at this next, wanted to push out the tweaks to #10338
[09:22] <mborzecki> pedronis: as for gofmt, not sure what going on there, i suppose we can either ignore it or disable goimports, although it's quite useful even if there's some misdetection
[09:22] <pedronis> mborzecki: as I said we could switch to use it instead of gofmt ourselves, but we need to compile it like golangci-lint does
[09:30] <mborzecki> pedronis: tbh maybe there's anothe imports linter, bit unfortunate that goimports does the same as gofmt, otoh they do mention it
[09:32] <mborzecki> pedronis: fwiw, there's https://github.com/daixiang0/gci which doesn't try to do it all
[09:32] <pedronis> mborzecki: but then is not compiled into golangci-lint, no?
[09:33] <mborzecki> pedronis: it is
[09:33] <pedronis> confused :)
[09:35] <pedronis> I pushed anothe daemon refactor PR, this one is very small: https://github.com/snapcore/snapd/pull/10356
[09:38] <mborzecki> pedronis: look at the output at the bottom https://paste.ubuntu.com/p/VVQM9TSYkF/ almost ok, the line number seems to be n+1, but emacs highlights it correctly for some reason
[09:39] <mborzecki> that's with gci instead of goimports
[09:52] <mborzecki> pedronis: pushed out a change to use gci with a canary in the file that was flagged due to non-gofmt formatting to https://github.com/snapcore/snapd/pull/10082
[09:58] <pedronis> mborzecki: so in theory after this if we add to ignore the currently non-compliant testpackage files, we should be ok?
[09:59] <mborzecki> pedronis: yup, but let's see what the github run shows
[09:59] <pedronis> ok, almost lunch time here
[10:18] <mborzecki> nice, the note was added after github run finished
[10:35] <mardy> github avatars are currently broken, and possibly something else too: https://www.githubstatus.com/
[10:47] <mardy> time to switch to gitlab...
[10:48] <mardy> ...except that it's also affected: https://status.gitlab.com/
[10:48] <mardy> :-)
[10:51] <mborzecki> mvo: pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/10357 ?
[10:52] <mborzecki> afaict we're not locking the mutex again, once defers run there's an attempt to unlock it again
[10:52] <mborzecki> also a missing test case, i'll try to add one now
[11:09] <mborzecki> anyone recall whether there's a common way to inject backend errors in snapstate tests?
[11:38] <pedronis> mborzecki: it's not used a lot but SetSnapManagerBackend exists
[11:38] <pedronis> in export_test.go
[11:41] <mborzecki> pedronis: i've pushed a little hack in https://github.com/snapcore/snapd/pull/10357
[12:11] <mborzecki> pedronis: suggested a little comment tweak in https://github.com/snapcore/snapd/pull/10345 otherwise it looks good to me
[12:41] <mardy> any hints on how to debug a configure hook? I'd like to see its stderr and stdout
[12:42] <mborzecki> mvo: can you land https://github.com/snapcore/snapd/pull/10338 ?
[12:42] <mborzecki> mardy: hm the output should be collected in task log, `snap change <id>` ?
[12:43] <mvo> mborzecki: sure
[12:43] <mvo> mborzecki: done
[12:48] <mborzecki> mvo: thanks!
[12:58] <mardy> mborzecki: nope, that only shows that the hook was executed, but it does not show its output
[12:59] <ogra> mardy, it usually just goes to the journal ... but only if it exited nonzero ... else you have to use logger inside the hook to get output
[13:25] <mardy> ogra: ah, I see, thanks!
[13:50] <pstolowski> ijohnson: i updated #10290
[13:58] <ijohnson> pstolowski: thanks I'll have another look 
[14:04] <pstolowski> ijohnson: i hope my explanations make sense. btw i wouldn't necessarily go with hold/gating renaming right now because it would probably mandate changes in other places too (and this PR is close to land). I can propose a separate PR to unify the naming when the feature is close to completion
[14:06] <ijohnson> pstolowski: yeah that's fine to not rename things in the PR, I just meant it more as a general comment about the concept in general 
[14:10] <ijohnson> pedronis: I'm going to wait for your review before merging #10354 just FYI since there was confusion there before
[14:35] <pedronis> ijohnson: going to do some reviews now including your PRs, had quite a few meeetings so far
[14:35] <ijohnson> pedronis: no worries thanks for the reviews
[14:37] <ijohnson> pstolowski: thanks for the explanation I think it makes sense now, just one clarifying comment about how gating is organized 
[14:37] <ijohnson> but the PR has my +1 now
[14:42] <pstolowski> ijohnson: thanks!
[14:58] <pedronis> ijohnson: I did review a couple of PRs, the next one will need the prereq to land and a master merge then I will re-review it
[14:58] <ijohnson> pedronis: thanks looking now
[14:59] <pedronis> mborzecki: what's the status https://github.com/snapcore/snapd/pull/10241 ? did it ever get the change to apparmor cpu use merged into it?
[15:01] <pedronis> https://github.com/snapcore/snapd/pull/10345 needs 2nd reviews
[15:04] <ijohnson> pedronis: regarding conflicts, I was hoping to first land the task handlers and wire them up to be used, then after that to add the conflict checking code, is that okay?
[15:05] <ijohnson> otherwise 10347 will get big again
[15:14] <pedronis> ijohnson: yes
[15:14] <ijohnson> ok, thanks