GH-49930: [CI][C++] Pin MinGW MSYS2 packages to unblock CI

[tadeja]

Rationale for this change

! Temporary workaround for #49930 !!
Both MinGW jobs fail every run since 2026 April 30, likely because of two MSYS2 updates:

1. MINGW64: gcc 15.2 -> 16.1 made the intermittent __emutls race in ThreadPool always reproduce (see [C++][CI] arrow-json-test segfaults occasionally on AMD64 Windows MinGW MINGW64 C++ job #49272, fix in GH-49272: [C++][CI] Fix intermittent segfault in arrow-json-test with MinGW #49462).
2. Both MINGW64 and CLANG64: aws-sdk-cpp 1.11.479 -> 1.11.801 stopped sending Content-Md5 on DeleteObjects; bundled MinIO RELEASE.2024-09-13 still requires it.

What changes are included in this PR?

CI change, new Pin MSYS2 packages step in cpp.yml

Are these changes tested?

Tested on a fork:
failing ->
passing

Are there any user-facing changes?

No

• GitHub Issue: [CI][C++] MinGW jobs fail every run after MSYS2 toolchain updates #49930

[github-actions]

⚠️ GitHub issue #49930 has been automatically assigned in GitHub to PR creator.

[tadeja]

With temporary CI changes here MinGW failing tests now pass...
Except for the single test arrow-flight-test Timeout on CLANG64 - could we rerun this? (@kou ?) https://github.com/apache/arrow/actions/runs/22742119641/job/65957707054?pr=49402#step:14:1080

arrow-flight-test has this issue already logged (for odbc) #49465

[tadeja]

@raulcd do you agree we could temporarily use solution from this draft PR (= listed failures in newer, broader issue #49930) in order to resolve MinGW C++ failures on CI while waiting on stuck PR #49462 (= your older issue #49272)?

[raulcd]

I think we faced this in the past on other jobs and we updated the minio version which contains the fix for newer aws-sdk-cpp. Shouldn't we just update minio version this is what we use on other jobs:

# Use specific versions for minio server and client to avoid CI failures on new releases.
minio_version="minio.RELEASE.2025-01-20T14-49-07Z"
mc_version="mc.RELEASE.2024-09-16T17-43-14Z"

As per the issue with the segfault, I think we should deal with it independently and possibly apply the proposed fix?

[kou]

It seems that some MinIO alternatives such as https://github.com/rustfs/rustfs .
Can we migrate from MinIO to solve this problem?

[tadeja]

It seems that some MinIO alternatives such as https://github.com/rustfs/rustfs . Can we migrate from MinIO to solve this problem?

interesting point! @kou rok mentions there's this existing issue, perhaps best to discuss alternative there? #47908

[raulcd]

It seems that some MinIO alternatives such as https://github.com/rustfs/rustfs . Can we migrate from MinIO to solve this problem?

For this specific issue I think that's unnecessary. The problem is that MinGW was using an old version of aws-sdk which was compatible with the minio version used. Now that they've updated the aws-sdk we just require to use the newer version. This exact same issue happened in the past with other jobs, basically AWS shipped a breaking change. I think for this one is enough with updating the version.

I do agree that we could (even should) migrate away from MinIO as the are not supporting their OSS offering anymore:
minio/minio@27742d4

Should we create a different issue for moving away from MinIO?

[raulcd]

oh! there's an issue already, yeah, I agree we should discuss there. Thanks @tadeja !

[tadeja]

• Bumped bundled MinIO to RELEASE.2025-01-20T14-49-07Z to match ci/scripts/install_minio.sh (per @raulcd's review).

• aws-sdk-cpp 1.11.479-1 stays pinned in the MINGW64 list for ABI compat (1.11.801-1 was rebuilt against gcc-libs 16.1 and would mismatch the rest of the libstdc++-15.2 cascade). Could test removing it once GH-49272: [C++][CI] Fix intermittent segfault in arrow-json-test with MinGW #49462 is solved. OK to wait?

• Agreed, the segfault belongs in [C++][CI] arrow-json-test segfaults occasionally on AMD64 Windows MinGW MINGW64 C++ job #49272. Happy to help with PR GH-49272: [C++][CI] Fix intermittent segfault in arrow-json-test with MinGW #49462 @vanshaj2023 (needs a rebase + the \ continuation removed from the new test comment, breaks -Werror=comment + GCC bug ref added to the description) cc @vanshaj2023

[raulcd]

@tadeja I am unsure I understand why aws-sdk requires pinning due to the failure as the failure is unrelated to AWS (it's on arrow JSON). Is it because of the other pins?

Can you try removing the pins (maybe temporarily) to validate the S3 issue is solved? Based on the assessment only the arrow-json failure should be raised now.