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
opensm: 3.3.20 -> 3.3.21 #47732
opensm: 3.3.20 -> 3.3.21 #47732
Conversation
Old git source repository was dead. Switched to GitHub
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: opensm Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: opensm Partial log (click to expand)
|
@@ -16,6 +17,8 @@ stdenv.mkDerivation rec { | |||
|
|||
preConfigure = "bash ./autogen.sh"; |
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 sure if this might be a source of problems but this could be simpler:
preConfigure = "./autogen.sh"
Let it be run in the current build env (sandboxed) with the current shell.
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.
It should not cause problems but I agree that it is unnecessary.
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.
Won't patchShebangs
patch it to use bash from the target env instead of the build/native env?
I would expect the bash
on the path during the build (preConfigure) to be the one from the build env. Is it not?
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.
You mean in a cross compilation environment? That is a good point. I am not sure how that would be handled. The manual does not mention this case (?) Using patchShebangs
to patch the build environment is rather common though. In some cases there are bunch of scripts, such that patchShebangs
seems to be the obvious choice to fix the build env.
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's done in plenty of packages.
At the moment the source states:
This setup hook [...] rewrite(s) all script interpreter file names to paths found in $PATH
Seems safe to use it that way.
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.
@c0bw3b I am still curious what would actually happen in a cross environment. nativeBuildInputs
and buildInputs
determine what should be run time and what should be pure build time dependency. These parts should be clear then. However, bash
is part of the build env, such that the fixupPhase
would write a bash
into scripts that belongs to the build env instead the target env?
I am sure nix has some magic going on that fixes it correctly but it is not obvious to me.
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.
The build env is sandboxed but still using a bash from the nix store, I'm guessing?
I'm not well-versed in cross-compilation matters but I see that one commit on patch-shebangs.sh
to address cross-compile was then reverted.
In any way the nix function patchShebangs
will "mask" the complexity and decide what to do when cross-compiling or not.
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.
Aha
This setup hook causes the fixup phase to rewrite all script
[...]
`newPath="$(command -v "$(basename "$oldPath")" || true)"
So, as is, it should be fine to use for patching build scripts.
When executed during the fixup phase (in the target env), it will patch to use the target env, but when executed during preConfigure (in the build env), it will actually patch to use the build env.
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.
There is the nix magic! Thanks for digging into it.
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: opensm Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: opensm Partial log (click to expand)
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: opensm Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: opensm Partial log (click to expand)
|
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.
LGTM
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.
LGTM
@domenkozar @rbvermaa @edolstra https://discourse.nixos.org/t/the-best-way-to-attract-attention-to-issues-and-pull-requests/1130/14 — giving @markuskowa commit access is indeed a good idea. |
Motivation for this change
Old git source repository was dead. Switched to GitHub. Update to new version.
CC @aij
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)