Jack Hill <jackhill@jackhill.us> writes:

> Katherine,
>
> On Wed, 3 Jun 2020, Katherine Cox-Buday wrote:
>
>> There are too many dependent Go packages to test, but I compiled
>> syncthing which should be a reasonably representative test.
>
> Thanks for working on updating Go.
>
> I have rebuilt all the packages reported by `guix refresh -l go`. The
> three failures were stress-make, which was already broken (build log
> attached), mongodb-tools, which was already broken [0], and docker
> (build log attached).

You're welcome! Thanks for the review. I wish I had more time to
contribute to Guix.

I suppose I should have qualified my statement by saying there's too
many dependent Go packages for me to test. I should invest in a better
computer :)

> Reading through the Go release notes [1], the following change to the
> net/url package caught my eye:
>
>> When parsing of a URL fails (for example by Parse or
>> ParseRequestURI), the resulting Error message will now quote the
>> unparsable URL. This provides clearer structure and consistency with
>> other parsing errors.
>
> I think this could be the cause of the docker test failure. Should we
> patch docker or perhaps try to update it?

Spot on! I've updated docker and docker-cli. hyperledger-fabric depends
on docker-cli and also continues to build. I've attached a patch which
should supersede the prior patch. It updates go, docker, and docker-cli
atomically.

> Another item from the release notes about changes to the Go runtime:
>
>> A consequence of the implementation of preemption is that on Unix
>> systems, including Linux and macOS systems, programs built with Go
>> 1.14 will receive more signals than programs built with earlier
>> releases. This means that programs that use packages like syscall or
>> golang.org/x/sys/unix will see more slow system calls fail with
>> EINTR errors. Those programs will have to handle those errors in
>> some way, most likely looping to try the system call again. For more
>> information about this see man 7 signal for Linux systems or similar
>> documentation for other systems.
>
> I didn't notice any problems caused by this during package rebuilds
> and testing, but it sounds like something that could be difficult to
> write automated tests for, so we should probably be on the lookout for
> future problems at runtime.

Agreed.

> I'm happy to see that that the go modules changes didn't cause us any
> problems with this upgrade.

I believe 1.14 represents a stabilization of the modules feature, so I
would expect future updates to go smoothly as well.

> I am curious, why switch to using git-fetch?

`guix lint` now complains about downloading tarballs. I have also
recently seen some chatter on the mailing list about preferring this.