diff mbox

Timestamps in ...-autoloads.el files

Message ID 87vb2ayps5.fsf@gmail.com
State New
Headers show

Commit Message

Alex Kost May 19, 2016, 4:29 p.m. UTC
Ludovic Courtès (2016-05-17 12:12 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2016-05-16 15:45 +0300) wrote:
[...]
>>> $ git describe
>>> v0.10.0-798-g8a7680a
>>> $ tar tvf $(./pre-inst-env guix build -S emacs) |grep 'autoload\.el'
>>> -rw-r--r-- root/root     37292 1970-01-01 01:00 emacs-24.5/lisp/emacs-lisp/autoload.el
>>> -rw-r--r-- root/root     37127 1970-01-01 01:00 emacs-24.5/lisp/emacs-lisp/autoload.el.orig
>>> -rw-r--r-- root/root     22624 1970-01-01 01:00 emacs-24.5/lisp/emacs-lisp/autoload.elc
>>>
>>> Upstream’s tarball already includes those three files.
>>
>> IIUC this source is after applying our patches (including
>> "emacs-source-date-epoch.patch"):
>>
>> - “autoload.el.orig” is the original file from the upstream;
>
> Indeed, this one isn’t present in upstream’s tarball:
>
> $ wget -q -O - ftp://ftp.gnu.org/gnu/emacs/emacs-24.5.tar.xz | tar tJvf - | grep 'autoload\.'
> -rw-rw-r-- nico/nico     37127 2015-04-02 09:23 emacs-24.5/lisp/emacs-lisp/autoload.el
> -rw-r--r-- nico/nico     22624 2015-04-08 19:16 emacs-24.5/lisp/emacs-lisp/autoload.elc
>
> How come we’re introducing this one?  I thought ‘patch’ did not produce
> .orig files unless the patch failed to apply, but here the patch
> correctly applies, only with a small offset (can be seen by running
> ‘guix build -S emacs --check’):
>
> patching file lisp/loadup.el
> patching file lisp/emacs-lisp/autoload.el
> Hunk #1 succeeded at 361 (offset -17 lines).

Indeed, I also didn't know that "patch" produces such .orig files when a
patch applies with offset.

> Apparently we have to use ‘--no-backup-if-mismatch’ to avoid that.

You even found the flag, thanks!  So is it OK to apply the attached
patch to core-updates?

Comments

Ludovic Courtès May 20, 2016, 12:02 p.m. UTC | #1
Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2016-05-17 12:12 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2016-05-16 15:45 +0300) wrote:
> [...]
>>>> $ git describe
>>>> v0.10.0-798-g8a7680a
>>>> $ tar tvf $(./pre-inst-env guix build -S emacs) |grep 'autoload\.el'
>>>> -rw-r--r-- root/root     37292 1970-01-01 01:00 emacs-24.5/lisp/emacs-lisp/autoload.el
>>>> -rw-r--r-- root/root     37127 1970-01-01 01:00 emacs-24.5/lisp/emacs-lisp/autoload.el.orig
>>>> -rw-r--r-- root/root     22624 1970-01-01 01:00 emacs-24.5/lisp/emacs-lisp/autoload.elc
>>>>
>>>> Upstream’s tarball already includes those three files.
>>>
>>> IIUC this source is after applying our patches (including
>>> "emacs-source-date-epoch.patch"):
>>>
>>> - “autoload.el.orig” is the original file from the upstream;
>>
>> Indeed, this one isn’t present in upstream’s tarball:
>>
>> $ wget -q -O - ftp://ftp.gnu.org/gnu/emacs/emacs-24.5.tar.xz | tar tJvf - | grep 'autoload\.'
>> -rw-rw-r-- nico/nico     37127 2015-04-02 09:23 emacs-24.5/lisp/emacs-lisp/autoload.el
>> -rw-r--r-- nico/nico     22624 2015-04-08 19:16 emacs-24.5/lisp/emacs-lisp/autoload.elc
>>
>> How come we’re introducing this one?  I thought ‘patch’ did not produce
>> .orig files unless the patch failed to apply, but here the patch
>> correctly applies, only with a small offset (can be seen by running
>> ‘guix build -S emacs --check’):
>>
>> patching file lisp/loadup.el
>> patching file lisp/emacs-lisp/autoload.el
>> Hunk #1 succeeded at 361 (offset -17 lines).
>
> Indeed, I also didn't know that "patch" produces such .orig files when a
> patch applies with offset.
>
>> Apparently we have to use ‘--no-backup-if-mismatch’ to avoid that.
>
> You even found the flag, thanks!  So is it OK to apply the attached
> patch to core-updates?

The patch LGTM, but since this is a full-rebuild change, I prefer keep
it for the next core-updates cycle.  Let’s try not to forget about it.
:-)

Thanks,
Ludo’.
Leo Famulari May 20, 2016, 1:38 p.m. UTC | #2
On Fri, May 20, 2016 at 02:02:41PM +0200, Ludovic Courtès wrote:
> The patch LGTM, but since this is a full-rebuild change, I prefer keep
> it for the next core-updates cycle.  Let’s try not to forget about it.

Should we create "core-updates-next" or something like that? I have a
few other patches I don't want to forget about either.
Alex Kost May 20, 2016, 9:14 p.m. UTC | #3
Ludovic Courtès (2016-05-20 15:02 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2016-05-17 12:12 +0300) wrote:
[...]
>>> Apparently we have to use ‘--no-backup-if-mismatch’ to avoid that.
>>
>> You even found the flag, thanks!  So is it OK to apply the attached
>> patch to core-updates?
>
> The patch LGTM, but since this is a full-rebuild change, I prefer keep
> it for the next core-updates cycle.  Let’s try not to forget about it.
> :-)

OK, I will not forget, thanks!
Alex Kost May 21, 2016, 10:49 a.m. UTC | #4
Leo Famulari (2016-05-20 16:38 +0300) wrote:

> On Fri, May 20, 2016 at 02:02:41PM +0200, Ludovic Courtès wrote:
>> The patch LGTM, but since this is a full-rebuild change, I prefer keep
>> it for the next core-updates cycle.  Let’s try not to forget about it.
>
> Should we create "core-updates-next" or something like that? I have a
> few other patches I don't want to forget about either.

Good idea!  I agree.
Ludovic Courtès May 21, 2016, 9:02 p.m. UTC | #5
Alex Kost <alezost@gmail.com> skribis:

> Leo Famulari (2016-05-20 16:38 +0300) wrote:
>
>> On Fri, May 20, 2016 at 02:02:41PM +0200, Ludovic Courtès wrote:
>>> The patch LGTM, but since this is a full-rebuild change, I prefer keep
>>> it for the next core-updates cycle.  Let’s try not to forget about it.
>>
>> Should we create "core-updates-next" or something like that? I have a
>> few other patches I don't want to forget about either.
>
> Good idea!  I agree.

OK, go ahead then.  :-)  We’ll rename it to ‘core-updates’ when the
current one is deleted.

Ludo’.
Alex Kost May 24, 2016, 9:07 a.m. UTC | #6
Ludovic Courtès (2016-05-22 00:02 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Leo Famulari (2016-05-20 16:38 +0300) wrote:
>>
>>> On Fri, May 20, 2016 at 02:02:41PM +0200, Ludovic Courtès wrote:
>>>> The patch LGTM, but since this is a full-rebuild change, I prefer keep
>>>> it for the next core-updates cycle.  Let’s try not to forget about it.
>>>
>>> Should we create "core-updates-next" or something like that? I have a
>>> few other patches I don't want to forget about either.
>>
>> Good idea!  I agree.
>
> OK, go ahead then.  :-)  We’ll rename it to ‘core-updates’ when the
> current one is deleted.

I went ahead.  Leo, now it's you turn to commit your patches to
"core-updates-next".

I based it on master, not sure if it should be based on "core-updates",
but anyway, it's done already :-)
diff mbox

Patch

From bcd636eff01f39583e8742b123d51550f9500795 Mon Sep 17 00:00:00 2001
From: Alex Kost <alezost@gmail.com>
Date: Thu, 19 May 2016 19:11:58 +0300
Subject: [PATCH] packages: Use '--no-backup-if-mismatch' for patching.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested-by: Ludovic Courtès <ludo@gnu.org>

* guix/packages.scm (patch-and-repack)[build]: Use
  '--no-backup-if-mismatch' patch flag to avoid making *.orig files.
---
 guix/packages.scm | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/guix/packages.scm b/guix/packages.scm
index d62d1f3..a7b502c 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -464,9 +464,11 @@  IMPORTED-MODULES specify modules to use/import for use by SNIPPET."
             (format (current-error-port) "applying '~a'...~%" patch)
 
             ;; Use '--force' so that patches that do not apply perfectly are
-            ;; rejected.
+            ;; rejected.  Use '--no-backup-if-mismatch' to prevent making
+            ;; "*.orig" file if a patch is applied with offset.
             (zero? (system* (string-append #+patch "/bin/patch")
-                            "--force" #+@flags "--input" patch)))
+                            "--force" "--no-backup-if-mismatch"
+                            #+@flags "--input" patch)))
 
           (define (first-file directory)
             ;; Return the name of the first file in DIRECTORY.
-- 
2.7.3