I'm trying to build Monero following the github resources. My make command is failing due to external miniupnp submodule not up to date. I've tried to pull the sub directly from the github repo, but it wont work and my 'git submodule update --init --force' is failing due to the upload-pack not containing 'our ref'. I noticed there was a commit 6 days ago, could there be something missing there?

is the "1" in support flags listed in the print_cn output indicative of a public RPC node?

I haven't made it that far, still building it with make

oh sorry, i was just asking the room :)

Opps

Just new :(

welcome! oh regarding that thing PvtCaboose , try git submodule sync , then git submodule update

Look on the bright side. At least you don't need to obsess over signs of life from FUK now.

Thanks Gingeropolous, I did manage to get it to build, but I had to skip those submodules, nothing I was trying was working. I was able to make it now thankfully!

I usually clone with --recursive, not sure if that might help

I did do that as well, and did try the submodule update. It had a hash value that it didn't like when I was trying to 'make' I had to bypass with cmake -DMANUAL_SUBMODULE=1

moneromooo, how can I increase the log level for Unit Tests?

I see the logs being produced in the UT dir with INFO.

MONERO_LOGS=2 unit_tests

Great. Thx

I will let the test run for a couple of hours. It will end up with a detailed log for a successful run and one for a failed run.

It can't bind listening acceptor to 58080/48080 due to another socket in TIME_WAIT state with endpoints local(127.0.0.1:48080/58080), remote(127.0.0.1:5262)

it can be reproduced locally

I've just reproduced it as well and have all the logs.

I will take it up but will gladly ask questions.

nothing interesting in logs even with '*:TRACE'

there must be some edge case when

This is the first difference.

it's unrelated

I think that some prior test doesn't clean up in time or is not let to clean up. This is to say, that the failing test is not the cause of the problem, it only detects it.

* there must be some edge case when non listening socket in TIME_WAIT state blocks bind to the same port though it should not happen

It only happens if I run all the tests. If I filter out all others and run zmq*, bind* and node*, it doesn't happen.

*all the unit tests

wfaressuissia[m], I'd expect to see another service using 48080/58080, but I can't find any.

"paste.debian.net/hidden/2eccc559" that test can test node_server with 127.0.0.1 instead of 0.0.0.0, it removes the above failure

Interesting. Let's put it on the gramophone ...

"paste.debian.net/hidden/a1bbfa8b" 127.0.0.1 -> 127.0.0.2

"paste.debian.net/hidden/7a5ab8dc" or this one

but in any case the point is to use different IPs for endpoints of different tests

Still crashed after the first patch. Trying the other ones.

first with 127.0.0.1 ?

Yes

that's expecetd, that patch is deleted now

I get your argument about endpoints.

So if 0.2 works, we should focus on making other tests unique. Is this what what you're about?

Anyway. Running wuth 0.2

that's very specific edge cases since only 48080/58080 ports are being observed for sockets with TIME_WAIT state;

if you have a lot of time then try to reproduce this bind failure in isolated test and find the real reason

otherwise no need to replace IPs for other tests

Unfortunately 0.2 crashed.

crap sorry. It's a different test, that crashed...

How many iterations without failure of that node_server.* test ?

I didn't check that. It's just a while loop.

it was 300+ here

On GitHub it was 10% of chance.

"... It's just a while loop." add some counter

Are you running all the tests or just node_server.*?

In the latter case it never failed.

on my machine

not all, not only that one

I'm almost sure you won't repro it this way.

How many seconds per iteration in your case ?

"paste.debian.net/hidden/f2276ddb" 5 seconds with this filter

I need about 2 minutes.

But do you mean that you are able to reproduce with this filter?

and the above filter is sufficient to trigger that error without fix

Excellent. Will be useful in the future.

"--gtest_filter='test_epee_connection.test_lifetime:node_server.bind_same_p2p_port'" this filter is sufficient too

probably the smallest possible one

time to start deep diving :D if you have time

Quick fixing and deep diving are candidates for 2 separate PRs. For the quickfix I will write some comment written why 127.0.0.2, but that's it. Other problems are waiting as well :)

and quick fix is likely needed for both branches

reproduced on release-v0.17 branch too

True that

To be safe, I will try to reproduce the crash using your filter without the IP change.

It has been already reproduced few times

OK, same here. Great.

wfaressuissia[m], I'd like to add you to the credits of my PR. What's your GitHub handle?

"paste.debian.net/hidden/ea0956ec" wait, isolated reproduction in python

Cool.

Python tests go to functional_

Are you sure you want to mix one quick fix and a full blown isolation?

I'm searching the reason

From my experience already medium sized PRs are hard to be merged. Quick fix just work.

So one doesn't disturb another, I'd say.

"A TCP local socket address that has been bound is unavailable for some time after closing, unless the SO_REUSEADDR flag has been set."

That's why connections with automatically assigned source port 48080/58080 from previous test blocks the next to bind acceptor

so solution is to either set reuse_addr option for each socket in all tests

or use ip different from localhost for acceptors in order to not interfere with automatically assigned source endpoints

That would be your explanation why '127.0.0.2'

"paste.debian.net/hidden/98c79d3b" an example with reuse_addr for all connections in previous test

"man7.org/linux/man-pages/man7/ip.7.html" relevant part about REUSEADDR from man

A personal question: Are you a machine? :)

How is it decided who can comment on issues/PRs in the main repo? I have previously merged commits but still zero permissions. Can’t even comment on my own PR :/

is your git email linked with github?

every previous contributor should have access, github apparently counts you as a contributor if your git email is linked with github

if you show up here you *should* have access

Yea my name shows up there

I use my personal email as my primary account email and sign commits with that email. My school email is also associated w the account. When I try to add my users.noreply@github it says email is already in use

monero-project/monero #7646 <-- node_server test fix for master

monero-project/monero #7647 <-- node_server test fix for release-v.0.17

The rest is entirely your show wfaressuissia[m].

Unless you need me to help with testing.

fwiw -> old.reddit.com/r/Monero/comments/mk…0zy/bulletproof_tests_are_too_naive

Tests is an important subject that needs an audit of its own.

... in every project BTW.

Anyone know about the problems with monerod rpc 'Transfer-Enconding: chunked' and also why it returns a 200 on errors? I'm trying to monitor the daemon with a tool that uses this by default and it breaks it. Here's a packet log: 0x0.st/-ce1.pcap (ignore the late responses, it's still syncing)

either case, the transfer encoding is still a the main question

If some RPC doesn't do the same as others, it can be fixed.

Ah.

What kind of person steals from own community? np.reddit.com/r/Monero/comments/6d6okb/_/ Your own leaders are laughing at how stupid you are for falling for thier 'Magical Crypto Friendship'

.merge+ 7350 7321

Added

.merge+ 7580 7635 7639 7646 7647

Added

vtnerd: since monero-project/monero #7021 the daemon often shows "Unable to send transaction(s), no available connections" on startup

is this something you can take a look at? it confuses users

I'm quite sure it shows up since 7021, but not guranteed

yeah crap thats a weird one

Hello, I am new to Monero and wanted to start contributing. I cloned the repo recursively and changed to the release branch. The build failed because the submodule defintion for miniupnp was different between master and release-v0.17. The error wasn't obvious to me at first, so I wanted to submit a small patch to the README. gist.github.com/georgeleege/f778e48bcf9ff374d1850ee0b3da8102

because its dependent on making new outgoing connections

georgeleege: thanks, I can submit it for you, sorry for the locked repo but someone is annoying with spam

georgeleege: git submodule sync

Oh nvm. Thanks for the patch :)

selsta: thank you

moneromooo: :)

What's the best way to start contributing? Thinking of reading through the test cases and running them to get an understanding of the codebase.

What I do is find something that annoys me in whatever codebase I want to start contributing to, and fix/improve it.

Small things to start with.

Github issues might also point to some of these bits that some want changed.

makes sense. thanks for the advice

.merge+ 7650

Added