---
tags: [meeting-notes]
title: '2025-11-12'
---
# conda-forge core meeting 2025-11-12
Add new agenda items under the `Your __new__() agenda items` heading
- [Zoom link](https://zoom.us/j/9138593505?pwd=SWh3dE1IK05LV01Qa0FJZ1ZpMzJLZz09)
- [What time is the meeting in my time zone](https://dateful.com/convert/utc?t=5pm)
- [Previous meetings](https://conda-forge.org/community/minutes/)
## Attendees
| Name | Initials | GitHub ID | Affiliation |
| ----------------------- | -------- | --------------- | --------------------------- |
| Daniel Ching | DJC | carterbox | NVIDIA/cf |
| Cheng H. Lee | CHL | chenghlee | Anaconda/cf |
| Klaus Zimmermann | KZ | zklaus | Quansight |
| John Kirkham | JK | jakirkham | NVIDIA/cf |
| Jaime RodrÃguez-Guerra | JRG | jaimergp | Quansight/cf |
| Axel | HV | h-vetinari | |
| Ruian Zhang | | | openKylin |
| Wenzhu Wang | | | openKylin |
| Tianxiang Bian | TB | bitsk | openKylin |
| Jiankang Li | | | openKylin |
| Tianmai Deng | | | UltraRISC |
| Lori Burns | LB | | cf |
X people total
### Standing items
- [ ]
### From previous meeting(s)
- [x] (CHL) Quick annoucement: [nvidia-virtual-packages](https://github.com/conda-incubator/nvidia-virtual-packages) now part of conda incubator
### Active votes
- [X] (HV) Currently open vote for new cf/core member.
- Core members check Helios.
### Your `__new__()` agenda items
- Introductions.
- [X] (HV) RISC-V in conda-forge:
- See recent [outreach](https://conda-forge.zulipchat.com/#narrow/channel/457337-general/topic/Bringing.20conda-forge.20to.20RISC-V.20.28We.20have.20a.20working.20miniforge/with/554889173) from "RISC-V SIG at the openKylin OS community" / "UltraRISC team"
- Also: https://github.com/conda-forge/conda-forge.github.io/issues/1744
- [OpenKylin](https://www.openkylin.top/index-en.html) community provides OS porting, packaging, compilation, maintains large sw repository. Partnered with UltraRISC chip manufacturer.
- Strong user demand for Python packaging, as provided by conda-forge. Critical for domains like AI, DS and HPC.
- Have experimental builds for cross-compilers, native core packages, and miniforge. Check conda.riscv.uno.
- Aware of the burden, can commit manpower: 2-3 FTE + interns. Building packages, platform issues, linux-riscv64. Proven expertise.
- Their problem: conda-forge base image does not support RISCV. PoC uses Fedora 42 with glibc 2.41. Realistic minimum is glibc 2.38, way more modern than conda-forge's glibc default.
- HV: No minimum glibc requirements for new architectures. Is RISCV supported in Alma / RHEL 10?
- https://developers.redhat.com/products/rhel-riscv
- https://access.redhat.com/articles/7117031
- https://fedoraproject.org/wiki/Architectures/RISC-V
- https://fedoramagazine.org/risc-v-and-fedora-all-aboard/
- https://iree.dev/building-from-source/riscv/
- IF: Alma Linux 10 ships with 2.39, is that glibc version sufficient?
- OpenKylin team: 2.39 should be ok.
- Question: What's the best way to add support for RISCV? Aware of s390x and win-arm64 efforts in the past.
- IF: GLIBC version not so much of a problem. How long would you be able to commit those FTEs?
- Ruian: This project would be long-term
- Wenzhu: We have a large team and can work long-term on it.
- HV: Details about the existing package repository? How do people install it?
- Ruian: Using `apt` like in Debian and Ubuntu.
- JK: Hardware for CI and testing so we don't use the Azure pool too much when cross-compiling?
- Wenzhu/Ruian: Hardware available as part of the commitment.
- Tianmai: We can provide RISC-V hardware through openKylin.
- IF: Which RISC-V ABI flavor is being used in OpenKylin?
- Tianxiang: rv64gc and rva23
- IF: Can they exist at the same time?
- Ruian: yes.
- Wenzhu: Machines are RVA20 for now, maybe next year RVA23.
- HV: LLVM has:
- riscv32, // RISC-V (32-bit, little endian): riscv32
- riscv64, // RISC-V (64-bit, little endian): riscv64
- riscv32be, // RISC-V (32-bit, big endian): riscv32be
- riscv64be, // RISC-V (64-bit, big endian): riscv64be
- Ruian: Happy to discuss more about these details in Zulip
- [X] (HV) Future C(F)EPs
- GPU-architecture metadata (bolstered by very painful episode with [cudnn](https://github.com/conda-forge/cudnn-feedstock/issues/124) recently): https://github.com/conda/ceps/issues/139
- "Temperature check" for https://github.com/conda/ceps/pull/129 before I begin writing specifications
- Jaime to check with Cheng.
- Package renaming policy https://github.com/conda-forge/cfep/pull/64
- [X] (HV) Reinstate https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/6910
- Aimed at avoiding wastefulness because on feedstocks that need GPUs, we cannot distinguish CUDA-vs.CPU-only and thus GPU-enabled agents (the most rarest resource) get used even for CPU builds; this is especially painful for the pytorch feedstock, where this increases the (already enormous) CI runtime by ~50% due to reduced parallelism.
- PR was reverted and currently blocked in https://github.com/conda-forge/conda-forge-pinning-feedstock/issues/6967 over a cosmetic concern (how many elements in `cuda_compiler_version` zip), which nowhere near outweighs the downsides.
- 10 months of no progress; time to unblock the situation.
- IF: Proposes to do the same thing we do with cuda `CF_CUDA_ENABLED` environment variable. e.g. `CF_SELF_HOSTED` which can be used in the global pinning file. This would only extend the zip keys for self-hosted.
- [X] (DJC) Bot migrator for arm-variant=tegra
- Having zip key difficulty. Need to zip `arm-variant`, `cuda_compiler_version`, and `c_stdlib_version` for linux-aarch64 :facepalm: because tegra is CUDA 12.9 only and has higher glibc requirement (2.34) than SBSA.
- HV: Refer to CUDNN migrator for an example.
- IF: Check if `additional_zip_keys` + `use_local: true` in the migrator helps.
### Pushed to next meeting
- [ ]
### CFEPs
- [ ]