Skip to main content

conda-forge core meeting 2023-04-19

Add new agenda items under the Your __new__() agenda items heading

Attendees​

NameInitialsGitHub IDAffiliation
Jaime Rodríguez-GuerraJRGjaimergpQuansight/cf
Cheng H. LeeCHLchenghleeconda-forge/Anaconda
John KirkhamJKjakirkhamconda-forge/NVIDIA
Marcel BargullMBmbargullBioconda/cf
Filipe FernandesFFocefpafconda-forge
Jannis LeidelJLjezdezAnaconda/conda-forge

X people total

Standing items​

  • [ ]

From previous meeting(s)​

  • [ ]

Active votes​

  • [ ]

Your __new__() agenda items​

  • (JK) Windows ARM64
    • (SD) Working on new Windows ARM hardware
      • like Surface Pro X
      • CPython building on Windows ARM (tier 3)
      • Currently GHA doesn't have native Windows ARM support
      • How to enable developers?
        • Interested in enabling conda-forge to build packages
        • Easy to give resources to one org (conda-forge fits the bill)
      • What would be needed?
        • Dev time (Finn dev w/Steve would be contributing)
        • Hardware?
        • Can cross-compile (have cross-compilers)
        • (MRB) Does LIEF work on Windows ARM?
          • (SD) Ordinary PE with another instruction set
        • (JRG/MRB) Migrator? Doable
        • (JRG) Constructor stack? NSIS, pyinstaller (conda-standalone)
          • SD: x86 installers should work
          • JRG: We need changes in constructor to support "cross-installers", but not too complicated (export CONDA_SUBDIR?)
        • ED: what's needed?
          • 1 or more "core sponsor(s)" of the work that can ensure things aren't block on the CF side
          • someone that provides hardware
          • someone that has the time to hack on this problem
          • someone at Anaconda that can help push changes into the various tools that need to be updated to support the new platform
      • Thoughts? :)
        • (JL) Introducing new platform is non-trivial
          • Want to make sure this is somehow funded
          • Maybe NF as a conduit (SDG or ...?) for Conda / cf
        • (MRB) How did we do this in the past (aarch64, pp64le, OSX arm)?
          • (IF) Linux aarch64 was Jonathan Helmus ( https://github.com/jjhelmus ) starting with Rasberry Pi and going from there
          • (IF) Can bootstrap
        • (JL)
        • (IF) Keeping things green (once a package works we'd like it to keep working)
        • (IF) A few more Azure jobs? Particularly if Windows ARM supports multiple version
      • (MRB) Cross-compiling is probably most efficient approach (like what MacOS ARM uses)
      • (MRB) Let's create a tracking issue
    • (CHL) Tracking ecosystem support as conda/conda#11472
  • (JK) New CTK packages / CUDA 12
  • (HV) Bump to GCC 12 / LLVM 15 (should not be controversial, just needs a merge)
  • (HV) RHEL 8-compatible sysroot (most likely AlmaLinux, matching manylinux_2_28)
    • sync requirements / naming with Anaconda (once aligned, I'll try to start raising PRs)
      • (CHL) Anaconda naming convention is sysroot_${subdir}=${glibc_version} (so probably sysroot_linux-64=2.28)
      • use cdt_name = "conda_2_28"
      • pull CDTs out of alma8
    • see Matthew's initial TODO list.
  • (HV) Boost harmonization

Pushed to next meeting​

  • (WV) rattler-build - new conda package build tool: https://github.com/prefix-dev/rattler-build
  • (JK) New CTK packages / CUDA 12
    • Opening CUDA 12 migrator
      • Package layout changes:
        • Document?
        • Message?
        • Incremental rollout?
    • (Longer-term) CUDA 11 backport?
      • New style packages on older CUDA versions
      • What version to start with (nvidia channel has 11.4)?
      • cudatoolkit becomes metapackage?
      • Potential to drop some CUDA specific things
        • Docker images
        • conda-forge-ci-setup simplification

CFEPs​

  • [ ]