-
-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
setuptools-rust-hook: Use correct python for cross #262123
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not to fit on cross things but looks logical to me
Has to target staging |
I changed the target to staging. |
The ofborg-eval failure doesn't look related to this PR. |
@ofborg eval |
1 similar comment
@ofborg eval |
Gotta force-push Do |
09803f6
to
4285520
Compare
I cherry-picked this back to
Is there something in Also, note that |
It's this #228139
is the fault of #211340 |
@kjeremy do you have binfmt enabled?
|
Could work around it by doing
The hook for the wrong host is dragging in the python to nativeBuildInputs via propagation but that shouldn't be the issue. Currently building on staging with no binfmt to see if there's something missing on master |
Eeeew.
Can we just move all the python hooks out of Also I think the |
@Artturin |
Not sure what the right fix is here. |
We probably need to deal with #263019 first. Or at least implement some kind of warning if unspliced dependencies get used. Otherwise it's extremely difficult to understand what's actually going on. When unspliced dependencies get into the mix, |
Rebase on and then run
you will get
So, those are the bugs we need to fix. |
In order to avoid setting off the unspliced-dependency check, we need to make sure that the targetPackages.stdenv.cc.bintools used by gcc gets spliced. In order for it to be spliced, it needs a top-level entry in all-packages.nix. Therefore, this commit adds one. This also causes us to stop abusing targetPackages to access the linker, which is a good thing.
This commit adds a `lib.warn` check to stdenv.mkDerivation, causing it to emit a warning if a dependency which ought to be spliced in fact is not.
Co-authored-by: Artturi <[email protected]>
…s in buildInputs" This reverts commit 0899b6b8746790eec9dc49ea4f4a6c3def072e3b.
@kjeremy can you do the fix noticed in the comment before this one? |
4285520
to
bf46f5e
Compare
@SuperSandro2000 I've rebased and did a force push |
!(list-of-shame ? ${approximate-pname}) | ||
) | ||
|
||
# Hi there! If you're reading this, it's probably |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be way easier to read and a lot less lines if we'd wrote one setence per line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it would be but that's part of #263082. I feel like if that got merged it would force us to address the cross-compilation issues.
cryptography seems to build for me now |
Description of changes
Sets
PYO3_PYTHON
according to https://pyo3.rs/v0.20.0/building_and_distribution#cross-compilingSetting
PYO3_INCLUDE_DIR
doesn't seem to be necessary for fixing #262073 but I set it for good measure.Fixes #262073
@Artturin
@Cynerd
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)