XPost: linux.debian.bugs.dist   
   From: manphiz@gmail.com   
      
   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.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-libvt   
   rm&arch=arm64&ver=0.0.2%2Bgit20250113.056ad74-1&stamp=1739790836&raw=0   
   >   
   > --    
   > Regards,   
   > Xiyue Deng   
      
   --    
   Regards,   
   Xiyue Deng   
      
   --=-=-Content-Type: application/pgp-signature; name="signature.asc"   
      
   -----BEGIN PGP SIGNATURE-----   
      
   iQJGBAEBCgAwFiEEiKQfd6o81mjI+LWALell7WOCXJMFAmjNEyYSHG1hbnBoaXpA   
   Z21haWwuY29tAAoJEC3pZe1jglyTZywP/jQ/aL1fjnrrNA+mhIJ3NuaxHepsbNHl   
   iPOC9J2ZoQjXoBfZd+/G4XEAuw4hJqXy0HLXWMPSuqwhFZ6+J08Hi1nu8BVS/SQS   
   kFUUm002jC1UrHBNbdxzca5e2oOudK5URT0Vs9zumhvqfUhe6FiUEdvUWS6TwLup   
   ay5KPAGGmXIeWt3fp8IuxBHkk9kcPIxBVzukxyZxkyJ/b3xVqckWfwlXHTu/NazP   
   iJ4Rg+E8KO6UKNBALjr73JlI4eRrodBcXN78LSHgIBS/TXSR4f5PjUNxy4UooeFu   
   bJg9F06yWnn9SuezcxZKlpm/RsxJFp6skj217t9nnXdiZSRbNdBT50ahSSUrkMbt   
   bAJ9sneJP8LyIGucOf8htdUhtflUFtcqeSN93dMWYU3tdl1pXwwntrHHYpMuJ/8I   
   3Wn0KkM2NjRBIJF2O59ApPy1jh2eNGCFipH927SFROlOo7VQK5+N50itxm3HIJsM   
   9yeCOVZMSX5yWJLoHTCihJFo4PJtzLID1JSmH/lj4jSomSmW7tjCsCksDY+IatiQ   
   x8B8lCnPVv4aTckSnOvrF1trPdolEEj8UQ98Xg6XiBEA5wFAClvmjIzL2+ie7/7K   
   +10JZp95X32vSMOTpLPXa3wvYvEsxcnRtoQRkJH5LaPg07gKSJDxNtTy7xkBn9m/   
   XS74L5nLn2mV   
   =oJja   
   -----END PGP SIGNATURE-----   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)