Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux