[bug#45161] [PATCH 0/1] Update go?

[bug#45161] [PATCH 0/1] Update go?

[David Dashyan]

Yesterday I found packages that won't compile with curent guix's
go-1.14. Apparently 1.15 is the "stable" thing today.

I've updated go package locally but when I try to run './pre-inst-env guix
build --rounds=3 go' guix just spits out currently installed go-1.14 store
directories.  Am I right that this is not how it should work?  It supposed to
find the modified version in source tree, right?

When I do ./pre-inst-env guile - I see local wortree in front of %load-path
tho. Strange.

But I've tested it ;) builds and works.

Additional test file in 'for-each delete' is required for the reasons stated
in the comment above.

David Dashyan (1):
  gnu: Update go

 gnu/packages/golang.scm | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)


base-commit: 0faef871784f4f88e622dd36b492f020387f7a5e
-- 
2.29.2

[bug#45161] [PATCH 1/1] gnu: Update go

[David Dashyan]

---
 gnu/packages/golang.scm | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 3b42bf3c8f..e367eb4d16 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -23,6 +23,7 @@
 ;;; Copyright © 2020 Marius Bakke <marius@gnu.org>
 ;;; Copyright © 2020 raingloom <raingloom@riseup.net>
 ;;; Copyright © 2020 Martin Becze <mjbecze@riseup.net>
+;;; Copyright © 2020 David Dashyan <mail@davie.li>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -230,11 +231,11 @@ in the style of communicating sequential processes (@dfn{CSP}).")
     (supported-systems '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux"))
     (license license:bsd-3)))
 
-(define-public go-1.14
+(define-public go-1.15
   (package
     (inherit go-1.4)
     (name "go")
-    (version "1.14.10")
+    (version "1.15.6")
     (source
      (origin
        (method git-fetch)
@@ -244,7 +245,7 @@ in the style of communicating sequential processes (@dfn{CSP}).")
        (file-name (git-file-name name version))
        (sha256
         (base32
-         "0h1nmqzjc0xxpn6n2hjq7692gdqkznagzdmiq9490yzkrrii2lgk"))))
+         "0pg811lfw1pdp0cba4jvsqbwjaqrqz6m7jspbc80r17snd7flk2z"))))
     (arguments
      (substitute-keyword-arguments (package-arguments go-1.4)
        ((#:system system)
@@ -277,7 +278,8 @@ in the style of communicating sequential processes (@dfn{CSP}).")
                  ;; not find object files/headers despite being present.
                  (for-each
                   delete-file
-                  '("cmd/go/testdata/script/mod_case_cgo.txt"
+                  '("cmd/go/testdata/script/ldflag.txt"
+                    "cmd/go/testdata/script/mod_case_cgo.txt"
                     "cmd/go/testdata/script/list_find.txt"
                     "cmd/go/testdata/script/list_compiled_imports.txt"
                     "cmd/go/testdata/script/cgo_syso_issue29253.txt"
-- 
2.29.2

[bug#45161] [PATCH 0/1] Update go?

[Jack Hill]

David,

On Thu, 10 Dec 2020, David Dashyan wrote:

> Yesterday I found packages that won't compile with curent guix's
> go-1.14. Apparently 1.15 is the "stable" thing today.

Awesome, thanks for working on this!

> I've updated go package locally but when I try to run './pre-inst-env guix
> build --rounds=3 go' guix just spits out currently installed go-1.14 store
> directories.  Am I right that this is not how it should work?  It supposed to
> find the modified version in source tree, right?

I think this is because the go still points at 1.14, see the following 
definition:

> (define-public go go-1.14)

We should probably update that so 1.15 is the new default version.

> But I've tested it ;) builds and works.

I've started testing it locally. I'll report back if I notice anything.

Best,
Jack

[bug#45161] [PATCH 0/1] Update go?

[Leo Famulari]

On Thu, Dec 10, 2020 at 06:10:24PM +0300, David Dashyan wrote:
> Yesterday I found packages that won't compile with curent guix's
> go-1.14. Apparently 1.15 is the "stable" thing today.

The Go policy is to support 2 major releases. Since 1.15 is the current
major release, that means that 1.14 is still supported upstream. So
please keep 1.14 unless we don't need it anymore. For example, if no
Guix packages require it. That means ensuring that all the existing Go
packages build successfully... or that there is no new breakage :)

https://golang.org/doc/devel/release.html#policy

[bug#45161] [PATCH 1/1] gnu: Update go

[Leo Famulari]

On Thu, Dec 10, 2020 at 06:17:55PM +0300, David Dashyan wrote:
> -(define-public go-1.14
> +(define-public go-1.15
>    (package
>      (inherit go-1.4)
>      (name "go")
> -    (version "1.14.10")
> +    (version "1.15.6")

Thanks! I'm doing some tests now. As Jack said, we'll need to update the
'go' package as well in order for this to take effect.

Depending on whether or not the Go packages work with 1.15, we might
need to keep 1.14 around for a while.

For example, check out a Git worktree at commit
18199da4b79ce79d5002c3290cc1fa95454d92ce (gnu: Add Go 1.12.)

In that commit, we added 1.12 but kept 1.11 as the default Go compiler.

$ git worktree add /tmp/guix-multiple-go-compilers 18199da4b79ce79d5002c3290cc1fa95454d92ce && cd /tmp/guix-multiple-go-compilers

[bug#45161] [PATCH 0/1] Update go?

[Jack Hill]

On Thu, 10 Dec 2020, Leo Famulari wrote:

> On Thu, Dec 10, 2020 at 06:10:24PM +0300, David Dashyan wrote:
>> Yesterday I found packages that won't compile with curent guix's
>> go-1.14. Apparently 1.15 is the "stable" thing today.
>
> The Go policy is to support 2 major releases. Since 1.15 is the current
> major release, that means that 1.14 is still supported upstream. So
> please keep 1.14 unless we don't need it anymore. For example, if no
> Guix packages require it. That means ensuring that all the existing Go
> packages build successfully... or that there is no new breakage :)

I've tested go 1.15 by trying to build the packages reported by `guix 
refresh -l go` on x86_64. There are some new build failures, but it 
doesn't look too bad. In fact, I've already fixed on of them, by updating 
go-github-com-kr-pretty in #45171 [0]. There were a number of packages 
whose tests failed because of changes [1] to `go vet`. The new kr-pretty 
release adjusts to the new vet behavior with a one line change [2] 
(kr-pretty had fortunately not fallen into the incorrect string() usage 
for which vet is now warning).

[0] https://issues.guix.gnu.org/45171
[1] https://golang.org/doc/go1.15#vet
[2] https://github.com/kr/pretty/compare/v0.2.0...v0.2.1

The other new build failures are:

go-etcd-io-bbolt
syncthing
restic
go-github-com-emicklei-go-restful
docker
go-github-com-magiconair-properties

I was unable to test at least

chezmoi
exercism
syncthing-gtk

because they depend on a package that failed to build.

fiano-fmap [3] and mongo-tools [4] continue to fail to build.

[3] https://issues.guix.gnu.org/45172
[4] https://issues.guix.gnu.org/39637

Best,
Jack

[bug#45161] [PATCH 0/1] Update go?

[Jack Hill]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On Fri, 11 Dec 2020, Jack Hill wrote:

> The other new build failures are:

[…]

> go-github-com-magiconair-properties

Updating go-github-com-magiconair-properties to 1.8.4 solves the problem. 
I've sent a patch in #45216

[0] https://issues.guix.gnu.org/45216

Best,
Jack

[bug#45161] [PATCH 1/1] gnu: Update go

[David Dashyan]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]


Hello Jack and Leo!

Thank you for review and for picking it up :)

As suggested senditng the patch adding go-1.15 but keeping go-1.14.

-- 
David aka zzappie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#45161] [PATCH] gnu: Add go-1.15

[David Dashyan]

---
 gnu/packages/golang.scm | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 3b42bf3c8f..a4e62d7d6b 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -23,6 +23,7 @@
 ;;; Copyright © 2020 Marius Bakke <marius@gnu.org>
 ;;; Copyright © 2020 raingloom <raingloom@riseup.net>
 ;;; Copyright © 2020 Martin Becze <mjbecze@riseup.net>
+;;; Copyright © 2020 David Dashyan <mail@davie.li>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -434,6 +435,29 @@ in the style of communicating sequential processes (@dfn{CSP}).")
        ,@(package-native-inputs go-1.4)))
     (supported-systems %supported-systems)))
 
+(define-public go-1.15
+  (package
+    (inherit go-1.14)
+    (name "go")
+    (version "1.15.6")
+    (source
+     (origin
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://github.com/golang/go")
+             (commit (string-append "go" version))))
+       (file-name (git-file-name name version))
+       (sha256
+        (base32
+         "0pg811lfw1pdp0cba4jvsqbwjaqrqz6m7jspbc80r17snd7flk2z"))))
+    (arguments
+     (substitute-keyword-arguments (package-arguments go-1.14)
+       ((#:phases phases)
+        `(modify-phases ,phases
+           (add-after 'prebuild 'postprebuild
+             (lambda* (#:key inputs outputs #:allow-other-keys)
+               (delete-file "cmd/go/testdata/script/ldflag.txt")))))))))
+
 (define-public go go-1.14)
 
 (define-public go-github-com-alsm-ioprogress

base-commit: 11c3744275de591b74f761d126667ab81b0efcee
-- 
2.29.2

[bug#45161] [PATCH 0/1] Update go?

[David Dashyan]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]


Hello again!

Jack Hill writes:

> I've tested go 1.15 by trying to build the packages reported by `guix refresh -l
> go` on x86_64. There are some new build failures, but it doesn't look too
> bad. In fact, I've already fixed on of them, by updating go-github-com-kr-pretty
> in #45171 [0]. There were a number of packages whose tests failed because of
> changes [1] to `go vet`. The new kr-pretty release adjusts to the new vet
> behavior with a one line change [2] (kr-pretty had fortunately not fallen into
> the incorrect string() usage for which vet is now warning).

May I ask how do you do afterer redefining "go" to point to go-1.15 and
getting list of deppending packages?  I mean how one buids all depended
packages in one move if there such a way to do this?

-- 
David aka zzappie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#45161] [PATCH 0/1] Update go?

[David Dashyan]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]


David writes:

> May I ask how do you do afterer redefining "go" to point to go-1.15 and
> getting list of deppending packages?  I mean how one buids all depended
> packages in one move if there such a way to do this?
Oops.  It should have been something like:

  "what do you do after redefining "go" package and getting list of
  depending packages?  I mean how one buids all packages that depend on
  go in one move if there such a way to do this?"

It was late I was sleepy :)

-- 
David aka zzappie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#45161] [PATCH 0/1] Update go?

[Jack Hill]

On Mon, 14 Dec 2020, David Dashyan wrote:

>
> Hello again!
>
> Jack Hill writes:
>
>> I've tested go 1.15 by trying to build the packages reported by `guix refresh -l
>> go` on x86_64. There are some new build failures, but it doesn't look too
>> bad. In fact, I've already fixed on of them, by updating go-github-com-kr-pretty
>> in #45171 [0]. There were a number of packages whose tests failed because of
>> changes [1] to `go vet`. The new kr-pretty release adjusts to the new vet
>> behavior with a one line change [2] (kr-pretty had fortunately not fallen into
>> the incorrect string() usage for which vet is now warning).
>
> May I ask how do you do afterer redefining "go" to point to go-1.15 and
> getting list of deppending packages?  I mean how one buids all depended
> packages in one move if there such a way to do this?

Sure. For me it involved some manual effort. There might be a more clever 
way to script it that others can share, but I didn't think it was too bad, 
and it allowed me to make notes about what problems I observed as I 
encountered them. Nothing I did was Go-specific. Perhaps a small project 
for another time, we could add a cookbook recipe for testing upgrades to 
languages or other packages with many dependents.

Here's what I did after changing the default go:

* ran `./pre-inst-env guix refresh -l go` and recorded the list of 
packages to build.

* ran `./pre-inst-env guix build` with that list.

* After a while there is a build failure, and the end of the log looks 
like (the actually failure here is unimportant):

```
FAIL	go.etcd.io/bbolt	600.127s
FAIL
command "go" "test" "go.etcd.io/bbolt" failed with status 1

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
builder for `/gnu/store/6dshsgwryfj8g27sf24sp7lhnpf639d1-go-etcd-io-bbolt-1.3.5.drv' failed with exit code 1
@ build-failed /gnu/store/6dshsgwryfj8g27sf24sp7lhnpf639d1-go-etcd-io-bbolt-1.3.5.drv - 1 builder for `/gnu/store/6dshsgwryfj8g27sf24sp7lhnpf639d1-go-etcd-io-bbolt-1.3.5.drv' failed with exit code 1
derivation '/gnu/store/6dshsgwryfj8g27sf24sp7lhnpf639d1-go-etcd-io-bbolt-1.3.5.drv' offloaded to 'libre-02.local' failed: build of `/gnu/store/6dshsgwryfj8g27sf24sp7lhnpf639d1-go-etcd-io-bbolt-1.3.5.drv' failed
build of /gnu/store/6dshsgwryfj8g27sf24sp7lhnpf639d1-go-etcd-io-bbolt-1.3.5.drv failed
View build log at '/var/log/guix/drvs/6d/shsgwryfj8g27sf24sp7lhnpf639d1-go-etcd-io-bbolt-1.3.5.drv.bz2'.
cannot build derivation `/gnu/store/23jx3gb17gdhz662d3dsrmfnpp92abw4-chezmoi-1.8.1.drv': 1 dependencies couldn't be built
guix build: error: build of `/gnu/store/23jx3gb17gdhz662d3dsrmfnpp92abw4-chezmoi-1.8.1.drv' failed
```

* From this, I make a not the go-etcd-io-bbolt has a build failure, and 
that I was unable to attempt chezmoi.

* I remove chezmoi from the list of packages to build and re-run `guix 
build`.

Repeat that process until all the remaining packages build, and you should 
have a nice list of build failures and builds that could not be attempted.

Hope that helps,
Jack