XPost: linux.debian.bugs.dist   
   From: manphiz@gmail.com   
      
   Xiyue Deng  writes:   
      
   > Xiyue Deng  writes:   
   >   
   >> Control: tags -1 confirmed   
   >>   
   >> "Kaloian Doganov"  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.   
   /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-libv   
   erm&arch=arm64&ver=0.0.2%2Bgit20250113.056ad74-1&stamp=1739790836&raw=0   
   >>   
   >> --    
   >> Regards,   
   >> Xiyue Deng   
   >   
   > --    
   > Regards,   
   > Xiyue Deng   
      
   --    
   Regards,   
   Xiyue Deng   
      
   --=-=-Content-Type: application/pgp-signature; name="signature.asc"   
      
   -----BEGIN PGP SIGNATURE-----   
      
   iQJGBAEBCgAwFiEEiKQfd6o81mjI+LWALell7WOCXJMFAmjN1akSHG1hbnBoaXpA   
   Z21haWwuY29tAAoJEC3pZe1jglyThLYP/2g2DgJdw4vD4T1QwQBveIfJpagp9B2Y   
   REK9wDE/z1IJAGlJw5nnhLO2AuFyL9jVXJayugKWZhmqKRYui45NjDX2ivIRZjpF   
   VLIHI72JojLJl7EXQ+FE5a2qlVbAvYaVl+60snEltGIiI4aEyab6qE1PnGgzHR+J   
   u//uH1gWTDd/Xou2yE7GNMY/h8XoRGCTmjDJP+V6NOX9223oC3sNDCmsiGTsCcIz   
   FoNrsNjdqAo8xQTWiguwkwF/LfTD5db+tPrgftC0G8Tr26aFx9YuGK361UT+9wmX   
   dcWnFM6/OhCDeM3Yfoq1xLQM0JHLhQyu7CEDfQ6Zj27zbfJ1v4+/wXtNIrVW8r4t   
   8IUlylaIDJbnqPkVKj9150xp2R8F8yiCmCenRg+T77AO3tIY0vHThrWoXQypiUqs   
   GiFs4DKUZEkIOXCzkk0ELdaUE6Eyi5VfqtlTZu1+CYkRjqA8yJuYWdRj4CA4d8ry   
   0bxZSA+i5gUvdlU3qAqrBUZzBOCvXv+PeNQbdMrYRjgLHYz0vW8WEnPAuaYxo6A5   
   kWqFnJIG9LWgEhQ8mmk+IwKvi942kMLZwToiec6qrmYD20x4+H/QxGBV3QjepnMk   
   iZCSuQdbR2HYk4dnj8NSweDF8l1ZHjW9us01s30WXIDpRLFq6Ni6Khc72uxJSmVT   
   r/MriOQNYP1A   
   =Nelk   
   -----END PGP SIGNATURE-----   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)