Honor SOURCE_DATE_EPOCH for the rpm %changelog date - #2155
Open
linus-mullvad wants to merge 1 commit into
Open
Conversation
FPM::Package::RPM#changelog reads attributes[:source_date_epoch], but the only code resolving --source-date-epoch-default (and thus the SOURCE_DATE_EPOCH environment variable) into that attribute lived in FPM::Package::Deb#output. So the rpm output dated the entry it generates from the wall clock, and since rpm parses that date into the CHANGELOGTIME header, the same input packaged on two different days produced two different rpms. Move the precedence into FPM::Package#source_date_epoch, so every package type gets the same answer, and read that from the deb and rpm code. An input type that discovers a release date of its own still wins, as FPM::Package::Gem does. The deb changelog and .changes templates read the attribute directly and relied on Deb#output having overwritten it first, so they read the accessor now too. Without that they would have gone back to dating themselves from the wall clock. Also format these dates in UTC. SOURCE_DATE_EPOCH is defined as UTC, but strftime rendered it in the local time zone, so a build machine east of UTC could name the following day. Only the fixed-epoch case changes; when no epoch is given the timestamp is still local wall clock time.
This was referenced Jul 30, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2154
FPM::Package::RPM#changelogreadsattributes[:source_date_epoch], but the only code resolving--source-date-epoch-default(and thus theSOURCE_DATE_EPOCHenvironment variable) into that attribute lived inFPM::Package::Deb#output. So the rpm output dated the entry it generates from the wall clock, and since rpm parses that date into theCHANGELOGTIMEheader, the same input packaged on two different days produced two different rpms.Move the precedence into
FPM::Package#source_date_epoch, so every package type gets the same answer, and read that from the deb and rpm code. An input type that discovers a release date of its own still wins, asFPM::Package::Gemdoes.The deb changelog and .changes templates read the attribute directly and relied on
Deb#outputhaving overwritten it first, so they read the accessor now too. Without that they would have gone back to dating themselves from the wall clock.Also format these dates in UTC.
SOURCE_DATE_EPOCHis defined as UTC, but strftime rendered it in the local time zone, so a build machine east of UTC could name the following day. Only the fixed-epoch case changes; when no epoch is given the timestamp is still local wall clock time.