00:00:11 mhm no its HTTP 200. but cloudflare. mhm! 00:29:18 hm, maybe it's curl's fault after all 00:29:30 server seems to return HTTP/1.1 416 Requested Range Not Satisfiable, which seems like it might be correct? 00:29:48 not sure what curl is doing with that but i'm guessing append the HTML error body to the bz2 file 00:30:44 yep, that's it 00:31:30 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? 01:40:12 ndorf: try `curl -f` 01:40:26 plus the other flags/args 02:51:16 kpcyrd: thanks, that does keep it from corrupting the file, but now real errors (e.g. 404) are indistinguishable 02:52:02 curl should exit with a non-zero exit code in that case 02:52:25 right. but it also exits with the same error (22) for this "i already have the whole file" case 02:53:22 you might be pushing the limits of shell scripting too hard on this one ;) 02:53:49 hehe, well, i guess i could just check the hash first before running curl 02:54:00 still though, it feels like someone's behavior is wrong here 02:54:10 if the file was fully downloaded curl should've exited with a non-zero exit code already, right? 02:54:11 not sure if it's curl or the web server 02:57:35 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 02:58:53 nope, only with -f 02:59:00 it returns 0 despite the 416 without it 02:59:17 yeah, you almost always want -f anyway 02:59:26 (above is assuming -f is set) 02:59:53 after some googling it looks like this is in fact correct behavior on the server's part 03:00:07 the client is supposed to know the length and not send the request if it already has it all 03:02:50 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 03:03:50 oof 03:05:53 dunno why they didn't just make it return a zero length success instead 03:06:01 oh well 03:18:16 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 03:19:52 that is true, but the simpler case of just using a stateless client to download a file is broken too 03:20:22 back in the day http even used to call itself a stateless protocol, dunno if it still does :) 03:28:51 wget seems to handle the 416 error better than curl, fwiw. "The file is already fully retrieved; nothing to do" and error code 0 03:29:51 wget is most likely the tool you want anyway, curl is very low-level after all 03:30:17 curl is *usually* easier for scripting 03:30:20 not today though ;) 07:01:10 I keep getting fricken proxy exception in refresh thread* 07:01:40 im working in k8 and trying to spin up a handfull of wallets at the same time 07:02:12 is there a way to configure the daemon to never block/deny requests? as I understand this is a primitive dos thing 08:58:44 http://27blltx6kt26k65umbs2tme6rhv4i7rhagnzzljp3bsoqfkj6w364sqd.onion/the-trouble-with-bisq.html 09:01:12 i always enjoy firing up tor browser to read your secret blog 09:02:25 haha 09:02:27 that's nice to hear! 09:02:54 i really enjoy not knowing who the readers are, where they come from, and contributing exactly zero analytics to google 09:03:07 just read, take something from it or don't, spread the ideas or don't 09:56:17 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 ??? 09:57:31 https://i.imgur.com/E31FRaZ.png 09:57:46 know why im getting those non-characters? 09:57:54 @ kayront 10:00:30 blue_ 8d61f99... is the correct hash as far as I remember. 10:00:59 Downloaded it a few days ago, checked hashes normally and it was 8d61f... 10:02:28 083a3862f is not my actual either ... (15.0.0) cli 64 linux 10:03:45 can you tail -f your bitmonero.org ? 10:03:52 can you tail -f your bitmonero.log ? 10:16:37 blue_ I can do it in the evening 11:43:16 blue_: Are you using the GUI? 12:05:16 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: https://downloads.getmonero.org/source/monero-source-v0.15.0.1.tar.bz2, SHA256 hash 083a3862f554a2e5157686d7a8075557dfd6f07de08069cac91017c17739750b 12:05:25 hmm, indeed... Hash is different 12:06:34 There's a bug where it displays the hash of the source code 12:06:47 Downloaded it and the hash is 8D61F992A7E2DBC3D753470B4928B5BB9134EA14CF6F2973BA11D1600C0CE9AD 12:07:35 cc selsta 12:08:44 yep fixed here https://github.com/monero-project/monero-gui/pull/2485 12:12:25 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 12:15:16 I fixed it for GUI at least 12:15:24 not sure if there is / was a similar CLI bug 17:45:23 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 :) 18:00:44 would that be just an xmr thing or would it be the API extensibility thing as well? 18:11:56 maybe you CLI guys can help: ./monerod update check 18:11:57 Error: Problem fetching info-- rpc_request: 18:12:46 i get that on other commands as well like status 18:15:55 Are you running with restricted rpc ? 18:17:17 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 18:17:57 Then that is why. The update command is restricted. As with the mining related ones. 18:18:47 Guest23325: feel free to discuss it. 18:19:21 Is "XMR-Bisq integration that is still sitting in the Bisq "incubator" implying monero support is ready but ain't getting merged ? 18:19:45 so stop it, remove --restricted-rpc run update, add --restricted-rpc back? 18:20:29 Yes. 18:20:44 It does check every 12 hours automatically though. 18:21:02 And it'll log if it finds an update. 18:21:32 it had been running for a month or so 🤷‍♂️ 18:22:11 heh, cant stop_daemon because of restricted-rpc 🤦‍♂️ 18:23:38 :) 18:24:47 the --rpc-bind-ip=0.0.0.0 needs restricted-rpc? 18:25:29 lel looks like all my commands need that 18:25:38 flags* 18:28:02 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 18:28:12 ./monerod update download* 19:01:52 So you mean instead of btc pairs it would be fully XMR pairs with xmr/fiat ? 19:03:40 Both I think 19:31:10 Yes. Could be XMR/anything 19:50:11 Guest23325: Regarding a hypothetical Monero Bisq fork: Count me in for any multisig-related consulting should it be necessary :) 19:55:37 is either of these flags be conflicting with the `update` commands? ./monerod --max-concurrency=1 --data-dir=/mnt/volume-1/monero --detach 19:56:01 be 22:51:59 Hello, is this a good place to talk about rx mining? 22:59:54 -pools is better generally. post there. 23:56:59 /join -pools 23:57:07 didn't work sox