GNU bug report logs - #48444
28.0.50; package.el wrong path for package-gnupghome-dir on win10

Previous Next

Full log

Message #11 received at 48444 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48444 <at> debbugs.gnu.org
Subject: Re: bug#48444: 28.0.50; package.el wrong path for
 package-gnupghome-dir on win10
Date: Sat, 15 May 2021 21:07:09 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: arthur.miller <at> live.com
>> Date: Sat, 15 May 2021 17:07:58 +0200
>> 
>> Recipe: start Emacs started -Q flag from mingw64 bash prompt (msys2).
>> 
>> I have freshly installed msys2 + deps + Emacs 28.0.50 from
>> master. Package installation failes due to some problem with how path for
>> `package-gnupghome-dir' is interpreted/setuped. Don't know really,
>> haven't investigated myself. Paths originally evals to:
>> "c:/Users/arthu/.emacs.d/elpa/gnupg" which is correct, but somehow
>> Emacs/package.el does not understands it or pass it wrongly to gpg;
>> since gpg ends up with this path:
>> 
>> /c/Users/arthu/.emacs.d/c:/Users/arthu/.emacs.d/elpa/gnupg/pubring.kbx.
>> 
>> I am pasting the error I get when trying go install a package:
>> 
>> Failed to verify signature archive-contents.sig:
>> No public key for 066DAFCB81E42C40 created at 2021-05-13T23:10:01+0200 using RSA
>> Command output:
>> gpg: keyblock resource '/c/Users/arthu/.emacs.d/c:/Users/arthu/.emacs.d/elpa/gnupg/pubring.kbx': No such file or directory
>> gpg: Signature made Thu May 13 23:10:01 2021    
>> gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
>> gpg: Can't check signature: No public key
>> 
>> If I setq path to use Unix prefix '/c/...' instead of 'C:/...' things
>> seems to work:
>> 
>> (setq package-gnupghome-dir "/c/Users/arthu/.emacs.d/elpa/gnupg")
>> 
>> Not sure if it is Emacs bug or on gpg side, but it is an issue.
>
> Looks like you are mixing MSYS2 executables and native Windows
> (a.k.a. "MinGW") executables, and that is at least part of the problem
> if not all of it.
>
> You should only use MinGW executables with a MinGW Emacs.

Indeed, seems to have been the problem. After I manually purged
c:/msys64/usr/bin and c:/msys64/usr/bin from exec-path, I was able to
install packages and create/compile init file.

Any idea how it got there? I didn't have any .bashrc or custom setuped
files, everything was just default as installed. It seems like path was
setup by msys.

I see when I start new process that exec path have those and they take
precedence before mingw:

("c:/msys64/mingw64/bin" "c:/msys64/usr/bin" "c:/msys64/mingw64/bin"
"C:/msys64/usr/local/bin" "C:/msys64/usr/bin" "C:/msys64/usr/bin"
"C:/Windows/System32" "C:/Windows" "C:/Windows/System32/Wbem"
"C:/Windows/System32/WindowsPowerShell/v1.0/"
"C:/msys64/usr/bin/site_perl" "C:/msys64/usr/bin/vendor_perl" ...)

Do I have any option other than to manually setq exec-path in
after-init-hook? 

Ouupps, seems like some random text make it to the list; sorry wasn't
ment, I must have sent it away by accident.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.