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",
> 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
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
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
Not as part of this change proposal and I have no intention to propose such
> 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.