Ludovic Courtès (2016-05-22 00:02 +0300) wrote:
> Alex Kost 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-upda
Ludovic Courtès (2016-05-22 00:01 +0300) wrote:
> Alex Kost skribis:
>
>> From 13c2e7123d3b8f7dda5814c2ac00acfe806cec3b Mon Sep 17 00:00:00 2001
>> From: Alex Kost
>> Date: Thu, 19 May 2016 11:01:40 +0300
>> Subject: [PATCH] gnu: emacs: Remove *.elc and autoloads from the tarball.
>>
>> * gnu/pa
Alex Kost 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.
>>
>> Shoul
Alex Kost skribis:
> From 13c2e7123d3b8f7dda5814c2ac00acfe806cec3b Mon Sep 17 00:00:00 2001
> From: Alex Kost
> Date: Thu, 19 May 2016 11:01:40 +0300
> Subject: [PATCH] gnu: emacs: Remove *.elc and autoloads from the tarball.
>
> * gnu/packages/emacs.scm (emacs)[source]: Add 'snippet' to remove
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-nex
Ludovic Courtès (2016-05-19 15:56 +0300) wrote:
>> From ca571f7631bf77ddc8ad6257fe165b4ff0ef5e6b Mon Sep 17 00:00:00 2001
>> From: Alex Kost
>> Date: Thu, 19 May 2016 11:01:40 +0300
>> Subject: [PATCH] gnu: emacs: Remove *.elc from the release tarball.
>>
>> * gnu/packages/emacs.scm (emacs)[argum
Ludovic Courtès (2016-05-20 15:02 +0300) wrote:
> Alex Kost 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
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
Alex Kost skribis:
> Ludovic Courtès (2016-05-17 12:12 +0300) wrote:
>
>> Alex Kost 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
Ludovic Courtès (2016-05-17 12:12 +0300) wrote:
> Alex Kost 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
Alex Kost skribis:
> Ludovic Courtès (2016-05-16 15:45 +0300) wrote:
>
>> Alex Kost skribis:
>>
>>> To recap: we use "gnu/packages/patches/emacs-source-date-epoch.patch" to
>>> modify 'autoload-insert-section-header' function, and it should work,
>>> but it doesn't. IIUC this happens because "a
Ludovic Courtès (2016-05-16 15:45 +0300) wrote:
> Alex Kost skribis:
>
>> To recap: we use "gnu/packages/patches/emacs-source-date-epoch.patch" to
>> modify 'autoload-insert-section-header' function, and it should work,
>> but it doesn't. IIUC this happens because "autoload.elc" file was
>> comp
Alex Kost skribis:
> Ludovic Courtès (2016-05-16 15:45 +0300) wrote:
>
>> Alex Kost skribis:
> [...]
>>> I looked at the compiled "autoload.elc" file and if I understood it
>>> correctly, it was compiled using the unpatched version of "autoload.el"
>>> (because there is no mention of SOURCE_DATE
Ludovic Courtès (2016-05-16 15:45 +0300) wrote:
> Alex Kost skribis:
[...]
>> I looked at the compiled "autoload.elc" file and if I understood it
>> correctly, it was compiled using the unpatched version of "autoload.el"
>> (because there is no mention of SOURCE_DATE_EPOCH there).
>
> Indeed.
>
>
Hi!
Alex Kost skribis:
> To recap: we use "gnu/packages/patches/emacs-source-date-epoch.patch" to
> modify 'autoload-insert-section-header' function, and it should work,
> but it doesn't. IIUC this happens because "autoload.elc" file was
> compiled using the unpatched "autoload.el", but first t
I've just noticed that our generated "…-autoloads.el" files still have
unwished timestamps (SOURCE_DATE_EPOCH is not honored).
To recap: we use "gnu/packages/patches/emacs-source-date-epoch.patch" to
modify 'autoload-insert-section-header' function, and it should work,
but it doesn't. IIUC this h
Ludovic Courtès (2015-11-14 18:03 +0300) wrote:
> Alex Kost skribis:
>
>> Ludovic Courtès (2015-11-03 16:27 +0300) wrote:
>
> [...]
>
+ ;; Avoid non-determinism related to generated timestamps.
+ (setenv "SOURCE_DATE_EPOCH" "1")
+
;; The trick is to #:allow-other-keys eve
Alex Kost skribis:
> Ludovic Courtès (2015-11-03 16:27 +0300) wrote:
[...]
>>> + ;; Avoid non-determinism related to generated timestamps.
>>> + (setenv "SOURCE_DATE_EPOCH" "1")
>>> +
>>>;; The trick is to #:allow-other-keys everywhere, so that each procedure
>>> in
>>>;; PHASES can
Ludovic Courtès (2015-11-03 16:27 +0300) wrote:
> Alex Kost skribis:
>
>> Ludovic Courtès (2015-10-21 19:55 +0300) wrote:
>>
>>> Alex Kost skribis:
>>>
I like the idea to honor SOURCE_DATE_EPOCH, so I'm attaching a patch for
this. But now I don't know how to make Guix set this variabl
Alex Kost skribis:
> Ludovic Courtès (2015-10-21 19:55 +0300) wrote:
>
>> Alex Kost skribis:
>>
>>> I like the idea to honor SOURCE_DATE_EPOCH, so I'm attaching a patch for
>>> this. But now I don't know how to make Guix set this variable during
>>> the build process :-( Need help.
>>
>> Ahem,
Ludovic Courtès (2015-10-21 19:55 +0300) wrote:
> Alex Kost skribis:
>
>> I like the idea to honor SOURCE_DATE_EPOCH, so I'm attaching a patch for
>> this. But now I don't know how to make Guix set this variable during
>> the build process :-( Need help.
>
> Ahem, eventually, we’ll have to set
Alex Kost skribis:
> I like the idea to honor SOURCE_DATE_EPOCH, so I'm attaching a patch for
> this. But now I don't know how to make Guix set this variable during
> the build process :-( Need help.
Ahem, eventually, we’ll have to set it in ‘gnu-build’ in (guix build
gnu-build-system) in the
Ludovic Courtès (2015-10-20 22:38 +0300) wrote:
> Alex Kost skribis:
>
[...]
>> However this will fix only those packages, that use
>> ‘emacs-generate-autoloads’ directly or via ‘emacs-build-system’. But
>> there are also packages that generate autoloads on their own (for
>> example, 'emacs-w3m'
Alex Kost skribis:
> Ludovic Courtès (2015-10-20 02:09 +0300) wrote:
>
>> If we diff as explained in the doc below, we see that the Git
>> discrepancies are due to timestamp in Perl’s POD files as well as
>> sorted-by-inode-number ‘tclIndex’ files. For the Emacs modes, the
>> problem is the auto
Ludovic Courtès (2015-10-20 02:09 +0300) wrote:
> If we diff as explained in the doc below, we see that the Git
> discrepancies are due to timestamp in Perl’s POD files as well as
> sorted-by-inode-number ‘tclIndex’ files. For the Emacs modes, the
> problem is the autogenerated autoloads files, w
25 matches
Mail list logo
