Closed regro-cf-autotick-bot closed 11 months ago
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.
Build is failing because the windows build scripts needs logic to change the target CUDA archs per CUDA toolkit version.
Hi! This is the friendly conda-forge automerge bot!
Commits were made to this PR after the automerge
label was added. For security reasons, I have disabled automerge by removing the automerge
label. Please add the automerge
label again (or ask a maintainer to do so) if you'd like to enable automerge again!
The link checker seems to think that libcudart is missing from the run requirements on Windows. The Windows cudart run export is missing maybe?
It should be there
We did spot a conda-build warning here ( https://github.com/conda-forge/cuda-cudart-feedstock/issues/13 ). Though hadn't settled on a fix. The library is provided for. So it is really a question of what is the right way to ensure conda-build doesn't raise the warning
Are we turning that warning into an error in this feedstock?
Are we turning that warning into an error in this feedstock?
Yes. The warning is promoted to an error somehow, so the build fails.
Looks like conda-forge.yml
sets conda_build
's error_overlinking
, which would cause this behavior:
We could turn that off
Alternatively could add build/overlinking_ignore_patterns
to ignore specific instances
@carterbox would be curious to hear your thoughts on the options above 🙂
I'm reluctant to disable overlinking warnings/errors. I'd rather wait until the cudart packages for Windows are adapted to account for the Windows-platform's different capabilities/behavior or the missing symbolic link is added to the cudart package.
I'm not in a hurry to merge this PR since pytorch hasn't been built for Windows in quite some time, and this package is already build for every other plaform that supports CUDA 12.
Would just note that what conda-build is complaining about is a layer of indirection done to be compatible with the cross-compilation structure
The library is there. It is just within cuda-cudart_win-64
, which cuda-cudart
depends on. As opposed to in cuda-cudart
directly
Think the other benefit in completing libmagma
would be to allow the migrator to handle all the PyTorch dependencies, which are still waiting for Linux CUDA 12 builds
Maybe if we are not comfortable with one of the options above and merging, we should consider closing this PR and revisiting at a later time
@conda-forge-admin, please rerender
Hi! This is the friendly conda-forge automerge bot!
I considered the following status checks when analyzing this PR:
Thus the PR was passing and merged! Have a great day!
Thanks Daniel! 🙏
Will follow up when we have a better resolution to issue: https://github.com/conda-forge/cuda-cudart-feedstock/issues/13
This PR has been triggered in an effort to update cuda120.
Notes and instructions for merging this PR:
Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.
Here are some more details about this specific migrator:
If this PR was opened in error or needs to be updated please add the
bot-rerun
label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase code>@<space/conda-forge-admin, please rerun bot in a PR comment to have theconda-forge-admin
add it for you.This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/6891353581, please use this URL for debugging.