When I see it right I need to build for a RPi zero ARMv6, I need only the monero-wallet-rpc, I don't care about the rest and I get crazy already since 5 hours because I get cross compiling not working. Is there a way to build only monero-wallet-rpc and ignore all unneeded to save time?

<s​needlewoods:monero.social> @vthor: I just tested to cross-compile for ARMv6 and it failed, but I think if you add `-D BUILD_DOCUMENTATION=OFF -D BUILD_DEBUG_UTILITIES=OFF` to the cmake command for `release-static-linux-armv6` in the Makefile and in src/CMakelists.txt remove `add_subdirectory()` for `seraphis_crypto`, `simplewallet`, `gen_multisig`, `gen_ssl_cert` and `blockchain_utilities` that should sligh<clipped message>

<s​needlewoods:monero.social> tly increase the speed.

<0​xfffc:monero.social> is there any way to get the latest hardfork version of the network, before full synchronization?

<j​effro256:monero.social> Like the latest supported hf version in the code, or the hf version that the blockchain is current processing?

<0​xfffc:monero.social> Like what is the current hf version of the network ( imagine my monerod has been sleeping for 2 years. And during start up I need the hf version of the network )

That is, if you know a node with working RPC

<j​effro256:monero.social> For p2p connections, you can check the `top_version` field of `CORE_SYNC_DATA`

<j​effro256:monero.social> Which is what is done in the `process_payload_sync_data` method of the cryptonote protocol handlers to log that "peer claims higher version than we think (VERSION for HEIGHT instead of OURVERSION) - we may be forked from the network and a software upgrade may be needed, or that peer is broken or malicious" message

<0​xfffc:monero.social> Yes, thanks both.

<0​xfffc:monero.social> The place I need current network hf, p2p is not initialized.

thank you s​needlewoods, will try this, have finally the RPi with PiOS and network over USB running. But wait, when I get you right I will use `make -D BUILD_DOCUMENTATION=OFF -D BUILD_DEBUG_UTILITIES=OFF release-static-linux-armv6` to crosscompile? I tried until now always with `make depends target=arm-linux-gnueabi` but the first issue was in unbound that is expect a OpenSSL >= 0.9.7 and found "ONLY" 3.0.13, after that I tried to comment out checks in the

configure file, but after that is goes on later with ECDSA.... missing, at some point I gave up in that direcction.

<p​hosphate1:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/dMcGBoyTkkPmaumdtjTuepYi

<p​hosphate1:matrix.org> 2 ips are spamming the same newest block from different ports massively slowing my node sync

<p​hosphate1:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/AcTXZSZLtJobheErmrVfpgLi

<p​hosphate1:matrix.org> several ips are spamming the same newest block from different ports massively slowing my node sync

<p​hosphate1:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/YZRXvEZPbIuTuGKEeOgfZRXs

<p​hosphate1:matrix.org> I've banned 20 ips so far but more keep coming

<j​effro256:monero.social> I can open a PR for that

<j​effro256:monero.social> to fix some all the perf issues if you want to test it out

<s​needlewoods:monero.social> vthor no, afaik the arguments don't work for `make`, but for `cmake`. So add the `-D BUILD_DOCUMENTATION=OFF -D BUILD_DEBUG_UTILITIES=OFF` here: github.com/monero-project/monero/blob/master/Makefile#L117 to the `cmake` command and then call `make release-static-linux-armv6` to build. Not sure though if this works for cross-compiling (I guess it could if you have the arm to<clipped message>

<s​needlewoods:monero.social> olchain installed) and how this differs from your approach `make depends target=arm-linux-gnueabi`.

<j​effro256:monero.social> jk it didn't make it faster, the slowdown must be coming from somewhere else

<j​effro256:monero.social> phosphate1: can you run the command `curl <YOUR NODE ADDRESS>/get_info | grep alt_blocks_count` plz?

s​needlewoods, yeah, figured out that it's not for make, wanted only to test and started compiling on the device, and it is compiling since an hours, how in your opinion it changes only slightly something will not stop, how I read that people needed 24 hours instead of the 3-4h but it could also be that the had slow sdcard.... so I will see, as long it compiles through, for x86_64 I compiled already and it worked with my extensions, so I hope it runs through

and works, and another day in the future I will fiddle out how to crosscompile or at least compile on a pi4 (thing that should work if I use the same sdcard) wit 8GB RAM. I wonder how long it will take to learn all the stuff with crosscompiling (I'm not really a patient person :D )

thank you again s​needlewoods