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 



Attachment: signature.asc
Description: OpenPGP digital signature

Reproducible-builds mailing list

Reply via email to