Hi, 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. Regards, -- Steven Chamberlain ste...@pyro.eu.org
signature.asc
Description: Digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds