Since version 2.0.0, proc-macro-crate has assumed it can exec()
`env::var("CARGO")` in order to run `cargo locate-project`.

This commit adds a crate override to proc-macro-crate which simply writes the
path to buildPlatform.cargo into the proc-macro-crate sources.

This way we don't need to set `env.CARGO` for every build that depends on
proc-macro-crate -- if we do that, the $CARGO environment variable would be
visible to the entire build.  This could potentially lead to incredibly
hard-to-troubleshoot heisenbugs if there is some other crate that expects
`env::var("CARGO")` to exist -- that other crate would mysteriously work only
in projects that use proc-macro-crate but not anywhere else!
---
 pkgs/build-support/rust/default-crate-overrides.nix | 13 +++++++++++++
[message trimmed]

Sorry about that, will resend.

  - a

Quoting Florian Klink (2024-08-22 01:45:43)
> Hey,
> 
> On Mon, Aug 19, 2024 at 10:57:03AM GMT, Adam Joseph wrote:
> >Since version 2.0.0, proc-macro-crate has assumed it can exec()
> >`env::var("CARGO")` in order to run `cargo locate-project`.
> >
> >This commit adds a crate override to proc-macro-crate which simply writes the
> >path to buildPlatform.cargo into the proc-macro-crate sources.
> >

Since version 2.0.0, proc-macro-crate has assumed it can exec()
`env::var("CARGO")` in order to run `cargo locate-project`.

This commit adds a crate override to proc-macro-crate which simply writes the
path to buildPlatform.cargo into the proc-macro-crate sources.

This way we don't need to set `env.CARGO` for every build that depends on
proc-macro-crate -- if we do that, the $CARGO environment variable would be
visible to the entire build.  This could potentially lead to incredibly
hard-to-troubleshoot heisenbugs if there is some other crate that expects
`env::var("CARGO")` to exist -- that other crate would mysteriously work only
in projects that use proc-macro-crate but not anywhere else!

This commit is required in order to build Arti (Tor in rust) using crate2nix.
[message trimmed]

@shortwavesurfer2009 and @Kreyren requested this package:

  https://github.com/NixOS/nixpkgs/issues/293842

Since I am still blissfully free of a github account, I'll let them carry this
one across the finish line.

The two patches below implement this request completely, for both the bare
"haveno" package as well as the currently-operating haveno-reto instance (which
is still on 1.0.9 at the moment).  The built package syncs up correctly to both
the monero network as well as the haveno-reto network (over Tor in both cases).

Nixpkgs users can now easily compile haveno (and haveno-reto) for themselves
(`--option substituters ""`) instead of having to trust binaries of questionable

---
 pkgs/by-name/ha/haveno-reto/deps.json   | 1544 +++++++++++++++++++++++
 pkgs/by-name/ha/haveno-reto/deps.json-  | 1544 +++++++++++++++++++++++
 pkgs/by-name/ha/haveno-reto/package.nix |   33 +
 3 files changed, 3121 insertions(+)
 create mode 100644 pkgs/by-name/ha/haveno-reto/deps.json
 create mode 100644 pkgs/by-name/ha/haveno-reto/deps.json-
 create mode 100644 pkgs/by-name/ha/haveno-reto/package.nix

diff --git a/pkgs/by-name/ha/haveno-reto/deps.json b/pkgs/by-name/ha/haveno-reto/deps.json
new file mode 100644
index 000000000000..51b45628d4cc
--- /dev/null
+++ b/pkgs/by-name/ha/haveno-reto/deps.json
[message trimmed]

---
 pkgs/by-name/ha/haveno/package.nix | 158 +++++++++++++++++++++++++++++
 1 file changed, 158 insertions(+)
 create mode 100644 pkgs/by-name/ha/haveno/package.nix

diff --git a/pkgs/by-name/ha/haveno/package.nix b/pkgs/by-name/ha/haveno/package.nix
new file mode 100644
index 000000000000..34e962cbd8a9
--- /dev/null
+++ b/pkgs/by-name/ha/haveno/package.nix
@@ -0,0 +1,158 @@
+{ lib
+, stdenv
+, pkgs
[message trimmed]

Quoting Florian Klink (2024-07-25 02:41:04)
> https://github.com/NixOS/nixpkgs/pull/329863

Thank you flokli!!

  - a

When a dependency references a github *release* URL, that dependency must be
fetched using https rather than git, since github does not require that
release tarballs have any relationship whatsoever to the git history.

This commit causes them to be fetched using https, not git.

A test case (which fails prior to this commit, and passes afterwards) is included.
---
 pkgs/build-support/node/fetch-yarn-deps/index.js         | 9 ++++++---
 .../build-support/node/fetch-yarn-deps/tests/default.nix | 4 ++++
 .../node/fetch-yarn-deps/tests/github-release.lock       | 6 ++++++
 3 files changed, 16 insertions(+), 3 deletions(-)
 create mode 100644 pkgs/build-support/node/fetch-yarn-deps/tests/github-release.lock
[message trimmed]

When the hash of an url being fetched does not match the expected value, this
commit will cause fetch-yarn-deps to include the url in the error message to
assist debugging.
---
 pkgs/build-support/node/fetch-yarn-deps/index.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pkgs/build-support/node/fetch-yarn-deps/index.js b/pkgs/build-support/node/fetch-yarn-deps/index.js
index e60fdeb54330..91e3d1014661 100755
--- a/pkgs/build-support/node/fetch-yarn-deps/index.js
+++ b/pkgs/build-support/node/fetch-yarn-deps/index.js
@@ -39,7 +39,7 @@ const downloadFileHttps = (fileName, url, expectedHash, hashType = 'sha1') => {
 				const h = hash.read()
 				if (expectedHash === undefined){
[message trimmed]

Quoting Florian Klink (2024-04-19 01:23:23)
> >Note this still causes a lot of rebuilds, probably due to the move of
> >gobject-introspection (?).
> >Are you OK with this simply targeting staging?

Yes of course; sorry about the slow reply.

> As the patches started to not apply anymore, I manually rebased this
> on staging, and sent it out (modulo some formatter fixes) to
> https://github.com/NixOS/nixpkgs/pull/305260.
>
> I'll undraft this PR once I finished building.

I see that you did, and that it was merged.  Thank you so much!