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 Miniforgehttps://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 tooa2) 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 themamba
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
inmeta.yaml
) to reset expectations about this packagePoint 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¶
[ ]