From 9f59add34a8629baeab8e677e941209def6d445f Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 30 Jul 2026 22:21:22 +0000 Subject: [PATCH 1/2] ci: pin Windows jobs to the windows-2022 runner The windows-latest image no longer ships Visual Studio 2022; it now provides Visual Studio 18 (VSINSTALLDIR .../Visual Studio/18/Enterprise, VisualStudioVersion 18.0). Every Windows job in this workflow configures CMake with -G "Visual Studio 17 2022", so they all fail at configure time: CMake Error at CMakeLists.txt:2 (project): Generator Visual Studio 17 2022 could not find any instance of Visual Studio. Nothing in the repository changed -- this workflow is byte-identical to the last commit whose CI was fully green -- so pin the Windows matrix entries to windows-2022, which still provides the toolchain the generator asks for. This restores exactly the configuration that was last green. Only ci.yml hardcodes the generator; vcpkg.yml and conan.yml let CMake pick one and their Windows jobs still pass on windows-latest, so they are left alone. Follow-up: adopt Visual Studio 18 on windows-latest so this does not need revisiting when windows-2022 is retired. That is a separate change since it builds against a toolchain these projects have not been tested with. --- .github/workflows/ci.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 4aa2df5..a57d35c 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -17,7 +17,7 @@ jobs: # Windows builds - { name: "Windows MSVC Module Debug", - os: windows-latest, + os: windows-2022, cc: "cl", cxx: "cl", build_type: "Debug", @@ -26,7 +26,7 @@ jobs: } - { name: "Windows MSVC Module Release", - os: windows-latest, + os: windows-2022, cc: "cl", cxx: "cl", build_type: "Release", From b71fc8df360884e5caa1238ce29d01be123f284c Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 30 Jul 2026 22:45:16 +0000 Subject: [PATCH 2/2] fix(conan): cap the openssl requirement below 4 openssl/4.0.1 reached conancenter, and the unbounded openssl/[>=3.0] range started resolving to it. minizip-ng/4.2.1 requires openssl/[>=1.1 <4], so the graph no longer resolves: ERROR: Version conflict: Conflict between openssl/[>=1.1 <4] and openssl/4.0.1 in the graph. Conflict originates from minizip-ng/4.2.1 Cap the range at <4 so it agrees with minizip-ng and keeps resolving to OpenSSL 3.x, which is what this package is built and tested against. Same class of breakage as the Windows runner change in this PR: an unpinned upstream moved, not a change in this repository. --- packages/Conan/neko-function/all/conanfile.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/Conan/neko-function/all/conanfile.py b/packages/Conan/neko-function/all/conanfile.py index 165cc38..7ec4a24 100644 --- a/packages/Conan/neko-function/all/conanfile.py +++ b/packages/Conan/neko-function/all/conanfile.py @@ -39,7 +39,7 @@ def set_version(self): def requirements(self): if self.options.enable_hash: - self.requires("openssl/[>=3.0]") + self.requires("openssl/[>=3.0 <4]") if self.options.enable_archive: self.requires("minizip-ng/[>=4.0]")