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.