Recent $EMACSLOADPATH changes crash gnome-session

  • Done
  • quality assurance status badge
Details
8 participants
  • Alex Griffin
  • Arne Babenhauserheide
  • Clément Lassieur
  • Jelle Licht
  • Leo Prikler
  • Ludovic Courtès
  • Mathieu Othacehe
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Alex Griffin
Severity
serious
A
A
Alex Griffin wrote on 21 Nov 2019 03:25
(address . bug-guix@gnu.org)
c88511b9-46aa-482f-9f8c-60fbeaa10f6e@www.fastmail.com
After upgrading my packages today, gnome-session started segfaulting. I think I finally tracked the problem down to the recent changes in how Emacs searches for packages. Apparently Emacs now uses the search path $EMACSLOADPATH. Unfortunately, this is a very long value on my system:

$ echo $EMACSLOADPATH | wc -c
22525

When I add `unset EMACSLOADPATH` to the end of `~/.profile`, GNOME works again.

--
Alex Griffin
C
C
Clément Lassieur wrote on 22 Nov 2019 14:00
(address . 38309@debbugs.gnu.org)
87y2w8vzeq.fsf@lassieur.org
"Alex Griffin" <a@ajgrf.com> writes:

Toggle quote (10 lines)
> After upgrading my packages today, gnome-session started segfaulting. I think
> I finally tracked the problem down to the recent changes in how Emacs searches
> for packages. Apparently Emacs now uses the search path
> $EMACSLOADPATH. Unfortunately, this is a very long value on my system:
>
> $ echo $EMACSLOADPATH | wc -c
> 22525
>
> When I add `unset EMACSLOADPATH` to the end of `~/.profile`, GNOME works again.

Same issue here.

Since restarting Gnome Session is not possible anymore, the only way to
add an Emacs package is to reboot.

In case it's not clear: Booting works, but restarting the session
crashes.

Log attached, with:

Toggle snippet (3 lines)
nov. 22 13:02:15 rodion kernel: gnome-session-b[3879]: segfault at 7ffd5d8e4f10 ip 00007fa420f1ba6a sp 00007ffd5d8e4f00 error 6 in libpcre.so.3.13.3[7fa420f03000+70000]

Guix version:

Toggle snippet (7 lines)
Generation 14 nov. 21 2019 12:51:33 (current)
guix fe9b72c
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: fe9b72c5861fabdf7f37862de393812ff3e423ac

With an up-to-date Ubuntu 18.04.3 LTS.

Cheers,
Clément
Attachment: log
C
C
Clément Lassieur wrote on 22 Nov 2019 14:01
control message for bug #38309
(address . control@debbugs.gnu.org)
87lfs85akq.fsf@lassieur.org
severity 38309 serious
quit
M
M
Mathieu Othacehe wrote on 22 Nov 2019 14:15
Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
(address . bug-guix@gnu.org)
8736egaw7g.fsf@gmail.com
Hello,

Toggle quote (3 lines)
> In case it's not clear: Booting works, but restarting the session
> crashes.

Not much to add, but I have the same issue and once logged out, I need to
restart my machine to login again to GNOME on Ubuntu 18.04.

Mathieu
M
M
Maxim Cournoyer wrote on 22 Nov 2019 18:40
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
87k17rvmfw.fsf@gmail.com
Hello all,

Really sorry about this ugly regression :-/.

I'm surprised that a 22000 characters in an environment variable would
be an issue though, given that that's probably around 22 KiB of memory
and some people tested huge variables (>18 MiB) without facing any hard
limit other than RAM [0].

Which leads me to suspect that the problem might be Gnome specific? I
haven't experienced it, but then my EMACSLOADPATH variable is only about
7000 characters and I'm not using Gnome (I use ratpoison as a WM).

If someone could confirm that they can login using another desktop
(XFCE, perhaps?) that'd tell us we need to look more carefully at what
gnome-session does and why it crashes on larger than average environment
variables.

I believe the "enhancement" #1 (to deprecate guix.d subdirectories) in
XFCE?) as explained in bug #38273 [1] could lead to a much leaner
EMACSLOADPATH, by reducing the number of entries necessary to refer to
all the Elisp packages.


Maxim
L
L
Ludovic Courtès wrote on 23 Nov 2019 19:05
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87eexy1nah.fsf@gnu.org
Hi Maxim,

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

Toggle quote (2 lines)
> Really sorry about this ugly regression :-/.

Should we revert 47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c so we can
address this without pressure in the meantime?

I think I missed the discussions around this patch, but we should get
Alex Kost into the loop (Alex did the initial work in that area, if I’m
not mistaken.)

Thanks,
Ludo’.
M
M
Maxim Cournoyer wrote on 24 Nov 2019 04:45
(name . Ludovic Courtès)(address . ludo@gnu.org)
87d0diuec0.fsf@gmail.com
Hello,

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

Toggle quote (16 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Really sorry about this ugly regression :-/.
>
> Should we revert 47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c so we can
> address this without pressure in the meantime?
>
> I think I missed the discussions around this patch, but we should get
> Alex Kost into the loop (Alex did the initial work in that area, if I’m
> not mistaken.)
>
> Thanks,
> Ludo’.

There would be a couple more commits to include in the revert to undo
the changes (one to the build system, others to adapt the renaming of
the emacs-set-load-path phase for some packages:

Toggle snippet (12 lines)
63edbb65e4 * origin/master gnu: emacs-protobuf-mode: Rename the set-emacs-load-path phase.
ffb2316548 * gnu: emacs-erlang: Rename the set-emacs-load-path phase.
ed94123667 * gnu: emacs-pdf-tools: Adapt phase name.
418febb54f * gnu: emacs-scel: Fix build.
1bb39982f1 * gnu: emacs-realgud: Fix build.
c51d4c7746 * gnu: emacs-pdf-tools: Fix build.
b44357d02a * gnu: emacs-forge: Fix build.
47b3b4c2aa * gnu: emacs: Adapt the autoloads auxiliary code to use EMACSLOADPATH.
e1d31e6457 * build-system: emacs: Simplify the SET-EMACS-LOAD-PATH phase.
215a45d9b8 * gnu: emacs: Locate Elisp libraries via EMACSLOADPATH.

The bug in questino seems to have to do with a regression in recent
versions PCRE, that trigger a crash on large environment variables as
reported in [0]. There's a new version of PCRE2 (10.34) available; but
I'm unsure if it addresses this particular problem:
https://pcre.org/changelog.txt. If it doesn't we should report the
problem to them.

This could happen with any other environment variable than
EMACSLOADPATH; it's just a matter of having an environment variable grow
sufficiently long to trigger it.

I'm testing a patch that may workaround this problem successfully right
now (that would reduce the length of EMACSLOADPATH) I'll send an
incomplete patch shortly for discussing the idea or testing. In case
it's not clear; I'd rather workaround the issue or have it fixed at its
source, ideally.

WDYT?

Maxim

L
L
Ludovic Courtès wrote on 24 Nov 2019 18:56
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
875zj9yx8f.fsf@gnu.org
Hi Maxim,

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

Toggle quote (4 lines)
> There would be a couple more commits to include in the revert to undo
> the changes (one to the build system, others to adapt the renaming of
> the emacs-set-load-path phase for some packages:

Oh indeed.

I must say I haven’t looked closely at the changes nor at the reasons
for the regression, but IIUC, the regression is serious enough that we
should have a way to address it quickly.

WDYT?

Thanks,
Ludo’.
M
M
Maxim Cournoyer wrote on 25 Nov 2019 18:23
(name . Ludovic Courtès)(address . ludo@gnu.org)
874kyrvphw.fsf@gmail.com
Hello Ludovic,

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

Toggle quote (14 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> There would be a couple more commits to include in the revert to undo
>> the changes (one to the build system, others to adapt the renaming of
>> the emacs-set-load-path phase for some packages:
>
> Oh indeed.
>
> I must say I haven’t looked closely at the changes nor at the reasons
> for the regression, but IIUC, the regression is serious enough that we
> should have a way to address it quickly.

The regression only seems to affect the "restarting the session",
e.g. logout then login, not the first boot, which means there's an
(inconvenient) workaround available for single user systems.

I've been trying to reproduce in a VM to get a backtrace (if those
affected by the problem could produce one, that'd help pinpoint the
problematic call to PCRE and its origin), but that'll need some more
time.

If those affected judge the situation dire enough, I don't mind
reverting the changes to the Emacs library loading mechanism for the
time being.

Thanks,

Maxim
M
M
Maxim Cournoyer wrote on 26 Nov 2019 05:04
(name . Ludovic Courtès)(address . ludo@gnu.org)
87zhgjthan.fsf@gmail.com
Hello again,

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

Toggle quote (14 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> There would be a couple more commits to include in the revert to undo
>> the changes (one to the build system, others to adapt the renaming of
>> the emacs-set-load-path phase for some packages:
>
> Oh indeed.
>
> I must say I haven’t looked closely at the changes nor at the reasons
> for the regression, but IIUC, the regression is serious enough that we
> should have a way to address it quickly.

I could reproduce the gnome-session crash by generating a Guix VM with
the attached OS configuration (it has about 100 Emacs packages installed
to its system profile, which gives an EMACSLOADPATH length of about
13000 characters), and got the following backtrace (no debugging
symbols):

Toggle snippet (15 lines)
#0 0x00007ffff7837e27 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#1 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#2 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
[...]
#17435 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#17436 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#17437 0x00007ffff78399c6 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#17438 0x00007ffff784a441 in pcre_exec () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
#17439 0x00007ffff7ceca8b in g_match_info_next () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
#17440 0x00007ffff7cee21f in g_regex_match_full () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
#17441 0x00007ffff7cee36a in g_regex_match () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
#17442 0x000000000042b779 in gsm_util_export_activation_environment ()
#17443 0x000000000040adde in main ()

This tells us that the problem originates from glib. Looking at the
number of match calls, libpcre is probably blowing up its stack as
described in this ticket [0]. According to this link, it seems glib
should be making use of PCRE's facilities to limit the depth of search,
e.g. by using "match limit" and "recursion limit" as documented here [1]
(search for "int pcre_exec(" on that page).

Parallel to this, perhaps the regexp used by glib could be rewritten to
not rely as much on the stack.

L
L
Ludovic Courtès wrote on 26 Nov 2019 09:56
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87y2w3c8y1.fsf@gnu.org
Hi Maxim,

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

Toggle quote (30 lines)
> I could reproduce the gnome-session crash by generating a Guix VM with
> the attached OS configuration (it has about 100 Emacs packages installed
> to its system profile, which gives an EMACSLOADPATH length of about
> 13000 characters), and got the following backtrace (no debugging
> symbols):
>
> #0 0x00007ffff7837e27 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
> #1 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
> #2 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
> [...]
> #17435 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
> #17436 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
> #17437 0x00007ffff78399c6 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
> #17438 0x00007ffff784a441 in pcre_exec () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
> #17439 0x00007ffff7ceca8b in g_match_info_next () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
> #17440 0x00007ffff7cee21f in g_regex_match_full () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
> #17441 0x00007ffff7cee36a in g_regex_match () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
> #17442 0x000000000042b779 in gsm_util_export_activation_environment ()
> #17443 0x000000000040adde in main ()
>
> This tells us that the problem originates from glib. Looking at the
> number of match calls, libpcre is probably blowing up its stack as
> described in this ticket [0]. According to this link, it seems glib
> should be making use of PCRE's facilities to limit the depth of search,
> e.g. by using "match limit" and "recursion limit" as documented here [1]
> (search for "int pcre_exec(" on that page).
>
> Parallel to this, perhaps the regexp used by glib could be rewritten to
> not rely as much on the stack.

Oh great, thanks for investigating!

I have a shallow understanding of the issues, but (1) are we not going
overboard with that big a environment variable? :-), and (2) fixing GLib
or PCRE would require a full rebuild, can you think of a way to work
around the issue?

Thanks,
Ludo’.
C
C
Clément Lassieur wrote on 26 Nov 2019 10:20
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87k17n0z9t.fsf@lassieur.org
Hello Maxim,

Thanks for taking the time to look into this. I've seen your other
email, you can install libpcre3-dbg to have PCRE's debug symbols. It
might help.

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

Toggle quote (14 lines)
> Hello Ludovic,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> There would be a couple more commits to include in the revert to undo
>>> the changes (one to the build system, others to adapt the renaming of
>>> the emacs-set-load-path phase for some packages:
>>
>> Oh indeed.

Well, maybe it would make sense to squash them into one revert commit,
that would be re-reverted when the bug is fixed?

Toggle quote (8 lines)
>> I must say I haven’t looked closely at the changes nor at the reasons
>> for the regression, but IIUC, the regression is serious enough that we
>> should have a way to address it quickly.
>
> The regression only seems to affect the "restarting the session",
> e.g. logout then login, not the first boot, which means there's an
> (inconvenient) workaround available for single user systems.

Before the patches, restarting Emacs was enough to have new packages
installed. Now I have to reboot my computer every time I 'guix package
-i emacs-something'. Emacs is central to my workflow and I often change
things around (as do a lot of Guix users). It is inconvenient, really.

Toggle quote (5 lines)
> I've been trying to reproduce in a VM to get a backtrace (if those
> affected by the problem could produce one, that'd help pinpoint the
> problematic call to PCRE and its origin), but that'll need some more
> time.

Even if you find a solution, the fix will take a lot of time to land
onto an Ubuntu release.

Toggle quote (4 lines)
> If those affected judge the situation dire enough, I don't mind
> reverting the changes to the Emacs library loading mechanism for the
> time being.

Please, do so :)

Lots of users don't have that bug, but there's still a change in their
workflow: they have to restart their session after installing new Emacs
packages. Maybe when that bug is fixed and this set of patch is
re-applied, there will be an opportunity to communicate about this? On
info-guix maybe, or on 'guix pull'. It would explain the pros and cons
of this new way of dealing with Emacs. I don't know if there was such
an announcement already, I didn't see it. WDYT?

Thanks again,
Clément
L
L
Ludovic Courtès wrote on 26 Nov 2019 10:30
(name . Clément Lassieur)(address . clement@lassieur.org)
87eexvc7do.fsf@gnu.org
Hello,

clement@lassieur.org (Clément Lassieur) skribis:

Toggle quote (5 lines)
> Before the patches, restarting Emacs was enough to have new packages
> installed. Now I have to reboot my computer every time I 'guix package
> -i emacs-something'. Emacs is central to my workflow and I often change
> things around (as do a lot of Guix users). It is inconvenient, really.

I wasn’t aware of that, it sounds like a drawback. I wonder if
Emacs-Guix knows how to deal with that (until now it was able to
directly load Emacs packages you’d install with itself).

I think I would lean towards a revert (that is, a single commit
reverting the 3 (?) patches that implement this new approach).

Then we can discuss the change with less pressure and make sure
stakeholders weigh in (they could have done that before but apparently
many, myself included, missed that opportunity :-)).

Thoughts?

Thanks,
Ludo’.
C
C
Clément Lassieur wrote on 26 Nov 2019 10:43
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87zhgjt1km.fsf@lassieur.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (22 lines)
> Hello Ludovic,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> There would be a couple more commits to include in the revert to undo
>>> the changes (one to the build system, others to adapt the renaming of
>>> the emacs-set-load-path phase for some packages:
>>
>> Oh indeed.
>>
>> I must say I haven’t looked closely at the changes nor at the reasons
>> for the regression, but IIUC, the regression is serious enough that we
>> should have a way to address it quickly.
>
> The regression only seems to affect the "restarting the session",
> e.g. logout then login, not the first boot, which means there's an
> (inconvenient) workaround available for single user systems.

Also, this assumes the users know about the bug. But some (most?) of
them won't know about it and will spend a lot of time (as I did) trying
to understand why their gnome-session crashes.

Toggle quote (12 lines)
> I've been trying to reproduce in a VM to get a backtrace (if those
> affected by the problem could produce one, that'd help pinpoint the
> problematic call to PCRE and its origin), but that'll need some more
> time.
>
> If those affected judge the situation dire enough, I don't mind
> reverting the changes to the Emacs library loading mechanism for the
> time being.
>
> Thanks,
>
> Maxim
L
L
Leo Prikler wrote on 27 Nov 2019 01:01
bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
(address . ludo@gnu.org)(address . 38309@debbugs.gnu.org)
674732dc751fbafbdb1e3fd4464d19e27e36607f.camel@student.tugraz.at
Hi everyone,

Am Dienstag, den 26.11.2019, 09:56 +0100 schrieb Ludovic Courtès:
Toggle quote (1 lines)
> are we not going overboard with that big a environment variable? :-)
I think I vaguely remember a related discussion about the Emacs build
system adding the guix.d directory, which further worsens this problem
[1]. Putting that aside however, $EMACSLOADPATH should not contain
more than
- $GUIX_PROFILE/share/emacs/$EMACS_VERSION/lisp
- $GUIX_PROFILE/share/emacs/$EMACS_VERSION/site-lisp
- $GUIX_PROFILE/share/emacs/site-lisp
If I read (elisp)Library Search correctly, these directories each
contain a file to add their subdirectories to the load-path variable.
This can be confirmed by searching in the store or through message-
debugging. It appears, however, that these files are not quite
sufficient. While the load-path is indeed modified, no autoloading
occurs for files inside guix.d -- indeed, I doubt it would occur for
any package, regardless of how we name it.

After further digging around, this appears to be a bug in guix-emacs.
Rather than using the load-path variable, it uses $EMACSLOADPATH
directly via getenv. I suggest either recursing into subdirectories as
Emacs itself would or using load-path instead of reverse engineering
it, preferring the latter if applicable.

Now that this has been cleared up, a fix should be in reach. First we
would fix guix-emacs, then we can restrict $EMACSLOADPATH to the above
three -- perhaps two, as the versioned site-lisp appears unused.

WDYT?

Regards,
Leo

[1] As I only vaguely remember it, I can not find a source for this.
However, the process that I've laid out should work fine with or
without guix.d
M
M
Maxim Cournoyer wrote on 27 Nov 2019 04:12
(name . Ludovic Courtès)(address . ludo@gnu.org)
87v9r6t3kv.fsf@gmail.com
Hello Ludovic,

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

Toggle quote (41 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> I could reproduce the gnome-session crash by generating a Guix VM with
>> the attached OS configuration (it has about 100 Emacs packages installed
>> to its system profile, which gives an EMACSLOADPATH length of about
>> 13000 characters), and got the following backtrace (no debugging
>> symbols):
>>
>> #0 0x00007ffff7837e27 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
>> #1 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
>> #2 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
>> [...]
>> #17435 0x00007ffff78467de in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
>> #17436 0x00007ffff783ac48 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
>> #17437 0x00007ffff78399c6 in match () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
>> #17438 0x00007ffff784a441 in pcre_exec () from /gnu/store/5j6w0x3aq0i5r9565w92lrh016vlmv2d-pcre-8.43/lib/libpcre.so.1
>> #17439 0x00007ffff7ceca8b in g_match_info_next () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
>> #17440 0x00007ffff7cee21f in g_regex_match_full () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
>> #17441 0x00007ffff7cee36a in g_regex_match () from /gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
>> #17442 0x000000000042b779 in gsm_util_export_activation_environment ()
>> #17443 0x000000000040adde in main ()
>>
>> This tells us that the problem originates from glib. Looking at the
>> number of match calls, libpcre is probably blowing up its stack as
>> described in this ticket [0]. According to this link, it seems glib
>> should be making use of PCRE's facilities to limit the depth of search,
>> e.g. by using "match limit" and "recursion limit" as documented here [1]
>> (search for "int pcre_exec(" on that page).
>>
>> Parallel to this, perhaps the regexp used by glib could be rewritten to
>> not rely as much on the stack.
>
> Oh great, thanks for investigating!
>
> I have a shallow understanding of the issues, but (1) are we not going
> overboard with that big a environment variable? :-), and (2) fixing GLib
> or PCRE would require a full rebuild, can you think of a way to work
> around the issue?

About (1); it's definitely bigger than others environment variables we
set in Guix (but not that different from PYTHONPATH when it is used on
the build side), but it hasn't posed a problem so far outside of glib.

I think having a recursive EMACSLOADPATH could be useful here and more
convenient for all Emacs users, so probably would be a welcome change in
upstream Emacs. That'd reduce the length of our EMACSLOADPATH greatly.

I'm also interested in studying if we could use package.el to do the
load the autoloads files and put the packages present under a directory
in the load-path of Emacs. It seems its variable `package-user-dir'
could play a role there.

About (2), I was thinking about using grafts -- IIUC this is one use
case where they can be useful (to fix a bug and avoid rebuilding many
packages).

Maxim
C
C
Clément Lassieur wrote on 27 Nov 2019 10:04
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87zhgh8zcb.fsf@lassieur.org
Clément Lassieur <clement@lassieur.org> writes:

Toggle quote (4 lines)
> Thanks for taking the time to look into this. I've seen your other
> email, you can install libpcre3-dbg to have PCRE's debug symbols. It
> might help.

I thought you were reproducing with Ubuntu.


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

Toggle quote (4 lines)
> About (2), I was thinking about using grafts -- IIUC this is one use
> case where they can be useful (to fix a bug and avoid rebuilding many
> packages).

This won't fix anything for users of foreign distros.
M
M
Maxim Cournoyer wrote on 27 Nov 2019 14:58
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
87o8wxto8o.fsf@gmail.com
Hello Leo!

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

Toggle quote (19 lines)
> Hi everyone,
>
> Am Dienstag, den 26.11.2019, 09:56 +0100 schrieb Ludovic Courtès:
>> are we not going overboard with that big a environment variable? :-)
> I think I vaguely remember a related discussion about the Emacs build
> system adding the guix.d directory, which further worsens this problem
> [1]. Putting that aside however, $EMACSLOADPATH should not contain
> more than
> - $GUIX_PROFILE/share/emacs/$EMACS_VERSION/lisp
> - $GUIX_PROFILE/share/emacs/$EMACS_VERSION/site-lisp
> - $GUIX_PROFILE/share/emacs/site-lisp
> If I read (elisp)Library Search correctly, these directories each
> contain a file to add their subdirectories to the load-path variable.
> This can be confirmed by searching in the store or through message-
> debugging. It appears, however, that these files are not quite
> sufficient. While the load-path is indeed modified, no autoloading
> occurs for files inside guix.d -- indeed, I doubt it would occur for
> any package, regardless of how we name it.

That's a precious find! I could validate your findings. The only place
we don't have a union of the Elisp directories (with a subdirs.el file)
is at build time, but in the event we'd stop producing guix.d the search
path would work natively there (as well as causing any newly installed
libraries to be found without any rescanning of directories).

Toggle quote (10 lines)
> After further digging around, this appears to be a bug in guix-emacs.
> Rather than using the load-path variable, it uses $EMACSLOADPATH
> directly via getenv. I suggest either recursing into subdirectories as
> Emacs itself would or using load-path instead of reverse engineering
> it, preferring the latter if applicable.
>
> Now that this has been cleared up, a fix should be in reach. First we
> would fix guix-emacs, then we can restrict $EMACSLOADPATH to the above
> three -- perhaps two, as the versioned site-lisp appears unused.

Neat! I find that this works best when guix.d is removed, as otherwise

1) relying on the load-path would mean we'd have to restart Emacs when
installed new libraries under guix.d directories (to have subdirs.el to
its magic and add them to the load-path)

2) the emacs-build-system simplifications that were made would need to
be reverted because at build time we don't have a profile with
subdirs.el readily available, and must manually hunt for the guix.d
subdirectories.

3) Even if we scanned directories recursively for autoloads from
EMACSLOADPATH ourselves in emacs-guix.el, a user would still need to
call the guix-emacs-autoload-packages manually after installing new
Elisp packages to have Emacs find them.

I've tested these changes with a Gnome VM and the EMACSLOADPATH is now
reduced to just the Emacs' lisp directory as well as the
share/emacs/site-lisp directory of any profile. Thanks for the great
ideas :-).

Some packages would need to be adapted to finalize the move to a
guix.d-less installation directory (some recipes refer to it), but this
is trivial to do. The documentation would need to be adapted as well.
I can take care of this if someones deems the attached patches fit to
fix the problems mentioned in this ticket.
From 6c2fcc4b6f4e8cf8e0b05858b2daa459cb390635 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Wed, 27 Nov 2019 13:40:20 +0900
Subject: [PATCH 2/6] gnu: emacs: Simplify the EMACSLOADPATH search path
specification.

The EMACSLOADPATH can be greatly simplified by relying on a subdirs.el file
that causes Emacs to search recursively a directory found in EMACSLOADPATH.

* gnu/packages/emacs.scm (emacs)[native-search-paths]: Remove the match-all
file pattern regexp. Remove the versioned site-lisp directory from searched
files, as it appears unused by Emacs.

Reported-by: Leo Prikler <leo.prikler@student.tugraz.at>
---
gnu/packages/emacs.scm | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

Toggle diff (21 lines)
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 16f9af0a0a..95859b8a88 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -186,11 +186,9 @@
(native-search-paths
(list (search-path-specification
(variable "EMACSLOADPATH")
- ;; The versioned entries are for the Emacs' builtin libraries.
- (files (list (string-append "share/emacs/" version "/site-lisp")
- (string-append "share/emacs/" version "/lisp")
- "share/emacs/site-lisp"))
- (file-pattern ".*")) ;recursively add any sub directory
+ ;; The versioned entry is for the Emacs' builtin libraries.
+ (files (list (string-append "share/emacs/" version "/lisp")
+ "share/emacs/site-lisp")))
(search-path-specification
(variable "INFOPATH")
(files '("share/info")))))
--
2.24.0
From 319b81ef8cbfd68c1c98fe644795ef28ad490bd9 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Wed, 27 Nov 2019 13:51:53 +0900
Subject: [PATCH 3/6] gnu: emacs: Fix guix-emacs.el indentation.

* gnu/packages/aux-files/emacs/guix-emacs.el: Fix indentation.
---
gnu/packages/aux-files/emacs/guix-emacs.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

Toggle diff (17 lines)
diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el b/gnu/packages/aux-files/emacs/guix-emacs.el
index 46ee557f20..b4315c1a2e 100644
--- a/gnu/packages/aux-files/emacs/guix-emacs.el
+++ b/gnu/packages/aux-files/emacs/guix-emacs.el
@@ -54,8 +54,8 @@ The files in the list do not have extensions (.el, .elc)."
(seq-filter (lambda (dir)
(string-match-p "/share/emacs/site-lisp" dir))
(split-string emacs-load-path ":")))
- (autoloads (mapcan #'guix-emacs-find-autoloads
- emacs-non-core-load-path-directories)))
+ (autoloads (mapcan #'guix-emacs-find-autoloads
+ emacs-non-core-load-path-directories)))
(mapc (lambda (f)
(load f 'noerror))
autoloads)))
--
2.24.0
From 3c8b5f63b2e34556463c22fa1565b46c1b31033c Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Wed, 27 Nov 2019 14:02:42 +0900
Subject: [PATCH 4/6] gnu: emacs: Use load-path instead of EMACSLOADPATH.

This enables the use of the subdirs.el feature of Emacs, where specifying a
directory in EMACSLOADPATH translates into a `load-path' variable containing
the directory and all its sub-directories.

* gnu/packages/aux-files/emacs/guix-emacs.el (guix-emacs-autoload-packages):
Use `load-path' directly instead of parsing EMACSLOADPATH.

Reported-by: Leo Prikler <leo.prikler@student.tugraz.at>
---
gnu/packages/aux-files/emacs/guix-emacs.el | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

Toggle diff (22 lines)
diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el b/gnu/packages/aux-files/emacs/guix-emacs.el
index b4315c1a2e..05fc9709b6 100644
--- a/gnu/packages/aux-files/emacs/guix-emacs.el
+++ b/gnu/packages/aux-files/emacs/guix-emacs.el
@@ -47,13 +47,12 @@ The files in the list do not have extensions (.el, .elc)."
;; FIXME: The autoloads generated by the emacs-build-system are not byte
;; compiled.
(interactive)
- (let* ((emacs-load-path (getenv "EMACSLOADPATH"))
- (emacs-non-core-load-path-directories
+ (let* ((emacs-non-core-load-path-directories
;; Filter out core Elisp directories, which are already autoloaded
;; by Emacs.
(seq-filter (lambda (dir)
(string-match-p "/share/emacs/site-lisp" dir))
- (split-string emacs-load-path ":")))
+ load-path))
(autoloads (mapcan #'guix-emacs-find-autoloads
emacs-non-core-load-path-directories)))
(mapc (lambda (f)
--
2.24.0
From baccbc37f60843f10e0bd384b5729e7670784b7a Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Wed, 27 Nov 2019 22:32:40 +0900
Subject: [PATCH 5/6] gnu: emacs-ert-runner: Fix build.

* gnu/packages/emacs-xyz.scm (emacs-ert-runner): Refer to the updated
installation directory.
---
gnu/packages/emacs-xyz.scm | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

Toggle diff (16 lines)
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 0caf12a423..7f140ad5de 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -9859,8 +9859,7 @@ Emacs.")
(substitute* "bin/ert-runner"
(("ERT_RUNNER=\"\\$\\(dirname \\$\\(dirname \\$0\\)\\)")
(string-append "ERT_RUNNER=\"" out
- "/share/emacs/site-lisp/guix.d/ert-runner-"
- ,version)))
+ "/share/emacs/site-lisp")))
(install-file "bin/ert-runner" (string-append out "/bin"))
(wrap-program (string-append out "/bin/ert-runner")
(list "EMACSLOADPATH" ":" 'prefix
--
2.24.0
From 0c7f859eff56d631ffe73227f012c6117040ade4 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Wed, 27 Nov 2019 22:34:44 +0900
Subject: [PATCH 6/6] gnu: emacs-emacsql: Fix build.

* gnu/packages/emacs-xyz.scm (emacs-emacsql): Refer to the updated
installation directory.
---
gnu/packages/emacs-xyz.scm | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

Toggle diff (16 lines)
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 7f140ad5de..a30685189b 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -11948,8 +11948,7 @@ object has been freed.")
(install-file "sqlite/emacsql-sqlite"
(string-append out "/bin"))
(for-each (cut install-file <>
- (string-append out "/share/emacs/site-lisp/guix.d/"
- "emacsql" "-" ,version))
+ (string-append out "/share/emacs/site-lisp"))
(find-files "." "\\.elc*$")))
#t)))))
(inputs
--
2.24.0
Maxim
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJ9WGpPiQCFQyn/CfEmDkZILmNWIFAl3egQcACgkQEmDkZILm
NWKnpA//R7Wo0YibMzNiqqmgcrpZw1wzMe+wredm/T+Dh1DzPm6glwahBDDHfw7j
PACf+fM4RXAb6fSMD0fH8r8J6X/1QbzNw7zspG46rSMD03H6zA08GhcYHkOFXcNr
CiMl5vOancEgqkE1gHQbss/irF2oBqYWVjfz7Czj6E8/6yQAHFr7RulKwvekhVwK
WWfi41WDaVMo3MLbRYdGQ/SPjkWzUjZ6M9f4s+z4FXBjfRbVx6ZYG9IBRVUpDk7X
DFQrvA2sObZZ+DFe2YNHcTAQlj8Yban4kM3iUNErzU4JeJzxn6uHcQAfjIvJe+FY
zFSa+YlWR8Ic/QDbpdDwOPMiEvohn75gr3dqICMf3C4Cj9an5Ypiwmv9szDI1Wff
qrXBJay1jOcK82INnUlDDpDY1YfOgaadn3mQH7bd9FJLgtQx76x8X2M269hlvelR
t2KmKRXRMqCKuoYOK0yZa2Vuo2tBlLRfMEV9Qn1CziHs7uESeejSbfLDXUPCjm58
6xXQT0MRuCmFm7lpSNiKkJ4GXkH7z1gaJ0Kkv1/xopGXhOtERgq6f7c/K1mQWXUB
sOy1VYbCuJ2cMUXkdve0pgAH6RE1p69cCICfrcmm4itjdsCd033RGZgbmn2nzCJI
KLBkcEkA7heJqnR/6ZOQF9y8YkwayCyIHZMOmhxkL9gXC6/OE2s=
=0jtx
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 27 Nov 2019 15:10
(name . Clément Lassieur)(address . clement@lassieur.org)
87h82ptnp4.fsf@gmail.com
Hello Clément,

clement@lassieur.org (Clément Lassieur) writes:

[...]

Toggle quote (14 lines)
>> If those affected judge the situation dire enough, I don't mind
>> reverting the changes to the Emacs library loading mechanism for the
>> time being.
>
> Please, do so :)
>
> Lots of users don't have that bug, but there's still a change in their
> workflow: they have to restart their session after installing new Emacs
> packages. Maybe when that bug is fixed and this set of patch is
> re-applied, there will be an opportunity to communicate about this? On
> info-guix maybe, or on 'guix pull'. It would explain the pros and cons
> of this new way of dealing with Emacs. I don't know if there was such
> an announcement already, I didn't see it. WDYT?

I was ready to revert the changes when I saw a reply from Leo Prikler in
this thread. They had really good ideas that I believe fix the
annoyances you reported about the recent changes, while preserving the
new plus points (per profile management of Emacs packages, 'guix
environment --ad-hoc' that works for Emacs, simplified build system).

Perhaps you could try it out and see if it indeed fixes the problems you
reported?

Thank you,

Maxim
C
C
Clément Lassieur wrote on 27 Nov 2019 15:15
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87d0ddpfqu.fsf@lassieur.org
Hi Maxim,

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

Toggle quote (9 lines)
> I was ready to revert the changes when I saw a reply from Leo Prikler in
> this thread. They had really good ideas that I believe fix the
> annoyances you reported about the recent changes, while preserving the
> new plus points (per profile management of Emacs packages, 'guix
> environment --ad-hoc' that works for Emacs, simplified build system).
>
> Perhaps you could try it out and see if it indeed fixes the problems you
> reported?

Sure! I'll try this as soon as possible and get back to you. Thank
you!

Clément
J
J
Jelle Licht wrote on 27 Nov 2019 15:21
(address . 38309@debbugs.gnu.org)
87blsxwgb9.fsf@jlicht.xyz
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (6 lines)
> [...]
> I've tested these changes with a Gnome VM and the EMACSLOADPATH is now
> reduced to just the Emacs' lisp directory as well as the
> share/emacs/site-lisp directory of any profile. Thanks for the great
> ideas :-).

Would this still allow Emacs to load packages from Guix' environments as well?
C
C
Clément Lassieur wrote on 27 Nov 2019 18:30
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87imn5p6qs.fsf@lassieur.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (9 lines)
> I was ready to revert the changes when I saw a reply from Leo Prikler in
> this thread. They had really good ideas that I believe fix the
> annoyances you reported about the recent changes, while preserving the
> new plus points (per profile management of Emacs packages, 'guix
> environment --ad-hoc' that works for Emacs, simplified build system).
>
> Perhaps you could try it out and see if it indeed fixes the problems you
> reported?

I just tried it, and except a build error with emacs-magit-todos[1], it
works very well! Things installed with 'guix package -i' get loaded on
Emacs reboot, which is great in my opinion.

Thanks again,
Clément

[1]:
Toggle snippet (8 lines)
Checking /gnu/store/81a9rjhsw7rh9pc5a121j65107vngyz8-emacs-magit-todos-1.4/share/emacs/site-lisp/...
Compiling /gnu/store/81a9rjhsw7rh9pc5a121j65107vngyz8-emacs-magit-todos-1.4/share/emacs/site-lisp/magit-todos-autoloads.el...
Compiling /gnu/store/81a9rjhsw7rh9pc5a121j65107vngyz8-emacs-magit-todos-1.4/share/emacs/site-lisp/magit-todos.el...
Cannot open load file: No such file or directory, transient
command "/gnu/store/2iaibkz1q8xmrqr1pr6ksijw5ifny0fn-emacs-minimal-26.3/bin/emacs" "--quick" "--batch" "--eval=(progn (setq byte-compile-debug t) (byte-recompile-directory (file-name-as-directory \"/gnu/store/81a9rjhsw7rh9pc5a121j65107vngyz8-emacs-magit-todos-1.4/share/emacs/site-lisp\") 0 1))" failed with status 255
builder for `/gnu/store/vadbvc79isvvy0wjyx5i0rbr2gr7xlab-emacs-magit-todos-1.4.drv' failed with exit code 1
build of /gnu/store/vadbvc79isvvy0wjyx5i0rbr2gr7xlab-emacs-magit-todos-1.4.drv failed
M
M
Maxim Cournoyer wrote on 28 Nov 2019 06:28
(name . Jelle Licht)(address . jlicht@fsfe.org)
8736e8tvrg.fsf@gmail.com
Hello,

Jelle Licht <jlicht@fsfe.org> writes:

Toggle quote (10 lines)
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> [...]
>> I've tested these changes with a Gnome VM and the EMACSLOADPATH is now
>> reduced to just the Emacs' lisp directory as well as the
>> share/emacs/site-lisp directory of any profile. Thanks for the great
>> ideas :-).
>
> Would this still allow Emacs to load packages from Guix' environments as well?

Yes, and directly handled by Guix search path machinery, as in:

guix environment --pure --ad-hoc emacs emacs-magit -- emacs

--> Magit available in that Emacs instance spawned from that
environment, given that EMACSLOADPATH has been set correctly.

Maxim
C
C
Clément Lassieur wrote on 2 Dec 2019 11:36
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87v9qzypxa.fsf@lassieur.org
Hello Maxim,

Any update about this? Any plan to push a fix or a revert? I've been
using your new patches without any issue for a few days already.

Thanks,
Clément
A
A
Arne Babenhauserheide wrote on 3 Dec 2019 10:38
(address . bug-guix@gnu.org)
877e3dda04.fsf@web.de
Clément Lassieur <clement@lassieur.org> writes:
Toggle quote (3 lines)
> Any update about this? Any plan to push a fix or a revert? I've been
> using your new patches without any issue for a few days already.

This would also be important for me. I’m currently forced to use xfce
due to this bug, and that hinders me quite a bit, for example because it
catches key-combinations I need to pass to the IDE.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl3mLR8ACgkQE++NRSQD
w+v2ChAAoVvkdcX2xTrYkBbh8B+9pfC3MunyCHtb3CF5Qv+AaOsztDTXcHGZF+fL
DGWkfrTDsuouCL4ypoWcLagZlicfrq0KFFPrajm0CWukp9ZMsF9b1ZZCed+3Btwk
m6xqM/QIfiloQT2YZbvYrP9MDCnLfusVXwtL7u0NKLJOEBaDMMmbrWUuhhFDNL+J
I79HH7oUxl5ZYiZJIUivNtzcvdBJRyBcmk5gEWGF0WpzxeEsXcDuX5gmq6515tK+
2vSYw352wwnS+5tQyhjFdS9pLzsfCgEi7aoX0Vfq1E/7iRG8Aw5RkouCH06UoUp4
AnuZk3DCTjHZRv5KUO5Lh6arFjcxV0wNTKLQGtP16sk7eLVxY7FIJ9E082ZYwiVq
QR1p9Q5iv1BRNIISMEuP7yFFO4BkRaX288v79v6gjRPS0O79qpBXOabyN79GbolG
7kE4VUmAhCEGkcvNWzIAbwKKESWlAKRNMiAAH2PxFsHF0R0E+vXPty+b7jGUn+Fd
gmrcjGoR+oduU6ahXo+gdS6fEGCjfPUs79QxfZ3vbZ/wwtKIee7/4vHUc/IvMmOh
5VfkgIrP+tIljRURCbtsUPvUMVeILh+davHomQs341i5Axy8PHoUtbUHQo+ViVC3
st5bk0/Tu1+yh0ZdcXwfkUWX03UrGTFb/YItUDXu4KnUI5RBOk+IswQBAQgAHRYh
BN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd5i0fAAoJENzPDbMLwQVIJlMD/06VPLVB
/mjGdtM4gh8c0uMcpnanpqKkJZ9sDAGpzinbgh5dOiQYHXFll5RIhdioua541mVA
teAwb/xH8K/YOTyxL9Y9IlRth8CyY6UykgoBcsrZOXUm5GfEIfUsitm5/EvUMUWt
FitGQpX6m7m1KuTZ/le5OynWsmG/9H82SHvk
=QiBc
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 4 Dec 2019 10:14
(name . Clément Lassieur)(address . clement@lassieur.org)
87lfrse9ku.fsf@gnu.org
Hi!

clement@lassieur.org (Clément Lassieur) skribis:

Toggle quote (3 lines)
> Any update about this? Any plan to push a fix or a revert? I've been
> using your new patches without any issue for a few days already.

I agree that a solution needs to be implemented now, it’s not cool to
leave fellow GNOME users without Emacs for several days. :-)

Clément, perhaps you can push the patches now on behalf of Maxim?
If Maxim eventually comes up and disagrees, we can always adjust.
At any rate, it’s better than leaving the thing broken.

Thanks,
Ludo’.
C
C
Clément Lassieur wrote on 4 Dec 2019 11:14
87sgm0gzyj.fsf@lassieur.org
Hi Ludo and Maxim,

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

Toggle quote (14 lines)
> Hi!
>
> clement@lassieur.org (Clément Lassieur) skribis:
>
>> Any update about this? Any plan to push a fix or a revert? I've been
>> using your new patches without any issue for a few days already.
>
> I agree that a solution needs to be implemented now, it’s not cool to
> leave fellow GNOME users without Emacs for several days. :-)
>
> Clément, perhaps you can push the patches now on behalf of Maxim?
> If Maxim eventually comes up and disagrees, we can always adjust.
> At any rate, it’s better than leaving the thing broken.

I pushed them, and I'm closing the bug. Thank you Maxim for those
patches, and I hope you'll be back soon to keep hacking on Guix and
Emacs!

Clément
Closed
A
A
Arne Babenhauserheide wrote on 4 Dec 2019 12:11
(address . bug-guix@gnu.org)
87y2vs73c7.fsf@web.de
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (3 lines)
> I agree that a solution needs to be implemented now, it’s not cool to
> leave fellow GNOME users without Emacs for several days. :-)

That did not leave me without Emacs. It left me without GNOME.

Priorities! :-)

(I cannot work without Emacs. It has all my planning and time tracking)

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl3nlFoACgkQE++NRSQD
w+sZOA//bekh+jEOIH8+w+4mEzJzb5W1W7pfd7kFUpSH4UqUh1OImDVknddTHeNY
ATONYGQ3tR5hYcqjfwPvXNwmUoQr2+QsT5WZBXWwNH6o4Bo9GC7RTLmL6rXOcpui
ltj6xt7mL2NQZgSYNGfWSYIMZxm5XSziA66tVWdzqJh07JfQd7NMOxtY0iXqfFLf
x5ICULBlga1Re+dBOPOhWcqP15EtWRwf91Oq60wdkiwtYlF9aL4KpGe9WsCvEUxM
Wa9UEpDrxIdqynmLM2JmGfBITW26OOLGYxmJ35b7SWAeFQ7GCsdHu2XGRM/hfXmA
ytZDAJlAU5PktR6KRiEm7EzKIVMj1zrUvOzqMc2qgLUc4Qt6oe9E1Ypw2XMlz7aM
z7zhxXT69DXiHKUfmHO94ZU2SfdMU3k0vmolrnzdVkHcH3q9A+Bi7DsqBljcKA9v
wBEO9E6wYbnK2Ugztz6k1Rxh0JhA/C/oIpOw6niSAlB9BP2HUevcPzLZ0ZveDJKO
MwEbrAUZokWa9/ZZv8yrabha7bUk+ernIbxmQxirYsFn/m6xUYObLYV+lbT1HexR
P8G9BkBSz+kGXJyF/zF5BONolyFEQu+8xeu+u64CjhNUANbbjxNxf87sDAfZePiP
EyZcDRiUE1647vrICxsqb3DlHBd2xG7H1hPxR/Fwh/mmTPq0PiWIswQBAQgAHRYh
BN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd55RbAAoJENzPDbMLwQVIzvAD/0y5lS/R
psr97xKkLIVE3YSAIRm9j0oX5IIWdpYJZppizpfjtyqjPhbkzuTTFwOzOpXml0OX
2URwO+1OUzv5YxTt/lqar/2lRecn2CBbFEmLM6d5nXBS5MVX5WidyvxwYfXdQ4p2
qJ8MYIQG7iGbTNxpAj+Fxy+cNW2cA1zY3SJ4
=05uw
-----END PGP SIGNATURE-----

A
A
Arne Babenhauserheide wrote on 4 Dec 2019 13:31
(address . bug-guix@gnu.org)
87wobc6zmw.fsf@web.de
Clément Lassieur <clement@lassieur.org> writes:
Toggle quote (8 lines)
>> Clément, perhaps you can push the patches now on behalf of Maxim?
>> If Maxim eventually comes up and disagrees, we can always adjust.
>> At any rate, it’s better than leaving the thing broken.
>
> I pushed them, and I'm closing the bug. Thank you Maxim for those
> patches, and I hope you'll be back soon to keep hacking on Guix and
> Emacs!

Thank you!

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl3npxkACgkQE++NRSQD
w+vS6g/+KD6Y8+Rq00Ml/5NHfD4E79wjyfWX0H/96lkrKpDgCJzmgpIRh6qEk8YB
I0UlqcS/v0GfQJG7wH3o6oEBnRjUNkBX7mpVlSra8A64BgKufPMlre00MUww6lIv
rANPEaGCeVm1bGMgcSeIBKP23qKTMQpab06e1n7CHVijHwrelkxtJgX4Uf8Uc5ZU
Pw69m4hjiuiN4YEkYAA6HIjro6s460peg2nolsm7K2fdmmoWeVjYzMiGoyqxQeMt
pHUkBF6pPO/DLMa339G1OtjjLKJobvsScQG9zkO/PvUbwnUIaKX3yGwmP8+Rtaux
p7Apf6PS7X19pX1cVSjjuZHgfdtj001y465YDe8cPZpQObP9aDH0S7pXGLSFZDBG
njJ+6PP16GFzzsFMyAO/XEA86A0RUo8UMYlRlc3OWwFZyPpq2DDX/bLmbXvyZ+gv
pUqBr6snj7Phz9FgcRXScpFyPkvmtSM3WxD6YL7y6RQrPXbHIG579I5d+/iEd5J6
cD/IUA6GWD9LW+NLEILY+REW9t7SiySWQQ5DbG6EJ5FYur/KazL32Axhbl0Vckil
qByOAs1R19spx/eO8xGuTZNlo1QnPfvu8FAkMqQGryPbKYFyhhu9VG1thfDHbDnK
eCbwen5IGGhsTkTJRbrCvKCMpLdc0l6yo60WS0SfojPkvKcBonKIswQBAQgAHRYh
BN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd56cZAAoJENzPDbMLwQVIyHwD/2HH3nbV
mf3RnfMZKacMVyPBcU88b4qgS2pZDYR2+vnVe4/WZrSy/r3B81cN23OJsLeXcqhJ
IJ7/3B7T7hwVG6obdLSc5smDHeyuI3r7J+nWcO6qv0Ex95iZIirgzf4W7GQzd4Rw
LAtB4wP2Cz8BXv9dPefcysWZOOmCk94LDfNg
=aJE6
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 6 Dec 2019 18:02
(name . Arne Babenhauserheide)(address . arne_bab@web.de)
871rths7zk.fsf@gmail.com
Hello everyone,

Arne Babenhauserheide <arne_bab@web.de> writes:

Toggle quote (9 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> I agree that a solution needs to be implemented now, it’s not cool to
>> leave fellow GNOME users without Emacs for several days. :-)
>
> That did not leave me without Emacs. It left me without GNOME.
>
> Priorities! :-)

Haha!

Toggle quote (5 lines)
> (I cannot work without Emacs. It has all my planning and time tracking)
>
> Best wishes,
> Arne

Sorry for the delays -- just wanted to say: I have another set of
patches that will allow continuing to use the guix.d subdirectory, as
well as allowing to reload newly installed packages on the fly.

It uses a hybrid of techniques found in the previous and current
site-start.el, and uses a custom GUIX_EMACSLOADPATH instead of
EMASCLOADPATH for full control of the load path without interference
from Emacs default behavior.

I'll post the new patches to "guix-patches", after I'll have them
rebased on what's in master.

A particular thank you to Clément for spending time testing (and
pushing) the reworked patches authored by the one who broke their setup
;-).

Maxim
A
A
Arne Babenhauserheide wrote on 7 Dec 2019 17:18
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87sglw153n.fsf@web.de
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (4 lines)
> Sorry for the delays -- just wanted to say: I have another set of
> patches that will allow continuing to use the guix.d subdirectory, as
> well as allowing to reload newly installed packages on the fly.

Sounds good. Thank you for improving the Emacs integration in Guix!

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl3r0O8ACgkQE++NRSQD
w+sPEw/+J2DKjcvvQtMZFgmPmiMygZBrv5dgQ05nOSuWCWQxOilQ89ehNSWV1NN+
HTFQnGswPcyz7hPTaDzD8Esuac0+qlFJH3FihLvV7dbjZ13LpJDheyTRzmHEJ81v
LX8rMk0ONfZTIlCWIqYeBimc3ReCg9a8NGgI1v69N/Si1XmnIVYOCeuWQiYLR7WH
Y+w2ETSDyS7v/PyBQvyTYWM0mS5srtSxWr/WknQ23WvkZvjNPIaIcW49UDOxbSPI
XNDZeiNqz/jgGgGbqpyEE7D1D0u+ASiK8XLYORLtUxk4Vc1eo8f42zDvcbQrIP7R
wKzorX/WgGve730MwoCfO7+tScZf9IRe1sgSF03NMf2CzdHSrDCNFgsZGeH3oNva
zuHbsjCQAZ7+msyltS4cmOFqKtciOFDPJMX4hwin6JJXuvPYnXVeqNaOq0Ce0YlF
X7tVN4ap3iLayBFVVA28BJDWVHXC3fC4Yuwc57GqfKcWiqzx/PxCVnORliqAnCwm
Pw015gjS9PTJ1WcxXFDlrW49qQjdc2HKkEVwvjH1vuXOGvcxcrygOzf/QIDkwNLP
BMPdNdw5V7qS/Et598AGXT7h/CCO5I49WcuJqnx76enneaO3gRt8Q7ZDS7LJ2Tt3
fCzaW/QrT12yPH8VNXsfz4gDikVAu3fiokMjZshOt+xE5xNpB2GIswQBAQgAHRYh
BN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd69DyAAoJENzPDbMLwQVIrE0EAIe5BgeT
vFx7e+4pQAZwLlFiMKp0EZBmjZgJ8BztwDSUTliJpqf1tEES4oWi88OeaLtgvjLM
Drq9pnDdxWVcYCEXnT8I4WqOMo3ZLoubHeUBJ/k0KRE0+HbrF8PWdvG9HX/RmA/z
1U3gw9GuTq2sNZkOPD8rjilub81rv3/3KjSk
=/a+D
-----END PGP SIGNATURE-----

?