GNU bug report logs - #47458
Terrible UX upgrading Emacs in Guix

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47458 in the body.
You can then email your comments to 47458 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: bug-guix <at> gnu.org
Subject: Terrible UX upgrading Emacs in Guix
Date: Sun, 28 Mar 2021 22:02:20 -0400

I just updated my Guix system, which included the Emacs update from 27.1
to 27.2.  After "guix package -m mhw-manifest.scm" finished running
(which takes a long time for me, since I don't use substitutes), and
before I even noticed that it had finished, my existing Emacs session
started misbehaving badly.

It failed to even open a plain text file in fundamental mode (a .drv
file) with an inscrutible error about 'arrayp'.  I tried to enable the
debugger with M-x toggle-debug-on-error, but then I started getting
errors about 'debug' not found.  (I neglected to record the exact
messages).

I tried running "emacs -Q", and the same errors happened there too.  I
tried running "emacs -Q" from my root shell on a Linux text terminal,
and the same errors happened there.

I resorted to using 'vi' (which thankfully I had, and still remember how
to use for basic editing) to revert the emacs update on my private
branch and to rebuild my user profiles.

Eventually, I realized what the problem was:

(1) My existing emacs session started failing because
    ~/.guix-profile/share/emacs/27.1 had disappeared out from under it.

(2) My newly launched emacs sessions were failing because my
    EMACSLOADPATH variable was still set to its old value, pointing at
    /home/mhw/.guix-profile/share/emacs/27.1/lisp, which no longer
    existed.

I'm not sure why I've never run into this problem before.  I'm also not
sure what can be done to make this better, but if anyone has ideas, that
would be good.  If a 7+ year Guix veteran developer gets bitten badly by
this, I doubt that less experienced users will be impressed.

Any ideas?

       Mark

Message #8 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Mark H Weaver <mhw <at> netris.org>, 47458 <at> debbugs.gnu.org
Subject: Re: Terrible UX upgrading Emacs in Guix
Date: Mon, 29 Mar 2021 10:07:51 +0200

Am Sonntag, den 28.03.2021, 22:02 -0400 schrieb Mark H Weaver:
> I just updated my Guix system, which included the Emacs update from
> 27.1
> to 27.2.  After "guix package -m mhw-manifest.scm" finished running
> (which takes a long time for me, since I don't use substitutes), and
> before I even noticed that it had finished, my existing Emacs session
> started misbehaving badly.
> 
> It failed to even open a plain text file in fundamental mode (a .drv
> file) with an inscrutible error about 'arrayp'.  I tried to enable
> the
> debugger with M-x toggle-debug-on-error, but then I started getting
> errors about 'debug' not found.  (I neglected to record the exact
> messages).
As you are probably aware by now, this is a result of parts of your
EMACSLOADPATH being deleted.  I don't think there's a good solution to
this, but you could (as part of your early init file) resolve the
symlinks in it, so that it behaves deterministically until it is
garbage collected?

> [...]
> 
> Eventually, I realized what the problem was:
> 
> (1) My existing emacs session started failing because
>     ~/.guix-profile/share/emacs/27.1 had disappeared out from under
> it.
> 
> (2) My newly launched emacs sessions were failing because my
>     EMACSLOADPATH variable was still set to its old value, pointing
> at
>     /home/mhw/.guix-profile/share/emacs/27.1/lisp, which no longer
>     existed.
> 
> I'm not sure why I've never run into this problem before.  I'm also
> not
> sure what can be done to make this better, but if anyone has ideas,
> that
> would be good.  If a 7+ year Guix veteran developer gets bitten badly
> by
> this, I doubt that less experienced users will be impressed.
Remember the snippet, that tells you you might want to recompute your
environment variables at the end of `guix package'?  Well, this is just
that.  I've already made it a habit to close Emacs at that point (and
you probably have as well), but as you said, you didn't even notice the
update succeed, so that's what lead to the confusion.

In a similar manner, if I see an Emacs version upgrade at the start of
the transaction, I already know to prepare for a little environment
variable dance to get it to start correctly.  I think there has been an
idea to update environment variables in GNOME Shell directly, for
instance, but
a. we're lacking the technology to do so at the moment (e.g. guile-
dbus)
b. it's not clear, that Guix itself should do such a thing rather than
relying on the user to e.g. code up a oneshot shepherd service 

Regards,
Leo

Message #11 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, Mark H Weaver
 <mhw <at> netris.org>,  47458 <at> debbugs.gnu.org
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Mon, 29 Mar 2021 10:24:01 +0200

[Message part 1 (text/plain, inline)]

On Mon, 2021-03-29 at 10:07 +0200, Leo Prikler wrote:
> [...]
> 
> In a similar manner, if I see an Emacs version upgrade at the start of
> the transaction, I already know to prepare for a little environment
> variable dance to get it to start correctly.  I think there has been an
> idea to update environment variables in GNOME Shell directly, for
> instance, but
> a. we're lacking the technology to do so at the moment (e.g. guile-
> dbus)

Actually, we do have dbus bindings for guile (actually, a reimplementation
of dbus in (Guile) Scheme): guile-ac-d-bus.  It doesn't support file descriptor
passing (at least on Guile, other Schemes may differ) though, but that's
probably not required for this.

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Maxime Devos <maximedevos <at> telenet.be>, Mark H Weaver <mhw <at> netris.org>, 
 47458 <at> debbugs.gnu.org
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Mon, 29 Mar 2021 10:43:22 +0200

Am Montag, den 29.03.2021, 10:24 +0200 schrieb Maxime Devos:
> On Mon, 2021-03-29 at 10:07 +0200, Leo Prikler wrote:
> > [...]
> > 
> > In a similar manner, if I see an Emacs version upgrade at the start
> > of
> > the transaction, I already know to prepare for a little environment
> > variable dance to get it to start correctly.  I think there has
> > been an
> > idea to update environment variables in GNOME Shell directly, for
> > instance, but
> > a. we're lacking the technology to do so at the moment (e.g. guile-
> > dbus)
> 
> Actually, we do have dbus bindings for guile (actually, a
> reimplementation
> of dbus in (Guile) Scheme): guile-ac-d-bus.  It doesn't support file
> descriptor
> passing (at least on Guile, other Schemes may differ) though, but
> that's
> probably not required for this.
Thanks for pointing this out!  Now I can finally write Guile code to
update all those environment variables.  (Hopefully this lets us do
polkit in Guix as well.)

Message #17 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 47458 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 45359 <at> debbugs.gnu.org
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Mon, 29 Mar 2021 17:55:02 +0200

Hi Mark,

Mark H Weaver <mhw <at> netris.org> skribis:

> Eventually, I realized what the problem was:
>
> (1) My existing emacs session started failing because
>     ~/.guix-profile/share/emacs/27.1 had disappeared out from under it.
>
> (2) My newly launched emacs sessions were failing because my
>     EMACSLOADPATH variable was still set to its old value, pointing at
>     /home/mhw/.guix-profile/share/emacs/27.1/lisp, which no longer
>     existed.
>
> I'm not sure why I've never run into this problem before.  I'm also not
> sure what can be done to make this better, but if anyone has ideas, that
> would be good.  If a 7+ year Guix veteran developer gets bitten badly by
> this, I doubt that less experienced users will be impressed.

Ouch.  “It used to be” (speaking like a veteran :-)) that Emacs in Guix
would not use EMACSLOADPATH.  Then we switched to EMACSLOADPATH, which
had some advantages, but necessarily has this drawback.

IIUC, <https://issues.guix.gnu.org/45359> is about possibly
backtracking.  Maxim, what’s the status of this one?

Thanks,
Ludo’.

Message #20 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 47458 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 45359 <at> debbugs.gnu.org
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Mon, 29 Mar 2021 17:55:30 +0200

Hi Mark,

Mark H Weaver <mhw <at> netris.org> skribis:

> Eventually, I realized what the problem was:
>
> (1) My existing emacs session started failing because
>     ~/.guix-profile/share/emacs/27.1 had disappeared out from under it.
>
> (2) My newly launched emacs sessions were failing because my
>     EMACSLOADPATH variable was still set to its old value, pointing at
>     /home/mhw/.guix-profile/share/emacs/27.1/lisp, which no longer
>     existed.
>
> I'm not sure why I've never run into this problem before.  I'm also not
> sure what can be done to make this better, but if anyone has ideas, that
> would be good.  If a 7+ year Guix veteran developer gets bitten badly by
> this, I doubt that less experienced users will be impressed.

Ouch.  “It used to be” (speaking like a veteran :-)) that Emacs in Guix
would not use EMACSLOADPATH.  Then we switched to EMACSLOADPATH, which
had some advantages, but necessarily has this drawback.

IIUC, <https://issues.guix.gnu.org/45359> is about possibly
backtracking.  Maxim, what’s the status of this one?

Thanks,
Ludo’.

Message #23 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mark H Weaver <mhw <at> netris.org>, 45359-done <at> debbugs.gnu.org,
 47458 <at> debbugs.gnu.org
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Mon, 29 Mar 2021 14:25:52 -0400

Hi,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi Mark,
>
> Mark H Weaver <mhw <at> netris.org> skribis:
>
>> Eventually, I realized what the problem was:
>>
>> (1) My existing emacs session started failing because
>>     ~/.guix-profile/share/emacs/27.1 had disappeared out from under it.
>>
>> (2) My newly launched emacs sessions were failing because my
>>     EMACSLOADPATH variable was still set to its old value, pointing at
>>     /home/mhw/.guix-profile/share/emacs/27.1/lisp, which no longer
>>     existed.
>>
>> I'm not sure why I've never run into this problem before.  I'm also not
>> sure what can be done to make this better, but if anyone has ideas, that
>> would be good.  If a 7+ year Guix veteran developer gets bitten badly by
>> this, I doubt that less experienced users will be impressed.
>
> Ouch.  “It used to be” (speaking like a veteran :-)) that Emacs in Guix
> would not use EMACSLOADPATH.  Then we switched to EMACSLOADPATH, which
> had some advantages, but necessarily has this drawback.
>
> IIUC, <https://issues.guix.gnu.org/45359> is about possibly
> backtracking.  Maxim, what’s the status of this one?

It's abandoned, The MUMI tracker lacks the responses from Leo Prickler,
but they had good arguments maintaining the status quo rather than going
with the extra complexity.  It also wouldn't change the issue at hand;
it'd merely prevent conflicts of *resources* files of Emacs packages
(and somewhat integrate with the Emacs native package manager, while
making the autoloading a bit slower).  It seems the price to pay is too
high for such a small gain.  I'm closing it now.

On the other hand, this very problem was the motivation for this patch
series here: https://issues.guix.gnu.org/43627, which would solve the
issue ta hand.  You were skeptical of the benefits the last time you
took a look at it; perhaps it's time to take a new look at it :-).

Thanks,

Maxim

Message #26 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Mark H Weaver <mhw <at> netris.org>, 45359-done <at> debbugs.gnu.org,
 47458 <at> debbugs.gnu.org
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Tue, 30 Mar 2021 10:04:23 +0200

Hello,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

>> Ouch.  “It used to be” (speaking like a veteran :-)) that Emacs in Guix
>> would not use EMACSLOADPATH.  Then we switched to EMACSLOADPATH, which
>> had some advantages, but necessarily has this drawback.
>>
>> IIUC, <https://issues.guix.gnu.org/45359> is about possibly
>> backtracking.  Maxim, what’s the status of this one?
>
> It's abandoned, The MUMI tracker lacks the responses from Leo Prickler,
> but they had good arguments maintaining the status quo rather than going
> with the extra complexity.  It also wouldn't change the issue at hand;
> it'd merely prevent conflicts of *resources* files of Emacs packages
> (and somewhat integrate with the Emacs native package manager, while
> making the autoloading a bit slower).  It seems the price to pay is too
> high for such a small gain.  I'm closing it now.

I see, makes sense!

> On the other hand, this very problem was the motivation for this patch
> series here: https://issues.guix.gnu.org/43627, which would solve the
> issue ta hand.  You were skeptical of the benefits the last time you
> took a look at it; perhaps it's time to take a new look at it :-).

Ah!  Now I may have to revisit it, indeed.

Thanks for explaining!

Ludo’.

Message #29 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: 47458 <at> debbugs.gnu.org
Cc: 43627 <at> debbugs.gnu.org, maxim.cournoyer <at> gmail.com
Subject: [PATCH] gnu: emacs: Wrap EMACSLOADPATH.
Date: Tue, 30 Mar 2021 20:41:01 +0200

With this, the search path specification of EMACSLOADPATH does no longer
depend on the version of Emacs, which should make upgrading major versions
less painful.  See also:
- <https://bugs.gnu.org/43627>
- <https://bugs.gnu.org/47458>

* gnu/packages/emacs.scm (emacs)[#:phases]: Add ‘wrap-load-path’.
[native-search-path]<EMACSLOADPATH>: Do not search for builtin libraries.
(emacs-next)[native-search-path]: Inherit from emacs.
---
 gnu/packages/emacs.scm | 31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 7447cfe33a..e12c489f8d 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -201,6 +201,20 @@
                 (car (find-files "bin" "^emacs-([0-9]+\\.)+[0-9]+$"))
                 "bin/emacs")
                #t)))
+         (add-after 'strip-double-wrap 'wrap-load-path
+           (lambda* (#:key outputs #:allow-other-keys)
+             (let* ((out (assoc-ref outputs "out"))
+                    (lisp-dirs (find-files (string-append out "/share/emacs")
+                                           "^lisp$"
+                                           #:directories? #t)))
+               (for-each
+                (lambda (prog)
+                  (wrap-program prog
+                    `("EMACSLOADPATH" suffix ,lisp-dirs)))
+                (find-files (string-append out "/bin")
+                            ;; versioned and unversioned emacs binaries
+                            "^emacs(-[0-9]+(\\.[0-9]+)*)?$"))
+               #t)))
          (add-before 'reset-gzip-timestamps 'make-compressed-files-writable
            ;; The 'reset-gzip-timestamps phase will throw a permission error
            ;; if gzip files aren't writable then.  This phase is needed when
@@ -255,9 +269,7 @@
     (native-search-paths
      (list (search-path-specification
             (variable "EMACSLOADPATH")
-            ;; The versioned entry is for the Emacs' builtin libraries.
-            (files (list "share/emacs/site-lisp"
-                         (string-append "share/emacs/" version "/lisp"))))
+            (files '("share/emacs/site-lisp")))
            (search-path-specification
             (variable "INFOPATH")
             (files '("share/info")))))
@@ -294,18 +306,7 @@ languages.")
            "0igjm9kwiswn2dpiy2k9xikbdfc7njs07ry48fqz70anljj8y7y3"))))
       (native-inputs
        `(("autoconf" ,autoconf)
-         ,@(package-native-inputs emacs)))
-      (native-search-paths
-       (list (search-path-specification
-              (variable "EMACSLOADPATH")
-              ;; The versioned entry is for the Emacs' builtin libraries.
-              (files (list "share/emacs/site-lisp"
-                           (string-append "share/emacs/"
-                                          (version-major+minor+point version)
-                                          "/lisp"))))
-             (search-path-specification
-              (variable "INFOPATH")
-              (files '("share/info"))))))))
+         ,@(package-native-inputs emacs))))))
 
 (define-public emacs-next-pgtk
   (let ((commit "ae18c8ec4f0ef37c8c9cda473770ff47e41291e2")
-- 
2.31.0

Message #32 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 47458 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Mark H Weaver <mhw <at> netris.org>
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Sun, 04 Apr 2021 00:35:31 -0400

Hi Leo!

Leo Prikler <leo.prikler <at> student.tugraz.at> writes:

> With this, the search path specification of EMACSLOADPATH does no longer
> depend on the version of Emacs, which should make upgrading major versions
> less painful.  See also:
> - <https://bugs.gnu.org/43627>
> - <https://bugs.gnu.org/47458>
>
> * gnu/packages/emacs.scm (emacs)[#:phases]: Add ‘wrap-load-path’.
> [native-search-path]<EMACSLOADPATH>: Do not search for builtin libraries.
> (emacs-next)[native-search-path]: Inherit from emacs.
> ---
>  gnu/packages/emacs.scm | 31 ++++++++++++++++---------------
>  1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index 7447cfe33a..e12c489f8d 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -201,6 +201,20 @@
>                  (car (find-files "bin" "^emacs-([0-9]+\\.)+[0-9]+$"))
>                  "bin/emacs")
>                 #t)))
> +         (add-after 'strip-double-wrap 'wrap-load-path
> +           (lambda* (#:key outputs #:allow-other-keys)
> +             (let* ((out (assoc-ref outputs "out"))
> +                    (lisp-dirs (find-files (string-append out "/share/emacs")
> +                                           "^lisp$"
> +                                           #:directories? #t)))
> +               (for-each
> +                (lambda (prog)
> +                  (wrap-program prog
> +                    `("EMACSLOADPATH" suffix ,lisp-dirs)))
> +                (find-files (string-append out "/bin")
> +                            ;; versioned and unversioned emacs binaries
> +                            "^emacs(-[0-9]+(\\.[0-9]+)*)?$"))
> +               #t)))

Shouldn't we wrap all the binaries to be on the safe side?  Things such
as emacsclient probably ought to have EMACSLOADPATH set correctly, no?

>           (add-before 'reset-gzip-timestamps 'make-compressed-files-writable
>             ;; The 'reset-gzip-timestamps phase will throw a permission error
>             ;; if gzip files aren't writable then.  This phase is needed when
> @@ -255,9 +269,7 @@
>      (native-search-paths
>       (list (search-path-specification
>              (variable "EMACSLOADPATH")
> -            ;; The versioned entry is for the Emacs' builtin libraries.
> -            (files (list "share/emacs/site-lisp"
> -                         (string-append "share/emacs/" version "/lisp"))))
> +            (files '("share/emacs/site-lisp")))
>             (search-path-specification
>              (variable "INFOPATH")
>              (files '("share/info")))))
> @@ -294,18 +306,7 @@ languages.")
>             "0igjm9kwiswn2dpiy2k9xikbdfc7njs07ry48fqz70anljj8y7y3"))))
>        (native-inputs
>         `(("autoconf" ,autoconf)
> -         ,@(package-native-inputs emacs)))
> -      (native-search-paths
> -       (list (search-path-specification
> -              (variable "EMACSLOADPATH")
> -              ;; The versioned entry is for the Emacs' builtin libraries.
> -              (files (list "share/emacs/site-lisp"
> -                           (string-append "share/emacs/"
> -                                          (version-major+minor+point version)
> -                                          "/lisp"))))
> -             (search-path-specification
> -              (variable "INFOPATH")
> -              (files '("share/info"))))))))
> +         ,@(package-native-inputs emacs))))))
>  
>  (define-public emacs-next-pgtk
>    (let ((commit "ae18c8ec4f0ef37c8c9cda473770ff47e41291e2")

This makes sense, and can make it to master rather than core-updates,
which is neat.

Thank you :-)

Maxim

Message #35 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 47458 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Mark H Weaver <mhw <at> netris.org>
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Sun, 04 Apr 2021 09:49:31 +0200

Hi Maxim!

Am Sonntag, den 04.04.2021, 00:35 -0400 schrieb Maxim Cournoyer:
> Hi Leo!
> 
> Leo Prikler <leo.prikler <at> student.tugraz.at> writes:
> 
> > With this, the search path specification of EMACSLOADPATH does no
> > longer
> > depend on the version of Emacs, which should make upgrading major
> > versions
> > less painful.  See also:
> > - <https://bugs.gnu.org/43627>
> > - <https://bugs.gnu.org/47458>
> > 
> > * gnu/packages/emacs.scm (emacs)[#:phases]: Add ‘wrap-load-path’.
> > [native-search-path]<EMACSLOADPATH>: Do not search for builtin
> > libraries.
> > (emacs-next)[native-search-path]: Inherit from emacs.
> > ---
> >  gnu/packages/emacs.scm | 31 ++++++++++++++++---------------
> >  1 file changed, 16 insertions(+), 15 deletions(-)
> > 
> > diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> > index 7447cfe33a..e12c489f8d 100644
> > --- a/gnu/packages/emacs.scm
> > +++ b/gnu/packages/emacs.scm
> > @@ -201,6 +201,20 @@
> >                  (car (find-files "bin" "^emacs-([0-9]+\\.)+[0-
> > 9]+$"))
> >                  "bin/emacs")
> >                 #t)))
> > +         (add-after 'strip-double-wrap 'wrap-load-path
> > +           (lambda* (#:key outputs #:allow-other-keys)
> > +             (let* ((out (assoc-ref outputs "out"))
> > +                    (lisp-dirs (find-files (string-append out
> > "/share/emacs")
> > +                                           "^lisp$"
> > +                                           #:directories? #t)))
> > +               (for-each
> > +                (lambda (prog)
> > +                  (wrap-program prog
> > +                    `("EMACSLOADPATH" suffix ,lisp-dirs)))
> > +                (find-files (string-append out "/bin")
> > +                            ;; versioned and unversioned emacs
> > binaries
> > +                            "^emacs(-[0-9]+(\\.[0-9]+)*)?$"))
> > +               #t)))
> 
> Shouldn't we wrap all the binaries to be on the safe side?  Things
> such
> as emacsclient probably ought to have EMACSLOADPATH set correctly,
> no?
The remaining binaries are
- emacsclient, which inherits its EMACSLOADPATH from the server it
connects to
- ctags, ebrowse and etags, which are helper binaries, that don't seem
to rely on EMACSLOADPATH at all.  (Or is there an indicator, that they
do?)
- .-real binaries, that should only be wrapped once.
We could relax the regex to include the upper two, but I don't think
it's necessary to do so.

> >           (add-before 'reset-gzip-timestamps 'make-compressed-
> > files-writable
> >             ;; The 'reset-gzip-timestamps phase will throw a
> > permission error
> >             ;; if gzip files aren't writable then.  This phase is
> > needed when
> > @@ -255,9 +269,7 @@
> >      (native-search-paths
> >       (list (search-path-specification
> >              (variable "EMACSLOADPATH")
> > -            ;; The versioned entry is for the Emacs' builtin
> > libraries.
> > -            (files (list "share/emacs/site-lisp"
> > -                         (string-append "share/emacs/" version
> > "/lisp"))))
> > +            (files '("share/emacs/site-lisp")))
> >             (search-path-specification
> >              (variable "INFOPATH")
> >              (files '("share/info")))))
> > @@ -294,18 +306,7 @@ languages.")
> >             "0igjm9kwiswn2dpiy2k9xikbdfc7njs07ry48fqz70anljj8y7y3")
> > )))
> >        (native-inputs
> >         `(("autoconf" ,autoconf)
> > -         ,@(package-native-inputs emacs)))
> > -      (native-search-paths
> > -       (list (search-path-specification
> > -              (variable "EMACSLOADPATH")
> > -              ;; The versioned entry is for the Emacs' builtin
> > libraries.
> > -              (files (list "share/emacs/site-lisp"
> > -                           (string-append "share/emacs/"
> > -                                          (version-
> > major+minor+point version)
> > -                                          "/lisp"))))
> > -             (search-path-specification
> > -              (variable "INFOPATH")
> > -              (files '("share/info"))))))))
> > +         ,@(package-native-inputs emacs))))))
> >  
> >  (define-public emacs-next-pgtk
> >    (let ((commit "ae18c8ec4f0ef37c8c9cda473770ff47e41291e2")
> 
> This makes sense, and can make it to master rather than core-updates,
> which is neat.
I'd like to avoid pushing this to master just yet, because we also have
changes in the Emacs build system to discuss and I don't want to cause
an "Emacs world" rebuild twice in a row.  That said, I'm including this
patch in wip-emacs with the plan to push to master or staging once
everything there is resolved.

Regards,
Leo

Message #38 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 47458 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Mark H Weaver <mhw <at> netris.org>
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Tue, 06 Apr 2021 08:09:02 -0400

Hi Leo!

Leo Prikler <leo.prikler <at> student.tugraz.at> writes:

[...]

>> Shouldn't we wrap all the binaries to be on the safe side?  Things
>> such
>> as emacsclient probably ought to have EMACSLOADPATH set correctly,
>> no?
> The remaining binaries are
> - emacsclient, which inherits its EMACSLOADPATH from the server it
> connects to
> - ctags, ebrowse and etags, which are helper binaries, that don't seem
> to rely on EMACSLOADPATH at all.  (Or is there an indicator, that they
> do?)
> - .-real binaries, that should only be wrapped once.
> We could relax the regex to include the upper two, but I don't think
> it's necessary to do so.

OK, thanks for the explanation, it makes sense.

[...]

> I'd like to avoid pushing this to master just yet, because we also have
> changes in the Emacs build system to discuss and I don't want to cause
> an "Emacs world" rebuild twice in a row.  That said, I'm including this
> patch in wip-emacs with the plan to push to master or staging once
> everything there is resolved.

Sure!  Which changes do you have in mind?  Are they already on the
tracker for review?

Thank you,

Maxim

Message #41 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 47458 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Mark H Weaver <mhw <at> netris.org>
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Tue, 06 Apr 2021 17:49:41 +0200

Hi Maxim!

Am Dienstag, den 06.04.2021, 08:09 -0400 schrieb Maxim Cournoyer:
> Hi Leo!
> 
> Leo Prikler <leo.prikler <at> student.tugraz.at> writes:
> 
> [...]
> 
> > > Shouldn't we wrap all the binaries to be on the safe
> > > side?  Things
> > > such
> > > as emacsclient probably ought to have EMACSLOADPATH set
> > > correctly,
> > > no?
> > The remaining binaries are
> > - emacsclient, which inherits its EMACSLOADPATH from the server it
> > connects to
> > - ctags, ebrowse and etags, which are helper binaries, that don't
> > seem
> > to rely on EMACSLOADPATH at all.  (Or is there an indicator, that
> > they
> > do?)
> > - .-real binaries, that should only be wrapped once.
> > We could relax the regex to include the upper two, but I don't
> > think
> > it's necessary to do so.
> 
> OK, thanks for the explanation, it makes sense.
> 
Should I also document that (as a comment in the code) or is it
somewhat intuitive, that only Emacs is interested in these variables
(just EMACSLOADPATH currently, maybe also PATH later)?
> 
> > I'd like to avoid pushing this to master just yet, because we also
> > have
> > changes in the Emacs build system to discuss and I don't want to
> > cause
> > an "Emacs world" rebuild twice in a row.  That said, I'm including
> > this
> > patch in wip-emacs with the plan to push to master or staging once
> > everything there is resolved.
> 
> Sure!  Which changes do you have in mind?  Are they already on the
> tracker for review?
> 

I've sent some of the changes for emacs-build-system to 45316.  The
rest only lives on wip-emacs as of yet.  The first 5 patches on that
branch are the ones that include the big changes (well, four of them
anyway), one of which is not yet up to review as it results from the
combined fixes to 45316 and 47458, the rest are mostly small "fixup"
commits.

Regards,
Leo

Message #44 received at 47458 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 47458 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Mark H Weaver <mhw <at> netris.org>
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Wed, 07 Apr 2021 15:46:18 -0400

Hi Leo!

Leo Prikler <leo.prikler <at> student.tugraz.at> writes:

> Hi Maxim!
>
> Am Dienstag, den 06.04.2021, 08:09 -0400 schrieb Maxim Cournoyer:
>> Hi Leo!
>>
>> Leo Prikler <leo.prikler <at> student.tugraz.at> writes:
>>
>> [...]
>>
>> > > Shouldn't we wrap all the binaries to be on the safe
>> > > side?  Things
>> > > such
>> > > as emacsclient probably ought to have EMACSLOADPATH set
>> > > correctly,
>> > > no?
>> > The remaining binaries are
>> > - emacsclient, which inherits its EMACSLOADPATH from the server it
>> > connects to
>> > - ctags, ebrowse and etags, which are helper binaries, that don't
>> > seem
>> > to rely on EMACSLOADPATH at all.  (Or is there an indicator, that
>> > they
>> > do?)
>> > - .-real binaries, that should only be wrapped once.
>> > We could relax the regex to include the upper two, but I don't
>> > think
>> > it's necessary to do so.
>>
>> OK, thanks for the explanation, it makes sense.
>>
> Should I also document that (as a comment in the code) or is it
> somewhat intuitive, that only Emacs is interested in these variables
> (just EMACSLOADPATH currently, maybe also PATH later)?

It wouldn't hurt!  It was not obvious to me that emacsclient didn't need
it (I have no knowledge of emacsclient's internals).

>> > I'd like to avoid pushing this to master just yet, because we also
>> > have
>> > changes in the Emacs build system to discuss and I don't want to
>> > cause
>> > an "Emacs world" rebuild twice in a row.  That said, I'm including
>> > this
>> > patch in wip-emacs with the plan to push to master or staging once
>> > everything there is resolved.
>>
>> Sure!  Which changes do you have in mind?  Are they already on the
>> tracker for review?
>>
>
> I've sent some of the changes for emacs-build-system to 45316.  The
> rest only lives on wip-emacs as of yet.  The first 5 patches on that
> branch are the ones that include the big changes (well, four of them
> anyway), one of which is not yet up to review as it results from the
> combined fixes to 45316 and 47458, the rest are mostly small "fixup"
> commits.

OK.  I'll have a look.

Maxim

Message #49 received at 47458-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: Mark H Weaver <mhw <at> netris.org>,
 Ludovic Courtès <ludo <at> gnu.org>, 47458-done <at> debbugs.gnu.org
Subject: Re: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Thu, 20 May 2021 09:24:16 -0400

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

This should be fixed with the recently merged changes from Leo.  See
commit 307a2d2e2a833c2e1f7a79f46e4c6945c618cd8c. Thank you!

Closing.

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.