conda-forge 核心会议 2024-12-11
在 Your __new__() agenda items
标题下添加新的议程项
与会者
姓名 | 首字母 | GitHub ID | 隶属关系 |
---|---|---|---|
Jaime Rodríguez-Guerra | JRG | jaimergp | conda-forge, Quansight |
Filipe Fernandes | FF | ocefpaf | conda-forge |
Klaus Zimmermann | KZ | zklaus | Quansight |
Daniel Ching | DJC | carterbox | NVIDIA, conda-forge |
Sophia Castellarin | SC | soapy1 | Quansight |
Marius van Niekerk | MvN | mariusvniekerk | Voltron Data, conda-forge |
John Kirkham | JK | jakirkham | NVIDIA/cf |
共 X 人
常设事项
-
(DJC) 为什么只有 x86 sysroot=2.17 软件包运行 export
__glibc
?- arm 和 powerpc sysroot 直到更高版本才具有运行导出,这意味着使用默认 sysroot 构建时,alt archs 没有最低
__glibc
版本。 - run_exports 在此处添加到 sysroot 软件包:https://github.com/conda-forge/linux-sysroot-feedstock/pull/11/files
- HV:可能是遗留更新的产物。x86 过去使用 2.12,然后升级到 2.17,但 ppc/arm 始终为 2.17。也许它从未更新,因为它只是一个疏忽,当时不需要。在某种程度上它是多余的,因为在那些 archs 中 2.17 之前没有任何东西,但是的,从这个意义上说它是不一致的。
- 行动项:打开 issue 或 PR 以解决不一致问题。
- arm 和 powerpc sysroot 直到更高版本才具有运行导出,这意味着使用默认 sysroot 构建时,alt archs 没有最低
-
(DJC) 使用 readelf 检查 NVIDIA redists 的 glibc 符号而不是 pinning os_version 是否可以接受
- 在之前的会议中,我们同意 NVIDIA redists 应选择 os_version 以匹配最低支持的 glibc 版本。这样,如果加载二进制文件,测试将失败。但是,许多 feedstock 在测试期间不加载二进制文件。使用 readelf 查找 glibc 符号是否可以接受?
- 使用此类检查的示例 feedstock:https://github.com/conda-forge/cudnn-feedstock/pull/97
- HV:有道理。比希望在错误的 glibc 上失败更全面。
-
(KZ) blas 是否发生了一些奇怪的事情,参见 https://conda-forge.zulipchat.com/#narrow/channel/457337-general/topic/error.20while.20loading.20shared.20libraries.3A.20libblis.2Eso.2E4 ?
- 我们对 MKL 的依赖引入了跟上 blas/lapack 版本的问题
- 此特定问题的可能候选者是拉入 blis 或 llvm 的瞬态依赖项
-
(HV) Numpy 2.0:何时关闭该 迁移?我们正在跟踪哪些指标来做出该决定?
- staged-recipes 中任何依赖于已需要 2.0 的配方的配方中的问题(可以使用
conda_build_config.yaml
覆盖)- JRG:CBC 覆盖听起来不错,但请确保我们在关闭迁移器后撤消此操作。
- HV:这为我们做出该决定争取了一些时间。
- 行动项:在 staged-recipes 中创建该 CBC 覆盖。
- staged-recipes 中任何依赖于已需要 2.0 的配方的配方中的问题(可以使用
-
(HV) 对
cache:
CEP 的反馈?- WV:重用与常规输出中相同的
build
结构,但仅使用script
。是否只应允许某些build.*
键? - WV:自动注入与否?
- JRG:如果是自动的,用户应该能够使用
cache: false
或类似的东西来覆盖。
- JRG:如果是自动的,用户应该能够使用
- WV:最新的 rattler-build 版本包括
cache
功能的最新草案,具有特定于缓存的源和工作目录解包。 - rattler-build 缓存是不可变的(它为每个输出重新生成),这与 conda-build 的有状态全局构建目录形成对比。关于是否需要多阶段缓存进行了一些讨论(输出是否可以以以下输出看到这些更改的方式修改缓存)。共识似乎是单阶段就足够了,如果我们真的需要多阶段,我们会在到达那里时听到相关信息。
- WV:重用与常规输出中相同的
-
(KZ) 我们应该发布贡献者统计信息吗?
- 示例:维护的 feedstock 数量,合并的 PR 数量
- JRG:在其他生态系统中:https://napari.org/weather-report/。
- JRG:conda-forge 徽章?代理数据 = 用户所属团队的数量。 https://github.com/orgs/conda-forge/teams?query=+members%3Ame
- FF:有人在 https://github.com/axiom-data-science/feedstockrot 上做了类似的事情
来自之前的会议
- [ ]
正在进行的投票
- [ ]
您的 __new__()
议程项
- [ ]
推迟到下次会议
- [ ]
CFEPs
- [ ]