[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1115607: elpa-vterm: "M-x vterm" insists on compiling `vterm-module` after initial installation



Xiyue Deng <manphiz@gmail.com> writes:

> 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'.
>

Which is actually obvious because `elpa-vterm' is an `arch:all' package
so the DEB_HOST_MULTIARCH will be the one that builds the arch:all
package which is amd64.

I wonder whether marking `elpa-vterm' as `arch:any' should work,
a.k.a. force it to be built for each architecture.

>> [...]
>
> [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

-- 
Regards,
Xiyue Deng

Attachment: signature.asc
Description: PGP signature


Reply to: