home  bbs  files  messages ]

      ZZLI4426             linux.debian.maint.emacsen             356 messages      

[ previous | next | reply ]

[ list messages | list forums ]

  Msg # 144 of 356 on ZZLI4426, Sunday 9-20-25, 1:49  
  From: XIYUE DENG  
  To: XIYUE DENG  
  Subj: Bug#1115607: elpa-vterm: "M-x vterm" ins  
 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) 

[ list messages | list forums | previous | next | reply ]

search for:

328,110 visits
(c) 1994,  bbs@darkrealms.ca