< Luke-Jr> wumpus: it seems using curl for the fetch (stealing it from the darwin platform support) fixes this. shall I PR that?
< Luke-Jr> or is there some reason to prefer wget?
< Luke-Jr> cfields: ^
< GitHub127> [bitcoin] luke-jr opened pull request #7487: depends: Use curl for fetching on Linux (master...depends_curl) https://github.com/bitcoin/bitcoin/pull/7487
< GitHub42> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/326f010332a6...3db828f95165
< GitHub42> bitcoin/master 7c06fbd Wladimir J. van der Laan: rpc: Add WWW-Authenticate header to 401 response...
< GitHub42> bitcoin/master 3db828f Wladimir J. van der Laan: Merge #7472: rpc: Add WWW-Authenticate header to 401 response...
< GitHub174> [bitcoin] laanwj closed pull request #7472: rpc: Add WWW-Authenticate header to 401 response (master...2016_02_www_authenticate) https://github.com/bitcoin/bitcoin/pull/7472
< GitHub94> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3db828f95165...3ffe4b241ed4
< GitHub94> bitcoin/master 301bc7b Suhas Daftuar: Update nQueuedValidatedHeaders after peer disconnection
< GitHub94> bitcoin/master 3ffe4b2 Wladimir J. van der Laan: Merge #7482: [P2P] Ensure headers count is correct...
< GitHub43> [bitcoin] laanwj closed pull request #7482: [P2P] Ensure headers count is correct (master...fix-download-timeouts) https://github.com/bitcoin/bitcoin/pull/7482
< Luke-Jr> wumpus: proxy_tests fails on Travis because they don't have IPv6 enabled :/
< wumpus> since when?
< wumpus> the test always passed fine
< Luke-Jr> dunno, it doesn't pass now..
< Luke-Jr> it seems AF_INET6 maybe valid, but no ::1
< wumpus> crap, what is the case with the travis tests lately
< wumpus> we switched to travis because it would be more reliable than the pulltester :)
< Luke-Jr> >_<
< wumpus> things are randomly breaking with certificates, seemingly with ipv6 support
< wumpus> to be clear: proxy tests doesn't need a valid IPv6 connection, having just ipv6 localhost work is enough
< Luke-Jr> right, but that's not there
< Luke-Jr> $ sudo ip -6 addr add ::1/128 scope host dev lo
< Luke-Jr> RTNETLINK answers: Permission denied
< Luke-Jr> blah
< wumpus> can we file an issue with them?
< wumpus> this seems like a problem, not just for us, I expect many projects will have ipv6 tests in the 2010's
< Luke-Jr> wumpus: apparently they have decided not to maintain IPv6 support :| https://blog.travis-ci.com/2015-11-27-moving-to-a-more-elastic-future
< Luke-Jr> wumpus: looks like bitcoin/* has the old servers specially set
< Luke-Jr> and there's a travis yml change I can add to explicitly set it
< wumpus> dropping ipv6 support is just lunatic
< wumpus> but sure, we can change the test to not test ipv6 if it's not present. I had hoped such a thing would no longer happen in 2016.
< Luke-Jr> wumpus: well, we can choose 14.04 OR IPv6 it looks like
< Luke-Jr> just not both
< wumpus> right - so you say we choose the old servers, so we should still have ipv6? Then in the pull switching to the new servers we should 'fix' the test too
< Luke-Jr> problem is forks don't get the old-servers setting as it is now
< Luke-Jr> hence my problems on my repo
< wumpus> right
< Luke-Jr> I *might* have a travis.yml setting to force it though
< Luke-Jr> testing it now
< wumpus> * [new tag] v0.12.0rc4 -> v0.12.0rc4
< wumpus> this is going to be a very short lived rc before final, there were some last-minute, trivial but critical fixes that had to go in
< Luke-Jr> found a new critical bug!
< Luke-Jr> :P jk
< wumpus> hehe
< wumpus> too late, we'll just add it as a feature :)
< randy-waterhouse> "trivial but critical"
< wumpus> randy-waterhouse: yes, as in two-line changes
< GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3ffe4b241ed4...b49a62379900
< GitHub33> bitcoin/master 993d089 instagibbs: Changed getnetworkhps value to double to avoid overflow.
< GitHub33> bitcoin/master b49a623 Wladimir J. van der Laan: Merge #7480: Changed getnetworkhps value to double to avoid overflow....
< GitHub170> [bitcoin] laanwj closed pull request #7480: Changed getnetworkhps value to double to avoid overflow. (master...hashps) https://github.com/bitcoin/bitcoin/pull/7480
< wumpus> Luke-Jr: can you check if this suffices to detect absence of local IPv6 support? http://www.hastebin.com/xefetokiji.py
< Luke-Jr> no, the URI doesn't load
< wumpus> hu
< wumpus> I see, retrying with another pastebin
< wumpus> https://0bin.net/paste/ikqfSQBBtoMqr5zn#6Gx9K0sYO+04oLDdfos+vloWxBiLUldVKsNxAEdymmS
< GitHub18> [bitcoin] laanwj pushed 4 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/b9ed8c996912...827a2b6736d0
< GitHub18> bitcoin/0.12 b2f2b85 Wladimir J. van der Laan: rpc: Add WWW-Authenticate header to 401 response...
< GitHub18> bitcoin/0.12 e16f5b4 Suhas Daftuar: Update nQueuedValidatedHeaders after peer disconnection...
< GitHub18> bitcoin/0.12 43484d7 Wladimir J. van der Laan: doc: Update release notes for rc4 changes
< wumpus> that's funny, I pushed the rc4 tag but not the 0.12 branch...
< Luke-Jr> wumpus: any reason not to just try: except socket.error: ?
< Luke-Jr> and in this case, wouldn't it need to be ::1 ?
< wumpus> eh yes, it needs to be ::1
< wumpus> except socket.error is an improvement, sure, I didn't know the specific error that would be raised
< wumpus> so I understand it works?
< wumpus> (I only have systems with basic ipv6 support where it prints True, I can't actually test the failing case)
< wumpus> and filing a pull request for travis won't work either, as on bitcoin/bitcoin the proxy tests are still passing
< Luke-Jr> only way I have to test it is to push to github and let travis do it ;)
< Luke-Jr> for whatever reason, the :: successfully diagnoses False on Travis and True on my PC
< wumpus> ok!
< Luke-Jr> I imagine ::1 would also work
< wumpus> yes let's use ::1 to be sure, :: is the any address, it doesnt really make sense to use it as target
< GitHub111> [bitcoin] laanwj opened pull request #7489: tests: Make proxy_test work on travis servers without IPv6 (master...2016_02_ipv6_tests_conditional) https://github.com/bitcoin/bitcoin/pull/7489
< GitHub142> [bitcoin] laanwj opened pull request #7490: tests: Remove May15 test (master...2016_02_may12forkdat) https://github.com/bitcoin/bitcoin/pull/7490
< MarcoFalke> wumpus, mind to share the reason for closing #2737?
< wumpus> it is extremely unlikely the signed message format will be changed anymore
< MarcoFalke> I see
< wumpus> it has been the same for years, no one ever bothered to do this, I don't see a point for keeping it open
< wumpus> so no, I'm not principally against it, but just cleaning house a bit
< wumpus> in this case it would also make more sense as a BIP proposal, especially if the goal is to coordinate between different software
< wumpus> in principle the issue tracker is for tracking issues, not every nice tangentially related idea anyone had in 6 years :)
< wumpus> but I'll post that to the issue ,so that it is more clear
< MarcoFalke> Right, so you don't get the same question twice.
< cfields> Luke-Jr: i believe the issue (we've seen it before) has to do with wget being more strict than curl wrt ssl certs
< cfields> I'm not sure why it's an issue in some cases and not others, though
< wumpus> the main thing I don't understand is why it doesn't use the fallback
< cfields> taking a look. I didn't realize it was failing for master, thought it was only for the older branches
< wumpus> I've seen the error only on 0.10
< wumpus> I haven't seen it for master in our repository, but Luke-Jr probably sees it in his own
< wumpus> cfields: isn't it sad: https://github.com/bitcoin/bitcoin/pull/7489
< cfields> oh, i saw a pile of his PRs failing and assumed that was the issue
< cfields> wumpus: yes, very. apparently it's an issue with google compute engine, that's the even crazier part
< cfields> wumpus: btw, i pinged them for an updated ETA on rolling out the cache, no response yet
< wumpus> cfields: agreed, *google* not supporting IPv6 is even more shocking
< cfields> wumpus: and yes, Luke-Jr's issue may be the way that the CA stores are setup on the different build configs
< cfields> last time we looked into the failing wget, it turned up that curl/wget behave differently there. iirc one of them bundle their own certs, the other uses system
< wumpus> it's a kind of roulette, this time curl comes out on top, but next time it may be wget that has a cert and not curl
< wumpus> which is why I haven't been terribly enthousiastic about changing the tool
< cfields> right
< wumpus> maybe the best solution is to drop https, we verify the hashes after all
< wumpus> (though some software may only be hosted on https, these days)
< cfields> my original logic for wget was that wget is always present on my minimal systems, so wget can "bootstrap" itself or curl if necessary.
< wumpus> yes, wget does seem to be more widespread by default
< cfields> (and the opposite is true on osx)
< warren> Fedora and RHEL ships curl by default but not wget.
< cfields> heh, nice. maybe it's a debian-ism
< warren> I do install wget on all of *my* systems.
< cfields> there's wget in busybox though, which is why i assumed it was more common (always find that on routers/phones/etc). unsure if curl is present there
< cfields> anyway, doesn't really matter. you're right that it's roulette. should work for both
< warren> what is this for?
< cfields> hunting for one of Luke-Jr's ssl fails, i'll see if i can track down the root cause
< warren> The removal of weak ciphers recently broke wget and curl in inconsistent ways.
< warren> IIRC curl trusts the system ciphers instead of using overriding a sane default
< warren> It would be entirely reasonable for distros to patch curl to behave sanely but people refused as upstream refused.
< cfields> warren: hmm, the cert chain looks ok to me
< cfields> (fukuchi.org)
< warren> cfields: ciphers were a problem recently, you sure that isn't it?
< warren> removal of SSLv3 or something, while curl requires a flag to do the sane thing
< cfields> warren: unsure what the actual issue is, trying to track down a failure
< michagogo> Luke-Jr: the problem with switching to curl is that it's not everywhere by default
< michagogo> Ubuntu, at least, comes with only wget afaik
< michagogo> I mean, other things are different -- e.g. OS X comes with curl and not wget
< michagogo> Really, the best thing to do is probably to try one and then the other of the first fails
< michagogo> (...and I see now that this was already mentioned)
< cfields> there's the problem
< GitHub104> [bitcoin] laanwj opened pull request #7491: wallet: Ignore MarkConflict if block hash is not known (master...2016_02_wallet_markconflict_assert) https://github.com/bitcoin/bitcoin/pull/7491
< Luke-Jr> cfields: Any idea what's going on in https://travis-ci.org/luke-jr/bitcoin/jobs/108003601 ?
< cfields> Luke-Jr: missing sdk?
< Luke-Jr> oh, weird. the empty curl doesn't stop the build? O.o
< Luke-Jr> does that mean there's a new Travis IP to whitelist?
< Luke-Jr> /bin/sh: 1: test: qtbase-opensource-src-5.5.0.tar.gz: unexpected operator
< Luke-Jr> /bin/sh: 1: test: ee31ae567931c426136c94aad457c7b51d844beb.tar.gz: unexpected operator
< Luke-Jr> Fetching native_ccache…
< Luke-Jr> wonder what's going on there too
< cfields> Luke-Jr: that one's harmless
< cfields> yea, weird that the busted curl doesn't fail. did you change that from wget?
< Luke-Jr> oh, maybe I need -L
< Luke-Jr> and yes, because wget failed
< cfields> looks like it should've :)
< morcos> wumpus: I probably figured this out before, but why do we even need to be calling MarkConflict from the fFromLoadWallet code block?
< morcos> re: 7491
< morcos> sipa: ^ any idea on this?
< Luke-Jr> cfields: 100 328 0 328 0 0 271 0 --:--:-- 0:00:01 --:--:-- 1131
< Luke-Jr> cfields: I think that's a forbidden error
< Luke-Jr> cfields: can you get the IP on your own, or shall I add some kind of IP detection to it? :p
< * Luke-Jr> pokes cfields :p
< cfields> Luke-Jr: was checking. My access to bitcoincore.org doesn't work, hasn't since the xfer
< cfields> wumpus: ping ^^. Firewall'd out, maybe?
< Luke-Jr> oh :/
< jtimon> just looking at this part of the code...does anybody actually use -disablesafemode=true ?
< jtimon> never mind, I guess people do
< GitHub173> [bitcoin] dcousens opened pull request #7493: rpc: add null assert (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7493
< gmaxwell> law of nature that new RC means someone else finds a crasher bug.
< gmaxwell> (re #7491)