Thanks again for the view and battling the list moderation! :)
> --set_all_file_dates "$timestring"
> which sets atime, mtime, and ctime of all files, covers your patches
Assuming it also sets iso_write_opts_set_always_gmt, yes. (I think,
I'm not 100% convinced though. I'm a little loathed to drop the
SOURCE_DATE_EPOCH handling in general - zooming out a bit from these
suggested new switches, it does make it somewhat difficult for the
fly-by developer to build a reproducible ISO - they will need to hunt
down and learn the ramifications (and minutiæ of the ISO format) for
all the various command-line arguments that will make the output
reproducible. This seems a little regrettable and perhaps even
In contrast, if we had a single "please make this ISO build
reproducible with this timestamp" toggle, then that would be extremely
straightforward and extensible to all possible future variations where
(Whether this is a command-line switch or based on the S-D-E environment
variable I'm not particularly fussed, although I would have a preference
for the latter as it's becoming increasing common as more tools adopt it.)
> - Do you agree that i omit
> and rather expect that option --scdbackup_tag is not to be used when
> reproducibly building an ISO ?
As I understand the code in Xorriso_make_iso_write_opts,
isoburn_igopt_set_scdbackup_tag appears to be called unconditionally - ie. it
will always have time(NULL).
> (Reason is the meaning of the tag in the context of my backup tool
> scdbackup. A fake timestamp would be flatly wrong.)
Sure, but you would you really be backing up with SOURCE_DATE_EPOCH defined?
> which i derived from your 0004-normalize-wday-yday.patch
> > > Is it really desirable/correct to override the timestamps of files when
> > > they get put into the ISO image ?
> A convenience option for -as mkisofs emulation could do the trick (and
> make the libisoburn patches obsolete).
> xorriso -as mkisofs mkisofs.options... --set_all_file_dates "$timestring"
Looks fine, modulo my general comments about SOURCE_DATE_EPOCH at the top
of this email.
> Probably there will be no new function iso_current_time() either.
> But if it emerges, then it cannot call exit()
Apologies, I was using "exit()" as a sloppy shorthand for "not silently
returning on error" rather than the literal method to call. Of course,
if there is a message queue or a context-dependent failure mode, we should
> Considering the birthday paradox, this should be good enough for about
> 4000 ISOs per day.
Can't /quite/ tell if you're joking! I mean, is anyone building this many
ISOs? Would it matter if their MBR ID clashed? ;-)
> Now i ponder whether it is worth to make it user-adjustable or whether
> i shall derive a reproducible value from the override value of
Mmm, well this is kinda what I was meaning about having a single switch.
> Have a nice day :)
Oh, you too.. and thank you so much for your attention and patience with
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
Reproducible-builds mailing list