conda-forge 核心会议 2024-11-13
在 您的 __new__() 议程项目 标题下添加新的议程项目
与会者
| 姓名 | 首字母 | GitHub ID | 隶属关系 |
|---|---|---|---|
| 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 人总计
常设事项
- [ ]
来自上次会议
- [ ]
正在进行的投票
- [ ]
您的 __new__() 议程项目
- (DJC) conda-forge 默认构建容器应始终具有我们发布的最新 glibc/sysroot 软件包
- https://github.com/conda-forge/conda-forge-pinning-feedstock/issues/6283#issuecomment-2453101928
- 默认为最新的操作系统使 os_version 对大多数用户无关紧要，因为 glibc 向后兼容性
- glibc 约束仍然由构建时的 sysroot 软件包设置；此软件包可能落后于容器中的 sysroot
- (HV) 为了清晰起见，我将首行表述为：“conda-forge 应该默认使用最新的可用镜像版本（与我们发布的最大 sysroot 同步）”
- (HV) 完全支持此提案；草案实施 此处
- (HV) 还建议从 CUDA zip 中删除
c_stdlib_version-- 采用“始终使用最新镜像”的策略，这不再必要（实际上对常见用例 有害） - 其他说明
- HV：系统镜像与构建过程几乎无关，仅与驱动
__glibc虚拟软件包的运行时约束相关。 - IF：同意继续，但应注意确保 cuda-* 重新打包的东西仍然适用于原始的 GLIBC / Docker 镜像。在这些情况下覆盖，因为这些重新打包的构建不使用我们的 sysroot，并且我们无法以其他方式确保它们与可用的最低 Docker 镜像一起工作。
- HV：结果是在
conda-forge.yml中对进行二进制重新打包的 feedstock 使用os_version: linux_*: alma8
- HV：系统镜像与构建过程几乎无关，仅与驱动
- 总结：可以继续，但二进制重新打包 feedstock 应按照上述内容锁定 os_version（以保持他们声称支持的任何最低版本），然后再 提升默认镜像。
- (HV) 建议合并镜像名称：https://github.com/conda-forge/docker-images/issues/293
- IF/CHL：Jinja 变量不能在
conda_build_config.yaml中使用 - 在标签中使用发行版名称（也适用于 CUDA 11.8）；尽管缺乏对其进行模板化
- （一些关于放弃 CUDA 11.8 的对话，这样就不需要相应的 Docker 镜像了。这最终会发生，只是还不是现在。）
- IF/CHL：Jinja 变量不能在
- (JRG)
conda-forge/miniforge被 Google 认为是“危险站点”。- 请参阅 https://github.com/conda-forge/miniforge/issues/667
- 建议的解决方案：将内容移动到 conda-forge.org，我们在那里对审查和争议拥有所有权。
- 有什么想法？
- 共识：尝试一下。
- (HV) 如何处理 CUDA 12.x？
推迟到下次会议
- (ME) 用于构建安装程序（Miniconda、Miniforge 等）的复合操作
- [ ]
CFEPs
- [ ]