It is not necessary to rebuild dependencies after this commit.
Fixes #3610 and #3612.
26 | + # A security fix in QHash makes the ordering of keys to be different on every ru 27 | + # (https://qt.gitorious.org/qt/qtbase/commit/c01eaa438200edc9a3bbcd8ae1e8ded058bea268). 28 | + # This is good in general but qrc shouldn't be doing a traversal over a randomized container. 29 | + # The thorough solution would be to use QMap instead of QHash, but this requires patching Qt. 30 | + # For now luckily there is a test mode that forces a fixed seed. 31 | + export QT_RCC_TEST=1
Why do you add this here? What exactly does it do, if you say rebuilding isn't necessary?
Hmm yes maybe it is necessary.
Okay -- in that case, don't forget to increment the dependency version.
35 | @@ -36,6 +36,14 @@ script: | 36 | INDIR=$HOME/build 37 | OPTFLAGS='-O2' 38 | NEEDDIST=1 39 | + # Qt: workaround for determinism in resource ordering 40 | + # Qt5's rcc uses a QHash to store the files for the resource. 41 | + # A security fix in QHash makes the ordering of keys to be different on every ru
Small typo on every run.
Sure, if there are some final instructions available that I can follow. As far as I remember, Gavin said he is currently writing on a doc?
20 | @@ -21,6 +21,14 @@ script: | 21 | # Defines 22 | export TZ=UTC 23 | INDIR=$HOME/build 24 | + # Qt: workaround for determinism in resource ordering 25 | + # Qt5's rcc uses a QHash to store the files for the resource. 26 | + # A security fix in QHash makes the ordering of keys to be different on every ru
Same here...
At least rebuild Qt after this. I'm not 100% sure that it is needed, but there is a large chance that Qt itself is also using the resource compiler somewhere.
ACK
- Add 'g++' package (virtualbox images don't have this by default)
- Workaround for determinism in Qt5 resources
- Pass --disable-maintainer-mode --disable-dependency-tracking to
configure for libqrencode to avoid random errors about missing m4
directory
- Fix typo -with-pic -> --with-pic
It is not necessary to rebuild dependencies after this commit.
Fixes #3610 and #3612.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/65615a3a784c01128b408a915ab375c35640fb0a for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
This seems to fix at least all the determinism issues on KVM. I built the entire chain (including all dependencies) twice and ended up with the same result:
763b94cd7fd717ec8838593f18743e4612a445cfe9622a7b14ef8d4a5077bae6 32/bitcoin-0.9.0-win32-setup.exe
778c489114209254a27d095ff56b4b6638092c58e2e277cdf3ce06056c5e81ff 32/bitcoin-cli.exe
023ad348dbe06a172b80d49bca9151c950d8485cc215ec0dc048a6c8a522c2c0 32/bitcoin-qt.exe
e549386338608ddfc3a8d551dd4638d216e0d6d05995737577b9b50e34a0c986 32/bitcoind.exe
057c990265b43c80178aa16fa18f6bacf5f3b0e1212ca55b77356b09122e1aa4 32/test_bitcoin-qt.exe
e65c38b013aca3506742c674c18fb0689792e51cae0af06cb96f10d6084071d9 32/test_bitcoin.exe
d1031fd597ba17a42d3da79e646cb8700fd76ab22d1b88a998024344f6b85af4 64/bitcoin-0.9.0-win64-setup.exe
0eaf0edcb173729fe3b416a95a704ed1415ae2874f6ea4b293f4177724d9e0f1 64/bitcoin-cli.exe
9c76db95dc4d6fd6a771c021e96e6b1d657cb29abadb92d47546247792be270e 64/bitcoin-qt.exe
bc2252edadfd63a82fe0fced4c8969e0bf07cf30a6727310746f85b7a3713437 64/bitcoind.exe
930597e75fad4455fc4253b5f2829933b7cfde48a679c28cf9aa57d57f8c773d 64/test_bitcoin-qt.exe
0dcfd1cc22cf6cb9e2554f22aa1502891fd1c22f29bd745b2a8497b9fe4c094b 64/test_bitcoin.exe
24798a99e86d54e1b45294a67ed22b836a2572fcf160cca1c5cf45884e9aca45 src/bitcoin-0.9.0.tar.gz
Edit: now going to try with LXC and see if it different (and if so, why).
I've written down the steps I had to follow to get the LXC build to work on Ubuntu 12.04: https://gist.github.com/laanwj/8787944
@laanwj Hm, what's wrong with doing it the way @devrandom suggests in his README, with these commands:
sudo brctl addbr br0
sudo ifconfig br0 10.0.2.2/24 up
?
Other than that, I don't see anything different in your gist relating to the build itself. Any idea what the difference might be?
I've rebuilt the entire dependency chain in LXC and got the same result as above. So, seems deterministic.
Edit: nothing is wrong with @devrandom's way, but I wanted to use the lxcbr0 device provided by Ubuntu itself instead of creating a new one. This will not make a difference to the executable.
@gavinandresen I've merged this, but I'm not sure how to do proceed. Can/should we re-tag rc1 to make sure that people build with these gitian descriptors?
Best to just consider rc1 dead, bump version numbers, and jump to rc2.
Hm, let's wait a bit. I'm not getting deterministic builds for Linux. (juist built everything twice w/ LXC, only bitcoin-cli and test_bitcoin are the same)
OK on waiting a bit; we should make sure we can cobble together builds that match before bumping version numbers.
FYI: I'll be out Wed-Fri this week, headed down to Princeton and DC.
Let's try to get it ready today then. I figured out the cause of non-determinism (OpenSSL embeds a timestamp, should use faketime during OpenSSL build).