Work around broken conda 26.5.3 _1 rebuild breaking the conda package CI build#2982
Closed
antonwolfy wants to merge 1 commit into
Closed
Work around broken conda 26.5.3 _1 rebuild breaking the conda package CI build#2982antonwolfy wants to merge 1 commit into
antonwolfy wants to merge 1 commit into
Conversation
antonwolfy
marked this pull request as ready for review
July 1, 2026 11:42
antonwolfy
requested review from
ndgrigorian and
vlad-perevezentsev
as code owners
July 1, 2026 11:42
Contributor
|
View rendered docs @ https://intelpython.github.io/dpnp/index.html |
Collaborator
|
coverage: 78.073%. remained the same — pin-conda-to-avoid-installing-faulty-build into master |
Contributor
|
Array API standard conformance tests for dpnp=0.21.0dev2=py313h509198e_7 ran successfully. |
ndgrigorian
approved these changes
Jul 1, 2026
Contributor
Author
|
The issue is resolved by conda-forge |
antonwolfy
added a commit
that referenced
this pull request
Jul 8, 2026
…ensor` on Windows (#2993) Re-land of #2984. That PR was a stacked PR targeting the intermediate branch `pin-conda-to-avoid-installing-faulty-build`, whose own PR (#2982) was **closed, not merged**. As a result, #2984 was merged into that dead intermediate branch and its changes never reached `master`. GitHub won't allow reopening a merged PR, so this re-lands the identical change directly against `master`. This is a follow-up to #2856 and #2770. The `dpnp.tensor` target never got the same `SYSTEM` treatment, so it was the one target still leaking these warnings. The Windows conda build produced a flood of `-Wdeprecated-declarations` warnings (hundreds of thousands of lines in the CI log). All of them originate inside the DPC++/SYCL headers themselves (`.../Library/include/sycl/...`) — none come from dpnp's own sources — so they are out of dpnp's control and are pure noise. They came exclusively from the `dpnp.tensor` `_tensor_*_impl` pybind11 modules built in `dpnp/tensor/CMakeLists.txt`. In the `dpnp/tensor` target loop, split the include directories so dpnp's own headers stay `PRIVATE`, and the third-party headers (`SYCL_INCLUDE_DIR`, `Dpctl_INCLUDE_DIR`, generated Cython headers) are added as `SYSTEM PRIVATE`, mirroring the pattern established in #2770 for the `backend/extensions/*` targets.
github-actions Bot
added a commit
that referenced
this pull request
Jul 8, 2026
…ensor` on Windows (#2993) Re-land of #2984. That PR was a stacked PR targeting the intermediate branch `pin-conda-to-avoid-installing-faulty-build`, whose own PR (#2982) was **closed, not merged**. As a result, #2984 was merged into that dead intermediate branch and its changes never reached `master`. GitHub won't allow reopening a merged PR, so this re-lands the identical change directly against `master`. This is a follow-up to #2856 and #2770. The `dpnp.tensor` target never got the same `SYSTEM` treatment, so it was the one target still leaking these warnings. The Windows conda build produced a flood of `-Wdeprecated-declarations` warnings (hundreds of thousands of lines in the CI log). All of them originate inside the DPC++/SYCL headers themselves (`.../Library/include/sycl/...`) — none come from dpnp's own sources — so they are out of dpnp's control and are pure noise. They came exclusively from the `dpnp.tensor` `_tensor_*_impl` pybind11 modules built in `dpnp/tensor/CMakeLists.txt`. In the `dpnp/tensor` target loop, split the include directories so dpnp's own headers stay `PRIVATE`, and the third-party headers (`SYCL_INCLUDE_DIR`, `Dpctl_INCLUDE_DIR`, generated Cython headers) are added as `SYSTEM PRIVATE`, mirroring the pattern established in #2770 for the `backend/extensions/*` targets. 6671952
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The "Conda package" CI job started failing with:
conda-forgerebuiltconda 26.5.3as build_1. The_1package ships thebin/condaentry point with a#!/usr/bin/env pythonshebang instead of the previous prefix-relocated#!<env>/bin/python.The
conda-recipe/build.shcallsconda list '^sysroot_linux-64$'(to derive the glibc version for the manylinux wheel tag). That runs inside conda-build's host sandbox, where the sandbox'spython— which does not contain thecondamodule — is first onPATH. With the old shebang this was fine (conda used its own env's python); with the_1shebang it resolves to the sandboxpython and fails with
ModuleNotFoundError: No module named 'conda'.Reported upstream:
conda-forge/conda-feedstock#304.
This PR pins
condato the known-good build_0in the build environment spec.