gpgme: work around pacman hangs on Windows/ARM64 runners

When running `pacman` on Windows/ARM64, we frequently run into curious
hangs (see msys2/msys2-autobuild#62 for more
details).

This commit aims to work around that by replacing the double-fork with a
single-fork in `_gpgme_io_spawn()`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

gpgme/0002-Work-around-pacman-hangs-on-Windows-ARM64.patch

@@ -0,0 +1,62 @@
+From 7501c30e631fad336bb3ae9339d9d5738fea9102 Mon Sep 17 00:00:00 2001
+From: Johannes Schindelin <johannes.schindelin@gmx.de>
+Date: Sat, 4 May 2024 19:51:52 +0000
+Subject: [PATCH] Work around `pacman` hangs on Windows/ARM64
+
+When calling `pacman` in GitHub Actions runners that run Windows/ARM64,
+we frequently experience curious hangs while Pacman is verifying signatures.
+
+These hangs are somewhat flaky, it seems as if certain scenarios (slow
+machines, for example) make the hangs more likely.
+
+A common symptom is that the hanging process has a command-line that is
+identical to its parent process' command-line (indicating that it has
+been `fork()`ed), and anecdotally, the hang occurs when `_exit()` calls
+`proc_terminate()` which is then blocked by a call to
+`TerminateThread()` with an invalid thread handle (for more details, see
+https://github.com/msys2/msys2-autobuild/issues/62#issuecomment-1951796327).
+
+In my tests, I found that the hanging process is spawned from
+`_gpgme_io_spawn()` which lets the child process _immediately_ spawn
+another child. That seems like a fantastic way to find timing-related
+bugs in the MSYS2/Cygwin runtime.
+
+As a work-around, it does seem to help if we avoid that double-fork.
+
+This partially reverts 61aa1947 (... Use a double-fork approach...,
+2002-08-28).
+
+Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
+---
+ src/posix-io.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/src/posix-io.c b/src/posix-io.c
+index a422d8f..8e4d9c5 100644
+--- a/src/posix-io.c
++++ b/src/posix-io.c
+@@ -552,7 +552,7 @@ _gpgme_io_spawn (const char *path, char *const argv[], unsigned int flags,
+   if (!pid)
+     {
+       /* Intermediate child to prevent zombie processes.  */
+-      if ((pid = fork ()) == 0)
++      // if ((pid = fork ()) == 0)
+ 	{
+ 	  /* Child.  */
+           int max_fds = -1;
+@@ -676,10 +676,12 @@ _gpgme_io_spawn (const char *path, char *const argv[], unsigned int flags,
+ 	_exit (0);
+     }
+
++#if 0
+   TRACE_LOG  ("waiting for child process pid=%i", pid);
+   _gpgme_io_waitpid (pid, 1, &status, &signo);
+   if (status)
+     return TRACE_SYSRES (-1);
++#endif
+
+   for (i = 0; fd_list[i].fd != -1; i++)
+     {
+-- 
+2.39.1.windows.1
+

gpgme/PKGBUILD

@@ -3,7 +3,7 @@
 pkgbase=gpgme
 pkgname=('libgpgme' 'libgpgme-devel' 'libgpgme-python')
 pkgver=1.23.2
-pkgrel=1
+pkgrel=2
 pkgdesc="A C wrapper library for GnuPG"
 arch=('i686' 'x86_64')
 url="https://gnupg.org/related_software/gpgme/"
@@ -26,10 +26,12 @@ makedepends=(
   'python-wheel'
 )
 source=(https://gnupg.org/ftp/gcrypt/${pkgbase}/${pkgbase}-${pkgver}.tar.bz2{,.sig}
-        0001-fix-broken-version.patch)
+        0001-fix-broken-version.patch
+        0002-Work-around-pacman-hangs-on-Windows-ARM64.patch)
 sha256sums=('9499e8b1f33cccb6815527a1bc16049d35a6198a6c5fae0185f2bd561bce5224'
             'SKIP'
-            '80771f9811ad809c8ff8977b05cfcc0d2d4a1c764c3df6ae5aa91c5aa7565a9a')
+            '80771f9811ad809c8ff8977b05cfcc0d2d4a1c764c3df6ae5aa91c5aa7565a9a'
+            '97f0272b4a7dcaadf857ce8f63b1de73855ad977d046b5c926c87977b83ee157')
 #These might be signed by any of these keys https://gnupg.org/signature_key.html
 validpgpkeys=('5B80C5754298F0CB55D8ED6ABCEF7E294B092E28'
               '6DAA6E64A76D2840571B4902528897B826403ADA'
@@ -40,6 +42,7 @@ prepare() {
 
   # otherwise it appends "unknown" to the version which isn't a valid python version
   patch -p1 -i "${srcdir}/0001-fix-broken-version.patch"
+  patch -p1 -i "${srcdir}/0002-Work-around-pacman-hangs-on-Windows-ARM64.patch"
 
   autoreconf -ivf
 }