On Fri, Nov 11, 2022 at 02:05:11PM +0100, Miro Hrončok wrote: > On 11. 11. 22 11:53, Petr Pisar wrote: > > V Thu, Nov 10, 2022 at 03:23:49PM -0500, Ben Cotton napsal(a): > > > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes > > > > > > == Summary == > > > > > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. > > > When an RPM package is built, mtimes of packaged files will be clamped > > > to `$SOURCE_DATE_EPOCH` > > > > Clamp as capping maximal mtime, or resetting mtime for all files? I.e. If > > I had a source file dated 1970-01-01 and installed it with "install -p", will > > the packaged file retain that 1970-01-01 date, or will it be set to the date > > of the latest changlog, e.g. 2022-11-11? In other words, will all files in > > a package have the same mtime, or there won't be an mtime newer than the > > changelog entry? > > Capping maximal mtime. It's actually described in the detailed description: > > """Clamping means that all files which would otherwise have a modification > datetime higher than $SOURCE_DATE_EPOCH will have the modification datetime > changed to $SOURCE_DATE_EPOCH; files with mtime lower (or equal) to > $SOURCE_DATE_EPOCH will retain the original mtimes.""" > > Possibly "higher" should say "greater" instead, not sure. > > > > which is already set to the date of the latest `%changelog` entry. > > > > What's a changelog entry date in case of rpmautospec changelog? Is it > > a git AuthorDate or CommitDate? > > I don't know from top of my head. There's also > https://pagure.io/fedora-infra/rpmautospec/issue/209 which touches this > topic a bit. This is obviously an interesting question, but it's orthogonal to this proposal. Here we'll take whatever rpmautospec generates as the last timestamp. The details of that generation may even change over time, as discussed in the issue. > > > As a result, more RPM packages will be reproducible: > > > > Where will this reproducibility stop? An RPM package itself carry a build > > time in its RPM header. Are we also going to fake this time in the name of > > reproducibility? > > Not as part of this change proposal and I have no intention to propose such > a thing. > > > What value these faked timestamps have? E.g. a compiled file is a function not > > only of its source, but also of the compiler. This proposed change removes > > the compiler part from the timestamp. Will timestamps like this be helpful? > > Are the current timestamps helpful? > > > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate > > all of them stamps from various data formats rather than trying to fake them? > > I don't think it would be easier, but I have not tried that. > > > Simply changing rpmbuild to set timestamp to 0 for all contained files, or > > removing the time attribute from the RPM format completely? > > RPM does not currently support this. RPM currently supports mtime clamping > which is what we have proposed. You seem to not like the idea but you don't > say so explicitly. If you prefer status quo over this change and would > rather see the proposal rejected, please say so, so FESCo can evaluate your > feedback when voting about the proposal. I think we should not get rid of timestamps altogether. They are useful metadata and even end users look at them occasionally. Our packaging guidelines say that an effort must be made to preserve _upstream_ timestamps. We also know from the experince with ostree systems that setting timestamps to 0 confuses some software. Thus, I think we should clamp the timestamps as required to achieve reproducible builds, but not more. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
