SBT installation issue for daml-on-fabric

It appears the exception is thrown in
src\main\java\com\daml\FabricContext.java

Line 229

private void runChannel(Collection<Peer> peers, LifecycleChaincodePackage lifecycleChaincodePackage {

...

catch (Exception) {
  debugOut("Caught an exception running Channel %s, fabChannel.getName());
 e.printStackTrace();
}

I also checked
~/daml-on-fabric/src/test/fixture/chaincode/src/github.com/daml_on_fabric/

but could only find vendor sub-directory with 1 empty file

NO_AUTO_COPYRIGHT

I believe the root cause here is the Docker build failure, i.e.

Get "https://proxy.golang.org/github.com/golang/protobuf/@v/v1.4.2.mod": EOF

My recommendation would be to check whether your corporate proxy allows you to connect to proxy.golang.com.

If I could find in the code where this get triggered then this will help me. I could change curl to curl -sSLk and that command will be allowed to go through the corporate proxy.

I just tested in this environment and
curl -sSLk "https://proxy.golang.org/github.com/golang/protobuf/@v/v1.4.2.mod"

returned

module GitHub - golang/protobuf: Go support for Google's protocol buffers

go 1.9

require (
GitHub - google/go-cmp: Package for comparing Go values in tests v0.4.0
protobuf module - google.golang.org/protobuf - Go Packages v1.23.0
)

1 Like

This log line may not come from curl; I’m not very familiar with the go ecosystem, but I wouldn’t be surprised if the download was done by a custom-built go dependency-management tool. I don’t have much context here but I would try two lines en enquiry if I had access to your system:

  1. If I could get access to the Dockerfile that fails to build, I would try to just add a few lines in it to set the env vars for proxying (http_proxy, HTTP_PROXY, https_proxy and HTTPS_PROXY, all with the same value) and hope the go tooling respects that.
  2. Look through the Docker documentation to see if maybe you can set this up at the Docker daemon level. You can’t be the first person that needs Docker to go through a proxy; maybe this can be set directly in the configuration of the Docker virtual network.

It’s been a long time since I had to deal with a corporate proxy so I’m a bit rusty on that front. I am not confident either of these approaches will solve the problem, but they’re the best options I can think of at this point.

1 Like