New installer hangs on clangarm64

[jeroen]

See: https://github.com/r-windows/r-devel/actions/runs/7523495967/job/20476942849

Run msys2/setup-msys2@v2
Downloading MSYS2...
Extracting MSYS2...
Disable Key Refresh...
Restoring package cache...
Starting MSYS2 for the first time...
Disable CheckSpace...
Installing additional packages through pacman...
Saving package cache...
  C:\Windows\system32\cmd.exe /D /S /C C:\actions-runner\_work\_temp\setup-msys2\msys2.cmd -c "'paccache' '-r' '-f' '-u' '-k0'"
  Error: The operation was canceled.

I tried wiping the GHA caches, rebooting my runner, but it keeps hanging.

[jeremyd2019]

I kind of suspect it's the same root cause as msys2/MSYS2-packages#4340 and msys2/msys2-autobuild#62.

[jeroen]

FWIW, I run this job every day and it started specifically after 280250c. A workaround is to set cache: false like so:

      - uses: msys2/setup-msys2@v2
        timeout-minutes: 15
        with:
          msystem: ${{ matrix.msystem }}
          install: git patch make unzip pactoys
          cache: false

[jeremyd2019]

I was going to comment that I set up arm64 runner images with msys2 'manually', and then use release: false in setup-msys2, but it turns out msys2-autobuild also disables the cache on arm64 runners: https://github.com/msys2/msys2-autobuild/blob/1c45f2ab2e58030a886d3c22ac161f01107896cc/.github/workflows/build.yml#L155

This was due to actions/toolkit#1311.

[lazka]

Not sure what could be the change causing this, except timing differences.

[jeremyd2019]

gnutls was just updated, which is part of the base system, so the timing should be changed up a bit. does this issue still happen?

[jeroen]

Yes the issue still happens: https://github.com/r-windows/r-devel/actions/runs/7568995399/job/20611357016

[jeremyd2019]

Interesting, on that one it seems to have hung up earlier, during the first start initialization of gnupg, before pacman is run. I've gotten plenty of hangs in plenty of places, but never there before...

[jeroen]

Interesting, on that one it seems to have hung up earlier, during the first start initialization of gnupg, before pacman is run. I've gotten plenty of hangs in plenty of places, but never there before...

It could be that the output of GHA is truncated. That seems to happen sometimes when a hang is killed.

[jeroen]

Sometimes it hangs here

  gpg: /etc/pacman.d/gnupg/trustdb.gpg: trustdb created
  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

Could it be due to flaky gpg keyservers?

Is it really needed to do this "migrate" step at every installation? Would it be possible to make the snapshot already contain the migrated/imported keys?

[lazka]

This was added 12 years ago in pacman: https://gitlab.archlinux.org/pacman/pacman/-/commit/0c9e86bab17691bf17c4251b2e16d65f517b88c8 and installing Arch Linux also shows those messages.

Since those files are empty anyway there shouldn't be anything being migrated, but who knows what gnupg does. We could ask upstream.

[lazka]

It's also assumed in libalpm: https://gitlab.archlinux.org/pacman/pacman/-/blob/3c28c301335f8f83b55ae536143ce944c40c8063/lib/libalpm/signing.c#L158 and there are no gnupg version checks, so not that easy.

[jeremyd2019]

https://cygwin.com/pipermail/cygwin-patches/2024q1/012617.html