Terrible UX upgrading Emacs in Guix

  • Done
  • quality assurance status badge
Details
5 participants
  • Leo Prikler
  • Ludovic Courtès
  • Maxim Cournoyer
  • Maxime Devos
  • Mark H Weaver
Owner
unassigned
Submitted by
Mark H Weaver
Severity
normal
M
M
Mark H Weaver wrote on 29 Mar 2021 04:02
(address . bug-guix@gnu.org)
87o8f23eew.fsf@netris.org
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
L
L
Leo Prikler wrote on 29 Mar 2021 10:07
a7f2bc110511dead9070bd805dd38788f3d5973f.camel@student.tugraz.at
Am Sonntag, den 28.03.2021, 22:02 -0400 schrieb Mark H Weaver:
Toggle quote (13 lines)
> 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?

Toggle quote (21 lines)
> [...]
>
> 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
M
M
Maxime Devos wrote on 29 Mar 2021 10:24
Re: bug#47458: Terrible UX upgrading Emacs in Guix
48be53a43407c9a298bc1abe798f7744a07ed9fa.camel@telenet.be
On Mon, 2021-03-29 at 10:07 +0200, Leo Prikler wrote:
Toggle quote (10 lines)
> [...]
>
> 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.
-----BEGIN PGP SIGNATURE-----

iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYGGOoRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7heHAP9CvAPUQ5xxS2l2Jm62EnHiEVtf
TR1OEdFV4mWCsdRv1wEA60MvVZCLozEQ7WBnLIqPQcmLtltCVWh4CIaVeI8zMwo=
=rCP2
-----END PGP SIGNATURE-----


L
L
Leo Prikler wrote on 29 Mar 2021 10:43
cbd14e7fe65ca52ad07557ae58f30dc55b6aef4b.camel@student.tugraz.at
Am Montag, den 29.03.2021, 10:24 +0200 schrieb Maxime Devos:
Toggle quote (20 lines)
> 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.)
L
L
Ludovic Courtès wrote on 29 Mar 2021 17:55
(name . Mark H Weaver)(address . mhw@netris.org)
87czvineeh.fsf@gnu.org
Hi Mark,

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

Toggle quote (15 lines)
> 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’.
L
L
Ludovic Courtès wrote on 29 Mar 2021 17:55
(name . Mark H Weaver)(address . mhw@netris.org)
87blb2nedp.fsf@gnu.org
Hi Mark,

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

Toggle quote (15 lines)
> 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’.
M
M
Maxim Cournoyer wrote on 29 Mar 2021 20:25
(name . Ludovic Courtès)(address . ludo@gnu.org)
87r1jxbyvj.fsf@gmail.com
Hi,

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

Toggle quote (26 lines)
> Hi Mark,
>
> Mark H Weaver <mhw@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
L
L
Ludovic Courtès wrote on 30 Mar 2021 10:04
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87ft0djce0.fsf@gnu.org
Hello,

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

Toggle quote (2 lines)
> Ludovic Courtès <ludo@gnu.org> writes:

[...]

Toggle quote (15 lines)
>> 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!

Toggle quote (5 lines)
> 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’.
L
L
Leo Prikler wrote on 30 Mar 2021 20:41
[PATCH] gnu: emacs: Wrap EMACSLOADPATH.
(address . 47458@debbugs.gnu.org)
20210330184101.7643-1-leo.prikler@student.tugraz.at
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:

* 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(-)

Toggle diff (58 lines)
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
M
M
Maxim Cournoyer wrote on 4 Apr 2021 06:35
Re: bug#47458: Terrible UX upgrading Emacs in Guix
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87wntipsz0.fsf_-_@gmail.com
Hi Leo!

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

Toggle quote (36 lines)
> 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?

Toggle quote (35 lines)
> (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
L
L
Leo Prikler wrote on 4 Apr 2021 09:49
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
0491bf7a885f44dbf62e2ca3b21fb5671daed5ec.camel@student.tugraz.at
Hi Maxim!

Am Sonntag, den 04.04.2021, 00:35 -0400 schrieb Maxim Cournoyer:
Toggle quote (50 lines)
> Hi Leo!
>
> Leo Prikler <leo.prikler@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.

Toggle quote (45 lines)
> > (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
M
M
Maxim Cournoyer wrote on 6 Apr 2021 14:09
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87k0pfpqch.fsf@gmail.com
Hi Leo!

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

[...]

Toggle quote (14 lines)
>> 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.

[...]

Toggle quote (6 lines)
> 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
L
L
Leo Prikler wrote on 6 Apr 2021 17:49
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
1b3ed7a0c057e55f9c5b16ee93c2afbbaa61e23d.camel@student.tugraz.at
Hi Maxim!

Am Dienstag, den 06.04.2021, 08:09 -0400 schrieb Maxim Cournoyer:
Toggle quote (27 lines)
> Hi Leo!
>
> Leo Prikler <leo.prikler@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)?
Toggle quote (14 lines)
>
> > 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
M
M
Maxim Cournoyer wrote on 7 Apr 2021 21:46
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
874kghop2t.fsf@gmail.com
Hi Leo!

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

Toggle quote (34 lines)
> Hi Maxim!
>
> Am Dienstag, den 06.04.2021, 08:09 -0400 schrieb Maxim Cournoyer:
>> Hi Leo!
>>
>> Leo Prikler <leo.prikler@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).

Toggle quote (20 lines)
>> > 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
M
M
Maxim Cournoyer wrote on 20 May 2021 15:24
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87v97dzgfz.fsf@gmail.com
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

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

Closing.

Maxim
Closed
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 47458
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