bump go daemon tag version

[sinkingsugar]

includes lastest changes, and latest noise

[sinkingsugar]

@stefantalpalaru would you mind checking that win 32 job at least .. it's a weird failure , stops at the p2p build script...
Cheers

[sinkingsugar]

@stefantalpalaru another thing sorry.. I fail to make it work actually.. passing the version didn't do anything, is it cache related ( see travis )?

[stefantalpalaru]

The Azure cache is not invalidated automatically. You need to manually change the cache key, for both the Nim compiler and p2pd.

The Travis problem doesn't seem cache-related.

[sinkingsugar]

The Azure cache is not invalidated automatically. You need to manually change the cache key, for both the Nim compiler and p2pd.

Thanks I see.

The Travis problem doesn't seem cache-related.

It's definitely printing the old p2pd help so it seems to me that is cache related too

[stefantalpalaru]

It's definitely printing the old p2pd help so it seems to me that is cache related too

You're right. I need to port "build_p2pd.sh" from the old binary-mtime-based system to the separate timestamp file we use in "build_nim.sh". Just a moment.

[dryajov]

is this the reason why https://dev.azure.com/nimbus-dev/nim-libp2p/_build/results?buildId=5171&view=logs&jobId=acd3af84-cc40-59fe-7fed-5ff2cf665cc2&j=acd3af84-cc40-59fe-7fed-5ff2cf665cc2&t=ef53e5c4-942b-5bd0-ca0f-68c11fbf8308 is failing?

[stefantalpalaru]

Yes. Hang on while I'm debugging it.

[stefantalpalaru]

It's a problem with Go-1.12: libp2p/go-libp2p-daemon#212

[sinkingsugar]

Oh wow, didn't realize it was so convoluted. Thanks @stefantalpalaru

[sinkingsugar]

I migrated my own projects to use GitHub actions and never regret about it to be honest.
Keeping track of the quirks and workarounds of all the other providers was taking too much time I don't have !

[stefantalpalaru]

I squashed all my commits and any CI failure you may see is not our fault, so this PR is ready for merging.

Important points: the latest p2pd version does not build with Go-1.12 nor does it build on 32-bit any more.

I saw a different p2pd cache key in another PR. Make sure it doesn't overwrite this one.

I migrated my own projects to use GitHub actions

What are the chances it uses the same underlying infrastructure as Azure Pipelines?

[stefantalpalaru]

I saw this Travis error appearing sometimes on Azure. A matter of timing?

   /home/travis/gopath/src/github.com/status-im/nim-libp2p/tests/pubsub/testfloodsub.nim(42, 31): Check failed: tracker.isLeaked() == false

    tracker.isLeaked() was true

    false was false

  [FAILED] FloodSub multiple peers, no self trigger

[sinkingsugar]

I saw this Travis error appearing sometimes on Azure. A matter of timing?

   /home/travis/gopath/src/github.com/status-im/nim-libp2p/tests/pubsub/testfloodsub.nim(42, 31): Check failed: tracker.isLeaked() == false

    tracker.isLeaked() was true

    false was false

  [FAILED] FloodSub multiple peers, no self trigger

yeah indeed, often on macos too cos probably it's nested virtualization...

[sinkingsugar]

Thank you for azure btw @stefantalpalaru !

[sinkingsugar]

It's weird tho, the timing issues I didn't have with pubsub before tho.. now this one too:
https://travis-ci.org/github/status-im/nim-libp2p/jobs/699921676#L666

[dryajov]

Quite possible, hard to tell from the snippet, but I haven't seen it break there in a while.

[sinkingsugar]

btw I'm closing this PR and move it (merging it) into #226
Since it's complementary!

[sinkingsugar]

Quite possible, hard to tell from the snippet, but I haven't seen it break there in a while.

@dryajov
Well it means that await switch.stop() is not enough to await all the possible closures and so it triggers leak check... possibly eventually there will be no leaks.
When I fixed those tests that was the hard work, making sure all was closed.. maybe something is sneaking out again :)

I really would try to avoid adding sleeps or so and rather have systematical knowledge that we close all.