Control: tags -1 confirmed
"Kaloian Doganov" <kaloian@doganov.org> writes:
> Package: elpa-vterm
> Version: 0.0.2+git20250113.056ad74-1
> Severity: important
>
> Dear Maintainer,
>
> * What led up to the situation?
>
> Just installed elpa-vterm, launched Emacs, and issued M-x vterm.
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> Issued M-x vterm.
>
> * What was the outcome of this action?
>
> The following message appeared in Emacs:
>
> Vterm needs `vterm-module' to work. Compile it now? (y or n)
>
> This is weird, because vterm-module.so is already installed on the system due to
> elpa-vterm depending on emacs-libvterm:
>
> $ find /usr/lib -name vterm-module.so
> /usr/lib/aarch64-linux-gnu/emacs-libvterm/vterm-module.so
>
> * What outcome did you expect instead?
>
> To get a vterm session buffer out of the box.
>
I can reproduce this in an arm64 qemu img. It turns out on arm64, the
vterm-load-path.el is pointing to the wrong shard library path:
,----
| root@host:~# uname -a
| Linux host 6.16.7+deb14-arm64 #1 SMP PREEMPT Debian 6.16.7-1 (2025-09-11) aarch64 GNU/Linux
| root@host:~# cat /usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-load-path.el
| ;;; set load-path for vterm-module.so -*- lexical-binding: t; -*-
| (add-to-list 'load-path "/usr/lib/x86_64-linux-gnu/emacs-libvterm")
`----
According to the buildd log[1], the arm64 package was built on an arm64
buildd, but it looks like ${DEB_HOST_MULTIARCH} gives the wrong value of
`x86_64-linux-gnu'.
> [...]
[1] https://buildd.debian.org/status/fetch.php?pkg=emacs-libvterm&arch=arm64&ver=0.0.2%2Bgit20250113.056ad74-1&stamp=1739790836&raw=0
--
Regards,
Xiyue Deng
Attachment:
signature.asc
Description: PGP signature