Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[icu] build failure #11873

Closed
pr8x opened this issue Jun 10, 2020 · 12 comments
Closed

[icu] build failure #11873

pr8x opened this issue Jun 10, 2020 · 12 comments
Assignees
Labels
category:tool-update The issue is with build tool or build script, which requires update or should be executed correctly requires:repro The issue is not currently repro-able

Comments

@pr8x
Copy link

pr8x commented Jun 10, 2020

Host Environment

  • OS: Windows 10 x64
  • Compiler: revision

To Reproduce
Steps to reproduce the behavior:
vcpkg install icu

Failure logs

-- Acquiring MSYS Packages...
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
Command failed: R:/vcpkg_official/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc -c "pacman -Sy --noconfirm --needed make automake1.15"
Working Directory: R:/vcpkg_official/downloads/tools/msys2
Error code: 1
See logs for more information:
R:\vcpkg_official\buildtrees\icu\msys-pacman-x86-windows-out.log
R:\vcpkg_official\buildtrees\icu\msys-pacman-x86-windows-err.log

Call Stack (most recent call first):
scripts/cmake/vcpkg_acquire_msys.cmake:166 (vcpkg_execute_required_process)
ports/icu/portfile.cmake:78 (vcpkg_acquire_msys)
scripts/ports.cmake:76 (include)
Error: Building package icu:x86-windows failed with: BUILD_FAILED

msys-pacman-x86-windows-err.log

error: failed to update mingw32 (unable to lock database)
error: failed to update mingw64 (unable to lock database)
error: failed to update msys (unable to lock database)
error: failed to synchronize all databases

@JackBoosY
Copy link
Contributor

I think this issue should be fixed in #11810.

@JackBoosY JackBoosY added the category:vcpkg-bug The issue is with the vcpkg system (including helper scripts in `scripts/cmake/`) label Jun 11, 2020
@rrouse
Copy link

rrouse commented Jun 12, 2020

I pulled the most recent master (6824460) and rebuilt vcpkg.

When trying to install this library, it fails in a similar place still.

My msys-pacman error log file reads:

error: mingw32: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
error: mingw64: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
error: msys: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
error: database 'mingw32' is not valid (invalid or corrupted database (PGP signature))
error: database 'mingw64' is not valid (invalid or corrupted database (PGP signature))
error: database 'msys' is not valid (invalid or corrupted database (PGP signature))

@JackBoosY
Copy link
Contributor

@emptyVoid Could you please take a look?

Thanks.

@emptyVoid
Copy link
Contributor

@pr8x and @rrouse, could you, please, retry installing icu deleting <vcpkg>\downloads\tools\msys2 directory beforehand?

I've checked vcpkg install icu with an already acquired MSYS2 and on the clean vcpkg installation -- both work for me.

If my suspicion is correct and the "MSYS2-clean" install of icu will succeed for pr8x and rrouse, to make the incremental installs of MSYS2 dependent ports more stable we should purge MSYS2 installation whenever critical changes are made to vcpkg_acquire_msys script. I do have an idea on how to implement that and would be able to return to the subject in 2 days.

@JackBoosY JackBoosY added requires:repro The issue is not currently repro-able and removed category:vcpkg-bug The issue is with the vcpkg system (including helper scripts in `scripts/cmake/`) labels Jun 12, 2020
@rrouse
Copy link

rrouse commented Jun 12, 2020

@emptyVoid It still fails for me in exactly the same way. I cleaned out all the downloads and directories to be doubly sure I was getting clean files.

Doing some further searching, a similar key issue was reported to MSYS2-pacman itself some time ago: Alexpux/MSYS2-pacman#12

I'm not exactly sure why this is happening to me specifically, but if it's not happening to anyone else, I'll chalk it up to bad luck and see if I can work around it on my machine.

Edit: Some more data:

If I run the pacman-key init and populate commands copied from the cmake script directly in my terminal, the supposedly invalid keys are no longer invalid and the command completes. However, that causes other issues with MSYS2 itself since I think file permissions get changed and stuff breaks.

@rrouse
Copy link

rrouse commented Jun 12, 2020

@emptyVoid As an experiment, I edited the vcpkg_acquire_msys.cmake file to run the set of pacman/gpg kill commands twice.

Building package icu[core]:x64-windows...
-- Using cached G:/Development/Tools/vcpkg/downloads/icu4c-67_1-src.tgz
-- Extracting source G:/Development/Tools/vcpkg/downloads/icu4c-67_1-src.tgz
-- Applying patch G:/Development/Tools/vcpkg/ports/icu/disable-escapestr-tool.patch
-- Applying patch G:/Development/Tools/vcpkg/ports/icu/remove-MD-from-configure.patch
-- Applying patch G:/Development/Tools/vcpkg/ports/icu/fix_parallel_build_on_windows.patch
-- Applying patch G:/Development/Tools/vcpkg/ports/icu/fix-extra.patch
-- Using source at G:/Development/Tools/vcpkg/buildtrees/icu/src/c-67_1-src-39ba50b26e
-- Acquiring MSYS2...
-- Using cached G:/Development/Tools/vcpkg/downloads/msys2-base-x86_64-20190524.tar.xz
gpg: DBG: locking for '/etc/pacman.d/gnupg/trustdb.gpg.lock' done via O_EXCL
gpg: /etc/pacman.d/gnupg/trustdb.gpg: trustdb created
gpg: DBG: locking for '/etc/pacman.d/gnupg/pubring.gpg.lock' done via O_EXCL
gpg: no ultimately trusted keys found
gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/etc/pacman.d/gnupg/secring.gpg' to gpg-agent
gpg: migration succeeded
gpg: Generating pacman keyring master key...
gpg: key D4346154E5DA36A2 marked as ultimately trusted
gpg: directory '/etc/pacman.d/gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/etc/pacman.d/gnupg/openpgp-revocs.d/B3CE55633A6EFD6006D19B3ED4346154E5DA36A2.rev'
gpg: Done
==> Updating trust database...
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
==> Appending keys from msys2.gpg...
==> Locally signing trusted keys in keyring...
  -> Locally signing key D55E7A6D7CE9BA1587C0ACACF40D263ECA25678A...
  -> Locally signing key 123D4D51A1793859C2BE916BBBE514E53E0D0813...
==> ERROR: 123D4D51A1793859C2BE916BBBE514E53E0D0813 could not be locally signed.
  -> Locally signing key B91BCF3303284BF90CC043CA9F418C233E652008...
  -> Locally signing key 9DD0D4217D75A33B896159E6DA7EF2ABAEEA755C...
==> ERROR: 9DD0D4217D75A33B896159E6DA7EF2ABAEEA755C could not be locally signed.
error: mingw32: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
error: mingw64: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
error: msys: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
:: Synchronizing package databases...
downloading mingw32.db...
downloading mingw32.db.sig...
error: mingw32: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
error: failed to update mingw32 (invalid or corrupted database (PGP signature))
downloading mingw64.db...
downloading mingw64.db.sig...
error: mingw64: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
error: failed to update mingw64 (invalid or corrupted database (PGP signature))
downloading msys.db...
downloading msys.db.sig...
error: msys: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is unknown trust
error: failed to update msys (invalid or corrupted database (PGP signature))
error: failed to synchronize all databases
==> Appending keys from msys2.gpg...
==> Locally signing trusted keys in keyring...
  -> Locally signing key D55E7A6D7CE9BA1587C0ACACF40D263ECA25678A...
  -> Locally signing key 123D4D51A1793859C2BE916BBBE514E53E0D0813...
  -> Locally signing key B91BCF3303284BF90CC043CA9F418C233E652008...
  -> Locally signing key 9DD0D4217D75A33B896159E6DA7EF2ABAEEA755C...
==> Importing owner trust values...
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
gpg: inserting ownertrust of 4
==> Updating trust database...
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   4  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   4  signed:   3  trust: 0-, 0q, 0n, 4m, 0f, 0u
gpg: depth: 2  valid:   3  signed:   0  trust: 3-, 0q, 0n, 0m, 0f, 0u
:: Synchronizing package databases...
 mingw32 is up to date
 mingw64 is up to date
 msys is up to date
:: Starting core system upgrade...
warning: resolving dependencies...
terminate other MSYS2 programs before proceeding
looking for conflicting packages...

Packages (8) bash-4.4.023-2  filesystem-2020.02-2  libzstd-1.4.5-2  mintty-1~3.1.7-1  msys2-runtime-3.1.5-3  pacman-5.2.1-12  pacman-mirrors-20200329-1  zstd-1.4.5-2

Total Download Size:    16.60 MiB
Total Installed Size:   58.29 MiB
Net Upgrade Size:      -11.43 MiB

So it looks like you have to update with pacman before the pacman keys will be accepted.

@JackBoosY JackBoosY added the category:tool-update The issue is with build tool or build script, which requires update or should be executed correctly label Jun 15, 2020
@emptyVoid
Copy link
Contributor

@rrouse, the part that is failing for you has always been there (2f8d8d8) and it seems no one else has stumbled on this issue. It really looks like something in your system interferes with the GPG key signing. Do you by chance use YubiKey? (I'm seeing a few issue reports concerning pacman-key failing on Arch Linux with a smart-card plugged in) Additionally could you, please, tell us your system spec?

It's great you've found a workaround, though I'm a bit hesitant about including it without trying to reproduce the issue and understand the root cause.

@pr8x
Copy link
Author

pr8x commented Jun 15, 2020

For me, the issue was resolved by deleting the msys2 folder beforehand. Should we close this and create seperate ticket for @rrouse' issue?

@emptyVoid
Copy link
Contributor

Yeah, I think rrouse' issue deserves a separate ticket.

As per this issue, please, don't close it just yet -- I'll create a PR resolving the need of deleting MSYS2 folder manually.

@BillyONeal
Copy link
Member

See also #11835 which is also broken by pacman :(

@JackBoosY
Copy link
Contributor

Hi guys, is this issue resolved?

@JackBoosY
Copy link
Contributor

We haven't been able to repro this; if more information comes up, or this issue appears again, please reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:tool-update The issue is with build tool or build script, which requires update or should be executed correctly requires:repro The issue is not currently repro-able
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants