unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Guillaume Le Vaillant <glv@posteo.net>
To: Kaz Kylheku <kaz@kylheku.com>
Cc: "Paul A. Patience" <paul@apatience.com>, 49517@debbugs.gnu.org
Subject: [bug#49517] [PATCH] gnu: txr: Build documentation and update to 265.
Date: Tue, 20 Jul 2021 09:18:39 +0000	[thread overview]
Message-ID: <87bl6xbaxc.fsf@kitej> (raw)
In-Reply-To: <b17b221c6f05b29e8b7576e7a2c99ced@mail.kylheku.com>

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

Kaz Kylheku <kaz@kylheku.com> skribis:

> On 2021-07-19 05:08, Guillaume Le Vaillant wrote:
>> So Debian indeed has a patch adding the possibility to set the timestamp
>> based on SOURCE_DATE_EPOCH (see '2010_add_build_timestamp_setting.patch'
>> in [1] for example).
>
> Looks like they rolled out this patch into production in 2015.
>
> Is there a reason why Guix can't just steal the Debian patches
> related to reproducibility? (Like underlying differences it the overall
> approach which lead to incompatibilities?)

I don't think so, the developer who made the patch for Guix probably
just didn't know about Debian's patch.


> It would probably be best if distros did this the same way, so
> there are no surprises.
>
> GNU/Linux could set a precedent for other platforms, even.
> If I'm building something on, say, Cygwin, OpenBSD or MacOS, if the
> reproducbility stuff works the same way like on GNU/Linuxes, that's
> great.
>
> Here is a powerful argument why Just One Way of doing it is better:
>
> Distros should not be carrying patches for this in the first place;
> the programs themselves should be upstreaming the changes for
> reproducibility.
>
> If there is an agreed-upon /de facto/ (or /de jure/) standard way
> of doing it, it is easier to persuade the individual program developers to
> accept the changes. They have a single target to hit which covers
> all platforms.
>
> In contrast, if reproducibility is an /ad hoc/ OS-and-distro-specific
> matter, they are going to be understandably less motivated to upstream
> the changes.
>
> Nobody wants a situation in their source tree like:
>
>   patches/for-debian
>          /for-guix
>          /for-solaris
>          ...
>
> Just one implementation, committed into trunk, with with no #ifdefs.

In this case upstream explicitly refused merging the patches for
reproducibility (https://bugs.ghostscript.com/show_bug.cgi?id=698208).

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

  reply	other threads:[~2021-07-20  9:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-11  0:37 [bug#49517] [PATCH] gnu: txr: Build documentation and update to 265 Paul A. Patience
2021-07-12  1:01 ` Paul A. Patience
2021-07-13 23:45   ` Paul A. Patience
2021-07-17  9:57     ` Guillaume Le Vaillant
2021-07-17 22:51       ` Kaz Kylheku
2021-07-18  3:43         ` Kaz Kylheku
2021-07-18 10:36           ` Guillaume Le Vaillant
2021-07-18 12:59             ` Paul A. Patience
2021-07-20  9:07               ` bug#49517: " Guillaume Le Vaillant
2021-07-18 20:27             ` [bug#49517] " Kaz Kylheku
2021-07-18 21:28               ` Paul A. Patience
2021-07-19 12:08                 ` Guillaume Le Vaillant
2021-07-19 21:31                   ` Kaz Kylheku
2021-07-20  9:18                     ` Guillaume Le Vaillant [this message]
2021-07-19  3:23             ` Kaz Kylheku

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87bl6xbaxc.fsf@kitej \
    --to=glv@posteo.net \
    --cc=49517@debbugs.gnu.org \
    --cc=kaz@kylheku.com \
    --cc=paul@apatience.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).