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
signature.asc
Description: PGP signature
