Windows msys2: pacman reports PGP signature errors. #5567

PaulJohnson · 2021-06-21T16:58:11Z

General summary/comments (optional)

I'm trying to install the text-icu library. When I run stack install text-icu I get an error:

* Missing (or bad) C libraries: icuuc, icuin, icudt

It suggests installing the icu development package. But when I try to say stack exec -- pacman -S icu-devel I get PGP signature errors.

Steps to reproduce

stack exec -- pacman -S icu-devel

Expected

Latest icu-devel packages installed.

Actual

resolving dependencies...
looking for conflicting packages...

Packages (2) icu-68.2-1  icu-devel-68.2-1

Total Download Size:    1.17 MiB
Total Installed Size:  57.45 MiB
Net Upgrade Size:      25.99 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages...
 icu-devel-68.2-1-x86_64                                                1197.3 KiB  2.77 MiB/s 00:00 [###########################################################] 100%
(2/2) checking keys in keyring                                                                       [###########################################################] 100%
(2/2) checking package integrity                                                                     [###########################################################] 100%
error: icu: signature from "David Macek <[email protected]>" is unknown trust
:: File /var/cache/pacman/pkg/icu-68.2-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: icu-devel: signature from "David Macek <[email protected]>" is unknown trust
:: File /var/cache/pacman/pkg/icu-devel-68.2-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Stack version

$ stack --version
Version 2.7.1, Git revision 8afe0c2932716b0441cf4440d6942c59568b6b19 x86_64 hpack-0.34.4

Method of installation

Official binary, downloaded from stackage.org or fpcomplete's package repository

The text was updated successfully, but these errors were encountered:

ce-dot · 2021-06-21T19:45:17Z

Workaround: stack exec -- pacman -Sy msys2-keyring

The packaged msys2 is almost a year old now; so is pacman's trustdb.

andreasabel · 2022-02-04T11:00:19Z

Me too:

CI: Installation of ICU lib failing on stack.yml/windows-latest workflow agda/agda#5768

and I bothered the wrong people when it is really a stack problem:

pacman -S mingw-w64-x86_64-icu fails with signature from "David Macek <...>" is unknown trust (starting 2022-01-23) actions/runner-images#4987

mpilgrem · 2022-05-14T19:20:32Z

Do any of the following assist?

The Stack-supplied MSYS2 (if an existing one is absent) has recently been updated to the latest version 20220503. See msys2 dependency updating #5595 (comment)
Noting the references to signature from "David Macek <[email protected]>" is unknown trust, I had that problem in the past when updating the Stack-supplied MSYS2 using MSYS2. I found this MSYS2 discussion to be of help in resolving the problem: error: XXXX : signature from "David macek <[email protected]>" is invalid msys2/MSYS2-packages#2343

andreasabel · 2022-05-15T15:07:37Z

The Stack-supplied MSYS2 (if an existing one is absent) has recently been updated to the latest version 20220503.

That could explain why my stack CI started failing under Windows: https://github.com/agda/agda/runs/6435596174?check_suite_focus=true

> <command line>: addDLL: icudt or dependencies not loaded. (Win32 error 126)   
> ghc.exe: addLibrarySearchPath: 
C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\lib (Win32 error 3): 
The system cannot find the path specified.

version 20220503

Can I get stack to tell me this version? Could be that I need to make this part of my cache keys...

andreasabel · 2022-05-15T16:29:44Z

Indeed, clearing the cache fixed my workflow: https://github.com/agda/agda/runs/6441965841?check_suite_focus=true

How can I get a robust cache key for a stack CI? Seems difficult if parts of stack are renewed without bumping the version number...

Atm, I have the key scheme OS-Stack-GHC-Yaml.lock (e.g. Windows-2.7.5-9.0.1-6c2bfc0ffd8aad4b0b1235aef7781dfad8790e9625165f2dee19f9919bba4397), but the MSYS update does not affect any of these components.

${{ runner.os }}-${{ env.STACK_VER }}-${{ env.GHC_VER }}-${{ hashFiles(format('stack-{0}.yaml.lock', env.GHC_VER)) }}

mpilgrem · 2022-05-15T17:45:51Z

@andreasabel, on your question "Can I get stack to tell me the MSYS2 version?", the short answer is No. However, I have proposed a pull request that would add a command stack ls tools --filter msys2 which would do just that. See #5725.

mpilgrem · 2022-05-15T18:12:23Z

@andreasabel, my knowledge of CI is limited, but what is the purpose of addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\lib?

I had understood that, in the stack environment, stack 'automatically' knows that it should look in its stack-supplied MSYS2 \mingw64\lib folder for extra libraries?

andreasabel · 2022-05-16T06:47:31Z

my knowledge of CI is limited, but what is the purpose of addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\lib?

This is not something that our CI is doing (check https://github.com/agda/agda/blob/d25dd477747155339afb9ad1159cffda0ef1111a/src/github/workflows/stack.yml), this must be something that stack is doing.

In short, the CI does the following steps:

stack update
stack build --dry-run, generating lock file
restore .stack/ if stack version and lock file have not changed in comparison with last run of CI
stack build

See also:

Caching in the stack.yml CI workflow done correctly? agda/agda#5887

I had understood that, in the stack environment, stack 'automatically' knows that it should look in its stack-supplied MSYS2 \mingw64\lib folder for extra libraries?

Maybe something goes wrong if stack runs on a stale version of its root directory tree (.stack/) which is restored by the cache logic.
Maybe restoring the entirety of .stack/ is wrong? Is there some official advice how to set up caching of github CI builds when using stack? I was looking for a "blessed" stack action for CI but couldn't find anything...

mpilgrem · 2022-05-16T23:20:52Z

@andreasabel, as I note above, my knowledge of CI is limited, but I don't understand how it can be caching-related.

 - with:
        path: ${{ steps.haskell-setup.outputs.stack-root }}
        key: |
          ${{ runner.os }}-stack-00-${{ env.STACK_VER }}-${{ hashFiles(format('stack-{0}.yaml.lock', env.GHC_VER)) }}
      uses: actions/cache@v2
      name: Cache dependencies
      id: cache

is caching the stack root directory - but, on Windows, that directory has nothing to do with the stack-supplied MSYS2. MSYS2 is a tool in the stack path --programs directory (which is outside the stack root directory). I think you can see in the log that the stack update --silent is triggering the download of MSYS2-20220503 into C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\. I am still trying to workout what is causing the executables to think C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\lib is a relevant path.

mpilgrem · 2022-05-17T20:28:30Z

Adding a link to this issue: https://gitlab.haskell.org/ghc/ghc/-/issues/14183 as it may provide an clue.

andreasabel · 2022-05-18T07:36:16Z

@mpilgrem wrote:

as I note above, my knowledge of CI is limited, but I don't understand how it can be caching-related.

Well, I imagine it like this:

stack update downloads MSYS2-20220503 (https://github.com/agda/agda/runs/6435596174?check_suite_focus=true#step:7:23) and stores it or at least its configuration in .stack/ somewhere.
An old cache build with MSYS2-20210604 is restored: https://github.com/agda/agda/runs/6435596174?check_suite_focus=true#step:7:23 ("Cache restored successfully").
This overwrites .stack/ and annihilates the effects of stack update. Now stack is in an inconsistent state (but apparently has no routines to detect this). It is running on MSYS2-20220505 but its configuration is for MSYS-20210604.
Running stack build in this inconsistent setup refers to paths that do not exist.

Does this sound plausible?
Is this true (not everything that is plausible is true...)?

mpilgrem · 2022-05-18T14:21:14Z

I tried the following experiment, but it was a blind alley. I am using a version of stack built from the current master branch with GHC 9.0.2/Cabal-3.4.1.0. I created a simple project pkgTest (stack new pkgTest, which - today - uses lts-19.7) and added a dependency on acme-missiles-0.3, so that Main.hs became:

module Main where

import Lib
import Acme.Missiles

main :: IO ()
main = do
  someFunc
  launchMissiles

stack build creates a snapshot in the stack root (for me) at C:\sr\snapshots\00e41759 and I looked at that with stack exec -- ghc-pkg dump -f C:\sr\snapshots\00e41759\pkgdb, yielding:

name:                 acme-missiles
version:              0.3
visibility:           public
id:                   acme-missiles-0.3-KfaH05Ue1Cs8dT7ALloWDX
key:                  acme-missiles-0.3-KfaH05Ue1Cs8dT7ALloWDX
license:              LicenseRef-PublicDomain
maintainer:           [email protected]
author:               Joey Adams
synopsis:             Cause serious international side effects.
description:
    The highly effectful 'launchMissiles' action, as mentioned in /Beautiful concurrency/,
    Simon Peyton Jones, 2007.

category:             Acme
abi:                  b249e6658759461df541cdd5c2e3aeba
exposed:              True
exposed-modules:      Acme.Missiles Acme.Missiles.STM
import-dirs:
    C:\sr\snapshots\00e41759\lib\x86_64-windows-ghc-9.0.2\acme-missiles-0.3-KfaH05Ue1Cs8dT7ALloWDX

library-dirs:
    C:\sr\snapshots\00e41759\lib\x86_64-windows-ghc-9.0.2\acme-missiles-0.3-KfaH05Ue1Cs8dT7ALloWDX
    C:\Users\mike\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\lib
    C:\Users\mike\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\bin

dynamic-library-dirs:
    C:\sr\snapshots\00e41759\lib\x86_64-windows-ghc-9.0.2
    C:\Users\mike\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\lib
    C:\Users\mike\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\bin

data-dir:
    C:\sr\snapshots\00e41759\share\x86_64-windows-ghc-9.0.2\acme-missiles-0.3

hs-libraries:         HSacme-missiles-0.3-KfaH05Ue1Cs8dT7ALloWDX
include-dirs:
    C:\Users\mike\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604\mingw64\include

depends:              base-4.15.1.0 stm-2.5.0.0
haddock-interfaces:
    C:\sr\snapshots\00e41759\doc\acme-missiles-0.3\acme-missiles.haddock

haddock-html:         C:\sr\snapshots\00e41759\doc\acme-missiles-0.3
pkgroot: "C:\\\\sr\\snapshots\\00e41759"

So, entries (a) in a file in my stack root (b) with paths to my existing stack-supplied MSYS2 (which is in msys2-20210604). Perhaps that was the cause of what @andreasabel was observing?

I investigated what happened if I disabled that MSYS2:

stack path --programs | cd
ren msys2-20210604 msys2-20210604.old
ren msys2-20210604.installed msys2-20210604.installed.old

Back in the project folder, stack build now (a) identified the missing MSYS2 and downloaded the latest MSYS2-20220503, and (b) yielded this (but no ghc.exe: addLibrarySearchPath errors reported):

pkgTest-0.1.0.0: unregistering (flags changed from ["--extra-include-dirs=C:\\Users\\mike\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20210604\\mingw64\\include","--extra-lib-dirs=C:\\Users\\mike\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20210604\\mingw64\\lib","--extra-lib-dirs=C:\\Users\\mike\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20210604\\mingw64\\bin"] to ["--extra-include-dirs=C:\\Users\\mike\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20220503\\mingw64\\include","--extra-lib-dirs=C:\\Users\\mike\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20220503\\mingw64\\lib","--extra-lib-dirs=C:\\Users\\mike\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20220503\\mingw64\\bin"])
pkgTest> configure (lib + exe)
Configuring pkgTest-0.1.0.0...
pkgTest> build (lib + exe)
Preprocessing library for pkgTest-0.1.0.0..
Building library for pkgTest-0.1.0.0..
[1 of 2] Compiling Lib [flags changed]
[2 of 2] Compiling Paths_pkgTest [flags changed]
Preprocessing executable 'pkgTest-exe' for pkgTest-0.1.0.0..
Building executable 'pkgTest-exe' for pkgTest-0.1.0.0..
[1 of 2] Compiling Main [flags changed]
[2 of 2] Compiling Paths_pkgTest [flags changed]
Linking .stack-work\dist\d53b6a14\build\pkgTest-exe\pkgTest-exe.exe ...
pkgTest> copy/register
Installing library in D:\Users\mike\Code\Haskell\pkgTest\.stack-work\install\a7a5ad27\lib\x86_64-windows-ghc-9.0.2\pkgTest-0.1.0.0-EYjhW8QjuAYDzydfO0o2wU
Installing executable pkgTest-exe in D:\Users\mike\Code\Haskell\pkgTest\.stack-work\install\a7a5ad27\bin
Registering library for pkgTest-0.1.0.0..

When I tried stack exec -- ghc-pkg dump -f C:\sr\snapshots\00e41759\pkgdb again, I had the same result as before - with the same paths to the old - now non-existent - C:\Users\mike\AppData\Local\Programs\stack\x86_64-windows\msys2-20210604. stack and ghc did not seem to be troubled by that.

If I deleted C:\sr\snapshots\00e41759, stack build recreated it - but this time with paths to the new C:\Users\mike\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503

I tried the same thing but with a stack purge after disabling the existing MSYS2 and had the same result: stack and ghc did not seem troubled by C:\sr\snapshots\00e41759\pkgdb containing references to paths that no longer existed.

mpilgrem · 2024-03-28T20:41:09Z

I am going to close this issue given the passage of time and because I think the original issue is no longer applicable.

PaulJohnson mentioned this issue Jun 28, 2021

Missing of regex.h on Windows haskell-hvr/regex-posix#4

Closed

This was referenced Feb 4, 2022

CI: Installation of ICU lib failing on stack.yml/windows-latest workflow agda/agda#5768

Closed

Support text-icu-0.8.0 agda/agda#5773

Closed

andreasabel mentioned this issue May 15, 2022

[ workflows ] try to fix stack/Win (ICU again) agda/agda#5909

Merged

This was referenced May 16, 2022

Blessed recipe how to use stack on github actions, in particular caching? #5754

Open

msys2 dependency updating #5595

Closed

Fails with complaint about missing .lock file freckle/stack-cache-action#68

Closed

mpilgrem closed this as completed Mar 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Windows msys2: pacman reports PGP signature errors. #5567

Windows msys2: pacman reports PGP signature errors. #5567

PaulJohnson commented Jun 21, 2021

ce-dot commented Jun 21, 2021

andreasabel commented Feb 4, 2022

mpilgrem commented May 14, 2022

andreasabel commented May 15, 2022 •

edited

Loading

andreasabel commented May 15, 2022

mpilgrem commented May 15, 2022

mpilgrem commented May 15, 2022

andreasabel commented May 16, 2022

mpilgrem commented May 16, 2022

mpilgrem commented May 17, 2022

andreasabel commented May 18, 2022

mpilgrem commented May 18, 2022

mpilgrem commented Mar 28, 2024

Windows msys2: pacman reports PGP signature errors. #5567

Windows msys2: pacman reports PGP signature errors. #5567

Comments

PaulJohnson commented Jun 21, 2021

General summary/comments (optional)

Steps to reproduce

Expected

Actual

Stack version

Method of installation

ce-dot commented Jun 21, 2021

andreasabel commented Feb 4, 2022

mpilgrem commented May 14, 2022

andreasabel commented May 15, 2022 • edited Loading

andreasabel commented May 15, 2022

mpilgrem commented May 15, 2022

mpilgrem commented May 15, 2022

andreasabel commented May 16, 2022

mpilgrem commented May 16, 2022

mpilgrem commented May 17, 2022

andreasabel commented May 18, 2022

mpilgrem commented May 18, 2022

mpilgrem commented Mar 28, 2024

andreasabel commented May 15, 2022 •

edited

Loading