跳转至主要内容

常见问题解答

为什么 conda-build 忽略 meta.yaml 中的 py37 选择器？​

TL;DR：将 py37 替换为 py==37。

conda-build 已经更改了选择器语法。现在鼓励您使用 py==<version>，而不是 py<version>。虽然旧的选择器 py27 和 py36 仍然有效，但选择器 py37 和更高版本不再有效。

请使用新的语法 py==27、py==36 和 py==37 以避免混淆。

相关链接

大于 1000 的构建编号表示什么？我应该如何处理它们？​

TL;DR：不再需要大于 1000 的构建编号。

当您更新仍然使用构建编号 > 1000 的 feedstock 时，以下规则适用

  • 当您增加版本时，将构建编号重置回 0（例如 1005 -> 0）。
  • 当版本保持不变并且您需要上传新软件包时，将构建编号增加 1（例如 1005 -> 1006）。

背景故事： 1000 及更大的构建编号是编译器迁移遗留下来的，其中 1000 的构建编号偏移表示软件包已迁移到新的编译器。自从编译器迁移完成以来，不再需要此偏移。但是，由于求解器优先选择更高的构建编号，因此我们无法在不更新版本的情况下简单地减去偏移量。因此，随着软件包更新到更新的版本，大于 1000 的构建编号将逐渐消失。

如何修复 CMake 在 Azure Windows 构建中找不到 MSBuild.exe 的问题？​

TL;DR：使用 Ninja 或 NMake Makefiles JOM 作为 CMake 生成器（cmake -G"Ninja"），并为 ninja 或 jom 添加 build 要求。

遗憾的是，在 Azure Windows 镜像中，MSBuild.exe 没有为使用 Visual Studio 生成器的 CMake 构建正确设置。为了解决这个问题，您可以使用不同的 CMake 生成器，例如 cmake -GNinja 或 cmake -G"NMake Makefiles JOM"。首选这两种生成器，因为它们允许并发构建，而例如仅使用 cmake -G"NMake Makefiles" 则不行

为什么我的新版本出现在 Anaconda Cloud 上，但无法通过 conda 安装？​

对于某些高流量频道（main 和 conda-forge），Anaconda 使用 CDN 来降低成本。因此，软件包将比通过 conda 下载提前约 10 分钟显示在 Anaconda Cloud 上。您可以使用 conda search <pkg> 来查看软件包是否可安装，因为此命令从 CDN 读取。

如果 CDN 同步没有及时发生，请检查 状态页面 以查看 CDN 克隆状态，并查看是否发生任何问题。如果克隆未同步，您可以在 Anaconda Issues repo 中打开一个 CDN Issue。

如何加快本地调试速度？​

如果您喜欢在本地调试您的 recipes，而不是使用提供的 脚本，而是使用您自己的设置，您也可以通过 mambabuild 使用 mamba 求解器。它不仅具有更快的求解速度，而且还打印更好的错误消息，使调试更简单。

为此，首先安装求解器，然后像往常一样构建 recipe

  • conda install boa -c conda-forge
  • conda mambabuild myrecipe

有关更多详细信息，请访问 此 页面。

我在构建期间看到 Importing conda-verify failed. 错误消息。我该怎么办？​

Importing conda-verify failed. Please be sure to test your packages. conda install conda-verify to make this message go away.

您看到此错误消息是因为默认情况下，conda-build 使用 conda-verify 来确保您的 recipe 和软件包满足一些最低限度的健全性检查。此消息可以安全地忽略，因为 conda-forge 不使用 conda-verify。

当机器人创建一个拉取请求到 feedstock 以更新版本时，我应该批准拉取请求并等待合并，直到所有其他作为代码所有者的人员都批准了 PR 吗？​

无需批准 PR。每个维护者都可以验证和合并机器人 PR，而无需等待其他维护者的批准。

如何修复 “build-locally.py 失败，退出代码 139”？​

使用 Linux Kernel 4.11，vsyscall 链接方面进行了一些更改。根据您的发行版，这可能会导致上述错误。您可以通过编辑 /etc/default/grub 并在该文件中指定 GRUB_CMDLINE_LINUX_DEFAULT="vsyscall=emulate" 来在 Debian 上修复此问题。之后，您需要运行 update-grub 并重新启动系统。在其他 Linux 发行版上，修复方法类似，但您需要编辑不同的配置文件来更改 Linux 内核 cmdline。此解决方法仅适用于基于 CentOS 6 (cos6) 的镜像。您也可以通过强制使用基于 CentOS 7 的镜像来解决此问题，方法是使用 DOCKER_IMAGE=quay.io/condaforge/linux-anvil-cos7-x86_64 ./build-locally.py。

退出代码 139 本身实际上是段错误的通用退出代码。这也可能意味着您遇到了不同的问题，但上述问题是我们基于 CentOS 6 的镜像最有可能遇到的问题。

我提交给 conda-forge 的软件包是否必须是上游维护的软件包？​

每个人都可以向 conda-forge 提交软件包，无论他们是否维护上游版本。此外，通知上游新的软件包并邀请他们也成为维护者不是必需的，但被认为是良好的做法。

如何修复 libGL.so.1 导入错误？​

错误

ImportError: libGL.so.1: cannot open shared object file: No such file or directory

如果您在 feedstock 中构建软件包时看到此错误，请添加 Linux 主机依赖项 libgl-devel，由 libglvnd-feedstock 提供。

requirements:
  host:
    - libgl-devel  # [linux]

其他 OpenGL API 变体（如 libegl-devel、libgles-devel、libglx-devel 和 libopengl-devel）也可用，并将自动添加非开发 run_exports 依赖项。

如果您在本地安装软件包后看到此错误，则说明您的系统依赖项中缺少 OpenGL 提供程序。这更可能发生在没有图形的无头系统（服务器、Docker 镜像等）中。要修复它，您必须使用您的系统软件包管理器安装一个提供程序，如 Mesa，例如（检查您的发行版文档以获取确切的软件包）

  • 基于 Debian/Ubuntu 的发行版：sudo apt-get install libgl1-mesa-dri libglx-mesa0 libegl-mesa0
  • 基于 Fedora 的发行版：sudo dnf install mesa-libGL mesa-libEGL mesa-dri-drivers

如何修复测试期间出现的 The Qt platform plugin "xcb" could not be loaded 错误？​

当测试依赖于 pyqt 的软件包时，在 linux 下可能会出现以下错误

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, webgl, xcb.

这来自无头 CI 环境，可以通过添加 QT_QPA_PLATFORM=offscreen 环境变量 来修复。该变量可以直接添加到测试命令中，也可以像这样在 meta.yaml 中提供

build:
  script_env:
    - QT_QPA_PLATFORM=offscreen

如何联系 conda-forge/core？​

当在 issue 或 PR 中时，您可以通过在评论中简单地提及 @conda-forge/core 来联系 conda-forge/core。如果您在几天后没有收到回复，请随时通过公共 Zulip 聊天室 与我们联系。

注意

由于 GitHub 的限制，新成员禁用此功能。在这种情况下，您可以使用机器人命令 @conda-forge-admin, please ping conda-forge/core 来 ping core。

如果您的问题较长，或者您希望私下联系我们，请随时通过联系我们页面上列出的方式与我们联系。

一个 feedstock 已被弃用，我想要接管维护。​

当维护者不再出现，并且不合并新的 PR 或回复任何 issue 时，通常认为 feedstock 已被弃用。 如果是这种情况，您可以使用 @conda-forge-admin, please add user @username 命令将自己添加到团队中。 如果维护者大约一周后仍未合并，请联系 conda-forge/core 以进行合并。 添加后，您将拥有 feedstock 的完全权限，并可以继续维护。

注意

即使维护者不再活跃，我们通常也希望将他们保留在维护者列表中，而不是删除他们，以防他们以后想要重新承担维护工作。

conda-forge 会对重要的上游软件包进行重大更改或应用代码补丁吗？​

我们通常尽量避免更改，但也有许多值得注意的例外情况，并且我们没有既定政策。 这些更改目前分为几类。 违反我们社区规范或通过其政策构成重大安全风险的上游项目可能会被更改，以便它们可以在 conda-forge 上分发。 但在许多情况下，这些项目根本不分发。 为了正确地构建项目并将项目安装到 conda 环境中，我们确实对项目构建脚本进行了广泛的更改。 最后，在某些情况下，我们会在特定项目中添加、启用或禁用功能，以确保它们与 conda-forge 软件包集广泛兼容。 我们应用的补丁/更改集始终位于构建软件包的 feedstock 中。 我们还在文档中维护了一个包含更改的重要软件包列表。