XPost: linux.debian.bugs.dist   
   From: steve@einval.com   
      
   Hey Nicholas!   
      
   I think we've sussed the problem - see my other mail to the bug a   
   couple of minutes ago!   
      
   Cheers,   
      
   Steve   
      
   On Tue, Dec 09, 2025 at 11:10:23PM -0500, Nicholas D Steeves wrote:   
   >Hi Steve,   
   >   
   >Steve McIntyre  writes:   
   >   
   >> Package: elpa-magit   
   >> Version: 4.3.5-1+deb13u1   
   >> Severity: important   
   >>   
   >> Hi!   
   >>   
   >> After upgrading a machine to trixie locally, emacs seems to be working   
   >> fine. Using it to write this mail!   
   >>   
   >> But when I try to start magit using M-x magit-status, I get the   
   >> following error and no magit:   
   >>   
   >> slot-missing: Invalid slot name: "#", :always-read   
   >   
   >I'm curious how to trigger this, because isn't completing-read the   
   >default, and isn't :always-read a user customisation (or file-local, or   
   >dir-locals)?  This suspicion is based off of a superficial search, btw.   
   >   
   >> In case it's my local config in .emacs etc. that might be causing this   
   >> problem, I've tested again with a new user with no customisations and   
   >> I still see the same issue.   
   >   
   >Was this a freshly-created user, (ie: empty $HOME except for the files   
   >copied from /etc/skel during user account creation) or had it ever run   
   >Emacs before?  The reason I ask is because a minority of users have been   
   >affected by one of several native-compilation-related bugs this upgrade   
   >cycle.  The test and workaround for the first class of these (Emacs   
   >doesn't invalidate the cache and recompile platform native code that   
   >needs to be recompiled) is this:   
   >   
   >  mv ~/.emacs.d/eln-cache ~/.emacs.d/possibly-broken-eln-cache   
   >   
   >and restart emacs.   
   >   
   >If that doesn't fix it, or if the problem comes back, then I worry this   
   >might be one of the not-fun-to-find-and-actually-fix bugs like #1036359   
   >(elpa-markdown-toc).  The tldr of that bug is that several packages   
   >appear to have interacted with native-compilation in a way that made   
   >elpa-markdown-toc crash, and it's not clear to me where the   
   >release-critical bug[s] actually were; however, it[they] now appear to   
   >have been transient.  The first step of exploring this hypothesis could   
   >be to get a list of packages that would be removed were you to uninstall   
   >elpa-transient.   
   >   
   >If you get tired of debugging and suspect a system state-related bug and   
   >wanted to purge (and then reinstall) and wanted to use an aggressive   
   >method, this should do the trick:   
   >   
   >  dpkg --get-selections | grep elpa.*install | wc -l  # Gets number of   
   packages   
   >  elpa_packages=$(dpkg --get-selections | grep elpa.*install | awk '{print   
   $1}' | tr '\n' ' ')   
   >  apt purge "$elpa_packages"  # Needs further work if this doesn't equal   
   >                              # number of packages from step 1, and I   
   >                              # recommend aborting if there is no time to   
   investigate   
   >  apt install "$elpa_packages"   
   >  # One limitation of this method is that every package in the list will   
   >  # be marked as "manual" rather than "auto".   
   >   
   >Ideally it would be nice to gather some more data about the difficult to   
   >reproduce bugs, but if one of the heavy handed approaches (that   
   >shouldn't ever be necessary!) fixes the magit issue on your system, then   
   >I'm guessing that you'll consider it a good resolution.   
   >   
   >Cheers,   
   >Nicholas   
      
      
   --   
   Steve McIntyre, Cambridge, UK.                                steve@einval.com   
   You raise the blade, you make the change... You re-arrange me 'til I'm sane...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)