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