| Message ID | 20201210151024.25316-1-mail@davie.li |
|---|---|
| Headers | show |
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
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
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
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
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 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 :)
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