Our solution to this was, against advice otherwise, to put go.sum in
.gitignore and to rev all the co-dependent modules together
simultaneously. As you said, it *was* really unpleasant. In the 3 days
since I posted I've since had to do it again.
Is there a "Go modules therapy group" (or at le
We had a similar issue last year due to some problem with a corporate proxy.
You might refer to https://github.com/golang/vscode-go/issues
And test to see if your problem is related to your proxies.
On Monday, March 1, 2021 at 5:21:52 PM UTC-6 oldCoderException wrote:
> Hi everyone,
>
> I've be
Hi everyone,
I've been working with our senior sysadmin guy here, trying to understand
some other troubles that I'm having in implementing Go modules in
conjunction with VSCode using the gopls extension. As I mentioned in a
previous post (https://groups.google.com/g/golang-nuts/c/2Xcfb4f7ans) I'v
On Thu, Feb 25, 2021 at 7:43 PM Bart Grantham wrote:
> If I understand the post here, it seems we're also struggling with this
> issue with our private repos. For us it means that in the go.sum of the
> highest level repos there's references for everything, all the way back to
> the initial v0.0
Hey everyone,
Please don't take this as a rant, but rather as a bit of an "experience"
report. I don't expect answers or suggestions, but I did think that I
should share so that the Go team would be aware. And yes, I still love
Go. ;) I am also keenly aware that I'm still doing some things
"i
The panic is in line 67, when you were decrypting the private key. However
you provided a public key (see line 131).
These things are always obvious to a fresh pair of eyes :-)
In short, you need to provide *Roger's public key* and *Roger's private key*
respectively. The public key is used to
