Fix osx-arm64 conda build: drop redundant openblas pin, allow single-platform release dispatch (#5652)

[alibeklfc]

Summary:
The OSX arm64 packages job failed in the v1.15.1 release run (35131196327), so faiss-cpu 1.15.1 is on the pytorch channel for linux-64, linux-aarch64 and win-64 but not osx-arm64. PyPI is unaffected.

Root cause

Upstream conda-forge inconsistency, not a faiss regression. On 2026-09-10 conda-forge published two new libopenblas 0.3.34 builds for osx-arm64 without matching openblas 0.3.34 metapackages:

openblas 0.3.34 accepts	libopenblas 0.3.34 available
openmp_he657e61_0	openmp_he657e61_0 (07-17)
pthreads_hddb8425_0	pthreads_hddb8425_0 (07-17)
pthreads_h60d1960_1	pthreads_h60d1960_1 (08-30)
openmp_h4f80526_1	openmp_h4f80526_1 (08-30)
—	pthreads_hb42d564_1 (09-10) ← no openblas
—	openmp_h5e6e99c_1 (09-10) ← no openblas

libfaiss built fine against openmp_h4f80526_1. The failure came when solving the faiss-cpu env: the unpinned libopenblas =0.3.34 resolves to the newest build openmp_h5e6e99c_1, which no openblas 0.3.34 accepts:

package libfaiss-1.15.1-py3.12_hcb8d3e5_0_cpu requires openblas 0.3.34.*,
but none of the providers can be installed

The recipe is vulnerable because the libfaiss output pins both openblas and libopenblas on osx-arm64 — # [not x86_64] was written for linux-aarch64 but also matches macOS ARM. The faiss-cpu output in the same file already pins only libopenblas on osx.

Changes

1. conda/faiss/meta.yaml (lines 72, 86) — narrow the selector to # [linux and not x86_64], so osx-arm64 constrains only libopenblas (what libfaiss actually links: libopenblas.0.dylib). linux-aarch64 and x86_64 behavior unchanged.

2. .github/workflows/build-release.yml — add workflow_dispatch with a platforms choice input. The workflow was workflow_call-only, so a single failed conda leg could not be rebuilt without pushing a tag. Each job gains an if: that is a no-op on tag pushes (github.event_name is push), preserving current release behavior.

Recovery plan for 1.15.1

After this lands, dispatch build-release.yml from main with platforms: osx-arm64. The conda version comes from git describe, so this produces 1.15.1 build 1 — same version, next build number, no retagging and no PyPI involvement.

Note

If conda-forge publishes the missing openblas builds, the old recipe would start working again on its own. This change removes the coupling so the build no longer depends on that.

Test Plan:

• CI passes
• Dispatch build-release.yml with platforms: osx-arm64 and confirm the conda solve succeeds
• Confirm faiss-cpu 1.15.1 appears for osx-arm64 on the pytorch channel

Differential Revision: D120400090

Pulled By: alibeklfc

[meta-codesync]

@alibeklfc has imported this pull request. If you are a Meta employee, you can view this in D120400090.

[alibeklfc]

Follow-up from review: pinned the openmp variant explicitly.

Dropping the openblas metapackage on osx left the libopenblas variant unconstrained. Four osx-arm64 builds share build number 1 (openmp_h5e6e99c_1, pthreads_hb42d564_1, openmp_h4f80526_1, pthreads_h60d1960_1), so nothing forced an openmp build — the solver reaching for openmp_h5e6e99c_1 is a tiebreak, not a guarantee. A pthreads pick would give an OpenMP-built faiss a pthreads OpenBLAS: same libopenblas.0.dylib SONAME so it links and runs, but nested-threading behaviour changes.

Now pinned at all 6 osx sites in both outputs:

- - libopenblas =0.3.34  # [osx]
+ - libopenblas =0.3.34=openmp*  # [osx]

Note the faiss-cpu output already carried this exposure before this PR, so it is pre-existing rather than introduced here — this tightens both outputs.

[meta-codesync]

@alibeklfc has exported this pull request. If you are a Meta employee, you can view the originating Diff in D120400090.

[meta-codesync]

@alibeklfc merged this pull request in 98af2cf.