ci: pin libjxl to 0.11.* in geotiff-corpus and cog-validator envs#3639
Merged
Conversation
conda-forge published libjxl 0.12.0 on 2026-07-03 before rebuilding libgdal-core/rasterio against it. An unpinned solve now installs a GDAL linked to libjxl.so.0.11 alongside libjxl 0.12, so rasterio fails at import and both workflows have been red on main since then. Pin libjxl to 0.11.* so the solve matches the last green combination (libjxl 0.11.2 + libgdal-core 3.12.3 + rasterio 1.5.0; verified with a dry-run solve). Remove the pin once conda-forge rebuilds the GDAL stack against libjxl 0.12.
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
1 participant
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.
pytest-geotiff-corpus and pytest-cog-validator have been red on main since 2026-07-03. Both die at the rasterio import check:
conda-forge published libjxl 0.12.0 on 2026-07-03. The libgdal-core 3.12.3 and rasterio 1.5.0 builds we get are still linked against libjxl 0.11, and nothing in their metadata caps libjxl below 0.12, so a fresh solve installs 0.12.0 next to binaries that want
libjxl.so.0.11(libjxl.0.11.dylibon macOS, where the loader error nameslibgdal.38.3.12.3.dylibas the culprit). The last green run (2026-07-03 04:43 UTC) solved libjxl 0.11.2 with the exact same libgdal-core and rasterio builds, so this is purely an upstream packaging gap, not a repo change.Fix: add
libjxl=0.11.*to the micromamba create-args in both workflows. A local dry-run solve with the pin reproduces the last green combination (libjxl 0.11.2, libgdal-core 3.12.3 he63569f_3, rasterio 1.5.0). Once conda-forge rebuilds the GDAL stack against libjxl 0.12 the pin should come back out; there's a comment in both workflow files saying so.