[Reproducible-builds] Minimising work needed for this build-path issue

Ximin Luo 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:
>     https://sources.debian.net/src/gcc-6/6.2.0-9/debian/patches/gcc-SOURCE_DATE_EPOCH.diff/
>     https://sources.debian.net/src/gcc-6/6.2.0-9/debian/patches/gcc-SOURCE_DATE_EPOCH-doc.diff/
>     https://sources.debian.net/src/gcc-6/6.2.0-9/debian/patches/gcc-SOURCE_DATE_EPOCH-2.diff/
>     https://sources.debian.net/src/gcc-6/6.2.0-9/debian/patches/gcc-SOURCE_DATE_EPOCH-2-doc.diff/
> 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
> documentation?

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.


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

More information about the Reproducible-builds mailing list