Upgrade to CUDA 12.9

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update cuda129.

Notes and instructions for merging this PR:

1. Please merge the PR only after the tests have passed.
2. Feel free to push to the bot's branch to update this PR if needed.

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

---

Here are some more details about this specific migrator:

CUDA 12.8 added support for architectures sm_100, sm_101 and sm_120,
while CUDA 12.9 further added sm_103 and sm_121. To build for these,
maintainers will need to modify their existing list of specified architectures
(e.g. CMAKE_CUDA_ARCHITECTURES, TORCH_CUDA_ARCH_LIST, etc.)
for their package. A good balance between broad support and storage
footprint (resp. compilation time) is to add sm_100 and sm_120.

Since CUDA 12.8, the conda-forge nvcc package now sets CUDAARCHS and
TORCH_CUDA_ARCH_LIST in its activation script to a string containing all
of the supported real architectures plus the virtual architecture of the
latest. Recipes for packages who use these variables to control their build
but do not want to build for all supported architectures will need to override
these variables in their build script.

ref: https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html#new-features

---

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/16608834922 - please use this URL for debugging.}

Closes #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/recipe.yaml) and found it was in an excellent condition.

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

For recipe/recipe.yaml:

• ℹ️ 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/16609234881. Examine the logs at this URL for more detail.}

[shermansiu]

@conda-forge-admin, please re-render

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

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

[h-vetinari]

Marking as draft so the bot doesn't auto close (it's almost always better to rebase directly rather than rerun the bot).

When doing an interactive rebase of a bot PR: fix up minor conflicts (realistically only the build number might conflict), ensure the build number is increased (might be dropped as "has already happened on main"), and don't hesitate to drop the rerender commit and redo it either manually (or let the bot do it).

[h-vetinari]

As commented on #6, this PR should ideally be rebased (but if you're not comfortable with that, feel free to ask the bot to rerun).

For some reason the CI on the server did not run in #6, but does run on main. This is strange, and not in line with the config merged in conda-forge/.cirun#109 (which has pull_request: true). Before digging further, I'd like to see if CI in PRs works now that the config has been merged to main.

[h-vetinari]

Also, please remove automerge as explained in #2

[shermansiu]

Automerge removed!

[h-vetinari]

You're going to need to debug the cross compiled builds (since they never ran in #6). Something is not yet working with

vllm-feedstock/recipe/recipe.yaml

Lines 65 to 69 in c33b58a

	- if: is_cross_compiling
	then:
	- python
	- cross-python_${{ target_platform }}
	- pytorch ==${{ pytorch_version }}

or you need extra config to ensure the right python is found (see logs on main).

Also, developing/debugging with one python version only (quoting from #6):

In general, please be aware that you're using a very rare resource that's needed by other feedstocks as well. In particular, while developing a PR for some change, you should add

build:
  skip: match(python, "!=312")

(or however this is spelled in v1; still don't know it by heart). Once everything is green you can remove the skip to build out all version only once before merging.

---

Automerge removed!

In the same vein, please be mindful of not creating superfluous runs on main, but rather combine changes into a single PR where appropriate.

Working on the opengpu server needs some special rules you won't necessarily encounter in the rest of conda-forge, please don't blindly apply previously known patterns, but think about how you can use this resource judiciously and effectively.

[shermansiu]

OK, that's good to know, thanks!

[conda-forge-admin]

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

I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[shermansiu]

@conda-forge-admin, please rerender

[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/recipe.yaml) and found it was in an excellent condition.

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

For recipe/recipe.yaml:

• ℹ️ 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/16616126486. Examine the logs at this URL for more detail.}

[h-vetinari]

Note that CI cannot start for the bot commit. Any commit you want to run on the opengpu server needs to be by an authorized user (and the bot is not, intentionally).

So you either need to push some other pending change / clean-up, or simply an empty commit, which you can create using git commit --allow-empty -m "trigger CI"

[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/recipe.yaml) and found it was in an excellent condition.

[shermansiu]

@conda-forge-admin, please rerender

[shermansiu]

Depends on conda-forge/pytorch-cpu-feedstock#405

[shermansiu]

May actually depend on conda-forge/pytorch-cpu-feedstock#408 now

[h-vetinari]

May actually depend on conda-forge/pytorch-cpu-feedstock#408 now

It shouldn't require a 12.9 build of pytorch. Or what aspect of that PR do you think is necessary?

[shermansiu]

It shouldn't rely on it, but for some reason, the build seems to fail for the CUDA 12.6 build of PyTorch.

[shermansiu]

@conda-forge-admin, please rerender

[h-vetinari]

OK, so vllm has some quite horrible homespun logic for CUDA arch selection, which produces something that's IMO highly questionable:

CUDA target architectures: 5.0;5.2;6.0;6.1;7.0;7.5;8.0;8.6;8.9;9.0;10.0;10.1;10.3;12.0;12.1

We've had problems with sm_90, in some places; let's try with a reduced set for now and see if that builds. Apparently the only way to pass this in is through a very verbose "interface" like

CUDA_ARCH_FLAGS="-gencode arch=compute_70,code=sm_70;-gencode arch=compute_75,code=sm_75"

[shermansiu]

Thanks for adding the Python 3.13 skip back in!

[shermansiu]

If the Python 3.10 build works, I'll probably just skip the CI for the final commit for re-enabling everything and just merge it in to prevent the same jobs from being run in the PR and in the main branch. I'll just double-check that the required jobs are created.