-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emacs fails to connect to MELPA, starting several days ago? #156
Comments
I realized this issue just now by rerun some workflows I had. It seems like connection error from Melpa, but I don't know why. 😕 |
I've been trying to figure this out, this afternoon, also. What changed a few days ago?
Thank you again for making this repo! I'm sorry to disturb you with questions about it. |
Not really. The last change from source code is 6 months ago. The rest are dependency updates from
I don't know about this, but I think it's a good guess since it suddenly happened without me changing anything to this repository. Let me ping some of the Melpa maintainers, maybe they would know... @purcell @tarsius Is there a specific changes so Melpa doesn't response to CI on Windows? 😕
I didn't make those changes, it was originally created by ericdallo. You can find the more update to date CI configuration in csharp-mode/.github/workflows/build.yml. As you can see, it can be used with cask without any special configuration (platform specific). |
I've been doing some experimental hacks. One thing I saw from Emacs Windows snaphot, using emacs --batch -Q -L . --eval '(package-initialize)' \ --eval '(add-to-list (quote package-archives) (cons "melpa" "http://melpa.org/packages/"))' \ --eval '(package-initialize)' \ --eval '(package-refresh-contents)' \ --eval '(package-install (quote faceup))' \ --eval '(package-install (quote paredit))' \ --eval '(package-install (quote pos-tip))' Importing package-keyring.gpg... Importing package-keyring.gpg...done Contacting host: melpa.org:80 Debugger entered--Lisp error: (error "Could not create connection to melpa.org:443") signal(error ("Could not create connection to melpa.org:443")) error("Could not create connection to %s:%d" "melpa.org" 443) url-http(#s(url :type "https" :user nil :password nil :host "melpa.org" :portspec nil :filename "/packages/archive-contents" :target nil :attributes nil :fullness t :silent nil :use-cookies t :asynchronous nil) #f(compiled-function (&rest ignored) #) ((:redirect "https://melpa.org/packages/archive-contents")) nil tls) url-https(#s(url :type "https" :user nil :password nil :host "melpa.org" :portspec nil :filename "/packages/archive-contents" :target nil :attributes nil :fullness t :silent nil :use-cookies t :asynchronous nil) #f(compiled-function (&rest ignored) #) ((:redirect "https://melpa.org/packages/archive-contents"))) url-retrieve-internal("https://melpa.org/packages/archive-contents" #f(compiled-function (&rest ignored) #) ((:redirect "https://melpa.org/packages/archive-contents")) nil nil) url-http-parse-headers() url-http-content-length-after-change-function(203 366 163) url-http-wait-for-headers-change-function(1 374 373) url-http-generic-filter(# "HTTP/1.1 301 Moved Permanently\15\nServer: nginx\15\nDat...") accept-process-output(# 1) url-retrieve-synchronously("http://melpa.org/packages/archive-contents") package--with-response-buffer-1("http://melpa.org/packages/" #f(compiled-function () #) :file "archive-contents" :async nil :error-function #f(compiled-function () #) :noerror nil) package--download-one-archive(("melpa" . "http://melpa.org/packages/") "archive-contents" nil) package--download-and-read-archives(nil) package-refresh-contents() eval((package-refresh-contents) t) command-line-1(("-L" "." "--eval" "(package-initialize)" "--eval" "(add-to-list (quote package-archives) (cons \"melpa..." "--eval" "(package-initialize)" "--eval" "(package-refresh-contents)" "--eval" "(package-install (quote faceup))" "--eval" "(package-install (quote paredit))" "--eval" "(package-install (quote pos-tip))")) command-line() normal-top-level() So it seems likely this is due to something changing in the neighborhood of SSL and/or certificates. Changed where? Maybe at https://github.com/actions/virtual-environments, but a quick glance at their commit history, I didn't see. (Although an SSL issue on macOS). But even if their build script didn't change, maybe the build refreshed and pulled a newer dependency. (I don't know all the pieces and how they work.) |
p.s. Also it is failing to download (via https) all of the archives It seems to be a general https/SSL/TLS issue, for Emacs (and more?) in the GitHub Actions Windows virtual environment. |
Thanks for the investigation! I think you got it right, would you mind report it to the upstream? Not sure if this is enough for them to find out the issue. 😅 |
If you don't mind, I think it would be more effective if you reported it? You're closer to upstream. Not only will you have more credibility, you'll be better able to answer any follow-up questions they might have? (I don't really understand the GitHub Actions ecosystem beyond the user-facing side... and sometimes I think I barely understand that!) p.s. I wonder if it might somehow be related to this which I just came here to mention: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/. I'm starting to see tweets etc. about other sites breaking. And the timing --- a few days ago --- is about right. |
I hacked my
and guess what, it works! So, I think this actually won't be an issue for the actions/virtual-environments repo? Instead, it seems more likely to do with Windows Emacs and how it is using TLS and certificates? So it might (unfortunately) turn out to be an issue for this repo, and/or for the Windows Emacs build itself. p.s. As a work-around in my yml I'm tempted to add some hacky steps to use curl to download directly into each of the |
I think this is certainly the issue from Emacs's Windows binaries. BTW, this issue seems to disappear in Emacs version
Would you like yo share your workaround here? Maybe we can merge this to this repo? 😅 |
Thanks! Before seeing that, I came here to report this work-around: greghendershott/racket-mode@c3eb98d That is, I figured this out by powering up a real Windows laptop, seeing that it prompts about the certificate, and finding that prompt message in On the one hand, this is a bad hack that should be removed once the situation is resolved. It's good for packages to be downloaded encrypted, even if only for CI. On the other hand, in my Makefile this is done only for a single invocation of Emacs that installs the packages. p.s. I was seeing |
This is likely an issue with the pre-built Emacs 27.2 archive for Windows from GNU's FTP, which probably includes its own outdated bundle of CA certs. My temporary workaround is using |
Hi, the issue is due to a bug in the GnuTLS version that comes with Emacs 27.2, that it does not honour a renewed root certificate in the presence of an expired one (in our case the one expired is the DST Root CA X3 certificate). A solution is to remove the expired certificate from the Windows certificate store, so that it gives a chance to GnuTLS to consult the renewed one. In terms of a GitHub workflow - name: Workaround for Emacs 27.2 bug on MS-Windows
run: |
# Remove expired DST Root CA X3 certificate. Workaround
# for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51038
# bug on Emacs 27.2.
gci cert:\LocalMachine\Root\DAC9024F54D8F6DF94935FB1732638CA6AD77C13
gci cert:\LocalMachine\Root\DAC9024F54D8F6DF94935FB1732638CA6AD77C13 | Remove-Item (background info: clojure-emacs/cider#3110) |
@ikappaki That sounds like a better solution than my hack, for testing against Emacs 27.2. Because I'm testing only the latest version of Emacs, on Windows, and because 28.1 doesn't have this problem, that's going to be my resolution for this, personally. (My project supports X versions of Emacs and Y versions of Racket. That's very many jobs, even before doubling by platform P. So I'm being more selective.) @jcs090218 I'd be happy to close this issue, if you want? The work-arounds in this thread would still be available for people who need 27.2. |
@greghendershott Yes! Thank you so much! I appreciate everyone who participate in this thread since I don't have enough knowledge to provide a good solution/workaround! 😓 (Edit: noticed I have also pinned this issue, so users should be able to find this issue easily.) |
@jcs090218 Thank you for providing such a useful resource to support people developing Emacs packages. For many years I did something similar, for Racket language on Travis CI. So I know first-hand. As the old saying goes, "no good deed goes unpunished". Thank you very much! |
Thank you so much for providing this GitHub Action!
I'm sorry to disturb you with a question.
Successful example
I've been using this successfully for some months now.
An example run is here, in the "Install Emacs Packages" node:
Success details
Failure example
But starting a few days ago, this step fails.
An example run is here, in the "Install Emacs Packages" node:
Failure details
Noting in the workflow
.yml
or has changed.All the Linux jobs still handle this step 100% OK.
Only the Windows job using your Emacs Windows build has started failing.
The first day or two, I ignored the error, thinking maybe it was some unique to Windows MELPA connectivity problem that would be fixed.
But it's still not working, and I'm not sure what to do.
Has anyone else seen this? Any ideas what parts might have changed?
Sorry in advance if I'm being dumb.
The text was updated successfully, but these errors were encountered: