Build 8.1.1 release candidate

[peastman]

Checklist

• Used a personal fork of the feedstock to propose changes
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)

[conda-forge-webservices]

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

I was trying to look for recipes to lint for you, but it appears we have a merge conflict.
Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[conda-forge-webservices]

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) and found it was in an excellent condition.

[peastman]

@conda-forge-admin, please rerender

[peastman]

@jakirkham I merged this PR, but there's no sign of it building the packages. I did an empty push to rc to try to force it, but still nothing.

[jakirkham]

Weird. Not sure why that happened. Manually started a new CI build

[peastman]

Thanks! Unfortunately, all the builds are failing when trying to solve the environment.

The reported errors are:
- Encountered problems while solving:
-   - nothing provides requested cuda-nvcc_linux-64 11.8.*

[jakirkham]

If I look at this CI build, which fails, it points to this variant file

Looking at the cuda_compiler above it show it as nvcc, which it should as it is CUDA 11 (not cuda-nvcc as used by CUDA 12 or in the error message). This appears to be the case for the rest of the variants as well

Is something else setting cuda_compiler later? Could we try re-rendering with the latest changes again?

[peastman]

How do I do that? Just create a new empty PR and tell it to rerender?

[jakirkham]

Interestingly this CI build passes though the values are exactly the same as the previous variant (both as would be expected for CUDA 11.8)

[jakirkham]

Thanks for letting me know Peter! 🙏

There are certainly a lot of failures that look rather odd, but it also appears there are quite a few builds that pass

What is particularly unusual is the failures are mostly with Linux x86_64 on CUDA 11.8 where cuda_compiler appears to be set as nvcc, which should result in using nvcc_linux-64, but instead we see cuda-nvcc_linux-64. Am not sure where that setting is coming from if not the variant files. Have noted a failing and passing build for Linux x86_64 on CUDA 11.8 above. Both set cuda_compiler to nvcc so both shouldn't see the issue (yet they do)

Somewhere cuda_compiler is changing to cuda-nvcc. Not entirely sure where that would be if not the variant files

[jakirkham]

cc @jaimergp (in case you have any insights on what is happening here)

[peastman]

Possibly I made a mistake in manually resolving all the conflicts between the main and rc branches? There were a lot of them, and it took quite a long time. But the build passed before I merged the PR. (Question for @jaimergp: is it really necessary to have separate main and rc branches? It means a painful manual merge every time we switch between them.)

Since those are all generated files, can we just tell it to regenerate them without changing anything else?

[isuruf]

Yes, it was an issue with your manual merge and push. This is why we require everything to be done in PRs instead of pushing to branches manually.

[peastman]

I did do it through a PR, and the build succeeded on the PR.

I created a new PR at #125 to force it to rerender.

[isuruf]

No, you pushed f132dc2 without a PR

[isuruf]

That git commit was the problematic one

[peastman]

That's because it failed to build when I merged the PR. The instructions @jaimergp wrote up said that if it fails to build, the solution is to force it with a direct push to the branch. If there's a better way of doing it, I'd love to know what it is.

[isuruf]

Only use a empty commit and push if the builds don't start. Do not make any functional changes outside of a PR.

[peastman]

I didn't make any functional changes outside the PR. My intent was to use an empty commit. But like I said above, every time we switch branches we end up with a horrible manual merge that is very difficult to do correctly. That's why I'm asking whether there's a way to avoid having to do that?