Merged #536 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/536#event-1876519089___
Rpm-maint mailing list
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/536#pullrequestreview-153583569___
@bmwiedemann: you recently made neon "reproducible" and asked about upstream
neon to send a patch.
This link likely has all the essential pointers:
https://github.com/aw/neon-unofficial-mirror
Neon is an ice library even if "old" and DAVFS peculiar (but with a large
following on M$ Windoze)
> On Sep 1, 2018, at 2:04 AM, Bernhard M. Wiedemann
> wrote:
>
> I'm already producing bit-identical RPMs using the 4 macros documented in
> https://en.opensuse.org/openSUSE:Reproducible_Builds
> So no changes on digests or signatures are needed atm.
>
> Inaccuracy of $SOURCE_DATE_EPOCH does
I'm already producing bit-identical RPMs using the 4 macros documented in
https://en.opensuse.org/openSUSE:Reproducible_Builds
So no changes on digests or signatures are needed atm.
Inaccuracy of $SOURCE_DATE_EPOCH does not matter, as long as it is in the past.
Some people always set it to 1
See also the thread on RPMTAG_IDENTITY here on rpm-maint@, which is another
attempt at "reproducibility" (in the sense of reproducible "packaging") that is
perhaps more soundly based because the BUILDTIME and file times are
deliberately excluded rather than being reset to some known time.
But
See issue #197 for how to represent time stamps with nano/micro second
precision in header tags with the least amount of legacy incompatibility.
There is an ISO standard for parsing high precision dates/times that rpm has
never adopted, nor is the %changelog time stamp particularly accurate
The real problem with setting a reproducible build time from a %changelog
entriy is lack of precision in the syntax of the permitted time. Other flaws
will eventually be discovered imho.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Make sure SOURCE_DATE_EPOCH is in the past,
otherwise, builds before noon will not have normalized mtimes
from %clamp_mtime_to_source_date_epoch
This also helps other programs like tar --clamp-mtime
Tested successfully on openSUSE.
To reproduce, create a changelog entry with only a date
```
*
