Closed n-raymond closed 4 years ago
Following in your error log caught my eye:
:name melpa.org :buffer #<killed buffer> :host 10.49.64.5
IP addressses starting with 10 are all intranet addresses, i.e., this cannot possibly be a valid IP address for any internet site. Following shows a more reasonable IP address:
$ ping melpa.org
PING melpa.org (178.128.185.1) 56(84) bytes of data.
Could your problem be related with IP configuration at your site?
Perhaps :host refers to the IP address of your own machine?
Thanks for your quick answer! :)
Well seen! 10.49.64.5
is the proxy IP at my current job.
I think my proxy configuration was still operational even if I was at home, even if I disabled it in my terminal because .spacemacs.env
file saved it (I just discovered this behaviour this morning).
This could explains why it fails only when installing a new package (since other packages are locally cached). However I don't understand why this only happens if commit 21551b6995e38110ce61fec58f608aa180b1d4fc
was applied. Shouldn't it fails every time when trying to access an unreachable proxy ? :thinking:
I will try asap to install a fresh layer from current develop branch after cleaning my environment and removing .spacemacs.env
file to see if this fixes the problem.
I think it was a mistake for spacemacs to save and restore environments. There are so many ways in which it could come back and bite us. That is why for me I have it disabled always by commenting out one line as shown here.
diff --git a/core/templates/.spacemacs.template b/core/templates/.spacemacs.template
index 7613ccc62..329acdf35 100644
--- a/core/templates/.spacemacs.template
+++ b/core/templates/.spacemacs.template
@@ -443,7 +443,11 @@ This function defines the environment variables for your Emacs session. By
default it calls `spacemacs/load-spacemacs-env' which loads the environment
variables declared in `~/.spacemacs.env' or `~/.spacemacs.d/.spacemacs.env'.
See the header of this file for more information."
- (spacemacs/load-spacemacs-env))
+ ;; Saving and loading environment is too risky when many different machines
+ ;; use the same emacs files! Perhaps the environment file name should include
+ ;; the hostname.
+ ;; (spacemacs/load-spacemacs-env)
+ )
(defun dotspacemacs/user-init ()
"Initialization for user code:
For most users, you can probably just edit ~/.spacemacs file to make above change if you want to make it.
@n-raymond I think this issue should be closed.
Thanks for your help I will use your workaround to disable it. This should solve my problem.
Issue closed ! :)
Hi !
Description :octocat:
I am curently using spacemacs on the
develop
branch. I have faced a problem recently when adding a new layer to my dotfile: Spacemacs does not reachmelpa.org
and other mirors when trying to download modules needed by the layer during the initialization. I first suspected a problem of proxy or firewall since I was doing this operation from work but the same thing was happening from my home where I don't have those constraints. I then noted this behaviour was not occuring on the master branch, so I tried to find the commit that introduced it usinggit bissect
and found it was commit21551b6995e38110ce61fec58f608aa180b1d4fc
. I also created a local branch from develop and reverted this commit and it solved my problem.I haven't really understood the goal of this commit but it clearly introduced a bug so I wanted to share this with you guys !
Reproduction guide :beetle:
develop
branch in my~/.emacs.d
directorySPC-f-e-d
and add a new layer that was not downloaded yet (so that it is not present in the cache or~/.emacs.d/elpa
folder)Observed behaviour: :eyes: :broken_heart:
Spacemacs can't reach
melpa.org
and other mirors, leading to timeouts when trying to download new pacakges. The following message appears in*spacemacs*
buffer:Expected behaviour: :heart: :smile:
The initialization phase should succeed to download those package and spacemacs should start normally.
System Info :computer:
Backtrace :paw_prints:
It was a real pain to get those debug traces using the
--debug-init
option: Since the initialization phase was not done, the key bindings was only partially working (I'm a evil user) and no transiant state menu was openning... I finally succeeded in copying a part of the buffer but I suspect this is not the complete log. Sorry for that!