26.09 Release by conda-forge-admin · Pull Request #111 · conda-forge/cuquantum-feedstock

conda-forge-admin · 2026-09-28T17:43:12Z

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

I've started rerendering the recipe as instructed in #110.

If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!

Here's a checklist to do before merging.

Bump the build number if needed

Fixes #110

conda-forge-admin · 2026-09-28T17:45:02Z

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

❌ pin_compatible should be used instead of pin_subpackage for cudensitymat mpi_mpi_* because it is not a known outputs of this recipe: ['cuquantum', 'cudensitymat', 'cupauliprop', 'custabilizer', 'cutensornet', 'custatevec', 'cuquantum-python', 'cuquantum-sdk'].
❌ pin_compatible should be used instead of pin_subpackage for cutensornet mpi_mpi_* because it is not a known outputs of this recipe: ['cuquantum', 'cudensitymat', 'cupauliprop', 'custabilizer', 'cutensornet', 'custatevec', 'cuquantum-python', 'cuquantum-sdk'].

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.
ℹ️ cudensitymat output overrides versions pinned in the feedstock:
['- In section host: cutensor >=2.3.1,<3']
Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.
ℹ️ cutensornet output overrides versions pinned in the feedstock:
['- In section host: cutensor >=2.3.1,<3']
Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.
ℹ️ 'Free Disk Space' is deprecated.
Deprecated. Use workflow_settings.free_disk_space instead.
This setting accepts a boolean or a list containing apt, cache,
and docker. When set to true, only apt and cache are cleaned
up. Set it to the full list to clean up all components.

The replacement setting uses the values skip, quick, and max
instead; the values accepted by this deprecated setting are not valid
for the replacement setting.

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

conda-forge-admin · 2026-09-28T17:45:26Z

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

I tried to rerender for you but ran into some issues. Please check the output logs of the GitHub Actions workflow below for more details. You can also ping conda-forge/core (using the @ notation) for further assistance or, if there was a rerendering error, you can try rerendering locally.

The following suggestions might help debug any issues:

Is the recipe/{meta.yaml,recipe.yaml} file valid?
If there is a recipe/conda-build-config.yaml file in the feedstock make sure that it is compatible with the current global pinnings.
Is the fork used for this PR on an organization or user GitHub account? Automated rerendering via the webservices admin bot only works for user GitHub accounts.

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

b-kloss · 2026-10-05T16:45:47Z

@mtjrider I assume this is what the lint refers to?

Most likely, yes. Not sure why it's expanding this way.

conda-smithy v2026.9.1 (#2659) now treats everything after a rendered pin_subpackage() as the package name, so the MPI-variant run_exports "{{ pin_subpackage(...) }} {{ mpi_prefix }}_*" lint as "cudensitymat mpi_mpi_*" / "cutensornet mpi_mpi_*" and fail to match any output. Spell the same pins out literally so the rendered result is unchanged (e.g. "cudensitymat >=0.7.0,<1.0a0 mpi_openmpi_*"). Also move the deprecated azure.free_disk_space setting to workflow_settings.free_disk_space: quick, which is the value conda-smithy already translates it to. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

conda-forge-admin · 2026-10-05T17:32:01Z

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.
ℹ️ cudensitymat output overrides versions pinned in the feedstock:
['- In section host: cutensor >=2.8,<3']
Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.
ℹ️ cutensornet output overrides versions pinned in the feedstock:
['- In section host: cutensor >=2.8,<3']
Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.

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

… deps cupauliprop now follows the cudensitymat pattern for MPI builds: - build strings carry the mpi prefix (mpi_openmpi_*, and nompi_* with the +100 build number) and run_exports pin the matching variant - MPI builds compile the shipped MPI and NCCL distributed interface plugins, install cupp-activate/deactivate scripts that export CUPAULIPROP_COMM_LIB (plus the *_MPI_/*_NCCL_COMM_LIB conveniences), and depend on openmpi and nccl; nompi builds conflict with openmpi - cupp-tests compiles the multiprocess sample single-process, with the MPI provider, and with the MPI+NCCL providers, and asserts both plugins exist cutensornet MPI builds gain the runtime dependencies required by the new distributed tensor decomposition path exercised by samples/cutensornet/approxTN/decompose_example_mpi_nccl.cu. The sample links only cutensornet and MPI; libcutensornet dlopens NCCL, cuSOLVERMp and cuTENSORMp lazily, so nccl is added to host/run and libcusolvermp0 to run (cuTENSORMp already ships with cutensor >=2.8). cutn-tests now compiles every MPI sample, fails if libmpi.so is missing in an MPI build, and checks that the three lazily loaded libraries are installed. Verified with full local conda-build runs, tests included, of the linux_aarch64 CUDA 13 openmpi and nompi variants. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

b-kloss · 2026-10-05T17:31:18Z

-        - {{ pin_subpackage("cudensitymat", max_pin="x") }} {{ mpi_prefix }}_*
+        # Equivalent to pin_subpackage("cudensitymat", max_pin="x") plus the MPI build
+        # string. Spelled out literally because conda-smithy (since #2659) treats
+        # everything after pin_subpackage(...) as part of the package name and
+        # then fails to match it against the recipe outputs.
+        - cudensitymat >={{ cudm_version }},<{{ cudm_major + 1 }}.0a0 {{ mpi_prefix }}_*


cudm pin was wrong already here, should have been minor.

Or maybe this was intentional?

What do you mean?

Do we intend to pin major version 0 libs to major version?

b-kloss · 2026-10-06T02:05:17Z

+    # distributed examples only link MPI on top of the regular libraries; this includes
+    # approxTN/decompose_example_mpi_nccl.cu, which does not link NCCL itself because
+    # libcutensornet dlopens NCCL and cuSOLVERMp lazily at runtime
+    if [[ "${mpi}" != "nompi" ]] ; then
+      declare example ; for example in "${examples[@]}" ; do
+        if [[ "${example}" == *"mpi"* ]] ; then
+          echo "${example}"
+          compile_command=(
+            "${NVCC:-"nvcc"}" "${NVCC_FLAGS:-"--verbose"}" "--std=c++17"
+            "-I${PREFIX}/include" "-L${PREFIX}/lib"
+            "-lcutensornet" "-lcutensor" "-lcublas" "${LINK_MPI}"
+            "${example}" "-o" "${example}.out"
+          )
+          echo "${compile_command[@]}"
+          "${compile_command[@]}"
+        fi
+      done
+    fi


Did we not have coverage for the cuTN mpi examples before?

b-kloss · 2026-10-06T02:06:07Z

        - mpi 1.0.* {{ mpi }}  # [mpi != "nompi"]
        - {{ mpi }}  # [mpi != "nompi"]
+        # Distributed tensor decomposition (samples/cutensornet/approxTN/decompose_example_mpi_nccl.cu)
+        # makes libcutensornet dlopen NCCL (>=2.29,<3), cuSOLVERMp (>=0.9.1,<0.10) and cuTENSORMp at


Shoudl we bound nccl version?

I don't think so ... not unless there's a compelling reason to restrict the NCCL version.

Sorry I didn't phrase this right. We should bound nccl version. It's the documented bound and I am pretty sure it is validated at runtime.

This is creating an awkward situation where we'd need to pin cuTensor tightly for this functionality. We can also skip that and introduce the pins once the API matures out of experimental stage.

Ah, I missed this. Thanks for catching. I'll update accordingly.

The latter is probably the better solution, so may be we just lower bound NCCL here? No cuTensor pin?

I agree. We should only introduce pins as they become relevant.

Well, there's no good clean solution here. There's experimental functionality with the above pins. The clean solutions (without further output splitting) are: Do not introduce any dependencies from the experimental functionality or pin according to the pins of the experimental functionality. The compromise is to do a mix:

lower bound NCCL (not very offensive)

pin cuSolverMp (more problematic, but pin will be raised to next minor with next release)

don't upper bound cuTensor and rely on user imposing the correct pin if required

b-kloss · 2026-10-07T16:20:17Z

@majones Please double check the lower bounds are aligned with documented lower bounds, I think the cuTensor >=2.8<3 bound has not been propagated?

cuquantum-python - nvmath-python >=1.0.0,<2.0.0 (was ==0.7.0) and cuda-pathfinder >=1.6.0,<2, matching install_requires in python/setup.py of v26.09.0 - cuda-bindings pinned to the two upstream windows (>=12.9.4,<13.0a0 | >=13.0.3,<14.0a0) - drop the no-op ignore_run_exports_from entries for cuda-bindings/cuda-python MPI variants (cudensitymat, cupauliprop, cutensornet) - nccl >=2.29,<3.0a0 in run, with NCCL's own run_exports ignored so the documented window applies instead of the build-time floor - cuda-cudart-dev in host and cuda-cudart in run for cudensitymat and cupauliprop, whose NCCL distributed interfaces are linked with -lcudart (conda-build previously reported libcudart.so.1x as unresolved) - cutensornet MPI pins cutensor to the 2.8 minor line that distributed tensor decomposition requires at runtime Libraries - host floor cutensor >=2.8 (cuTensorNet 2.14 requires cuTENSOR 2.8.0+) - cudensitymat lists libcusparse directly instead of via libcusolver - custatevec drops the unused cuda-nvml-dev dependency and now installs custatevecEx.h and custatevecEx_ext.h Packaging - unpack the GitHub tree into its own source folder so its BSD-3-Clause LICENSE no longer overwrites the SDK EULA shipped by the library outputs Tests - cuquantum-python imports every binding module (including custatevecEx, cupauliprop and custabilizer) and checks every CLI target - cudensitymat distributed samples compile with MPI_ENABLED/NCCL_ENABLED like the upstream Makefile, instead of the fallback stub - MPI builds fail if libmpi or libnccl is missing from the test env Verified with local conda-build of the linux-aarch64 CUDA 12.9 openmpi and nompi variants: all outputs built, all tests passed, and the resulting packages carry the intended dependencies, headers and license texts. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mtjrider · 2026-10-07T20:13:35Z

@b-kloss please review the latest batch of changes. I identified and resolved several gaps from the previous build.

dummy commit for rerendering

a175cb2

conda-forge-webservices Bot mentioned this pull request Sep 28, 2026

@conda-forge-admin, please rerender #110

Closed

mtjrider changed the title ~~chore: rerender~~ 26.09 Release Sep 28, 2026

updating versions and checksums

83ba412

b-kloss reviewed Oct 5, 2026

View reviewed changes

b-kloss reviewed Oct 6, 2026

View reviewed changes

b-kloss approved these changes Oct 8, 2026

View reviewed changes

mtjrider marked this pull request as ready for review October 8, 2026 17:08

mtjrider requested review from DmitryLyakh, JeremyWangNVDA, leofang and yangcal as code owners October 8, 2026 17:08

mtjrider merged commit e5526f9 into conda-forge:main Oct 8, 2026
11 checks passed

Conversation

conda-forge-admin commented Sep 28, 2026

Uh oh!

conda-forge-admin commented Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

conda-forge-admin commented Sep 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

conda-forge-admin commented Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b-kloss commented Oct 7, 2026

Uh oh!

mtjrider commented Oct 7, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

conda-forge-admin commented Sep 28, 2026 •

edited

Loading

conda-forge-admin commented Oct 5, 2026 •

edited

Loading