conda-forge core meeting 2023-08-09

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

Attendees

Name

Initials

GitHub ID

Affiliation

Matthew R Becker

MRB

beckermr

cf

Katherine Kinnaman

KK

kathatherine

Anaconda

Chris Ostrouchov

CO

costrouc

Quansight

Cheng H. Lee

CHL

chenghlee

Anaconda/cf

John Kirkham

JK

jakirkham

NVIDIA/cf

X people total

Standing items

  • [ ]

From previous meeting(s)

  • [ ]

Active votes

  • [ ]

Your new() agenda items

  • [x] (JK) GLIBC 2.28

    • ARM / Power

    • NVIDA CUDA static libraries (namely cudart) using 2.17 symbols only (others like cudadevrt or culibos use none?)

    • (MRB) Should we mark existing glibc 2.28 sysroots as broken? Will submit PR and see what happens.

    • SUSE as an option potentially? Will wait and see; still unclear where everything stands

  • [x] (JK) Adding conda-libmamba-solver to Miniforge

    • https://github.com/conda-forge/miniforge/issues/284

    • Jaime (absent): I won’t be able to attend today but I am very interested in solving the question above. Miniconda already ships conda-libmamba-solver, and by the September release it will be the default solver (i.e. a conda dependency). So it will end up in Miniforge at some point when we update to 23.9 or above. The question is: shall we …

      • a) ship mamba in Miniforge too

      • a2) the above, and deprecate Mambaforge

        • and add links that redirect “mambaforge” -> “miniforge”

        • use copies to ensure old installs work (if no redirect option)

      • b) let mamba in Mambaforge only, and keep both installers separate, with the only difference being the presence of the mamba Python package (but note that libmamba and libmambapy are there)

    • Discussion: generally have miniconda/miniforge (include conda-libmamba-solver)

      • Are we dumping the pypy installers? keep (Up to Matti and others to decide)

        • Handling PyPy as separate item (so keeping PyPy installers for now)

    • List of artifacts

      • https://github.com/conda-forge/miniforge/releases/tag/23.1.0-4

    • Consensus is a2

  • [x] (JK) TexLive?

    • https://github.com/conda-forge/texlive-core-feedstock/issues/84

    • We’ll need to discover and solve dependency issues before we deprecate (if we choose to do so).

    • We don’t want to maintain a full (La)TeX distribution. Maybe add a caveat that this is for small bits of TeX, not a “full” distribution. (Reset expectations)

    • Plan to add README (maybe also description in meta.yaml) to reset expectations about this package

    • Point out release and migrator merged recently

  • [x] (JRG) osx-arm64 native runners. Possibility to ask for sponsorship to MacStadium (they do it for Homebrew) or Scaleway (they have an OSS program).

    • JRG: Sorry I will be absent but this was discussed briefly in the core chat and in case anyone missed it, posting it here for visibility.

    • JRG: Scaleway offers “up to” 2400€/year for OSS projects. M1 runners cost 0.11€/h, so we can afford around 2.5 runners.

      • Asked Amit about cirun support for scaleway

  • [x] (MRB) Cirrus CI

    • Limited free usage due to cryptominers

    • Cost is rather high and may involve self-hosting (ToS)

    • Running out of credits would mean it would stop suddenly (bad UX story)

    • Will look at other options

Pushed to next meeting

  • [ ] (JK) Windows ARM

  • [ ] (CHL) How long should we keep osx-64 support?

CFEPs

  • [ ]