[Reproducible-builds] Minimising work needed for this build-path issue
infinity0 at debian.org
Tue Nov 1 15:56:00 UTC 2016
Hey, thanks for the review.
Daniel Kahn Gillmor:
> Looking at what we're doing in debian, i see:
> Is there a reason that these changes differ from
> SOURCE_DATE_EPOCH_-_for_TIMESTAMP_macro.patch ? Or is it just
> divergence between gcc 6 and the master dev branch?
Not sure what you mean exactly by "difference". Some of it will be because of divergence between GCC 6 and 7 yes. But the TIMESTAMP patch is for __TIMESTAMP__ whereas our currently-existing Debian patches are only for __DATE__ and __TIME__.
Also __TIMESTAMP__ is defined as the file-modification date and not the "current" date/time like the other two macros, which is why we do the clamping behaviour (similar to tar --clamp-mtime), suggested by Reiner.
> Also, i note that the -doc.diff patches above are really helpful (though
> i see no reason to break them out separately from the code changes
> unless there's an upstream convention to do so; i think coupling
> documentation changes with code changes is a Good Thing). Maybe this
> SOURCE_PREFIX_MAP changeset can also include changes to gcc
Yeah, I was just on my way to add those. :)
> Your accompanying SRD_debug.txt describes the reasoning behind these
> changes well, thanks! But it says:
> I will also be submitting a follow-up patch to perform this
> behaviour for the __FILE__ macro as well,
> Unless i'm misunderstanding, you have already included a patch for the
> __FILE__ macro as well, so unless you plan on submitting these with some
> sort of deliberately delayed timing, i'd change the text in
> SRD_debug.txt to reflect the fact that this is a complete changeset that
> we expect to Do the Right Thing.
I was going to send the __FILE__ patch in a separate email later yes. Just so it's a bit less overwhelming for the reviewers.
> Finally, SOURCE_PREFIX_MAP_-_rsplit.patch changes from splitting on the
> first "=" to splitting on the last "=". I think you've justified this
> change well in previous e-mails on this thread, but the justification
> doesn't appear in this patchset. If the gcc folks are going to see this
> series fresh, it'd be good to explain the change and justify it, as well
> as marking it clearly as optional. That is, if this change makes
> upstream balk at accepting the patchset, we want them to drop it and
> accept the rest, right?
Right, I've added this too. Also included the documentation update along with it.
More information about the Reproducible-builds