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 <[email protected]> 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: "#<transient-option >> transient-option-1037fa0c2081>", :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. [email protected] You raise the blade, you make the change... You re-arrange me 'til I'm sane...
