Help packaging go-ethereum 1.10.23, built with go 1.18

Help
1

I’m trying to bump the version in nixpkgs to 1.10.23 on nixpkgs/master

boring diff 
diff --git a/pkgs/applications/blockchains/go-ethereum/default.nix b/pkgs/applications/blockchains/go-ethereum/default.nix
index 7766158193d..20d63da39a1 100644
--- a/pkgs/applications/blockchains/go-ethereum/default.nix
+++ b/pkgs/applications/blockchains/go-ethereum/default.nix
@@ -9,16 +9,16 @@ let
 
 in buildGoModule rec {
   pname = "go-ethereum";
-  version = "1.10.21";
+  version = "1.10.23";
 
   src = fetchFromGitHub {
     owner = "ethereum";
     repo = pname;
     rev = "v${version}";
-    sha256 = "sha256-qaM1I3ytMZN+5v/Oj47n3Oc21Jk7DtjfWA/xDprbn/M=";
+    sha256 = "sha256-1fEmtbHKrjuyIVrGr/vTudZ99onkNjEMvyBJt4I8KK4=";
   };
 
-  vendorSha256 = "sha256-Dj+xN8lr98LJyYr2FwJ7yUIJkUeUrr1fkcbj4hShJI0=";
+  vendorSha256 = "sha256-ZO6KG0M4LXJUF1udpYMrjXlBefBbnzkK2CV87sRgUF4=";
 
   doCheck = false;

And the error I get is puzzling:

go-ethereum> # github.com/urfave/cli/v2
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:15:12: type parameter requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:15:29: type instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:15:44: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:25:18: type parameter requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:25:20: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:44:29: type instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:48:30: type instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:52:28: type instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:56:26: type instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:215:24: type parameter requires go1.18 or later (-lang was set to go1.16; check go.mod)
go-ethereum> vendor/github.com/urfave/cli/v2/sliceflag.go:56:26: too many errors

Note that the package builds fine when using buildGo117Module.

So this seems to be an issue with the fact that Go 1.18 introduces generics, the urfav/cli package uses them, but that somehow the nix build isn’t picking up or correctly exposing the go version, resulting in the build failing. Also note that the 1.16 version is probably a red herring, and that the go directive is simply missing somewhere, since:

As of the Go 1.17 release, if the go directive is missing, go 1.16 is assumed.

I am not sure if this error affects other packages built with 1.18.

Also note that upstream builds the package with go 1.18.5.

3

I built 1.10.23 without any issues using this:

gethPackage = go-ethereum.geth.overrideAttrs (old: rec {
  version = "1.10.23";
  src = pkgs.fetchFromGitHub {
    owner = "ethereum";
    repo = old.pname;
    rev = "v${version}";
    sha256 = "sha256-1fEmtbHKrjuyIVrGr/vTudZ99onkNjEMvyBJt4I8KK4=";
  };
});

Also, as far as I can tell the vendor SHA256 shouldn’t change.

And the go directive does exist in the go.mod and is set to 1.17:

4

@jakubgs you’re right, it was the updated vendor hash that somehow broke the build - although I don’t quite understand what, nor how to debug this.

Yes, but I wasn’t referring to the project’s go.mod, but to one of its dependencies’. Anyway, that was a red herring.

Thanks for the quick reply!

5

sha256-Dj+xN8lr98LJyYr2FwJ7yUIJkUeUrr1fkcbj4hShJI0= is the hash I get when building the vendor directory for 1.10.23 with Go 1.18, as well as building it with Go 1.17 – so I have absolutely no clue where you got sha256-ZO6KG0M4LXJUF1udpYMrjXlBefBbnzkK2CV87sRgUF4= hash from.

Do you happen to have a reproducible example where you get that hash?

6

The diff was handed to me as is by a coworker so I could debug the build, so no, I don’t know how they arrived at that hash, unfortunately! It must be a valid hash, for an existing version of the vendor dir, but not that one. Confusing!

7

If you happen to figure out what they were doing, I’d be interested in the answer :slight_smile: