< 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
< 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
< 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)
< 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