+1
😞
This could be related to the migration to Linode, which has caused some problems recently, see this tweet.
adding the following lines should help until it comes back
(add-to-list 'package-archives '("melpa-mirror" . "http://www.mirrorservice.org/sites/melpa.org/packages/") t)
It looks like the server completely crashed and it’s unclear why. Trying to
reboot to unblock things.
On Wed, Nov 28, 2018 at 07:59 Guillermo Vayá notifications@github.com
wrote:
adding the following lines should help until it comes back
(add-to-list 'package-archives '("melpa-mirror" . "http://www.mirrorservice.org/sites/melpa.org/packages/") t)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/melpa/melpa/issues/5837#issuecomment-442456143, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACUsgP6CFDEfUJaOzZ0vO6UbzJb9znYks5uzpbSgaJpZM4Y3mNK
.
If you happen to be using Spacemacs develop branch, you can implement @Willyfrog's suggestion by modifying the .lock file in your in the directory where Spacemacs is installed (~/.emacs.d).
;; TODO: revert to melpa.org/packages/
(setq configuration-layer-elpa-archives
`(("melpa" . "http://www.mirrorservice.org/sites/melpa.org/packages/")
("org" . "orgmode.org/elpa/")
("gnu" . "elpa.gnu.org/packages/")
("spacelpa" . ,(concat configuration-layer-stable-elpa-directory
"spacelpa-"
configuration-layer-stable-elpa-version))))
It’s back up. It’s unclear what the problem was and I will investigate more
soon. From the console it looks like a kernel panic.
On Wed, Nov 28, 2018 at 09:43 Benjamin Zalasky notifications@github.com
wrote:
If you happen to be using Spacemacs develop branch, you can implement
Willyfrog's suggestion by modifying the .lock file in your in the directory
where Spacemacs is installed (~/.emacs.d).;; TODO: revert to melpa.org/packages/
(setq configuration-layer-elpa-archives
`(("melpa" . "http://www.mirrorservice.org/sites/melpa.org/packages/")
("org" . "orgmode.org/elpa/")
("gnu" . "elpa.gnu.org/packages/")
("spacelpa" . ,(concat configuration-layer-stable-elpa-directory
"spacelpa-"
configuration-layer-stable-elpa-version))))—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/melpa/melpa/issues/5837#issuecomment-442493622, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACUsulZaV11es0iUwXmOU_xqqBh6B2Sks5uzq8wgaJpZM4Y3mNK
.
Great, thanks!
This seems to have generated a lot of discussion elsewhere suggesting packages use Github releases for distribution.
Perhaps an alternative would be if Melpa used a CDN (Cloudflare, for instance) so it would remain available even if the hosting goes down.
This seems to have generated a lot of discussion elsewhere suggesting packages use Github releases for distribution.
Where's that? Curious to read up on people's experiences.
Perhaps an alternative would be if Melpa used a CDN (Cloudflare, for instance) so it would remain available even if the hosting goes down.
Maybe. It all takes time to set up, though, and an occasional blip in availability doesn't necessarily justify a lot of extra volunteer work, expense or complexity for a relatively non-critical service like this. MELPA does pretty well overall in terms of uptime IMO.
I'm sure I saw it on Hacker News somewhere, but that has no search.
Reddit has this.
IMO, MELPA's uptime is doing fine. There are alternative ways to install packages if it happens to be down and someone must install a certain package right now.
Most helpful comment
It’s back up. It’s unclear what the problem was and I will investigate more
soon. From the console it looks like a kernel panic.
On Wed, Nov 28, 2018 at 09:43 Benjamin Zalasky notifications@github.com
wrote: