Publish 3.11 to main

[h-vetinari]

MKL 2024.2 finally fixes the failures observed before on the blas feedstock, see conda-forge/blas-feedstock#114. That means we can now release the 3.11 netlib variant and then merge the PR on the blas feedstock.

[conda-forge-webservices]

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

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

For recipe:

• It looks like the 'libblas' output doesn't have any tests.
• It looks like the 'libtmglib' output doesn't have any tests.
• It looks like the 'libcblas' output doesn't have any tests.
• It looks like the 'liblapack' output doesn't have any tests.
• It looks like the 'liblapacke' output doesn't have any tests.
• It looks like the 'blas-devel' output doesn't have any tests.
• It looks like the 'lapack' output doesn't have any tests.
• This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

[conda-forge-webservices]

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

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

For recipe:

• It looks like the 'libblas' output doesn't have any tests.
• It looks like the 'libtmglib' output doesn't have any tests.
• It looks like the 'libcblas' output doesn't have any tests.
• It looks like the 'liblapack' output doesn't have any tests.
• It looks like the 'liblapacke' output doesn't have any tests.
• It looks like the 'blas-devel' output doesn't have any tests.
• It looks like the 'lapack' output doesn't have any tests.

[h-vetinari]

Ping @conda-forge/lapack

[h-vetinari]

Re-ping @conda-forge/lapack. I'm planning to merge this (and subsequently conda-forge/blas-feedstock#114) in 48h unless there are comments

[isuruf]

conda-forge/blas-feedstock#114 needs to be merged first.

[h-vetinari]

conda-forge/blas-feedstock#114 needs to be merged first.

I presume you prefer to merge the blas PR with non-main channel sources to avoid having a window where lapack builds get preferred, even if it's just a couple hours?

[isuruf]

Yes

[conda-forge-webservices]

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.

[h-vetinari]

Now that conda-forge/blas-feedstock#151 is in, we can publish these to the main channel as well. I'm resetting the build number because all previous builds have only been available in label/lapack_rc

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

[isuruf]

You can't have the same build number and hash in one channel even though they have different labels.

[h-vetinari]

You can't have the same build number and hash in one channel even though they have different labels.

Of course that's possible. The hashes are different

[h-vetinari]

You can see here

None of these hashes will be reproduced. Not just because those builds are from >1 year ago, but because the variant configs change (channel_targets: at the very least), and so the package hash will always be different.

[isuruf]

There are outputs here without a hash in the build string.

[h-vetinari]

Compare the package hash ingredients

  "libblas-3.11.0-0_hc00574d_netlib.conda": {
    "recipe": {
      "__glibc": "__glibc >=2.17,<3.0.a0",
      "c_compiler": "gcc",
      "c_compiler_version": "14",
      "c_stdlib": "sysroot",
      "c_stdlib_version": "2.17",
      "channel_targets": "conda-forge main",    # <---
      "fortran_compiler": "gfortran",
      "fortran_compiler_version": "14",
      "libblas": "3.9.* *netlib",
      "target_platform": "linux-64"
    }
  }

[isuruf]

You picked one with a hash though.
Check the following

  "blas-2.300-netlib.conda": {
    "recipe": {
      "channel_targets": "conda-forge main",
      "libblas": "3.9.* *netlib",
      "libcblas": "3.9.* *netlib",
      "liblapack": "3.9.* *netlib",
      "liblapacke": "3.9.* *netlib",
      "target_platform": "linux-64"
    }
  },
  "blas-devel-3.11.0-0_netlib.conda": {
    "recipe": {
      "channel_targets": "conda-forge main",
      "target_platform": "linux-64"
    }
  },
  "lapack-3.11.0-netlib.conda": {
    "recipe": {
      "channel_targets": "conda-forge main",
      "target_platform": "linux-64"
    }
  }

[h-vetinari]

There are outputs here without a hash in the build string.

There's one (blas), and it has exactly one build that would coincide (2.305 from #88). But OK, that's a constraint 😑

[h-vetinari]

You picked one with a hash though.

Our messages had crossed paths; my browser hadn't refreshed to show your "There are outputs here without a hash in the build string." when I was typing the other comment.

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!