v2.9.0

[mgorny]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Fixes #430. Added py3.14 migration too, let's see how it goes.

[h-vetinari]

let's see how it goes.

During debugging, can you please reduce the number of builds to ~one python version? Or maybe one+3.14

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The magma output has been superseded by libmagma-devel.
• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/18806987615. Examine the logs at this URL for more detail.}

[mgorny]

let's see how it goes.

During debugging, can you please reduce the number of builds to ~one python version? Or maybe one+3.14

Sure. Could you stop the Azure builds then?

[h-vetinari]

Sure. Could you stop the Azure builds then?

Azure is much less critical for resource scarcity, but if you want sure. Easiest is to just push a skip though

[mgorny]

I'll also strip down CUDA targets.

[mgorny]

(mumbling about platform-conditional patching)

[mgorny]

I have an updated patch ready, but will wait for other jobs to finish.

[mgorny]

Looks like it's not ready for py3.14 yet. I'm going to look for another solutions for triton later today.

[mgorny]

Okay, so:

• linux-64 jobs are failing over being unable to find pybind11 headers
• linux-aarch64 jobs are failing over some computation assert (help?)
• win-64 jobs are failing over asmjit.dll install — I must have failed at updating the patch

[h-vetinari]

I think the conclusion from #413 was that we'll have to add in the pybind migration (c.f. #415) for v2.9