2.9.0 osx testing

[mgorny]

Splitting to run it independently of the Linux/Windows builds.

[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, 'self_hosted': True, 'store_build_artifacts': True, 'timeout_minutes': 1200, 'triggers': ['push', 'pull_request']}.

  {'resize_win_partitions': True, 'self_hosted': True, 'store_build_artifacts': True, 'timeout_minutes': 1200, '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 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/19195452456. Examine the logs at this URL for more detail.}

[mgorny]

@h-vetinari, disabling FBGEMM didn't seem to change much. I've now also disabled MKLDNN but TBH I don't think this is the right way forward.

Hopefully conda-forge/.cirun#118 + conda-forge/.cirun#119 will let us switch runners.

[mgorny]

Now, are the runners busy or is there still something wrong with the labels?

[mgorny]

(already fixed wrong bugno in the commit message locally)

[h-vetinari]

Now, are the runners busy or is there still something wrong with the labels?

Given that this our first foray into the osx runners, I'm assuming something's not yet configured right. CC @aktech

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

[mgorny]

Okay, that's something new. Either insufficient permissions on the runner, or a bad action script?

[aktech]

Either insufficient permissions on the runner, or a bad action script?

Most likely "insufficient permissions", I'll update the macos image.

[mgorny]

@h-vetinari, on a semi-related manner, I suppose we want to start doing "megabuilds" here as well after the switch, right?

[h-vetinari]

Yeah, would be great to use megabuilds for osx too! :)

[aktech]

Most likely "insufficient permissions", I'll update the macos image.

I built another image and also took another look at the error above. The error is valid, you can't create directories there without sudo, the runnerx user already has the passwordless sudo permissions.

This behaviour is in-compliant with the github runner images (macos-latest) as well:

also FYI: I am updating images irrespective with latest xcode (orthogonal to issues in this PR)

[mgorny]

I'm going to try something cursed here, to at least confirm if lack of sudo is the only problem.

[aktech]

FYI: I am in the process of upgrading macos runners server to a more powerful one, which means the runners will not spin up for today, migration should be complete tomorrow.

[mgorny]

Okay, thanks for telling me before I started frantically trying to figure out why they aren't starting again xP.

[aktech]

@mgorny @h-vetinari The OSX CI is running now, with the new image. (Also fyi reminder: max concurrency is 2, due to Apple's Virtualisation limit on a single machine)

[h-vetinari]

That's amazing, thanks so much @aktech! The OSX CI didn't only run, it produced the builds and tests passed (except on osx-arm64 where we shouldn't run the tests obviously; possibly test: native_and_emulated isn't correctly skipping the tests for osx builds outside of azure yet). 🥳

I'm surprised though, I had thought that the scaleway machines are osx-arm64 already; clearly they're osx-64... I must have gotten this wrong somewhere, sorry.

In any case, this should unblock us ~completely. @mgorny, I suggest we don't touch the current setup to get 2.9 out the door, and take care of switching to megabuilds on osx afterwards.

[h-vetinari]

I'm surprised though, I had thought that the scaleway machines are osx-arm64 already; clearly they're osx-64... I must have gotten this wrong somewhere, sorry.

Nevermind, I just need to look at the config in this PR:

build_platform:
  osx_64: osx_arm64
provider:
  osx_arm64: github_actions

OTOH, that means that our (now native) osx-arm64 builds aren't passing the tests 😑

[h-vetinari]

OK, with the fixes from #448, the test suite is looking pretty good, except the following two failures:

=================================== FAILURES ===================================
______________ TestModuleMPS.test_forward_nn_Bilinear_mps_float16 ______________
[gw0] darwin -- Python 3.10.19 $PREFIX/bin/python3.10
Unexpected success
____________________________ TestTorch.test_qengine ____________________________
[gw0] darwin -- Python 3.10.19 $PREFIX/bin/python3.10
self = <test_torch.TestTorch testMethod=test_qengine>
    @xfailIfS390X
    def test_qengine(self):
        qengines = torch.backends.quantized.supported_engines
        original_qe = torch.backends.quantized.engine
        for qe in qengines:
            torch.backends.quantized.engine = qe
            assert torch.backends.quantized.engine == qe, 'qengine not set successfully'
>       torch.backends.quantized.engine = original_qe
test/test_torch.py:9488: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
self = <torch.backends.quantized._QEngineProp object at 0x11b3688b0>
obj = <module 'torch.backends.quantized' from '/Users/runnerx/miniforge3/conda-bld/libtorch_1763869149195/_test_env_placehol...cehold_placehold_placehold_placehold_placehold_plac/lib/python3.10/site-packages/torch/backends/quantized/__init__.py'>
val = 'none'
    def __set__(self, obj, val: str) -> None:
>       torch._C._set_qengine(_get_qengine_id(val))
E       RuntimeError: quantized engine NoQEngine is not supported
E       
E       To execute this test, run the following from the base repo dir:
E           python test/test_torch.py TestTorch.test_qengine
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_placehold_plac/lib/python3.10/site-packages/torch/backends/quantized/__init__.py:37: RuntimeError

The "unexpected success" is from a highly templated test and AFAICT the failure expectation comes from here.

I'll see if skipping does the job