02:02:38 <gingeropolous> my daemon is stuck on 2569430
02:02:51 <gingeropolous> no wait, sorry
06:40:44 <mj-xmr[m]> A small announcement:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/86998aae4e6bb4e254947f9a8704777242ae0ef9)
09:07:19 <M9teeneightyfour> Hello. I am/have been having a wierd issue where my funds dont show up in the gui wallet, connected with a ledger. Have been trying to find a solution since may last year with no success. I have tried everything I myself could find on the web as a solution, but nothing has worked. Is there anyone here that can help me/knows what my issue is (if so I could explain it further)? Would greatly appreciate any help since I don’t know
09:07:19 <M9teeneightyfour> where else to turn. Thank you.
09:12:33 <moneromooo> Try asking in #monero.
11:30:18 -xmr-pr- mj-xmr opened pull request #8197: Copyright: Update to 2022
11:30:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8197
18:08:36 <gingeropolous> well, what i believe to be is master branch on xmrchain has been up for  81d 14h 14m 2s
18:10:35 <gingeropolous> hrm. compiling master makes monerod help spit out (v0.17.0.0-4f6e17ad8)
18:14:57 <gingeropolous> well in any case xmrchain.net is now running master
18:15:12 <gingeropolous> at least for mainnet
18:44:06 <jeffro256[m]> How do I run all the tests ?
18:44:27 <jeffro256[m]> (the ones that run during the ubuntu CI build)
18:48:08 <moneromooo> make -C build/etc test
19:00:15 <jeffro256[m]> Awesome, thank you so much!
19:30:18 -xmr-pr- ikseles opened issue #8198: Payment never received (similar to issue #8134)
19:30:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8198
19:53:45 <jeffro256[m]> Are the tests (specifically core_tests) fail-fast?
19:57:49 <moneromooo> No.
19:58:28 <moneromooo> Well, depends on your subjective subjevtivity I subjectively surmise.
19:59:20 <moneromooo> "Fail fast" usually means "if bad, say so quick". But it's a test. If it's bad, and it says so quick, why would it continue for a while just to say it went well ?
20:00:15 <moneromooo> Normal programs would use that time to produce useful data, etc. A test doesn't. It just says yes/no.
20:09:12 <hocuspocusoutoff> i see a lot of "generate" stuff going on in some tests. i wonder if any of that stuff can be pre-generated and loaded from a fixture file?
20:09:38 <moneromooo> See --help. It's probably broken though, feel free to fix it if you can.
20:10:04 <moneromooo> Also, caching means you're in danger of using stale data. Be wary of this.
20:10:33 <moneromooo> By --help, I mean core_tests --help.
20:11:05 <moneromooo> But tbh, it's not too long if you use the quick PoW env var.
20:12:00 <hocuspocusoutoff> "not too long" adds up over hundreds or thousands of tests :)
20:13:07 <hocuspocusoutoff> my knowledge of this stuff comes from an entirely different language so im just spitballing here for jeffro
20:30:37 <selsta> luigi1111: merges? pls
20:31:28 <luigi1111> Probably
20:50:32 <jeffro256[m]> moneromooo I guess I meant to ask if a subtest of (for example) core_tests fails, will core_tests continue to test the rest of the subtests in core_tests? Because overall, that isn't true of all the tests correct? Like if unit_tests fails, the hash_fast test will still run, right? But conversely, if a subtest of any of hash-target, core_tests, etc fail then that specific test terminates with a failure immediately right?
20:52:12 <jeffro256[m]> Sorry if its a dumb question
21:07:50 <hocuspocusoutoff> imo fast-fail should be a user option, turned on for CI runs since there you only care that anything failed rather than a full list of fails
21:14:06 <moneromooo> core_tests will run all tests, whether or not any of them fail.
21:14:08 <moneromooo> Same for unit_tests.
21:14:26 <moneromooo> If a (core, unit other) test fails, other will also run.
21:15:00 <moneromooo> For core tests, since they're a bit long and spammy, you can grep '#TEST#' in the log, to see fail/success as they run.
21:15:20 <moneromooo> Then you can strt debugging a failing one as the rest runs.
21:44:14 <luigi1111w> .merges
21:44:14 -xmr-pr- 7084 7877 8052 8145 8161 8163
22:10:14 <selsta> moneromooo: anything they can provide to debug this? https://github.com/monero-project/monero/issues/8194
22:10:24 <selsta> as expected, the OS update didn't fix it
22:13:25 <hocuspocusoutoff> so... possibly not related at all since user's details dont match mine, but i had similar symptoms when i tried my first sync. i am hosting the blockchain on a NAS while daemon runs on my server. the NAS had some goofy-ass software that "indexed" things every time a change was made on disk. this basically caused the sync to grind to a halt somewhere around the same block height user is mentioning. once i was able to turn that
22:13:25 <hocuspocusoutoff> nonsense off, sync finished cleanly
22:15:21 <selsta> guess I'll try a fresh blockchain sync to check if I can reproduce
22:15:29 <selsta> but we didn't get any other reports about this
22:18:57 <hocuspocusoutoff> a lot of random forum posts out there insist that this is just what happens on non-SSDs, which is total nonsense, so i think a lot of people just give up
22:19:39 <selsta> HDDs are significantly slower for sync
22:19:49 <hocuspocusoutoff> my problem was the NAS' software doesnt give you any easy way to remove this index shit so all of my time was spent figuring out how to do that
22:20:15 <hocuspocusoutoff> yeah but they shouldnt grind to a halt. after cleaning out the crap software it took me 1.5 days for full sync
22:20:39 <hocuspocusoutoff> and thats HDD over a network drive with RAID