conda-forge core meeting 2024-11-13
Add new agenda items under the Your __new__() agenda items
heading
Attendees
Name | Initials | GitHub ID | Affiliation |
---|---|---|---|
Marco Esters | ME | marcoesters | Anaconda |
Daniel J Ching | DJC | carterbox | NVIDIA/conda-forge |
Klaus Zimmermann | KZ | zklaus | Quansight |
Cheng H. Lee | CHL | chenghlee | Anaconda/conda-forge |
Scott Hain | SMH | scotthain | Anaconda |
Dasha Gurova | DG | dashagurova | Anaconda |
John Kirkham | JK | jakirkham | NVIDIA/cf |
X people total
Standing items
- [ ]
From previous meeting(s)
- [ ]
Active votes
- [ ]
Your __new__()
agenda items
- (DJC) conda-forge default build containers should always have the latest glibc/sysroot package that we publish
- https://github.com/conda-forge/conda-forge-pinning-feedstock/issues/6283#issuecomment-2453101928
- defaulting to the latest os makes os_version irrelevant for most users because glibc backward compatability
- glibc constraint still set by sysroot package at build time; this package can lag behind syroot in container
- (HV) For clarity, I would formulate the topline as: "conda-forge should use the newest available image versions by default (in sync with max sysroot that we publish)"
- (HV) Fully support this proposal; draft implementation here
- (HV) Also propose to remove
c_stdlib_version
from CUDA zip -- with the policy of "always newest image", this is not necessary anymore (and actually harmful to common usecases) - Additional clarifications:
- HV: System image mostly irrelevant to the build process, only relevant for runtime constraints that power the
__glibc
virtual package. - IF: Ok with proceeding, but should take care of making sure that the cuda-* repackaged stuff still works with the original GLIBC / Docker images. Override in those cases, because those repackaged builds do not use our sysroot, and we can't ensure otherwise that they do work with the lowest Docker image available.
- HV: consequence would be using
os_version: linux_*: alma8
inconda-forge.yml
on feedstocks that do binary repackaing
- HV: System image mostly irrelevant to the build process, only relevant for runtime constraints that power the
- Recap: Ok to go, but binary repackaging feedstocks should pin os_version as per above (to stay with whatever minimum version they claim to support) before bumping the default image.
- (HV) Propose to consolidate image names: https://github.com/conda-forge/docker-images/issues/293
- IF/CHL: Jinja variables can't be used in
conda_build_config.yaml
- use distro-name in the tag (also for CUDA 11.8); despite the lack of templating over it
- (Some conversations about dropping CUDA 11.8 so the corresponding Docker images are not needed. This will happen eventually, just not yet.)
- IF/CHL: Jinja variables can't be used in
- (JRG)
conda-forge/miniforge
considered "dangerous site" by Google.- See https://github.com/conda-forge/miniforge/issues/667
- Proposed solution: Move content to conda-forge.org, where we have ownership for reviews and disputes.
- Thoughts?
- Consensus: Give it a try.
- (HV) How to deal with CUDA 12.x?
Pushed to next meeting
- (ME) Composite action to build installers (Miniconda, Miniforge, etc.)
- [ ]
CFEPs
- [ ]