An error occurred fetching the project authors.
  1. 02 Feb, 2020 1 commit
    • Jérome Perrin's avatar
      component/golang: set gcc's path in workspace's PATH · 4b832215
      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]
      4b832215
  2. 01 Oct, 2019 1 commit
  3. 30 Aug, 2019 1 commit
  4. 19 Jul, 2019 1 commit
  5. 26 Jun, 2019 1 commit
  6. 26 Apr, 2019 1 commit
  7. 11 Apr, 2019 1 commit
  8. 14 Mar, 2019 1 commit
  9. 22 Jan, 2019 1 commit
    • Kirill Smelkov's avatar
      golang: v↑ to go1.11 · 36f105cd
      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
      36f105cd
  10. 07 Nov, 2018 1 commit
  11. 29 Oct, 2018 1 commit
    • Kirill Smelkov's avatar
      golang: Don't require users to put \ into gowork.install · 754acb1b
      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
      754acb1b
  12. 17 Sep, 2018 1 commit
  13. 09 Aug, 2018 1 commit
  14. 26 Mar, 2018 1 commit
    • Kirill Smelkov's avatar
      golang: Hook-in pkg-config for Cgo support · df7db445
      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.
      df7db445
  15. 08 Feb, 2018 1 commit
    • Kirill Smelkov's avatar
      golang: v↑ (1.9.4, 1.8.7) · 668984a6
      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
      668984a6
  16. 29 Jan, 2018 1 commit
    • Kirill Smelkov's avatar
      golang: Allow users to specify desired buildflags · 831271a2
      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
      831271a2
  17. 25 Jan, 2018 1 commit
  18. 05 Nov, 2017 1 commit
  19. 27 Oct, 2017 1 commit
  20. 25 Oct, 2017 1 commit
  21. 23 Oct, 2017 1 commit
    • Kirill Smelkov's avatar
      golang: Infrastructure to build Go workspaces / projects · 1b540151
      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
      1b540151
  22. 11 Oct, 2017 1 commit
  23. 10 Oct, 2017 2 commits
  24. 22 Feb, 2017 2 commits
  25. 19 Jul, 2016 1 commit
  26. 06 Jul, 2016 2 commits
  27. 17 Jan, 2016 1 commit
  28. 04 Dec, 2015 1 commit
  29. 03 Nov, 2015 1 commit
    • Kirill Smelkov's avatar
      Go component · f7db20a7
      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
      f7db20a7