Closed drcxd closed 8 months ago
Please share the output of M-x elpaca-info
for vertico.
there are some other failed packages due to other reasons. I guess we should discuss about them in a separate issue in the future.
Yes, please.
Hi, I have tested the same configuration on a Linux machine and everything works fine. It might be a platform issue. However, on another Windows machine, when I try to replicate the issue, I can not make elpaca work.
Package Status Info Time ▼
elpaca failed No recipe: (file-missing "Opening directory" "No such file or directory" "e:/emacs_home/.emacs.d/elpaca/cache/melpa/recipes/") 145.383414
elpaca-use-package failed No recipe: (file-missing "Opening directory" "No such file or directory" "e:/emacs_home/.emacs.d/elpaca/cache/melpa/recipes/") 310.751292
It looks like a network issue, though I do have a proxy which can make me connect to github. I can clone repositories on the command line.
If you're able to, please evaluate the following test form on that Window's machine in your *scratch* buffer:
(require 'elpaca-test)
(elpaca-test)
A result buffer should pop up after the test has finished. Please copy the contents here.
elpaca | 6e352ba HEAD -> master, origin/master, origin/HEAD |
installer | 0.6 |
emacs | GNU Emacs 30.0.50 (build 2, x86_64-w64-mingw32) of 2023-12-10 |
git | git version 2.33.1.windows.1 |
Looks like elpaca can't establish a connection to melpa repository? However, I have tested on my PowerShell terminal:
PS E:\workplace> git clone https://github.com/melpa/melpa.git
Cloning into 'melpa'...
remote: Enumerating objects: 49053, done.
remote: Counting objects: 100% (3120/3120), done.
remote: Compressing objects: 100% (200/200), done.
remote: Total 49053 (delta 2959), reused 3047 (delta 2917), pack-reused 45933
Receiving objects: 100% (49053/49053), 12.67 MiB | 8.44 MiB/s, done.
Resolving deltas: 100% (25764/25764), done.
Updating files: 100% (5760/5760), done.
Not sure why this is happening.
Debugger entered--Lisp error: (error "Unable to clone MELPA: (1 nil \"fatal: unable to access 'https://github.com/melpa/melpa.git/': Failed to connect to github.com port 443 after 21078 ms: Timed out\n\")") error("Unable to clone MELPA: %S" (1 nil "fatal: unable to access 'https://github.com/melpa/melpa.git/': Failed to connect to github.com port 443 after 21078 ms: Timed out\n")) elpaca-menu-melpa--clone("c:/Users/drcxd/AppData/Local/Temp/elpaca.4voyFC/elpaca/cache/melpa/")
Looks like elpaca can't establish a connection to melpa repository?
Given the error above, yes, that is the case. The connection is timing out.
However, I have tested on my PowerShell terminal:
How about trying to clone it from within Emacs by evaluating the following form in your *scratch* buffer:
(with-current-buffer (get-buffer-create "*melpa-clone-test*")
(erase-buffer)
(let ((default-directory (temporary-file-directory)))
(call-process "git" nil t t "clone" "https://github.com/melpa/melpa.git/"))
(display-buffer (current-buffer)))
It should display a buffer, *melpa-clone-test*, which will show the output of the git process. Share the output of that buffer once the process terminates.
You mentioned you've got a proxy set up. I imagine that may be in play here. While PowerShell works, maybe Emacs is having trouble making a network connection. Another option would be to disable the proxy to see if it Emacs is able to clone without that.
The output of the melpa-clone-test buffer:
Cloning into 'melpa'...
Updating files: 73% (4206/5760)
Updating files: 74% (4263/5760)
Updating files: 75% (4320/5760)
Updating files: 76% (4378/5760)
Updating files: 77% (4436/5760)
Updating files: 78% (4493/5760)
Updating files: 79% (4551/5760)
Updating files: 80% (4608/5760)
Updating files: 81% (4666/5760)
Updating files: 82% (4724/5760)
Updating files: 83% (4781/5760)
Updating files: 84% (4839/5760)
Updating files: 85% (4896/5760)
Updating files: 86% (4954/5760)
Updating files: 87% (5012/5760)
Updating files: 88% (5069/5760)
Updating files: 89% (5127/5760)
Updating files: 90% (5184/5760)
Updating files: 91% (5242/5760)
Updating files: 92% (5300/5760)
Updating files: 93% (5357/5760)
Updating files: 94% (5415/5760)
Updating files: 95% (5472/5760)
Updating files: 96% (5530/5760)
Updating files: 97% (5588/5760)
Updating files: 98% (5645/5760)
Updating files: 99% (5703/5760)
Updating files: 100% (5760/5760)
Updating files: 100% (5760/5760), done.
In my current network environment, when using package.el, if the proxy is absent, then Emacs may not be able to connect to melpa, elpa, etc..
Disabling the proxy and executing (elpaca-test)
produce the following:
elpaca | 6e352ba HEAD -> master, origin/master, origin/HEAD |
installer | 0.6 |
emacs | GNU Emacs 30.0.50 (build 2, x86_64-w64-mingw32) of 2023-12-10 |
git | git version 2.33.1.windows.1 |
The output of the melpa-clone-test buffer
Looks like it cloned successfully there.
Failed to connect to 127.0.0.1 port 7078 after 2088 ms: Connection refused
And it looks like disabling your proxy didn't work.
I've pushed a slight change to a testing branch. Try this out:
(elpaca-test :ref "fix/247")
Failed to connect to 127.0.0.1 port 7078 after 2088 ms: Connection refused
And it looks like disabling your proxy didn't work.
I made a mistake here, I simply disabled the proxy but I forgot to change the proxy settings of git, so git still tries to connect to the proxy and failed. According to my experience, the proxy is necessary if I want a stable connection to github, that's why I establish it. Disabling it makes using git on the command line almost impossible.
I've pushed a slight change to a testing branch. Try this out:
(elpaca-test :ref "fix/247")
Can I evaluate this directly? Do I need to pull some changes or do something else? If not, evaluating this yields a lisp error:
Debugger entered--Lisp error: (error "raw.githubusercontent.com/443 getaddrinfo error 11004")
open-network-stream("raw.githubusercontent.com" #<buffer *url-http-temp*> "raw.githubusercontent.com" 443 :nowait nil :tls-parameters nil :coding nil)
open-gnutls-stream("raw.githubusercontent.com" #<buffer *url-http-temp*> "raw.githubusercontent.com" 443 (:type tls :nowait nil))
network-stream-open-tls("raw.githubusercontent.com" #<buffer *url-http-temp*> "raw.githubusercontent.com" 443 (:type tls :nowait nil))
open-network-stream("raw.githubusercontent.com" #<buffer *url-http-temp*> "raw.githubusercontent.com" 443 :type tls :nowait nil)
url-open-stream("raw.githubusercontent.com" #<buffer *url-http-temp*> "raw.githubusercontent.com" 443 tls)
url-http-find-free-connection("raw.githubusercontent.com" 443 tls)
url-http(#s(url :type "https" :user nil :password nil :host "raw.githubusercontent.com" :portspec nil :filename "/progfolio/elpaca/fix/274/doc/init.el" :target nil :attributes nil :fullness t :silent silent :use-cookies nil :asynchronous nil) #f(compiled-function (&rest args) #<bytecode 0x147d28beaf8f2aef>) (nil) nil tls)
url-https(#s(url :type "https" :user nil :password nil :host "raw.githubusercontent.com" :portspec nil :filename "/progfolio/elpaca/fix/274/doc/init.el" :target nil :attributes nil :fullness t :silent silent :use-cookies nil :asynchronous nil) #f(compiled-function (&rest args) #<bytecode 0x147d28beaf8f2aef>) (nil))
url-retrieve-internal("https://raw.githubusercontent.com/progfolio/elpaca/fix/274/doc/init.el" #f(compiled-function (&rest args) #<bytecode 0x147d28beaf8f2aef>) (nil) silent inhibit-cookies)
url-retrieve("https://raw.githubusercontent.com/progfolio/elpaca/fix/274/doc/init.el" #f(compiled-function (&rest args) #<bytecode 0x147d28beaf8f2aef>) nil silent inhibit-cookies)
url-retrieve-synchronously("https://raw.githubusercontent.com/progfolio/elpaca/fix/274/doc/init.el" silent inhibit-cookies)
elpaca-test--upstream-init("fix/274")
elpaca--test-write-init(nil "fix/274" nil)
(let* ((default-directory "c:/Users/drcxd/AppData/Local/Temp/elpaca.PM7i7R") (procname (format "elpaca-test-%s" default-directory)) (buffer (generate-new-buffer procname))) (if (file-exists-p default-directory) nil (make-directory default-directory 'parents)) (elpaca--test-write-init nil '"fix/274" 'nil) (if buffer (progn (elpaca-test--format-output-buffer buffer "(elpaca-test\n :ref \"fix/274\")\n"))) (elpaca-test--make-process procname buffer (elpaca-test--command 'nil t nil 'nil) (cons ':computed-dir (cons default-directory '(:ref ("fix/274"))))) (elpaca-test--announce nil "fix/274"))
(progn (let* ((default-directory "c:/Users/drcxd/AppData/Local/Temp/elpaca.PM7i7R") (procname (format "elpaca-test-%s" default-directory)) (buffer (generate-new-buffer procname))) (if (file-exists-p default-directory) nil (make-directory default-directory 'parents)) (elpaca--test-write-init nil '"fix/274" 'nil) (if buffer (progn (elpaca-test--format-output-buffer buffer "(elpaca-test\n :ref \"fix/274\")\n"))) (elpaca-test--make-process procname buffer (elpaca-test--command 'nil t nil 'nil) (cons ':computed-dir (cons default-directory '(:ref ("fix/274"))))) (elpaca-test--announce nil "fix/274")))
eval((progn (let* ((default-directory "c:/Users/drcxd/AppData/Local/Temp/elpaca.PM7i7R") (procname (format "elpaca-test-%s" default-directory)) (buffer (generate-new-buffer procname))) (if (file-exists-p default-directory) nil (make-directory default-directory 'parents)) (elpaca--test-write-init nil '"fix/274" 'nil) (if buffer (progn (elpaca-test--format-output-buffer buffer "(elpaca-test\n :ref \"fix/274\")\n"))) (elpaca-test--make-process procname buffer (elpaca-test--command 'nil t nil 'nil) (cons ':computed-dir (cons default-directory '(:ref ...)))) (elpaca-test--announce nil "fix/274"))) t)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
command-execute(eval-last-sexp)
I searched for the error number and there is a suggestion that adding
199.232.68.133 raw.githubusercontent.com
to the hosts
may fix my problem. I tried and it did work. However, there is a new error:
Debugger entered--Lisp error: (error "Unable to download \"https://raw.githubusercontent.com/progfolio/elpaca/fix/274/doc/init.el\" 404")
error("Unable to download %S %S" "https://raw.githubusercontent.com/progfolio/elpaca/fix/274/doc/init.el" 404)
elpaca-test--upstream-init("fix/274")
elpaca--test-write-init(nil "fix/274" nil)
(let* ((default-directory "c:/Users/drcxd/AppData/Local/Temp/elpaca.tKLoZ0") (procname (format "elpaca-test-%s" default-directory)) (buffer (generate-new-buffer procname))) (if (file-exists-p default-directory) nil (make-directory default-directory 'parents)) (elpaca--test-write-init nil '"fix/274" 'nil) (if buffer (progn (elpaca-test--format-output-buffer buffer "(elpaca-test\n :ref \"fix/274\")\n"))) (elpaca-test--make-process procname buffer (elpaca-test--command 'nil t nil 'nil) (cons ':computed-dir (cons default-directory '(:ref ("fix/274"))))) (elpaca-test--announce nil "fix/274"))
(progn (let* ((default-directory "c:/Users/drcxd/AppData/Local/Temp/elpaca.tKLoZ0") (procname (format "elpaca-test-%s" default-directory)) (buffer (generate-new-buffer procname))) (if (file-exists-p default-directory) nil (make-directory default-directory 'parents)) (elpaca--test-write-init nil '"fix/274" 'nil) (if buffer (progn (elpaca-test--format-output-buffer buffer "(elpaca-test\n :ref \"fix/274\")\n"))) (elpaca-test--make-process procname buffer (elpaca-test--command 'nil t nil 'nil) (cons ':computed-dir (cons default-directory '(:ref ("fix/274"))))) (elpaca-test--announce nil "fix/274")))
eval((progn (let* ((default-directory "c:/Users/drcxd/AppData/Local/Temp/elpaca.tKLoZ0") (procname (format "elpaca-test-%s" default-directory)) (buffer (generate-new-buffer procname))) (if (file-exists-p default-directory) nil (make-directory default-directory 'parents)) (elpaca--test-write-init nil '"fix/274" 'nil) (if buffer (progn (elpaca-test--format-output-buffer buffer "(elpaca-test\n :ref \"fix/274\")\n"))) (elpaca-test--make-process procname buffer (elpaca-test--command 'nil t nil 'nil) (cons ':computed-dir (cons default-directory '(:ref ...)))) (elpaca-test--announce nil "fix/274"))) t)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
command-execute(eval-last-sexp)
I guess my OS and network environment are also responsible for this problem. However, I do not think manually add something to hosts
can become part of the solution of the problem. I mean, I may forget about it when I am on another machine. Due to my lack of understanding of computer network, I do not know if this (adding hosts
configuration) can be circumvented programmatically.
I am trying to use elpaca because I want to install a package that is only available on github. Actually, I am content with my package.el workflow before I need such a package. If using elpaca costs too much (considering my network environment), I may be satisfied just using package.el plus git submodule.
I am glad to use elpaca (if possible) and if you still want to research on this issue, I am also glad to help you do the tests and give feedback. However, if you do not want to spend time on it due to its particularity, I totally understand and agree with you.
Thank you!
I've pushed a slight change to a testing branch. Try this out:
emacs-lisp (elpaca-test :ref "fix/247")
Can I evaluate this directly? Do I need to pull some changes or do something else? If not, evaluating this yields a lisp error:
Debugger entered--Lisp error: (error "raw.githubusercontent.com/443 getaddrinfo error 11004") ...
Yes, the test should "just work" if evaluated in the *scratch* buffer. It looks like a different networking issue, though.
I searched for the error number and there is a suggestion that adding
I guess my OS and network environment are also responsible for this problem.
Yes, unfortunately I'm not able to reproduce this on my end.
However, I do not think manually add something to
hosts
can become part of the solution of the problem. I mean, I may forget about it when I am on another machine. Due to my lack of understanding of computer network, I do not know if this (addinghosts
configuration) can be circumvented programmatically.I am trying to use elpaca because I want to install a package that is only available on github. Actually, I am content with my package.el workflow before I need such a package. If using elpaca costs too much (considering my network environment), I may be satisfied just using package.el plus git submodule.
I am glad to use elpaca (if possible) and if you still want to research on this issue, I am also glad to help you do the tests and give feedback. However, if you do not want to spend time on it due to its particularity, I totally understand and agree with you.
Thank you!
I say go with whatever is easiest. If package.el is working with your network configuration, I'd use that. I appreciate you testing, and will keep this noted here in case anyone else runs into a similar issue. Thanks.
Confirmation
Elpaca Version
Elpaca 6e352ba HEAD -> master, origin/master, origin/HEAD installer: 0.6 emacs-version: GNU Emacs 30.0.50 (build 2, x86_64-w64-mingw32) of 2024-01-03 git --version: git version 2.32.0.windows.2
Operating System
Windows
Description
I am trying to switch from native package.el to elpaca, since I want to install a package only available on github. I have added the installer script to the begining of the init.el. I have also used the
elpaca-nosymlink-mode
. Then I have enabled the use-package integration.After I restart my Emacs, the elpaca-log buffer shows that several packages fail to install. consult, org-modern, vertico among them, all come from the same author. The failing reasons listed in the info column are the same, except the package name, for these three packages:
My config for vertico is:
I have checked the files in
~/.emacs.d/elpaca/repos/vertico
and there is only a.git
directory.I have tried to add the following code in the use-package declaration:
but it does not improve anything.
There is another package, lsp-mode, failed for the same reason. And there are some other failed packages due to other reasons. I guess we should discuss about them in a separate issue in the future.