File 0001-Set-SOURCE_DATE_EPOCH-2nd-try.patch of Package post-build-checks

Overview Repositories Revisions Requests Users Attributes Meta

File 0001-Set-SOURCE_DATE_EPOCH-2nd-try.patch of Package post-build-checks

From d664cd85c8c9fe9f17895e137e2ecb54b43e150c Mon Sep 17 00:00:00 2001
From: Jan Zerebecki <jan.suse@zerebecki.de>
Date: Mon, 2 Oct 2023 19:07:53 +0200
Subject: [PATCH] Set SOURCE_DATE_EPOCH (2nd try)

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
https://github.com/openSUSE/obs-build/commit/5d1da8553791ecdf35ab538bddd6afa4494d66d0
.

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 https://github.com/openSUSE/obs-build/pull/977 to be
deployed first.

This works together with
https://github.com/rpm-software-management/rpm/pull/2880 . For the full
effect its settings need to be enabled.

First try https://github.com/openSUSE/post-build-checks/pull/58 was
reverted with bfa988bcbab960ed96abd39edd3d40dbd6a0ae20 .
---
 suse-buildsystem.sh | 47 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/suse-buildsystem.sh b/suse-buildsystem.sh
index 1f3dccf..fec4dcd 100644
--- a/suse-buildsystem.sh
+++ b/suse-buildsystem.sh
@@ -7,3 +7,50 @@ export QT_HASH_SEED=0
 export PERL_HASH_SEED=42
 export PYTHONHASHSEED=0
 export FORCE_SOURCE_DATE=1 # for texlive to use SOURCE_DATE_EPOCH
+
+if test ! -v SOURCE_DATE_EPOCH && test -f /.buildenv && test "Y" != "$(rpm --eval '%disable_obs_set_source_date_epoch')"; then
+    SOURCE_DATE_EPOCH="$(
+    . /.buildenv
+    if test -f "$TOPDIR/SOURCES/_scmsync.obsinfo" ; then
+        mtime="$(grep mtime "$TOPDIR/SOURCES/_scmsync.obsinfo" |cut -d ' ' -f 2)"
+        if test -z "$mtime" || test 1 -gt "$mtime" ; then
+            echo "WARNING mtime in \TOPDIR/SOURCES/_scmsync.obsinfo seems invalid as it is less than 1" >&2
+        fi
+    elif test -v BUILD_CHANGELOG_TIMESTAMP ; then
+        mtime=$BUILD_CHANGELOG_TIMESTAMP
+        if test -z "$mtime" || test 1 -gt "$mtime" ; then
+            echo "WARNING BUILD_CHANGELOG_TIMESTAMP in /.buildenv seems invalid as it is less than 1" >&2
+        fi
+    else
+        echo "WARNING could not set SOURCE_DATE_EPOCH, ensure mtime is in \$TOPDIR/SOURCES/_scmsync.obsinfo or BUILD_CHANGELOG_TIMESTAMP is set in /.buildenv" >&2
+    fi
+    echo "$mtime"
+    )"
+    if test -z "$SOURCE_DATE_EPOCH"; then
+        unset SOURCE_DATE_EPOCH
+    fi
+    SOURCE_DATE_EPOCH_MTIME="$(
+    . /.buildenv
+    if test -v BUILD_RELEASE && test -v SOURCE_DATE_EPOCH; then
+        counter="$(echo "$BUILD_RELEASE" |cut -d '.' -f 2)"
+        if test -z "$counter" || test 1 -gt "$counter" ; then
+            echo "WARNING number after \".\" in BUILD_RELEASE in /.buildenv seems invalid as it is less than 1" >&2
+        fi
+        date=$(( SOURCE_DATE_EPOCH + counter ))
+        echo "setting SOURCE_DATE_EPOCH_MTIME to $date" >&2
+    else
+        echo "WARNING could not set SOURCE_DATE_EPOCH, ensure BUILD_RELEASE is set in /.buildenv" >&2
+    fi
+    echo "$date"
+    )"
+    if test -z "$SOURCE_DATE_EPOCH_MTIME"; then
+        unset SOURCE_DATE_EPOCH_MTIME
+        unset SOURCE_DATE_EPOCH
+    else
+        export SOURCE_DATE_EPOCH_MTIME
+        export SOURCE_DATE_EPOCH
+    fi
+    if test "$SOURCE_DATE_EPOCH_MTIME" -ge "$(date '+%s')" ; then
+        echo "WARNING SOURCE_DATE_EPOCH_MTIME is in the future, we assume you do not use clamping of mtime, it would fail in hard to notice ways, continuing" >&2
+    fi
+fi
-- 
2.30.2

Places

File 0001-Set-SOURCE_DATE_EPOCH-2nd-try.patch of Package post-build-checks

Places