gitian: make linux qt intermediate deterministic #4270

A qt installation date snuck into the host utils (lrelease etc). This doesn't affect the end product, so no dependency version bump.

It also doesn't explain why gavin's and mine bitcoin-qt build is different: https://github.com/bitcoin/gitian.sigs/blob/master/0.9.2rc1/laanwj/bitcoin-build.assert https://github.com/bitcoin/gitian.sigs/blob/master/0.9.2rc1/gavinandresen/bitcoin-build.assert

Let's wait for some further gitian builds to see if they converge into two groups, or everyone gets wildly different output.

I've managed to reproduce @gavinandresen 's gitian build by adding the libqt4-dev package to the gitian-linux.yml. Seemingly the gitian linux build picks the globally installed qt4 headers (Qt 4.8.x) before the locally compiled ones (4.6.x).

This sucks a lot because we make it compile against the Qt 4.6.x headers to be compatible with older linux distros, and they get ignored here.

We define both

• --with-qt-bindir=$STAGING/bin
• PKG_CONFIG_PATH="$STAGING/lib/pkgconfig"

In theory this should be enough to make it pick our headers. @theuni any idea how to force the build to use our Qt headers even harder?

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/1411a51feffe327956350417079104f573caeb5d 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.

Ok, I see what's happening. We don't install this to our real prefix, we just dump it into $HOME/install. This needs to be installed to the same paths as everything else in order for our configure to pick it up. Else, configure needs to point to $HOME/install/* instead for qt stuff.

Nm, spoke too soon. That is our actual prefix in linux.