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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48444 in the body.
You can then email your comments to 48444 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: arthur.miller <at> live.com
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; package.el wrong path for package-gnupghome-dir on win10
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.


Configured using:
 'configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
 --build=x86_64-w64-mingw32 --with-cairo --without-modules
 --without-compress-install --with-x-toolkit=no --with-gnutls
 --without-gconf --without-xwidgets --without-xaw3d --without-gsettings
 --with-mailutils --with-native-compilation 'CFLAGS=-O3 -mtune=native
 -march=native -fomit-frame-pointer' build_alias=x86_64-w64-mingw32
 host_alias=x86_64-w64-mingw32 target_alias=x86_64-w64-mingw32
 PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'

Configured features:
ACL DBUS GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

Important settings:
  value of $LC_CTYPE: sv_SE.UTF-8
  value of $LANG: SVE
  locale-coding-system: cp1252

Major mode: Org

Minor modes in effect:
  org-init-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
c:/msys64/mingw64/share/emacs/28.0.50/lisp/transient hides c:/Users/arthu/.emacs.d/elpa/transient-20210426.2141/transient
c:/Users/arthu/.emacs.d/lisp/company-cmake hides c:/Users/arthu/.emacs.d/elpa/company-20210513.1853/company-cmake
c:/Users/arthu/.emacs.d/lisp/bind-key hides c:/Users/arthu/.emacs.d/elpa/bind-key-20160227.48/bind-key

Features:
(shadow sort mail-extr emacsbug sendmail mm-archive gnutls
network-stream url-http url-gw nsm url-cache url-auth finder-inf
helm-easymenu info autoload radix-tree lisp-mnt package url-handlers
org-element avl-tree generator ol-eww eww xdg url-queue thingatpt mm-url
ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-search eieio-opt
speedbar ezimage dframe gnus-art mm-uu mml2015 mm-view mml-smime smime
dig gnus-sum shr kinsoku svg dom browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse url-vars mailcap gnus-group gnus-undo gnus-start gnus-dbus
dbus xml gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo parse-time
gnus-spec gnus-int gnus-range message rmc puny rfc822 mml mml-sec epa
derived epg epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader gnus-win gnus nnheader gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map rfc2047 rfc2045 ietf-drums mail-utils mm-util
mail-prsvr ol-docview doc-view jka-compr image-mode exif ol-bibtex
bibtex iso8601 ol-bbdb ol-w3m tmtxt-async-tasks eshell esh-cmd esh-ext
esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util term
shell ehelp recentf tree-widget comp comp-cstr rx cl-seq cl-extra
help-mode wid-edit dired-x wdired org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
pcomplete org-list org-faces org-entities time-date subr-x noutline
outline org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys
org-compat advice org-macs org-loaddefs format-spec find-func cal-menu
calendar cal-loaddefs edmacro kmacro cl-macs seq gv warnings easy-mmode
byte-opt compile text-property-search comint ansi-color ring bytecomp
byte-compile cconv dired-aux cl-loaddefs cl-lib dired dired-loaddefs
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify dbusbind w32 lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 500038 105238)
 (symbols 48 30566 1)
 (strings 32 138236 41347)
 (string-bytes 1 4157999)
 (vectors 16 55072)
 (vector-slots 8 1586872 150266)
 (floats 8 328 354)
 (intervals 56 6434 547)
 (buffers 992 26))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: arthur.miller <at> live.com
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 19:04:43 +0300

> 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.

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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Arthur Miller <arthur.miller <at> live.com>
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 22:17:51 +0300

> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: 48444 <at> debbugs.gnu.org
> Date: Sat, 15 May 2021 21:07:09 +0200
> 
> > 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?

How what got where?

> I didn't have any .bashrc or custom setuped files, everything was
> just default as installed. It seems like path was setup by msys.

Yes, installing MSYS will definitely change PATH, especially the one
that MSYS Bash uses.

> 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? 

If you start Emacs from MSYS Bash, then you should look in the MSYS
Bash startup files, perhaps in some etc directory?

If you start Emacs from cmd or from a desktop shortcut, then you can
edit the environment variables from Computer->Properties.

Message #17 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: Sun, 16 May 2021 13:40:18 +0200

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

>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: 48444 <at> debbugs.gnu.org
>> Date: Sat, 15 May 2021 21:07:09 +0200
>> 
>> > 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?
>
> How what got where?
Msys specific usr/bin and local/bin.

>> I didn't have any .bashrc or custom setuped files, everything was
>> just default as installed. It seems like path was setup by msys.
>
> Yes, installing MSYS will definitely change PATH, especially the one
> that MSYS Bash uses.

At that particular occasion I started it from mingw64 console as it
comes with msys2.

>> 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? 
>
> If you start Emacs from MSYS Bash, then you should look in the MSYS
> Bash startup files, perhaps in some etc directory?
>
> If you start Emacs from cmd or from a desktop shortcut, then you can
> edit the environment variables from Computer->Properties.

Yeah, I know I can set env vars in system props or via some script
:), I ment if Emacs can figure it out on it's own. It seems a bit
annoying if path will vary depending on how I start Emacs and it gives
different behaviour later on, so setq after start seems to work best for
me, at least I have total control what Emacs will see after start. 

Thanks for help.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: 48444 <at> debbugs.gnu.org
Subject: Re: bug#48444: 28.0.50; package.el wrong path for
 package-gnupghome-dir on win10
Date: Sun, 16 May 2021 14:47:17 +0300

> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: 48444 <at> debbugs.gnu.org
> Date: Sun, 16 May 2021 13:40:18 +0200
> 
> > If you start Emacs from cmd or from a desktop shortcut, then you can
> > edit the environment variables from Computer->Properties.
> 
> Yeah, I know I can set env vars in system props or via some script
> :), I ment if Emacs can figure it out on it's own. It seems a bit
> annoying if path will vary depending on how I start Emacs and it gives
> different behaviour later on, so setq after start seems to work best for
> me, at least I have total control what Emacs will see after start. 

That's a feature ;-)  You can control the Emacs behavior by changing
the environment variables in the shell from which you start Emacs.

My advice is to set the system properties and never start Emacs from
the MSYS Bash unless you want to try something that really needs the
MSYS executables.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Arthur Miller <arthur.miller <at> live.com>, 48444 <at> debbugs.gnu.org
Subject: Re: bug#48444: 28.0.50; package.el wrong path for
 package-gnupghome-dir on win10
Date: Wed, 13 Jul 2022 13:14:11 +0200

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

> My advice is to set the system properties and never start Emacs from
> the MSYS Bash unless you want to try something that really needs the
> MSYS executables.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this bug report, this doesn't seem to be about a problem on the
Emacs side (but instead a problem with mixing mingw/msys2 binaries), so
I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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