Open l-monninger opened 1 month ago
I'm getting a FOD hash mismatch error. Are you sure things are up to date? Maybe the Cargo.lock
is out of date?
error: hash mismatch in fixed-output derivation '/nix/store/a76g3p1ph5aljw2v8qkyiz28b5qm3xm7-aptos-core-e9b4212.drv':
specified: sha256-53ObE7yoEMuZWjIAXXAm4hDBBKU1VhgEj/Zc9EQ4MBA=
got: sha256-uT/HGPsUhYDrOp4/fhRiRh5Jmi48zHLw7n9tR6Iupdo=
EDIT: I ran this without cloning using the following, so let me know if I should clone it instead (though it shouldn't matter)
nix build 'github:movementlabsxyz/movement?branch=nix-issue/rustBuildPackage#m1-da-light-node' -L
The thing is that I can build the project with cargo build
. So Cargo.lock must be fine
Why is there both a cargoSha256
and a cargoLock
in your derivation? Since cargoSha256
is incompatible with git dependencies you should remove it. Your ed22519-dalek
patch to the git version is in the [[patch.unused]]
section in your Cargo.lock
your lockfile still uses the non-git version of ed25519
in it's actual [[package]]
section. Did you really run cargo update
on that repo? It should warn you if your patch isn't used at all.
The rest of the derivation is also weird.
buildPhase
? Especially cargo clean
should not be necessary and all cargo
commands should include a --frozen
. I think you should remove your buildPhase
alltogether.pkg-config
twice in your buildInputs
? It's only invoked at compile time for package discovery and thus belongs into nativeBuildInputs
and should not be in buildInputs
at all.I think the derivation is seriously messed up.
EDIT:
I was to curious on that error and it's just terrible code....
ed25519-dalek
crates.io patch is unused.outputHashes
for multiple dependencies were out of date.nativeBuildInputs
wasn't used where appropriate.buildPhase
was seriously broken. After I rewrote/fixed the nix/m1-da-light-node.nix
in that project I've gotten to this error:
Compiling move-prover v0.1.0 (https://github.com/movementlabsxyz/aptos-core?rev=e9b42128f8ed51e90d06beec72d32797693ab66c#e9b42128)
error: couldn't read /build/cargo-vendor-dir/move-prover-0.1.0/src/../../../../aptos-move/framework/src/aptos-natives.bpl: No such file or directory (os error 2)
--> /build/cargo-vendor-dir/move-prover-0.1.0/src/cli.rs:774:33
|
774 | template_bytes: include_bytes!(
| _________________________________^
775 | | "../../../../aptos-move/framework/src/aptos-natives.bpl"
776 | | )
| |_________________^
|
= note: this error originates in the macro `include_bytes` (in Nightly builds, run with -Z macro-backtrace for more info)
error: could not compile `move-prover` (lib) due to 1 previous error
And that is definitely an error in that move-prover
crate. move-prover
is part of the git repo of aptos-core
but isn't part of any workspace. This causes cargo vendor
to vendor it by itself, but the include_bytes!
directive is written in a way that expects the move-prover
crate to be part of that aptos-core
git repo. Running cargo build
without the vendoring step builds move-prover
as part of the original repo and thus works by accident.
This isn't a bug with Nix. It's just a little curious behaviour in cargo vendor
.
Here's the patch I've used to get to that error: fix-nix-files.patch.txt
Yeah, that's the error! Thanks for taking a closer look!
We had hypothesized that this was because of a source filter being applied to vendored dependencies. I believe @andyjsbell had actually found the particular spot in Crane where that appeared to occur. But, if this is down to Cargo Vendor behavior, that would make sense and prevent us running that fools errand.
I'm going to leave open until I have time to confirm.
Describe the bug
When using build
buildRustPackage
to build a crate that has a git dependency which usesinclude_bytes
, the dependency fails to compile.Ostensibly, this is a consequence of some setup in
buildRustPackage
.Steps To Reproduce
Steps to reproduce the behavior:
nix-issue/rustBuildPackage
(sorry for the naming)nix --extra-experimental-features "nix-command flakes" --option filter-syscalls false build '.#m1-da-light-node
Note: I have overwritten
buildPhase
to counteract file writability issues which I was initially under the impressionbuildRustPackage
would handle.Expected behavior
I would expect deps using
include_bytes
to compile without error if they would in other environments.Notify maintainers
@dasJ
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result.Add a :+1: reaction to issues you find important.