[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:

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

The testing on experimental was successful.  I'll upload to unstable
soon, and propose a stable update once it migrates to Forky.

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

-- 
Regards,
Xiyue Deng

Attachment: signature.asc
Description: PGP signature


Reply to: