Recent $EMACSLOADPATH changes crash gnome-session

DoneSubmitted by Alex Griffin.
Details
8 participants
  • Alex Griffin
  • Arne Babenhauserheide
  • Clément Lassieur
  • Jelle Licht
  • Leo Prikler
  • Ludovic Courtès
  • Mathieu Othacehe
  • Maxim Cournoyer
Owner
unassigned
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 -c22525
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 toadd an Emacs package is to reboot.
In case it's not clear: Booting works, but restarting the sessioncrashes.
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 seriousquit
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 torestart 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 wouldbe an issue though, given that that's probably around 22 KiB of memoryand some people tested huge variables (>18 MiB) without facing any hardlimit other than RAM [0].
Which leads me to suspect that the problem might be Gnome specific? Ihaven't experienced it, but then my EMACSLOADPATH variable is only about7000 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 whatgnome-session does and why it crashes on larger than average environmentvariables.
I believe the "enhancement" #1 (to deprecate guix.d subdirectories) inXFCE?) as explained in bug #38273 [1] could lead to a much leanerEMACSLOADPATH, by reducing the number of entries necessary to refer toall the Elisp packages.
[0] https://aplawrence.com/Unixart/variable_limits.html[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38273#34
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 canaddress this without pressure in the meantime?
I think I missed the discussions around this patch, but we should getAlex Kost into the loop (Alex did the initial work in that area, if I’mnot 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 undothe changes (one to the build system, others to adapt the renaming ofthe 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 recentversions PCRE, that trigger a crash on large environment variables asreported in [0]. There's a new version of PCRE2 (10.34) available; butI'm unsure if it addresses this particular problem:https://pcre.org/changelog.txt. If it doesn't we should report theproblem to them.
This could happen with any other environment variable thanEMACSLOADPATH; it's just a matter of having an environment variable growsufficiently long to trigger it.
I'm testing a patch that may workaround this problem successfully rightnow (that would reduce the length of EMACSLOADPATH) I'll send anincomplete patch shortly for discussing the idea or testing. In caseit's not clear; I'd rather workaround the issue or have it fixed at itssource, ideally.
WDYT?
Maxim
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1430103
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 reasonsfor the regression, but IIUC, the regression is serious enough that weshould 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 thoseaffected by the problem could produce one, that'd help pinpoint theproblematic call to PCRE and its origin), but that'll need some moretime.
If those affected judge the situation dire enough, I don't mindreverting the changes to the Emacs library loading mechanism for thetime 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 withthe attached OS configuration (it has about 100 Emacs packages installedto its system profile, which gives an EMACSLOADPATH length of about13000 characters), and got the following backtrace (no debuggingsymbols):
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 thenumber of match calls, libpcre is probably blowing up its stack asdescribed in this ticket [0]. According to this link, it seems glibshould 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 tonot 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
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 goingoverboard with that big a environment variable? :-), and (2) fixing GLibor PCRE would require a full rebuild, can you think of a way to workaround 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 otheremail, you can install libpcre3-dbg to have PCRE's debug symbols. Itmight 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 packagesinstalled. Now I have to reboot my computer every time I 'guix package-i emacs-something'. Emacs is central to my workflow and I often changethings 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 landonto 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 theirworkflow: they have to restart their session after installing new Emacspackages. Maybe when that bug is fixed and this set of patch isre-applied, there will be an opportunity to communicate about this? Oninfo-guix maybe, or on 'guix pull'. It would explain the pros and consof this new way of dealing with Emacs. I don't know if there was suchan 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 ifEmacs-Guix knows how to deal with that (until now it was able todirectly load Emacs packages you’d install with itself).
I think I would lean towards a revert (that is, a single commitreverting the 3 (?) patches that implement this new approach).
Then we can discuss the change with less pressure and make surestakeholders weigh in (they could have done that before but apparentlymany, 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?) ofthem won't know about it and will spend a lot of time (as I did) tryingto 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 buildsystem adding the guix.d directory, which further worsens this problem[1]. Putting that aside however, $EMACSLOADPATH should not containmore than- $GUIX_PROFILE/share/emacs/$EMACS_VERSION/lisp- $GUIX_PROFILE/share/emacs/$EMACS_VERSION/site-lisp- $GUIX_PROFILE/share/emacs/site-lispIf I read (elisp)Library Search correctly, these directories eachcontain 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 quitesufficient. While the load-path is indeed modified, no autoloadingoccurs for files inside guix.d -- indeed, I doubt it would occur forany 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 $EMACSLOADPATHdirectly via getenv. I suggest either recursing into subdirectories asEmacs itself would or using load-path instead of reverse engineeringit, preferring the latter if applicable.
Now that this has been cleared up, a fix should be in reach. First wewould fix guix-emacs, then we can restrict $EMACSLOADPATH to the abovethree -- 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 orwithout 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 weset in Guix (but not that different from PYTHONPATH when it is used onthe 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 moreconvenient for all Emacs users, so probably would be a welcome change inupstream Emacs. That'd reduce the length of our EMACSLOADPATH greatly.
I'm also interested in studying if we could use package.el to do theload the autoloads files and put the packages present under a directoryin 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 usecase where they can be useful (to fix a bug and avoid rebuilding manypackages).
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:(in https://lists.gnu.org/archive/html/bug-guix/2019-11/msg00363.html)
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 placewe 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 searchpath would work natively there (as well as causing any newly installedlibraries 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 wheninstalled new libraries under guix.d directories (to have subdirs.el toits magic and add them to the load-path)
2) the emacs-build-system simplifications that were made would need tobe reverted because at build time we don't have a profile withsubdirs.el readily available, and must manually hunt for the guix.dsubdirectories.
3) Even if we scanned directories recursively for autoloads fromEMACSLOADPATH ourselves in emacs-guix.el, a user would still need tocall the guix-emacs-autoload-packages manually after installing newElisp packages to have Emacs find them.
I've tested these changes with a Gnome VM and the EMACSLOADPATH is nowreduced to just the Emacs' lisp directory as well as theshare/emacs/site-lisp directory of any profile. Thanks for the greatideas :-).
Some packages would need to be adapted to finalize the move to aguix.d-less installation directory (some recipes refer to it), but thisis 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 tofix the problems mentioned in this ticket.
From 141e7e8c45c39fbe2e6cfa879f1dc7b7f721bbfc Mon Sep 17 00:00:00 2001From: Maxim Cournoyer <maxim.cournoyer@gmail.com>Date: Sat, 23 Nov 2019 12:04:50 +0900Subject: [PATCH 1/6] build: emacs-build-system: Unify the installation directory.
This change aims to reduce the length of the EMACSLOADPATH environmentvariable, which was found to cause issues such as bug\#38309 (https://bugs.gnu.org/38309).
It should also enable discovery of newly installed packages without refreshingthe session's EMACSLOADPATH of the user profile (e.g., when launching Emacsfrom the desktop manager application launcher), as discussed in bug\#38309 (https://bugs.gnu.org/38309).
* guix/build/emacs-build-system.scm (%legacy-install-suffix): Rename to...(%install-dir): ...this.(%install-suffix): Remove variable.(build): Adjust installation target directory.(patch-el-files): Likewise.(install): Likewise.(move-doc): Likewise.(make-autoloads): Likewise.--- guix/build/emacs-build-system.scm | 39 +++++++++++++------------------ 1 file changed, 16 insertions(+), 23 deletions(-)
Toggle diff (107 lines)diff --git a/guix/build/emacs-build-system.scm b/guix/build/emacs-build-system.scmindex f0c41812f1..e2b792d3dc 100644--- a/guix/build/emacs-build-system.scm+++ b/guix/build/emacs-build-system.scm@@ -40,11 +40,10 @@ ;; ;; Code: -;; Directory suffix where we install ELPA packages. We avoid ".../elpa" as-;; Emacs expects to find the ELPA repository 'archive-contents' file and the-;; archive signature.-(define %legacy-install-suffix "/share/emacs/site-lisp")-(define %install-suffix (string-append %legacy-install-suffix "/guix.d"))+;;; All the packages are installed directly under site-lisp, which means that+;;; having that directory in the EMACSLOADPATH is enough to have them found by+;;; Emacs.+(define %install-dir "/share/emacs/site-lisp") ;; These are the default inclusion/exclusion regexps for the install phase. (define %default-include '("^[^/]*\\.el$" "^[^/]*\\.info$" "^doc/.*\\.info$"))@@ -87,11 +86,10 @@ environment variable\n" source-directory))) "Compile .el files." (let* ((emacs (string-append (assoc-ref inputs "emacs") "/bin/emacs")) (out (assoc-ref outputs "out"))- (elpa-name-ver (store-directory->elpa-name-version out))- (el-dir (string-append out %install-suffix "/" elpa-name-ver)))+ (site-lisp (string-append out %install-dir))) (setenv "SHELL" "sh") (parameterize ((%emacs emacs))- (emacs-byte-compile-directory el-dir))))+ (emacs-byte-compile-directory site-lisp)))) (define* (patch-el-files #:key outputs #:allow-other-keys) "Substitute the absolute \"/bin/\" directory with the right location in the@@ -108,9 +106,7 @@ store in '.el' files." #:binary #t)) (let* ((out (assoc-ref outputs "out"))- (elpa-name-ver (store-directory->elpa-name-version out))- (el-dir (string-append out %install-suffix "/" elpa-name-ver))-+ (site-lisp (string-append out %install-dir)) ;; (ice-9 regex) uses libc's regexp routines, which cannot deal with ;; strings containing NULs. Filter out such files. TODO: Remove ;; this workaround when <https://bugs.gnu.org/30116> is fixed.@@ -124,7 +120,7 @@ store in '.el' files." (error "patch-el-files: unable to locate " cmd-name)) (string-append "\"" cmd "\""))))) - (with-directory-excursion el-dir+ (with-directory-excursion site-lisp ;; Some old '.el' files (e.g., tex-buf.el in AUCTeX) are still ;; ISO-8859-1-encoded. (unless (false-if-exception (substitute-program-names))@@ -175,15 +171,14 @@ parallel. PARALLEL-TESTS? is ignored when using a non-make TEST-COMMAND." (not (any (cut match-stripped-file "excluded" <>) exclude))))) (let* ((out (assoc-ref outputs "out"))- (elpa-name-ver (store-directory->elpa-name-version out))- (target-directory (string-append out %install-suffix "/" elpa-name-ver))+ (site-lisp (string-append out %install-dir)) (files-to-install (find-files source install-file?))) (cond ((not (null? files-to-install)) (for-each (lambda (file) (let* ((stripped-file (string-drop file (string-length source)))- (target-file (string-append target-directory stripped-file)))+ (target-file (string-append site-lisp stripped-file))) (format #t "`~a' -> `~a'~%" file target-file) (install-file file (dirname target-file)))) files-to-install)@@ -197,14 +192,12 @@ parallel. PARALLEL-TESTS? is ignored when using a non-make TEST-COMMAND." (define* (move-doc #:key outputs #:allow-other-keys) "Move info files from the ELPA package directory to the info directory." (let* ((out (assoc-ref outputs "out"))- (elpa-name-ver (store-directory->elpa-name-version out))- (el-dir (string-append out %install-suffix "/" elpa-name-ver))- (name-ver (strip-store-file-name out))+ (site-lisp (string-append out %install-dir)) (info-dir (string-append out "/share/info/"))- (info-files (find-files el-dir "\\.info$")))+ (info-files (find-files site-lisp "\\.info$"))) (unless (null? info-files) (mkdir-p info-dir)- (with-directory-excursion el-dir+ (with-directory-excursion site-lisp (when (file-exists? "dir") (delete-file "dir")) (for-each (lambda (f) (copy-file f (string-append info-dir "/" (basename f)))@@ -216,11 +209,11 @@ parallel. PARALLEL-TESTS? is ignored when using a non-make TEST-COMMAND." "Generate the autoloads file." (let* ((emacs (string-append (assoc-ref inputs "emacs") "/bin/emacs")) (out (assoc-ref outputs "out"))+ (site-lisp (string-append out %install-dir)) (elpa-name-ver (store-directory->elpa-name-version out))- (elpa-name (package-name->name+version elpa-name-ver))- (el-dir (string-append out %install-suffix "/" elpa-name-ver)))+ (elpa-name (package-name->name+version elpa-name-ver))) (parameterize ((%emacs emacs))- (emacs-generate-autoloads elpa-name el-dir))))+ (emacs-generate-autoloads elpa-name site-lisp)))) (define (emacs-package? name) "Check if NAME correspond to the name of an Emacs package."-- 2.24.0
From 6c2fcc4b6f4e8cf8e0b05858b2daa459cb390635 Mon Sep 17 00:00:00 2001From: Maxim Cournoyer <maxim.cournoyer@gmail.com>Date: Wed, 27 Nov 2019 13:40:20 +0900Subject: [PATCH 2/6] gnu: emacs: Simplify the EMACSLOADPATH search path specification.
The EMACSLOADPATH can be greatly simplified by relying on a subdirs.el filethat causes Emacs to search recursively a directory found in EMACSLOADPATH.
* gnu/packages/emacs.scm (emacs)[native-search-paths]: Remove the match-allfile pattern regexp. Remove the versioned site-lisp directory from searchedfiles, 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.scmindex 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 2001From: Maxim Cournoyer <maxim.cournoyer@gmail.com>Date: Wed, 27 Nov 2019 13:51:53 +0900Subject: [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.elindex 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 2001From: Maxim Cournoyer <maxim.cournoyer@gmail.com>Date: Wed, 27 Nov 2019 14:02:42 +0900Subject: [PATCH 4/6] gnu: emacs: Use load-path instead of EMACSLOADPATH.
This enables the use of the subdirs.el feature of Emacs, where specifying adirectory in EMACSLOADPATH translates into a `load-path' variable containingthe 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.elindex 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 2001From: Maxim Cournoyer <maxim.cournoyer@gmail.com>Date: Wed, 27 Nov 2019 22:32:40 +0900Subject: [PATCH 5/6] gnu: emacs-ert-runner: Fix build.
* gnu/packages/emacs-xyz.scm (emacs-ert-runner): Refer to the updatedinstallation 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.scmindex 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 2001From: Maxim Cournoyer <maxim.cournoyer@gmail.com>Date: Wed, 27 Nov 2019 22:34:44 +0900Subject: [PATCH 6/6] gnu: emacs-emacsql: Fix build.
* gnu/packages/emacs-xyz.scm (emacs-emacsql): Refer to the updatedinstallation 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.scmindex 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
;; This is an operating system configuration template ;; for a "desktop" setup with GNOME and Xfce where the ;; root partition is encrypted with LUKS. (use-modules (gnu) (gnu system nss)) (use-service-modules desktop xorg ssh) (use-package-modules certs gnome emacs emacs-xyz databases gdb) (operating-system (host-name "antelope") (timezone "Europe/Paris") (locale "en_US.utf8") ;; Choose US English keyboard layout. The "altgr-intl" ;; variant provides dead keys for accented characters. (keyboard-layout (keyboard-layout "us" "altgr-intl")) ;; Use the UEFI variant of GRUB with the EFI System ;; Partition mounted on /boot/efi. (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi") (keyboard-layout keyboard-layout))) ;; Specify a mapped device for the encrypted root partition. ;; The UUID is that returned by 'cryptsetup luksUUID'. (mapped-devices (list (mapped-device (source (uuid "12345678-1234-1234-1234-123456789abc")) (target "my-root") (type luks-device-mapping)))) (file-systems (append (list (file-system (device (file-system-label "my-root")) (mount-point "/") (type "ext4") (dependencies mapped-devices)) (file-system (device (uuid "1234-ABCD" 'fat)) (mount-point "/boot/efi") (type "vfat"))) %base-file-systems)) (users (cons (user-account (name "bob") (comment "Alice's brother") (group "users") (supplementary-groups '("wheel" "netdev" "audio" "video"))) %base-user-accounts)) ;; This is where we specify system-wide packages. (packages (cons* gdb emacs-datetime emacs-dashboard emacs-dash emacs-dash-docs emacs-darkroom emacs-dante emacs-danneskjold-theme emacs-daemons emacs-d-mode emacs-cyberpunk-theme emacs-ctable emacs-csv-mode emacs-crux emacs-counsel-tramp emacs-counsel-projectile emacs-counsel-etags emacs-counsel-dash emacs-constants emacs-compdef emacs-company emacs-company-restclient emacs-company-quickhelp emacs-company-math emacs-company-lua emacs-company-lsp emacs-company-jedi emacs-company-irony emacs-company-flow emacs-company-cabal emacs-company-auctex emacs-commander emacs-column-marker emacs-cnfonts emacs-cmake-font-lock emacs-closql emacs-clojure-mode emacs-cl-print emacs-cl-generic emacs-circe emacs-cider emacs-cdlatex emacs-ccls ;emacs-calfw emacs-buttercup emacs-butler emacs-build-farm emacs-bui emacs-bug-hunter emacs-browse-at-remote emacs-bongo emacs-blimp emacs-biblio emacs-better-defaults emacs-benchmark-init emacs-beginend emacs-bbdb emacs-bash-completion emacs-base16-theme emacs-avy emacs-autothemer emacs-auto-yasnippet emacs-auto-complete emacs-auctex emacs-attrap emacs-atom-one-dark-theme emacs-async emacs-ascii-art-to-unicode emacs-arduino-mode emacs-apheleia emacs-anzu emacs-ansi emacs-annalist emacs-anaphora emacs-amx emacs-ample-regexps emacs-all-the-icons emacs-all-the-icons-dired emacs-alert emacs-alect-themes emacs-ahungry-theme emacs-aggressive-indent emacs-ag emacs-adoc-mode emacs-add-node-modules-path emacs-add-hooks emacs-adaptive-wrap emacs-ace-window emacs-ace-link emacs-ace-jump-mode emacs-academic-phrases emacs-a emacs-2048-game emacs-magit emacs-ws-butler emacs-string-inflection emacs-recutils emacs-grep-a-lot emacs-diff-hl emacs %base-packages)) ;; Add GNOME and Xfce---we can choose at the log-in screen ;; by clicking the gear. Use the "desktop" services, which ;; include the X11 log-in service, networking with ;; NetworkManager, and more. (services (append (list (service gnome-desktop-service-type) (service xfce-desktop-service-type) (service openssh-service-type (openssh-configuration (permit-root-login #t) (allow-empty-passwords? #t))) (set-xorg-configuration (xorg-configuration (keyboard-layout keyboard-layout)))) %desktop-services)) ;; Allow resolution of '.local' host names with mDNS. (name-service-switch %mdns-host-lookup-nss))
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJ9WGpPiQCFQyn/CfEmDkZILmNWIFAl3egQcACgkQEmDkZILmNWKnpA//R7Wo0YibMzNiqqmgcrpZw1wzMe+wredm/T+Dh1DzPm6glwahBDDHfw7jPACf+fM4RXAb6fSMD0fH8r8J6X/1QbzNw7zspG46rSMD03H6zA08GhcYHkOFXcNrCiMl5vOancEgqkE1gHQbss/irF2oBqYWVjfz7Czj6E8/6yQAHFr7RulKwvekhVwKWWfi41WDaVMo3MLbRYdGQ/SPjkWzUjZ6M9f4s+z4FXBjfRbVx6ZYG9IBRVUpDk7XDFQrvA2sObZZ+DFe2YNHcTAQlj8Yban4kM3iUNErzU4JeJzxn6uHcQAfjIvJe+FYzFSa+YlWR8Ic/QDbpdDwOPMiEvohn75gr3dqICMf3C4Cj9an5Ypiwmv9szDI1WffqrXBJay1jOcK82INnUlDDpDY1YfOgaadn3mQH7bd9FJLgtQx76x8X2M269hlvelRt2KmKRXRMqCKuoYOK0yZa2Vuo2tBlLRfMEV9Qn1CziHs7uESeejSbfLDXUPCjm586xXQT0MRuCmFm7lpSNiKkJ4GXkH7z1gaJ0Kkv1/xopGXhOtERgq6f7c/K1mQWXUBsOy1VYbCuJ2cMUXkdve0pgAH6RE1p69cCICfrcmm4itjdsCd033RGZgbmn2nzCJIKLBkcEkA7heJqnR/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 inthis thread. They had really good ideas that I believe fix theannoyances you reported about the recent changes, while preserving thenew plus points (per profile management of Emacs packages, 'guixenvironment --ad-hoc' that works for Emacs, simplified build system).
Perhaps you could try it out and see if it indeed fixes the problems youreported?
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. Thankyou!
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], itworks very well! Things installed with 'guix package -i' get loaded onEmacs 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, transientcommand "/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 255builder for `/gnu/store/vadbvc79isvvy0wjyx5i0rbr2gr7xlab-emacs-magit-todos-1.4.drv' failed with exit code 1build 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 thatenvironment, 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 beenusing 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 xfcedue to this bug, and that hinders me quite a bit, for example because itcatches key-combinations I need to pass to the IDE.
Best wishes,Arne-- Unpolitisch seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl3mLR8ACgkQE++NRSQDw+v2ChAAoVvkdcX2xTrYkBbh8B+9pfC3MunyCHtb3CF5Qv+AaOsztDTXcHGZF+fLDGWkfrTDsuouCL4ypoWcLagZlicfrq0KFFPrajm0CWukp9ZMsF9b1ZZCed+3Btwkm6xqM/QIfiloQT2YZbvYrP9MDCnLfusVXwtL7u0NKLJOEBaDMMmbrWUuhhFDNL+JI79HH7oUxl5ZYiZJIUivNtzcvdBJRyBcmk5gEWGF0WpzxeEsXcDuX5gmq6515tK+2vSYw352wwnS+5tQyhjFdS9pLzsfCgEi7aoX0Vfq1E/7iRG8Aw5RkouCH06UoUp4AnuZk3DCTjHZRv5KUO5Lh6arFjcxV0wNTKLQGtP16sk7eLVxY7FIJ9E082ZYwiVqQR1p9Q5iv1BRNIISMEuP7yFFO4BkRaX288v79v6gjRPS0O79qpBXOabyN79GbolG7kE4VUmAhCEGkcvNWzIAbwKKESWlAKRNMiAAH2PxFsHF0R0E+vXPty+b7jGUn+FdgmrcjGoR+oduU6ahXo+gdS6fEGCjfPUs79QxfZ3vbZ/wwtKIee7/4vHUc/IvMmOh5VfkgIrP+tIljRURCbtsUPvUMVeILh+davHomQs341i5Axy8PHoUtbUHQo+ViVC3st5bk0/Tu1+yh0ZdcXwfkUWX03UrGTFb/YItUDXu4KnUI5RBOk+IswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd5i0fAAoJENzPDbMLwQVIJlMD/06VPLVB/mjGdtM4gh8c0uMcpnanpqKkJZ9sDAGpzinbgh5dOiQYHXFll5RIhdioua541mVAteAwb/xH8K/YOTyxL9Y9IlRth8CyY6UykgoBcsrZOXUm5GfEIfUsitm5/EvUMUWtFitGQpX6m7m1KuTZ/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 toleave 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 thosepatches, and I hope you'll be back soon to keep hacking on Guix andEmacs!
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 seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl3nlFoACgkQE++NRSQDw+sZOA//bekh+jEOIH8+w+4mEzJzb5W1W7pfd7kFUpSH4UqUh1OImDVknddTHeNYATONYGQ3tR5hYcqjfwPvXNwmUoQr2+QsT5WZBXWwNH6o4Bo9GC7RTLmL6rXOcpuiltj6xt7mL2NQZgSYNGfWSYIMZxm5XSziA66tVWdzqJh07JfQd7NMOxtY0iXqfFLfx5ICULBlga1Re+dBOPOhWcqP15EtWRwf91Oq60wdkiwtYlF9aL4KpGe9WsCvEUxMWa9UEpDrxIdqynmLM2JmGfBITW26OOLGYxmJ35b7SWAeFQ7GCsdHu2XGRM/hfXmAytZDAJlAU5PktR6KRiEm7EzKIVMj1zrUvOzqMc2qgLUc4Qt6oe9E1Ypw2XMlz7aMz7zhxXT69DXiHKUfmHO94ZU2SfdMU3k0vmolrnzdVkHcH3q9A+Bi7DsqBljcKA9vwBEO9E6wYbnK2Ugztz6k1Rxh0JhA/C/oIpOw6niSAlB9BP2HUevcPzLZ0ZveDJKOMwEbrAUZokWa9/ZZv8yrabha7bUk+ernIbxmQxirYsFn/m6xUYObLYV+lbT1HexRP8G9BkBSz+kGXJyF/zF5BONolyFEQu+8xeu+u64CjhNUANbbjxNxf87sDAfZePiPEyZcDRiUE1647vrICxsqb3DlHBd2xG7H1hPxR/Fwh/mmTPq0PiWIswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd55RbAAoJENzPDbMLwQVIzvAD/0y5lS/Rpsr97xKkLIVE3YSAIRm9j0oX5IIWdpYJZppizpfjtyqjPhbkzuTTFwOzOpXml0OX2URwO+1OUzv5YxTt/lqar/2lRecn2CBbFEmLM6d5nXBS5MVX5WidyvxwYfXdQ4p2qJ8MYIQG7iGbTNxpAj+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 seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl3npxkACgkQE++NRSQDw+vS6g/+KD6Y8+Rq00Ml/5NHfD4E79wjyfWX0H/96lkrKpDgCJzmgpIRh6qEk8YBI0UlqcS/v0GfQJG7wH3o6oEBnRjUNkBX7mpVlSra8A64BgKufPMlre00MUww6lIvrANPEaGCeVm1bGMgcSeIBKP23qKTMQpab06e1n7CHVijHwrelkxtJgX4Uf8Uc5ZUPw69m4hjiuiN4YEkYAA6HIjro6s460peg2nolsm7K2fdmmoWeVjYzMiGoyqxQeMtpHUkBF6pPO/DLMa339G1OtjjLKJobvsScQG9zkO/PvUbwnUIaKX3yGwmP8+Rtauxp7Apf6PS7X19pX1cVSjjuZHgfdtj001y465YDe8cPZpQObP9aDH0S7pXGLSFZDBGnjJ+6PP16GFzzsFMyAO/XEA86A0RUo8UMYlRlc3OWwFZyPpq2DDX/bLmbXvyZ+gvpUqBr6snj7Phz9FgcRXScpFyPkvmtSM3WxD6YL7y6RQrPXbHIG579I5d+/iEd5J6cD/IUA6GWD9LW+NLEILY+REW9t7SiySWQQ5DbG6EJ5FYur/KazL32Axhbl0VckilqByOAs1R19spx/eO8xGuTZNlo1QnPfvu8FAkMqQGryPbKYFyhhu9VG1thfDHbDnKeCbwen5IGGhsTkTJRbrCvKCMpLdc0l6yo60WS0SfojPkvKcBonKIswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd56cZAAoJENzPDbMLwQVIyHwD/2HH3nbVmf3RnfMZKacMVyPBcU88b4qgS2pZDYR2+vnVe4/WZrSy/r3B81cN23OJsLeXcqhJIJ7/3B7T7hwVG6obdLSc5smDHeyuI3r7J+nWcO6qv0Ex95iZIirgzf4W7GQzd4RwLAtB4wP2Cz8BXv9dPefcysWZOOmCk94LDfNg=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 ofpatches that will allow continuing to use the guix.d subdirectory, aswell as allowing to reload newly installed packages on the fly.
It uses a hybrid of techniques found in the previous and currentsite-start.el, and uses a custom GUIX_EMACSLOADPATH instead ofEMASCLOADPATH for full control of the load path without interferencefrom Emacs default behavior.
I'll post the new patches to "guix-patches", after I'll have themrebased on what's in master.
A particular thank you to Clément for spending time testing (andpushing) 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 seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl3r0O8ACgkQE++NRSQDw+sPEw/+J2DKjcvvQtMZFgmPmiMygZBrv5dgQ05nOSuWCWQxOilQ89ehNSWV1NN+HTFQnGswPcyz7hPTaDzD8Esuac0+qlFJH3FihLvV7dbjZ13LpJDheyTRzmHEJ81vLX8rMk0ONfZTIlCWIqYeBimc3ReCg9a8NGgI1v69N/Si1XmnIVYOCeuWQiYLR7WHY+w2ETSDyS7v/PyBQvyTYWM0mS5srtSxWr/WknQ23WvkZvjNPIaIcW49UDOxbSPIXNDZeiNqz/jgGgGbqpyEE7D1D0u+ASiK8XLYORLtUxk4Vc1eo8f42zDvcbQrIP7RwKzorX/WgGve730MwoCfO7+tScZf9IRe1sgSF03NMf2CzdHSrDCNFgsZGeH3oNvazuHbsjCQAZ7+msyltS4cmOFqKtciOFDPJMX4hwin6JJXuvPYnXVeqNaOq0Ce0YlFX7tVN4ap3iLayBFVVA28BJDWVHXC3fC4Yuwc57GqfKcWiqzx/PxCVnORliqAnCwmPw015gjS9PTJ1WcxXFDlrW49qQjdc2HKkEVwvjH1vuXOGvcxcrygOzf/QIDkwNLPBMPdNdw5V7qS/Et598AGXT7h/CCO5I49WcuJqnx76enneaO3gRt8Q7ZDS7LJ2Tt3fCzaW/QrT12yPH8VNXsfz4gDikVAu3fiokMjZshOt+xE5xNpB2GIswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd69DyAAoJENzPDbMLwQVIrE0EAIe5BgeTvFx7e+4pQAZwLlFiMKp0EZBmjZgJ8BztwDSUTliJpqf1tEES4oWi88OeaLtgvjLMDrq9pnDdxWVcYCEXnT8I4WqOMo3ZLoubHeUBJ/k0KRE0+HbrF8PWdvG9HX/RmA/z1U3gw9GuTq2sNZkOPD8rjilub81rv3/3KjSk=/a+D-----END PGP SIGNATURE-----
?
Your comment

This issue is archived.

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