-
Notifications
You must be signed in to change notification settings - Fork 4k
Ensure that file modified time is set correctly #14444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure that file modified time is set correctly #14444
Conversation
Here's a
|
@lukebakken thank you. JSP is out on PTO this week, perhaps @lhoguin can help with a review :) |
Yeah I'm pretty sure @lhoguin is a good choice π |
328470d
to
6347323
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not 100% sure why TZ=
. TZ=
means that the system default timezone is used but that behavior varies between platforms.
It might be there to ensure that misconfigured systems can still build reproducibly.
If that's the case then TZ=UTC
might be better. But if doing that the part of the Makefile using the git-times.txt file likely needs updating so that UTC is used when updating timestamps with touch
at the end of the target (it also needs TZ=UTC
).
If this doesn't work and waiting is a bother then I'm OK with merging this for now and seeing with JSP when he gets back.
At least on Ubuntu 24, using git 2.43, the timestamps in the
I'll give that a try to see what happens! |
6347323
to
507a2ca
Compare
@lhoguin yep, that worked like a charm. I've updated the PR and associated commit log message. |
@lukebakken may I ask you to rebase this PR? That should fix the OCI job but @Zerpet and I can only verify it with a PR from an "external contributor" :) |
Commit e435bc6 introduced behavior in creating the source-dist archive that sets the file modification time to the same time as the most recent `git` commit. This facilitates reproducible builds, but it also has an issue. The code sets `TZ=`, which means that on systems running in time zones which aren't UTC, the modification time may be in the future (or past). It depends on the system's behavior. Up until recently, this only resulted in GNU make printing warnings about modification times being in the future. However, with recent changes in how escripts are built, this results in an "infinite make loop" that is described in rabbitmq#14440 and rabbitmq#14443 This solution is to set the `TZ=UTC` when calculating the time of the most recent `git` commit, as well as when using `touch -t` to set the file modification times. Fixes rabbitmq#14440, rabbitmq#14443
507a2ca
to
993322f
Compare
@michaelklishin done! |
@Mergifyio backport v4.1.x |
β Backports have been created
|
Perfect, thank you! |
For 4.1.5: Ensure that file modified time is set correctly (backport #14444)
The solution looks good to me. After reading git-log(1) again, I see that the datetime in Anyway, thank you! |
Commit e435bc6 introduced behavior in creating the source-dist archive that sets the file modification time to the same time as the most recent
git
commit. This facilitates reproducible builds, but it also has an issue. The code setsTZ=
, which means that on systems running in time zones which aren't UTC, the modification time may be in the future (or past). It depends on the system's behavior.Up until recently, this only resulted in GNU make printing warnings about modification times being in the future. However, with recent changes in how escripts are built, this results in an "infinite make loop" that is described in #14440 and #14443
This solution is to set the
TZ=UTC
when calculating the time of the most recentgit
commit, as well as when usingtouch -t
to set the file modification times.Fixes #14440, #14443