Spacemacs can not start correctly after upgrading to 0.105.0

[tommyjiang]

The error is as following:

error: Package `spacemacs-theme-' is unavailable.

I just deleted the whole directory .emacs.d and re-install Spacemacs but it still exists.

It feels like my config .spacemacs.d is conflict with the new version. I am trying to figure out what is the problem.

[StreakyCobra]

CC @syl20bnr as it was already discussed in #4097. Also I saw this error once on gitter but without solution.

[StreakyCobra]

Can you also try running emacs --insecure and see if it helps?

[tommyjiang]

Thanks for your advice @StreakyCobra. The problem still exists even I delete the elpa directory. Maybe I should consider using the older version..

[StreakyCobra]

Let's wait for @syl20bnr then :-)

[tommyjiang]

Thanks for your kind help @StreakyCobra

[syl20bnr]

@tommyjiang did you try launching emacs with emacs --insecure ? Should fix the issue (I have the exact same at work).

[syl20bnr]

We should document it clearly by mentioning it on README.md and in the FAQ/

[tommyjiang]

@syl20bnr I use proxy to connect melpa.org and it seems all right with the backup version 0.104.8 from another Mac. I will try to test whether it works fine with the newest version, i.e., 0.105.0.

[syl20bnr]

@tommyjiang in 0.104.8 ELPA packages are fetched with http. It is now https by default unless you either:

• launch emacs with emacs --insecure
• set the variable dotspacemacs-elpa-https to nil

[tommyjiang]

I tested the newest version 0.105.0 with proxychains-ng on Mac. Everything seems OK.

So I suggetst the connection problem without proxy is the critical reason for this. For me maybe the website is blocked by GFW of China. For others, maybe it is related to @syl20bnr's explanation with https in the newest version.

Hope my solution helps.

[bohrshaw]

@tommyjiang Thus maybe some newly added URLs is blocked by GFW, as Spacemacs starts fine on v0.104.8 while stucks on v0.105.

[et2010]

I had the same error while try to fix issue #4402 , I forgot to remove the --insecure argument after removing .emacs.d directory and started installing spacemacs from the very beginning. That's when the error popped up. After I removed the argument, everthing is fine except #4402 still haunting me.

[royseto]

@syl20bnr

I am seeing this error too. Running with emacs --insecure does not help.

Environment:

• Fresh build of emacs 24.5.1 from source
• Ubuntu 14.04 running in a Docker container
• Running at home in California (no proxy). I confirmed using "curl https://melpa.org" that I can access that URL over https without problems.

Steps I am taking:

1. cd $HOME
2. rm -rf .emacs .spacemacs .emacs.d
3. git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d
4. run either "emacs" or "emacs --insecure"

My emacs Warnings buffer has the following contents:

Warning (initialization): An error occurred while loading `/home/dev/.emacs.d/init.el':

error: Package `spacemacs-theme-' is unavailable

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the `--debug-init' option to view a complete error backtrace.

Spacemacs 0.104.8 had been working fine for me (on emacs 24.3.1).

[syl20bnr]

Wow github, I did not want to close it so soon, shouldn't have put the fixes tag in comment :-)

[syl20bnr]

I consider this fixed as it is now mentioned in the documentations but we can let it opened since there may be several issues.

[royseto]

I suspect this may not be completely fixed. I started Emacs with the --insecure argument as mentioned in commit 74689e0 but am still seeing the behavior I described in my earlier comment in this issue. This reproduces on 0.105.1 as well as 0.105.0. When I revert to 0.104.8, spacemacs loading works fine again.

This blocks spacemacs from starting for me on 0.105.1 and 0.105.0.

[bohrshaw]

--insecure doesn't help too.

[StreakyCobra]

I suppose the problem on your side is emacs 24.3. We know there are bugs with emacs version older than 24.4, and this is probably one of them. We are dropping support of it as no regular contributor is working on it.

[bohrshaw]

@StreakyCobra I'm on Emacs 24.5 on Windows 10.

[StreakyCobra]

Sorry, I was speaking for @royseto

[roelandmoors]

I had the same problem. Starting with --insecure fixed it.
I'm running Emacs 24.5 on Windows. The windows build doesn't has SSL/TLS by default.
Maybe set dotspacemacs-elpa-https to nil on Windows by default?

[giodamelio]

I am having this same problem, and neither using --insecure or setting dotspacemacs-elpa-https fixes it. I am using Emacs 25.4.1 and Spacemacs 0.105.9.

[alanct-minted]

Likewise. dotspacemacs-elpa-https nil and --insecure aren't doing it for me. (on both develop and master). This is in a fresh Ubuntu vivid VM with no previous or custom emacs config.

[alanct-minted]

FWIW, I was able to get unblocked for the moment by going back to d822241.

$ cd ~/.emacs.d/
$ git checkout d82224173937a10f1a4594a988444d6e51373322
$ emacs

Miiiight still need dotspacemacs-elpa-https nil (I had this in my .spacemacs) or emacs --insecure.

Not sure what the big difference is, but I found that commit from the other conversation in #4097.

[giodamelio]

@alanct-minted Thanks, that worked great without --insecure or dotspacemacs-elpa-https nil

[alanct-minted]

Also, for a bit more context, the exact same configuration ran just fine on my OS X 10.10 host machine on latest master, whereas I had to check out the older commit in the Ubuntu VM (running in Vagrant).

[StreakyCobra]

@alanct-minted Have you tried with both OS X and Ubuntu VM on the same network (i.e. both at home or both at work, not one at home and one at work)?

[alanct-minted]

@StreakyCobra Ugh, good question. I'm 90% sure these were both on the same network. The Mac one is a little difficult to reproduce again since that's my Macbook host, but I'll take a stab at the Ubuntu one both at home and at work today as I make my way into the office and see if either works like the Mac install.

[alanct-minted]

Actually, as I typed that... the Ubuntu VM was in Vagrant, which has some inherent complexity creating virtual network interfaces and routing the networking through the host machine. Think it could have anything to do with that extra layer? The Vagrantfile I used for testing is pretty simple. You could probably even vagrant up that one and give it a shot on your own machine too.

I'll still play with it on different networks today just to be sure.

[alanct-minted]

If you're feeling especially ambitious, you can clone my exact configuration into the Vagrant too:

https://github.com/alanctkc/dotfiles

Then:

$ cd dotfiles
$ ./install-ubuntu.sh
$ ./dotme.sh

[StreakyCobra]

The problem is not about the complexity, but because some ISP (internet service providers) or firewalls have caused problems before. Not sure it's this in your case.

I don't really have time these days to test this. Maybe somebody else will do :-)

[alanct-minted]

Ok, after testing at home and at work, the network seems to make no difference. Everything works smoothly on OS X, and in an Ubuntu Vivid vagrant VM, packages end up unavailable on emacs startup past d822241.

[StreakyCobra]

Ok :-( So I don't really know where it can come from…

[syl20bnr]

@alanct-minted can you paste the contents of SPC h d s for both machine ?

[alanct-minted]

@syl20bnr Here are system info message for both machines: https://gist.github.com/alanct-minted/103a072f04c0219f0dc8

Note, those are the working revisions, so the linux one just reports Spacemacs 0.105.0 instead of 0.105.10 since the latter (latest master) was the one that barfed for me on melpa. Interesting the linux machine is on emacs 24.4 instead of 24.5, though.

[bpizzi]

I was having the same troubles as you guys (fresh install, emacs 24.5, spacemacs 0.105.16, curl https://melpa.org working, --insecure doing nothing good).
It turned out that my dns configuration wasn't quite ok and that was the root cause of a timeout during the initialization against melpa.
I changed my dns primary server for one that was actually fast for me, and no more "unable to contact melpa.com".

[ghost]

Had the same issue, was fixed by setting dotspacemacs-elpa-https nil in dotspacemacs/init.

--insecure didn't help, and I think there's a bug somewhere as it seems like that flag is being ignored or overriden.

I confirmed my suspicion and checked the value of dotspacemacs-elpa-https after starting emacs with --insecure - sure enough it was set to true, even though the documentation explicitly states:

   ;; This variable has no effect if Emacs is launched with the parameter
   ;; `--insecure' which forces the value of this variable to nil.

Furthermore, in Messages buffer I saw:
... --insecure --port 443 elpa.gnu.org

...which doesn't make sense to me, port 443 and insecure are mutually exclusive. In any case if --insecure flag was obviously detected then the port shouldn't be set to 443.

[LachyTech]

As @syl20bnr suggested earlier about it being a timeout issue: increasing the (dotspacemacs-elpa-timeout) variable in core-dotspacemacs.el to 60s worked for me, even without running with the --insecure argument. I'm in Australia.

[bingxiao]

@LachyTech It works for me too. Thanks a lot.

diff --git a/core/core-dotspacemacs.el b/core/core-dotspacemacs.el
index af89594..bec185e 100644
--- a/core/core-dotspacemacs.el
+++ b/core/core-dotspacemacs.el
@@ -58,7 +58,7 @@ or `spacemacs'.")
 possible. Set it to nil if you have no way to use HTTPS in your
 environment, otherwise it is strongly recommended to let it set to t.")

-(defvar dotspacemacs-elpa-timeout 5
+(defvar dotspacemacs-elpa-timeout 50
   "Maximum allowed time in seconds to contact an ELPA repository.")

 (defvar dotspacemacs-configuration-layer-path '()

[danShumway]

Same results as @Cpt0r. My guess is that dotspacemacs-elpa-https overrides the --insecure flag.

[mimoralea]

Thanks for the patch @LachyTech. That did it for me too.

[ghost]

Has there been any progress with the Issue? I wanted to give spacemacs a first try but this issue is holding me away from it. I'm behind a corparate proxy and in an ubuntu vm. With my default emacs configuration everything works and connection to melpa is established via the url-proxy-services. I'm somehow helpless, as --debug-init returns nothing here and all fixes above do not work for me. Suggestions?

[costa]

TL;DR something happened between d822241 and the current master screwing the package installation, please debug

First, kudos for this project to all involved, I hope it will keep Emacs on the right track.
Then, this is one major issue I've experienced in the several months that I'm with Spacemacs, so to me, it's of the highest priority. Now I wish I was fluent with Lisp and could contribute, but alas.
Now here's what I just experienced:

• start with very modestly configured (almost default) Spacemacs installation which works well
• add javascript layer to .spacemacs
• restart Emacs
• watch the bootstrap fail miserably with network errors etc.
• restart Emacs hoping it will go away
• watch the bootstrap fail miserably with network errors etc. again
• find this issue, read comments, checkout d822241
• restart Emacs with mixed feelings
• watch it mostly pass the layer installation and startup
• checkout master (aka latest version) back
• restart Emacs out of curiosity
• watch it work flawlessly again

[syl20bnr]

Closing this issue since we are now in 0.200.0
@costa please open a fresh issue if you still have problem, thank you!

[costa]

@syl20bnr Thanks, it's okay now. The upgrade procedure itself probably has some issues — it doesn't refresh the packages upon switching to the new version (clicking on the UP in the status bar), only on the following manual restart — but it succeeds eventually, so this is clearly not a priority.