2025-39: A week in conda-forge

 · 

In the third week of reporting on my conda-forge work, you will see how the large number of contributions happens quickly. As we’re getting closer to the Python 3.14 release, I spent some time bringing that forward.

The week started with a rust-dev update. These updates are based on a script that regenerates a section of the meta.yaml, but the PRs themselves are not yet automated. In the same weekly cleaning session, I manually closed the close aws_c_202509 migration and aws_crt_cpp0343 migration.

Last week, the libxml2 migration progressed. Unfortunately, this also meant some breakage in a few places. I spent some time debugging lxml-feedstock#105, where we need to pin to libxml2-16 2.14.x. This is much stricter than the run_exports of the libxml2 packages enforces. In the end, this was not an unstable ABI but a change in the build that occurred in the latest minor release. While the PR for the libxml2 for ibm_db passed, it sadly resulted in failing packages as it picked the system libxml2 and not the new conda-forge version. Thus, we marked these builds as broken in admin-requests#1672. We fixed the linkages in ibm_db-feedstock#87 by pinning to the old version.

As I’m a maintainer (also user) of pcre2-feedstock, I spent a bit of time reviewing the PRs that were still open on the pcre2 10.46 migration:

Meanwhile, I made minor fixes in librsvg-feedstock#129 and reviewed admin-requests#1674 and sqlglotrs-feedstock#33. As some colleagues required specific versions of Netbird, I contributed that via staged-recipes#31096 and added linux-aarch64, linux-ppc64le, and osx-arm64 immediately afterwards.

As jaxlib 0.7.1 was merged, it was time to continue work on jaxlib v0.7.2. @h-vetinari already started working on this, so it wasn’t a fresh start. As part of the new version, I updated the absl third-party dependency by adding new log targets. We could also drop the GCC 15 fixes we did for 0.7.1, as they were already integrated into this release. Sadly, the compilation now takes longer on osx-64, and to get it below the six-hour limit, I changed the oneDNN build from the bundled version to linking against the conda-forge package. Meanwhile, we also attempted to migrate to CUDA 13. This sadly failed, as not even the latest Clang 21 release can build CUDA 13 device code. Still, I used the chance to contribute Clang 21 support to google-ml-infra/rules_ml_toolchain#88.

There were again several (trivial) merges I did this week using my maintainer duties or conda-forge/core powers:

As a first step, I manually opened pymsbuild-feedstock#25, as the bot did not open a migration PR for it, but already had ones for packages depending on it. Similarly, conda-feedstock#274 failed because it needs mamba to migrate first. We could close futures-feedstock#17 , as futures is a Python 2.x-only package. I requested its archival in admin-requests#1671.

Then there was a round of PRs that could be merged, because they either were part of an abandoned feedstock or the maintainer had already approved it: cchardet-feedstock#24, flt-feedstock#14, and fake-factory-feedstock#26

For fill-voids-feedstock#6 and fisher-feedstock#30, I triggered a bot rerun because they looked good but had conflicts that prevented their direct merge.

Some PRs could easily be fixed by adding setuptools to host. Since Python 3.13, conda-forge no longer ships it as an implicit dependency of pip and thus it often breaks the build for some packages on these newer Python releases. I applied it to the following feedstocks and pinged the maintainers once the CI was green: fastbpe-feedstock#18, fastpath-feedstock#13, and future_fstrings-feedstock#21.

Finally, there is a long list of feedstocks where I reviewed the PR and pinged the maintainers as the builds looked fine: