mhm no its HTTP 200. but cloudflare. mhm!

hm, maybe it's curl's fault after all

server seems to return HTTP/1.1 416 Requested Range Not Satisfiable, which seems like it might be correct?

not sure what curl is doing with that but i'm guessing append the HTML error body to the bz2 file

yep, that's it

guess that leaves the question of whether 416 is correct when Range specifies exactly the length of the file, or it should be an empty 200 response instead?

ndorf: try `curl -f`

plus the other flags/args

kpcyrd: thanks, that does keep it from corrupting the file, but now real errors (e.g. 404) are indistinguishable

curl should exit with a non-zero exit code in that case

right. but it also exits with the same error (22) for this "i already have the whole file" case

you might be pushing the limits of shell scripting too hard on this one ;)

hehe, well, i guess i could just check the hash first before running curl

still though, it feels like someone's behavior is wrong here

if the file was fully downloaded curl should've exited with a non-zero exit code already, right?

not sure if it's curl or the web server

so basically you could download foo.bin into foo.bin.part with resumption enabled, then mv foo.bin.part foo.bin if curl exits with success. At this point the script is going to notice it already has the file even if something fails later and the script is restarted

nope, only with -f

it returns 0 despite the 416 without it

yeah, you almost always want -f anyway

(above is assuming -f is set)

after some googling it looks like this is in fact correct behavior on the server's part

the client is supposed to know the length and not send the request if it already has it all

I guess there's an edgecase if the connection uses chunked encoding, no Content-Length header has been sent and the connection dies after the last "real" chunk, but before the zero length chunk has been sent

oof

dunno why they didn't just make it return a zero length success instead

oh well

that case should be super rare though and if you're downloading something that can be resumed you most likely have a Content-Length header anyway

that is true, but the simpler case of just using a stateless client to download a file is broken too

back in the day http even used to call itself a stateless protocol, dunno if it still does :)

wget seems to handle the 416 error better than curl, fwiw. "The file is already fully retrieved; nothing to do" and error code 0

wget is most likely the tool you want anyway, curl is very low-level after all

curl is *usually* easier for scripting

not today though ;)

I keep getting fricken proxy exception in refresh thread*

im working in k8 and trying to spin up a handfull of wallets at the same time

is there a way to configure the daemon to never block/deny requests? as I understand this is a primitive dos thing

i always enjoy firing up tor browser to read your secret blog

haha

that's nice to hear!

i really enjoy not knowing who the readers are, where they come from, and contributing exactly zero analytics to google

just read, take something from it or don't, spread the ideas or don't

hi, am i dreaming again or am i drunk ? bitmonero.log propose me Version 0.15.0.1 SHA256 hash 083a3862f554a2e5157686d7a8075557dfd6f07de08069cac91017c17739750b and getmonero.org display Current Version: 0.15.0.1 SHA256 Hash (CLI): 8d61f992a7e2dbc3d753470b4928b5bb9134ea14cf6f2973ba11d1600c0ce9ad ???

know why im getting those non-characters?

@ kayront

blue_ 8d61f99... is the correct hash as far as I remember.

Downloaded it a few days ago, checked hashes normally and it was 8d61f...

083a3862f is not my actual either ... (15.0.0) cli 64 linux

can you tail -f your bitmonero.org ?

can you tail -f your bitmonero.log ?

blue_ I can do it in the evening

blue_: Are you using the GUI?

<sech1> 2019-11-27 00:26:13.932 [P2P0] INFO global src/cryptonote_core/cryptonote_core.cpp:1733 Version 0.15.0.1 of monero for source is available: downloads.getmonero.org/source/monero-source-v0.15.0.1.tar.bz2, SHA256 hash 083a3862f554a2e5157686d7a8075557dfd6f07de08069cac91017c17739750b

<sech1> hmm, indeed... Hash is different

There's a bug where it displays the hash of the source code

<sech1> Downloaded it and the hash is 8D61F992A7E2DBC3D753470B4928B5BB9134EA14CF6F2973BA11D1600C0CE9AD

cc selsta

yep fixed here monero-project/monero-gui #2485

it is just not the same tar : monero-source-v0.15.0.1.tar.bz2 is 083a3862f554a2e5157686d7a8075557dfd6f07de08069cac91017c17739750b and monero-linux-x64-v0.15.0.1.tar.bz2 is 8d61f992a7e2dbc3d753470b4928b5bb9134ea14cf6f2973ba11d1600c0ce9ad then actually it is good

I fixed it for GUI at least

not sure if there is / was a similar CLI bug

I really feel we should really have a serious discussion about the practical possibility of creating a Monero-based Bisq. I would be all in, and maybe woodser, niyid (who made the XMR-Bisq integration that is still sitting in the Bisq "incubator") and rbrunner woud be interested too :)

would that be just an xmr thing or would it be the API extensibility thing as well?

maybe you CLI guys can help: ./monerod update check

Error: Problem fetching info-- rpc_request:

i get that on other commands as well like status

Are you running with restricted rpc ?

damn, ya. here are the flags i run the daemon with: ./monerod --restricted-rpc --rpc-bind-ip=0.0.0.0 --confirm-external-bind --public-node --max-concurrency=1 --data-dir=/mnt/volume-1/monero --detach

Then that is why. The update command is restricted. As with the mining related ones.

Guest23325: feel free to discuss it.

Is "XMR-Bisq integration that is still sitting in the Bisq "incubator" implying monero support is ready but ain't getting merged ?

so stop it, remove --restricted-rpc run update, add --restricted-rpc back?

Yes.

It does check every 12 hours automatically though.

And it'll log if it finds an update.

it had been running for a month or so 🤷‍♂️

heh, cant stop_daemon because of restricted-rpc 🤦‍♂️

:)

the --rpc-bind-ip=0.0.0.0 needs restricted-rpc?

lel looks like all my commands need that

flags*

ran with: ./monerod --max-concurrency=1 --data-dir=/mnt/volume-1/monero --detach and still get "Error: Problem fetching info-- rpc_request:" when doing: ./monerod update downloa

./monerod update download*

So you mean instead of btc pairs it would be fully XMR pairs with xmr/fiat ?

Both I think

Yes. Could be XMR/anything

Guest23325: Regarding a hypothetical Monero Bisq fork: Count me in for any multisig-related consulting should it be necessary :)

is either of these flags be conflicting with the `update` commands? ./monerod --max-concurrency=1 --data-dir=/mnt/volume-1/monero --detach

be

Hello, is this a good place to talk about rx mining?

-pools is better generally. post there.

/join -pools

didn't work sox