< luke-jr> "Syncing Headers (%1%)…" <-- is this valid?
< luke-jr> wumpus: is update-translations.py not giving you an assert in check_format_specifiers for zh_TW?
< cfields> achow101: we've got a mismatch on osx. rebuilding mine.
< achow101> cfields: ok. I'll run it again too. Are we still using the osx 10.11 sdk?
< cfields> achow101: yes. I suspect that we probably have different versions of the sdk.
< achow101> I've been using the same version of the sdk for a long time now
< cfields> achow101: ah, I was thinking it was bumped from 0.13, but it's not.
< achow101> so I don't need to re-run?
< cfields> achow101: let's both re-run and see what happens
< achow101> alright
< cfields> (unless it's inconvenient for you)
< achow101> no, it's fine, I can re-run it
< achow101> cfields: I got the same results
< cfields> achow101: me too :(
< achow101> uh oh
< cfields> we need a 3rd builder...
< cfields> achow101: can you drop your bitcoin-0.14.0-osx64.tar.gz somewhere?
< achow101> sure
< cfields> thank
< cfields> s
< cfields> looks like there may be non-determinism there
< achow101> maybe it's caches?
< cfields> we both had empty caches this time
< cfields> Binary files bitcoin-0.14.0-me/bin/bitcoin-qt and bitcoin-0.14.0-achow/bin/bitcoin-qt differ
< cfields> will see if i can track it down. maybe something new in qt 5.7
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/12f46fa7d87d...50a226563cd8
< bitcoin-git> bitcoin/master 8e5cca0 Cory Fields: gitian: bump descriptors for master...
< bitcoin-git> bitcoin/master 50a2265 MarcoFalke: Merge #9788: gitian: bump descriptors for master...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9788: gitian: bump descriptors for master (master...gitian-bump-0.15) https://github.com/bitcoin/bitcoin/pull/9788
< cfields> achow101: can you: find MacOSX10.11.sdk/ -type f -exec sha256sum {} >> sdk.sha256 \;
< cfields> in particular, i think we might have differing libobjc.A.tbd
< achow101> where should this file/folder be?
< cfields> achow101: don't worry about it, i'll just grab a fresh sdk and rule it out
< achow101> found it (i've never extracted the sdk tar before)
< luke-jr> isn't the SDK always different?
< luke-jr> I guess that's probably just the tar format
< achow101> this is the hash for libobjc.A.tbd: ef9438dc380ce92cf82538ef483fdbf96743b5f8907c752def4a6d922f822ec6
< cfields> achow101: damn, same
< cfields> luke-jr: yea, contents should be the same
< achow101> cfields: here's the link to the entire sdk.sha256 file: https://drive.google.com/file/d/0Bxw3ip9QfNOUWWtNb2Z6VC1hRXc/view?usp=sharing
< cfields> achow101: hmm, they match up
< cfields> ok, time to dig into hex/disasm
< sipa> cfields: are there any locks protecting CAddrDB and CBanDB?
< sipa> DumpBanList or any of its callees never grab any locks
< sipa> ah, but it writes a copy
< cfields> sipa: it's only grabbed in Start() iirc
< sipa> less sure about DumpAddresses
< sipa> ah, but addrman has its own lock
< achow101> cfields: any luck?
< cfields> achow101: not yet
< bitcoin-git> [bitcoin] sipa opened pull request #9792: FastRandomContext improvements and switch to ChaCha20 (master...chacha) https://github.com/bitcoin/bitcoin/pull/9792
< cfields> achow101: any chance you could grab the .o files from your gitian environment?
< gmaxwell> sipa: re random, seeding is a lot more of an interesting issue... that patch feels like sideways motion to me. sounds fine and all but doesn't obviously get rid of openssl.
< sipa> gmaxwell: sure... 1) make fastrandomcontext stronger 2) move some uses that now use getrandbytes to fastrandomcontexts 3) move everything else to a single secure RNG 4) make that single secure RNG not be OpenSSL
< sipa> when every use of the strong RNG reads from /dev/urandom etc, i feel we can avoid a lot of the complexity in it (gathering entropy etc)
< sipa> s/gathering/background/
< achow101> cfields: I don't think so
< cfields> achow101: ok
< gmaxwell> Making fastrandomcontext robust agaist VM restore, forward/backward prediction will make it slow.
< sipa> gmaxwell: don't use fastrandomcontext in places where it needs to be robust
< sipa> we don't need VM robustness for determining the filename we temporarily write the addrman db to
< sipa> (which currently uses GetRandBytes)
< gmaxwell> We don't, I agree. But review what you just said above!
< sipa> 2) move *some* uses that now use getrandbytes to fastrandomcontexts
< gmaxwell> okay I looked through the usage of GetRand* and I'm less skeptical.
< gmaxwell> The ones where we need better properties we can use something fantastically slow.
< sipa> right, anything that constructs an actual secret key usually just runs once during the whole application (cache blinding keys, wallet keys, ...)
< sipa> for ping nonces i don't think that VM restores are that much of a deal
< cfields> sigh, best i can tell the linker is reordering some symbols
< cfields> don't know how we could be running into that now and not before, though
< achow101> it would be great if someone else could also do a gitian build :/
< cfields> yea :(
< cfields> I'm going to have to throw in the towel for tonight. I'll pick it up again tomorrow. Will be much easier with a third data point.
< bitcoin-git> [bitcoin] kobake opened pull request #9793: Vs2015 wip (master...vs2015-wip) https://github.com/bitcoin/bitcoin/pull/9793
< bitcoin-git> [bitcoin] kobake closed pull request #9793: Vs2015 wip (master...vs2015-wip) https://github.com/bitcoin/bitcoin/pull/9793
< luke-jr> achow101: pushed my sigs
< luke-jr> which match cfields's
< achow101> :(
< cfields> woohoo!
< achow101> nuked cache and input (except for sdk). trying again
< cfields> achow101: double-check your sdk? The only thing I can come up with other than ld64 constructing the indirect symbol table in a non-deterministic order, is that your sdk has a different stub which leads to a different layout
< luke-jr> my guess would be something with his VM
< cfields> luke-jr: thanks, btw
< luke-jr> np, sorry I'm late
< cfields> luke-jr: i'm not sure what could matter, other than filesystem or locale
< achow101> how do I check the sdk? I don't really have a way to get another one
< cfields> but i'd think those would cause many issues, not just these
< achow101> (short of someone sending me one)
< cfields> achow101: the dump you gave me matches mine. Just make sure that's really the one you're using
< cfields> achow101: lxc or kvm?
< achow101> kvm
< cfields> ok
< * luke-jr> is also KVM
< cfields> yes, same
< achow101> lxc stopped working for me a long time ago. I still have an issue open somewhere about it
< achow101> the sdk is definitely the same. my original and the one in inputs have the same sha256sum
< fanquake> achow101 can you post the sha here?
< achow101> 9f950cd715b58b0ae002ec47bf2fe7ed76857d4f7b0b3520ae2820082b3e41ce
< fanquake> That's the sha256 of MacOSX10.11.sdk.tar.gz ?
< achow101> yep
< fanquake> Weirdly mine does not match.
< achow101> should it?
< fanquake> I see 57a69e69bec23aa190b9ca50726df1ca8bc3d68d70094868211dcbeeb477db91
< fanquake> I'll wait until my builds done. Should only be a few more minutes.
< luke-jr> fanquake: it doesn't normally match
< luke-jr> MacOSX10.11.sdk.tar.gz is not itself typically deterministic because we make it on our own
< achow101> build finished, got the exact same results
< achow101> fanquake: your build done yet?
< fanquake> achow101 yep, one sec.
< fanquake> achow101 heh my osx sigs match yours.
< fanquake> 8c42c1f996935fc0f2a13616d8b0f557594b23588e7781f72c9ebe53ef097cbd bitcoin-0.14.0-osx-unsigned.dmg
< achow101> well shit
< luke-jr> O.o
< luke-jr> timezone?
< achow101> how would that matter?
< luke-jr> dunno, just guessing cfields and I are probably in the same one and you two might not be
< achow101> could the version of gitian matter?
< fanquake> Just PR'd my sigs, if you want to take look.
< fanquake> Not sure about timezone. I'm using latest gitian.
< achow101> I think I'm using the latest. hash: ad3f9cc4c2c8c0899961a366f5b9fbd1483b0ee3
< fanquake> Building with VirtualBox on OS X. Basically using the build-guide in doc.
< fanquake> Yep, same. "Merge #135: Fixes Debian jessie lxc-init path issue".
< gribble> https://github.com/bitcoin/bitcoin/issues/135 | [mac os x] Crash on exit · Issue #135 · bitcoin/bitcoin · GitHub
< luke-jr> I'm on ee1b69d Merge #122: Allow build to use sudo without a password, part deux
< gribble> https://github.com/bitcoin/bitcoin/issues/122 | Spent per txout by sipa · Pull Request #122 · bitcoin/bitcoin · GitHub
< achow101> oh well. I'm going to sleep now
< luke-jr> night
< bitcoin-git> [bitcoin] mitchellcash opened pull request #9794: Minor update to qrencode package builder (master...minor_depends_fix) https://github.com/bitcoin/bitcoin/pull/9794
< wumpus> luke-jr: I fixed that assertion problem recently
< luke-jr> ?
< luke-jr> oh
< luke-jr> thanks
< wumpus> apparently my for gitian output for linux mismatches
< wumpus> windows matches, and osx too (except for achow101)
< wumpus> linux: looks like only the x86_64 output mismatches - aarch64, arm, i686 are the same
< wumpus> cfields: your gitian assert package overview has "Reading package lists..." ""Building dependency tree..." apt command output in it
< wumpus> my assert has *three* versions of g++-4.8 in it:g++-4.8_4.8.2-19ubuntu1_amd64.deb, g++-4.8_4.8.4-2ubuntu1~14.04.1_amd64.deb, g++-4.8_4.8.4-2ubuntu1~14.04.3_amd64.deb ... that seems overkill
< wumpus> that almost must be the problem, will try to clean it up
< wumpus> the base image that is, not the assert file :)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/50a226563cd8...8efd1c820b9a
< bitcoin-git> bitcoin/master a432aa0 Takashi Mitsuta: Remove unused module from rpc-tests
< bitcoin-git> bitcoin/master 8efd1c8 MarcoFalke: Merge #9744: Remove unused module from rpc-tests...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9744: Remove unused module from rpc-tests (master...remove-unused-modules-from-rpc-tests) https://github.com/bitcoin/bitcoin/pull/9744
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #9795: doc: Update manpages for master (laanwj) (master...Mf1602-docManMaster) https://github.com/bitcoin/bitcoin/pull/9795
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8efd1c820b9a...aa5fa642b0e7
< bitcoin-git> bitcoin/master 0c9b9b7 practicalswift: [trivial] Fix recently introduced typos in comments
< bitcoin-git> bitcoin/master aa5fa64 MarcoFalke: Merge #9696: [trivial] Fix recently introduced typos in comments...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9696: [trivial] Fix recently introduced typos in comments (master...fix-recently-introduced-typos) https://github.com/bitcoin/bitcoin/pull/9696
< wumpus> ok, above gitian issue was solved by rebuildling with a new base image
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/aa5fa642b0e7...7ff4a538a868
< bitcoin-git> bitcoin/master 1581ecb John Newbery: Use configparser in rpc-tests.py...
< bitcoin-git> bitcoin/master 91bffff John Newbery: Use argparse in rpc_tests.py...
< bitcoin-git> bitcoin/master afd38e7 John Newbery: Improve rpc-tests.py arguments...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9657: Improve rpc-tests.py (master...improvepytests2) https://github.com/bitcoin/bitcoin/pull/9657
< cfields> wumpus: so your sigs match mine now?
< achow101> I'm going to be away from my build computer today so I won't be able to help
< cfields> ok
< cfields> i guess if we have 3 matches we can go with that one, but we really need to figure out why we're getting 2 different results
< achow101> I tried remaking the base vm and rebuilding before I left but I was having issues with making it
< cfields> achow101: thanks for trying
< cfields> wumpus: please confirm if you'd like me to go ahead and push the sigs for the one we've got. the fact that achow101 and fanquake have matching mismatches for osx is a bit worrisome
< MarcoFalke> "matching mismatches", heh.
< MarcoFalke> going to run the osx gitian, lets see what my result is...
< cfields> ok, i'm going to go ahead and push
< cfields> we need to try to figure out what the discrepancy is before rc2, though
< cfields> gitian builders: detached osx/win sigs for 0.14.0rc1 pushed.
< cfields> achow101 / fanquake: not sure what to tell you yet, i'll keep trying to get it pinned down
< wumpus> cfields: yes, let's try to continue. It's strange that macosx apparently isn't determinstic, but that's no reason to not go on with the other platforms for rc1
< wumpus> would be nice to sort this out before final, of course
< luke-jr> [13:09:35] <wumpus> ok, above gitian issue was solved by rebuildling with a new base image <-- eh, not sure this is a good resolution :|
< luke-jr> thoughts on a GUI screen showing what #bitcoin-watch used to? https://en.bitcoin.it/wiki/Bitcoin-Watch
< luke-jr> (minus the trade info I guess)