> > As it is now, it is the clearest no-brainer:
> > Export SOURCE_DATE_EPOCH and forget about any other time issues which
> > you don't create yourself by own xorriso arguments.
Chris Lamb wrote:
> I'm sorry but I don't quite follow and I don't want to read what I want
> to read.
Currently it is (hopefully) this way:
If the same SOURCE_DATE_EPOCH value is in effect with each xorriso run
then the user may expect that timestamps in the ISO are not an obstacle
for reproducibility. Regardless of input.
So it is only about names, ownership, permissions, and data content.
With popular option -r one can make ownership and permissions flatly
This can be changed by own xorriso arguments to the three xorrisofs
options named in the man page text:
--modification-date=, --gpt_disk_guid, --set_all_file_dates.
> trying to avoid the case of — heaven forbid we broke
> the Debian CD creation! — that we would get the blame as ACKing on their
> behalf. :)
The popular debian-cd ones i can ACK quite well myself. (And then i'd
first need to convince Steve McIntyre of using Sid's xorriso.)
I test with
and mini.iso for amd64 and i386.
I mount them, let xorriso pack up the files and replay the boot related
-as mkisofs options which it deduced from inspecting the unmounted ISO.
Then i let xorriso report both boot equipments and let diff compare the
reports. After mounting both ISOs, two find runs over both trees make
sure that differences in file content, ownership, permissions, or time
The few reported differences come from automatic timestamps and differing
block addresses which get patched into boot images. (The originally used
xorriso versions still produced the reproducibility-unfriendly sequence
of file data extents.)
My scruples are more towards adventurous distros which immediately use
my newest releases.
Have a nice day :)
Reproducible-builds mailing list