bug#42984: 27.1; package-list results in error while updating archive due to malformed path

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Mirko Vukovic]

[-- Attachment #1: Type: text/plain, Size: 5325 bytes --]

This report mirrors the issue I submitted to Spacemacs as issue 13866. This
issue
has not received any replies yet. Since then I reproduced the issue with
'emacs -Q'

Link to Spacemacs issue (with diagnostic and traceback info)
- https://github.com/syl20bnr/spacemacs/issues/13866

I run Emacs on MSYS2. On August 20, 2020, I refreshed MSYS2 packages
and Emacs 27.1 was installed.

This problem is generated with 'emacs -Q --debug-init':
- no traceback info generated despite '--debug-init'
- When Emacs comes up, execute command: 'package-list'
- The package list comes up (it has 478 packages)
- The *Error* buffer comes up with the following contents:

Failed to verify signature archive-contents.sig:
No public key for 066DAFCB81E42C40 created at 2020-08-22T05:05:02-0400
using RSA
Command output:
gpg: keyblock resource
'/c/Users/977315/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx': No such
file or directory
gpg: Signature made Sat, Aug 22, 2020  5:05:02 AM EDT
gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
gpg: Can't check signature: No public key

The offending file path consists of the current directory, followed by
c:/Users/977315/.emacs.d/elpa/...
I verified this by launching emacs from a different directory. That change
would be reflected in the filepath, for example, when launched from the
~/tmp directory:
gpg: keyblock resource
'/c/Users/977315/tmp/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx': No
such file or directory

In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-11 built on fv-az75
Windowing system distributor 'Microsoft Corp.', version 10.0.17763
System Description: Microsoft Windows 10 Enterprise (v10.0.1809.17763.1339)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Importing package-keyring.gpg...done
Setting ‘package-selected-packages’ temporarily since "emacs -q" would
overwrite customizations
Package refresh done
error in process filter: package--check-signature-content: Failed to verify
signature: "archive-contents.sig"
error in process filter: Failed to verify signature: "archive-contents.sig"
You can run the command ‘package-list-packages’ with M-x pa-l- RET
error in process filter: Failed to verify signature: "archive-contents.sig"

Configured using:
 'configure --prefix=/mingw64 --build=x86_64-w64-mingw32 --with-modules
 --without-dbus --without-compress-install 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe' CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1
 LDFLAGS=-pipe'

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

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: cp1252

Major mode: Package Menu

Minor modes in effect:
  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
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail help-mode mm-archive message
dired dired-loaddefs format-spec rfc822 mml mml-sec epa derived
gnus-util rmail rmail-loaddefs text-property-search time-date mailabbrev
gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils mule-util
cus-edit cus-start cus-load wid-edit gnutls network-stream url-http
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw
nsm rmc puny url-cache url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap epg
epg-config finder-inf package easymenu browse-url url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib 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
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
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 loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads w32notify w32
multi-tty make-network-process emacs)

Memory information:
((conses 16 168321 9580)
 (symbols 48 10138 1)
 (strings 32 37790 3595)
 (string-bytes 1 1045947)
 (vectors 16 16682)
 (vector-slots 8 200678 15938)
 (floats 8 35 249)
 (intervals 56 11569 0)
 (buffers 1000 13))

[-- Attachment #2: Type: text/html, Size: 5886 bytes --]

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Stefan Kangas]

Mirko Vukovic <mirko.vukovic@gmail.com> writes:

> This report mirrors the issue I submitted to Spacemacs as issue 13866. This issue
> has not received any replies yet. Since then I reproduced the issue with 'emacs -Q'
>
> Link to Spacemacs issue (with diagnostic and traceback info)
> - https://github.com/syl20bnr/spacemacs/issues/13866
>
> I run Emacs on MSYS2. On August 20, 2020, I refreshed MSYS2 packages
> and Emacs 27.1 was installed.
>
> This problem is generated with 'emacs -Q --debug-init':
> - no traceback info generated despite '--debug-init'
> - When Emacs comes up, execute command: 'package-list'
> - The package list comes up (it has 478 packages)
> - The *Error* buffer comes up with the following contents:
>
> Failed to verify signature archive-contents.sig:
> No public key for 066DAFCB81E42C40 created at 2020-08-22T05:05:02-0400 using RSA
> Command output:
> gpg: keyblock resource '/c/Users/977315/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx': No such file or directory
> gpg: Signature made Sat, Aug 22, 2020  5:05:02 AM EDT
> gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
> gpg: Can't check signature: No public key
>
> The offending file path consists of the current directory, followed by c:/Users/977315/.emacs.d/elpa/...
> I verified this by launching emacs from a different directory. That change would be reflected in the filepath, for example, when launched
> from the ~/tmp directory:
> gpg: keyblock resource '/c/Users/977315/tmp/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx': No such file or directory

I don't understand why this path is used.  It should be using:

    (expand-file-name "gnupg" package-user-dir)

What is the value of `package-gnupghome-dir' and `package-user-dir' on
your machine?

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Stefan Kangas]

(Please keep the bug tracker in Cc.)

Mirko Vukovic <mirko.vukovic@gmail.com> writes:

>> > Failed to verify signature archive-contents.sig:
>> > No public key for 066DAFCB81E42C40 created at 2020-08-22T05:05:02-0400
>> using RSA
>> > Command output:
>> > gpg: keyblock resource
>> '/c/Users/977315/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx': No such
>> file or directory
>> > gpg: Signature made Sat, Aug 22, 2020  5:05:02 AM EDT
>> > gpg:                using RSA key
>> C433554766D3DDC64221BFAA066DAFCB81E42C40
>> > gpg: Can't check signature: No public key
>> >
>> > The offending file path consists of the current directory, followed by
>> c:/Users/977315/.emacs.d/elpa/...
>> > I verified this by launching emacs from a different directory. That
>> change would be reflected in the filepath, for example, when launched
>> > from the ~/tmp directory:
>> > gpg: keyblock resource
>> '/c/Users/977315/tmp/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx': No
>> such file or directory
>>
>> I don't understand why this path is used.  It should be using:
>>
>>     (expand-file-name "gnupg" package-user-dir)
>>
>> What is the value of `package-gnupghome-dir' and `package-user-dir' on
>> your machine?
>>
>
> package-gnupghome-dir ==> "c:/Users/977315/.emacs.d/elpa/gnupg"
> package-user-dir: ==> "~/.emacs.d/elpa"
> (expand-file-name "gnupg" package-user-dir) ==>
> "c:/Users/977315/.emacs.d/elpa/gnupg"

Well, I'm stomped.  But I don't know much of anything about Windows.

Does anyone have an idea why a path like this would be used on Windows?

  "/c/Users/977315/tmp/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx"

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 25 Nov 2020 16:06:43 -0500
> Cc: 42984@debbugs.gnu.org
> 
> > package-gnupghome-dir ==> "c:/Users/977315/.emacs.d/elpa/gnupg"
> > package-user-dir: ==> "~/.emacs.d/elpa"
> > (expand-file-name "gnupg" package-user-dir) ==>
> > "c:/Users/977315/.emacs.d/elpa/gnupg"
> 
> Well, I'm stomped.  But I don't know much of anything about Windows.
> 
> Does anyone have an idea why a path like this would be used on Windows?
> 
>   "/c/Users/977315/tmp/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx"

Yes, it happens when MSYS2 ports of programs (gpg?) are mixed with
native Windows ports.

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Does anyone have an idea why a path like this would be used on Windows?
>>
>>   "/c/Users/977315/tmp/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx"
>
> Yes, it happens when MSYS2 ports of programs (gpg?) are mixed with
> native Windows ports.

Should we do anything about that, or is it expected?

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 25 Nov 2020 23:36:36 -0500
> Cc: mirko.vukovic@gmail.com, 42984@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Does anyone have an idea why a path like this would be used on Windows?
> >>
> >>   "/c/Users/977315/tmp/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx"
> >
> > Yes, it happens when MSYS2 ports of programs (gpg?) are mixed with
> > native Windows ports.
> 
> Should we do anything about that, or is it expected?

My guess is it's not an Emacs problem.  But to be sure, I miss some
details:

  . is gpg being used an MSYS2 port of a native Windows
    (a.k.a. "mingw") port?
  . was the problematic file name emitted by gpg, or was it generated
    by Emacs and passed to gpg?

The last question could be answered by stepping in Edebug through
package--check-signature-content and epg functions it calls, and
looking at the file names we place on the gpg command line.

If the OP could provide this information, we could easily see whether
there's some problem in Emacs in this use case.

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Mirko Vukovic]

[-- Attachment #1: Type: text/plain, Size: 7157 bytes --]

On Thu, Nov 26, 2020 at 9:09 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Wed, 25 Nov 2020 23:36:36 -0500
> > Cc: mirko.vukovic@gmail.com, 42984@debbugs.gnu.org
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> Does anyone have an idea why a path like this would be used on
> Windows?
> > >>
> > >>
>  "/c/Users/977315/tmp/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx"
> > >
> > > Yes, it happens when MSYS2 ports of programs (gpg?) are mixed with
> > > native Windows ports.
> >
> > Should we do anything about that, or is it expected?
>
> My guess is it's not an Emacs problem.  But to be sure, I miss some
> details:
>
>   . is gpg being used an MSYS2 port of a native Windows
>     (a.k.a. "mingw") port?
>   . was the problematic file name emitted by gpg, or was it generated
>     by Emacs and passed to gpg?
>
> The last question could be answered by stepping in Edebug through
> package--check-signature-content and epg functions it calls, and
> looking at the file names we place on the gpg command line.
>
> If the OP could provide this information, we could easily see whether
> there's some problem in Emacs in this use case.
>

Tracing package--check-signature-content

   - I trace it in plain emacs, started with emacs -Q
   - I edebug the function and step through it
   - I have a single signature and its status is no-pub-key which triggers
   the No public key error
      - This results in the message in the error buffer with the malformed
      directory

Below is the code annotated with values of key variables. I did not see
anything obvious.

I evaluated context at several points. I following deeper into the epg-...
functions, stopped when I saw compiler macros. I would need guidance to
trace those.

Let me know if you required additional debug/testing, including issuing gpg
commands in the shell.

(defun package--check-signature-content (content string &optional sig-file)
  "Check signature CONTENT against STRING.
SIG-FILE is the name of the signature file, used when signaling
errors."
  ;; Evaluated in edebug and copied from *Messages*
  ;; content:  "\211 \263 \0 \n\0  ! \3043UGf\323\335\306B!\277\252
m\257\313\201\344,@  _\277}\316\0\n	  m\257\313\201\344,@..."
  ;; string: "(1\n (ace-window .\n	     [(0 9 0)\n	      ((avy\n		(0..."
  ;; sig-file: "archive-contents.sig"
  (let ((context (epg-make-context 'OpenPGP)))
  ;; #s(epg-context :protocol OpenPGP :program
"c:/msys64-a/usr/bin/gpg.exe" :home-directory nil :armor nil :textmode
nil :include-certs nil :cipher-algorithm nil :digest-algorithm nil
:compress-algorithm nil :passphrase-callback
(epg-passphrase-callback-function) :progress-callback nil
:edit-callback nil :signers nil :sender nil :sig-notations nil
:process nil :output-file nil :result nil :operation nil
:pinentry-mode nil :error-output "" :error-buffer nil)
    (when package-gnupghome-dir
      (setf (epg-context-home-directory context) package-gnupghome-dir))
      ;; #s(epg-context :protocol OpenPGP :program
"c:/msys64-a/usr/bin/gpg.exe" :home-directory
"c:/Users/977315/.emacs.d/elpa/gnupg" :armor nil :textmode nil
:include-certs nil :cipher-algorithm nil :digest-algorithm nil
:compress-algorithm nil :passphrase-callback
(epg-passphrase-callback-function) :progress-callback nil
:edit-callback nil :signers nil :sender nil :sig-notations nil
:process nil :output-file nil :result nil :operation nil
:pinentry-mode nil :error-output "" :error-buffer nil)
    (condition-case error
        (epg-verify-string context content string) ;; ""
      (error (package--display-verify-error context sig-file)
             (signal 'bad-signature error)))
    (let (good-signatures had-fatal-error)
      ;; The .sig file may contain multiple signatures.  Success if one
      ;; of the signatures is good.
      ;; context: #s(epg-context :protocol OpenPGP :program
"c:/msys64-a/usr/bin/gpg.exe" :home-directory
"c:/Users/977315/.emacs.d/elpa/gnupg" :armor nil :textmode nil
:include-certs nil :cipher-algorithm nil :digest-algorithm nil
:compress-algorithm nil :passphrase-callback
(epg-passphrase-callback-function) :progress-callback nil
:edit-callback nil :signers nil :sender nil :sig-notations nil
:process nil :output-file
"c:/Users/977315/AppData/Local/Temp/epg-output2eIiW..." :result
((error) (verify #s(epg-signature :status no-pubkey :key-id
"066DAFCB81E42C40" :validity nil :fingerprint nil :creation-time
1606385102 :expiration-time nil :pubkey-algorithm 1 :digest-algorithm
10 :class 0 :version nil :notations nil))) :operation verify
:pinentry-mode nil :error-output "gpg: keyblock resource
'/home/977315/.emacs.d/elpa..." :error-buffer #<killed buffer>)
      (dolist (sig (epg-context-result-for context 'verify))
      ;; sig: #s(epg-signature :status no-pubkey :key-id
"066DAFCB81E42C40" :validity nil :fingerprint nil :creation-time
1606385102 :expiration-time nil :pubkey-algorithm 1 :digest-algorithm
10 :class 0 :version nil :notations nil)
        (if (eq (epg-signature-status sig) 'good) ;;
epg-signature-status returns NO-PUBKEY
            (push sig good-signatures)
          ;; If `package-check-signature' is allow-unsigned, don't
          ;; signal error when we can't verify signature because of
          ;; missing public key.  Other errors are still treated as
          ;; fatal (bug#17625).
          (unless (and (eq (package-check-signature) 'allow-unsigned) ;; T
                       (eq (epg-signature-status sig) 'no-pubkey)) ;; T
            (setq had-fatal-error t)))) ;; NIL
      (when (or (null good-signatures) ;; T
                (and (eq (package-check-signature) 'all)
                     had-fatal-error))
       ;; context: #s(epg-context :protocol OpenPGP :program
"c:/msys64-a/usr/bin/gpg.exe" :home-directory
"c:/Users/977315/.emacs.d/elpa/gnupg" :armor nil :textmode nil
:include-certs nil :cipher-algorithm nil :digest-algorithm nil
:compress-algorithm nil :passphrase-callback
(epg-passphrase-callback-function) :progress-callback nil
:edit-callback nil :signers nil :sender nil :sig-notations nil
:process nil :output-file
"c:/Users/977315/AppData/Local/Temp/epg-output2eIiW..." :result
((error) (verify #s(epg-signature :status no-pubkey :key-id
"066DAFCB81E42C40" :validity nil :fingerprint nil :creation-time
1606385102 :expiration-time nil :pubkey-algorithm 1 :digest-algorithm
10 :class 0 :version nil :notations nil))) :operation verify
:pinentry-mode nil :error-output "gpg: keyblock resource
'/home/977315/.emacs.d/elpa..." :error-buffer #<killed buffer>)
        (package--display-verify-error context sig-file)
;; Failed to verify signature archive-contents.sig:
;; No public key for 066DAFCB81E42C40 created at
2020-11-26T05:05:02-0500 using RSA
;; Command output:
;; gpg: keyblock resource
'/home/977315/.emacs.d/elpa/gnupg/c:/Users/977315/.emacs.d/elpa/gnupg/pubring.kbx':
No such file or directory
;; gpg: Signature made Thu, Nov 26, 2020  5:05:02 AM EST
;; gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
;; gpg: Can't check signature: No public key
        (signal 'bad-signature (list sig-file)))
      good-signatures)))

[-- Attachment #2: Type: text/html, Size: 8541 bytes --]

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Eli Zaretskii]

> From: Mirko Vukovic <mirko.vukovic@gmail.com>
> Date: Thu, 26 Nov 2020 10:28:17 -0500
> Cc: Stefan Kangas <stefan@marxist.se>, 42984@debbugs.gnu.org
> 
> Tracing package--check-signature-content
> 
> * I trace it in plain emacs, started with emacs -Q
> * I edebug the function and step through it
> * I have a single signature and its status is no-pub-key which triggers the No public key error 
> 
> * This results in the message in the error buffer with the malformed directory
> 
> Below is the code annotated with values of key variables. I did not see anything obvious.
> 
> I evaluated context at several points. I following deeper into the epg-... functions, stopped when I saw
> compiler macros. I would need guidance to trace those.

Thanks.  I think the situation is clear:

>   ;; #s(epg-context :protocol OpenPGP :program "c:/msys64-a/usr/bin/gpg.exe" 

The "C:/msys64-a" part indicates that gpg.exe is an MSYS2 port, not a
native MinGW port.  So it's expected that it will manipulate
Posix-like file names like /c/foo/bar and /home/977315/...  It is also
expected that it may not realize that "c:/foo/bar" is an absolute file
name, since in the Posix world any file name which doesn't begin with
a slash is not an absolute file name.  So it concatenates the file
name passed to it by Emacs with /home/977315/... on the assumption
that the file name passed by Emacs is a relative file name.

Bottom line: you need to install a native MinGW port of gpg, or make
some wrapper script for gpg which would convert Windows d:/foo/bar
file names into the Posix-like format expected by MSYS2 executables.

Thanks.

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Mirko Vukovic]

[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]

On Thu, Nov 26, 2020 at 10:38 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Mirko Vukovic <mirko.vukovic@gmail.com>
> > Date: Thu, 26 Nov 2020 10:28:17 -0500
> > Cc: Stefan Kangas <stefan@marxist.se>, 42984@debbugs.gnu.org
> >
> > Tracing package--check-signature-content
> >
> > * I trace it in plain emacs, started with emacs -Q
> > * I edebug the function and step through it
> > * I have a single signature and its status is no-pub-key which triggers
> the No public key error
> >
> > * This results in the message in the error buffer with the malformed
> directory
> >
> > Below is the code annotated with values of key variables. I did not see
> anything obvious.
> >
> > I evaluated context at several points. I following deeper into the
> epg-... functions, stopped when I saw
> > compiler macros. I would need guidance to trace those.
>
> Thanks.  I think the situation is clear:
>
> >   ;; #s(epg-context :protocol OpenPGP :program
> "c:/msys64-a/usr/bin/gpg.exe"
>
> The "C:/msys64-a" part indicates that gpg.exe is an MSYS2 port, not a
> native MinGW port.  So it's expected that it will manipulate
> Posix-like file names like /c/foo/bar and /home/977315/...  It is also
> expected that it may not realize that "c:/foo/bar" is an absolute file
> name, since in the Posix world any file name which doesn't begin with
> a slash is not an absolute file name.  So it concatenates the file
> name passed to it by Emacs with /home/977315/... on the assumption
> that the file name passed by Emacs is a relative file name.
>
> Bottom line: you need to install a native MinGW port of gpg, or make
> some wrapper script for gpg which would convert Windows d:/foo/bar
> file names into the Posix-like format expected by MSYS2 executables.
>
> Thanks.
>
I think this solved it:

   1. Installed MinGW version: pacman -S mingw64/mingw-w64-x86_64-gnupg
   2. Started emacs -Q in the MingGW64 terminal (not the MSYS2 terminal)
   3. package-list-packages completes without errors:

From the *Messages* buffer:

Importing package-keyring.gpg...done
Setting ‘package-selected-packages’ temporarily since "emacs -q" would
overwrite customizations
Package refresh done
Packages that can be upgraded: 2; type ‘U’ to mark for upgrading.

To me this implies that gnupg should be installed along with Emacs 27.1 in
MinGW64. I will try to contact the maintainer to suggest that.

Thank you very much for your help.

Mirko

[-- Attachment #2: Type: text/html, Size: 3381 bytes --]

bug#42984: 27.1; package-list results in error while updating archive due to malformed path

[Eli Zaretskii]

> From: Mirko Vukovic <mirko.vukovic@gmail.com>
> Date: Thu, 26 Nov 2020 10:58:13 -0500
> Cc: Stefan Kangas <stefan@marxist.se>, 42984@debbugs.gnu.org
> 
> I think this solved it:
> 
> 1 Installed MinGW version: pacman -S mingw64/mingw-w64-x86_64-gnupg
> 2 Started emacs -Q in the MingGW64 terminal (not the MSYS2 terminal)
> 3 package-list-packages completes without errors:
> 
> From the *Messages* buffer:
> 
> Importing package-keyring.gpg...done
> Setting ‘package-selected-packages’ temporarily since "emacs -q" would overwrite customizations
> Package refresh done
> Packages that can be upgraded: 2; type ‘U’ to mark for upgrading.
> 
> To me this implies that gnupg should be installed along with Emacs 27.1 in MinGW64. I will try to contact the
> maintainer to suggest that.

Yes, using MSYS2 ports of programs with the MinGW Emacs is prone to
subtle hard-to-debug errors.  MinGW ports should be preferred.

> Thank you very much for your help.

You are welcome.  I'm therefore closing this bug report.