← Back to context Comment by amelius 2 years ago Could you name an example of how (and for what reason) this might happen? 8 comments amelius Reply mbakke 2 years ago 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? oever 2 years ago 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. mbakke 2 years ago 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? :-) 4 replies → mgaunard 2 years ago 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.
mbakke 2 years ago 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? oever 2 years ago 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. mbakke 2 years ago 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? :-) 4 replies →
oever 2 years ago 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. mbakke 2 years ago 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? :-) 4 replies →
mbakke 2 years ago 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? :-) 4 replies →
mgaunard 2 years ago 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.
Typically part of a "version string":
Perhaps a relic from when software had to be manually updated?
On NixOS, I think the release time or commit time is used:
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? :-)
4 replies →
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.