Failing depext install on windows

[SkySkimmer]

eg https://github.com/rocq-community/rocq-lsp/actions/runs/25496448387/job/74817386293

The following system packages will first need to be installed:
    mingw64-i686-gcc-core mingw64-i686-gmp mingw64-x86_64-gmp pkgconf

<><> Handling external dependencies <><><><><><><><><><><><><><><><><><><><><><>

+ C:\.opam\.cygwin\setup-x86_64.exe "--root" "C:\\.opam\\.cygwin\\root" "--quiet-mode" "noinput" "--no-shortcuts" "--no-startmenu" "--no-desktop" "--no-admin" "--no-version-check" "--no-write-registry" "--packages" "mingw64-i686-gcc-core,mingw64-i686-gmp,mingw64-x86_64-gmp,pkgconf" "--symlink-type" "native" "--upgrade-also" "--only-site" "--site" "https://cygwin.mirror.constant.com/" "--local-package-dir" "C:\\.opam\\.cygwin\\cache"
Error: Process completed with exit code 1.

Not sure what's going on

[smorimoto]

What happens if you re-run it?

[SkySkimmer]

It has run a few times already with same error https://github.com/rocq-community/rocq-lsp/actions/runs/25445718848/job/74649127210 https://github.com/rocq-community/rocq-lsp/actions/runs/25446431242/job/74651749921 https://github.com/rocq-community/rocq-lsp/actions/runs/25497517967/job/74821129457 https://github.com/rocq-community/rocq-lsp/actions/runs/24994389015/job/73187557906

[smorimoto]

@kit-ty-kate, I wonder whether this might be caused by opam trying to upgrade its internal Cygwin whilst that same Cygwin is in use.

I compared a successful run with the failing ones:

• On 20 April, the Windows job had no opam cache, created a fresh internal Cygwin, and successfully installed the same depexts.
• That run then saved the entire C:\.opam root, including .cygwin.
• Cygwin 3.6.9-1 was published on 21 April.
• The first failure I found was on 27 April. It restored the opam cache created by the 20 April run; subsequent failures restored the same cache key.
• The setup-ocaml cache key includes the Windows release, opam version, compiler, etc., but not the internal Cygwin version.
• For an actual depext installation, opam 2.5.1 invokes the internal Cygwin installer with --upgrade-also.

There is one additional detail which might matter here: the workflow runs

opam exec -- make opam-deps

and that Make target invokes opam install. On Windows, the outer make.exe comes from the internal Cygwin. If the restored installation still contained the pre-3.6.9 Cygwin DLL, setup.exe may therefore have attempted to upgrade that DLL whilst make (and possibly its shell) still had it loaded. That would explain why the fresh installation succeeded, but the cached installation started failing immediately after the Cygwin release, with setup.exe returning 1.

This is only a hypothesis because --quiet-mode noinput suppresses the useful setup diagnostics. The decisive evidence should be in:

C:\.opam\.cygwin\root\var\log\setup.log.full

It may be worth printing that file in an always() step after a reproduction. If it reports an in-use/replacement failure for cygwin1.dll or another Cygwin component, this would appear to be an opam internal-Cygwin self-upgrade issue which setup-ocaml's cache makes readily reproducible.

[MavenRain]

A new, distinct wave of Windows depext failures started 2026-07-26: this
one is a Cygwin pkgconf packaging bug, not the stale-cache/DLL issue
discussed above, so filing the diagnosis here for anyone bisecting red
CI today.

Symptom: opam install fails building conf-mingw-w64-gmp-i686,
conf-mingw-w64-gmp-x86_64, conf-mingw-w64-zlib-x86_64; their probe
pkgconf --personality=<triplet>-w64-mingw32 <lib> exits 1 with no
output.

Root cause: Cygwin's pkgconf 3.0.4-1 (released 2026-07-26 07:46) is
compiled with personality search path
/usr/lib/pkgconfig/personality.d:/usr/share/pkgconfig/personality.d
(strings on libpkgconf8 confirms), but the package still installs the
mingw personality files under /etc/pkgconfig/personality.d (where the
2.5.1-1 binary used to look). libpkgconf silently falls back to the
native personality when the file is not found, so the probe searches
native paths and fails. Runs that got pkgconf 2.5.1-1 (last green:
Jul 25) are unaffected; nothing changed in setup-ocaml (v3.7.0 in both
green and red runs), opam, or opam-repository.

Workaround until Cygwin fixes the packaging, since pkgconf 3.x also
consults $XDG_DATA_DIRS/pkgconfig/personality.d:

- run: |
    "XDG_DATA_DIRS=/etc:/usr/local/share:/usr/share" >> $env:GITHUB_ENV

before the opam install step (Windows only). Verified against
rocq-prover/rocq CI; ahrefs/ocannl hit the same failure independently,
which brackets the regression window to Jul 26 09:42-13:02 UTC.
Reported to the Cygwin mailing list as well.

[kit-ty-kate]

@kit-ty-kate, I wonder whether this might be caused by opam trying to upgrade its internal Cygwin whilst that same Cygwin is in use.

Unless setup-ocaml uses the internal cygwin as login shell or something, i don't think so. opam doesn't call anything else while the depexts are being installed.

This is only a hypothesis because --quiet-mode noinput suppresses the useful setup diagnostics.

It could be a setup.exe bug. It would indeed be useful to be able to see the log.

It's possible that the whole thing is simply a setup.exe bug or a cygwin bug, these are not unheard of. Has this appeared again with cygwin 3.6.10? (changelog)