Only add the time zone offset once #977
Closed
Conversation
This file contains 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
when computing the time of a changes entry in changelog2spec. This avoids getting a date in the future which would fail when using it for SOURCE_DATE_EPOCH for reproducible builds. Such failures happened when we tried using it with openSUSE/post-build-checks#58 . Example failure from build log: setting SOURCE_DATE_EPOCH to 1698749844 ERROR SOURCE_DATE_EPOCH is in the future, clamping mtime if used might fail in hard to notice way, returning error "Mon Oct 30 12:36:34 CET 2023" in .changes results in SOURCE_DATE_EPOCH=1698669395 but that's Mon 30. Oct 12:36:35 UTC 2023 Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1216738
JanZerebecki
added a commit
to JanZerebecki/post-build-checks
that referenced
this pull request
Feb 1, 2024
replacing rpm its %source_date_epoch_from_changelog . This instead also increments the date by the build counter, which OBS puts into the release field of rpm. When available it uses the mtime that OBS its scmsync obtains from the git HEAD commit date instead of from the changelog. All this can be disabled by setting the rpm macro %disable_obs_set_source_date_epoch to Y . This uses new variables in /.buildenv that were implemented in openSUSE/obs-build@5d1da85 . See https://reproducible-builds.org/docs/source-date-epoch/#interaction-of-source_date_epoch-with-automatic-rebuilds for more general discussion. Increasing the date by the build counter is necessary, so that that even for rebuilds with unchanged source but updated build depends the date is always increased, such that no build with a different input/output has the same date. Not increasing the date breaks rsync without --checksum or anything else that relies on modification time stamps of files to detect changes. That the build counter is the number after the first dot of the release is a OBS convention. This breaks if a Release is set manually in the spec file. 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 . This needs openSUSE/obs-build#977 to be deployed first. This works together with rpm-software-management/rpm#2880 . For the full effect its settings need to be enabled. First try openSUSE#58 was reverted with bfa988b .
JanZerebecki
added a commit
to JanZerebecki/post-build-checks
that referenced
this pull request
Feb 6, 2024
replacing rpm its %source_date_epoch_from_changelog . This instead also increments the date by the build counter obtained from OBS. When available it uses the mtime that OBS its scmsync obtains from the git HEAD commit date instead of from the changelog. All this can be disabled by setting the rpm macro %disable_obs_set_source_date_epoch to Y . This uses new variables in /.buildenv that were implemented in openSUSE/obs-build@5d1da85 . See https://reproducible-builds.org/docs/source-date-epoch/#interaction-of-source_date_epoch-with-automatic-rebuilds for more general discussion. Increasing the date by the build counter is necessary, so that that even for rebuilds with unchanged source but updated build depends the date is always increased, such that no build with a different input/output has the same date. Not increasing the date breaks rsync without --checksum or anything else that relies on modification time stamps of files to detect changes. 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 . This needs openSUSE/obs-build#977 to be deployed first. This works together with rpm-software-management/rpm#2880 . For the full effect its settings need to be enabled. First try openSUSE#58 was reverted with bfa988b .
|
Tested it with a CET time locally and seems to work. |
|
Just removing the line is not correct. Now fixed with commit ad8accf. |
JanZerebecki
added a commit
to JanZerebecki/post-build-checks
that referenced
this pull request
Feb 15, 2024
replacing rpm its %source_date_epoch_from_changelog . This instead also increments the date by the build counter obtained from OBS. When available it uses the mtime that OBS its scmsync obtains from the git HEAD commit date instead of from the changelog. It exports the old date in SOURCE_DATE_EPOCH and the new incremented date in SOURCE_DATE_EPOCH_MTIME. rpm will use SOURCE_DATE_EPOCH_MTIME for for file mtimes and the old date for everything else. All this can be disabled by setting the rpm macro %disable_obs_set_source_date_epoch to Y . This uses new variables in /.buildenv that were implemented in openSUSE/obs-build@5d1da85 . See https://reproducible-builds.org/docs/source-date-epoch/#interaction-of-source_date_epoch-with-automatic-rebuilds for more general discussion. Increasing the date by the build counter is necessary, so that that even for rebuilds with unchanged source but updated build depends the date is always increased, such that no build with a different input/output has the same date. Not increasing the date breaks rsync without --checksum or anything else that relies on modification time stamps of files to detect changes. 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 . This needs openSUSE/obs-build#977 to be deployed first. This works together with rpm-software-management/rpm#2880 . For the full effect its settings need to be enabled. First try openSUSE#58 was reverted with bfa988b .
JanZerebecki
added a commit
to JanZerebecki/post-build-checks
that referenced
this pull request
Feb 15, 2024
replacing rpm its %source_date_epoch_from_changelog . This instead also increments the date by the build counter obtained from OBS. When available it uses the mtime that OBS its scmsync obtains from the git HEAD commit date instead of from the changelog. It exports the old date in SOURCE_DATE_EPOCH and the new incremented date in SOURCE_DATE_EPOCH_MTIME. rpm will use SOURCE_DATE_EPOCH_MTIME for for file mtimes and the old date for everything else. All this can be disabled by setting the rpm macro %disable_obs_set_source_date_epoch to Y . This uses new variables in /.buildenv that were implemented in openSUSE/obs-build@5d1da85 . See https://reproducible-builds.org/docs/source-date-epoch/#interaction-of-source_date_epoch-with-automatic-rebuilds for more general discussion. Increasing the date by the build counter is necessary, so that that even for rebuilds with unchanged source but updated build depends the date is always increased, such that no build with a different input/output has the same date. Not increasing the date breaks rsync without --checksum or anything else that relies on modification time stamps of files to detect changes. 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 . This needs openSUSE/obs-build#977 to be deployed first. This works together with rpm-software-management/rpm#2880 . For the full effect its settings need to be enabled. First try openSUSE#58 was reverted with bfa988b .
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
when computing the time of a changes entry in changelog2spec.
This avoids getting a date in the future which would fail when using it for SOURCE_DATE_EPOCH for reproducible builds.
Such failures happened when we tried using it with openSUSE/post-build-checks#58 .
Example failure from build log:
setting SOURCE_DATE_EPOCH to 1698749844
ERROR SOURCE_DATE_EPOCH is in the future, clamping mtime if
used might fail in hard to notice way, returning error
"Mon Oct 30 12:36:34 CET 2023" in .changes results in SOURCE_DATE_EPOCH=1698669395 but that's Mon 30. Oct 12:36:35 UTC 2023
Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1216738