Repository navigation
fix(conda): the osx-64 package carries arm64 binaries from conda convert #1822
Description
Describe the bug
The conda-dist job in .github/workflows/cron-conda.yml builds on macos-latest, which is an arm64 runner, so the host package is osx-arm64. It then targets osx-64 (around lines 519-535) and runs conda convert "$host_package" -p osx-64. That step relabels the platform but copies the binaries unchanged, so the published osx-64 package carries arm64 compiled extensions.
This already affected the vendored lxml. With #1814's ruling (option A), it also affects the vendored cffi and cryptography, so ESP decryption would fail to import on Intel Macs. This is inferred from how conda convert works and from the runner's architecture, and has not been confirmed on an Intel Mac.
Expected behavior
Every published conda package carries binaries for its own platform. For example: build osx-64 natively on an Intel runner (macos-13), and either publish osx-arm64 from the arm64 runner as well or stop converting.
Additional context
Found while auditing #1814; see #1821. Blocked until #1821 merges, because both change cron-conda.yml. create-release.yml's conda job should be checked for the same convert step.
Activity
JarryShaw commentedon Oct 16, 2026
Blocked until #1821 merges, since both change
cron-conda.yml.JarryShaw commentedon Oct 16, 2026
Unblocked: #1821 has merged. A worker is on it.
JarryShaw commentedon Oct 16, 2026
#1825 is up. It needs one call from you on cryptography for the Intel macOS conda package.
cryptography has not shipped an Intel macOS wheel since 49.0.0. I checked with
pip download: 48.0.1 has a universal2 wheel, while 49.0.0 and 50.0.2 have none. That leaves the newosx-64leg to build 50.0.2 from source, which probably links the runner's Homebrew OpenSSL. A package built that way would import on Macs that have Homebrew's OpenSSL and fail on others.cryptography==48.0.1for Intel macOS only, using its universal2 wheel. The script would need per-platform pins.pip install cryptography.There is also a smaller question.
osx-arm64is already published, and #1825 keeps it. Should the release completeness check count it too? It currently countslinux-64andosx-64. Counting it means a release missing onlyosx-arm64gets rebuilt.fix(conda): build each macOS conda package on its own architecture (#…
JarryShaw commentedon Oct 16, 2026
take B; use platform pins - i think requirements.txt support that actually
JarryShaw commentedon Oct 16, 2026
Recorded: option B. Intel macOS pins
cryptography==48.0.1, the universal2 wheel, through a platform marker inconda/requirements.txt; pip evaluates those markers, and every other build keeps50.0.2.util/conda_vendor.pyhas to write and check that pin too, so Conda Update does not drop it. #1825 gets a revision before merge. Theosx-arm64completeness question is left as is: still published, still not counted.