Cyril Brulebois wrote:
> I've cherry-picked 3 patches from there onto master locally and I'm
> currently running diffoscope to see how that goes (and it's taking
> ages…):

I'm guessing the initrd would differ if the Linux tool to generate it
stores timestamps.  If its compressed size varies much due to those
differences, the .iso block numbers may vary as a result.

> FWIW, I'm not exactly entirely convinced by the exporting of the
> SOURCE_DATE_EPOCH variable from debian/rules; all other variables have
> been passed without exporting so I'm wondering if we shouldn't adapt
> this to behave like other variables, reducing possible surprise for
> users.

Just to explain that -- if it's defined in the environment, it requires
no special handling and doesn't need to be (re-)exported.  I think this
is maybe the case now for dpkg-buildpackage in sid?

If the dpkg-buildpackage environment doesn't have SOURCE_DATE_EPOCH
(e.g. jessie), debian/rules sets it to the correct value, and so must
export that.

Or (for jessie or sid), in case build/Makefile is used directly, outside
of a package build, we set SOURCE_DATE_EPOCH to a dummy value ("now") if
undefined (since ../debian/changelog may not exist), which we need
when calling makefs from within that Makefile.  We export it for use by
gen-tarball to avoid duplication there.

Steven Chamberlain

Attachment: signature.asc
Description: Digital signature

Reproducible-builds mailing list

Reply via email to