all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@reproducible-builds.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Set FORCE_SOURCE_DATE=1 by default
Date: Wed, 22 Jun 2022 18:03:37 -0700	[thread overview]
Message-ID: <87v8ssry1i.fsf@contorta> (raw)
In-Reply-To: <87pmj06bpl.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

On 2022-06-22, Maxim Cournoyer wrote:
> Vagrant Cascadian <vagrant@reproducible-builds.org> writes:
>> On 2022-06-21, Maxim Cournoyer wrote:
>>> Vagrant Cascadian <vagrant@reproducible-builds.org> writes:
>>>> That said, some projects (such as texlive) might be worried about
>>>> messing with time too much (I get it, lots of cautionary sci-fi
>>>> stories!), and so you *also* need FORCE_SOURCE_DATE=1 to be set in order
>>>> to respect SOURCE_DATE_EPOCH.
>>>
>>> That seems ridiculous.  Has anyone tried getting in touch with them to
>>> get their arguments about why inventing another variable that means the
>>> same thing was necessary?
>>
>> Yes, there were some fairly long threads about it and I have little hope
>> that revisiting it would change much; it was originally implemented as a
>> texlive specific variable, which was changed to the FORCE_SOURCE_DATE
>> variable to at least avoid the danger of every project inventing their
>> own name-brand variables...

I have tracked it down to these threads:

  https://www.tug.org/pipermail/tex-k/2016-May/thread.html#2691
  https://www.tug.org/pipermail/tex-k/2016-May/thread.html#2712
  https://www.tug.org/pipermail/tex-k/2016-June/thread.html#2721


>>> I'd much prefer challenging that stance than "endorsing" it in Guix :-).
>>> I think it'd be OK to reluctantly add it in as a stop-gap fix in Guix,
>>> but *only* after opening an issue to discuss it upstream and linking to
>>> that issue in Guix.
...
>> I think the pragmatism of making more packages reproducible by conceding
>> to set FORCE_SOURCE_DATE is the appropriate way forward; I agree it
>> feels silly or even maybe would go so far as to say a bit "wrong".
>
> Perhaps to show our stand here we could patch our copy of pdftex with
> 's/FORCE_SOURCE_DATE/SOURCE_DATE_EPOCH/', lest we end up with a grocery
> list of *SOURCE_DATE* variable variants.

Sure, with some technical details fixed up, as I think they are
functionally different, in that FORCE_SOURCE_DATE is a boolean, and
SOURCE_DATE_EPOCH is an integer, though ... Guix sets
SOURCE_DATE_EPOCH=1 ... so it might just work by dumb luck! Though There
may be some rare packages that need SOURCE_DATE_EPOCH to be some larger
value...  "It can't possibly be 1970, this program was first written in
2002, there must be some error, failing build..."

At any rate, if diverging from upstream Tex Live is how Guix wants to
handle this, I'm all for it!

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

  reply	other threads:[~2022-06-23  1:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 23:53 Set FORCE_SOURCE_DATE=1 by default Vagrant Cascadian
2022-06-15  8:58 ` Ludovic Courtès
2022-06-15 16:24   ` Vagrant Cascadian
2022-06-21 20:48   ` Vagrant Cascadian
2022-06-21 21:06     ` Vagrant Cascadian
2022-06-22  3:57 ` Maxim Cournoyer
2022-06-22  6:08   ` Vagrant Cascadian
2022-06-22 13:53     ` Ludovic Courtès
2022-06-22 15:11       ` Vagrant Cascadian
2022-06-22 17:41         ` Maxim Cournoyer
2022-06-22 13:59     ` Maxim Cournoyer
2022-06-23  1:03       ` Vagrant Cascadian [this message]
2022-06-23 16:44         ` Maxim Cournoyer
2022-07-03  1:58           ` Vagrant Cascadian
2022-07-04 13:14             ` Ludovic Courtès
2022-08-12 15:32               ` Vagrant Cascadian
2022-06-22 15:16 ` Time namespace for build sandbox (was Re: Set FORCE_SOURCE_DATE=1 by default) Zhu Zihao
2022-06-22 15:35   ` Vagrant Cascadian
2022-06-22 16:41   ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8ssry1i.fsf@contorta \
    --to=vagrant@reproducible-builds.org \
    --cc=guix-devel@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.