Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1017757: emacs: early error: no suitable directory for output in 'comp-native-load-path'

442 views
Skip to first unread message

Florent Rougon

unread,
Aug 19, 2022, 4:50:03 PM8/19/22
to
Package: emacs
Version: 1:28.1+1-1
Severity: normal

Dear maintainer,

After performing the following upgrades today on sid:

[UPGRADE] emacs:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-bin-common:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-bin-common-dbgsym:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-common:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-el:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-gtk:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-gtk-dbgsym:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1

starting Emacs, even with the -q option, stops very early with a beep
and the following in the *Messages* buffer:

defalias: Cannot find suitable directory for output in 'comp-native-load-path'.

Therefore, it is impossible to execute my initialization files
(I would put severity at least serious, but reportbug wants me to
quote Policy sections in this case, so...).

With 'emacs -q --no-site-file', there is no error.

Thanks!

-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii emacs-gtk 1:28.1+1-1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Florent Rougon

unread,
Aug 19, 2022, 5:10:03 PM8/19/22
to
After downgrading to 1:27.1+1-3, the error is gone.

Regards

--
Florent

Luis Finotti

unread,
Aug 24, 2022, 10:40:04 AM8/24/22
to
I also just updated to emacs 28.1 and have the same problem.

Luis Finotti

unread,
Aug 24, 2022, 5:20:03 PM8/24/22
to

> I also just updated to emacs 28.1 and have the same problem.

FWIW: deleting the user's .emacs.d directory fixed it, even after copying the init.el file back.  (So, the problem was not in the init.el, it seems.)

Florent Rougon

unread,
Aug 25, 2022, 5:50:03 AM8/25/22
to
Since #1017739 is filed on emacs-lucid and I use emacs-gtk, not
emacs-lucid, I don't know how to reassign this bug to merge it with
#1017739; will let this to the Emacs maintainer.

Thanks & regards :-)

--
Florent

Florent Rougon

unread,
Aug 25, 2022, 5:50:04 AM8/25/22
to
Thanks for your input, Luis!

TL;DR: this is the same bug as #1017739:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017739

While trying what you suggested, I had again the same error after:
- quitting Emacs;
- deleting ~/.emacs.d;
- upgrading again to the current version of the Emacs packages in sid;
- restarting Emacs as normal user.

Then I realized I had root-owned files in ~/.emacs.d/eln-cache such as
subr--trampoline-6d616b652d73706172736. I pass you some details like
trying an 'strace -f' and looking if any of the Emacs packages ships
suid binaries... in the end, I understood that it was the *upgrade* to
Emacs 28 that created these files under my home dir, not the emacs
binary run as normal user (yes, I used 'su' without '-'). Pheeeeeew! :)

Regards

--
Florent
0 new messages