02:45:12 <PvtCaboose> 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?
03:01:36 <gingeropolous> is the "1" in support flags listed in the print_cn output indicative of a public RPC node?
03:19:15 <PvtCaboose> I haven't made it that far, still building it with make
03:36:13 <gingeropolous> oh sorry, i was just asking the room :)
03:37:13 <PvtCaboose> Opps
03:37:28 <PvtCaboose> Just new :(
03:45:17 <gingeropolous> welcome! oh regarding that thing PvtCaboose , try git submodule sync , then  git submodule update
04:03:48 <wihvgfppn> Look on the bright side. At least you don't need to obsess over signs of life from FUK now.
04:05:49 <PvtCaboose> 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!
04:11:38 <virgildante[m]> I usually clone with --recursive, not sure if that might help
04:12:33 <PvtCaboose> 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
12:32:55 <mj-xmr> moneromooo, how can I increase the log level for Unit Tests?
12:33:13 <mj-xmr> I see the logs being produced in the UT dir with INFO.
12:33:20 <moneromooo> MONERO_LOGS=2 unit_tests
12:33:29 <mj-xmr> Great. Thx
12:54:01 <mj-xmr> 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.
12:57:09 <wfaressuissia[m]> 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)
12:59:31 <wfaressuissia[m]> it can be reproduced locally
13:20:49 <mj-xmr> I've just reproduced it as well and have all the logs.
13:21:31 <mj-xmr> I will take it up but will gladly ask questions.
13:23:12 <wfaressuissia[m]> nothing interesting in logs even with '*:TRACE'
13:27:39 <wfaressuissia[m]> there must be some edge case when
13:27:46 <mj-xmr> https://paste.debian.net/1192373/
13:27:52 <mj-xmr> This is the first difference.
13:28:19 <wfaressuissia[m]> it's unrelated
13:28:24 <mj-xmr> 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.
13:29:39 <wfaressuissia[m]>  * 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
13:30:44 <mj-xmr> 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.
13:30:51 <mj-xmr> *all the unit tests
13:31:37 <mj-xmr> wfaressuissia[m], I'd expect to see another service using 48080/58080, but I can't find any.
13:31:47 <wfaressuissia[m]> "https://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
13:33:12 <mj-xmr> Interesting. Let's put it on the gramophone ...
13:36:11 <wfaressuissia[m]> "https://paste.debian.net/hidden/a1bbfa8b/" 127.0.0.1 -> 127.0.0.2
13:39:04 <wfaressuissia[m]> "https://paste.debian.net/hidden/7a5ab8dc/" or this one
13:39:57 <wfaressuissia[m]> but in any case the point is to use different IPs for endpoints of different tests
13:46:20 <mj-xmr> Still crashed after the first patch. Trying the other ones.
13:46:38 <wfaressuissia[m]> first with 127.0.0.1 ?
13:47:14 <mj-xmr> Yes
13:47:24 <wfaressuissia[m]> that's expecetd, that patch is deleted now
13:48:09 <mj-xmr> I get your argument about endpoints.
13:48:48 <mj-xmr> So if 0.2 works, we should focus on making other tests unique. Is this what what you're about?
13:49:09 <mj-xmr> Anyway. Running wuth 0.2
13:51:07 <wfaressuissia[m]> that's very specific edge cases since only 48080/58080 ports are being observed for sockets with TIME_WAIT state;
13:51:32 <wfaressuissia[m]> if you have a lot of time then try to reproduce this bind failure in isolated test and find the real reason
13:52:34 <wfaressuissia[m]> otherwise no need to replace IPs for other tests
14:00:06 <mj-xmr> Unfortunately 0.2 crashed.
14:01:05 <mj-xmr> crap sorry. It's a different test, that crashed...
14:03:28 <wfaressuissia[m]> How many iterations without failure of that node_server.* test ?
14:03:59 <mj-xmr> I didn't check that. It's just a while loop.
14:04:09 <wfaressuissia[m]> it was 300+ here
14:04:13 <mj-xmr> On GitHub it was 10% of chance.
14:04:25 <wfaressuissia[m]> "... It's just a while loop." add some counter
14:04:36 <mj-xmr> Are you running all the tests or just node_server.*?
14:04:43 <mj-xmr> In the latter case it never failed.
14:04:47 <mj-xmr> on my machine
14:05:05 <wfaressuissia[m]> not all, not only that one
14:05:29 <mj-xmr> I'm almost sure you won't repro it this way.
14:08:05 <wfaressuissia[m]> How many seconds per iteration in your case ?
14:09:37 <wfaressuissia[m]> "https://paste.debian.net/hidden/f2276ddb/" 5 seconds with this filter
14:10:17 <mj-xmr> I need about 2 minutes.
14:10:52 <mj-xmr> But do you mean that you are able to reproduce with this filter?
14:10:59 <wfaressuissia[m]> and the above filter is sufficient to trigger that error without fix
14:11:16 <mj-xmr> Excellent. Will be useful in the future.
14:15:15 <wfaressuissia[m]> "--gtest_filter='test_epee_connection.test_lifetime:node_server.bind_same_p2p_port'" this filter is sufficient too
14:15:25 <wfaressuissia[m]> probably the smallest possible one
14:18:06 <wfaressuissia[m]> time to start deep diving :D if you have time
14:21:46 <mj-xmr> 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 :)
14:23:52 <wfaressuissia[m]> and quick fix is likely needed for both branches
14:33:22 <wfaressuissia[m]> reproduced on release-v0.17 branch too
14:41:40 <mj-xmr> True that
14:42:27 <mj-xmr> To be safe, I will try to reproduce the crash using your filter without the IP change.
14:42:54 <wfaressuissia[m]> It has been already reproduced few times
14:47:41 <mj-xmr> OK, same here. Great.
14:48:02 <mj-xmr> wfaressuissia[m], I'd like to add you to the credits of my PR. What's your GitHub handle?
14:48:55 <wfaressuissia[m]> "https://paste.debian.net/hidden/ea0956ec/" wait, isolated reproduction in python
14:52:10 <mj-xmr> Cool.
14:53:12 <mj-xmr> Python tests go to functional_
14:53:57 <mj-xmr> Are you sure you want to mix one quick fix and a full blown isolation?
14:55:21 <wfaressuissia[m]> I'm searching the reason
14:56:06 <mj-xmr> From my experience already medium sized PRs are hard to be merged. Quick fix just work.
14:56:21 <mj-xmr> So one doesn't disturb another, I'd say.
14:59:24 <wfaressuissia[m]> "A TCP local socket address that has been bound is unavailable for some time after closing, unless the SO_REUSEADDR  flag has been set."
14:59:45 <wfaressuissia[m]> That's why connections with automatically assigned source port 48080/58080 from previous test blocks the next to bind acceptor
15:00:07 <wfaressuissia[m]> so solution is to either set reuse_addr option for each socket in all tests
15:00:32 <wfaressuissia[m]> or use ip different from localhost for acceptors in order to not interfere with automatically assigned source endpoints
15:00:46 <wfaressuissia[m]> That would be your explanation why '127.0.0.2'
15:01:39 <wfaressuissia[m]> "https://paste.debian.net/hidden/98c79d3b/" an example with reuse_addr for all connections in previous test
15:03:40 <wfaressuissia[m]> "https://www.man7.org/linux/man-pages/man7/ip.7.html" relevant part about REUSEADDR from man
15:06:05 <mj-xmr> A personal question: Are you a machine? :)
15:15:00 <bevanoff[m]> 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 :/
15:15:24 <selsta> is your git email linked with github?
15:16:04 <selsta> every previous contributor should have access, github apparently counts you as a contributor if your git email is linked with github
15:18:25 <selsta> https://github.com/monero-project/monero/graphs/contributors
15:18:34 <selsta> if you show up here you *should* have access
15:24:53 <bevanoff[m]> Yea my name shows up there
15:27:19 <bevanoff[m]> 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
15:55:03 <mj-xmr> https://github.com/monero-project/monero/pull/7646 <-- node_server test fix for master
15:55:03 <mj-xmr> https://github.com/monero-project/monero/pull/7647 <-- node_server test fix for release-v.0.17
15:57:41 <mj-xmr> The rest is entirely your show wfaressuissia[m].
15:57:58 <mj-xmr> Unless you need me to help with testing.
17:37:30 <dEBRUYNE> fwiw -> https://old.reddit.com/r/Monero/comments/mkp0zy/bulletproof_tests_are_too_naive/
18:27:22 <mj-xmr> Tests is an important subject that needs an audit of its own.
18:27:36 <mj-xmr> ... in every project BTW.
19:09:52 <caskd-Alex> 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: http://0x0.st/-ce1.pcap (ignore the late responses, it's still syncing)
19:12:43 * moneromooo not quite sure whether JSON RPC errors are meant to be 200 with a JSON with an error object or not 200.
19:13:25 <caskd-Alex> either case, the transfer encoding is still a the main question
19:13:28 <moneromooo> If some RPC doesn't do the same as others, it can be fixed.
19:13:36 <moneromooo> Ah.
19:13:58 * moneromooo has no idea about encoding, waits for someone else
19:16:13 <vsoyexlng> 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'
21:50:11 <selsta> .merge+ 7350 7321
21:50:11 <xmr-pr> Added
21:54:50 <selsta> .merge+  7580 7635 7639 7646 7647
21:54:50 <xmr-pr> Added
22:14:08 <selsta> vtnerd: since https://github.com/monero-project/monero/pull/7021 the daemon often shows "Unable to send transaction(s), no available connections" on startup
22:14:16 <selsta> is this something you can take a look at? it confuses users
22:14:37 <selsta> I'm quite sure it shows up since 7021, but not guranteed
22:15:00 <vtnerd> yeah crap thats a weird one
22:15:06 <georgeleege> 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. https://gist.github.com/georgeleege/f778e48bcf9ff374d1850ee0b3da8102
22:15:11 <vtnerd> because its dependent on making new outgoing connections
22:16:21 <selsta> georgeleege: thanks, I can submit it for you, sorry for the locked repo but someone is annoying with spam
22:24:05 <moneromooo> georgeleege: git submodule sync
22:24:49 <moneromooo> Oh nvm. Thanks for the patch :)
22:25:03 <georgeleege> selsta: thank you
22:25:03 <georgeleege> moneromooo: :)
22:27:12 <georgeleege> 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.
22:27:48 <moneromooo> What I do is find something that annoys me in whatever codebase I want to start contributing to, and fix/improve it.
22:27:53 <moneromooo> Small things to start with.
22:29:09 <moneromooo> Github issues might also point to some of these bits that some want changed.
22:39:41 <georgeleege> makes sense. thanks for the advice
22:53:17 <selsta> .merge+ 7650
22:53:17 <xmr-pr> Added