Hi,
by the narrow margin of one vote, the proposal "set_to_mtime" wins.
Committed as http://libburnia-project.org/changeset/5757
man 1 xorrisofs of the next release will state:
SOURCE_DATE_EPOCH belongs to the specs of reproducible-builds.org. It
is supposed to be either undefined or to co
Hi,
i wrote:
> > All three possible behaviors lead to reproducibility if the
> > input trees of the ISO production runs are sufficiently
> > similar.
Sam Hartman wrote:
> So, are you using a definition of reproducible different than the
> resulting iso will have the same SHA-1 hash?
I mean ident
> "Thomas" == Thomas Schmitt writes:
Thomas> Hi,
Thomas> Chris Lamb wrote:
>> I just don't see this usecase of being "partly" reproducible
>> being remotely useful to anyone, ever. I'm probably
>> misunderstanding something, however.
Thomas> All three possible behavio
Hi,
Chris Lamb wrote:
> I just don't see this usecase of being "partly" reproducible being remotely
> useful to anyone, ever. I'm probably misunderstanding something, however.
All three possible behaviors lead to reproducibility if the input trees
of the ISO production runs are sufficiently simil
> > I believe [--set_all_file_dates] is entirely unnecessary
>
> if SOURCE_DATE_EPOCH sets the default, there must be some option to set
> non-default values, especially the value which is default without
> SOURCE_DATE_EPOCH.
Consider the state space:
If someone does not set SOURCE_DATE_EPOCH,
Hi,
i wrote:
> > new program option: --set_all_file_dates [...]
Chris Lamb wrote:
> I believe this option is entirely unnecessary. No need to
> complicate things.
It is architecturally needed, because if SOURCE_DATE_EPOCH sets the
default, there must be some option to set non-default values, es
Hi Thomas,
> Still undecided is whether [SOURCE_DATE_EPOCH] shall by default override
> all timestamps inside the ISO
I believe this steps outside the scope of what exporting SOURCE_DATE_EPOCH
should do, both philosophically, æsthetically, and practically as it
prevents ISO producers from having
