Magit/Transient error message

  • Done
  • quality assurance status badge
Details
9 participants
  • Alvin Hsu
  • aurtzy
  • daniel szmulewicz
  • gemmaro
  • Liliana Marie Prikler
  • Richard Sent
  • Rutherther
  • Simon Tournier
  • Tomas Volf
Owner
unassigned
Submitted by
daniel szmulewicz
Severity
normal
D
D
daniel szmulewicz wrote on 28 Jul 14:41 +0200
(address . bug-guix@gnu.org)
CAABPU6-gVgJTL8-qGGGVanMS0cWmtte0VJmEeK_q6LQxaLwapg@mail.gmail.com
Running M-x magit-branch generates the following error:

transient-setup: Symbol’s function definition is void:
transient-prefix-object

In order to reproduce:

guix shell emacs emacs-magit -- emacs -Q

M-x magit-version
Magit 3.3.0-8.538cb2f, Transient 0.7.3, Git 2.45.2, Emacs 29.4, gnu/linux
Attachment: file
A
A
aurtzy wrote on 31 Jul 00:50 +0200
(address . daniel.szmulewicz@gmail.com)(address . 72333@debbugs.gnu.org)
1b85ce10-bff3-4517-b178-a545d2b5a022@gmail.com
Hi Daniel,

> Running M-x magit-branch generates the following error:
>
> transient-setup: Symbol’s function definition is void:
> transient-prefix-object
>
> In order to reproduce:
>
> guix shell emacs emacs-magit -- emacs -Q
>
> M-x magit-version
> Magit 3.3.0-8.538cb2f, Transient 0.7.3, Git 2.45.2, Emacs 29.4, gnu/linux

It looks like this is because emacs is actually using the built-in (older)
version of transient, while magit relies on a function from a newer version.

Evaluating the following definition from the newer transient source code
fixes
this particular issue for me (I've put it in my init.el for the time being):

#+begin_src lisp
  (defun transient-prefix-object ()
    (or transient--prefix transient-current-prefix))
#+end_src

This sounds similar to another issue with embark and org [1], however in
that
report it was because emacs-org was not included in the environment; in this
case, the newer version of transient is already an input of magit in the
guix
package, so I'm not sure what's happening here.


Cheers,

aurtzy
A
A
Alvin Hsu wrote on 31 Jul 00:20 +0200
(address . daniel.szmulewicz@gmail.com)(address . 72333@debbugs.gnu.org)
cd8fe8de-57c3-4da5-9aa3-88241dc7ce99@gmail.com
Hi Daniel,

> Running M-x magit-branch generates the following error:
> transient-setup: Symbol’s function definition is void:
> transient-prefix-object
>
> In order to reproduce:
>
> guix shell emacs emacs-magit -- emacs -Q
>
> M-x magit-version
> Magit 3.3.0-8.538cb2f, Transient 0.7.3, Git 2.45.2, Emacs 29.4, gnu/linux

It looks like this is because emacs is actually using the built-in (older)
version of transient, while magit relies on a function from a newer version.

Evaluating the following definition from the newer transient source code
fixes
this particular issue for me (I've put it in my init.el for the time being):

#+begin_src lisp
  (defun transient-prefix-object ()
    (or transient--prefix transient-current-prefix))
#+end_src

This sounds similar to another issue with embark and org [1], however in
that report it
was because emacs-org was not included in the environment; in this case, the
newer version of transient is already an input of magit in the guix
package, so
I'm not sure what's happening here.


Cheers,

aurtzy
G
G
gemmaro wrote on 31 Jul 14:04 +0200
[PATCH] gnu: emacs-transient: Prioritise loading over built-in.
(address . 72333@debbugs.gnu.org)(name . gemmaro)(address . gemmaro.dev@gmail.com)
d147012fc8d18eef3e3b73b3a2ab802b94ad5f71.1722427477.git.gemmaro.dev@gmail.com
* gnu/packages/emacs-xyz.scm (emacs-transient)[arguments]<#:emacs>:
Use the full emacs package.

Change-Id: Id6277f365ae0a780469658818872b7277de20135
---
Hello,

I hope this fixes the problem.

I found out the followings:
* Native compiled files (.eln) might be loaded first.
* The built-in Transient has an eln version and lacks transient-prefix-object.
* Using the full emacs generates the eln and now it is prioritised.

Best,
gemamro.

gnu/packages/emacs-xyz.scm | 3 +++
1 file changed, 3 insertions(+)

Toggle diff (18 lines)
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index d4e60d0d5e..17d58996ce 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -32056,6 +32056,9 @@ (define-public emacs-transient
(build-system emacs-build-system)
(arguments
`(#:tests? #f ;no test suite
+ ;; Native compile if available to make it preferable to the build-in
+ ;; Transient. See <https://issues.guix.gnu.org/72333>.
+ #:emacs ,emacs
#:phases (modify-phases %standard-phases
(add-after 'unpack 'build-info-manual
(lambda _

base-commit: 01d4363168ed10ea223047f7a7b83201f161ec0b
--
2.45.2
R
R
Richard Sent wrote on 31 Jul 18:52 +0200
Re: bug#72333: Magit/Transient error message
(address . 72333@debbugs.gnu.org)
43AD488C-91C5-4A18-92AB-93B26C950477@freakingpenguin.com
On July 30, 2024 6:50:12 PM EDT, aurtzy <aurtzy@gmail.com> wrote:
Toggle quote (40 lines)
>Hi Daniel,
>
>> Running M-x magit-branch generates the following error:
>>
>> transient-setup: Symbol’s function definition is void:
>> transient-prefix-object
>>
>> In order to reproduce:
>>
>> guix shell emacs emacs-magit -- emacs -Q
>>
>> M-x magit-version
>> Magit 3.3.0-8.538cb2f, Transient 0.7.3, Git 2.45.2, Emacs 29.4, gnu/linux
>
>It looks like this is because emacs is actually using the built-in (older)
>version of transient, while magit relies on a function from a newer version.
>
>Evaluating the following definition from the newer transient source code fixes
>this particular issue for me (I've put it in my init.el for the time being):
>
>#+begin_src lisp
>  (defun transient-prefix-object ()
>    (or transient--prefix transient-current-prefix))
>#+end_src
>
>This sounds similar to another issue with embark and org [1], however in that
>report it was because emacs-org was not included in the environment; in this
>case, the newer version of transient is already an input of magit in the guix
>package, so I'm not sure what's happening here.
>
>[1] https://github.com/oantolin/embark/issues/723
>
>Cheers,
>
>aurtzy
>
>
>
>

I encountered a similar issue to this (void-function transient--suffix-only) when I enabled the following block of code:

#+begin_src lisp
;; FIXME: This caused (void-function transient--suffix-only) errors
;; in Guix c9cd16c630ccba655b93ff32fd9a99570b4f5373 with magit.
;;
;; (setq read-extended-command-predicate
;; #'command-completion-default-include-p)
#+end_src

I'm also not sure of the underlying cause, but something seems funky with Magit.
L
L
Liliana Marie Prikler wrote on 31 Jul 19:10 +0200
Re: bug#72333: [PATCH] gnu: emacs-transient: Prioritise loading over built-in.
2b9d6faf689d9f5677387d29ff70f2bfdd1c1e04.camel@gmail.com
Am Mittwoch, dem 31.07.2024 um 21:04 +0900 schrieb gemmaro:
Toggle quote (14 lines)
> * gnu/packages/emacs-xyz.scm (emacs-transient)[arguments]<#:emacs>:
> Use the full emacs package.
>
> Change-Id: Id6277f365ae0a780469658818872b7277de20135
> ---
> Hello,
>
> I hope this fixes the problem.
>
> I found out the followings:
> * Native compiled files (.eln) might be loaded first.
> * The built-in Transient has an eln version and lacks transient-
> prefix-object.
> * Using the full emacs generates the eln and now it is prioritised.
This won't work if you use any other Emacs (e.g. emacs-pgtk).

Try for example: 
guix shell emacs-magit emacs-pgtk \
--with-input=emacs-minimal=emacs --pure -- emacs

One workaround would be to check the symbol in magit and other packages
that rely on this symbol, but I hazard a guess that there's a reason
why they require the newer magit.

The other (recommended at the moment) would be to use the proper
transformation to natively compile your emacs packages.

We could also, for the time being, offer an Emacs without native
compilation – YMMV on how well liked that'd be.

The proper fix would be to build Emacs packages for the various
variants directly with emacs-build-system. I have an as-of-yet
incomplete patch set to do exactly that.

Cheers
T
T
Tomas Volf wrote on 17 Aug 11:26 +0200
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
ZsBswZLxykKmgsno@ws
On 2024-07-31 19:10:03 +0200, Liliana Marie Prikler wrote:
Toggle quote (3 lines)
> The other (recommended at the moment) would be to use the proper
> transformation to natively compile your emacs packages.

So just to make sure I understand correctly what is the correct work around
here. Let us assume I install emacs and emacs-magit into my home environment.
So until now I have (leaving everything else out) this:

(home-environment
(packages (list emacs emacs-magit <more-here>)))

Assuming I want to follow the recommendation above, I should turn it into
something like this:

(home-environment
(packages (map (package-input-rewriting `((,emacs-minimal . ,emacs)))
(list emacs emacs-magit <more-here>))))

Did I get it right? Are there any downsides to doing this (except compute)?

Have a nice day,
Tomas

Side note: I am surprised how long emacs-yaml takes to build on my ~5.5 GHz
build machine. I compile whole of firefox faster.

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmbAbMEACgkQL7/ufbZ/
wan1Ug/+KdM7B0JCxMZ+mJfscGZq664KwIGwqdo9drmbMS4Ap9xP3vUPssyY/bLp
Z/9DzaVnyTPNf6nS7aC0WwngoiTZqsXPdV9SASom4pjnSaGqWnrOGQoIegt8ewXy
31UtMYj33a1WFSOiUd6FOQuB12DIOTstfCei85VhbxlAxQyp5Fikqvwco+kZTtBH
BxyFNrjyaqb53q0nDBL+qoPf3XDyhI56hbvw8+oPQJb9a06mT21nki+9HmDjSaKu
pVzYZktAV+ulFAVzItn/BKC1JN38Ec2Z1Ss+VasJ+A8EBwlMGmmHbr2a0+Ca5NBi
EEMC84o5n9XRqC9nae1ZBq+XVHb7UnnJL7za4aOS4P7HJUPBygjBL+zF3Uc5QqSE
twNDrd8zGCzIbjVUiROQrm2u7xFMaiaNgi22YJ3k5bcb5TarnAnGqWOti5QDnpwu
nggxMFYB4OpSxD4LUz80ysirZmQkG3Tjc6g60qpmMHEqi7dR2s5ymFf/T9DMIefP
2BGJbr+sX2gadFf0RUpUYVf7NR4VNCXIw2yFAxWEKW2gGo0HeXprBktY0zlCObUn
BPFv0H9GeeU34DGRaTjZwAh4F+nUmOF50bv1KChjZmNaMFG2NXAxeFwbmBMDlUPs
ctfYxnfP0FFUiE0aMoydUIQASOlFNt4yGzHBJ7L3JvP1Fw0bv+Q=
=2fjl
-----END PGP SIGNATURE-----


L
L
Liliana Marie Prikler wrote on 17 Aug 13:21 +0200
(name . Tomas Volf)(address . ~@wolfsden.cz)
a4c3b4c4048b229019c2910148355b07f06c03ee.camel@gmail.com
Am Samstag, dem 17.08.2024 um 11:26 +0200 schrieb Tomas Volf:
Toggle quote (22 lines)
> On 2024-07-31 19:10:03 +0200, Liliana Marie Prikler wrote:
> > The other (recommended at the moment) would be to use the proper
> > transformation to natively compile your emacs packages.
>
> So just to make sure I understand correctly what is the correct work
> around here.  Let us assume I install emacs and emacs-magit into my
> home environment. So until now I have (leaving everything else out)
> this:
>
>     (home-environment
>      (packages (list emacs emacs-magit <more-here>)))
>
> Assuming I want to follow the recommendation above, I should turn it
> into something like this:
>
>     (home-environment
>      (packages (map (package-input-rewriting `((,emacs-minimal .
> ,emacs)))
>                     (list emacs emacs-magit <more-here>))))
>
> Did I get it right?  Are there any downsides to doing this (except
> compute)?
Yep, that's the low-level way of achieving this (more or less – emacs-
minimal isn't always the only package to replace). On a higher level,
you can bind (package-input-rewriting …) to a name and use that. I
personally prefer the (options->transformation …)¹ variant, though,
which is nearly identical and compiles to this.

Cheers

Toggle quote (2 lines)
> Side note: I am surprised how long emacs-yaml takes to build on my
> ~5.5 GHz build machine.  I compile whole of firefox faster.
That sounds concerning. We might want to look into individual bugs
such as this.

¹ the argument is '((with-input . "emacs-minimal=<your-emacs>")),
which imho, reads nicer. <your-emacs> could be emacs, emacs-pgtk,
etc.
S
S
Simon Tournier wrote on 30 Aug 18:33 +0200
Re: bug#72333: Magit/Transient error message
87ikvias2d.fsf@gmail.com
Hi,

On Sun, 28 Jul 2024 at 15:41, daniel szmulewicz <daniel.szmulewicz@gmail.com> wrote:
Toggle quote (12 lines)
> Running M-x magit-branch generates the following error:
>
> transient-setup: Symbol’s function definition is void:
> transient-prefix-object
>
> In order to reproduce:
>
> guix shell emacs emacs-magit -- emacs -Q
>
> M-x magit-version
> Magit 3.3.0-8.538cb2f, Transient 0.7.3, Git 2.45.2, Emacs 29.4, gnu/linux

Well, that’s annoying. Using Guix revision d531237 (CommitDate: Thu Aug
29), I also get this error about Transient and thus it makes Magit
hardly usable with local fixes.

This issue is that emacs-magit does not use the package emacs-transient
but the built-in transient. I mean it fails similarly when removing
emacs-transient from the list of propagated-inputs.

Why is emacs-transient not loaded?

Toggle snippet (20 lines)
$ ag --elisp 'defvar transient--buffer' $(./pre-inst-env guix build -S emacs-transient)
/gnu/store/jhbk7wzs9lh7myav6czyxx4i2wgyw3vl-emacs-transient-0.7.4-checkout/lisp/transient.el
1547:(defvar transient--buffer-name " *transient*"
1550:(defvar transient--buffer nil

$ ./pre-inst-env guix shell -C -E TERM emacs emacs-transient \
-- emacs --batch --eval "(progn (require 'transient) (print transient--buffer))"

Error: void-variable (transient--buffer)
mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode 0x1a5b59c931aef3ca>))
debug-early-backtrace()
debug-early(error (void-variable transient--buffer))
(print transient--buffer)
(progn (require 'transient) (print transient--buffer))
command-line-1(("--eval" "(progn (require 'transient) (print transient--buffer))"))
command-line()
normal-top-level()
Symbol's value as variable is void: transient--buffer

And built-in transient is used instead?

Toggle snippet (7 lines)
$ ./pre-inst-env guix shell -C -E TERM emacs emacs-transient \
-- emacs --batch --eval "(progn (require 'transient) (print transient--buffer-name))"

" *transient*"


Please note it works as expected with say Org:

Toggle snippet (12 lines)
$ ./pre-inst-env guix shell -C -E TERM emacs \
-- emacs --batch --eval "(print (org-version)))"

"9.6.15"

$ ./pre-inst-env guix shell -C -E TERM emacs emacs-org \
-- emacs --batch --eval "(print (org-version)))"

"9.7.10"


Cheers,
simon
S
S
Simon Tournier wrote on 2 Sep 20:55 +0200
Re: bug#72333: builtin native-compiled is loaded instead of emacs-packages
87y149q418.fsf@gmail.com
Hi,

Alvin Hsu

Once bisecting, the first occurrence appears with:

7a2fc32ba2cec79b087932f30d77751f9133d740
CommitDate: Sun Jul 21 13:32:27 2024 +0200
Parent: bb1aea46e6 gnu: emacs-gnosis: Update to 0.3.2.

gnu: emacs-magit: Update to 3.3.0-8.538cb2f

* gnu/packages/emacs-xyz.scm (emacs-magit): Update to 3.3.0-8.538cb2f.

A.o. it contains the fix for https://github.com/magit/magit/issues/4940which is a showstopper.

Change-Id: Id83a237d38c03a97f9f1043db4b8ba594521a2f7


This update of emacs-magit depends on transient-prefix-object, i.e., it
depends on a new version of transient.

Toggle snippet (17 lines)
$ ag transient-prefix-object \
$(guix time-machine -q --commit=7a2fc32ba2cec79b087932f30d77751f9133d740 -- build emacs-magit -S)
/gnu/store/fgcz4a4adhnrcxa541kdkn30f0hgn6c5-emacs-magit-3.3.0-8.538cb2f-checkout/lisp/magit-branch.el
213: (oref (transient-prefix-object) scope)))
217: (propertize (oref (transient-prefix-object) scope)
866: (propertize (oref (transient-prefix-object) scope)
910: (when-let* ((branch (oref (transient-prefix-object) scope))
918: (magit-read-upstream-branch (oref (transient-prefix-object) scope)
922: (magit-set-upstream-branch (oref (transient-prefix-object) scope) refname)
924: (and-let* ((branch (oref (transient-prefix-object) scope))
931: (let ((branch (oref (transient-prefix-object) scope)))

/gnu/store/fgcz4a4adhnrcxa541kdkn30f0hgn6c5-emacs-magit-3.3.0-8.538cb2f-checkout/lisp/magit-remote.el
73: (oref (transient-prefix-object) scope)))
318: (propertize (oref (transient-prefix-object) scope)

When the commit parent does not:

$ ag transient-prefix-object \
$(guix time-machine -q --commit=bb1aea46e6 -- build emacs-magit -S)


However, it should be an issue since emacs-transient is correctly
updated and correctly contains the requirements.

Toggle snippet (11 lines)
$ ag transient-prefix-object \
$(guix time-machine -q --commit=bb1aea46e6 -- build emacs-transient)
/gnu/store/8zwwwprv93shxjjfcc4a406gs9qgk58i-emacs-transient-0.7.2/share/emacs/site-lisp/transient-0.7.2/transient.el
1605:(defun transient-prefix-object ()
3044: (format "levels > %s" (oref (transient-prefix-object) level))
3058: (transient-set-value (transient-prefix-object)))
3066: (transient-save-value (transient-prefix-object)))
3074: (transient-reset-value (transient-prefix-object)))
3607: (oref (transient-prefix-object) scope))

Therefore, the issue…

On Fri, 30 Aug 2024 at 18:33, Simon Tournier <zimon.toutoune@gmail.com> wrote:

Toggle quote (2 lines)
> Why is emacs-transient not loaded?

…is something about loading Emacs Lisp code.

Toggle snippet (16 lines)
$ guix time-machine -q --commit=bb1aea46e6 \
-- shell emacs emacs-transient \
-- emacs --batch --eval "(progn (require 'transient) (transient-prefix-object) (print \"done\"))"
Error: void-function (transient-prefix-object)
mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode 0x5d8e1c931aef1bf>))
debug-early-backtrace()
debug-early(error (void-function transient-prefix-object))
(transient-prefix-object)
(progn (require 'transient) (transient-prefix-object) (print "done"))
command-line-1(("--eval" "(progn (require 'transient) (transient-prefix-object) (print \"done\"))"))
command-line()
normal-top-level()
Symbol’s function definition is void: transient-prefix-object

Compared to:

Toggle snippet (9 lines)
$ guix time-machine -q --commit=bb1aea46e6 \
-- shell emacs emacs-transient \
-- emacs --batch --eval "(progn (load (locate-library \"transient\")) (transient-prefix-object) (print \"done\"))"

Loading /gnu/store/8zwwwprv93shxjjfcc4a406gs9qgk58i-emacs-transient-0.7.2/share/emacs/site-lisp/transient-0.7.2/transient.elc...

"done"

Now, if native compilation is not able to find .eln files then all work
as expected.

Toggle snippet (8 lines)
$ guix time-machine -q --commit=bb1aea46e6 \
-- shell emacs emacs-transient \
-- emacs --batch --eval "(progn (setq native-comp-eln-load-path nil) (require 'transient) (transient-prefix-object) (print \"done\"))"
"done"


Other said, the bug is not about Magit or Transient but the bug is about
all native-compiled Emacs Lisp code that are part of builtin Emacs:
these are loaded and not the ones from packages if provided.

About the example of Org-mode, I guess ’org-version’ is not marked for
the compilation and that’s why it works in appearances.


Well, maybe that’s a bug known upstream (I have not checked) and maybe
this behaviour has already been reported for Guix. In both cases,
that’s annoying because it means that emacs-packages are useless as
dependencies since builtin is always used instead.

Somehow, one solution would to not provide native-compilation of source
code that is developed outside the Emacs tree (transient, Magit, etc.)
and let user locally native-compile them.

Or another solution would to split ’native-comp-eln-load-path’. Say one
folder for builtin code that we know is developed outside Emacs tree,
e.g., transient, Org, etc. And append them in EMACSNATIVELOADPATH by
default. When a known package is provided by the user, the builtin path
is removed from EMACSNATIVELOADPATH (and the package path could be added
if emacs-build-system native-compile them).


Cheers,
simon
S
S
Simon Tournier wrote on 2 Sep 21:00 +0200
CAJ3okZ2Gj5gJSLdGfjCazUu-bxwRZp65VfuGwWu9KykT-iiucg@mail.gmail.com
Oups, missing some edits, as usual. :-)

Toggle quote (3 lines)
> However, it should be an issue since emacs-transient is correctly
> updated and correctly contains the requirements.

it should *NOT* be an issue
L
L
Liliana Marie Prikler wrote on 2 Sep 21:22 +0200
82d48037563e5cdc51d038216538c7a03f54e786.camel@gmail.com
Hi Simon

Am Montag, dem 02.09.2024 um 20:55 +0200 schrieb Simon Tournier:
Toggle quote (5 lines)
> […]
> Well, maybe that’s a bug known upstream (I have not checked) and
> maybe this behaviour has already been reported for Guix.  In both
> cases, that’s annoying because it means that emacs-packages are
> useless as dependencies since builtin is always used instead.
It is a bug unique to our handling in Guix – upstream uses hashes to
guard against it, but those break grafts. In any case, builtin
packages are only used instead if the dependency isn't natively
compiled with a compatible Emacs (sadly the current default!) – I've
started a WIP series at [1], but we're still looking for solutions that
scale better in terms of what we need to declare for our packages (and
CI integration).

Toggle quote (3 lines)
> Somehow, one solution would to not provide native-compilation of
> source code that is developed outside the Emacs tree (transient,
> Magit, etc.) and let user locally native-compile them.
I'm not sure that'd work. Even if you byte-compile that code, you are
still loading the natively-compiled stuff from the Emacs tree. You
could disable native compilation for the Emacs package itself, but
that'd kinda defeat the purpose of bundling these things with Emacs
(which tbf is an upstream thing).

Toggle quote (7 lines)
> Or another solution would to split ’native-comp-eln-load-path’.  Say
> one folder for builtin code that we know is developed outside Emacs
> tree, e.g., transient, Org, etc. And append them in
> EMACSNATIVELOADPATH by default.  When a known package is provided by
> the user, the builtin path is removed from EMACSNATIVELOADPATH (and
> the package path could be added if emacs-build-system native-compile
> them).
This already happens. The bug is not that built-in stuff is found
prior to non-builtin stuff, it's that it is found *at all*. Since we
don't do native compilation for packages at the moment, most folks only
get Emacs itself natively compiled.

Cheers

S
S
Simon Tournier wrote on 3 Sep 16:57 +0200
[PATCH] gnu: emacs-minimal: Do not native-compile lisp/transient.el.
(address . 72333@debbugs.gnu.org)(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
fae9eb4815d3d4867a2cc48795bd30f0ec4b84c7.1725374463.git.zimon.toutoune@gmail.com
Reported by daniel szmulewicz <daniel.szmulewicz@gmail.com>.

* gnu/packages/emacs.scm (emacs-minimal)[arguments]<phases>: Turn off
native-compilation for the file lisp/transient.el.

Change-Id: I27c9d660cbad46be66df641816e4596346969dfc
---
gnu/packages/emacs.scm | 10 ++++++++++
1 file changed, 10 insertions(+)

Toggle diff (25 lines)
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index f1ea4fe061..c555ca09f7 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -233,6 +233,16 @@ (define-public emacs-minimal
(("\\(tramp-compat-process-running-p \"(.*)\"\\)" all process)
(format #f "(or ~a (tramp-compat-process-running-p ~s))"
all (string-append "." process "-real"))))))
+ (add-after 'unpack 'do-not-native-compile
+ (lambda _
+ ;; Fixes <https://issues.guix.gnu.org/72333>. Temporary
+ ;; workaround for native-compilation bug of transient.el.
+ ;; Please remove once the native-compilation for Emacs packages
+ ;; is fully supported.
+ (substitute* "lisp/transient.el"
+ ((";; End:")
+ ";; no-native-compile: t
+;; End:"))))
(add-before 'configure 'fix-/bin/pwd
(lambda _
;; Use `pwd', not `/bin/pwd'.

base-commit: 1569b861f504178263b73b4b48563bf3937d01bf
--
2.41.0
S
S
Simon Tournier wrote on 3 Sep 17:05 +0200
Re: bug#72333: builtin native-compiled is loaded instead of emacs-packages
875xrcu69c.fsf@gmail.com
Hi Liliana,

On Mon, 02 Sep 2024 at 21:22, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Toggle quote (2 lines)
> It is a bug unique to our handling in Guix

Well, waiting a proper fix and a better story for Emacs package native
compilation, I propose to turn off the native-compilation for
lisp/transient.el only; see [1]. This fixes the bug at hand so it
removes the annoyance with a broken Magit.

And it lets the time to discuss a better long-term solution.


Cheers,
simon
L
L
Liliana Marie Prikler wrote on 3 Sep 18:49 +0200
Re: bug#72333: [PATCH] gnu: emacs-minimal: Do not native-compile lisp/transient.el.
9c3737160558822cb90fabe516d78ed82853f4ca.camel@gmail.com
Am Dienstag, dem 03.09.2024 um 16:57 +0200 schrieb Simon Tournier:
Toggle quote (2 lines)
> Reported by daniel szmulewicz <daniel.szmulewicz@gmail.com>.
I think those belong in the trailer, but I can fix that myself.

Toggle quote (32 lines)
> * gnu/packages/emacs.scm (emacs-minimal)[arguments]<phases>: Turn off
> native-compilation for the file lisp/transient.el.
>
> Change-Id: I27c9d660cbad46be66df641816e4596346969dfc
> ---
>  gnu/packages/emacs.scm | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index f1ea4fe061..c555ca09f7 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -233,6 +233,16 @@ (define-public emacs-minimal
>                  (("\\(tramp-compat-process-running-p \"(.*)\"\\)"
> all process)
>                   (format #f "(or ~a (tramp-compat-process-running-p
> ~s))"
>                           all (string-append "." process "-
> real"))))))
> +          (add-after 'unpack 'do-not-native-compile
> +            (lambda _
> +              ;; Fixes <https://issues.guix.gnu.org/72333>. 
> Temporary
> +              ;; workaround for native-compilation bug of
> transient.el.
> +              ;; Please remove once the native-compilation for Emacs
> packages
> +              ;; is fully supported.
> +              (substitute* "lisp/transient.el"
> +                ((";; End:")
> +                 ";; no-native-compile: t
> +;; End:"))))
Should we do this in a snippet instead? Otherwise LGTM.

Cheers
L
L
Liliana Marie Prikler wrote on 3 Sep 21:47 +0200
c6aaaa11775b1b995bebbd0fe408c173be385594.camel@gmail.com
Am Dienstag, dem 03.09.2024 um 18:49 +0200 schrieb Liliana Marie
Prikler:
Toggle quote (4 lines)
> Am Dienstag, dem 03.09.2024 um 16:57 +0200 schrieb Simon Tournier:
> > Fixes <https://issues.guix.gnu.org/72333>.
> > Reported by daniel szmulewicz <daniel.szmulewicz@gmail.com>.
> I think those belong in the trailer, but I can fix that myself.
Pushed with the mentioned fixes.

Toggle quote (2 lines)
> > […]
> Should we do this in a snippet instead?  Otherwise LGTM.
I left it as a phase, so that Emacsen with modified source also
benefit.

Cheers
Closed
S
S
Simon Tournier wrote on 3 Sep 23:00 +0200
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
CAJ3okZ3Egv24-_LD2ri6PN7FhF1sZXMeEUacs0XSdD=7TOcKPA@mail.gmail.com
On Tue, 3 Sept 2024 at 21:47, Liliana Marie Prikler
<liliana.prikler@gmail.com> wrote:

Toggle quote (5 lines)
> > Should we do this in a snippet instead? Otherwise LGTM.
>
> I left it as a phase, so that Emacsen with modified source also
> benefit.

I think it's better as a phase because of what you wrote and also
because "guix build -S emacs" returns a non (or less) Guix specific
source.

Thanks for quick review and push. Now it's free my mind and I am
fully able to enjoy Magit v4.0. ;-)

Cheers,
simon
Closed
R
R
Rutherther wrote on 14 Sep 19:53 +0200
Re: Magit/Transient error message
(address . 72333@debbugs.gnu.org)
87tteidsuv.fsf@protonmail.com
From Liliana dmarie Prikler:
Toggle quote (3 lines)
> It is a bug unique to our handling in Guix – upstream uses hashes to
> guard against it, but those break grafts.

Do we need to remove the whole hash? The path hash would definitely
break grafts, but why should the content hash break grafts? Having the
content hash would also solve this issue.

Here is the upstream explanation for the hash
having two parts, path and content hash.

Regards,
Rutherther
L
L
Liliana Marie Prikler wrote on 14 Sep 21:12 +0200
fadfabf2734bfa9b1edb04ec68dc949c9985203a.camel@gmail.com
Am Samstag, dem 14.09.2024 um 17:53 +0000 schrieb Rutherther:
Toggle quote (12 lines)
>
> From Liliana dmarie Prikler:
> > It is a bug unique to our handling in Guix – upstream uses hashes
> > to guard against it, but those break grafts.
>
> Do we need to remove the whole hash? The path hash would definitely
> break grafts, but why should the content hash break grafts? Having
> the content hash would also solve this issue.
>
> Here is the upstream explanation for the hash
> https://git.savannah.gnu.org/cgit/emacs.git/tree/src/comp.c?h=194a8f5c1406dd7e762376bdfde78d1b7d01b6b1#n4433
> having two parts, path and content hash.
Because the content hash also refers to stuff that we're grafting, e.g.
program names that get compiled to store paths. It's sadly not that
easy.

Cheers
?
Your comment

This issue is archived.

To comment on this conversation send an email to 72333@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 72333
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch