An error occurred fetching the project authors.
- 02 Feb, 2020 1 commit
-
-
Jérome Perrin authored
It seems some programs can only be built by the same gcc than the one used to build golang itself. For example, when system gcc is gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, grafana-server fail to build with: /data/slappart11_testnode/cqg/inst/test0-0/tmp/shared/golang1.12/fbee59cfb3c995382cf70d409615aa54/pkg/tool/linux_amd64/link: running gcc failed: exit status 1 /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info /tmp/go-link-305363633/000000.o: file not recognized: File format not recognized collect2: error: ld returned 1 exit status Also generally, if we don't trust system gcc to build golang, we cannot trust it to build golang programs. The downside is that if components or software want to use a specifig golang version they have to set both golang= and the corresponding gcc-bin-directory= in their [gowork]
-
- 01 Oct, 2019 1 commit
-
-
Jérome Perrin authored
We'll use "go1.4-bootstrap-20171003.tar.gz, which contains the Go 1.4 source code plus accumulated fixes to keep the tools running on newer operating systems." as described in https://golang.org/doc/install/source#bootstrapFromSource (this archive contains the "time: Skip TestParseInLocation test." commit)
-
- 30 Aug, 2019 1 commit
-
-
Łukasz Nowak authored
-
- 19 Jul, 2019 1 commit
-
-
Łukasz Nowak authored
-
- 26 Jun, 2019 1 commit
-
-
Łukasz Nowak authored
It's released, let's use the newest version.
-
- 26 Apr, 2019 1 commit
-
-
Łukasz Nowak authored
It's released, let's use the newest version.
-
- 11 Apr, 2019 1 commit
-
-
Łukasz Nowak authored
Contains many bug fixes found since 1.12, see https://golang.org/doc/devel/release.html#go1.12.minor
-
- 14 Mar, 2019 1 commit
-
-
Łukasz Nowak authored
Do not change any defaults regarding 1.9, 1.10 and 1.11.
-
- 22 Jan, 2019 1 commit
-
-
Kirill Smelkov authored
Don't drop support for Go1.9, as, even though Go1.9 is no longer supported, software/gitlab depends on it. Our Go1.10.X is also too outdated, but I'm not touching it here neither. /cc @alain.takoudjou, @luke
-
- 07 Nov, 2018 1 commit
-
-
Jérome Perrin authored
When ld version is too old (Debian 7 comes with version 2.2 which is too old), golang testsuite fail with: binutils_test.go:237: SourceLine for main: expect [{main /tmp/hello.c 3}]; got [{main 0}] see also https://github.com/golang/go/issues/26584 We explicitly use gcc 8.2, but what we need is gcc > 5.5 because of https://github.com/golang/go/issues/24046 When 8.2 (or newer) becomes the default SlapOS gcc, there should be no problem in dropping the explicit version and using ${gcc:location} here.
-
- 29 Oct, 2018 1 commit
-
-
Kirill Smelkov authored
Previously it was required to put \ into multi-entry gowork.install, because the way it was processed was to directly pass it into bash command, and if \n were there the command was cut by bash and the trailing was considered as another command. We can avoid that by explicitly processing \n in gowork.install and translate it to just ' '. This helps people because now gowork.install becomes just a regular multiline buildout entry, similar e.g. to gowork.cpkgpath et all. Here is one example where it helps: jerome/slapos@95c45fe0 (comment 68408) /reviewed-by @jerome /reviewed-on nexedi/slapos!430
-
- 17 Sep, 2018 1 commit
-
-
Alain Takoudjou authored
-
- 09 Aug, 2018 1 commit
-
-
Kirill Smelkov authored
Drop support for Go 1.8; Add support for Go 1.10 and make it the default. It comes a bit late because previously we were hitting https://golang.org/issues/24285, and so have beeing waiting for nexedi/slapos.core!42 to be deployed there on slapos nodes everywhere. As of 9 Aug 2018 it seems that deployment has been completed. /reviewed-by @alain.takoudjou, @rafael. /reviewed-on nexedi/slapos!372
-
- 26 Mar, 2018 1 commit
-
-
Kirill Smelkov authored
The most convenient way to discover CFLAGS/LDFLAGS when building Cgo bits is via pkg-config: https://golang.org/cmd/cgo/ For this to work let's add pkg-config to be available there in gowork out of the box, and provide users with a way to specify which C packages they want to be there on gowork's $PKG_CONFIG_PATH, e.g. this way: [gowork] cpkgpath = ${sqlite3:location}/lib/pkgconfig ${zlib:location}/lib/pkgconfig In buildout sources cpkgpath is specified as multiline - not one line with ":" delimiters - with the idea that it should be easy to amend gowork.cpkgpath with "+=" in different places.
-
- 08 Feb, 2018 1 commit
-
-
Kirill Smelkov authored
Update go19 and go18 to their latest upstream versions bringing up bug and security fixes. Go19 tested briefly on neotest run. /reviewed-by TrustMe
-
- 29 Jan, 2018 1 commit
-
-
Kirill Smelkov authored
For example one could want to build the software with race detector, e.g. [gowork] ... buildflags = -race or if you want to build a plugin for fluent-bit [gowork] ... install = your.package.import.path buildflags = -buildmode=c-shared and then your package will be installed as shared library into ${gowork:directory}/pkg/`go env GOOS`_`go env GOARCH`/<your.package.import.path>.a One could pass that location explicitly to `fluentd-bit -e ...` or symlink to it from some .so from global directory of fluent-bit plugins. Maybe it is not very good to use `go install` for building plugins (instead of `go build -o ...`) but we anyway need to have ability to specify buildflags as a generic feature, hence this patch. /reviewed-on nexedi/slapos!274
-
- 25 Jan, 2018 1 commit
-
-
Kirill Smelkov authored
My mistake from 1b540151 (golang: Infrastructure to build Go workspaces / projects) /reviewed-by TrustMe
-
- 05 Nov, 2017 1 commit
-
-
Julien Muchembled authored
On some machines, net:TestDialTimeout never passes and today, Go 1.4 is only used for bootstrapping, so let's not be more clever than Go devs, who explicitly state to use make.bash See also https://github.com/golang/go/issues/18954
-
- 27 Oct, 2017 1 commit
-
-
Eteri authored
Version up for golang from go1.9.1 to go1.9.2 @rafael @kirr @alain.takoudjou [ kirr: from https://golang.org/doc/devel/release.html#go1.9.minor go1.9.2 (released 2017/10/25) includes fixes to the compiler, linker, runtime, documentation, go command, and the crypto/x509, database/sql, log, and net/smtp packages. It includes a fix to a bug introduced in Go 1.9.1 that broke go get of non-Git repositories under certain conditions. See the Go 1.9.2 milestone on our issue tracker for details. @gabriel says they tested go1.9.2 on Caddy ] /reviewed-on nexedi/slapos!247
-
- 25 Oct, 2017 1 commit
-
-
Alain Takoudjou authored
[golang14] fix TestParseInLocation test: Install package from latest changes on upstream go14 branch https://github.com/golang/go/commit/4d5426a570c2820c5894a61b52e3dc147e4e7925 golang14 is still failing to build on some server, the commit above fix the problem on test TestParseInLocation. This is why we install golang14 from upstream go14 branch. [ kirr: see also relateddiscussion on nexedi/slapos!133 ] /reviewed-by @kirr /reviewed-on nexedi/slapos!245
-
- 23 Oct, 2017 1 commit
-
-
Kirill Smelkov authored
In Go world development workflow is organized around so-called workspace where multiple packages can be installed / worked on etc. The following page describes Go workspaces: https://golang.org/doc/code.html A new [gowork] section and infrastructure around it is introduced. Quoting code: # gowork is a top-level section representing workspace # # users should add `install` field to [gowork] to describe packages they want to # be installed (+ automatically their dependencies are installed too). e.g. # # [gowork] # install = # lab.nexedi.com/kirr/neo/go/... \ # github.com/pkg/profile \ # golang.org/x/perf/cmd/benchstat The way it all works inside is: - gowork organizes to create go.work/ directory in buildout root - inside it creates env.sh which when sources in shell adjusts all paths so that appropriate go compiler is in path, GOPATH is also set appropriately, etc - in other words everything needs for using/working on this workspace is setup in the environment. - in actual user software profile the list of Go projects which needs to be installed by SlapOS has to be listed. The [gowork] machinery takes care about git-cloning these projects and `go install`s them after. - by SlapOS design builds have to be reproducible and so every component state/version has to be fixed. A convenient helper (gowork-snapshot) to get snapshot of git go packages installed with their exact revisions is added. This should be used to automatically (re-)generate list of go git repositories & their pinning for a workspace. For a new Go project that needs to be slaposified the workflow should be: - first get a project into working state via any convenient way (`go get`, etc.) - generate list of go packages & their pinning with gowork-snapshot - extend golang/buildout.cfg and in project software profile add [gowork] install = your-top-level-packages as it was outlined above. P.S. [golang] is removed because 1. it is not used anywhere in slapos.git tree, and 2. the canonical way to work on go projects from now on will be to use [gowork]. There latest go version is preconfigured, but users can override it to some particular other version in their projects as they need. /reviewed-on nexedi/slapos!242 /also-needed-for nexedi/slapos!243
-
- 11 Oct, 2017 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 10 Oct, 2017 2 commits
-
-
Alain Takoudjou authored
Go1.5 and go1.6 are not used anywhere in slapos tree and neither these versions are supported by upstream release policy https://golang.org/doc/devel/release.html#policy anymore. So let's remove them.
-
Alain Takoudjou authored
-
- 22 Feb, 2017 2 commits
-
-
Kirill Smelkov authored
1.8.X is current stable series of Go. https://golang.org/doc/go1.8 https://golang.org/doc/devel/release.html#go1.8 Besides many other significant improvements it should now also support ARM64. /cc @jp /reviewed-by TrustMe (tested on helloworld)
-
Kirill Smelkov authored
Otherwise it started to fail this way: [2017-02-22 11:49:22,982] INFO --- FAIL: TestLoadFixed (0.00s) [2017-02-22 11:49:22,982] INFO time_test.go:929: Now().In(loc).Zone() = "-01", -3600, want "GMT+1", -3600 [2017-02-22 11:49:22,983] INFO FAIL [2017-02-22 11:49:22,983] INFO FAIL time 2.380s See https://github.com/golang/go/issues/16352#issuecomment-255835099 and around for details.
-
- 19 Jul, 2016 1 commit
-
-
Kirill Smelkov authored
From upcoming https://golang.org/doc/devel/release.html#go1.6.minor go1.6.3 (released 2016/07/17) includes security fixes to the net/http/cgi package and net/http package when used in a CGI environment. This release also adds support for macOS Sierra. See the Go 1.6.3 milestone[1] on our issue tracker for details. [1] https://github.com/golang/go/issues?q=milestone%3AGo1.6.3 /reviewed-by TrustMe (tested with helloworld)
-
- 06 Jul, 2016 2 commits
-
-
Kirill Smelkov authored
1.6.X is current stable series of Go. https://golang.org/doc/go1.6 https://golang.org/doc/devel/release.html#go1.6 So switch helloweb and default golang to it. /reviewed-by TrustMe (tested on helloworld)
-
Kirill Smelkov authored
From https://golang.org/doc/devel/release.html#go1.5.minor: go1.5.4 (released 2016/04/12) includes two security fixes. It contains the same fixes as Go 1.6.1 and was released at the same time. See the Go 1.6.1 milestone[1] on our issue tracker for details. [1] https://github.com/golang/go/issues?q=milestone%3AGo1.6.1 /reviewed-by TrustMe (tested with helloworld)
-
- 17 Jan, 2016 1 commit
-
-
Kirill Smelkov authored
This is a security-bugfix release: From https://golang.org/doc/devel/release.html#go1.5.minor: go1.5.3 (released 2016/01/13) includes a security fix to the math/big package affecting the crypto/tls package. See the Go 1.5.3 milestone on our issue tracker[1] and the release announcement[2] for details. [1] https://github.com/golang/go/issues?q=milestone%3AGo1.5.3 [2] https://golang.org/s/go153announce I've rebuild helloworld software release and briefly tested helloweb.go with go 1.5.3 ok. /reviewed-by: TrustMe /cc @kazuhiko, !39
-
- 04 Dec, 2015 1 commit
-
-
Kirill Smelkov authored
From https://golang.org/doc/devel/release.html#go1.5.minor: go1.5.2 (released 2015/12/02) includes bug fixes to the compiler, linker, and the mime/multipart, net, and runtime packages /reviewed-by: TrustMe
-
- 03 Nov, 2015 1 commit
-
-
Kirill Smelkov authored
Add support for Go language in the form of providing component for Go toolchain and stdlib. Current Go stable series is 1.5.* but to bootstrap it one need to have Go 1.4.* available, which itself needs C compiler to bootstrap. We need Go support for upcoming GitLab SR, where one server is written in this language: https://gitlab.com/gitlab-org/gitlab-workhorse /cc @gabriel, @Camata
-