Hello,

Le dimanche 16 juillet 2023 à 08:22, Sean Whitton <spwhit...@spwhitton.name> a écrit :

async 1.9.3 is from buster.  You have
/usr/share/emacs/site-lisp/elpa-async-1.9.7 on your system, right?

The directory you're supposed to have is /usr/share/emacs/site-lisp/elpa/async-1.9.7

Le dimanche 16 juillet 2023 à 10:52, Nikolaus Rath <nikol...@rath.org> a écrit :

No. It seems these files got orphaned during the upgrade:

# dpkg -S  /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc
dpkg-query: no path found matching pattern /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc

They did not.

dpkg -S only shows the files that are present in the .deb file, and the byte-compiled files (elc) are not.

The real file list of the elpa-async package can be queried with :

- dpkg -L elpa-async
- apt-file list elpa-async (same as previous one, but without prefix directories) - Or directly on https://packages.debian.org/bookworm/all/elpa-async/filelist

It is normal that files in /usr/share/emacs/site-lisp/elpa do not show up in any file list.

It is because those files are generated during the installation process, from the content of /usr/share/emacs/site-lisp/elpa-src (note the -src suffix). And indeed, those files in /usr/share/emacs/site-lisp/elpa are either symbolic links to elisp source files in /usr/share/emacs/site-lisp/elpa-src, or the byte-compiled version of those same files.

Looking at one randomly there seems to be a broken symlink for the .el
file:

nikratio@vostro /u/s/e/s/elpa> dir /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.* lrwxrwxrwx 1 root 57 Feb 24 10:49 /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.el -> /usr/share/emacs/site-lisp/elpa-src/async-1.9.3//async.el -rw-r--r-- 1 root 12K Feb 24 10:49 /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc

I am not sure what you mean by broken symlink. My output of dir(1) does not show the target of symlinks. Do you mean that the target of the symbolic link is not present on your system ? This is not supposed to be the case after a successful installation of an elpa-* package : they are part of it. Try to reinstall elpa-async from stable, you should have /usr/share/emacs/site-lisp/elpa-src/async-1.9.7 and the elisp source files therein, and the corresponding symlinks and byte-compiled files in /usr/share/emacs/site-lisp/elpa/async-1.9.7.

Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc Disable showing Disable logging Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/transient-0.2.0.30/transient.elc Disable showing Disable logging Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/async-1.9.3/async-bytecomp.elc Disable showing Disable logging Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc Disable showing Disable logging Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc Disable showing Disable logging

Those warnings can safely be ignored. The new native compiler is looking for the source file of each loaded byte-compiled file, and because of our specific file architecture, it does not find it in the same directory. However, in my case, I do have the corresponding native-compiled files in my ~/.emacs.d/eln-cache directory. You could check if you have it, it is supposed to be named ~/.emacs.d/eln-cache/<emacs-version>-xxxxxxxxxx/async-xxxxxxxx-xxxxxxxxx.eln.

My point is that if there is a native-compiled version of some elisp source file on my system, and emacs is capable of loading the native-compiled file, then it means that the native compiler found the source file. So the warnings can be ignored, because some time after the issuing of those warnings, the native compiler will look for the source file in the right place.

So it seems to me there are two different things here :
- The broken symlink, which should be resolved after a reinstallation of the corresponding package (do tell us if that's not the case)
- The native compiler warnings, which can be ignored.

Best,

Aymeric

Reply via email to