Conversation
Two things broke the release pipeline for v0.3.2:
1. Chocolatey now ships CMake 4.4.0, which advertises c_std_23 in
CMAKE_C_COMPILE_FEATURES for MSVC. libmdbx therefore selects
C_STANDARD 23 (/std:clatest), and MSVC then fails to parse the C23
attributes in mdbx.c:
mdbx.c(31103,21): error C2143: syntax error: missing ';' before 'const'
mdbx.c(31103,3): error C2416: attribute [[maybe_unused]] cannot be
applied in this context
Only build_wheels_all hit this because it is the job that runs
`choco install cmake`; the fast job kept using the image's older CMake
and got /std:c11. Pin CMAKE_C_STANDARD=11 for MSVC so the result no
longer depends on which CMake happens to be on PATH — this also fixes
sdist builds on Windows machines with CMake 4.x.
2. The macos-13 runner image was retired in December 2025, so those jobs
sat queued forever and never let the publish job start. Move to
macos-15-intel, the x86_64 replacement label (available until Aug 2027).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Linux wheel jobs fail intermittently in `git fetch --tags`, which
recurses into the submodule and has to reach gitflic.ru:
fatal: error processing acks: 4
Errors during submodule fetch:
libmdbx
##[error]Command ['sh', '-c', 'pip install ninja && git fetch --tags'] failed with code 1.
Nothing needs those tags any more. Since v0.13.x libmdbx resolves its
version solely from the committed VERSION.json (cmake/utils.cmake
fetch_version()), and its GNUmakefile never shells out to git either;
configuring a checkout with .git removed still yields
`MDBX_VERSION: 0.13.12`. Drop the fetch so a flaky third-party host is no
longer in the path of every wheel build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
test_db_iter records its random pairs in a list and asserts every one of
them afterwards, but id_generator() draws from 36^6 keys and the test makes
1024 draws per map across 15 maps — so a repeated key is a ~0.4% event per
run. When it happens the second put overwrites the first and the assertion
for the earlier pair fails:
AssertionError: '6F8NK3' != '8XJ126' (tests/test_mdbx.py:101)
That is roughly one red job in every few CI runs, which is enough to block
a release tag at random.
Keep the pairs in a dict and skip keys already drawn, which is what
test_multi_write right below already does. Verified by shrinking
id_generator to 3 characters so collisions are certain: the previous code
reproduces the exact failure above, the new code passes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Kudos to Claude! By manually reviewing, the code seems good.