Skip to main content

conda-forge core meeting 2024-12-11

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

Attendees​

NameInitialsGitHub IDAffiliation
Jaime Rodríguez-GuerraJRGjaimergpconda-forge, Quansight
Filipe FernandesFFocefpafconda-forge
Klaus ZimmermannKZzklausQuansight
Daniel ChingDJCcarterboxNVIDIA, conda-forge
Sophia CastellarinSCsoapy1Quansight
Marius van NiekerkMvNmariusvniekerkVoltron Data, conda-forge
John KirkhamJKjakirkhamNVIDIA/cf

X people total

Standing items​

  • (DJC) Why do only x86 sysroot=2.17 packages run export __glibc?

    • arm and powerpc sysroots do not have the run export until later versions, this means there is no minimum __glibc version for alt archs when built with the default sysroot.
    • run_exports were added to the sysroot package here: https://github.com/conda-forge/linux-sysroot-feedstock/pull/11/files
    • HV: Likely to be an artifact of legacy updates. x86 used to use 2.12, and then was bumped to 2.17, but ppc/arm was always on 2.17. Maybe it was never updated because it was just an oversight and not needed at that time. In a way it's redundant, because there's nothing before 2.17 in those archs, but yes, it's inconsistent in that sense.
    • Action item: open an issue or PR to address the inconsistency.

  • (DJC) Acceptable to use readelf to check NVIDIA redists for glibc symbols instead of pinning os_version

    • In a previous meeting, we agreed that NVIDIA redists should choose os_version to match the minimum supported glibc version. This way, tests would fail if the binaries were loaded. However, many feedstocks do not load the binaries during testing. Is it acceptable to use readelf to look for glibc-symbols instead?
    • Example feedstock where this type of checking is used: https://github.com/conda-forge/cudnn-feedstock/pull/97
    • HV: Makes sense. More comprehensive than hoping to fail on a bad glibc.

  • (KZ) Is something funky going on with blas, c.f. https://conda-forge.zulipchat.com/#narrow/channel/457337-general/topic/error.20while.20loading.20shared.20libraries.3A.20libblis.2Eso.2E4 ?

    • Our dependency on MKL introduces problems wrt keeping up with blas/lapack versions
    • Likely candidate with this specific issue is transient dependency pulling in blis or llvm

  • (HV) Numpy 2.0: when to close that migration? What metrics are we tracking to make that decision?

    • Issues in staged-recipes for any recipe that depends on something which already requires 2.0 (can be overridden with conda_build_config.yaml)
      • JRG: CBC override sounds good, make sure we undo this once we close the migrator though.
      • HV: That buys us some time until we have to make that decision.
    • Action item: create that CBC override in staged-recipes.

  • (HV) Feedback to cache: CEP?

    • WV: Reusing the same build struct as in the regular output, but only script is used. Should only some build.* keys be allowed?
    • WV: Automatic injection or not?
      • JRG: If automatic, users should be able to override with cache: false or something.
    • WV: Last rattler-build release includes the latest draft of the cache feature, with cache-specific sources and workdir unpacking.
    • The rattler-build cache is immutable (it's regenerated for each output), which contrasts with conda-build's stateful global build directory. There was some discussion about the need for multi-stage caching or not (whether an output can modify the cache or not in a way that the following outputs see those changes). Consensus seems to be that single-stage is enough and we ever need multi-stage, we'll hear about it when we get there.

  • (KZ) Should we publish contributor statistics?

From previous meeting(s)​

  • [ ]

Active votes​

  • [ ]

Your __new__() agenda items​

  • [ ]

Pushed to next meeting​

  • [ ]

CFEPs​

  • [ ]