On Wed, Apr 26, 2023 at 12:40:09PM -0700, Vagrant Cascadian wrote:
> Yes, ideally SOURCE_DATE_EPOCH does not matter. It is a workaround to
> embed a (hopefully meaningful) timestamp, when from a reproducible
> builds perspective, ideally there would be no timestamp at all in the
> resulting
On Wed, 26 Apr 2023 at 18:48, Vagrant Cascadian
wrote:
>
> On 2023-04-26, James Addison wrote:
> > On Tue, 18 Apr 2023 at 18:51, Vagrant Cascadian
> > wrote:
> >> > James Addison wrote:
> >> This is why in the reproducible builds documentation on timestamps,
> >> there is a paragraph
On 2023-04-26, James Addison wrote:
> On Tue, 18 Apr 2023 at 18:51, Vagrant Cascadian
> wrote:
>> > James Addison wrote:
>> This is why in the reproducible builds documentation on timestamps,
>> there is a paragraph "Timestamps are best avoided":
>>
>>
On 2023-04-17, John Gilmore wrote:
> James Addison wrote:
>> When the goal is to build the software as it was available to the
>> author at the time of code commit/check-in - and I think that that is
>> a valid use case - then that makes sense.
>
> I think of the goal as being less related to the
On Sun, 16 Apr 2023 at 00:25, John Gilmore wrote:
>
> James Addison via rb-general wrote:
> > In general, we should be able to
> > pick two times, "s" and "t", s <= t, where "s" is the
> > source-package-retrieval time, and "t" is the build-time, and using
> > those,
James Addison wrote:
> When the goal is to build the software as it was available to the
> author at the time of code commit/check-in - and I think that that is
> a valid use case - then that makes sense.
I think of the goal as being less related to the author, and more
related to the creator of
James Addison via rb-general wrote:
> In general, we should be able to
> pick two times, "s" and "t", s <= t, where "s" is the
> source-package-retrieval time, and "t" is the build-time, and using
> those, any two people should be able to create exactly the same
>
On Fri, 14 Apr 2023 at 19:51, Holger Levsen wrote:
>
> Dear James,
>
> many thanks also from me for your work on this and sharing your findings here.
>
> I'm another happy sphinx user affected by those problems. :)
Thanks, Holger - I think I made a bit of a (verbose) mess of this
particular
On 2023-04-14, Holger Levsen wrote:
> i'm wondering whether distro-info should respect SOURCE_DATE_EPOCH:
> src:developers-reference builds different content based on the build
> date, due to using distro-info and distro-info knows that in 398 days
> trixie will be released :)))
> see
>
Dear James,
many thanks also from me for your work on this and sharing your findings here.
I'm another happy sphinx user affected by those problems. :)
somewhat related:
i'm wondering whether distro-info should respect SOURCE_DATE_EPOCH:
src:developers-reference builds different content
Dear James,
Thanks for your recent emails. As the original bug filer (#9778), I'm
obviously invested in this being fixed… and I was enjoying watching
the recent flurry of activity hit my inbox.
> Probably nothing new to many of the folks on this mailing list and/or
> seasoned software engineers
A follow-up: after doing more work to try to confirm the behaviour of
the fix -- something I should have done before even starting
development! -- I was confused that I couldn't replicate the original
problem when using a version of the codebase _before_ my proposed fix
pr#10949 was applied.
I
Hi folks,
A set of reproducible-build-related changes[1] that I've developed for
sphinx (a documentation project generator) have been accepted for
inclusion in v6.2.0 of sphinx.
I'm optimistic that those changes can address a sizable category[2] of
reproducible build failures related to
13 matches
Mail list logo
