XPost: linux.debian.bugs.dist 
 From: sten@debian.org 
  
 Hi, 
  
 Christoph Groth  writes: 
  
 > Yes, moving the native compilation cache makes the problem disappear! 
 > (And moving it back makes it reappear...) 
 > 
 > Thanks! 
 > 
 > Now I understand why the other local user was not affected. 
  
 Wonderful, you're welcome, and understanding is treasure! :) 
  
 > Before I upgraded to trixie, I was using magit and transient from elpa, 
 > but then I upgraded to elpa-* packages to simplify things.  I guess that 
 > my package version history is pretty unique and as such the particular 
 > manifestation I observed might be very rare. 
  
 Thank you very much for this; it brings us closer to figuring out a 
 reproducer.  Maybe this time we'll finally figure out how to trigger it 
 (hopefully there's only one bug!) reliably, which of course will point 
 to what actually cause is, and thus towards a resolution. 
  
 At what point did you switch from ELPA-from-upstream-packages to 
 Debian-provided elpa-* packages?  I'm guessing it's this: 
  
   1. Bookworm's Emacs 29.4 with Debian-provided-packages. 
   2. Installed Emacs 30.1 from bookworm-backports, which broke many 
   packages because compatible backports of those packages were not 
   provided. 
   3. So you solved this by deinstalling the affected Debian-provied 
   elpa-* packages and installing ELPA-from-upstream-provided ones. 
   4. Upgraded to trixie. 
   5. Did you run Emacs and activate magit at this point? 
   6. How did you deinstall ELPA-from-upstream-provided packages? 
   7. Installed Debian-provided elpa-* packages. 
   8. Opened Emacs and...breakage (in at least magit) 
  
 > I kept the eln-cache-broken directory in case it can somehow serve to 
 > debug the deeper problem at play here.  Please let me know if there€€€s 
 > a way in which we can help Emacs upstream here. 
  
 Thank you!  I'm curious about a couple of things, but let's start with 
 this:  Do you have the following eln-cache subdirs (if you include full 
 output, please `ls -l`)? 
  
   29.4-6c7920b0, 30.1-9b0c1374, 30.1-e3a6a941 
   # 30.1-9b0c1374 is for the bookworm-backport on my system 
  
 Then, let's move you good eln-cache someplace safe, and then copy 
 eln-cache-broken to eln-cache to resurrect the bug.  Then 
  
   $ strace -e open emacs > ~/.emacs-eln-bug.strace 2>&1 
  
 to see if Emacs is opening transient's native-comp bits from the right 
 cachedir.  The most efficient way to attack this problem is probably 
 something like 
  
   1. Search for "30.1-9b0c1374", the bookworm-backport eln-cache 
   2. Search for a line that looks something like: 
  
   openat(AT_FDCWD, "/home/user/.emacs.d/eln-cache/30.1-e3a6a941/ 
 ransient-ff32346b-0aab668a.eln", O_RDONLY|O_CLOEXEC) = 9 
  
   Please use some kind or regex, pattern, or glob-enabled search for 
   this!  I expect that you'll find that Emacs is loading from the 
   correct cache dir, so this test is mostly to establish a baseline. 
  
 The test after this will be to determine why our elpa-{transient, 
 magit*,etc} packages didn't invalidate the cache generated from 
 ELPA-from-upstream native compilation...that's a much harder thing to 
 debug.  I'm guessing the resolution to that will probably look like 
 adding a method where the ELPA-source injects a source-cookie (GNU ELPA, 
 MELPA, dh-elpa, etc) so Emacs can use ELPA-source-cookie to invalidate 
 the eln-cache.  Foo-pkg.el seems like a convenient place for this. 
  
 Cheers, 
 Nicholas 
  
 --=-=-Content-Type: application/pgp-signature; name="signature.asc" 
  
 -----BEGIN PGP SIGNATURE----- 
  
 iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmjKKmwQHHN0ZW5AZGVi 
 aWFuLm9yZwAKCRBaiDBHX30QYZqPD/98a87FJnXeXTNEDZma8l/IRO7CqES60k5m 
 5Ww+hly/BfGvFl/JBos5zW+ZttS44SJqloJBzc3DBtceHVK9YAhZtOCIOuDeAOhU 
 wezhBkYxRiRuFYgPQw7jZaD+R8O7q48Xyp2z8pqxB/kxdjru5EtRvb5BYvISQ3Tk 
 fDuCIKiQG7Nq4Ebgp1d2Om9hC55mTdW0q5dj5ANubGfCpTTWTrCtBWKzb/LhHYmj 
 RkZ/2yuCvGZgLzBrWVjdBu7vcGC9wqYT75GFQ9Mw4sNCQZorSS52cNydf5UHLbTV 
 X3zyjO+Tn7whZQfJ7w+pYqhKeouXS2APvF3hrYESqAQ4gfNVUlNF7DNX1cQE2PyO 
 Pk/ThK4I2ZzNYt5F2XEovXZb1vQfTSTpJjCfbWmWMjIRqXNL7XxUgfpejM3n9Uhz 
 YPiLRvcv+wSWqwCCjug5IjbNsMVXFdQb/isuEkyhR53Qhb7YeooEMN5pP9UxZX3Y 
 SiCsFa2NTmssU7rOVY+5JcZWW1ajDZiZyXUlgGeif+vKkTM8W3DhQ3h0feMF76bv 
 mfMus9yxewnMo/zGPkOYIDoTMaZTYc3RVYFO5Q3GwWfR8DgkBczRyiFGnYBFT+sd 
 qkcH8gLB9L225CdIsjEtC5CUV1mi36G6cwlyFY+zuBwvsvRdycR6dLmhkZST7xfw 
 yVSSlWOGPw==xYfb 
 -----END PGP SIGNATURE----- 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)