Skip to main content

conda-forge core meeting 2023-08-09

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

Attendees​

NameInitialsGitHub IDAffiliation
Matthew R BeckerMRBbeckermrcf
Katherine KinnamanKKkathatherineAnaconda
Chris OstrouchovCOcostroucQuansight
Cheng H. LeeCHLchenghleeAnaconda/cf
John KirkhamJKjakirkhamNVIDIA/cf

X people total

Standing items​

  • [ ]

From previous meeting(s)​

  • [ ]

Active votes​

  • [ ]

Your new() agenda items​

  • (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
  • (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
    • Consensus is a2
  • (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
  • (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
  • (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​

  • [ ]