3.12.1

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

Based on #151.

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

• ❌ You're setting a constraint on the __osx virtual package directly; this should now be done by adding a build dependence on {{ stdlib("c") }}, and overriding c_stdlib_version in recipe/conda_build_config.yaml for the respective platform as necessary. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

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

[h-vetinari]

Please increment blas_minor for 3.12 by 100

[mgorny]

Done locally. I'm working on BLIS bump first, then I'll push to see if that improved anything.

[h-vetinari]

Done locally. I'm working on BLIS bump first, then I'll push to see if that improved anything.

Could you rebase this PR on main, even without the blis stuff?

[mgorny]

Done.

[h-vetinari]

Not looking too good for 3.12 for now; we'll definitely need a blis update, but also MKL does not look compatible yet (missing symbols and thus failed tests)

[h-vetinari]

For expectation management, I had been trying to update our lapack stack past 3.9.0 since almost 5 years ago, so don't be surprised if this takes a while. Before running into the MKL SDL failures, the longest wait was for MKL to become compatible at all -- I recommend asking for an update in conda-forge/intel_repack-feedstock#26

[mgorny]

Am I also seeing correctly that Accelerate is quite incompatible too? I guess that's going to be a hard blocker, unless we want to proceed with the alternate approach of per-platform LAPACK versions.

[h-vetinari]

newaccelerate should be compatible with 3.12 (as of macOS 15.5, c.f #158), but it's possible that that's only for 3.12.0 and not 3.12.1

[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.
• ℹ️ libcblas output overrides versions pinned in the feedstock:
  ['- In section host: libblas 3.12.1 0*_openblas']
  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.
• ℹ️ blas-devel output overrides versions pinned in the feedstock:
  ['- In section host: openblas 0.3.33']
  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/26493188258. Examine the logs at this URL for more detail.}

[mgorny]

Ok, I think the problem with BLIS is that liblapack.so from Netlib is now LP64+ILP64 library, and therefore requires LP64+ILP64 libblas.so. I think this will be causing cross-package compatibility issues in general, so we need to rebuild it without the ext API.

[mgorny]

@h-vetinari, looks like it's pulling liblapack-3.12.1-5_h276a3f0_netlib even though it seems to be marked broken. Any clue what's wrong here? Should we rebuild with lapack-feedstock with build number 6 to work around this?

[h-vetinari]

looks like it's pulling liblapack-3.12.1-5_h276a3f0_netlib even though it seems to be marked broken. Any clue what's wrong here?

I can only guess that something is going wrong with the fact that those builds were marked broken on a non-main label; I've removed the lapack_rc label now (so now the builds are just under broken), which should keep them from being pulled in. Perhaps give it a bit of time for the channel to be re-indexed.

[mgorny]

Hmm, still something suspicious:

/home/conda/feedstock_root/build_artifacts/blas-split_1764948318319/work/build/bin/xexample_DGESV_rowmajor: symbol lookup error: /home/conda/feedstock_root/build_artifacts/blas-split_1764948318319/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/liblapacke.so.3: undefined symbol: zggev3_64_

[mgorny]

@h-vetinari, could you also remove the label from liblapacke?

[h-vetinari]

@h-vetinari, could you also remove the label from liblapacke?

now removed from all the associated outputs of that build. Not sure why that didn't occur to me yesterday, sorry

[mgorny]

Ok, BLIS looks good now.

What remains:

• missing cgemmtr_ in mkl
• missing cgemmtr_ in (old) accelerate
• Windows/OpenBLAS:

  ** On entry to CGEMM  parameter number  1 had an illegal value
  […]
  fatal Fortran runtime error(D:\bld\blas-split_1765005415426\work\BLAS\TESTING\zblat3.f:3973): Data edit descriptor 'I' may not be used with a REAL data item
  

[h-vetinari]

Looks like cgemmtr_ is now present in MKL 2026 / openblas 0.3.33, but we still have

96% tests passed, 4 tests failed out of 96

Total Test time (real) =  50.83 sec

The following tests FAILED:
	 84 - BLAS-xblat3s (Failed)
	 87 - BLAS-xblat3d (Failed)
	 89 - BLAS-xblat3c (Failed)
	 92 - BLAS-xblat3z (Failed)

			-->   LAPACK TESTING SUMMARY  <--
		Processing LAPACK Testing output found in the TESTING directory
SUMMARY             	nb test run 	numerical error   	other error  
================   	===========	=================	================  
REAL             	271576		1	(0.000%)	1450	(0.534%)	
DOUBLE PRECISION	279072		3	(0.001%)	1461	(0.524%)	
COMPLEX          	44121		0	(0.000%)	857	(1.942%)	
COMPLEX16         	260190		2	(0.001%)	1378	(0.530%)	

--> ALL PRECISIONS	854959		6	(0.001%)	5146	(0.602%)

on win+MKL, resp

98% tests passed, 2 tests failed out of 111

Total Test time (real) = 179.75 sec

The following tests FAILED:
	104 - BLAS-xblat3c (Failed)
	107 - BLAS-xblat3z (Failed)

for win+openblas; the old accelerate will not be recoverable, but that's fine and can IMO be dropped.