build: fix release name strings for gitian builds #4946

Fixes #4819

This is a short-term fix. I'd like to address the current tangled version/string logic, but my attempts so far haven't actually improved the situation.

Fix the symptom for now.

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

utACK

I'm not sure this is the best way to go. Looking through the parent directories of the current directory for a .git directory is hardly more elegant than assuming it is in the current directory. share/genbuild.sh takes a srcroot argument, could we use that to determine where to look for the .git directory?

Yea, that's what makes this so twisty. When we build from this dir, we're not actually in a git repo, we're in an extracted tarball. That's done to ensure that we're building from the same release tarball that we actually distribute.

So, the srcroot doesn't actually have a .git dir in it either. It only works because we've extracted this dir below a git repo.

What needs to happen is that a new file is created for tarballs, which is used as a fall-back when not using git. Similar to how git-version-gen scripts work. Like I said, I hacked on that some, but it only tangled things further.

If you'd like to ignore this and wait for a rework of the logic that's fine, I just didn't want to ignore the broken-ness for now. If nothing else, this fixes gitian builds.