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,
The next point release for "jessie" (8.6) is scheduled for Saturday,
September 17th. Processing of new uploads into jessie-proposed-updates
will be frozen during the preceding weekend.
Regards,
Adam
> > 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,
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
> "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,
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
6 matches
Mail list logo
