Pick up date from SOURCE_DATE_EPOCH, for reproducible builds #874
Conversation
| @@ -80,6 +80,10 @@ along with this program; if not, see <http://www.gnu.org/licenses/>. | |||
| #define HOMEPATH_NAME_MACOSX HOMEPATH_NAME_WIN | |||
| #endif | |||
|
|
|||
| #ifndef SOURCE_DATE | |||
There was a problem hiding this comment.
Can you add this to the shared/qcommon/ folder instead? Perhaps in q_platform.h if you think it fits there.
I want to try to avoid duplication of code between the code/ and codemp/ folders as much as possible.
There was a problem hiding this comment.
Can you add this to the
shared/qcommon/folder instead?
Done. Could you re-review, please?
The goal of reproducible builds is that a rebuild of the same source code with the same compiler, libraries, etc. should result in the same binaries. SOURCE_DATE_EPOCH provides a standard way for build systems to fill in the date of the latest source change, typically from a git commit or from metadata like the debian/changelog in Debian packages. This does not change anything if SOURCE_DATE_EPOCH is not defined; the intention is that a larger build system like a Debian package will define it. Please see https://reproducible-builds.org/ for more information about reproducible builds. Similar to <ioquake/ioq3#225>.
smcv
force-pushed
the
reproducible-date
branch
from
a657d2c
to
829b049
Compare
|
Updated commit moves |
|
I'll let @xycaleth merge this one since the changes requested were his. |
|
@xycaleth, any further comment on this? I think I've done what you asked. I am not aware of a way to clear the "changes requested" flag (I'm surprised it wasn't cleared by me pushing a new version actually). |
|
I'm not sure what I commented on a few months ago, but it all looks good to me now. |
You didn't like the definition of |
|
Personally I don't like the change in behavior anyway. It would make more sense to have a way to check the ~~~source~~~ commit date and hash. The build date is preferable for most people. TimeDoctor got confused as to why the date in the builds was way wrong (relative to his pov in terms of build date) for a while sometime after you merged that in ioq3. |
Er, unless I got something very wrong, if you don't define
Those people shouldn't define |
|
https://reproducible-builds.org/specs/source-date-epoch/ explains this better than I can. |
|
"These people". Sure, but the default ("official") builds have it defined in ioquake3 which cause(s)/(d) confusion in the past. |
Oh, that's news to me... I didn't expect they'd do that. Presumably it's taken from the commit timestamp, like I mentioned as a possibility in this PR? My interest in this is only that I want to enable it for the builds in Debian, as a step towards improving confidence that if our autobuilders were compromised and made to produce malicious packages, we'd detect it (a lot of other infrastructure is needed for that, but that isn't something that needs to be done per-package, whereas adding |
Pick up date from SOURCE_DATE_EPOCH, for reproducible builds Former-commit-id: 6fb1cab
Pick up date from SOURCE_DATE_EPOCH, for reproducible builds
The goal of reproducible builds is that a rebuild of the same source
code with the same compiler, libraries, etc. should result in the same
binaries. SOURCE_DATE_EPOCH provides a standard way for build systems
to fill in the date of the latest source change, typically from a git
commit or from metadata like the debian/changelog in Debian packages.
This does not change anything if SOURCE_DATE_EPOCH is not defined;
the intention is that a larger build system like a Debian package
will define it.
Please see https://reproducible-builds.org/ for more information about
reproducible builds.
Similar to ioquake/ioq3#225.
If desired you could use this in your buildbot's script by setting the environment variable
SOURCE_DATE_EPOCHto the number of seconds since 1970-01-01 00:00 UTC (the Unix epoch), for example fromgit show --pretty=format:%ct --no-patchto use the commit timestamp of the latest commit.