@jonasschnelli I don't want to break your debian box, so would you mind testing this after updating your gitian-builder to the latest version?

Ping @theuni

Concept ACK however:

There's a potential determinism problem with making the datetime depend on the bitcoin repository: the dependencies are built with datetime set to a single commit date, then cached, then next time they'll be reused. If the dependencies embed the datetime anywhere, different builders can get different result depending on when they built the dependencies.

Appears to be working:

$ curl https://bitcoin.jonasschnelli.ch/pulls/7256/bitcoin-0.12.99-linux64.tar.gz -s | tar ztv | head -3
drwxr-xr-x root/root         0 2015-06-01 02:00 bitcoin-0.12.99/
drwxr-xr-x root/root         0 2015-06-01 02:00 bitcoin-0.12.99/bin/
-rwxr-xr-x root/root   2470520 2015-06-01 02:00 bitcoin-0.12.99/bin/bench_bitcoin
$ curl https://bitcoin.jonasschnelli.ch/pulls/7283/bitcoin-0.12.99-linux64.tar.gz -s | tar ztv | head -3
drwxr-xr-x root/root         0 2016-01-04 12:11 bitcoin-0.12.99/
drwxr-xr-x root/root         0 2016-01-04 12:11 bitcoin-0.12.99/bin/
-rwxr-xr-x root/root   2470520 2016-01-04 12:11 bitcoin-0.12.99/bin/bench_bitcoin

Agree with @laanwj: would it be possible to build and cache the dependencies still with a fixed time?
Maybe first someone needs to check if the datetime results/gets included somehow in the dependencies.

BTW: Ugh. I think it was a mistake to add the build date there. It's worthless at most, and deceptive at the least.
If we want the date of last commit in there, would make sense to add it after the "Client version".

@laanwj I'm all for removing the build date and git commit from tagged releases. That would also mean that we could merge the signing steps, since the only reason they're staggered is the changed commit hash in the binary.

@jonasschnelli I believe we've already removed all time sources from the depends.

@laanwj I believe that would already be the case?

@laanwj I believe that would already be the case?

Faketime prevents that at the moment by setting the date/time stamp to a fixed value

Then, wouldn't stuff like be65628 break this as well?

Anyway, depends could use a different (static) date other than reference_datetime.

You're right, but be65628 is a one-time change. So dependencies built before and after that may differ. The problem with this is that the time/date will change every time.

Not sure it is an issue, but as this is a non-critical detail I'd like to be sure it doesn't cause problems down the line before merging it.

Needs rebase

@laanwj I've been running gitian builder to see if the results match:

So this appears to indicate that the result is independent from the cache of which commit created the cache.

@theuni Do you think this is ready to merge?

Sorry for the delay, testing this.

Yes, after taking a closer look, unfortunately this will not play nice with depends. Mostly because of the timestamps inside of tarballs, but also .a's and other problematic formats. Note that the end-results may or may not be the same, but the intermediates would differ.

We can revisit this later though, as options for tar/binutils/ld/etc have been added recently that reliably purge this data.

The only realistic thing I see that we can do here for now without a major overhaul would be to set the faketime once to a hard-coded date for depends, so that it remains the same regardless of the commit used, then reset for the bitcoin build itself.

set the faketime once to a hard-coded date for depends

@theuni Something like the last commit I pushed (untested)?

@MarcoFalke Yep, I think that approach should be fine.

Not sure why gitian fails on the windows build...

[gitian-builder]$ tail -8 var/build.log
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking whether the C++ compiler works... no
configure: error: in `/home/ubuntu/build/bitcoin':
configure: error: C++ compiler cannot create executables
See `config.log' for more details

[gitian-builder]$ ./libexec/on-target tail -5 ./build/bitcoin/config.log
#define PACKAGE_STRING "Bitcoin Core 0.12.99"
#define PACKAGE_BUGREPORT "https://github.com/bitcoin/bitcoin/issues"
#define PACKAGE_URL "https://bitcoincore.org/"

configure: exit 77

Can one of the admins verify this patch?

I think it would be better to remove use of the build date in our binary completely, making the use of faketime unnecessary. We don't have control over that for the dependencies but we do for our own code.

If you want the date/time of the last commit somewhere in the binary there are better ways to do that (e.g. through genbuild.sh) than a faketime.

The motivation for this pull was to avoid regular "bump date" pulls such as #7251 (comment).

The build date was removed in #7732 and I don't think we should add the commit date to the gui.

If this pull gets closes, it might be worth to update https://github.com/bitcoin/bitcoin/blob/950be19727a581970591d8f8138dfe4725750382/doc/release-process.md#bitcoin-maintainersrelease-engineers-update-version-in-sources and mention to bump the date in the same go.

There's another place where this matters: the times/dates in the .zip files and .tar.gz archives of the binary distribution. I guess that makes it worth doing this.

The build date was removed in #7732

Only from the GUI though. It's still logged in two places:

src/init.cpp:    LogPrintf("Bitcoin version %s (%s)\n", FormatFullVersion(), CLIENT_DATE);
src/wallet/rpcdump.cpp:    file << strprintf("# Wallet dump created by Bitcoin %s (%s)\n", CLIENT_BUILD, CLIENT_DATE);

If this pull gets closes, it might be worth to update

Well my point was more 'why would we care about this'. If there is no reason to care about this date at all, there's no point in bumping it either. E.g. after making sure it doesn't get shown in the GUI or log anymore.
But I suppose the dates in archives are a reason to care that it is somewhat up to date. It looks stupid to have files from 1970.