Package: guix;
Reported by: brettg <at> posteo.net
Date: Mon, 18 Nov 2019 19:02:01 UTC
Severity: normal
Tags: fixed
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38261 in the body.
You can then email your comments to 38261 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Mon, 18 Nov 2019 19:02:02 GMT) Full text and rfc822 format available.brettg <at> posteo.net
:bug-guix <at> gnu.org
.
(Mon, 18 Nov 2019 19:02:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Bug guix <Bug-guix <at> gnu.org> Subject: Recent changes to emacs build system Date: Mon, 18 Nov 2019 20:01:29 +0100
Hey all, the recent changes to the emacs build system result in a few broken packages like emacs-pdf-tools, or basically anything that uses a phase for emacs-set-emacs-load-path. For example, I borrowed the technique used by emacs-pdf-tools to package emacs-telega, resulting in both packages failing to build: Here is the code for emacs-telega: https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 The issue is in this phase for both emacs-pdf-tools and my channel package: (add-after 'compress-documentation 'emacs-set-emacs-load-path (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) Resulting in: starting phase `emacs-set-emacs-load-path' Backtrace: 5 (primitive-load "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") In ice-9/eval.scm: 191:35 4 (_ _) In ice-9/boot-9.scm: 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at /gnu/store/zmkg…> …) In srfi/srfi-1.scm: 863:16 2 (every1 #<procedure 7ffff30ae160 at /gnu/store/zmkgrvv…> …) In /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: 839:30 1 (_ _) In unknown file: 0 (_ #:source "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" …) ERROR: Wrong type to apply: #f If we suspect that changes are going to be non-backwards compatible could we use the news system to pass along that message? Much appreciated. Thanks. Brett Gilio
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Mon, 18 Nov 2019 20:30:02 GMT) Full text and rfc822 format available.Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Bug guix <Bug-guix <at> gnu.org> Cc: bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Mon, 18 Nov 2019 21:28:52 +0100
On 18.11.2019 20:01, brettg <at> posteo.net wrote: > Hey all, the recent changes to the emacs build system result in a few > broken packages like emacs-pdf-tools, or basically anything that uses > a phase for emacs-set-emacs-load-path. > > For example, I borrowed the technique used by emacs-pdf-tools to > package emacs-telega, resulting in both packages failing to build: > > Here is the code for emacs-telega: > > https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 > > The issue is in this phase for both emacs-pdf-tools and my channel > package: > > (add-after 'compress-documentation 'emacs-set-emacs-load-path > (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) > > Resulting in: > > starting phase `emacs-set-emacs-load-path' > Backtrace: > 5 (primitive-load "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") > In ice-9/eval.scm: > 191:35 4 (_ _) > In ice-9/boot-9.scm: > 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at /gnu/store/zmkg…> > …) > In srfi/srfi-1.scm: > 863:16 2 (every1 #<procedure 7ffff30ae160 at /gnu/store/zmkgrvv…> > …) > In > /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: > 839:30 1 (_ _) > In unknown file: > 0 (_ #:source "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" > …) > > ERROR: Wrong type to apply: #f > > If we suspect that changes are going to be non-backwards compatible > could we use the news system to pass along that message? Much > appreciated. Thanks. > > Brett Gilio I applied a hotfix to the package by replacing 'set-emacs-load-path with 'add-source-to-load-path. I believe this fix would work for all other affected packages.
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Mon, 18 Nov 2019 20:34:02 GMT) Full text and rfc822 format available.Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Bug guix <Bug-guix <at> gnu.org> Cc: bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Mon, 18 Nov 2019 21:33:41 +0100
On 18.11.2019 21:28, brettg <at> posteo.net wrote: > On 18.11.2019 20:01, brettg <at> posteo.net wrote: >> Hey all, the recent changes to the emacs build system result in a few >> broken packages like emacs-pdf-tools, or basically anything that uses >> a phase for emacs-set-emacs-load-path. >> >> For example, I borrowed the technique used by emacs-pdf-tools to >> package emacs-telega, resulting in both packages failing to build: >> >> Here is the code for emacs-telega: >> >> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 >> >> The issue is in this phase for both emacs-pdf-tools and my channel >> package: >> >> (add-after 'compress-documentation 'emacs-set-emacs-load-path >> (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) >> >> Resulting in: >> >> starting phase `emacs-set-emacs-load-path' >> Backtrace: >> 5 (primitive-load >> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") >> In ice-9/eval.scm: >> 191:35 4 (_ _) >> In ice-9/boot-9.scm: >> 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at /gnu/store/zmkg…> >> …) >> In srfi/srfi-1.scm: >> 863:16 2 (every1 #<procedure 7ffff30ae160 at /gnu/store/zmkgrvv…> >> …) >> In >> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: >> 839:30 1 (_ _) >> In unknown file: >> 0 (_ #:source "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" >> …) >> >> ERROR: Wrong type to apply: #f >> >> If we suspect that changes are going to be non-backwards compatible >> could we use the news system to pass along that message? Much >> appreciated. Thanks. >> >> Brett Gilio > > I applied a hotfix to the package by replacing 'set-emacs-load-path > with 'add-source-to-load-path. I believe this fix would work for all > other affected packages. https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd74e4bb3912173
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Mon, 18 Nov 2019 21:35:02 GMT) Full text and rfc822 format available.Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Bug guix <Bug-guix <at> gnu.org>, Ricardo Wurmus <rekado <at> elephly.net> Cc: bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Mon, 18 Nov 2019 22:34:21 +0100
On 18.11.2019 21:33, brettg <at> posteo.net wrote: > On 18.11.2019 21:28, brettg <at> posteo.net wrote: >> On 18.11.2019 20:01, brettg <at> posteo.net wrote: >>> Hey all, the recent changes to the emacs build system result in a few >>> broken packages like emacs-pdf-tools, or basically anything that uses >>> a phase for emacs-set-emacs-load-path. >>> >>> For example, I borrowed the technique used by emacs-pdf-tools to >>> package emacs-telega, resulting in both packages failing to build: >>> >>> Here is the code for emacs-telega: >>> >>> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 >>> >>> The issue is in this phase for both emacs-pdf-tools and my channel >>> package: >>> >>> (add-after 'compress-documentation 'emacs-set-emacs-load-path >>> (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) >>> >>> Resulting in: >>> >>> starting phase `emacs-set-emacs-load-path' >>> Backtrace: >>> 5 (primitive-load >>> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") >>> In ice-9/eval.scm: >>> 191:35 4 (_ _) >>> In ice-9/boot-9.scm: >>> 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at /gnu/store/zmkg…> >>> …) >>> In srfi/srfi-1.scm: >>> 863:16 2 (every1 #<procedure 7ffff30ae160 at /gnu/store/zmkgrvv…> >>> …) >>> In >>> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: >>> 839:30 1 (_ _) >>> In unknown file: >>> 0 (_ #:source "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" >>> …) >>> >>> ERROR: Wrong type to apply: #f >>> >>> If we suspect that changes are going to be non-backwards compatible >>> could we use the news system to pass along that message? Much >>> appreciated. Thanks. >>> >>> Brett Gilio >> >> I applied a hotfix to the package by replacing 'set-emacs-load-path >> with 'add-source-to-load-path. I believe this fix would work for all >> other affected packages. > > https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd74e4bb3912173 Ricardo, just wanted to make you aware that this emacs-build-system change does break your guile-studio. I discovered this because I adopted some of your ideas of autoloading in the generated emacs lisp from guile-studio when creating my own emacs configuration dependent on guix, which resulted in progn: Wrong number of arguments: (lambda nil "Autoload Emacs packages found in EMACSLOADPATH. 'Autoload' means to load the 'autoloads' files matching `guix-emacs-autoloads-regexp'." (interactive) (let* ((emacs-load-path (getenv "EMACSLOADPATH")) (emacs-non-core-load-path-directories (seq-filter (function (lambda (dir) (string-match-p "/share/emacs/site-lisp" dir))) (split-string emacs-load-path ":"))) (autoloads (mapcan (function guix-emacs-find-autoloads) emacs-non-core-load-path-directories))) (mapc (function (lambda (f) (load f (quote noerror)))) autoloads))), 78 I'll let you know if I can find any fix for this when I get some time. But just wanted to pass the message along. Brett
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Tue, 19 Nov 2019 00:28:02 GMT) Full text and rfc822 format available.Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Bug guix <Bug-guix <at> gnu.org>, Ricardo Wurmus <rekado <at> elephly.net> Cc: bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Tue, 19 Nov 2019 01:27:39 +0100
On 18.11.2019 22:34, brettg <at> posteo.net wrote: > On 18.11.2019 21:33, brettg <at> posteo.net wrote: >> On 18.11.2019 21:28, brettg <at> posteo.net wrote: >>> On 18.11.2019 20:01, brettg <at> posteo.net wrote: >>>> Hey all, the recent changes to the emacs build system result in a >>>> few >>>> broken packages like emacs-pdf-tools, or basically anything that >>>> uses >>>> a phase for emacs-set-emacs-load-path. >>>> >>>> For example, I borrowed the technique used by emacs-pdf-tools to >>>> package emacs-telega, resulting in both packages failing to build: >>>> >>>> Here is the code for emacs-telega: >>>> >>>> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 >>>> >>>> The issue is in this phase for both emacs-pdf-tools and my channel >>>> package: >>>> >>>> (add-after 'compress-documentation 'emacs-set-emacs-load-path >>>> (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) >>>> >>>> Resulting in: >>>> >>>> starting phase `emacs-set-emacs-load-path' >>>> Backtrace: >>>> 5 (primitive-load >>>> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") >>>> In ice-9/eval.scm: >>>> 191:35 4 (_ _) >>>> In ice-9/boot-9.scm: >>>> 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at >>>> /gnu/store/zmkg…> …) >>>> In srfi/srfi-1.scm: >>>> 863:16 2 (every1 #<procedure 7ffff30ae160 at >>>> /gnu/store/zmkgrvv…> …) >>>> In >>>> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: >>>> 839:30 1 (_ _) >>>> In unknown file: >>>> 0 (_ #:source >>>> "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" …) >>>> >>>> ERROR: Wrong type to apply: #f >>>> >>>> If we suspect that changes are going to be non-backwards compatible >>>> could we use the news system to pass along that message? Much >>>> appreciated. Thanks. >>>> >>>> Brett Gilio >>> >>> I applied a hotfix to the package by replacing 'set-emacs-load-path >>> with 'add-source-to-load-path. I believe this fix would work for all >>> other affected packages. >> >> https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd74e4bb3912173 > > Ricardo, just wanted to make you aware that this emacs-build-system > change does break your guile-studio. I discovered this because I > adopted some of your ideas of autoloading in the generated emacs lisp > from guile-studio when creating my own emacs configuration dependent > on guix, which resulted in > > progn: Wrong number of arguments: (lambda nil "Autoload Emacs packages > found in EMACSLOADPATH. > > 'Autoload' means to load the 'autoloads' files matching > `guix-emacs-autoloads-regexp'." (interactive) (let* ((emacs-load-path > (getenv "EMACSLOADPATH")) (emacs-non-core-load-path-directories > (seq-filter (function (lambda (dir) (string-match-p > "/share/emacs/site-lisp" dir))) (split-string emacs-load-path ":"))) > (autoloads (mapcan (function guix-emacs-find-autoloads) > emacs-non-core-load-path-directories))) (mapc (function (lambda (f) > (load f (quote noerror)))) autoloads))), 78 > > I'll let you know if I can find any fix for this when I get some time. > But just wanted to pass the message along. > > Brett I tried removing the arguments passed to `guix-emacs-autoload-packages' as the updated version (http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aux-files/emacs/guix-emacs.el?id=47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c) does not carry arguments anymore, instead depending on a variable EMACSLOADPATH. However, whenever that is done it returns split-string: Wrong type argument: stringp, nil possibly because my system is not finding EMACSLOADPATH. I will keep investigating.
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Tue, 19 Nov 2019 00:33:02 GMT) Full text and rfc822 format available.Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Bug guix <Bug-guix <at> gnu.org>, Ricardo Wurmus <rekado <at> elephly.net> Cc: bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Tue, 19 Nov 2019 01:32:06 +0100
On 19.11.2019 01:27, brettg <at> posteo.net wrote: > On 18.11.2019 22:34, brettg <at> posteo.net wrote: >> On 18.11.2019 21:33, brettg <at> posteo.net wrote: >>> On 18.11.2019 21:28, brettg <at> posteo.net wrote: >>>> On 18.11.2019 20:01, brettg <at> posteo.net wrote: >>>>> Hey all, the recent changes to the emacs build system result in a >>>>> few >>>>> broken packages like emacs-pdf-tools, or basically anything that >>>>> uses >>>>> a phase for emacs-set-emacs-load-path. >>>>> >>>>> For example, I borrowed the technique used by emacs-pdf-tools to >>>>> package emacs-telega, resulting in both packages failing to build: >>>>> >>>>> Here is the code for emacs-telega: >>>>> >>>>> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 >>>>> >>>>> The issue is in this phase for both emacs-pdf-tools and my channel >>>>> package: >>>>> >>>>> (add-after 'compress-documentation 'emacs-set-emacs-load-path >>>>> (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) >>>>> >>>>> Resulting in: >>>>> >>>>> starting phase `emacs-set-emacs-load-path' >>>>> Backtrace: >>>>> 5 (primitive-load >>>>> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") >>>>> In ice-9/eval.scm: >>>>> 191:35 4 (_ _) >>>>> In ice-9/boot-9.scm: >>>>> 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at >>>>> /gnu/store/zmkg…> …) >>>>> In srfi/srfi-1.scm: >>>>> 863:16 2 (every1 #<procedure 7ffff30ae160 at >>>>> /gnu/store/zmkgrvv…> …) >>>>> In >>>>> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: >>>>> 839:30 1 (_ _) >>>>> In unknown file: >>>>> 0 (_ #:source >>>>> "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" …) >>>>> >>>>> ERROR: Wrong type to apply: #f >>>>> >>>>> If we suspect that changes are going to be non-backwards compatible >>>>> could we use the news system to pass along that message? Much >>>>> appreciated. Thanks. >>>>> >>>>> Brett Gilio >>>> >>>> I applied a hotfix to the package by replacing 'set-emacs-load-path >>>> with 'add-source-to-load-path. I believe this fix would work for all >>>> other affected packages. >>> >>> https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd74e4bb3912173 >> >> Ricardo, just wanted to make you aware that this emacs-build-system >> change does break your guile-studio. I discovered this because I >> adopted some of your ideas of autoloading in the generated emacs lisp >> from guile-studio when creating my own emacs configuration dependent >> on guix, which resulted in >> >> progn: Wrong number of arguments: (lambda nil "Autoload Emacs packages >> found in EMACSLOADPATH. >> >> 'Autoload' means to load the 'autoloads' files matching >> `guix-emacs-autoloads-regexp'." (interactive) (let* ((emacs-load-path >> (getenv "EMACSLOADPATH")) (emacs-non-core-load-path-directories >> (seq-filter (function (lambda (dir) (string-match-p >> "/share/emacs/site-lisp" dir))) (split-string emacs-load-path ":"))) >> (autoloads (mapcan (function guix-emacs-find-autoloads) >> emacs-non-core-load-path-directories))) (mapc (function (lambda (f) >> (load f (quote noerror)))) autoloads))), 78 >> >> I'll let you know if I can find any fix for this when I get some time. >> But just wanted to pass the message along. >> >> Brett > > I tried removing the arguments passed to > `guix-emacs-autoload-packages' as the updated version > (http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aux-files/emacs/guix-emacs.el?id=47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c) > does not carry arguments anymore, instead depending on a variable > EMACSLOADPATH. However, whenever that is done it returns > > split-string: Wrong type argument: stringp, nil > > possibly because my system is not finding EMACSLOADPATH. > > I will keep investigating. I can confirm, when running something analogous to `guix environment --ad-hoc emacs-dashboard` no changes are being made to the $GUIX_ENVIRONMENT/etc/profile to resemble EMACSLOADPATH.
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Tue, 19 Nov 2019 01:59:02 GMT) Full text and rfc822 format available.Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Bug guix <Bug-guix <at> gnu.org>, Ricardo Wurmus <rekado <at> elephly.net> Cc: bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Tue, 19 Nov 2019 02:58:33 +0100
On 19.11.2019 01:32, brettg <at> posteo.net wrote: > On 19.11.2019 01:27, brettg <at> posteo.net wrote: >> On 18.11.2019 22:34, brettg <at> posteo.net wrote: >>> On 18.11.2019 21:33, brettg <at> posteo.net wrote: >>>> On 18.11.2019 21:28, brettg <at> posteo.net wrote: >>>>> On 18.11.2019 20:01, brettg <at> posteo.net wrote: >>>>>> Hey all, the recent changes to the emacs build system result in a >>>>>> few >>>>>> broken packages like emacs-pdf-tools, or basically anything that >>>>>> uses >>>>>> a phase for emacs-set-emacs-load-path. >>>>>> >>>>>> For example, I borrowed the technique used by emacs-pdf-tools to >>>>>> package emacs-telega, resulting in both packages failing to build: >>>>>> >>>>>> Here is the code for emacs-telega: >>>>>> >>>>>> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 >>>>>> >>>>>> The issue is in this phase for both emacs-pdf-tools and my channel >>>>>> package: >>>>>> >>>>>> (add-after 'compress-documentation 'emacs-set-emacs-load-path >>>>>> (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) >>>>>> >>>>>> Resulting in: >>>>>> >>>>>> starting phase `emacs-set-emacs-load-path' >>>>>> Backtrace: >>>>>> 5 (primitive-load >>>>>> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") >>>>>> In ice-9/eval.scm: >>>>>> 191:35 4 (_ _) >>>>>> In ice-9/boot-9.scm: >>>>>> 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at >>>>>> /gnu/store/zmkg…> …) >>>>>> In srfi/srfi-1.scm: >>>>>> 863:16 2 (every1 #<procedure 7ffff30ae160 at >>>>>> /gnu/store/zmkgrvv…> …) >>>>>> In >>>>>> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: >>>>>> 839:30 1 (_ _) >>>>>> In unknown file: >>>>>> 0 (_ #:source >>>>>> "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" …) >>>>>> >>>>>> ERROR: Wrong type to apply: #f >>>>>> >>>>>> If we suspect that changes are going to be non-backwards >>>>>> compatible >>>>>> could we use the news system to pass along that message? Much >>>>>> appreciated. Thanks. >>>>>> >>>>>> Brett Gilio >>>>> >>>>> I applied a hotfix to the package by replacing 'set-emacs-load-path >>>>> with 'add-source-to-load-path. I believe this fix would work for >>>>> all >>>>> other affected packages. >>>> >>>> https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd74e4bb3912173 >>> >>> Ricardo, just wanted to make you aware that this emacs-build-system >>> change does break your guile-studio. I discovered this because I >>> adopted some of your ideas of autoloading in the generated emacs lisp >>> from guile-studio when creating my own emacs configuration dependent >>> on guix, which resulted in >>> >>> progn: Wrong number of arguments: (lambda nil "Autoload Emacs >>> packages >>> found in EMACSLOADPATH. >>> >>> 'Autoload' means to load the 'autoloads' files matching >>> `guix-emacs-autoloads-regexp'." (interactive) (let* ((emacs-load-path >>> (getenv "EMACSLOADPATH")) (emacs-non-core-load-path-directories >>> (seq-filter (function (lambda (dir) (string-match-p >>> "/share/emacs/site-lisp" dir))) (split-string emacs-load-path ":"))) >>> (autoloads (mapcan (function guix-emacs-find-autoloads) >>> emacs-non-core-load-path-directories))) (mapc (function (lambda (f) >>> (load f (quote noerror)))) autoloads))), 78 >>> >>> I'll let you know if I can find any fix for this when I get some >>> time. >>> But just wanted to pass the message along. >>> >>> Brett >> >> I tried removing the arguments passed to >> `guix-emacs-autoload-packages' as the updated version >> (http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aux-files/emacs/guix-emacs.el?id=47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c) >> does not carry arguments anymore, instead depending on a variable >> EMACSLOADPATH. However, whenever that is done it returns >> >> split-string: Wrong type argument: stringp, nil >> >> possibly because my system is not finding EMACSLOADPATH. >> >> I will keep investigating. > > I can confirm, when running something analogous to `guix environment > --ad-hoc emacs-dashboard` no changes are being made to the > $GUIX_ENVIRONMENT/etc/profile to resemble EMACSLOADPATH. So I have investigated the issue with EMACSLOADPATH: Similar to Ricardo's guile-studio, my package enlign was using the autoload function from guix-emacs.el to propagate a list of packages called from inputs to be loaded with the start of emacs. I have since revised this to just call the autoload function directly, no longer passing any arguments, and had to modify my enlign package to respect the EMACSLOADPATH variable. This is only possible if all of the packages are passed as propagated-inputs though, which is less than desirable in my opinion (though I am willing to be convinced.) This additionally leads to having to require emacs as a propagated input as well, as leading it native or regular input leads to an error with emacs not recognizing simple.el or mule-util. Overall, I am not sure if I like the recent change to guix-emacs.el. I understand where the incentive is to do this, but ultimately it seems to lead to more headache when creating packages around emacs. https://git.sr.ht/~brettgilio/cfg/commit/47bc9ae544ba10c0cacef1435625dcb0114e8cf5 Anyways, If there is no other comment, this issue really just needs to fix emacs-pdf-tools and other affected packages from the recent string of changes. Best, Brett Gilio
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Tue, 19 Nov 2019 21:16:02 GMT) Full text and rfc822 format available.Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: brettg <at> posteo.net Cc: Ricardo Wurmus <rekado <at> elephly.net>, bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org>, Bug guix <Bug-guix <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Wed, 20 Nov 2019 06:14:46 +0900
Hello Brett, Thank you for the heads-up concerning the latest changes to the way Emacs find its libraries and the adjustments done to the emacs-build-system. brettg <at> posteo.net writes: > On 19.11.2019 01:32, brettg <at> posteo.net wrote: >> On 19.11.2019 01:27, brettg <at> posteo.net wrote: >>> On 18.11.2019 22:34, brettg <at> posteo.net wrote: >>>> On 18.11.2019 21:33, brettg <at> posteo.net wrote: >>>>> On 18.11.2019 21:28, brettg <at> posteo.net wrote: >>>>>> On 18.11.2019 20:01, brettg <at> posteo.net wrote: >>>>>>> Hey all, the recent changes to the emacs build system result in >>>>>>> a few >>>>>>> broken packages like emacs-pdf-tools, or basically anything >>>>>>> that uses >>>>>>> a phase for emacs-set-emacs-load-path. >>>>>>> >>>>>>> For example, I borrowed the technique used by emacs-pdf-tools to >>>>>>> package emacs-telega, resulting in both packages failing to build: >>>>>>> >>>>>>> Here is the code for emacs-telega: >>>>>>> >>>>>>> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 >>>>>>> >>>>>>> The issue is in this phase for both emacs-pdf-tools and my >>>>>>> channel package: >>>>>>> >>>>>>> (add-after 'compress-documentation 'emacs-set-emacs-load-path >>>>>>> (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) >>>>>>> >>>>>>> Resulting in: >>>>>>> >>>>>>> starting phase `emacs-set-emacs-load-path' >>>>>>> Backtrace: >>>>>>> 5 (primitive-load >>>>>>> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") >>>>>>> In ice-9/eval.scm: >>>>>>> 191:35 4 (_ _) >>>>>>> In ice-9/boot-9.scm: >>>>>>> 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at >>>>>>> /gnu/store/zmkg…> …) >>>>>>> In srfi/srfi-1.scm: >>>>>>> 863:16 2 (every1 #<procedure 7ffff30ae160 at >>>>>>> /gnu/store/zmkgrvv…> …) >>>>>>> In >>>>>>> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: >>>>>>> 839:30 1 (_ _) >>>>>>> In unknown file: >>>>>>> 0 (_ #:source >>>>>>> "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" …) >>>>>>> >>>>>>> ERROR: Wrong type to apply: #f Sorry for failing to foresee this problem. I've fixed the couple packages that were impacted on master now. You can have a look at the fixes (they are fairly simple). >>>>>>> If we suspect that changes are going to be non-backwards >>>>>>> compatible >>>>>>> could we use the news system to pass along that message? Much >>>>>>> appreciated. Thanks. >>>>>>> >>>>>>> Brett Gilio >>>>>> >>>>>> I applied a hotfix to the package by replacing 'set-emacs-load-path >>>>>> with 'add-source-to-load-path. I believe this fix would work for >>>>>> all >>>>>> other affected packages. >>>>> >>>>> https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd74e4bb3912173 Indeed! >>>> Ricardo, just wanted to make you aware that this emacs-build-system >>>> change does break your guile-studio. I discovered this because I >>>> adopted some of your ideas of autoloading in the generated emacs lisp >>>> from guile-studio when creating my own emacs configuration dependent >>>> on guix, which resulted in >>>> >>>> progn: Wrong number of arguments: (lambda nil "Autoload Emacs >>>> packages >>>> found in EMACSLOADPATH. >>>> >>>> 'Autoload' means to load the 'autoloads' files matching >>>> `guix-emacs-autoloads-regexp'." (interactive) (let* ((emacs-load-path >>>> (getenv "EMACSLOADPATH")) (emacs-non-core-load-path-directories >>>> (seq-filter (function (lambda (dir) (string-match-p >>>> "/share/emacs/site-lisp" dir))) (split-string emacs-load-path ":"))) >>>> (autoloads (mapcan (function guix-emacs-find-autoloads) >>>> emacs-non-core-load-path-directories))) (mapc (function (lambda (f) >>>> (load f (quote noerror)))) autoloads))), 78 >>>> >>>> I'll let you know if I can find any fix for this when I get some >>>> time. >>>> But just wanted to pass the message along. >>>> >>>> Brett >>> >>> I tried removing the arguments passed to >>> `guix-emacs-autoload-packages' as the updated version >>> (http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aux-files/emacs/guix-emacs.el?id=47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c) >>> does not carry arguments anymore, instead depending on a variable >>> EMACSLOADPATH. However, whenever that is done it returns >>> >>> split-string: Wrong type argument: stringp, nil >>> >>> possibly because my system is not finding EMACSLOADPATH. Yes, that's the reason. Perhaps it could be worthwhile to give a better message in this condition, but it's unclear to me why this condition would arise at all. Would you mind giving some more background to how you got into that situation? I'll try building guile-studio and see if I could get a hint or two. >>> I will keep investigating. >> >> I can confirm, when running something analogous to `guix environment >> --ad-hoc emacs-dashboard` no changes are being made to the >> $GUIX_ENVIRONMENT/etc/profile to resemble EMACSLOADPATH. > > So I have investigated the issue with EMACSLOADPATH: Similar to > Ricardo's guile-studio, > my package enlign was using the autoload function from guix-emacs.el > to propagate a list > of packages called from inputs to be loaded with the start of emacs. > > I have since revised this to just call the autoload function directly, > no longer passing any arguments, and had to modify my enlign package > to respect the EMACSLOADPATH variable. This is only possible if all of > the packages are passed as propagated-inputs though, which is less > than desirable in my opinion (though I am willing to be convinced.) Is your package an Emacs library/package? If so, just defining the other Elisp dependencies of this package as propagated inputs would be the correct solution. For other cases (I can't think of how that would work exactly), perhaps wrapping the package's script with the computed EMACSLOADPATH environment variable could do? > This additionally leads to having to require emacs as a propagated > input as well, as leading it native or regular input leads to an error > with emacs not recognizing simple.el or mule-util. Do you mean, that your package somehow uses Emacs without having Emacs installed in the profile (not being propagated)? If this is the case, wrapping your program with EMACSLOADPATH (and patching its reference to Emacs) should work, without having to propagate anything. > Overall, I am not sure if I like the recent change to guix-emacs.el. I > understand where the incentive is to do this, but ultimately it seems > to lead to more headache when creating packages around emacs. > > https://git.sr.ht/~brettgilio/cfg/commit/47bc9ae544ba10c0cacef1435625dcb0114e8cf5 > > Anyways, > > If there is no other comment, this issue really just needs to fix > emacs-pdf-tools and other affected packages from the recent string of > changes. I'm sorry you've had some problems with this recent change! Thanks for bringing them out. Please do continue, I'm interested to know about any remaining issues you might find. Maxim
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Tue, 19 Nov 2019 21:17:01 GMT) Full text and rfc822 format available.Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ricardo Wurmus <rekado <at> elephly.net>, bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org>, Bug guix <Bug-guix <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Tue, 19 Nov 2019 22:16:43 +0100
On 19.11.2019 22:14, Maxim Cournoyer wrote: > Hello Brett, > > Thank you for the heads-up concerning the latest changes to the way > Emacs find its libraries and the adjustments done to the > emacs-build-system. > > brettg <at> posteo.net writes: > >> On 19.11.2019 01:32, brettg <at> posteo.net wrote: >>> On 19.11.2019 01:27, brettg <at> posteo.net wrote: >>>> On 18.11.2019 22:34, brettg <at> posteo.net wrote: >>>>> On 18.11.2019 21:33, brettg <at> posteo.net wrote: >>>>>> On 18.11.2019 21:28, brettg <at> posteo.net wrote: >>>>>>> On 18.11.2019 20:01, brettg <at> posteo.net wrote: >>>>>>>> Hey all, the recent changes to the emacs build system result in >>>>>>>> a few >>>>>>>> broken packages like emacs-pdf-tools, or basically anything >>>>>>>> that uses >>>>>>>> a phase for emacs-set-emacs-load-path. >>>>>>>> >>>>>>>> For example, I borrowed the technique used by emacs-pdf-tools to >>>>>>>> package emacs-telega, resulting in both packages failing to >>>>>>>> build: >>>>>>>> >>>>>>>> Here is the code for emacs-telega: >>>>>>>> >>>>>>>> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99 >>>>>>>> >>>>>>>> The issue is in this phase for both emacs-pdf-tools and my >>>>>>>> channel package: >>>>>>>> >>>>>>>> (add-after 'compress-documentation 'emacs-set-emacs-load-path >>>>>>>> (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) >>>>>>>> >>>>>>>> Resulting in: >>>>>>>> >>>>>>>> starting phase `emacs-set-emacs-load-path' >>>>>>>> Backtrace: >>>>>>>> 5 (primitive-load >>>>>>>> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…") >>>>>>>> In ice-9/eval.scm: >>>>>>>> 191:35 4 (_ _) >>>>>>>> In ice-9/boot-9.scm: >>>>>>>> 829:9 3 (catch _ _ #<procedure 7ffff3bbb518 at >>>>>>>> /gnu/store/zmkg…> …) >>>>>>>> In srfi/srfi-1.scm: >>>>>>>> 863:16 2 (every1 #<procedure 7ffff30ae160 at >>>>>>>> /gnu/store/zmkgrvv…> …) >>>>>>>> In >>>>>>>> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm: >>>>>>>> 839:30 1 (_ _) >>>>>>>> In unknown file: >>>>>>>> 0 (_ #:source >>>>>>>> "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" …) >>>>>>>> >>>>>>>> ERROR: Wrong type to apply: #f > > Sorry for failing to foresee this problem. I've fixed the couple > packages that were impacted on master now. You can have a look at the > fixes (they are fairly simple). > >>>>>>>> If we suspect that changes are going to be non-backwards >>>>>>>> compatible >>>>>>>> could we use the news system to pass along that message? Much >>>>>>>> appreciated. Thanks. >>>>>>>> >>>>>>>> Brett Gilio >>>>>>> >>>>>>> I applied a hotfix to the package by replacing >>>>>>> 'set-emacs-load-path >>>>>>> with 'add-source-to-load-path. I believe this fix would work for >>>>>>> all >>>>>>> other affected packages. >>>>>> >>>>>> https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd74e4bb3912173 > > Indeed! > >>>>> Ricardo, just wanted to make you aware that this emacs-build-system >>>>> change does break your guile-studio. I discovered this because I >>>>> adopted some of your ideas of autoloading in the generated emacs >>>>> lisp >>>>> from guile-studio when creating my own emacs configuration >>>>> dependent >>>>> on guix, which resulted in >>>>> >>>>> progn: Wrong number of arguments: (lambda nil "Autoload Emacs >>>>> packages >>>>> found in EMACSLOADPATH. >>>>> >>>>> 'Autoload' means to load the 'autoloads' files matching >>>>> `guix-emacs-autoloads-regexp'." (interactive) (let* >>>>> ((emacs-load-path >>>>> (getenv "EMACSLOADPATH")) (emacs-non-core-load-path-directories >>>>> (seq-filter (function (lambda (dir) (string-match-p >>>>> "/share/emacs/site-lisp" dir))) (split-string emacs-load-path >>>>> ":"))) >>>>> (autoloads (mapcan (function guix-emacs-find-autoloads) >>>>> emacs-non-core-load-path-directories))) (mapc (function (lambda (f) >>>>> (load f (quote noerror)))) autoloads))), 78 >>>>> >>>>> I'll let you know if I can find any fix for this when I get some >>>>> time. >>>>> But just wanted to pass the message along. >>>>> >>>>> Brett >>>> >>>> I tried removing the arguments passed to >>>> `guix-emacs-autoload-packages' as the updated version >>>> (http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aux-files/emacs/guix-emacs.el?id=47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c) >>>> does not carry arguments anymore, instead depending on a variable >>>> EMACSLOADPATH. However, whenever that is done it returns >>>> >>>> split-string: Wrong type argument: stringp, nil >>>> >>>> possibly because my system is not finding EMACSLOADPATH. > > Yes, that's the reason. Perhaps it could be worthwhile to give a > better > message in this condition, but it's unclear to me why this condition > would arise at all. Would you mind giving some more background to how > you got into that situation? I'll try building guile-studio and see if > I could get a hint or two. > >>>> I will keep investigating. >>> >>> I can confirm, when running something analogous to `guix environment >>> --ad-hoc emacs-dashboard` no changes are being made to the >>> $GUIX_ENVIRONMENT/etc/profile to resemble EMACSLOADPATH. >> >> So I have investigated the issue with EMACSLOADPATH: Similar to >> Ricardo's guile-studio, >> my package enlign was using the autoload function from guix-emacs.el >> to propagate a list >> of packages called from inputs to be loaded with the start of emacs. >> >> I have since revised this to just call the autoload function directly, >> no longer passing any arguments, and had to modify my enlign package >> to respect the EMACSLOADPATH variable. This is only possible if all of >> the packages are passed as propagated-inputs though, which is less >> than desirable in my opinion (though I am willing to be convinced.) > > Is your package an Emacs library/package? If so, just defining the > other > Elisp dependencies of this package as propagated inputs would be the > correct solution. > > For other cases (I can't think of how that would work exactly), perhaps > wrapping the package's script with the computed EMACSLOADPATH > environment variable could do? > >> This additionally leads to having to require emacs as a propagated >> input as well, as leading it native or regular input leads to an error >> with emacs not recognizing simple.el or mule-util. > > Do you mean, that your package somehow uses Emacs without having Emacs > installed in the profile (not being propagated)? If this is the case, > wrapping your program with EMACSLOADPATH (and patching its reference to > Emacs) should work, without having to propagate anything. > >> Overall, I am not sure if I like the recent change to guix-emacs.el. I >> understand where the incentive is to do this, but ultimately it seems >> to lead to more headache when creating packages around emacs. >> >> https://git.sr.ht/~brettgilio/cfg/commit/47bc9ae544ba10c0cacef1435625dcb0114e8cf5 >> >> Anyways, >> >> If there is no other comment, this issue really just needs to fix >> emacs-pdf-tools and other affected packages from the recent string of >> changes. > > I'm sorry you've had some problems with this recent change! Thanks for > bringing them out. Please do continue, I'm interested to know about > any > remaining issues you might find. > > Maxim Thank you for your work Maxim, I think most of them are resolved now. I do wonder about what prompted the change, though. Perhaps you might share? Brett
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Tue, 19 Nov 2019 21:30:02 GMT) Full text and rfc822 format available.Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: brettg <at> posteo.net Cc: Ricardo Wurmus <rekado <at> elephly.net>, bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org>, Bug guix <Bug-guix <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Wed, 20 Nov 2019 06:29:05 +0900
brettg <at> posteo.net writes: [...] > Thank you for your work Maxim, I think most of them are resolved > now. I do wonder about what prompted the change, though. Perhaps you > might share? > > Brett The main motivation was to gain the ability to install Emacs in a given profile and have it use the Elisp libraries installed in said profile (and only from that profile). Using a search path specification is the native Guix mechanism to find libraries for systems that mostly rely on the FHS and means it work consistently across profiles, environments, or other features supported by Guix. There was a discussion here about this change and some feedback in the two weeks it was published preceding its merge: https://lists.gnu.org/archive/html/help-guix/2019-11/msg00000.html. HTH! Maxim
bug-guix <at> gnu.org
:bug#38261
; Package guix
.
(Tue, 19 Nov 2019 21:33:02 GMT) Full text and rfc822 format available.Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):
From: brettg <at> posteo.net To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Ricardo Wurmus <rekado <at> elephly.net>, bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org>, Bug guix <Bug-guix <at> gnu.org> Subject: Re: bug#38261: Recent changes to emacs build system Date: Tue, 19 Nov 2019 22:32:29 +0100
On 19.11.2019 22:29, Maxim Cournoyer wrote: > brettg <at> posteo.net writes: > > [...] > >> Thank you for your work Maxim, I think most of them are resolved >> now. I do wonder about what prompted the change, though. Perhaps you >> might share? >> >> Brett > > The main motivation was to gain the ability to install Emacs in a given > profile and have it use the Elisp libraries installed in said profile > (and only from that profile). Using a search path specification is the > native Guix mechanism to find libraries for systems that mostly rely on > the FHS and means it work consistently across profiles, environments, > or > other features supported by Guix. > > There was a discussion here about this change and some feedback in the > two weeks it was published preceding its merge: > https://lists.gnu.org/archive/html/help-guix/2019-11/msg00000.html. > > HTH! > > Maxim Maxim, indeed it does! I guess I was out of the loop on that conversation and it just took me by surprise! Thanks for your efforts. Best, Brett
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
to control <at> debbugs.gnu.org
.
(Thu, 28 Nov 2019 05:22:01 GMT) Full text and rfc822 format available.Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
to control <at> debbugs.gnu.org
.
(Thu, 28 Nov 2019 05:22:01 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Thu, 26 Dec 2019 12:24:06 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.