GNU bug report logs - #38309
Recent $EMACSLOADPATH changes crash gnome-session

Previous Next

Package: guix;

Reported by: "Alex Griffin" <a <at> ajgrf.com>

Date: Thu, 21 Nov 2019 02:27:01 UTC

Severity: serious

Done: clement <at> lassieur.org (Clément Lassieur)

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Thu, 21 Nov 2019 02:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Alex Griffin" <a <at> ajgrf.com>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Thu, 21 Nov 2019 02:27:04 GMT) Full text and rfc822 format available.

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

From: "Alex Griffin" <a <at> ajgrf.com>
To: bug-guix <at> gnu.org
Subject: Recent $EMACSLOADPATH changes crash gnome-session
Date: Thu, 21 Nov 2019 02:25:33 +0000
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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Fri, 22 Nov 2019 13:02:01 GMT) Full text and rfc822 format available.

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

From: clement <at> lassieur.org (Clément Lassieur)
To: Alex Griffin <a <at> ajgrf.com>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 38309 <at> debbugs.gnu.org
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Fri, 22 Nov 2019 14:00:45 +0100
[Message part 1 (text/plain, inline)]
"Alex Griffin" <a <at> ajgrf.com> writes:

> 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:

--8<---------------cut here---------------start------------->8---
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]
--8<---------------cut here---------------end--------------->8---

Guix version:

--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---

With an up-to-date Ubuntu 18.04.3 LTS.

Cheers,
Clément
[log (application/octet-stream, attachment)]

Severity set to 'serious' from 'normal' Request was from clement <at> lassieur.org (Clément Lassieur) to control <at> debbugs.gnu.org. (Fri, 22 Nov 2019 13:02:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Fri, 22 Nov 2019 13:16:02 GMT) Full text and rfc822 format available.

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

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: bug-guix <at> gnu.org
Cc: Alex Griffin <a <at> ajgrf.com>, 38309 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Fri, 22 Nov 2019 14:15:31 +0100
Hello,

> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Fri, 22 Nov 2019 13:16:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Fri, 22 Nov 2019 17:42:01 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: Alex Griffin <a <at> ajgrf.com>, bug-guix <at> gnu.org, 38309 <at> debbugs.gnu.org
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Sat, 23 Nov 2019 02:40:51 +0900
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.

[0]  https://aplawrence.com/Unixart/variable_limits.html
[1]  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38273#34

Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Fri, 22 Nov 2019 17:42:05 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Sat, 23 Nov 2019 18:06:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Sat, 23 Nov 2019 19:05:10 +0100
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> 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’.




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Sun, 24 Nov 2019 03:47:04 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Sun, 24 Nov 2019 12:45:51 +0900
Hello,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> 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:

--8<---------------cut here---------------start------------->8---
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.
--8<---------------cut here---------------end--------------->8---

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

[0]  https://bugzilla.redhat.com/show_bug.cgi?id=1430103




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Mon, 25 Nov 2019 15:30:03 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Sun, 24 Nov 2019 18:56:16 +0100
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> 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.

WDYT?

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Mon, 25 Nov 2019 17:25:02 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Tue, 26 Nov 2019 02:23:55 +0900
Hello Ludovic,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Tue, 26 Nov 2019 04:05:02 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Tue, 26 Nov 2019 13:04:00 +0900
Hello again,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> 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):

--8<---------------cut here---------------start------------->8---
#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 ()
--8<---------------cut here---------------end--------------->8---

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.

[0]  https://bugs.exim.org/show_bug.cgi?id=2126
[1]  https://pcre.org/original/doc/html/pcreapi.html




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Tue, 26 Nov 2019 08:57:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Tue, 26 Nov 2019 09:56:22 +0100
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> 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?

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Tue, 26 Nov 2019 09:21:02 GMT) Full text and rfc822 format available.

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

From: clement <at> lassieur.org (Clément Lassieur)
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Tue, 26 Nov 2019 10:20:46 +0100
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 <at> gmail.com> writes:

> Hello Ludovic,
>
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer <at> 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?

>> 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.

> 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.

> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Tue, 26 Nov 2019 09:31:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: clement <at> lassieur.org (Clément Lassieur)
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Tue, 26 Nov 2019 10:30:11 +0100
Hello,

clement <at> lassieur.org (Clément Lassieur) skribis:

> 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’.




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Tue, 26 Nov 2019 09:44:02 GMT) Full text and rfc822 format available.

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

From: clement <at> lassieur.org (Clément Lassieur)
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Tue, 26 Nov 2019 10:43:37 +0100
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hello Ludovic,
>
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer <at> 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.

> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 27 Nov 2019 00:02:02 GMT) Full text and rfc822 format available.

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

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: ludo <at> gnu.org
Cc: 38309 <at> debbugs.gnu.org
Subject: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 27 Nov 2019 01:01:31 +0100
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.

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





Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 27 Nov 2019 03:13:01 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 27 Nov 2019 12:12:32 +0900
Hello Ludovic,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 27 Nov 2019 09:05:02 GMT) Full text and rfc822 format available.

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

From: clement <at> lassieur.org (Clément Lassieur)
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 27 Nov 2019 10:04:20 +0100
Clément Lassieur <clement <at> lassieur.org> writes:
(in https://lists.gnu.org/archive/html/bug-guix/2019-11/msg00363.html)

> 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 <at> gmail.com> writes:

> 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.




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 27 Nov 2019 13:59:02 GMT) Full text and rfc822 format available.

Message #61 received at 38309 <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: ludo <at> gnu.org, 38309 <at> debbugs.gnu.org
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 27 Nov 2019 22:58:31 +0900
[Message part 1 (text/plain, inline)]
Hello Leo!

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

> 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).

> 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.

[0001-build-emacs-build-system-Unify-the-installation-dire.patch (text/x-patch, attachment)]
[0002-gnu-emacs-Simplify-the-EMACSLOADPATH-search-path-spe.patch (text/x-patch, attachment)]
[0003-gnu-emacs-Fix-guix-emacs.el-indentation.patch (text/x-patch, attachment)]
[0004-gnu-emacs-Use-load-path-instead-of-EMACSLOADPATH.patch (text/x-patch, attachment)]
[0005-gnu-emacs-ert-runner-Fix-build.patch (text/x-patch, attachment)]
[0006-gnu-emacs-emacsql-Fix-build.patch (text/x-patch, attachment)]
[Message part 8 (text/plain, inline)]
Maxim

[vm-desktop-config.scm (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 27 Nov 2019 14:11:01 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: clement <at> lassieur.org (Clément Lassieur)
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 27 Nov 2019 23:10:15 +0900
Hello Clément,

clement <at> lassieur.org (Clément Lassieur) writes:

[...]

>> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 27 Nov 2019 14:16:02 GMT) Full text and rfc822 format available.

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

From: Clément Lassieur <clement <at> lassieur.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 27 Nov 2019 15:15:37 +0100
Hi Maxim,

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

> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 27 Nov 2019 14:22:02 GMT) Full text and rfc822 format available.

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

From: Jelle Licht <jlicht <at> fsfe.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 38309 <at> debbugs.gnu.org
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 27 Nov 2019 15:21:30 +0100
Maxim Cournoyer <maxim.cournoyer <at> 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?





Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 27 Nov 2019 17:31:01 GMT) Full text and rfc822 format available.

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

From: Clément Lassieur <clement <at> lassieur.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Mathieu Othacehe <m.othacehe <at> gmail.com>, 38309 <at> debbugs.gnu.org, a <at> ajgrf.com
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 27 Nov 2019 18:30:03 +0100
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> 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]:
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Thu, 28 Nov 2019 05:29:01 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Jelle Licht <jlicht <at> fsfe.org>
Cc: Leo Prikler <leo.prikler <at> student.tugraz.at>, 38309 <at> debbugs.gnu.org
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Thu, 28 Nov 2019 14:28:19 +0900
Hello,

Jelle Licht <jlicht <at> fsfe.org> writes:

> Maxim Cournoyer <maxim.cournoyer <at> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Mon, 02 Dec 2019 10:37:02 GMT) Full text and rfc822 format available.

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

From: clement <at> lassieur.org (Clément Lassieur)
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: ludo <at> gnu.org, Leo Prikler <leo.prikler <at> student.tugraz.at>,
 38309 <at> debbugs.gnu.org
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Mon, 02 Dec 2019 11:36:49 +0100
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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Tue, 03 Dec 2019 09:39:01 GMT) Full text and rfc822 format available.

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

From: Arne Babenhauserheide <arne_bab <at> web.de>
To: bug-guix <at> gnu.org
Cc: Leo Prikler <leo.prikler <at> student.tugraz.at>, 38309 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Tue, 03 Dec 2019 10:38:35 +0100
[Message part 1 (text/plain, inline)]
Clément Lassieur <clement <at> lassieur.org> writes:
> 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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Tue, 03 Dec 2019 09:40:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 04 Dec 2019 09:16:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: clement <at> lassieur.org (Clément Lassieur)
Cc: Leo Prikler <leo.prikler <at> student.tugraz.at>, 38309 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 04 Dec 2019 10:14:41 +0100
Hi!

clement <at> 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.

Thanks,
Ludo’.




Reply sent to clement <at> lassieur.org (Clément Lassieur):
You have taken responsibility. (Wed, 04 Dec 2019 10:15:02 GMT) Full text and rfc822 format available.

Notification sent to "Alex Griffin" <a <at> ajgrf.com>:
bug acknowledged by developer. (Wed, 04 Dec 2019 10:15:02 GMT) Full text and rfc822 format available.

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

From: clement <at> lassieur.org (Clément Lassieur)
To: Ludovic Courtès <ludo <at> gnu.org>,  Maxim Cournoyer
 <maxim.cournoyer <at> gmail.com>
Cc: Leo Prikler <leo.prikler <at> student.tugraz.at>, 38309-done <at> debbugs.gnu.org
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 04 Dec 2019 11:14:12 +0100
Hi Ludo and Maxim,

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

> Hi!
>
> clement <at> 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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 04 Dec 2019 11:12:01 GMT) Full text and rfc822 format available.

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

From: Arne Babenhauserheide <arne_bab <at> web.de>
To: bug-guix <at> gnu.org
Cc: Leo Prikler <leo.prikler <at> student.tugraz.at>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 Clément Lassieur <clement <at> lassieur.org>,
 38309 <at> debbugs.gnu.org
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 04 Dec 2019 12:11:20 +0100
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> 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! :-)

(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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 04 Dec 2019 11:12:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 04 Dec 2019 12:32:02 GMT) Full text and rfc822 format available.

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

From: Arne Babenhauserheide <arne_bab <at> web.de>
To: bug-guix <at> gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Leo Prikler <leo.prikler <at> student.tugraz.at>, 38309-done <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Wed, 04 Dec 2019 13:31:19 +0100
[Message part 1 (text/plain, inline)]
Clément Lassieur <clement <at> lassieur.org> writes:
>> 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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Wed, 04 Dec 2019 12:32:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Fri, 06 Dec 2019 17:03:02 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Arne Babenhauserheide <arne_bab <at> web.de>
Cc: Leo Prikler <leo.prikler <at> student.tugraz.at>, bug-guix <at> gnu.org,
 38309 <at> debbugs.gnu.org,
 Clément Lassieur <clement <at> lassieur.org>
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Sat, 07 Dec 2019 02:02:07 +0900
Hello everyone,

Arne Babenhauserheide <arne_bab <at> web.de> writes:

> Ludovic Courtès <ludo <at> 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!

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




Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Fri, 06 Dec 2019 17:03:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Sun, 08 Dec 2019 02:47:01 GMT) Full text and rfc822 format available.

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

From: Arne Babenhauserheide <arne_bab <at> web.de>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Leo Prikler <leo.prikler <at> student.tugraz.at>, bug-guix <at> gnu.org,
 38309 <at> debbugs.gnu.org,
 Clément Lassieur <clement <at> lassieur.org>
Subject: Re: bug#38309: Recent $EMACSLOADPATH changes crash gnome-session
Date: Sat, 07 Dec 2019 17:18:52 +0100
[Message part 1 (text/plain, inline)]
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> 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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#38309; Package guix. (Sun, 08 Dec 2019 06:16:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 05 Jan 2020 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 84 days ago.

Previous Next


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