conda-forge also uses GHA for infrastructure and automation, and there is no way to split the general pool into smaller subpools with different priorities. All the repos in the organization are part of a flat FIFO queue. In order to avoid self-DOS'ing our infra, we are implement a few rules:

• In order to guarantee fair use across all repositories, a given feedstock can only run up to 50 concurrent GHA jobs. Feedstocks needing more concurrent jobs can still use Azure by setting the appropriate value in the provider section of their conda-forge.yml.
• We reserve the right to cancel build jobs if the org-wide limits are close to being hit. This is done to secure a buffer of runners for infrastructure and automation jobs.

As a reminder, the only Github Actions workflows that can be used are those provided by conda-smithy rerender, without any further modifications. Any other use is forbidden and may be removed without prior warning.

This will not affect already-published artefacts, and you will not receive incompatible builds even when still using an older Mac. However, going forward, to be able to keep using the most recent packages from conda-forge, you will need to update your OS to at least 11.0.

The reason conda-forge is able to support macOS versions far beyond their end-of-life is due to the fact that -- unlike many other paradigms -- we are able to always ship an up-to-date C++ standard library (libcxx on OSX) in user environments, superseding the system library (at least from the point of view of packages in the respective conda environments) that's usually too outdated for contemporary packaging needs.

However, several core packages in the ecosystem have begun requiring 11.0 or newer, in a way that we cannot be circumvent. The key driver for this is libcxx itself; it has a foundational role in our infrastructure, and many aspects depend on this library being up-to-date. Given that libcxx itself will begin requiring macOS 11.0 as of v22.1, we need to follow suit.

Other fundamental packages that already require a newer deployment target is the qt ecosystem, languages like go, nodejs, dotnet, zig, and key libraries like libabseil and libprotobuf. Since go already requires a deployment target of at least 12.0, we have added a custom migrator that will send PRs to update go-feedstocks without having to do manual modifications.

As soon as we make the switch, all new builds (on properly rerendered feedstocks) in conda-forge for OSX will require at least 11.0. This constraint is implemented via the {{ stdlib("c") }} meta-package, which picks up c_stdlib_version from our global pinning (unless overridden on the feedstock in recipe/conda_build_config.yaml), and will inject (on OSX) a corresponding constraint on __osx >=11 in the package metadata. This instructs the resolver to ignore such artefacts on older systems, ensuring that no incompatible packages get installed.

If you are overriding c_stdlib_version or MACOSX_SDK_VERSION to values <=11.0 in your feedstock, please remove that configuration, as it has become redundant.

For more details (or questions) about this, see https://github.com/conda-forge/conda-forge.github.io/issues/2467.

This special Tegra variant is only relevant for packages still targeting CUDA 12.9 because starting with CUDA 13.0, supported Tegra devices are SBSA-compliant, so they do not need to be targeted separately.

• 2PM UTC
• 5PM UTC

The first meeting in 2026 will take place on January 7th, at 5PM UTC. For more details consult our calendar.

The meeting minutes will be available in both conda.org and conda-forge.org, in the usual places.

This is one of our first steps towards reducing the administrative duplication existing between these overlapping communities.

This change may result in some build systems, particularly CMake, storing paths to this temporary build directory in installed metadata. Feedstocks will need to substitute the stored paths with path-agnostic solutions (for example, see substitutions in openpmd-api-feedstock) or the correct sysroot paths (for example, see substitutions in cartographer-feedstock).

macOS 13.3 updated the Accelerate framework after a long time with improved support for LAPACK APIs and has fixes for long-time known bugs in the older Accelerate's BLAS and LAPACK APIs. conda-forge has added support for this new Accelerate framework by using a shim library to expose its functionality to most conda-forge packages including numpy, scipy and pytorch.

You can use it by doing

conda install libblas=*=*_newaccelerate

For more details, see https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/7421.

We are planning to update our default compilers on windows to the (fully compatible) successor VS2022 in one week from now.

This will not affect you as a general user of conda-forge packages on windows; the only potential impact is that if you are compiling locally with VS2019 against artefacts produced by conda-forge, you might be required to upgrade.

For more details see https://github.com/conda-forge/conda-forge.github.io/issues/2138.

For CUDA-enabled feedstocks, we've been building both 11.8 and 12.6 by default for a while now, but many feedstocks (notably pytorch, tensorflow, onnx, jax etc.) have dropped CUDA 11.8 for many months already.

Due to various constraints (details below), we are dropping CUDA 11.8 as a default version in our global pinning on June 5th. It will still be possible to opt into building CUDA 11.8 on a per-feedstock basis where this is necessary or beneficial.

The above-mentioned contraints are mainly:

• it complicates our pinning due to needing to switch images and compilers with 11.8.
• it keeps us from migrating to newer CUDA 12.x versions necessary to support new architectures.
• it's not compatible with VS2022, which is due to become the default toolchain on windows in conda-forge soon (the previous VS2019 has reached end-of-life more than a year ago).
• it complicates our infrastructure in several places, due to the big differences between the before/after of the new CUDA architecture.

After we have removed CUDA 11.8 from the pinning, any feedstock still building that version will drop the respective CI jobs upon rerendering. For feedstocks wanting to keep building CUDA 11.8 a bit longer, we have provided a custom migrator.

The way to make use of this is to copy cuda118.yaml from the global pinning into .ci_support/migrations on your feedstock. If the migrations subfolder doesn't exist, please create it. Once that's committed (and there are no skips in the recipe for CUDA 11.8), rerendering the feedstock will reinstate the builds for CUDA 11.8. If you have trouble with that, please open a thread on https://conda-forge.zulipchat.com/.

Finally, please let us know in the issue if your feedstock still needs to support CUDA 11.8 and why (later down the line we'll want to drop support also in conda-forge-ci-setup, and knowing what feedstocks - if any - still need CUDA 11.8 will help guide the decision on timing).

For feedstocks that are not compatible with v2.x yet, this means you will have to add

numpy:
  - 1.26  # or 1.25

to your recipe/conda_build_config.yaml, and then rerender. Pins below 1.25 are not possible if your feedstock supports Python 3.12, as NumPy 1.25 was the first version with support for that Python version (and it will not be possible going forward to pin different NumPy versions for different Python versions).

Downstream users building on top of the Ubuntu variant of our containers should verify compatibility with the updated environment.

Thanks to @rpanai for the contribution and to the reviewers for their input.

More details in the corresponding blog post.

1. We've updated our default docker images to be based on alma9
2. It is now easier to override c_stdlib_version (especially for CUDA-enabled feedstocks), though our baseline of 2.17 hasn't changed.
3. Where necessary, you can more easily switch images by setting os_version: ... (see below).
4. We've consolidated our image names to follow a consistent pattern:

linux-anvil-{x86_64,aarch64,ppc64le}:{cos7,alma8,alma9}

In general, it won't be necessary in the vast majority of cases to override the docker-image, but if you need to do so, you can add the following to conda-forge.yml

os_version:             # just to demo different values;
  linux_64: cos7        # whenever possible, please use
  linux_aarch64: alma8  # homogeneous distro versions
  linux_ppc64le: alma9  # across platforms

Linux builds in conda-forge run on infrastructure derived from RHEL and its clones -- previously CentOS, now AlmaLinux. Primarily we need this for four different interrelated but distinct pieces:

• the docker images (containing the OS which will execute our builds)
• the sysroot (mainly the C standard library, glibc)
• the CDTs (pieces from the distribution we cannot package ourselves)
• feedstock usage of yum_requirements.txt

A first key observation is that the glibc appears twice -- once explicitly in the sysroot we package (and compile against!), and once implicitly in the image that our CI runs on. This setup is essential to provide highly compatible packages by default (by compiling against a cos7 baseline), while avoiding constant hassles for feedstocks where any of the build/host/run dependencies requires a newer glibc than the baseline.

This is because, for packages requiring a newer c_stdlib_version (and thus compiling against a newer sysroot through the {{ stdlib("c") }} infrastructure), will inherit a runtime-requirement of __glibc >=c_stdlib_version, which would be unsatisfiable on docker-images with a too-old glibc present at runtime.

We've already had this setup since 2021 (when our glibc baseline was 2.12 from cos6, yet we already used cos7 images), but after increasing the glibc baseline to 2.17, our images had lost their lead again. This is mostly related due to the third component from above, the CDTs (core dependency trees). These represent packages from the distribution itself that are hard or impossible for us to provide, yet need a systematic way to interact with. You can read more about why we want to avoid them as much as possible here.

Due to the end of CentOS-as-we-knew it, we already had to rewrite a lot of the logic there in any case to switch to Alma, which we took as an opportunity to pare down the set of CDTs we provide going forward. In a large majority of cases, we have regular conda packages for some things that only used to be available as CDTs.

CDTs and packages in yum_requirements.txt are closely related; in many ways it can be considered a similar compilation-vs.-runtime split as is the case with our sysroot (that we compile against) vs. the glibc in the image at runtime. The split here being that CDTs are what we use to compile against a given distro package, and yum_requirements.txt are how we tell the infrastructure to install them into the image, if they're also necessary at runtime (which is not always the case).

In other words, using our own packages generally allows feedstocks to avoid both use of CDTs and yum_requirements.txt. You can check out the CDTs we removed here and how yum_requirements.txt translate from CentOS to Alma (resp. our own packages) here.

The change of the image might mean that CDTs we have not repackaged for Alma do not match what's actually in the image anymore, or -- in rare cases -- that a package name under yum_requirements.txt needs to be updated. Please let us know if you run into problems there (after checking out the two links above how to transition a given package).

Finally, there is one rare case where we explicitly ask feedstock authors to opt out of the newest images: for any feedstocks doing binary repackaging on linux (i.e. not compiling the package from source), please ensure that your image version (as specified in conda-forge.yml, see above) matches the c_stdlib_version that you are using. By default this is 2.17, which means you'd have to do

os_version:
  linux_64: cos7
  linux_aarch64: cos7
  linux_ppc64le: cos7

If you require a c_stdlib_version of 2.28 for a given platform, then set alma8.

For clarity, these are the next dates:

• November 13th, 2024 at 17:00 UTC
• November 27th, 2024 at 14:00 UTC
• December 11th, 2024 at 17:00 UTC
• December 25th, 2024 at 14:00 UTC
• January 8th, 2025, at 17:00 UTC
• ... and so on.

A new calendar is now available in the Community > Meetings section to help find the dates.

This vote has passed and now we are opening the doors to our Zulip instance: https://conda-forge.zulipchat.com/. Please sign up to stay in touch!

As per CFEP-23 (read it for more details), this means that we will stop using our Element chat rooms. Instead all chat activity will continue in Zulip.