-
Notifications
You must be signed in to change notification settings - Fork 353
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
Increment build date every release #2677
Increment build date every release #2677
Conversation
for %source_date_epoch_from_changelog to avoid breaking rsync without --checksum or anything else that relies on modification time stamp of files to detect changes. Only use the number at the start of the string for this. To ensure clamping mtime still works the date needs to be in the past, so a day is substracted. Because the release is a string with multiple version components, it could be much bigger than a unix time stamp. E.g. in Fedora 3.fc40 is common. And there are packages that are not touched for years. So even only including the 40 would reduce the available numbers for rebuilds too much, e.g. for 3*40, then one day of SOURCE_DATE_EPOCH only leaves space for a release up to 2160.fc40 ( =60*60*24/40 ). So only use the 3 in this example to increment the date. SOURCE_DATE_EPOCH (see https://reproducible-builds.org/docs/source-date-epoch/ ) should be increased every time the build output changes. Rebuilds with different build dependencies do not necessarily have a new changelog entry. To ensure that it increases increment the SOURCE_DATE_EPOCH by the release number. The reason for it is that when it does not increase there may be complications. When %clamp_mtime_to_source_date_epoch and %source_date_epoch_from_changelog are enabled and a rebuild is done with different build dependencies a file may have different content but with the same mtime. When two releases of this rpm are extracted after each other at the same location and the extracted files are synced with rsync without --checksum, then the resulting copy will contain a mix of files from the old and new build. This can happen on installed systems due to updates when it is then backed up with rsync. While it is not safe generally safe to rely on mtimes and thus nor to backup systems without --checksum, we should not unnecessarily break things. We came across this problem because this happens for rpm repos from OpenSUSE that have extracted files used for installing from a repo, which get broken when mirroring with rsync, see https://bugzilla.suse.com/show_bug.cgi?id=1148824 .
d29950a
to
873e2c4
Compare
The fix is to not clamp buildtime to SOURCE_DATE_EPOCH (i.e. don't set |
Oh, I misunderstood, this is about files inside of the package, not the RPM itself. I don't think this change is a valid one, because you're basically asking for RPMs to be automatically because your process flow includes automatic rebuilds that don't bump changelogs. That's what setting |
The correct fix for openSUSE is that the OBS builder should generate a new |
Are rebuilds with changed dependencies but unchanged source never done for Fedora? |
The changelog bumps for every build, even no-change rebuilds. |
There is also an error in this as OBS increases the second number of release, like 1.2 -> 1.3 . Will implement in obs-build instead. |
for %source_date_epoch_from_changelog to avoid breaking rsync without --checksum or anything else that relies on modification time stamp of files to detect changes. Only use the number at the start of the string for this. To ensure clamping mtime still works the date needs to be in the past, so a day is substracted.
Because the release is a string with multiple version components, it could be much bigger than a unix time stamp. E.g. in Fedora 3.fc40 is common. And there are packages that are not touched for years. So even only including the 40 would reduce the available numbers for rebuilds too much, e.g. for 340, then one day of SOURCE_DATE_EPOCH only leaves space for a release up to 2160.fc40 ( =6060*24/40 ). So only use the 3 in this example to increment the date.
SOURCE_DATE_EPOCH (see
https://reproducible-builds.org/docs/source-date-epoch/ ) should be increased every time the build output changes. Rebuilds with different build dependencies do not necessarily have a new changelog entry. To ensure that it increases increment the SOURCE_DATE_EPOCH by the release number.
The reason for it is that when it does not increase there may be complications. When %clamp_mtime_to_source_date_epoch and %source_date_epoch_from_changelog are enabled and a rebuild is done with different build dependencies a file may have different content but with the same mtime. When two releases of this rpm are extracted after each other at the same location and the extracted files are synced with rsync without --checksum, then the resulting copy will contain a mix of files from the old and new build. This can happen on installed systems due to updates when it is then backed up with rsync. While it is not safe generally safe to rely on mtimes and thus nor to backup systems without --checksum, we should not unnecessarily break things. We came across this problem because this happens for rpm repos from OpenSUSE that have extracted files used for installing from a repo, which get broken when mirroring with rsync, see
https://bugzilla.suse.com/show_bug.cgi?id=1148824 .