[-- Attachment #1: Type: text/plain, Size: 923 bytes --] Hi, for the past few days I have been wrestling with getting go lang to work on 9front (latest version) I have been referencing these guidelines: http://docs.9front.org/building-go here is a brief paste detailing what I did: https://dpaste.com/6D26TWPXA.txt go seems to run, go env and go version return their expected results. the problems come from actually trying to fetch things go get github.com/bwmarrin/discordgo go: golang.org/x/crypto@v0.0.0-20200622213623-75b288015ac9: Get "https://proxy.golang.org/golang.org/x/crypto/@v/v0.0.0-20200622213623-75b288015ac9.mod": x509: failed to load system roots and no roots provided; open /sys/lib/tls/ca.pem: '/sys/lib/tls/ca.pem' does not exist Seems to be a tls issue? There was supposedly a thread on the issue but it is gone and not in any archives that I know of... http://comments.gmane.org/gmane.os.plan9.general/74781 being the dead link [-- Attachment #2: Type: text/html, Size: 1922 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --] 9front nor go come with a CA certificate bundle. a certificate bundle that go can use can be downloaded at https://curl.haxx.se/docs/caextract.html. On Fri, Oct 23, 2020, 21:16 <nydldmcd2@mail.com> wrote: > Hi, for the past few days I have been wrestling with getting go lang to > work on 9front (latest version) > I have been referencing these guidelines: > http://docs.9front.org/building-go > > here is a brief paste detailing what I did: > https://dpaste.com/6D26TWPXA.txt > > go seems to run, go env and go version return their expected results. the > problems come from actually trying to fetch things > > go get github.com/bwmarrin/discordgo > go: golang.org/x/crypto@v0.0.0-20200622213623-75b288015ac9: Get "https://proxy.golang.org/golang.org/x/crypto/@v/v0.0.0-20200622213623-75b288015ac9.mod": x509: failed to load system roots and no roots provided; open /sys/lib/tls/ca.pem: '/sys/lib/tls/ca.pem' does not exist > > > Seems to be a tls issue? There was supposedly a thread on the issue but > it is gone and not in any archives that I know of... > http://comments.gmane.org/gmane.os.plan9.general/74781 being the dead link > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/T80ee3327f2f3dc57-M111deac6f99ad745a0a7e036> > [-- Attachment #2: Type: text/html, Size: 3350 bytes --]
[-- Attachment #1: Type: text/plain, Size: 408 bytes --] A second problem I am having seems to be related to git. I have the git shell script in bin/rc, and it is executable. git9 is installed, too. However ... go get github.com/henesy/disco go: missing Git command. See https://golang.org/s/gogetcmd package github.com/henesy/disco: exec: "git": executable file not found in $path I have both the git shell script (in bin/rc) and git9 installed, [-- Attachment #2: Type: text/html, Size: 727 bytes --]
[-- Attachment #1: Type: text/plain, Size: 542 bytes --] Since having the git rc script in either /bin/amd64, $home/bin or $home/bin/rc didnt work i just had it put it in the same directory that i was running go get from it results in this ... term% go get github.com/henesy/disco # cd .; git clone -- https://github.com/henesy/disco /usr/glenda/go/src/github.com/henesy/disco rc: git:2: syntax error package github.com/henesy/disco: exit status: 'git 569: syntax error' Do I have the wrong git? I compared this rc git wrapper to the one found on 9legacy and it looks the same. [-- Attachment #2: Type: text/html, Size: 938 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --] it probably doesn't work with newer go as it isn't well maintained. there is no replacement for real git right now. a contribution to git9 to do this would be welcome. On Fri, Oct 23, 2020, 22:33 <nydldmcd2@mail.com> wrote: > Since having the git rc script in either /bin/amd64, $home/bin or > $home/bin/rc didnt work > i just had it put it in the same directory that i was running go get from > it results in this ... > > term% go get github.com/henesy/disco > # cd .; git clone -- https://github.com/henesy/disco /usr/glenda/go/src/ > github.com/henesy/disco > rc: git:2: syntax error > package github.com/henesy/disco: exit status: 'git 569: syntax error' > > Do I have the wrong git? I compared this rc git wrapper to the one found > on 9legacy and it looks the same. > > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/T80ee3327f2f3dc57-M662e84a2602304b2c0303ace> > [-- Attachment #2: Type: text/html, Size: 2398 bytes --]
Try git9's git/compat instead of standalone rc script. It still seems to be work in progress, but as it's actual stated purpose is for go get, maybe it will work for you.
You don't need git. Try this:
% GO111MODULE=on go get github.com/henesy/disco
On Sat, Oct 24, 2020 at 1:32 AM <nydldmcd2@mail.com> wrote:
>
> Since having the git rc script in either /bin/amd64, $home/bin or $home/bin/rc didnt work
> i just had it put it in the same directory that i was running go get from
> it results in this ...
>
> term% go get github.com/henesy/disco
> # cd .; git clone -- https://github.com/henesy/disco /usr/glenda/go/src/github.com/henesy/disco
> rc: git:2: syntax error
> package github.com/henesy/disco: exit status: 'git 569: syntax error'
>
> Do I have the wrong git? I compared this rc git wrapper to the one found on 9legacy and it looks the same.
>
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink
> Try git9's git/compat instead of standalone rc script. It still
> seems to be work in progress, but as it's actual stated purpose is
> for go get, maybe it will work for you.
I just tried the repo in question. Git/compat was broken with
it, so I fixed it.
And, yes -- 'git/compat' is definitely a work in progress,
so patches are welcome. Thanks to halfwit for stepping up
to the plate and writing it.
For the curious, here's what was going wrong:
- go get calls 'git submodule init' unconditionally, and
git/compat barfed even if there were no submodules. Now
it treats it as a no-op if there are no submodules, and
only barfs when it needs to. (Making it handle submodules
would be even better!)
- git/fetch had a bug parsing offset deltas, which is why
they weren't enabled.
- googlesource.com's git server is buggy. It ignores the
capabilities I sent, and generates offset deltas, so
I fixed the bug in the implementation.
[-- Attachment #1: Type: text/plain, Size: 96 bytes --] http://sprunge.us/3hcWI4 Is my go outdated or something? I cannot get a single project to work. [-- Attachment #2: Type: text/html, Size: 200 bytes --]
> hget http://sprunge.us/3hcWI4
The first error message is:
../go/pkg/mod/github.com/henesy/disco@v0.0.0-20200313024015-ff90b1ac381a/config.go:4:2: package bufio is not in GOROOT (/sys/lib/go/amd64-1.15.2/src/bufio)
That's telling you that it's attempting to rebuild some of the go library.
(Don't ask why. Rather than use something understandably deterministic like mk,
the go authors have opted for an inference engine to detect "staleness",
which, in my experience, can trigger a recompile of the entire library
when something apparently innocent is touched.)
Does the source directory it's mentioning exist, and have .go files in it?
Do you have write permission in the $GOROOT/pkg tree?
Giving your go build cache a good clean might help. Or it might break
everything completely, so make a backup first.
On Wed, Oct 28, 2020, at 9:46 AM, Richard Miller wrote:
>
> That's telling you that it's attempting to rebuild some of the go library.
> (Don't ask why. Rather than use something understandably deterministic like mk,
> the go authors have opted for an inference engine to detect "staleness",
> which, in my experience, can trigger a recompile of the entire library
> when something apparently innocent is touched.)
Ugh! Didn't it formerly use mk? Just yesterday, I recalled my ancient notion of forking an early version of the language and calling it Stop. ;) If I liked the language, I might have done it already, (and the switch to a non-deterministic builder would be a likely trigger,) but then I am a little crazy.
> non-deterministic builder It's probably not non-deterministic. It's just unpredictable (to me) because the rules are encoded in the logic of 'go build' rather than being visibly exposed as mk patterns. I suspect I'm not the only one who doesn't find the staleness algorithm predictable, as evidenced by the number of times 'go tool dist test' for a single package repeatedly tries to rebuild the toolchain and standard library and hen re-check for staleness, even when invoked with '-no-rebuild'. See https://github.com/golang/go/issues/24300
On Wed, Oct 28, 2020, at 1:08 PM, Richard Miller wrote:
> > non-deterministic builder
>
> It's probably not non-deterministic. It's just unpredictable (to me)
> because the rules are encoded in the logic of 'go build' rather than
> being visibly exposed as mk patterns.
I understand, but I'm sure it would seem unpredictable to me too. Such apparent unpredictability bothers my brain when I'm trying to concentrate. A compiler unexpectedly taking the time to rebuild the entire toolchain in the middle of an edit-test-debug cycle would be a little too much for me personally.
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --] @Richard Miller I had installed go following http://docs.9front.org/building-go I do have permissions to the $GOROOT tree. And other than the go binary I do not see any go files under src. Would I even have a cache considering i've never successfully built a go project yet? term% cd $GOROOT term% pwd /sys/lib/go/amd64-1.15.2 term% touch test.t term% ls src src/Make.dist src/README.vendor src/all.bash src/all.bat src/all.rc src/archive src/bootstrap.bash src/bufio src/buildall.bash src/builtin src/bytes src/clean.bash src/clean.bat src/clean.rc src/cmd src/cmp.bash src/compress src/container src/context src/crypto src/database src/debug src/encoding src/errors src/expvar src/flag src/fmt src/go src/go.mod src/go.sum src/hash src/html src/image src/index src/internal src/io src/iostest.bash src/log src/make.bash src/make.bat src/make.rc src/math src/mime src/net src/os src/path src/plugin src/race.bash src/race.bat src/reflect src/regexp src/run.bash src/run.bat src/run.rc src/runtime src/sort src/strconv src/strings src/sync src/syscall src/testdata src/testing src/text src/time src/unicode src/unsafe src/vendor [-- Attachment #2: Type: text/html, Size: 1790 bytes --]
> I had installed go following > http://docs.9front.org/building-go Those instructions don't actually install go into /sys/lib/go/amd64-1.15.2 They install go into /tmp/go, which is then bound dynamically onto /sys/lib/go/amd64-1.15.2 This has two consequences: - every time you run go, you must first ensure that /tmp/go is bound onto $GOROOT in the current process environment - your /tmp had better not be too temporary (some people use ramfs to mount /tmp as an in-memory filesystem) I think it would be safer to install go into the actual /sys/lib tree, or (eg if you're on a shared system without write permission in /sys/lib), into your home directory and add the relevant bind command to your $home/lib/profile > And other than the go binary I do not see any go files under src. The .go files are in subdirectories. 'du -a $GOROOT/src' should show at least 4000 of them. > Would I even have a cache considering i've never successfully built a go project yet? Installing go by building from source will cache lots of stuff in $home/lib/cache/go-build.
[-- Attachment #1: Type: text/plain, Size: 386 bytes --] I see now. This has two consequences: - every time you run go, you must first ensure that /tmp/go is bound onto $GOROOT in the current process environment - your /tmp had better not be too temporary (some people use ramfs to mount /tmp as an in-memory filesystem) This was the issue. I re-ran those binds, and go projects work now. I will install it properly now [-- Attachment #2: Type: text/html, Size: 1253 bytes --]
> I see now.
> This has two consequences:
> - every time you run go, you must first ensure that /tmp/go is bound onto
> $GOROOT in the current process environment
> - your /tmp had better not be too temporary (some people use ramfs to mount
> /tmp as an in-memory filesystem)
> This was the issue.
>
> I re-ran those binds, and go projects work now.
>
> I will install it properly now
Yeah -- those instructions weren't good -- /tmp is not a place
to store things. Moody has fixed them (thanks).
[-- Attachment #1: Type: text/plain, Size: 335 bytes --] I was able to solve the same issue with hget https://curl.se/ca/cacert-2021-01-19.pem >/sys/lib/tls/ca.pem ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T80ee3327f2f3dc57-M36366bde4c34815f3b04b988 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 1282 bytes --]