Bug#787444: [Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-10 Thread Brendan O'Dea
On 10 June 2015 at 01:59, Ximin Luo infini...@pwned.gg wrote: Given the above, I think it would still be good to define SOURCE_DATE as I originally suggested: SOURCE_DATE = $(date -d $(dpkg-parsechangelog --count 1 -SDate) --iso-8601=seconds) # includes the TZ offset - if the

Bug#787444: [Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-09 Thread Ximin Luo
On 06/06/15 16:39, Holger Levsen wrote: Hi, On Freitag, 5. Juni 2015, Daniel Kahn Gillmor wrote: My vote is for SOURCE_DATE_UTC, and i agree with Brendan that we should take the opportunity to define this as strictly and narrowly as possible (i.e. end in a 'Z', none of the other offsets),

Bug#787444: [Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-06 Thread Holger Levsen
Hi, On Freitag, 5. Juni 2015, Daniel Kahn Gillmor wrote: My vote is for SOURCE_DATE_UTC, and i agree with Brendan that we should take the opportunity to define this as strictly and narrowly as possible (i.e. end in a 'Z', none of the other offsets), so that people relying on it know they're

Bug#787444: [Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-05 Thread Daniel Kahn Gillmor
On Fri 2015-06-05 10:55:34 -0400, Brendan O'Dea wrote: Any of UTC_SOURCE_DATE, SOURCE_DATE_UTC My vote is for SOURCE_DATE_UTC, and i agree with Brendan that we should take the opportunity to define this as strictly and narrowly as possible (i.e. end in a 'Z', none of the other offsets), so that