Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-25 Thread Jan Zerebecki
Closed #2677.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#event-10462916706
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-25 Thread Jan Zerebecki
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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733740158
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-25 Thread ニール・ゴンパ
The changelog bumps for every build, even no-change rebuilds.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733638621
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-25 Thread ニール・ゴンパ
Never.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733637577
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-25 Thread Jan Zerebecki
Are rebuilds with changed dependencies but unchanged source never done for 
Fedora?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733634320
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-22 Thread ニール・ゴンパ
The correct fix for openSUSE is that the OBS builder should generate a new 
`SOURCE_DATE_EPOCH` number to pass into the rpmbuild environment and you should 
_not_ set `%source_date_epoch_from_changelog 1`.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1732230398
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-22 Thread ニール・ゴンパ
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 `SOURCE_DATE_EPOCH` externally 
is for.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1732229913
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-22 Thread ニール・ゴンパ
The fix is to _not_ clamp buildtime to SOURCE_DATE_EPOCH (i.e. don't set 
`%use_source_date_epoch_as_buildtime 1`). We don't do this in Fedora and I 
don't recommend any distribution to do it if they have a pipeline that relies 
on the buildtime (and the openSUSE pipeline definitely does).



-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1732228211
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-22 Thread Jan Zerebecki
@JanZerebecki pushed 1 commit.

873e2c4b7b2958c40aee38d073c0d5d88e4687fe  Increment build date every release

-- 
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677/files/d29950aad75b870ade68b9f0eb0918c2d80514f7..873e2c4b7b2958c40aee38d073c0d5d88e4687fe
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Increment build date every release (PR #2677)

2023-09-22 Thread Jan Zerebecki
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 .
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/2677

-- Commit Summary --

  * Increment build date every release

-- File Changes --

M build/build.c (34)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/2677.patch
https://github.com/rpm-software-management/rpm/pull/2677.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2677
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint