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

2015-07-20 Thread Ximin Luo
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



signature.asc
Description: OpenPGP digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

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

2015-07-12 Thread Jérémy Bobbio
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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


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