Thomas Schmitt wrote:
> This discussion yielded that your xorriso-1.3.2 with SOURCE_DATE_EPOCH
> will not work reproducibly if you present the same input file tree on
> different hard disks or after copying it to another location in the
> global tree.
Just to confirm, this is due to non-determinstic extent numbering due to
sorting?
> If you need reliable effect of SOURCE_DATE_EPOCH right now, then you have
> to port your changeset to xorriso-1.4.2 or 1.4.4.
I'm actually targetting stable/jessie for my specific use-case. When I
checked before, my patches ported almost trivially to the version in sid
at least. No need to make this a blocker or worry about it further; let's
just consider git/svn HEAD.
> One single suggested switch, to be exacting. :))
> And only if really file timestamps shall not matter.
For now, sure. But extent ordering, etc. etc.. In my experience of hunting
down reproducible issues, it *can* turn into a bit of a rabbit hole..
> I do not deem the overriding of file timestamps a normal goal of
> reproducibility. In general the POSIX attributes of a file are as significant
> as is the file content or the softlink target string.
Well, if you are using any tool that generates files (for example,
the tool that's actually building the files to put on your ISO!), then
these files will have varying timestamps between builds, no?
> Of course, if your use case makes it desirable to override the file timestamps
> then "filesystem manipulator" comes in handy. So i currently strive to put
> your use case on that track.
Can you briefly elaborate/confirm what you mean by that? Post-process the
ISO with the manipulators rather than do this during build?
> > developer [...] will need to hunt down and learn [...] all the
> > various command-line arguments
>
> A valid point, indeed.
Further to this, someone once did a survey of all the Debian-area ISO/chroot
build tools and found there were at least ten. All of these would need
separate patching to achieve reproducible ISOs, alas. Just another data point
really..
> (I plan to derive the isohybrid MBR id from the --modification-date=
> setting if present.)
Nice!
> > As I understand the code in Xorriso_make_iso_write_opts,
> > isoburn_igopt_set_scdbackup_tag appears to be called unconditionally
>
> It copies to libisoburn the scdbackup_tag_name, which is empty by default.
> This causes libisoburn not to call iso_write_opts_set_scdbackup_tag().
> Else you'd get a message at the end of the run:
> xorriso : NOTE : scdbackup tag written : x_y B60805.122358 3111051
> 397e84253510b0dc3d8f17178585e226
Ahh, okay. You can now see why I had not sent my patches before you
requested them as they contained -- at least -- unnecessary things like
this.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
