On 10/06/15 12:58, Brendan O'Dea wrote:
> On 10 June 2015 at 20:54, Ximin Luo wrote:
>> On 10/06/15 12:41, Brendan O'Dea wrote:
>>> On 10 June 2015 at 01:59, Ximin Luo wrote:
SOURCE_DATE = "$(date -d "$(dpkg-parsechangelog --count 1 -SDate)"
--iso-8601=seconds)" # includes the TZ offse
On 10 June 2015 at 20:54, Ximin Luo wrote:
> On 10/06/15 12:41, Brendan O'Dea wrote:
>> On 10 June 2015 at 01:59, Ximin Luo wrote:
>>> SOURCE_DATE = "$(date -d "$(dpkg-parsechangelog --count 1 -SDate)"
>>> --iso-8601=seconds)" # includes the TZ offset
> The TZ offset is given statically in debi
On 10/06/15 12:41, Brendan O'Dea wrote:
> On 10 June 2015 at 01:59, Ximin Luo 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
On 10 June 2015 at 01:59, Ximin Luo 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 language/tool alread
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 off
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'r
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
On 5 June 2015 at 21:12, Ximin Luo wrote:
> If we're going to mandate that it ends with Z, might I suggest that we add
> "UTC" or "_UTC" to the variable name? It leaves the option open in the future
> that we might allow TZ offsets.
>
> Note that the TZ offsets mentioned in ISO8601 and the other
On 05/06/15 04:19, Daniel Kahn Gillmor wrote:
> On Thu 2015-06-04 21:51:37 -0400, Brendan O'Dea wrote:
>> Local times, and daylight savings are just too much of a PITA. Just
>> use UTC and if builds on the first of the month are possibly different
>> to the changelog, so be it.
>
> I agree with B
On Thu 2015-06-04 21:51:37 -0400, Brendan O'Dea wrote:
> Local times, and daylight savings are just too much of a PITA. Just
> use UTC and if builds on the first of the month are possibly different
> to the changelog, so be it.
I agree with Brendan here.
If there are no objections to the idea th
On 5 June 2015 at 04:40, Ximin Luo wrote:
> On 04/06/15 19:30, Daniel Kahn Gillmor wrote:
>> What TZ should SOURCEDATE have? ISO8601 is capable of supplying a TZ as
>> well, so the current time could be written in a wide variety of ways
>> while meaning the same instant:
>>
>> 0 dkg@alice:~$ date
On 04/06/15 19:30, Daniel Kahn Gillmor wrote:
> What TZ should SOURCEDATE have? ISO8601 is capable of supplying a TZ as
> well, so the current time could be written in a wide variety of ways
> while meaning the same instant:
>
> 0 dkg@alice:~$ date '+%FT%T%z' && date -u '+%FT%T%z'
> 2015-06-04T13
On Thu 2015-06-04 10:38:53 -0400, Ximin Luo wrote:
> A few months ago I had an idea for this that would be more generalisable. See
>
> https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150330/001317.html
>
> for details. TL;DR is to have SOURCEDATE as an environment variab
On 04/06/15 16:19, Daniel Kahn Gillmor wrote:
>>> If the build system is going to set environment variables, maybe it
>>> could set an environment variable with a parseable date string
>>> (ISO-8601?) and help2man could look at that environment variable and
>>> extract a string from it? (ideally t
On Thu 2015-06-04 08:17:59 -0400, Brendan O'Dea wrote:
> The idea was that unless that environment variable was set, the
> behaviour would be unchanged: the current date would be used. It
> seems unlikely that DEB_BUILD_CHANGELOG would be set accidentally.
right, but this wouldn't be terribly use
On 4 June 2015 at 00:19, Daniel Kahn Gillmor wrote:
> On Wed 2015-06-03 08:24:51 -0400, Brendan O'Dea wrote:
>> My inclination is instead to do something fairly specific to your
>> project: If the environment variable DEB_BUILD_CHANGELOG (or something
>> similar) is set, then the file to which it
Hi Brendan--
Thanks for the quick followup! (cc'ing the r-b list)
On Wed 2015-06-03 08:24:51 -0400, Brendan O'Dea wrote:
> On 2 June 2015 at 04:49, Daniel Kahn Gillmor wrote:
>> Please consider the attached patch as a step on the way toward allowing
>> packages that use help2man to build reprodu
On 2 June 2015 at 04:49, Daniel Kahn Gillmor wrote:
> Please consider the attached patch as a step on the way toward allowing
> packages that use help2man to build reproducibly. For more info, see:
Hi Daniel,
I appreciate that you've provided a relatively generic solution to
your problem: addin
Package: help2man
Version: 1.46.6
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamp toolchain
Hi Brendan--
Please consider the attached patch as a step on the way toward allowing
packages that use help2man to build reproducibly. For more info, see:
https://repr
19 matches
Mail list logo
