An error occurred fetching the project authors.
  1. 28 Dec, 2023 1 commit
  2. 31 Aug, 2023 1 commit
  3. 14 Aug, 2023 2 commits
  4. 11 Jan, 2023 1 commit
  5. 30 Dec, 2022 2 commits
    • Levin Zimmermann's avatar
      golang: Switch default to Go1.18 · d32524c3
      Levin Zimmermann authored
      Go1.18 is the next stable go release. There is already Go1.19
      (released 2022-08-02), but we incrementally increase versions.
      For Go1.18 there are already many bug fix releases (last one
      2022-12-06) which gives it a more stable/mature impression.
      
      /reviewed-on nexedi/slapos!1305
      d32524c3
    • Levin Zimmermann's avatar
      golang: Add go version 1.18 · b2a25a20
      Levin Zimmermann authored
      Go 1.18 is the incremental improvement for earlier go 1.17 release.
      Is "is a significant release, including changes to the language,
      implementation of the toolchain, runtime, and libraries". Please find
      all details in the official release note:
      
          https://go.dev/doc/go1.18
      
      It was released on 2022-03-15. Due to the go promise of compatibility
      most software should still compile without any problems.
      
      /reviewed-on nexedi/slapos!1305
      b2a25a20
  6. 20 Dec, 2022 1 commit
  7. 12 May, 2022 1 commit
    • Kirill Smelkov's avatar
      golang: Clean internal build cache after part is compiled/tested · 86a21a53
      Kirill Smelkov authored
      @tomo reports that parts/golang1.17/pkg/obj/go-build takes ~ 1GB which makes it
      wasteful if we want to upload result of compilation to shacache.
      
      It turns out we can drop that particular build cache completely, because it is
      used only during the build and test of Go itself and its standard library. And
      when Go is installed it will be another - "user" build cache - that will be
      used to maintain and reuse build artifacts. For the reference: in SlapOS that
      latter "user" build cache is located inside go.work/
      
      -> Purge internal build cache after compilation is over.
      
      Size of parts/golang1.17 before and after hereby patch:
      
      before: 1.6G
      after:  447M
      
      See also related discussion in nexedi/slapos!929 (comment 128379)
      
      /reviewed-by @tomo, @jerome
      /reviewed-on nexedi/slapos!1169
      86a21a53
  8. 28 Apr, 2022 1 commit
  9. 19 Jan, 2022 1 commit
  10. 18 Jan, 2022 1 commit
  11. 10 Dec, 2021 1 commit
    • Kirill Smelkov's avatar
      golang += patches to fix tests under user namespaces · 71ced145
      Kirill Smelkov authored
      If we enter user namespace via regular unshare without help from SUID
      newuidmap/newgidmap, all supplementary groups are mapped to -1. As the result
      when Go test tries to chown to a supplementary group, it gets EINVAL:
      
      https://github.com/golang/go/issues/42525
      
      -> work it around with patch to skip this chown tests.
      
      A more proper, longer-term fix would be to fix Linux kernel to allow writes to
      /proc/self/gid_map to setup mapping not only to original gid, but to all
      original supplementary groups as well here:
      
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/user_namespace.c?id=v5.16-rc4-0-g0fcfb00b28c0#n1143
      
      this fix, even if accepted by upstream, would be long to be waited for to
      propagate to distribution kernels that we currently use. So we go with this
      workaround for now.
      
      --------
      
      Another patch is to fix the following TestSCMCredentials failure:
      
          === RUN   TestSCMCredentials
              creds_test.go:81: WriteMsgUnix failed with invalid argument, want EPERM
          --- FAIL: TestSCMCredentials (0.00s)
      
      There the code tries to send uid0/gid0 credentials from non-zero uid and
      expects EPERM reject from kernel. However under `unshare -Umc` uid0/gid0 are
      not mapped to anywhere and so implicitly map to -1 and are rejected with EINVAL
      by the kernel.
      
      /reviewed-by @jerome
      /reviewed-on nexedi/slapos!1095
      71ced145
  12. 02 Dec, 2021 1 commit
  13. 12 Nov, 2021 1 commit
  14. 11 Nov, 2021 2 commits
  15. 10 Sep, 2021 3 commits
    • Kirill Smelkov's avatar
      golang: Build SWIG and include it into Go build environment · 762daa2c
      Kirill Smelkov authored
      Even if we don't use swig in our go projects, if hosting environment has
      swig, but incorrectly installed, then Go build will fail as:
      
         --- FAIL: TestScript (0.03s)
             --- FAIL: TestScript/list_swigcxx (0.46s)
                 script_test.go:252:
                     # go list should not report SWIG-generated C++ files in CompiledGoFiles. (0.001s)
                     # CompiledGoFiles should contain 4 files:
                     #  a.go
                     #  a.swigcxx.go
                     #  _cgo_gotypes.go
                     #  a.cgo1.go (0.421s)
                     > go list -f '{{.CompiledGoFiles}}' -compiled=true example/swig
                     [stdout]
                     []
                     [stderr]
                     # example/swig
                     :1: Error: Unable to find 'swig.swg'
                     :3: Error: Unable to find 'go.swg'
                     [exit status 2]
                     FAIL: testdata/script/list_swigcxx.txt:12: unexpected command failure
      
      Such broken environment, in particular, is present on our testnodes,
      because there swig program is being included into slapos-node package,
      slapos command includes it into $PATH for spawned programs
      
          https://lab.nexedi.com/nexedi/slapos/blob/99cf4bfd/component/slapos/buildout.cfg#L22-30
          https://lab.nexedi.com/nexedi/slapos/blob/99cf4bfd/component/slapos/buildout.cfg#L74-88
      
      but the swig binary itself is configured to look into its supporting files in
      the wrong place:
      
          slapuser91@vifibcloud-rapidspace-hosting-007:~/t/swig$ /opt/slapos/parts/swig/bin/swig -swiglib
          /usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10
      
          slapuser91@vifibcloud-rapidspace-hosting-007:~/t/swig$ ll /usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10
          ls: cannot access '/usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10': No such file or directory
      
      which leads to SWIG being broken:
      
          slapuser91@vifibcloud-rapidspace-hosting-007:~/t/swig$ /opt/slapos/parts/swig/bin/swig -v -go -intgosize 64 a.swigcxx
          Language subdirectory: go
          Search paths:
             ./
             ./swig_lib/go/
             /usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10/go/
             ./swig_lib/
             /usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10/
          Preprocessing...
          :1: Error: Unable to find 'swig.swg'
          :3: Error: Unable to find 'go.swg'
      
      -> Fix it by building SWIG ourselves and using that built swig to build go and
      in the Go environment provided to users.
      
      See "Troubleshooting" in http://www.swig.org/Release/README for details.
      
      /cc @luke, @jerome, @romain
      762daa2c
    • Kirill Smelkov's avatar
      golang: +go1.17 -go1.15 · 15e26abd
      Kirill Smelkov authored
      Go1.17 is incremental improvement over Go1.16 with better and faster compiler,
      runtime, module-mode improvements and faster generated code:
      
      https://blog.golang.org/go1.17
      https://golang.org/doc/go1.17
      
      Drop support for Go1.15, as that release reached EOL and nothing currently uses
      it in SlapOS.
      
      Don't drop support for Go1.12 yet, as that long-ago-EOL and no longer supported
      Go release is still being used by software/gitlab.
      
      Remain default at Go1.16 yet.
      
      Switch helloworld to Go1.17 and test this patch on that
      software-release.
      15e26abd
    • Kirill Smelkov's avatar
      golang: v↑ go1.16 (1.16.4 -> 1.16.8) · e43a96db
      Kirill Smelkov authored
      Going Go1.16.4 -> Go1.16.8 brings in fixes to compiler, runtime and stdlib
      including security fixes to net, crypto/tls, archive/zip, math/big, and
      net/http/httputil packages:
      
      https://golang.org/doc/devel/release.html#go1.16.minor
      
      Tested on helloworld SR.
      e43a96db
  16. 28 May, 2021 2 commits
  17. 07 Apr, 2021 2 commits
  18. 25 Mar, 2021 5 commits
  19. 10 Mar, 2021 3 commits
  20. 09 Mar, 2021 1 commit
  21. 02 Mar, 2021 3 commits
    • Kirill Smelkov's avatar
      golang: Go modules support; Prepare to deprecate GOPATH · 73ff1a8d
      Kirill Smelkov authored
      Add support for using Go modules to golang/gowork infrastructure:
      
      - Users can now request to install a module via gowork:install as. e.g.
        in the following example:
      
      	[gowork]
      	install =
      	    lab.nexedi.com/kirr/neo/go/...@v0.0.0-20210103165133-f3effa6c535f
      	    golang.org/x/tools/gopls@v0.4.3
      	    ${helloweb:location}/go:./...
      
        The first two request to install programs from an external module at particular
        revision/version. The latter requests to install programs from locally
        cloned/checked-out module source.
      
        The documentation now talks only about programs, because "package
        installation" became unnecessary long time ago as Go toolchain uses
        right packages and recompiles things as needed automatically since
        introduction of the Go build cache in go 1.10.
      
      - The change comes accompanied by corresponding helloweb change that
        reworks it to a) become a module itself, and b) to use other modules -
        that are not explicitly cloned by buildout - so that we can be sure
        that module way of fetching/building things actually works.
      
        kirr/helloweb@a7c788ae
      
      - Non-module way - e.g. build via GOPATH - is still supported (because
        e.g. software/gitlab still uses it), but not explicitly documented and
        scheduled to be deprecated and removed. The reason for this is that
        upstream Go is going to remove support for GOPATH and leave only
        module-based approach in Go1.17
      
        https://github.com/golang/go/issues/37755#issuecomment-771879911
      73ff1a8d
    • Kirill Smelkov's avatar
      golang: Make gowork.install optional · 0f72fe8c
      Kirill Smelkov authored
      Some software releases - e.g. wendelin.core - only use ${go:exe} and
      does not put anything into ${gowork:install}.
      0f72fe8c
    • Kirill Smelkov's avatar
      golang: Rework [gowork] documentation a bit · e2a4b391
      Kirill Smelkov authored
      Put emphasis on that gowork defines Go workspace and explain first
      settings that are related to that definition. Only after that say how to
      use gowork.install. The reason for this is that gowork.install will
      become optional in the next patch.
      e2a4b391
  22. 01 Mar, 2021 2 commits
    • Kirill Smelkov's avatar
      golang: Break future gowork ⇄ go-git-package cycle · e11efc27
      Kirill Smelkov authored
      Consider a Go package that is defined via go-git-package, for example
      
          [helloweb]
          <= go-git-package
          go.importpath = lab.nexedi.com/nexedi/helloweb
          repository    = https://lab.nexedi.com/nexedi/helloweb.git
      
      Currently, since go-git-package references ${gowork:src}, it creates
      helloweb -> gowork dependency. gowork, in turn, depends on
      gowork.goinstall, which gets list of things to install from ${gowork:install}.
      
      Currently we put only plain strings into ${gowork.install}, e.g.
      
          [gowork]
          install =
             lab.nexedi.com/nexedi/helloweb/go/...
      
      but for Go modules support and for properly expressing what depends on what,
      we'll want in the next patch to be able to specify something like
      
          [gowork]
          install =
             ${helloweb:location}/go:./...
      
      which will create helloweb ⇄ gowork cycle.
      
      Unfortunately buildout does not detect nor report an error for such cycles, and
      simply processes parts in an order, which leads to situation where e.g.
      helloweb was not yet cloned, but gowork.goinstall tries to `go install` it and
      complains "no such helloweb directory".
      
      -> Fix it by leaving gowork to use by component/golang/ users, and putting
      settings about where gowork directories is into underlying gowork.dir section.
      e11efc27
    • Kirill Smelkov's avatar
      golang: Prepare for future GOPATH removal · 8eac67a5
      Kirill Smelkov authored
      GOPATH is going to be removed in Go1.17 (see e.g. https://github.com/golang/go/issues/37755#issuecomment-771879911).
      
      -> Prevent programs suddenly become installed into $HOME/go/bin instead of
      gowork/bin, and mod cache to become something like $HOME/go/... instead of
      being kept under gowork/
      
      No change in behaviour for Go ≤ 1.16
      8eac67a5
  23. 26 Feb, 2021 2 commits