Emacs native compilation on startup can crash the system

OpenSubmitted by Konrad Hinsen.
Details
6 participants
  • Thompson, David
  • Konrad Hinsen
  • Liliana Marie Prikler
  • Ludovic Courtès
  • Max Brieiev
  • zimoun
Owner
unassigned
Severity
important
K
K
Konrad Hinsen wrote on 17 Sep 11:09 +0200
(address . bug-guix@gnu.org)
m1y1ui2wqf.fsf@fastmail.net
After updating to a commit after the introduction of native compilation
in Emacs, I cannot start Emacs any more. It launches an ever increasing
number of async processes for native compilation, which rapidly makes
kswapd the main CPU user on my machine, and ultimately crashes the
kernel.

Some experiments showed that it's loading the site-lisp/site-start.el that
causes this avalanche of processes:

emacs -Q --batch --eval="(print load-path)"

works fine. As does:

emacs -Q --batch --load=~/.guix-profile/share/emacs/site-lisp/guix-emacs.el --eval="(print load-path)"

But not:

emacs -Q --batch --load=~/.guix-profile/share/emacs/site-lisp/site-start.el --eval="(print load-path)"

which starts the avalanche of compilation.

Possibly related: in my user-dir (~/.emacs.d/) I have a directory
"eln-cache" containing a directory "28.1-f1a30909", but that directory
remains empty. Perhaps all native compilation attempts fail and that's
what causes the problem. Just guessing!

Cheers,
Konrad.
K
K
Konrad Hinsen wrote on 17 Sep 12:28 +0200
Minimal reproducible setup
(address . 57878@debbugs.gnu.org)
m1o7ve2t2a.fsf@fastmail.net
My understanding of site-start.el is that it actually loads all the
Emacs packages that are listed in my Guix profile. Which means that my
package list matters. Here is a minimal containerized example that
creates a process avalanche:

guix shell -C emacs emacs-ido-completing-read+ \
-- emacs --batch --eval="(print load-path)"

ido-completing-read+ is a rather small Emacs package, and I don't see
anything obvious in it that could cause trouble with native compilation.
But more importantly, I think no package should be able to cause the
behavior that I observe.

Cheers
Konrad.
K
K
Konrad Hinsen wrote on 17 Sep 17:45 +0200
(address . 57878@debbugs.gnu.org)
m1o7vexawf.fsf@fastmail.net
Konrad Hinsen <konrad.hinsen@fastmail.net> writes:

Toggle quote (6 lines)
> Here is a minimal containerized example that
> creates a process avalanche:
>
> guix shell -C emacs emacs-ido-completing-read+ \
> -- emacs --batch --eval="(print load-path)"

I went through all my emacs packages. The only one that starts
the process avalanche is emacs-ido-completing-read+.

Cheers
Konrad.
L
L
Liliana Marie Prikler wrote on 18 Sep 01:19 +0200
e00fb97ec9fa651b42c7bbbf29760e0d93e6e3e6.camel@gmail.com
Am Samstag, dem 17.09.2022 um 17:45 +0200 schrieb Konrad Hinsen:
Toggle quote (10 lines)
> Konrad Hinsen <konrad.hinsen@fastmail.net> writes:
>
> > Here is a minimal containerized example that
> > creates a process avalanche:
> >
> >     guix shell -C emacs emacs-ido-completing-read+ \
> >        -- emacs --batch --eval="(print load-path)"
>
> I went through all my emacs packages. The only one that starts
> the process avalanche is emacs-ido-completing-read+.
I think you can prevent native-compilation entirely by setting no-
native-compile to t in your early-init.el (I'm playing with the idea of
doing this anyway, because I'm annoyed by the clutter that falls
through the cracks). That being said, this looks like a real breakage
in the emacs-ido-completing-read package, does it not? Should we add
"no-native-compile" to some local variables?

WDYT?
L
L
Liliana Marie Prikler wrote on 18 Sep 20:35 +0200
12eb8b51fe6c9508517e19bdeed923c389cafe1f.camel@gmail.com
Am Sonntag, dem 18.09.2022 um 01:19 +0200 schrieb Liliana Marie
Prikler:
Toggle quote (4 lines)
> I think you can prevent native-compilation entirely by setting no-
> native-compile to t in your early-init.el (I'm playing with the idea
> of doing this anyway, because I'm annoyed by the clutter that falls
> through the cracks).
Okay, it turns out that disabling native compilation is not so simple
after all. Other ideas are welcome.

Cheers
K
K
Konrad Hinsen wrote on 19 Sep 08:04 +0200
m14jx3q4qy.fsf@fastmail.net
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (8 lines)
>> I think you can prevent native-compilation entirely by setting no-
>> native-compile to t in your early-init.el (I'm playing with the idea
>> of doing this anyway, because I'm annoyed by the clutter that falls
>> through the cracks).
>
> Okay, it turns out that disabling native compilation is not so simple
> after all. Other ideas are welcome.

That's what I discovered as well. What you can do is set
native-comp-speed to -1, reducing native compilation to byte code
compilation. But that doesn't deactivate the machinery.

Cheers,
Konrad.
K
K
Konrad Hinsen wrote on 19 Sep 10:51 +0200
m1r107iw6t.fsf@fastmail.net
I did one more test: run native-compile by hand on each elisp file in
the package ido-completing-read+. Works fine.

The next question that I consider relevant: is this an upstream (Emacs)
issue, or an issue created by packaging in Guix? That's not easy to
answer.

A related question: what are appropriate debugging techniques?

Cheers,
Konrad.
T
T
Thompson, David wrote on 2 Oct 02:15 +0200
Re: bug#57878: Minimal reproducible setup
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)
CAJ=RwfbckEBc+7MSTbVtKsoL7EGM_ZYk+CecO-6x0PGDkWfntw@mail.gmail.com
Hello Konrad and Liliana,

On Mon, Sep 19, 2022 at 5:16 AM Konrad Hinsen
<konrad.hinsen@fastmail.net> wrote:
Toggle quote (8 lines)
>
> I did one more test: run native-compile by hand on each elisp file in
> the package ido-completing-read+. Works fine.
>
> The next question that I consider relevant: is this an upstream (Emacs)
> issue, or an issue created by packaging in Guix? That's not easy to
> answer.

I just got bit by this and lost a bunch of time trying to get my
system stable again. I am leaning towards this being an upstream
issue as it is also affecting Debian users [0]. Unfortunately, they
do not seem to have found a solution. I haven't checked the Emacs bug
tracker/mailing lists so I don't know if upstream is working on or has
a fix for this. I will be sticking to a pre-commit
dbcba75c0e96d8eb2b0bf9dbb3a49d15b38f80d2 version of Guix for the time
being. There may be many more people affected that have not reported
in. Is disabling native compilation an option on the table?

- Dave

L
L
Liliana Marie Prikler wrote on 2 Oct 02:23 +0200
(address . 57878@debbugs.gnu.org)
3e87d36344804c7252fa25b7ddad87b32390486d.camel@gmail.com
Am Samstag, dem 01.10.2022 um 20:15 -0400 schrieb Thompson, David:
Toggle quote (1 lines)
> Is disabling native compilation an option on the table?
I don't want to disable native compilation for everyone, but I'd very
much disable deferred compilation and replace it with Guix packages.
In other words, as long as your change doesn't break the current "guix
build --with-input=emacs-minimal=emacs" flow, I'm leaning towards
accepting a patch.

As for disabling native compilation, using 
(setq native-comp-deferred-compilation nil)
removes most, but sadly not all compilation from personal experience.
I do wonder what causes the remaining ones to still pop up.

Cheers
K
K
Konrad Hinsen wrote on 2 Oct 10:25 +0200
(name . Thompson, David)(address . dthompson2@worcester.edu)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 57878@debbugs.gnu.org)
m17d1iskc0.fsf@fastmail.net
Hi David and Liliana,

Thanks David for the added observations. This does indeed look like an
upstream bug, but it also seems to have a context dependence because the
Debian bug reports list some packages are affected that cause no problem
under Guix (e.g. git-timemachine).

As for Liliana's idea of disabling deferred compilation : shouldn't it
be sufficient to have all Emacs Lisp packages in Guix AOT-compiled?
There would be nothing left to compile in deferred mode. A quick scan of
the relevant page on Emacs Wiki
manager do this.

Cheers,
Konrad.
Z
Z
zimoun wrote on 11 Oct 12:04 +0200
86r0zeoew6.fsf@gmail.com
Hi,

On Sat, 01 Oct 2022 at 20:15, "Thompson, David" <dthompson2@worcester.edu> wrote:

Toggle quote (8 lines)
> I am leaning towards this being an upstream
> issue as it is also affecting Debian users [0]. Unfortunately, they
> do not seem to have found a solution. I haven't checked the Emacs bug
> tracker/mailing lists so I don't know if upstream is working on or has
> a fix for this.

> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017817

Heavy discussions are currently happening upstream; see this loooong
thread [1]. From my understanding, no fix yet.



Cheers.
simon
L
L
Liliana Marie Prikler wrote on 12 Oct 21:42 +0200
(address . 57878@debbugs.gnu.org)
6873fe86a05a548e7427d2de7df04a27a967713a.camel@gmail.com
Am Sonntag, dem 02.10.2022 um 10:25 +0200 schrieb Konrad Hinsen:
Toggle quote (3 lines)
> As for Liliana's idea of disabling deferred compilation : shouldn't
> it be sufficient to have all Emacs Lisp packages in Guix AOT-
> compiled?
From personal experience, no. Even if you compile code ahead of time,
there seem to be some leftovers that are deferred. guix-emacs.el is an
oversight, but apart from that I also other leftovers (possibly from
init.el?)

Toggle quote (4 lines)
> There would be nothing left to compile in deferred mode. A quick scan
> of the relevant page on Emacs Wiki
> (https://www.emacswiki.org/emacs/GccEmacs) suggests that some package
> manager do this.
In Guix, this is more or less a user choice – we advertised the
transformation by which you can opt-in to AOT compilation in a news
entry. Also, enforcing ahead-of-time compilation does not fix the more
pressing issue of packages breaking with native compilation ;)

To quote Eli:
Toggle quote (4 lines)
> More generally, we never expected people who have Emacs with native
> compilation available to want to disable it. It made no sense to us
> during development of Emacs 28, and frankly, it still doesn't, at
> least to me.
I think this reasoning really falls flat in presence of any non-Emacs
package manager. Like, obviously wanting to natively compile packages
managed by (dpkg, rpm, pacman, emerge, guix), but not natively
compiling a random elisp script you just downloaded from the web is a
legitimate use case.

Cheers
M
M
Max Brieiev wrote on 13 Oct 11:31 +0200
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87wn943w9p.fsf@gmail.com
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
Toggle quote (5 lines)
> From personal experience, no. Even if you compile code ahead of time,
> there seem to be some leftovers that are deferred. guix-emacs.el is an
> oversight, but apart from that I also other leftovers (possibly from
> init.el?)

AFAIU, the compiler is invoked any time a function is redefined or
advised, see (info "(elisp) Advising Functions"). In Emacs it is a very
common paractice to put advices around a function to modify its
behaviour. Since this happens during runtime (for example, in response
to a hook, or after you manually run some command), you should accept
the fact that native compiler may be invoked at any time as you use
Emacs.

Toggle quote (5 lines)
> In Guix, this is more or less a user choice – we advertised the
> transformation by which you can opt-in to AOT compilation in a news
> entry. Also, enforcing ahead-of-time compilation does not fix the more
> pressing issue of packages breaking with native compilation ;)

How pressing is this issue? There are literally no reports of packages
breaking due to native compilation. So this is probably the reason why
Eli considers it as a non-issue.

Toggle quote (11 lines)
> To quote Eli:
>> More generally, we never expected people who have Emacs with native
>> compilation available to want to disable it. It made no sense to us
>> during development of Emacs 28, and frankly, it still doesn't, at
>> least to me.
> I think this reasoning really falls flat in presence of any non-Emacs
> package manager. Like, obviously wanting to natively compile packages
> managed by (dpkg, rpm, pacman, emerge, guix), but not natively
> compiling a random elisp script you just downloaded from the web is a
> legitimate use case.

If security is a concern, you should not load random Elisp in the first
place. It is much easier to just directly run harmful elisp, then to
exploit native compiler, which stays silent until after you evaluate
some (possibly harmful) elisp.
M
M
Max Brieiev wrote on 13 Oct 12:06 +0200
(name . zimoun)(address . zimon.toutoune@gmail.com)
87sfjs3um8.fsf@gmail.com
I am new to Guix.

My issue is related to the native compilation too, however it manifests
itself differently.

The build of emacs-next goes well.

However, when I start Emacs it throws lots of errors, most of which are
like this:

Deleting /tmp/comp-lambda-RCGJQI.eln
comp--native-compile: Native compiler error: (lambda (&rest arg1) (let ((f #'make-process)) (apply f arg1))), "Compiling /tmp/comp-lambda-RCGJQI.eln...
x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
compilation terminated.

So while it builds successfully I can't really run it.

What confuses me is that everyone else in this thread has a differnt
issue. For some, if I understand it correctly, the problem is that the
compiler runs to aggressively and makes Emacs unusable. Is it right?

But in my case the native compiler just plainly fails to execute,
because assembler program is not found.

Why isn't it deterministic, meaning that going through the same build
process, the resulting build of my Emacs is different from the others,
reporting related, but different issues?

And this is what makes me think that the problem is actually in
packaging.

This sounds like the problem with dependencies, libgccjit in particular,
doesn't it?
L
L
Ludovic Courtès wrote on 13 Oct 16:56 +0200
control message for bug #57878
(address . control@debbugs.gnu.org)
87bkqfpybj.fsf@gnu.org
severity 57878 important
quit
L
L
Liliana Marie Prikler wrote on 13 Oct 20:23 +0200
Re: bug#57878: Minimal reproducible setup
(name . Max Brieiev)(address . max.brieiev@gmail.com)
603e94929389d6d4c61939fb3a7251ea74d632ae.camel@gmail.com
Am Donnerstag, dem 13.10.2022 um 12:31 +0300 schrieb Max Brieiev:
Toggle quote (10 lines)
> > I think this reasoning really falls flat in presence of any non-
> > Emacs package manager.  Like, obviously wanting to natively compile
> > packages managed by (dpkg, rpm, pacman, emerge, guix), but not
> > natively compiling a random elisp script you just downloaded from
> > the web is a legitimate use case.
>
> If security is a concern, you should not load random Elisp in the
> first place. It is much easier to just directly run harmful elisp,
> then to exploit native compiler, which stays silent until after you
> evaluate some (possibly harmful) elisp.
The nature of compiled code being compiled makes it much easier to
exploit, however. Assume you have a genuine dash.el, but a malicious
person delivers you a dash.eln with some backdoor. Unless you know how
to read x86 assembly, you won't debug the latter, whereas you could
reasonably find the former if you're an Elisp hacker.

This is typically not a concern for Guix, where the challenge mechanism
provides tools to highlight that something is going wrong, but it might
be a concern for traditional distros. Then again, the same applies to
bytecode too, and here as well the solution is to typically use a
trusted package manager.

Cheers
Z
Z
zimoun wrote on 14 Oct 18:07 +0200
(address . 57878@debbugs.gnu.org)
871qrapexf.fsf@gmail.com
Hi Liliana,

On mer., 12 oct. 2022 at 21:42, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Toggle quote (5 lines)
> In Guix, this is more or less a user choice – we advertised the
> transformation by which you can opt-in to AOT compilation in a news
> entry. Also, enforcing ahead-of-time compilation does not fix the more
> pressing issue of packages breaking with native compilation ;)

Indeed, the news entry reads,

Toggle snippet (18 lines)
(entry (commit "11a06d1e49f4d50d6789e05bbf35e2e145ff7838")
(title
(en "Emacs now supports native compilation")
(de "Emacs kann Pakete nun nativ kompilieren")
(pt "O Emacs agora suporta compilação nativa"))
(body
(en "Emacs can now compile packages natively. Under the default
configuration, this means that Emacs packages will now be just-in-time (JIT)
compiled as you use them, and the results stored in a subdirectory of your
@code{user-emacs-directory}.

Furthermore, the build system for Emacs packages transparently supports native
compilation, but note, that @code{emacs-minimal}---the default Emacs for
building packages---has been configured without native compilation.
To natively compile your emacs packages ahead of time, use a transformation
like @option{--with-input=emacs-minimal=emacs}.")

Maybe it could be worth to have that in the manual too, no? For
example, under ’Application setup, Emacs packages’ [1].

Because it appears to me more than just a simple news if it is more or
less an user choice.



Cheers,
simon
L
L
Liliana Marie Prikler wrote on 14 Oct 20:22 +0200
(address . 57878@debbugs.gnu.org)
9bd516f1cbd16a1a9408928d53f3946af3bfe1e8.camel@gmail.com
Am Freitag, dem 14.10.2022 um 18:07 +0200 schrieb zimoun:
Toggle quote (4 lines)
> Hi Liliana,
>
> Maybe it could be worth to have that in the manual too, no?  For
> example, under ’Application setup, Emacs packages’ [1].
Would you prefer a paragraph, a note, or a footnote?
Z
Z
zimoun wrote on 15 Oct 12:11 +0200
(address . 57878@debbugs.gnu.org)
86k051bdmh.fsf@gmail.com
Hi Liliana,

On Fri, 14 Oct 2022 at 20:22, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Toggle quote (5 lines)
>> Maybe it could be worth to have that in the manual too, no?  For
>> example, under ’Application setup, Emacs packages’ [1].
>>
> Would you prefer a paragraph, a note, or a footnote?

As you would prefer. Maybe a note with,

Emacs can now compile packages natively. Under the default
configuration, this means that Emacs packages will now be
just-in-time (JIT) compiled as you use them, and the results
stored in a subdirectory of your @code{user-emacs-directory}.

Furthermore, the build system for Emacs packages transparently
supports native compilation, but note, that
@code{emacs-minimal}---the default Emacs for building
packages---has been configured without native compilation. To
natively compile your emacs packages ahead of time, use a
transformation like @option{--with-input=emacs-minimal=emacs}.

BTW, thanks for your efforts to explain upstream the situation. :-)


Cheers,
simon
L
L
Liliana Marie Prikler wrote on 15 Oct 16:40 +0200
(address . 57878@debbugs.gnu.org)
2ef3c47fabb502a231a028c790aeeed10bdc5511.camel@gmail.com
Am Samstag, dem 15.10.2022 um 12:11 +0200 schrieb zimoun:
Toggle quote (28 lines)
> Hi Liliana,
>
> On Fri, 14 Oct 2022 at 20:22, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
>
> > > Maybe it could be worth to have that in the manual too, no?  For
> > > example, under ’Application setup, Emacs packages’ [1].
> > >
> > Would you prefer a paragraph, a note, or a footnote?
>
> As you would prefer.  Maybe a note with,
>
>         Emacs can now compile packages natively.  Under the default
>         configuration, this means that Emacs packages will now be
>         just-in-time (JIT) compiled as you use them, and the results
>         stored in a subdirectory of your @code{user-emacs-directory}.
>
>         Furthermore, the build system for Emacs packages
> transparently
>         supports native compilation, but note, that
>         @code{emacs-minimal}---the default Emacs for building
>         packages---has been configured without native compilation. 
> To
>         natively compile your emacs packages ahead of time, use a
>         transformation like @option{--with-input=emacs-
> minimal=emacs}.
>
> BTW, thanks for your efforts to explain upstream the situation. :-)
Done. Since I just copypasta'd the wording, I made you the author.

As for this bug: I've bumped emacs-next to a version that can inhibit
almost all native-compilation (trampolines are still compiled, but not
written to the cache), fixed the linker issue, and disabled native
compilation for emacs-ido-completing-read+. Any remaining native-comp
issues or can this be closed?

Cheers
Z
Z
zimoun wrote on 15 Oct 17:40 +0200
(address . 57878@debbugs.gnu.org)
86o7ud9jst.fsf@gmail.com
Hi Liliana,

On Sat, 15 Oct 2022 at 16:40, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Toggle quote (2 lines)
> Done. Since I just copypasta'd the wording, I made you the author.

Oh, thanks. (It was the news’ wording. :-))


Toggle quote (6 lines)
> As for this bug: I've bumped emacs-next to a version that can inhibit
> almost all native-compilation (trampolines are still compiled, but not
> written to the cache), fixed the linker issue, and disabled native
> compilation for emacs-ido-completing-read+. Any remaining native-comp
> issues or can this be closed?

Closing is fine with me; well I do not have a opinion on that. :-)

Just to be sure, do you mean an emacs-next version which includes the
upstream Lars’s patches? The ones that Eli and Andrea are calling to be
reverted?

Toggle snippet (10 lines)
Sorry as changeset I meant 5fec9182db + f97993ee66. I'm not against
e245c4f226.

[...]

Again 5fec9182db + f97993ee66 are IMO not useful / wrong, they were not
discussed and are just a step backward. The best change I can suggest
is to revert them now.

L
L
Liliana Marie Prikler wrote on 15 Oct 18:30 +0200
(address . 57878@debbugs.gnu.org)
aba5435cbb1f8ca9fe38d635acea6202874070d7.camel@gmail.com
Am Samstag, dem 15.10.2022 um 17:40 +0200 schrieb zimoun:
Toggle quote (16 lines)
> Just to be sure, do you mean an emacs-next version which includes the
> upstream Lars’s patches?  The ones that Eli and Andrea are calling to
> be reverted?
>
> --8<---------------cut here---------------start------------->8---
> Sorry as changeset I meant 5fec9182db + f97993ee66.  I'm not against
> e245c4f226.
>
> [...]
>
> Again 5fec9182db + f97993ee66 are IMO not useful / wrong, they were
> not discussed and are just a step backward.  The best change I can
> suggest is to revert them now.
> --8<---------------cut here---------------end--------------->8---
>
> from <https://yhetil.org/emacs-devel/xjfk05e5k9t.fsf@ma.sdf.org/>
Ehm, yes... best to keep this open until I can bump to a version that's
approved and solves the problem.
M
M
Max Brieiev wrote on 25 Oct 18:23 +0200
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87ilk7oos1.fsf@gmail.com
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (3 lines)
> Ehm, yes... best to keep this open until I can bump to a version that's
> approved and solves the problem.

Do the recent changes suppose to fix the issue?

Today I did:

guix pull
sudo guix system reconfigure /etc/system-config.scm
guix package -u emacs-next

After starting Emacs I see lots of errors.

It is not mere compilation warnings. They render Emacs unusable, because
trying to run a command gives me "function is void" errors.

So I switched back to previous generation again.

Please, see the screenshot.
L
L
Liliana Marie Prikler wrote on 25 Oct 20:31 +0200
(name . Max Brieiev)(address . max.brieiev@gmail.com)
52f500c6f35520c8b496174bceb9aabbb036682c.camel@gmail.com
Am Dienstag, dem 25.10.2022 um 19:23 +0300 schrieb Max Brieiev:
Toggle quote (20 lines)
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
> > Ehm, yes... best to keep this open until I can bump to a version
> > that's
> > approved and solves the problem.
>
> Do the recent changes suppose to fix the issue?
>
> Today I did:
>
>     guix pull
>     sudo guix system reconfigure /etc/system-config.scm
>     guix package -u emacs-next
>
> After starting Emacs I see lots of errors.
>
> It is not mere compilation warnings. They render Emacs unusable,
> because trying to run a command gives me "function is void" errors.
>
> So I switched back to previous generation again.
While I can't really reproduce the one you showed me in a pure
environment, I do see

Warning (comp): /gnu/store/hjciw32mj05yz1m6r6nzwdi12waz81ni-emacs-next-
29.0.50-2.4aeb80c/share/emacs/29.0.50/lisp/emacs-lisp/cl-
loaddefs.el.gz: Error: error Uncompression program `sh' not found

which is equally concerning.
Z
Z
zimoun wrote on 26 Oct 09:46 +0200
86r0yv10zm.fsf@gmail.com
Hi Liliana,

On Tue, 25 Oct 2022 at 20:31, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
Toggle quote (5 lines)
>
> Warning (comp): /gnu/store/hjciw32mj05yz1m6r6nzwdi12waz81ni-emacs-next-
> 29.0.50-2.4aeb80c/share/emacs/29.0.50/lisp/emacs-lisp/cl-
> loaddefs.el.gz: Error: error Uncompression program `sh' not found

I have reported something similar the Emacs package ESS. See [1].


Cheers,
simon
?
Your comment

Commenting via the web interface is currently disabled.

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