v2.11.0 WIP

[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.

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

[h-vetinari]

FYI, the fact that the job didn't start had nothing to do with the new vs. old actions/checkout commit, it's just that the interaction with the server is pretty fragile at the moment, and often jobs don't start correctly; the only option is to cancel and restart.

[mgorny]

Yeah, I know. It just happened that conda update downgraded smithy.

[h-vetinari]

Yeah, I know. It just happened that conda update downgraded smithy.

interesting. Any idea what forced the downgrade? You should then re-update smithy (and the rerender will generally error if you're on an old version; I assume you must have added --no-check-uptodate?). And for going back to the full matrix, you'll need a development version of smithy from the upstream main branch due to the windows path lengths stuff (unless we get a new smithy release until then).

As another aside, it'd be good to try to revert cd7d159 & fbe7265 if possible.

[mgorny]

Apparently that's the answer:

The following packages will be UPDATED:

  conda-recipe-mana~                     0.5.0-pyhd8ed1ab_0 --> 0.10.0-pyhd8ed1ab_0 
  conda-smithy                     3.54.1-unix_pyh9ac5cc3_0 --> 3.55.1-unix_pyh9ac5cc3_0 

The following packages will be DOWNGRADED:

  click                                  8.3.1-pyh8f84b5b_1 --> 8.2.1-pyh707e725_0 

[h-vetinari]

Thanks; yeah, click has a pretty horrible versioning strategy which often leads to caps being introduced after some breakage occurs. The solver doesn't like to backtrack (for any package), but which one it chooses when it comes down to it is pretty random. Can't do much except look out for such cases (or aggressively add repodata patches after the fact, which we generally avoid though unless really necessary)

[h-vetinari]

As another aside, it'd be good to try to revert cd7d159 & fbe7265 if possible.

Realistically, the former depends on pytorch/pytorch#175115 being fixed & backported, though the latter should be fine after conda-forge/conda-forge-repodata-patches-feedstock#1163.

[mgorny]

Uh, many test failures. Some really weird:

________ TestTorchDeviceTypeCUDA.test_deterministic_empty_cuda_bfloat16 ________
[gw0] linux -- Python 3.14.3 $PREFIX/bin/python3.14

self = <test_torch.TestTorchDeviceTypeCUDA testMethod=test_deterministic_empty_cuda_bfloat16>
device = 'cuda:0', dtype = torch.bfloat16

    @skipXLA
    @skipIfTorchInductor("https://github.com/pytorch/pytorch/issues/113707")
    @dtypes(*all_types_and_complex_and(
        torch.half, torch.bool, torch.bfloat16, torch.uint16, torch.uint32, torch.uint64, torch.complex32))
    def test_deterministic_empty(self, device, dtype):
        gen_fns = [
            lambda: torch.empty(10, 9, device=device, dtype=dtype),
            lambda: torch.empty(10, 9, out=torch.zeros(1, device=device, dtype=dtype)),
            lambda: torch.empty_like(torch.zeros(10, 9, device=device, dtype=dtype)),
            lambda: torch.empty_like(torch.zeros(10, 9, device=device, dtype=dtype), memory_format=torch.contiguous_format),
            lambda: torch.empty_strided((10, 9), (1, 5), device=device, dtype=dtype),
            lambda: torch.empty_permuted((2, 3, 5), (1, 0, 2), device=device, dtype=dtype),
        ]
    
        for gen_fn in gen_fns:
            with DeterministicGuard(True, fill_uninitialized_memory=True):
>               res = gen_fn()
                      ^^^^^^^^

test/test_torch.py:1323: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
test/test_torch.py:1314: in <lambda>
    lambda: torch.empty(10, 9, out=torch.zeros(1, device=device, dtype=dtype)),
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <torch.utils._device.DeviceContext object at 0x7cddf1ff36b0>
func = <built-in method empty of type object at 0x7cdf4372abe0>, types = ()
args = (10, 9)
kwargs = {'device': device(type='cpu'), 'out': tensor([0.], device='cuda:0', dtype=torch.bfloat16)}

    def __torch_function__(self, func, types, args=(), kwargs=None):
        kwargs = kwargs or {}
        if func in _device_constructors() and kwargs.get("device") is None:
            kwargs["device"] = self.device
>       return func(*args, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^
E       RuntimeError: device type cpu does not match device type of out parameter (cuda)
E       
E       To execute this test, run the following from the base repo dir:
E           python test/test_torch.py TestTorchDeviceTypeCUDA.test_deterministic_empty_cuda_bfloat16
E       
E       This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0

../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/lib/python3.14/site-packages/torch/utils/_device.py:116: RuntimeError

[h-vetinari]

      if func in _device_constructors() and kwargs.get("device") is None:
          kwargs["device"] = self.device

It looks to me like this condition is going wrong somehow, probably in _device_constructors(). This looks to be a bug in the test suite setup itself (under some conditions we're hitting), causing a mismatch between the device being passed by the test (cuda:0) and the device where actual execution is attempted (cpu).

Sidenote: another commit to try reverting: fdc4c03, and this needs to be updated to 3.14

pytorch-cpu-feedstock/recipe/meta.yaml

Lines 547 to 551 in cdeaf5a

	# regression test for https://github.com/conda-forge/pytorch-cpu-feedstock/issues/329, where we picked up
	# duplicate `.pyc` files due to newest py-ver (3.13) in the build environment not matching the one in host;
	# obviously this test can only be done for other python versions.
	- test ! -f $SP_DIR/functorch/__pycache__/__init__.cpython-313.pyc # [py!=313 and unix]
	- if exist %SP_DIR%\functorch\__pycache__\__init__.cpython-313.pyc exit 1 # [py!=313 and win]

[mgorny]

Okay, let's try another CPU run with the changes you've suggested.

[jaimergp]

@mgorny, FYI, the GPU server will be disconnected in ~90mins so you may observe a cancelled job if it doesn't finish by then. More info at conda-forge/.cirun#174

[conda-forge-admin]

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:

• ❌ In conda-forge.yml: $.github_actions = {'resize_win_partitions': True, 'store_build_artifacts': True, 'timeout_minutes': 1440, 'triggers': ['push', 'pull_request']}.

  {'resize_win_partitions': True, 'store_build_artifacts': True, 'timeout_minutes': 1440, 'triggers': ['push', 'pull_request']} is not valid under any of the given schemas

  Schema

  {
    "anyOf": [
      {
        "$ref": "#/$defs/GithubActionsConfig"
      },
      {
        "type": "null"
      }
    ]
  }

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

[mgorny]

@conda-forge/pytorch-cpu, I'm stuck with these Windows linking errors. Any idea?

[8](https://github.com/conda-forge/pytorch-cpu-feedstock/actions/runs/24847677323/job/72739209654?pr=490#step:6:54421)
[2/2] Linking CXX executable cmake_test.exe
FAILED: [code=4294967295] cmake_test.exe 
C:\Windows\system32\cmd.exe /C "cd . && %PREFIX%\Library\bin\cmake.exe -E vs_link_exe --msvc-ver=1944 --intdir=CMakeFiles\cmake_test.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx64\x64\link.exe /nologo CMakeFiles\cmake_test.dir\main.cpp.obj  /out:cmake_test.exe /implib:cmake_test.lib /pdb:cmake_test.pdb /version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:console -LIBPATH:\lib   -LIBPATH:\lib\intel64   -LIBPATH:\lib\intel64_win   -LIBPATH:\lib\win-x64 %PREFIX%\Library\lib\c10.lib  %PREFIX%\Library\lib\caffe2_nvrtc.lib  %PREFIX%\Library\lib\c10_cuda.lib  %PREFIX%\libs\python313.lib  %PREFIX%\Lib\site-packages\torch\lib\torch_python.lib  %PREFIX%\Library\lib\torch.lib  %PREFIX%\Library\lib\torch_cuda.lib  %PREFIX%\Library\lib\torch_cpu.lib  %PREFIX%\Library\lib\libprotobuf.lib  %PREFIX%\Library\lib\utf8_validity.lib  %PREFIX%\Library\lib\abseil_dll.lib  -ignore:4221  -INCLUDE:?warp_size@cuda@at@@YAHXZ  %PREFIX%\Library\lib\c10_cuda.lib  %PREFIX%\Library\lib\c10.lib  %PREFIX%\Library\lib\cudart.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK: command "C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx64\x64\link.exe /nologo CMakeFiles\cmake_test.dir\main.cpp.obj /out:cmake_test.exe /implib:cmake_test.lib /pdb:cmake_test.pdb /version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:console -LIBPATH:\lib -LIBPATH:\lib\intel64 -LIBPATH:\lib\intel64_win -LIBPATH:\lib\win-x64 %PREFIX%\Library\lib\c10.lib %PREFIX%\Library\lib\caffe2_nvrtc.lib %PREFIX%\Library\lib\c10_cuda.lib %PREFIX%\libs\python313.lib %PREFIX%\Lib\site-packages\torch\lib\torch_python.lib %PREFIX%\Library\lib\torch.lib %PREFIX%\Library\lib\torch_cuda.lib %PREFIX%\Library\lib\torch_cpu.lib %PREFIX%\Library\lib\libprotobuf.lib %PREFIX%\Library\lib\utf8_validity.lib %PREFIX%\Library\lib\abseil_dll.lib -ignore:4221 -INCLUDE:?warp_size@cuda@at@@YAHXZ %PREFIX%\Library\lib\c10_cuda.lib %PREFIX%\Library\lib\c10.lib %PREFIX%\Library\lib\cudart.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST:EMBED,ID=1" failed (exit code 1120) with the following output:
   Creating library cmake_test.lib and object cmake_test.exp

main.cpp.obj : error LNK2019: unresolved external symbol "class std::optional<struct c10::InferredType> __cdecl torch::jit::detail::_tryToInferTypeImpl(class pybind11::handle)" (?_tryToInferTypeImpl@detail@jit@torch@@YA?AV?$optional@UInferredType@c10@@@std@@Vhandle@pybind11@@@Z) referenced in function "struct c10::InferredType __cdecl torch::jit::tryToInferType(class pybind11::handle)" (?tryToInferType@jit@torch@@YA?AUInferredType@c10@@Vhandle@pybind11@@@Z)

cmake_test.exe : fatal error LNK1120: 1 unresolved externals

My first thought was maybe pybind11 version, but FWICS v2.11.0 upstream still used 3.0.1 (and we pin that version here).

[isuruf]

Probably because https://github.com/pytorch/pytorch/blob/3e62cf764d544b7b0db35290574becd64833eef1/torch/csrc/jit/python/pybind_utils.h#L375 is not exported with TORCH_PYTHON_API

[mgorny]

Indeed. Now we just have a bunch of CustomDecompTable test failures.

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

[mgorny]

aarch64:

onednn_verbose,v1,primitive,create:dispatch,convolution,cpu,convolution,ref:any,forward_training,src:f16:a:any:any::f0 wei:f16:a:any:any::f0 bia:f16:a:any:any::f0 dst:f16:a:any:any::f0,attr-scratchpad:user,alg:convolution_direct,mb2_ic4oc5_id3od5kd3sd1dd0pd2_ih4oh6kh3sh1dh0ph2_iw5ow7kw3sw1dw0pw2,unsupported datatype,src/cpu/ref_convolution.hpp:51
onednn_verbose,v1,primitive,create:dispatch,deconvolution,brgemm implementation not found for strided convolution,src/cpu/aarch64/jit_brgemm_deconv.cpp:160
onednn_verbose,v1,primitive,create:dispatch,convolution,cpu,convolution,ref:any,forward_training,src:f16:a:any:any::f0 wei:f16:a:any:any::f0 bia:f16:a:any:any::f0 dst:f16:a:any:any::f0,attr-scratchpad:user,alg:convolution_direct,mb2_ic4oc5_id3od5kd3sd1dd0pd2_ih4oh6kh3sh1dh0ph2_iw5ow7kw3sw1dw0pw2,unsupported datatype,src/cpu/ref_convolution.hpp:51
onednn_verbose,v1,primitive,create:dispatch,deconvolution,brgemm implementation not found for strided convolution,src/cpu/aarch64/jit_brgemm_deconv.cpp:160
onednn_verbose,v1,primitive,create:dispatch,convolution,cpu,convolution,ref:any,backward_data,src:f16:a:any:any::f0 wei:f16:a:any:any::f0 bia:f16:a:any:any::f0 dst:f16:a:any:any::f0,,alg:convolution_direct,mb2_ic5oc4_id5od3kd3sd1dd0pd0_ih6oh4kh3sh1dh0ph0_iw7ow5kw3sw1dw0pw0,unsupported datatype,src/cpu/ref_convolution.hpp:137
onednn_verbose,v1,primitive,create:dispatch,convolution,cpu,convolution,ref:any,backward_data,src:f32:a:any:any::f0 wei:f16:a:any:any::f0 bia:undef::undef::: dst:f16:a:any:any::f0,,alg:convolution_direct,mb2_ic5oc4_id5od3kd3sd1dd0pd0_ih6oh4kh3sh1dh0ph0_iw7ow5kw3sw1dw0pw0,unsupported datatype,src/cpu/ref_convolution.hpp:139

So I guess onednn limitation?