ethrun: init at 0.1.0

[dbrock]

Motivation for this change

The ethrun program is a dependency of some other Ethereum-related utilities. It is a relatively stable basic tool that changes infrequently.

https://github.com/dapphub/ethrun

Things done

• Tested using sandboxing
  (nix.useSandbox on NixOS,
  or option build-use-sandbox in nix.conf
  on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • Linux
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[mention-bot]

@dbrock, thanks for your PR! By analyzing the history of the files in this pull request, we identified @AndersonTorres, @jefdaj and @chris-martin to be potential reviewers.

[bennofs]

I got output path ‘/nix/store/f4cfq4cfig3j2i04rvqd3dirzfkq6451-ethrun-0.1.0-fetch’ has r:sha256 hash ‘0grf3gyxwcwrx06bmdx29ipnv332wiihbvpz774gwba6jbvhr5is’ when ‘14x8pbjgkz0g724lnvd9mi2alqd6fipjljw6xsraf9gqwijn1knq’ was expected when I tried to build this. Can you update the depsSha256 to 0grf3gyxwcwrx06bmdx29ipnv332wiihbvpz774gwba6jbvhr5is and see if it still builds for you?

[dbrock]

Looks like this wasn't deterministic after all. @mbrock has been working on trying to fix it but he seems to have run into some pretty deep hair-pulling problems relating to the Nix–Rust-industrial complex.

[mbrock]

It's pretty weird that there seem to be two different hashes. @bennofs and Travis both get the 0grf3 hash, but I and some other person on reddit get the 14x8p hash.

Beyond that problem is the problem that Rust packages with Cargo dependencies from GitHub don't work in the sandbox (I think).

[bennofs]

@mbrock They should work in the sandbox just fine. Nix does allow network access to derivations that specify the output hash beforehand (called fixed output derivations), which the fetch-deps derivation for rust packages does (this is why you get the "hash not deterministic" problem in the first case).

Did you build this against the master nixpkgs version? You can use this command to ensure that we both build exactly the same thing:

$  nix-build -I nixpkgs=https://github.com/dbrock/nixpkgs/archive/881595ac0325a5622aa02e1d078e98b450fa4496.tar.gz -E '(import <nixpkgs> { config = {}; }).ethrun'

[bennofs]

@mbrock I think the isssue is this: nix-community/nix-index#2 (comment)

[bennofs]

Ok, that hash difference was fixed in bd78749.

[mbrock]

Ok, interesting!

In my own investigations, I actually got this same error as on Hydra but only sometimes -- rerunning the exact same build (<up> <enter> in bash) would yield the basename: no operand error very roughly 50% of the time.

I didn't investigate further because I'm quite ignorant of exactly how Cargo works, and this seemed very mysterious.

[bennofs]

@mbrock I think the current rust infrastructure is broken in various ways. I'll try to replace it with a better one.

To be honest, I don't know how it even works correclty most of the time right now. Are you using sandboxed builds?