跳到主要內容

FAQ

為什麼 conda-build 忽略 meta.yaml 中的 py37 選擇器？​

簡而言之：將 py37 替換為 py==37。

conda-build 已變更選擇器語法。現在建議您使用 py==<version>，而不是 py<version>。雖然舊版的選擇器 py27 和 py36 仍然有效，但選擇器 py37 及更高版本已不再有效。

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

相關連結

大於 1000 的建置編號代表什麼意義？我該如何處理它們？​

簡而言之：不再需要大於 1000 的建置編號。

當您更新仍使用大於 1000 建置編號的 feedstock 時，適用以下規則

  • 當您增加版本時，將建置編號重設回 0（例如 1005 -> 0）。
  • 當版本保持不變，且您需要上傳新的套件時，將建置編號增加 1（例如 1005 -> 1006）。

背景故事： 1000 及更大的建置編號是編譯器遷移遺留下來的，其中 1000 的建置編號偏移量表示套件已遷移到新的編譯器。由於編譯器遷移已完成，因此不再需要此偏移量。但是，由於較高的建置編號受到求解器的偏好，因此我們無法在不更新版本的情況下簡單地減去偏移量。因此，隨著套件更新到較新版本，大於 1000 的建置編號將逐漸消失。

如何在 Azure Windows 建置中修復 CMake 找不到 MSBuild.exe 的問題？​

簡而言之：使用 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 來降低成本。因此，套件將在大約 10 分鐘後顯示在 Anaconda Cloud 上，然後才能透過 conda 下載。您可以使用 conda search <pkg> 來查看套件是否可安裝，因為此命令會從 CDN 讀取。

如果 CDN 同步未及時發生，請查看 狀態頁面 以了解 CDN 克隆狀態，並查看是否發生任何問題。如果克隆未同步，您可以在 Anaconda Issues repo 中開啟 CDN 問題。

如何讓本機偵錯更快？​

如果您希望在本機偵錯您的配方，而不是使用提供的腳本，而是使用您自己的設定，您也可以透過 mambabuild 使用 mamba 求解器。它不僅具有更快的求解速度，而且還會印出更好的錯誤訊息，使偵錯更簡單。

若要執行此操作，請先安裝求解器，然後像平常一樣建置配方

  • 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 來確保您的配方和套件符合一些最低限度的健全性檢查。此訊息可以安全地忽略，因為 conda-forge 不使用 conda-verify。

當機器人建立提取請求 (pull request) 到 feedstock 以更新版本時，我應該批准提取請求，並等待其他所有程式碼擁有者都批准 PR 後再合併嗎？​

無需批准 PR。每位維護者都可以驗證和合併機器人 PR，而無需等待其他維護者的批准。

如何修復「build-locally.py 失敗，並顯示退出代碼 139」？​

在 Linux Kernel 4.11 中，vsyscall 連結方面有一些變更。根據您的發行版，這可能會導致上述錯誤。您可以在 Debian 上透過編輯 /etc/default/grub 並在此檔案中指定 GRUB_CMDLINE_LINUX_DEFAULT="vsyscall=emulate" 來修復此問題。之後，您需要執行 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？​

當您在問題或 PR 中時，您可以透過在註解中簡單地提及 @conda-forge/core 來聯絡 conda-forge/core。如果您在幾天後沒有收到回覆，請隨時透過公開的 Zulip 聊天室 與我們聯繫。

注意

由於 GitHub 的限制，新成員無法使用此功能。在這種情況下，您可以使用機器人命令 @conda-forge-admin, please ping conda-forge/core 來 ping core。

如果您的問題較長，或者您想私下與我們聯繫，請隨時透過 聯絡我們 中列出的選項與我們聯繫。

feedstock 已被棄用，我想接管維護。​

當維護者不再出現，並且不合併新的 PR 或回覆任何問題時，feedstock 通常被視為已棄用。如果是這種情況，您可以使用 @conda-forge-admin, please add user @username 命令將自己新增到團隊中。如果維護者在大約一週後沒有合併它，請聯絡 conda-forge/core 以將其合併。新增後，您就擁有 feedstock 的完整權限，並且可以繼續維護它。

注意

即使維護者不再活躍，我們通常也希望將他們保留在維護者列表中，而不是將他們移除，以防他們想在稍後恢復維護。

conda-forge 是否會對重要的上游套件進行重大變更或應用程式碼修補程式？​

我們通常嘗試避免變更，但有很多值得注意的例外情況，而且我們沒有設定任何政策。這些變更目前分為幾類。違反我們社群規範或透過其政策構成重大安全風險的上游專案可能會被變更，以便可以在 conda-forge 上發布。但在許多情況下，這些專案根本不會發布。我們確實對專案建置腳本進行了廣泛的變更，以便將專案正確地建置和安裝到 conda 環境中。最後，在某些情況下，我們會新增、啟用或停用特定專案中的功能，以確保它們與 conda-forge 套件集廣泛相容。我們應用的修補程式/變更集始終位於建置套件的 feedstock 中。我們還在文件中維護著一份包含變更的重要套件列表。