Hacker News new | past | comments | ask | show | jobs | submit login

Don't you have to fake the system time to do this? The time often ends up inside the binaries one way or another.



Indeed time stamps are probably the most common sources of indeterminism. So common that a de-facto standard variable to fake a timestamp has been implemented in many compilers:

https://reproducible-builds.org/docs/source-date-epoch/


Could you name an example of how (and for what reason) this might happen?


Typically part of a "version string":

    $ python3
    Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>>
Perhaps a relic from when software had to be manually updated?


On NixOS, I think the release time or commit time is used:

    $ python3
    Python 3.10.11 (main, Apr  4 2023, 22:10:32) [GCC 12.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 
That is more useful than the build time.


How is that possible? Is nixpkgs an input to the Python derivation? Or do packagers "hard code" a value every time they modify the Python build code? Automated tooling that sets it after pull requests? Something else? :-)


GCC respects SOURCE_DATE_EPOCH, and Nixpkgs has specific support for setting that environment variable: https://github.com/NixOS/nixpkgs/blob/92fdbd284c262f3e478033... (although I haven't proved that this is actually how it works for cpython's build).

Irrelevant spelunking details follow:

That string is output by cpython to contain the contents of the __DATE__ C macro (https://github.com/python/cpython/blob/fa35b9e89b2e207fc8bae... which calls to https://github.com/python/cpython/blob/fa35b9e89b2e207fc8bae... which uses the __DATE__ macro at https://github.com/python/cpython/blob/fa35b9e89b2e207fc8bae... ).

Cpython is defined in nixpkgs at https://github.com/NixOS/nixpkgs/blob/92fdbd284c262f3e478033... which I imagine (but haven't proved) uses GCC.


Thank you! Setting SOURCE_DATE_EPOCH to the most recent file timestamp found in the source input is a clever hack.


The source for the cpython build is the release tarball (https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...).

In that case, NixOS sets SOURCE_DATE_EPOCH (which I suspect will be picked up by the python build) to the latest timestamp found in that archive (https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...)


2023-04-04T22:10:32 is the timestamp of Python-3.10.11/Misc/NEWS from https://www.python.org/ftp/python/3.10.11/Python-3.10.11.tar...


GCC embeds timestamps in o/gcno/gcda files to check they match.

It's mostly annoying as gcov will actively prevent you from using gcda files from a different but equivalent binary than what generated the gcno.


You would just either not include the timestamp at all in all builds, or set 0, so the build date is 1970 everywhere.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: