Comment # 2 on bug 1175487 from Philipp Reichmuth

For the record, this seems to be related to MELPA currenly being down, and to
how Emacs behaves with respect to HTTP connection issues. 

Emacs 27.1 from the TW repository seems to give up quite quickly when it can't
connect to melpa.org. After the connection fails, it seems to to receive some
junk (probably an error message either from the server or locally, couldn't
check which), which then gets interpreted as Lisp code and throws an error. 

Spacemacs is just particularly visible case of this, because upon installation
there's lots of downloading and compiling going on. 

For comparison, I tried Emacs 27.1 from Andreas Schwab's repository instead,
which tries to connect to melpa.org for much longer time until it gives up
gracefully. In the Spacemacs case, this means that the first install with all
the package downloads takes much longer, but in the end you get a working
install.

In the meantime, while MELPA is down, the easiest workaround is to use a
different mirror, e.g. by putting something like this in your init.el:

(require 'package)
(setq package-archives
   '(("melpa" .
"https://raw.githubusercontent.com/d12frosted/elpa-mirror/master/melpa/")
     ("org"   .
"https://raw.githubusercontent.com/d12frosted/elpa-mirror/master/org/")
     ("gnu"   .
"https://raw.githubusercontent.com/d12frosted/elpa-mirror/master/gnu/")))
;; (setq package-check-signature nil) ;; probably not necessary
(package-initialize)

If I put this into the Spacemacs configuration, with Emacs 27.1 from the TW
repository I still get spurious errors (such as org-mode failing to load), with
the version from Andreas Schwab's repository it workes fine. So in the meantime
I'll use that as a workaround.