Melpa: Bad Request error

[xerz-one]

At the beginning of my .init.el file, I have the following bunch of code:

(package-initialize)

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

(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

This works perfectly fine on my Emacs 25.2.2 on Ubuntu 18.10, but then on my Emacs 26.1 on Musl Void Linux I get the following error (with debug-on-error enabled)

Debugger entered--Lisp error: (file-error "https://melpa.org/packages/archive-contents" "Bad Request")
  signal(file-error ("https://melpa.org/packages/archive-contents" "Bad Request"))
  package--download-one-archive(("melpa" . "https://melpa.org/packages/") "archive-contents" nil)
  package--download-and-read-archives(nil)
  package-refresh-contents()
  (if (package-installed-p 'use-package) nil (package-refresh-contents) (package-install 'use-package))
  eval-buffer()  ; Reading at buffer position 238
  funcall-interactively(eval-buffer)
  call-interactively(eval-buffer nil nil)
  command-execute(eval-buffer)

I tried to check the URL (including switching between HTTP and HTTPS) to no avail. Manually downloading from Firefox, curl and wget works, but if I try to use eww within Emacs it seems to hang. I wonder if it's a distro-specific issue with Emacs or there's something going on with MELPA.

[DanLanglois]

Here is your case:

--I had an internet connection.
--As far as I was aware, Melpa was up.
--It hung with no immediately discoverable cause.

Well, I ponder, that who knows about bad internet connection, walls and other stuff.

If we say 'gateway timeout' then actually, you know, DNS lookups time out. Thus, when I run into this sort of thing the first thought I have, is to just edit resolv.conf and add nameserver 8.8.8.8, but it will likely be overwritten at some point so that is just a temporary fix. The general idea is to get into manually configuring your Linux computer with other DNS server addresses. Or maybe my advice is the opposite of what you need -- I've heard of melpa.org becoming unresolvable if using Google's DNS resolvers (8.8.8.8 and 8.8.4.4). What happens if you try this?:

dig NS melpa.org @8.8.8.8

That is, I want to check the authoritative DNS servers for a domain. I'm wondering about DNS propagation delay or such. Or try this:

dig NS melpa.org @208.67.222.222

The idea is to see whether trying on other recursive resolvers (ISP resolvers etc), has melpa.org resolve correctly -- maybe you want for something to clear Google's DNS cache or whatever is causing this. Also, you may find that 'the issue cleared itself'. I'm going on and on about how maybe 'It's just a DNS thing', only because I've seen this. I look at what's new in emacs 26.1, and I get nervous when I read this:

'The networking code has been reworked so that it's more
asynchronous than it was (when specifying :nowait t in
'make-network-process'). How asynchronous it is varies based on the
capabilities of the system, but on a typical GNU/Linux system the DNS
resolution, the connection, and (for TLS streams) the TLS negotiation
are all done without blocking the main Emacs thread.'

I dunno, sounds like so many timers running at one time. It's a theory..

Also a note -- I'm looking at your 'bunch of code':

(package-initialize)

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

(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

And, I'm checking melpa documentation, and noticing this:

(require 'package)
(let* ((no-ssl (and (memq system-type '(windows-nt ms-dos))
                    (not (gnutls-available-p))))
       (proto (if no-ssl "http" "https")))
  (when no-ssl
    (warn "\
Your version of Emacs does not support SSL connections,
which is unsafe because it allows man-in-the-middle attacks.
There are two things you can do about this warning:
1. Install an Emacs version that does support SSL and be safe.
2. Remove this warning from your init file so you won't see it again."))
  ;; Comment/uncomment these two lines to enable/disable MELPA and MELPA Stable as desired
  (add-to-list 'package-archives (cons "melpa" (concat proto "://melpa.org/packages/")) t)
  ;;(add-to-list 'package-archives (cons "melpa-stable" (concat proto "://stable.melpa.org/packages/")) t)
  (when (< emacs-major-version 24)
    ;; For important compatibility libraries like cl-lib
    (add-to-list 'package-archives (cons "gnu" (concat proto "://elpa.gnu.org/packages/")))))
(package-initialize)

Here: https://melpa.org/#/getting-started

In particular I see what apparently needs to happen before the call to package-initialize. You need, I think, to enable installation of packages from MELPA by adding an entry to package-archives, before the call to package-initialize. I have no idea about whether this is significant..

[purcell]

This works perfectly fine on my Emacs 25.2.2 on Ubuntu 18.10, but then on my Emacs 26.1 on Musl Void Linux I get the following error (with debug-on-error enabled)

If eww doesn't work then it sounds like your Emacs doesn't support HTTPS -- this isn't a MELPA issue. If eww works with, say, https://github.com but not MELPA, then it might be a certificate store issue.

[xerz-one]

Wow, @DanLanglois that seems to have fixed it, thanks! I'll make sure everything is fine and I'll close the ticket.

@purcell nope, I can open other HTTPS websites just fine, and as I said HTTP didn't work either

[xerz-one]

Update: First off, reading my init.el again, I feel dumb for trying to do (package-initialize) before even doing (require 'package) first. Definitely need to get more used to Emacs Lisp.

It seems like it works the second time you boot up Emacs, very likely my fault there for not initializing stuff properly. That's much better than "never", so I'll just try to further find out what's going on. Thanks a lot!

[purcell]

Glad you figured it out. And thanks @DanLanglois for jumping in with a fix: I should have read the sample snippet more carefully myself!

[xdavidliu]

Wow, @DanLanglois that seems to have fixed it, thanks! I'll make sure everything is fine and I'll close the ticket.

What was the fix? The post is very long and offers several theories and fixes. Can you please share which particular one fixed your issue?

[xerz-one]

@xdavidliu I just moved package-initialize below iirc

[purcell]

Yes, you'd absolutely have to modify package-archives before calling package-initialize.