Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Warn if $SOURCE_DATE_EPOCH is in the future
If $SOURCE_DATE_EPOCH < 0, warn and ignore. If $SOURCE_DATE_EPOCH > now, warn and continue. In a build of fityk-1.3.2-8.fc41, the result was: fityk-devel-1.3.2-8.fc41.x86_64 modified-..........T /usr/include/fityk modified-..........T /usr/include/fityk/fityk.h modified-..........T /usr/include/fityk/ui_api.h modified-..........T /usr/lib64/libfityk.so modified-..........T /usr/share/fityk/samples/hello.cc Since we clamp mtimes to $SOURCE_DATE_EPOCH, we don't see a T mismatch very often. This result was a combination of two factors: - the package has "bespoke" autotools-based build system which doesn't preserve timestamps when copying files, - the maintainer made an off-by-one in the changelog datestamp and at the time of the koji build, $SOURCE_DATE_EPOCH which was generated from the changelog entry was higher than the system clock. (It's possible that the date _appeared_ correct in the maintainer's local time zone and it was already after midnight.) So in the koji build, we got the time of the build as final mtimes, because clamping was not performed on timestamps which were lower than the $SOURCE_DATE_EPOCH. When the build was repeated later, the build timestamps were higher than $SOURCE_DATE_EPOCH, so clamping was performed, and we got $SOURCE_DATE_EPOCH as mtimes. It took me much longer to figure this out than it should have. Add a warning when $SOURCE_DATE_EPOCH is either negative or in the future to make such cases easier to diagnose.
- Loading branch information