[Reproducible-builds] Bug#791823: debhelper: set SOURCE_DATE_EPOCH env var for reproducible builds

Ximin Luo infinity0 at pwned.gg
Mon Jul 20 08:45:24 UTC 2015


On 12/07/15 12:03, Jérémy Bobbio wrote:
> Hi!
> 
> Dhole:
>> Also, in order to help reproducible builds, a fixed timezone is exported
>> (TZ=UTC).
> 
> I am not convinced this change is a good idea. While reviewing new uploads
> to the Debian archive, I have at least spotted these lines in
> exim4/4.86~RC4-1 changelog [1]:
> 
>>   * unexport/undefine TZ in debian/rules for reproducible build. It
>>     would be used as default value for TIMEZONE_DEFAULT.
> 
> The `TZ` environment variable is not usually set in a build environment.
> It is a reproducibility problem if a package produce different binaries
> when it is, but that's all. I am afraid that some packages, like exim4,
> would silently start behaving differently if we set `TZ` in debhelper.
> 
> If we don't set the variable in debhelper, we can use the
> reproducibility tests to spot packages who are building differently
> depending on the timezone or the value of TZ and propose fixes to
> maintainers. This enables them to review their impact. It is indeed more
> work, but it's less likely to unknowingly introduce any weird behavior.
> 
>  [1]: https://tracker.debian.org/news/694090
> 

I also had some reservations about setting TZ in this way, but wasn't quite sure how to express it. But here's a more general, abstract version of the scenario Lunar pointed out.

- Imagine that upstream thinks it's reasonable to e.g. generate certain locale data based on the TZ variable at build time.
- Setting TZ=UTC would make the build appear "reproducible", and the package maintainer may not even realise that there's something missing, especially if this locales thing is buried deep in the build scripts.
- The correct solution would be for upstream to generate such data for all TZs. For sure, setting TZ=UTC would not interfere with this fix, but it makes such issues harder to detect.

I suggest we drop this particular aspect from this patch and just focus on SOURCE_DATE_EPOCH instead.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150720/ff12e653/attachment.sig>


More information about the Reproducible-builds mailing list