Skip to content
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

Set SOURCE_DATE_EPOCH #58

Merged
merged 1 commit into from
Oct 24, 2023

Commits on Oct 20, 2023

  1. Set SOURCE_DATE_EPOCH

    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/ for general
    introduction.
    
    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 .
    JanZerebecki committed Oct 20, 2023
    Configuration menu
    Copy the full SHA
    e56b51b View commit details
    Browse the repository at this point in the history