Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

For the reasoning behind c7f5973, see discussion here. The preceding commit fails if a feedstock would override c_stdlib_version, see also this branch where I've tested this for an affected feedstock.

c7f5973 would thus be necessary to make the docker image (sufficiently) independent from c_stdlib_version, so that they can be set independently (if indeed this is something we desire to enable; one reason why is that the image version doesn't have to affect the sysroot-baseline, in particular if it's only for being able to load a build tool or test dependency).

@jakirkham, you mentioned in the core call just now that all the CUDA feedstocks already set os_version explicitly? In only did a spot check and it looks like this for example:

os_version:
  linux_64: cos7
  linux_aarch64: cos7
  linux_ppc64le: cos7

Following conda-forge/docker-images#291 (using the consolidated names that allow choosing the distro version), this would eventually have to move to

os_version:
  linux_64: cos7
  linux_aarch64: ubi8
  linux_ppc64le: ubi8

or just

os_version:
  linux_64: cos7

because we don't/won't support distro overrides for aarch/ppc. In either case, once we've confirmed that we got os_version set in the relevant feedstocks doing binary repackaging, this PR should be ready. I'll leave out the image renaming stuff for #6687

once we've confirmed that we got os_version set in the relevant feedstocks doing binary repackaging, this PR should be ready.

@jakirkham do you have a list of cuda-related feedstocks that I can double-check?

Gentle ping @jakirkham

Thanks Axel! 🙏

Please don't feel obliged to track or make these changes. This is something NVIDIA plans to pick up. In fact folks are eager to adopt these changes once available

There is not one comprehensive list as there are the CUDA Toolkit (CTK) packages, CUDA Math libraries, CUDA DL libraries, etc. Plus more packages are being added

That said, for the CUDA Toolkit packages we handled this work as part of issue ( conda-forge/cuda-feedstock#26 ), this has a list of CTK feedstocks that had this change included

Other NVIDIA feedstocks have been encouraged to follow the same pattern

Please don't feel obliged to track or make these changes. This is something NVIDIA plans to pick up. In fact folks are eager to adopt these changes once available

I agree that this makes sense, but in the last core call the ask had been to commit os_version: ... into the binary repackaging feedstocks before switching. That would currently be a no-op, so we could even just push them with a [ci skip]. I'm willing to do that (or help), but I don't have a list of feedstocks (well, except perhaps searching for "cuda" in our feedstock names).

The issue link above hopefully answers that question. Admittedly not comprehensively, but that is pretty close

Will look for other cases we may have missed and file issues

Thank you! 🙏

Found a few stragglers. Have put together a list in this comment: conda-forge/cuda-feedstock#28 (comment)

Will start working through those. Also will update the list if we find more

Your list is correct as of this PR, but I think it'd actually be better to pull in the changes from conda-forge/docker-images#293 / #6687 into this PR. I'll update conda-forge/docker-images#291 to finish the rest of the necessary changes.

I have thought about the fact that only a single value of os_version can be used per platform, and how to handle the split between different distros between CUDA 11.8 and the rest. I'll push some changes to this effect momentarily. The result would look as follows (not counting the cross-compilation split for cuda 11.8)

For wrong values of os_version, we could add something like the following,

  # intentional breakage for unsupported values of DEFAULT_LINUX_VERSION
  - quay.io/condaforge/this_image_does_not_exist    # [linux and os.environ.get("DEFAULT_LINUX_VERSION", "alma9") not in ("cos7", "ubi8", "alma8", "alma9")]
  - quay.io/condaforge/this_image_does_not_exist    # [linux and os.environ.get("DEFAULT_LINUX_VERSION", "alma9") not in ("cos7", "ubi8", "alma8", "alma9")]

but arguably, failed renders are hard to debug, so IMO this should rather be a linter rule in smithy

OK, conda-forge/docker-images#291 was merged and I've tested it on the faiss feedstock with several variations of cos7 / ubi8 / alma8 / alma9, and it did the right thing in all those cases (compare table above).

In other words, this PR should be ready. :)

I'll write up the announcement that John asked for shortly.

so IMO this should rather be a linter rule in smithy

I started implementing this in smithy, but ran into conda-forge/conda-smithy#2152, which we should very likely solve first.

I have a smithy PR for a linter rule now: conda-forge/conda-smithy#2155

Thanks Axel! 🙏

Opened a couple of test PRs

Was able to re-render ok

Though did see some issues pulling the Docker images. Were the images from PR ( conda-forge/docker-images#291 ) pushed ok? Or are there some naming changes that still need to be picked up here?

• [NO MRG, TST] Try alma8 & c_stdlib_version: 2.28 (CUDA 11/12) nccl-feedstock#120 (comment)
• [NO MRG, TST] Try alma8 & c_stdlib_version: 2.28 zlib-feedstock#87 (comment)

Thanks for testing! 🙏

Though did see some issues pulling the Docker images. Were the images from PR ( conda-forge/docker-images#291 ) pushed ok? Or are there some naming changes that still need to be picked up here?

I had double-checked the CI runs there, and aside from being green, the deploy step looks normal too. Not sure what could be causing the

+ docker pull quay.io/condaforge/linux-anvil-x86_64:alma8
Error response from daemon: unauthorized: access to the requested resource is not authorized

you're seeing.

Default setting for new images on quay.io is private. Made them public just now.

Ah right 😅

Thanks Isuru! 🙏

Remembered there was something on Quay.io that needed an extra tweak. Had forgotten exactly what it was

Restarted the failed CI runs in those test PRs

Looks like both of those builds passed! 🥳

Also looks like the recent work on changing the cdt_name to conda in PR ( conda-forge/conda-forge-ci-setup-feedstock#365 ) has fixed CUDA cross-compilation on Alma 8 (am guessing Alma 9 would work similarly)

@conda-forge/core, this should be ready to go and I'd welcome reviews. 🙏

It's been tested both by me and by @jakirkham, and covers what we discussed in the core call (c.f. #6283 & conda-forge/docker-images#293)

To accompany this, I also have an announcement (as suggested by John) and a doc update ready. A linter rule for the distrotags in os_version is waiting for some dependent work and will follow soon, but we don't need to wait for that here.