--- tags: [meeting-notes] --- # conda-forge core meeting 2023-04-19 Add new agenda items under the `Your __new__() agenda items` heading - [Zoom link](https://zoom.us/j/9138593505?pwd=SWh3dE1IK05LV01Qa0FJZ1ZpMzJLZz09) - [What time is the meeting in my time zone](https://dateful.com/convert/utc?t=5pm) - [Last week's meeting](https://hackmd.io/#REPLACE_ME#) ## Attendees | Name | Initials | GitHub ID | Affiliation | | ----------------------- | -------- | --------------- | --------------------------- | | Jaime Rodríguez-Guerra | JRG | jaimergp | Quansight/cf | | Cheng H. Lee | CHL | chenghlee | conda-forge/Anaconda | | John Kirkham | JK | jakirkham | conda-forge/NVIDIA | | Marcel Bargull | MB | mbargull | Bioconda/cf | | Filipe Fernandes | FF | ocefpaf | conda-forge | | Jannis Leidel | JL | jezdez | Anaconda/conda-forge | | | | | | | | | | | | | | | | X people total ### Standing items - [ ] ### From previous meeting(s) - [ ] ### Active votes - [ ] ### Your `__new__()` agenda items - [X] (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? - Easiest path: https://azure.microsoft.com/en-us/products/dev-box/ - Could also ship physical machines - 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 - https://github.com/conda-forge/conda-forge.github.io/issues/1940 - - (CHL) Tracking ecosystem support as [conda/conda#11472](https://github.com/conda/conda/issues/11472) - PR [conda/conda#11778](https://github.com/conda/conda/pull/11778): add `win-arm64` as platform in `conda` - PR [conda/conda-build#4579](https://github.com/conda/conda-build/pull/4579): add `win-arm64` as platform in `conda-build` - [ContinuumIO/anaconda-issues#12957](https://github.com/ContinuumIO/anaconda-issues/issues/12957): add `win-arm64` as platform in anaconda.org - [X] (JK) New CTK packages / CUDA 12 - Most packages up (few remaining / some follow up items) - `cuda-version` - https://github.com/conda-forge/cudatoolkit-feedstock/pull/89 - https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/435 - 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 - [x] (HV) Bump to GCC 12 / LLVM 15 (should not be controversial, just needs a merge) - https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/4215 - [x] (HV) RHEL 8-compatible sysroot (most likely AlmaLinux, matching [manylinux_2_28](https://github.com/pypa/manylinux/issues/1282)) - 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](https://github.com/conda-forge/conda-forge.github.io/issues/1432#issuecomment-1512315951). - [x] (HV) Boost harmonization - Can we agree on the plan in https://github.com/conda-forge/boost-cpp-feedstock/issues/137? - If so, I can start raising PRs - agreed to plan with name libboost-python for anaconda py-boost and conda-forge boost ### 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 - [ ]