GNU bug report logs -
#45161
[PATCH 0/1] Update go?
Previous Next
Reported by: David Dashyan <mail <at> davie.li>
Date: Thu, 10 Dec 2020 15:12:02 UTC
Severity: normal
Tags: patch
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45161 in the body.
You can then email your comments to 45161 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Thu, 10 Dec 2020 15:12:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
David Dashyan <mail <at> davie.li>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Thu, 10 Dec 2020 15:12:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Thu, 10 Dec 2020 15:19:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 45161 <at> debbugs.gnu.org (full text, mbox):
---
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 <at> gnu.org>
;;; Copyright © 2020 raingloom <raingloom <at> riseup.net>
;;; Copyright © 2020 Martin Becze <mjbecze <at> riseup.net>
+;;; Copyright © 2020 David Dashyan <mail <at> 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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Thu, 10 Dec 2020 17:14:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 45161 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Thu, 10 Dec 2020 17:38:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 45161 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Thu, 10 Dec 2020 17:44:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 45161 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Fri, 11 Dec 2020 06:16:01 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Fri, 11 Dec 2020 06:16:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Sat, 12 Dec 2020 22:52:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 45161 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Sun, 13 Dec 2020 21:35:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 45161 <at> debbugs.gnu.org (full text, mbox):
---
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 <at> gnu.org>
;;; Copyright © 2020 raingloom <raingloom <at> riseup.net>
;;; Copyright © 2020 Martin Becze <mjbecze <at> riseup.net>
+;;; Copyright © 2020 David Dashyan <mail <at> 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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Sun, 13 Dec 2020 21:35:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 45161 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Sun, 13 Dec 2020 21:58:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 45161 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Mon, 14 Dec 2020 13:11:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 45161 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Mon, 14 Dec 2020 21:55:01 GMT)
Full text and
rfc822 format available.
Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#45161
; Package
guix-patches
.
(Mon, 14 Dec 2020 21:55:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
45161 <at> debbugs.gnu.org and David Dashyan <mail <at> davie.li>
Request was from
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 05 Aug 2021 16:57:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 03 Sep 2021 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 228 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.