[06:02] <mborzecki> morning
[06:04] <mardy> mborzecki: hi!
[06:04] <mborzecki> mardy: heya
[06:12] <pstolowski> morning
[06:15] <mardy> pstolowski: hi!
[06:17] <mborzecki> pstolowski: and hey
[06:23] <pstolowski> mborzecki: do you have a moment for 2nd review of https://github.com/snapcore/snapd/pull/10539 ?
[06:23] <mborzecki> pstolowski: will do, i have it open already
[06:23] <pstolowski> ty
[07:12] <mborzecki> https://github.com/snapcore/snapd/pull/10542 is simple and needs a 2nd review
[07:29] <mardy> mborzecki: added a +1, but mine is just a formal review
[07:32] <zyga> good morning :)
[07:46] <mborzecki> zyga: hey
[07:50] <mardy> zyga: hi!
[07:50] <zyga> hey mardy :)
[08:27] <mardy> uh... I'm getting the unit tests to hang in my branch stuck for 10 minutes in TestHappyOrthogonalRefreshAutoAliases. Any ideas of what could be wrong? https://paste.ubuntu.com/p/VQrNm8GjJJ/
[08:33] <pstolowski> mardy: hard to say, when this happens to me I usually add a loop to print all tasks (kind + status) right before assert around settle
[08:35] <zyga-mbp> mardy usually deadlock
[08:35] <zyga-mbp> or state waiting forever
[08:35] <pstolowski> ah, but this doesn't return from settle
[08:35] <zyga-mbp> right
[08:35] <pstolowski> so yeah, something is probably holding the lock so Wait() deadlocks
[08:39] <mborzecki> pstolowski: mardy hm i just directly add a couple of printfs in taskrunner before the handler runs
[08:49] <mardy> ok, let's go back to a more basic question :-) How do I run a single test? I tried `go test -v -run TestHappyOrthogonalRefreshAutoAliases ./overlord/` but it doesn't find any tests to run
[08:49] <pstolowski> mardy: go test -check.f <partial name>
[08:50] <mardy> pstolowski: aahhhh, thanks :-)
[08:50] <zyga-mbp> it took me a while to query check command line options
[08:50] <zyga-mbp> mardy note that check and testing are separate beasts
[08:51] <zyga-mbp> mardy testing sees one test
[08:51] <zyga-mbp> check has internal structure
[08:51] <zyga-mbp> it's a bit annoying at times
[08:51] <zyga-mbp> I could be wrong but my attempts to use testing specific features didn't work
[08:53] <mardy> mines either: $ go test -v -check.f TestHappyOrthogonalRefreshAutoAliases ./overlord/
[08:53] <mardy> can't load package: package github.com/snapcore/snapd: no Go files in /home/mardy/go/src/github.com/snapcore/snapd
[08:55] <pstolowski> grrr, power outages today
[08:58] <mardy> pstolowski: you probably missed my last question then: if I add the -check.f parameter, then it doesn't find the packages to test anymore:
[08:58] <mardy> $ go test -v -check.f TestHappyOrthogonalRefreshAutoAliases ./overlord/
[08:58] <mardy> can't load package: package github.com/snapcore/snapd: no Go files in /home/mardy/go/src/github.com/snapcore/snapd
[08:58] <pstolowski> mardy: run it from the actual subdirecotry
[08:58] <zyga-mbp> pstolowski oh?
[08:58] <zyga-mbp> pstolowski more storms?
[08:58] <zyga-mbp> mardy yeah
[08:59] <mardy> pstolowski: wow, so easy, yet so hidden :-)
[08:59] <zyga-mbp> mardy it looks like a bug in check
[08:59] <zyga-mbp> I ran into that lately a lot
[08:59] <pstolowski> zyga-mbp: not storms right now, might be just some maintenance work
[08:59] <pstolowski> *no storms
[09:00] <mardy> zyga-mbp: yes, I guess it can't be a design decision
[09:11] <mardy> pstolowski_: mmm... actually, the fault is not only in my branch: that test times out even in the master branch, in my machine
[09:12] <zyga-mbp> mardy which directory? overlord?
[09:12] <pstolowski_> mardy: checking
[09:12] <mardy> zyga-mbp: yep
[09:12] <pstolowski_> mardy: passes here
[09:12] <zyga-mbp> I bet missing dependency
[09:12] <mardy> zyga-mbp: I run `go test -check.f HappyOrthogonalRefreshAutoAliases -v .`
[09:12] <pstolowski_> wot
[09:12] <zyga-mbp> it relies on squashfstools
[09:13] <zyga-mbp> trying
[09:13] <mardy> let me check...
[09:13] <zyga-mbp> wait
[09:13] <zyga-mbp> I mean, give me a sec
[09:14] <zyga-mbp> I need older go
[09:14] <zyga-mbp> I use 1.17
[09:14] <mardy> I do have squashfs-tools installed, do I need squashfs-tools-ng?
[09:15] <zyga-mbp> apt-get build-dep .
[09:15] <zyga-mbp> this will give you the right list
[09:15] <zyga-mbp> testing overlord with go 1.10
[09:15] <zyga-mbp> btw, what does mardy and pstolowski_ use for go version?
[09:15] <mardy> nope, seems like I have all the needed deps
[09:15] <zyga-mbp> ...
[09:15] <pstolowski_> 1.13.8
[09:15] <zyga-mbp> (it's sure taking a long time)
[09:16] <zyga-mbp> passed
[09:16] <zyga-mbp> on 1.10
[09:16] <mardy> go version go1.13.8 linux/amd64
[09:16] <pstolowski_> yes it's slow for all tests in overlord
[09:17] <zyga-mbp> trying 1.13
[09:17] <zyga-mbp> mardy what sort of machine do you have? I'm doing this on a 8 core laptop
[09:17] <zyga-mbp> maybe it's just slow
[09:18] <zyga-mbp> 32 seconds on 1st run on go 1.13
[09:18] <pstolowski_> just HappyOrthogonalRefreshAutoAliases is relatively fast
[09:23] <mardy> zyga-mbp: it's an intel i5 from... uh... 2011 I think :-) I upgraded it to 8GB of RAM a couple of years ago
[09:23] <zyga-mbp> mardy do you have a hdd there?
[09:23] <zyga-mbp> could be that IO is just slow
[09:25] <mardy> zyga-mbp: mmm... no, it's an SSD, but in the background I'm creating a copy of an external 1TB drive into another 1TB drive; I wonder if this has an impact...
[09:25] <mardy> ops on my root partition seem to be fast, though
[09:27] <zyga-mbp> mardy no idea though
[09:27] <zyga-mbp> are you swapping?
[09:27] <zyga-mbp> 8GB is a bit thin
[09:30] <pstolowski> these tests have 45s timeout for Settle though
[09:30] <pstolowski> should be more than enough ;)
[09:31] <pstolowski> mardy: ah, i missed what you said about 1TB copy op in the background... yeah, maybe
[09:31] <mardy> let's see how CI goes then :-)
[13:40] <mardy> pstolowski, ijohnson[m]: so, the issue with "snapctl start" happens because, unless --enable is given, I build a list of the snap's disabled services and I pass that to wrappers.StartServices()
[13:40] <mardy> I've verified that if I set this to nil, then everything works
[13:40] <mardy> when building this list I do exclude those snaps explicitly mentioned in the command line, but this does not seem to be enough
[13:41] <mardy> (indeed, the explicitly mentioned services are not part of the disabledServices list)
[13:42] <mardy> but I guess that some of these disabled services are a dependency for the explicitly requested one?
[13:43] <mardy> we do not track service dependencies, AFAIK
[13:45] <ijohnson[m]> mardy: I don't think dependencies have anything to do with it
[13:45] <ijohnson[m]> mardy: pstolowski I wrote a simple reproducer test expanding our current existing spread test
[13:47] <mardy> ijohnson[m]: can you push it somewhere?
[13:48] <mardy> ijohnson[m]: I guess that some of those units which I'm not starting are sockets needed by the requested snap
[13:48] <ijohnson[m]> mardy: sorry I thought I linked it here but I forgot to paste it https://github.com/snapcore/snapd/pull/10548
[13:49] <pstolowski> ijohnson[m]: ah, so existing test didn't pass --enable, that's why it was happy
[13:49] <ijohnson[m]> yes
[13:54] <mardy> pstolowski: it's actually the opposite: the test *did* pass --enable, that's why it was happy :-)
[13:55] <pstolowski> mardy: yes you're right
[13:58] <ijohnson[m]> uh sorry my test modification as proposed isn't working, let me fix it
[14:00] <pstolowski> mardy: anyway, the if !enable {... case is most likely the culprit but it's not clear to me how, needs some printf debugging
[14:07] <mardy> ouch
[14:08] <mardy> explicit service is "snap.edgexfoundry.postgres.service", but the string being compared to it is "edgexfoundry.postgres"
[14:08] <mardy> I think I saw some patch from Samuele addressing snap service names
[14:11] <ijohnson[m]> mardy: pstolowski ok, the test if fixed now, it fails as expected :-)
[14:11] <pstolowski> ijohnson[m]: thanks a lot for it and for finding the regression!
[14:35] <mardy> ijohnson[m], pstolowski: this works for the edgexfoundry snap, now I'll try to pull the spread test and see how it goes with that: https://github.com/snapcore/snapd/pull/10549
[14:41] <pstolowski> mardy: we didn't have a unit test for !enable or was it using incorrect input names?
[14:44] <mardy> pstolowski: don't remember, but maybe it was receiving the proper names, being that they are mocked
[14:58] <mardy> ijohnson[m]: yep, your test passes with my changes
[14:59] <ijohnson[m]> mardy: \o/ nice thanks for looking into this so quickly
[15:05] <pstolowski> awesome
[16:14]  * cachio lunch
[20:28]  * cachio afk