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