1

My ultimate goal is to get magit working again with Emacs 27.1 on openSUSE Tumbleweed, but the problem ahead of that is getting (melpa?) package management working - so that is really what this post is about. I run into these problems with other packages; magit is just the example, because want teh awesome. I had not installed any packages recently with Emacs 26.3, but my assumption is that it was OK. Magit was certainly working.

Attempt is to start from bare wood:

rm .emacs
rm -r .emacs.d

Need melpa to get magit, so I create a new .emacs with only this inside:

(require 'package)
(add-to-list 'package-archives
             '("melpa" . "https://melpa.org/packages/") t)
(package-initialize)

Restarting emacs, the package-list command shows a ton of melpa stuff in there (yay!). Including magit!

So I install that (version 20200820.227) by clicking on the Install button, then "Yes" when it asks for confirmation. Here is what happens at the end of the "Messages" buffer:

Wrote /home/tcarroll/.emacs.d/elpa/magit-20200820.227/magit-autoloads.el [2 times]
Loading async...done
Contacting host: melpa.org:80

error in process sentinel: async-handle-result: End of file during parsing
error in process sentinel: End of file during parsing

At this point magit is "installed" - and magit-status even works. But if I restart Emacs, running magit-status results in:

load-history-filename-element: Wrong type argument: stringp, (require . info)

...and I don't actually get any Git status.

Some output I get that I don't recall ever getting when starting Emacs 26.3:

Warning: game dir '/var/games/emacs': Permission denied
Loading loadup.el (source)...
dump mode: nil
Using load-path (/usr/share/emacs/27.1/site-lisp /usr/share/emacs/site-lisp /usr/share/emacs/27.1/lisp /usr/share/emacs/27.1/lisp/emacs-lisp /usr/share/emacs/27.1/lisp/progmodes /usr/share/emacs/27.1/lisp/language /usr/share/emacs/27.1/lisp/international /usr/share/emacs/27.1/lisp/textmodes /usr/share/emacs/27.1/lisp/vc)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/byte-run...done
Loading emacs-lisp/backquote...

Several screenfuls of "Loading" this and that; I can include more if helpful. My speculation is that this has something to do with the new portable dumper?

There are a great many clean-shaven yaks in my vicinity (and the rest are scared). Trying to keep this from getting too long.

Adding new info at request:

openSUSE Tumbleweed update today to emacs. Still at version 27.1 but dated today:

GNU Emacs 27.1 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.24.22, cairo version 1.16.0) of 2020-08-25

Toggled on debugging via toggle-debug-on-error. Installation behavior nothing new, unfortunately; still

async-handle-result: End of file during parsing

Again, thanks for any help!

PieSwiper
  • 31
  • 4
  • Can you try cloning Magit repo and adding it to the path. That would be an alternate way to install. – Vasantha Ganesh Aug 23 '20 at 08:05
  • See whether `M-x toggle-debug-on-error` gets you a backtrace, if you reproduce that error. "End of file during parsing" certainly indicates that something didn't download properly; but offhand I'm not certain what that something would be. – phils Aug 24 '20 at 21:01

1 Answers1

2

Turns out the /usr/bin/emacs is a script not a binary (old news to most of you, I'm sure) and it decides between different ways of invoking Emacs. For me, the key thing is that at the end it does this:

exec -a emacs /usr/bin/emacs-gtk

which causes Emacs to emit lots of messages about "Loading" this and that, including loadup.el, and finally not work properly with regard to packages (Org and Magit both affected, probably others).

When I invoke this instead:

/usr/bin/emacs-gtk

...I don't see any of those "Loading" messages. And Magit and Org both work fine.

From my limited understanding of this "exec -a" thng it seems that there "should" not be this difference in behavior, so maybe it is some dumb thing in my environment that I overlooked. But stuff works now.

PieSwiper
  • 31
  • 4
  • My `emacs` is the actual binary -- this sort of thing will just depend on how you installed Emacs. Presumably what you're seeing is the approach taken by the openSUSE package. – phils Aug 26 '20 at 05:13
  • Seeing messages "including loadup.el" is interesting -- *that* indicates an undumped Emacs -- `loadup.el` determines what will be pre-loaded in the dumped executable. So maybe there's an issue with the (new) portable dumper in 27.1. Did you actually install 27.1 via an openSUSE package, or have you manually installed 27.1 over the top of a pre-existing openSUSE package for an earlier Emacs version? – phils Aug 26 '20 at 05:15
  • @phils The openSUSE (Tumbleweed) package management (YaST/zypper) handled the Emacs install - including the update to 27.1. I don't think that 26.3 is around any more. – PieSwiper Aug 26 '20 at 15:05
  • 1
    To me this sounds like a problem with either the new Tumbleweed package for 27.1, or the upgrade process from the older package. I suggest that you log this upstream with whoever maintains the packages, and see if they can see what's gone wrong, and prevent it in future. – phils Aug 27 '20 at 01:13
  • 1
    Opened https://bugzilla.opensuse.org/show_bug.cgi?id=1175915 – duncan Aug 29 '20 at 13:12