Maintenance Notes

Maintenance Notes

Evidence-backed notes that explain current dashboard state, intentional platform limits, or follow-up work. Keep transient progress in upstream issues or PRs; add notes here only when they affect a row in Feedstock Inventory.

• Home
• Feedstock Inventory
• Dashboard Conventions

Created Feedstocks

• momentum-feedstock PR #293 for the CUDA 13 migration has merged at 4e8a191 from head bba9286. It landed the short-term eigen >=3.4,<4 workaround for current Momentum 0.1.110, the Linux CUDA 13 cuda-gdb skip for Python 3.13/3.14, and the runtime Eigen dependency needed by downstream momentum-cpp CMake consumers. The longer-term Eigen 5 support follow-up remains upstream in facebookresearch/momentum#1407 and facebookresearch/momentum#1408.
• momentum-feedstock PR #295 has merged at 6592853 and uploaded linux-aarch64 artifacts for momentum 0.1.110; the row now includes la64 and remains yellow only because linux-ppc64le artifacts are not present.
• momentum-feedstock PR #300 was the tbb 2023 bot rebuild. The first Azure run failed before the recipe ran because the worker could not resolve pixi.sh; the branch was no-op amended to 2ac4b56 to restart CI without adding a PR comment. It merged as 15cfb22.
• momentum-feedstock PR #301 is ready for review at e30ebe9, rebased on #300. The pre-ready current-head GitHub/Azure/linter CI was green, and converting from draft to ready started a fresh Azure matrix build 1544055 on the same head. It reflects upstream PyPI split work from facebookresearch/momentum#1483, #1523, and #1503 by adding a real pymomentum-core output, making pymomentum-cpu/pymomentum-gpu real full-package outputs, and keeping pymomentum as a compatibility metapackage. pymomentum-cpu/pymomentum-gpu were already registered through conda-forge/admin-requests#1137; conda-forge/admin-requests#2165 registered the new pymomentum-core output. Do not merge before 2026-06-26 08:37 PT / 2026-06-26 15:37 UTC; leave the 24h reviewer window open and avoid PR comments unless asked.
• mhr-feedstock PR #5 merged as cccb284 for mhr 1.0.1 with recipe/pyproject-runtime-deps.patch to backport the missing NumPy runtime metadata. Upstream facebookresearch/MHR#71 has merged the same fix, but the latest public GitHub/PyPI/conda release remains 1.0.1, which predates it. On the next upstream release containing #71, remove the feedstock patch and the source.patches entry instead of carrying the backport forward.
• pyroomacoustics-feedstock was created and PRs #1, #4, and #5 have merged. Build 3 artifacts for pyroomacoustics 0.8.3 are uploaded for linux-64, linux-aarch64, linux-ppc64le, osx-64, osx-arm64, and win-64; the recipe is now v1 and the row is green.
• mmpose-feedstock PR #7 and mmpretrain-feedstock PR #4 have merged and uploaded noarch: python artifacts. The packages are platform-independent, while mmcv/pytorch dependency availability still controls where installs solve.
• drjit-cpp-feedstock PR #45 merged as f8c1e5a from head 02b5526 for the bot drjit-cpp 1.4.0 update. The landed fix updated the vendored Dr.Jit submodule source archives to the upstream v1.4.0 pins, refreshed drjit-core/disable-march-flags.patch for the newer cmake-defaults, gated DRJIT_ENABLE_OPTIX with CUDA in C++ and Python builds, and disabled DRJIT_ENABLE_METAL for macOS builds because Dr.Jit v1.4.0's new Metal backend failed against conda-forge's default macOS 11 SDK (MTLResourceID, gpuAddress, MTLGPUFamilyMetal3, and related APIs are not available there). No existing patch could be cleanly removed for this upstream release; the source-stub and ISA patches still cover feedstock-specific build constraints. Pre-merge CI was green: GitHub Actions run 28258093104, Azure build 1544722, and the linter all passed on 02b5526.
• drjit-cpp-feedstock PR #46 merged as 800a0ac from head 6cfcaf6 to re-enable Dr.Jit Metal only for osx-arm64. It raises only the osx-arm64 SDK to 15.5 and deployment/runtime floor to 15.0, leaves osx-64 at SDK/deployment target 11.0, and keeps Metal disabled outside osx-arm64.
• drjit-cpp-feedstock PR #47 is open and mergeable at head 294beb9 on base 800a0ac as the separate LLVM cleanup follow-up. The verdict after checking upstream Dr.Jit, conda-forge pinning/package contents, and reverse-dependency use is that the custom LLVM 18/19/20/21 build matrix is not a hard requirement: the conda-forge-standard shape for this feedstock is one LLVM major, with future migrations moving the pin. The major still needs to be explicit because the runtime packages are major-named (libllvm21 and Windows libllvm-c21), llvmdev has no run exports, and unpinned llvmdev plus hardcoded runtime names could drift. The root Windows configuration issue was that linked LLVM mode expected a monolithic LLVM.lib; conda-forge's Windows LLVM packaging provides LLVM-C.dll/LLVM-C.lib through libllvm-c21, and upstream Dr.Jit's dynamic mode loads LLVM-C.dll. The next Windows CI failure at d5350f6 reached jit_llvm_init(): found LLVM 21.1.8 (ORCv2) and then failed materializing COFF generated constants (__real@..., __ymm@...). The attempted default-LLJIT-layer patch was not correct because Dr.Jit copies generated code out of its custom memory manager after ORCv2 compilation; bypassing that manager left jitc_llvm_memmgr_offset == 0 and Windows failed VirtualAlloc(..., 0, ...) with error 87. Current head 294beb9 keeps Dr.Jit's custom ORCv2 memory manager and sets LLVM's COFF object-layer symbol responsibility flags on the underlying RTDyldObjectLinkingLayer, matching LLJIT's default COFF behavior without bypassing Dr.Jit's memory manager. It adds LLVM_INCLUDE_DIRS for Windows dynamic-LLVM builds and puts the small LLVM C++ downcast in a separate Windows source file so it does not collide with Dr.Jit's dynamic C-API typedefs; runtime remains dynamic through LLVM-C.dll. Current #47 keeps Windows LLVM enabled as cpu_llvm21_2, uses upstream dynamic LLVM mode on Windows, adds runtime libllvm-c21, and restores the Windows installed-consumer jit_llvm test. Unix LLVM builds use single LLVM 21 with llvmdev 21.* and libllvm21; Python builds link with DRJIT_DYNAMIC_LLVM=OFF; Linux aarch64/ppc64le C++ remain explicit cpu_nollvm_2 because current conda-forge repodata has no LLVM 21 llvmdev/libllvm21 packages for those subdirs, and ppc64le is not covered by Dr.Jit-core's target mapping. The only current consumer family found is Momentum/PyMomentum, which requests the CPU Dr.Jit flavor but not a specific LLVM major. Current-head validation passed: git diff --text --check origin/main..HEAD, conda-smithy recipe-lint --conda-forge recipe, conda-smithy rerender --check --feedstock_directory ., patch apply check against extracted drjit-core, Windows render/solve showing cpu_llvm21_2 with llvmdev 21.* and libllvm-c21, Linux C++ render/solve showing cpu_llvm21_2 with llvmdev 21.* and libllvm21, and Linux aarch64 render/solve showing explicit cpu_nollvm_2 with no LLVM dependency. Fresh CI restarted on 294beb9. Avoid public PR comments unless asked, and do not merge unless explicitly requested.
• Remaining yellow created feedstocks are currently intentional platform limits unless noted above: igl, gpytoolbox, and pymeshlab are blocked from linux-ppc64le by the Embree/libigl dependency surface; causal-conv1d, gsplat, nerfacc, and tiny-cuda-nn are CUDA/PyTorch extension packages where macOS and linux-ppc64le are not applicable and Windows remains disabled until the conda-forge PyTorch/CUDA extension build path is proven; inplace-abn keeps Windows and some CUDA/Python variants skipped per recipe comments.

Co-Maintained Feedstocks

• igl-feedstock PR #51 merged as 9ed0532 to add linux-aarch64; all five linux-aarch64 artifacts for 2.6.1 are uploaded. Local linux-aarch64 Python 3.12 --no-test build completed successfully after the cross-compile stubgen fix. linux-ppc64le was removed after CI showed the upstream Embree-backed build passes -msse2, which the ppc64le compiler rejects.
• librerun-sdk-feedstock is already on v1 recipe.yaml with conda_build_tool: rattler-build on main; no conversion PR is needed.
• rerun-sdk-feedstock has a local v1/rattler-build migration prepared and validated, but the PR should be opened after the Wayland unblock PR #120 lands so the modernization stays separate from the functional fix.