Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
@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) -- 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#issuecomment-417888190___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
> 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 not matter, as long as it is in the > past. Some people always set it to 1 (aka 1970-01-01 00:00:01) and are happy. > If $SOURCE_DATE_EPOCH "does not matter", then any value will do, including a high precision BUILDTIME tag from the *.src.rpm clamped on all files in packaging. Distinct advantages to using a high precision build time everywhere include: * many package rebuilds could be checked for reproducibility without using diffoscope * clamped file mtimes become more compressible! including in metadata with zchunk. * the file mtime tag becomes largely vestigial. * the BUILDTIME becomes useful as a package identifier everywhere, including rebuilds. While some of these issues are out of scope for your definition of reproducibility, all of the advantages above are closely related to some definition of reproducibility. The changelog time parsing is/was deliberately sloppy, where 12 noon stood the greatest chance of not causing a date change if/when the timezone was set incorrectly. Many build systems, and most end-user rebuilds, start from a src.rpm, not from a spec file because the SRPM contains all (at last by design if not in fact) necessary elements for a reproducible build. POSIX routines to parse date/time are now widely deployed: not true last century. There comes a time for improving rpm code rather than zombie marching ancient features into the future forevermore: legacy compatibility can be handled with an opt in or out logic to permit distributions the necessary decades to discuss and change as they wish. > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread. -- 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#issuecomment-417882743___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 (aka 1970-01-01 00:00:01) and are happy. -- 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#issuecomment-417835992___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 all defends on how "reproducibility" is defined: if the definition of "reproducibility" includes file mtimes, well, one MUST change the file mtimes everywhere in packaging to achieve "reproducibility". It would be nice if the so far independent efforts to set time stamps from recipes and have digest plaintext exclude per-build specific information somehow started to unify to a single useful approach. -- 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#issuecomment-417822837___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 since it depends on conversions with time zone. Try changing the day-of-week in the spec file %changelog to something incorrect, then display the changelog time stamp in the produced packages. Merges through git are also not handled sufficiently well: earlier time stamps can merge before later (which used to cause rpmbuild to fail, dunno current behavior). The entire idea of "reproducibility" as a means to set an arbitrary time everywhere is somewhat suspect. The BUILDTIME has been used as a tie breaker with identical NEVRA in order to prefer one of several packages, based on the same heuristic that depsolvers use, that the "newer" NEVRA (or BUILDTIME) is preferred. Reproducibility with buildids (I.e. digests) is a better overall approach. JMHO, YMMV, everyone's does. -- 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#issuecomment-417821833___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 it on GitHub: https://github.com/rpm-software-management/rpm/pull/536#issuecomment-417819587___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 ``` * Fri Aug 31 2018 user@host - dummy ``` and build it before 12:00 UTC using macros ``` %source_date_epoch_from_changelog Y %clamp_mtime_to_source_date_epoch Y %use_source_date_epoch_as_buildtime Y %_buildhost reproducible ``` `rpm -qpvl` showed file mtime values to not be normalized and therefore build results were not bit-identical. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/536 -- Commit Summary -- * build: Make sure SOURCE_DATE_EPOCH is in the past -- File Changes -- M build/build.c (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/536.patch https://github.com/rpm-software-management/rpm/pull/536.diff -- 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 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
