The following tests FAILED: 6 - check_missing_rpc_methods (Failed)Errors while running CTestmake[1]: *** [Makefile:149: test] Error 8make[1]: Leaving directory '/usr/local/src/monero/build/Linux/release-v0.17/release'make: *** [Makefile:99: release-test] Error 2

make release-test

Which RPC ? It'll be in LastTest.log in build/...

(grep for check_missing_rpc_methods)

6/21 Testing: check_missing_rpc_methods6/21 Test: check_missing_rpc_methodsCommand: "/usr/bin/python" "/usr/local/src/monero/tests/functional_tests/check_missing_rpc_methods.py" "/usr/local/src/monero""check_missing_rpc_methods" start time: Dec 16 16:22 PST File "/usr/local/src/monero/tests/functional_tests/check_missing_rpc_methods.py", line 16,

in <module>"check_missing_rpc_methods" end time: Dec 16 16:22 PST"check_missing_rpc_methods" time elapsed: 00:00:00

Works for me, master and branch.

yep selsta , even with out of 12, i still get the same problem

~100 rpc connections, monerod can't add more rpc connections

or its being griefed somehow

gingeropolous: i linked an github issue some weeks ago

afaik it had a workaround but I don't find it

will look in logs later

gingeropolous: monero-project/monero #6262#issuecomment-674382742

Hello!

I want to ask a question and I've posted it on Reddit. Is it okay if I link it here?

All you are fighting for is e-penis of a guy you never met, that doesn't even have common decency to pay you for your time.

Do you think they care about Monero, or privacy or anything other than money?

monero-project/monero #7160 Ready for review, if you care about a quick and dirty solution for cutting the compilation time by at least 70%

Would using this impact deterministic builds in any way?

needmoney90 if I understand your question correctly, it only affects your local builds. It is enabled only by setting USE_ICECC=ON, and the only 2 (new) targets, that do it are release/debug-all-icecc

Because Deterministic builds is the CI, no?

If yes, then these 2 new targets are not being called by the CI.

sech1: could you take a look / review 7154 ?

tobtoht_: did you have any luck with the busy RPC PR?

selsta: got sidetracked. I have time in a bit to look into it further

great

selsta, thanks for link. im trying that hack.

selsta I tried, and I Can't understand how 7154 works now :D

We expect a block hash we have (where a new chain is grafted) and a set of new block hashes that make up the new chain portion.

I'm actually not sure whether it's kosher to get anything below what we expect...

context.m_expect_height - 1 is the block we have, right?

Anyway, if you get something below, the hashes should not be hte same, or it'd graft higher.

Yes.

I have no more questions :)

sech1: thanks

moneromooo: 7157 requires minor rpc bump

done

.merges

Hmm. Shittily though. We get 3.3 for branch and 3.4 for master. That makes it useless :/

would setting both to 3.5 work

Deterministic unlock time stuff. No, it would not.

Since 3.5 would mean it has both, but the branch does not have the Deterministic unlock time stuff.

No good solution beyond massive amounts of bitfields.

hmm, deterministic unlock time should be in release too

wasn’t it part of v0.17 hard fork?

Oh it is, sorry. Skipped a patch.

A synchronized field.

yep, someone asked for this

Yes, that one.

It's tiny. Maybe add it to the branch first :)

xiphon: can your PR 7030 to branch too?

moneromooo: then you can set it to 4

#monero-policy

Whoops

Typo. It's police.

.merge+ 7161

Added

luigi1111w: please also merge 7161 so that we can avoid merge conflict

I'm not merging a 2hr old pr

I can merge it first though

It has been merged to master a while ago so not really new

merging 7156 7157 would be the alternative

luigi1111w: yep, merging 7156 7167 would be even better instead of 7161

ok

how does this work wallet_api wise when connecting to a node that does not support is_busy_syncing?