Skip to content

Conversation

@conda-forge-admin
Copy link
Contributor

@conda-forge-admin conda-forge-admin commented May 21, 2025

Note that only builds triggered by maintainers of the feedstock (and core)
who have accepted the terms of service and privacy policy will run
on Github actions via Cirun.

Closes #150
Closes #151
Closes #152
Closes #158

automatic conda-forge administrator and others added 2 commits May 21, 2025 09:00
@conda-forge-admin
Copy link
Contributor Author

conda-forge-admin commented May 21, 2025

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 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/19783971603. Examine the logs at this URL for more detail.

@cbourjau cbourjau mentioned this pull request Jul 9, 2025
2 tasks
@cbourjau
Copy link
Contributor

cbourjau commented Jul 9, 2025

I'm a bit lost on how to move this forward or which documentation to follow. Do all maintainers have to accept the ToS? Is there an obvious next step to take here, @hmaarrfk?

@hmaarrfk hmaarrfk closed this Jul 9, 2025
@hmaarrfk hmaarrfk reopened this Jul 9, 2025
@cbourjau
Copy link
Contributor

cbourjau commented Aug 4, 2025

The 1.22.0 builds fail due to a hash-issue with some of the external dependencies pulled in by cmake. The issue is reportedly fixed in 1.22.1. I changed this PR to target that version and rerendered.

@cbourjau
Copy link
Contributor

The Cirun fails with "No runners configuration found after labels filtering" (see here). @h-vetinari stated here that all maintainers need to agree to the ToS by going through the motions described here. This is not the case, yet. May this be the issue? The following list tracks which maintainers have agreed:

It would be great if those missing could create the appropriate PRs so that we can finally get this over the finish line ❤️ .

Copy link
Member

@h-vetinari h-vetinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@h-vetinari stated here that all maintainers need to agree to the ToS by going through the motions described here.

Not all listed maintainers need to accept, but anyone who wants to trigger CI. Things ran fine here already, but you've misconfigured things, and jobs with unknown labels fail.

This must be fixed, because as it stands, you're wasting an enormous amount of resources by doing each job three times

@h-vetinari h-vetinari changed the title Update feedstock to use cirun-openstack-cpu-medium, cirun-openstack-cpu-large, cirun-openstack-cpu-xlarge with Cirun Update feedstock to use cirun Aug 31, 2025
h-vetinari and others added 6 commits August 31, 2025 15:55
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
…5.08.31.03.07.54

Other tools:
- conda-build 25.7.0
- rattler-build 0.46.0
- rattler-build-conda-compat 1.4.5
@cbourjau
Copy link
Contributor

@h-vetinari, do you see a way to unblock this PR? I'm a bit lost here...

@leofang
Copy link
Member

leofang commented Nov 4, 2025

It seems we are cross-compiling here? Any chance the wrong libcudadevrt is fed to the linker?

@h-vetinari
Copy link
Member

h-vetinari commented Nov 4, 2025

It seems we are cross-compiling here? Any chance the wrong libcudadevrt is fed to the linker?

Hey Leo, thanks for the quick response! We're cross-compiling aarch+CUDA in many places (including on this feedstock with CUDA 12.6), so I'd be surprised if a more or less standard setup (that we've been using for years) would suddenly stop working. We'd be seeing this in a lot more places.

@cbourjau
Copy link
Contributor

At least the xlarge runners are enough to get through the build without OOM'ing.

It seems like we might still be OOM'ing, does it not: https://github.com/conda-forge/onnxruntime-feedstock/actions/runs/19094250500/job/54550686105?pr=149#step:3:3757

@h-vetinari
Copy link
Member

Indeed. But d14dff9 was only experimental to see if it would change anything about

nvlink fatal   : elfLink linker library load error (target: sm_50)

(it didn't...) and the commit before that ran fine on linux-64. We can however try 2xlarge, just send a PR for using cirun-openstack-cpu-2xlarge to https://github.com/conda-forge/admin-requests using the template

…5.11.14.11.30.28

Other tools:
- conda-build 25.9.0
- rattler-build 0.49.0
- rattler-build-conda-compat 1.4.9
@cbourjau
Copy link
Contributor

Should we consider skipping cuda builds on linux-aarch64 for now?

@h-vetinari
Copy link
Member

Should we consider skipping cuda builds on linux-aarch64 for now?

Fine by me. I don't know what's wrong with

nvlink fatal   : elfLink linker library load error (target: sm_80)

I've tried dropping the older arches, but the same error remains even for stuff that's definitely still supported, and I don't know how to debug this

@hmaarrfk
Copy link
Contributor

after you drop things, ping @dslarm, he has been quite interested in maintain arm.

Perhaps he can help troubleshoot things.

@cbourjau
Copy link
Contributor

cbourjau commented Dec 1, 2025

I skipped the aarch64 cuda builds and the cuda+novec builds. On the other hand, I re-added the Windows-novec builds. I think this is finally ready to go 😍!

Copy link
Contributor

@cbourjau cbourjau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll merge by the end of today if there are no objections. Thanks to everybody involved already!

@hmaarrfk hmaarrfk changed the title Update feedstock to use cirun Update to 1.22.2 and CUDA 12.9 -- use cirun for compilation Dec 8, 2025
@hmaarrfk
Copy link
Contributor

hmaarrfk commented Dec 8, 2025

i updated the title a bit.

@cbourjau cbourjau merged commit 4cee211 into conda-forge:main Dec 8, 2025
98 of 100 checks passed
@cbourjau
Copy link
Contributor

cbourjau commented Dec 8, 2025

@dslarm I'm afraid we had to remove CUDA builds from linux-aarch64 to get this PR over the finish line. Are you interested in taking a look at this at some point?

This was referenced Dec 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants