What do go version, go env and env | grep GO say?

FWIW I installed this pkg:

https://storage.googleapis.com/golang/go1.6beta1.darwin-amd64.pkg

It looks like this gets triggered any time 'net/http' gets imported.

If i relax perms on the vendor directory, the next error is this

go install net/http: open /usr/local/go/pkg/darwin_amd64/net/http.a: permission denied

ls -l /usr/local/go/pkg/darwin_amd64/net/http.a?
It looks like the file permissions are wrong after installing that pkg. But what are they?
You say you relaxed the permissions on the vendor directory, but what were they before, and what did you change them to?

Hey @rsc,

I was able to repro this. Here are the steps:

• Have 1.5 installed and 'go get' in a project under GOPATH which does:

import "golang.org/x/net/http2"

(AFAICS this is a valid use case of the above package in a server capacity...)

• Install 1.6beta1.
• Type go get in any project (even if it doesn't reference golang.org/x/net/http2). The permission error occurs then.

I was able to get things to work just be removing my $GOPATH/src/golang.org directory.

I don't know if this is something that needs to be thought about prior to 1.6 release...

Again, what are the permissions in the broken state?

Oh! go get is trying to reinstall the standard library. I missed that. I thought it was trying to read the files, not write them. It makes sense that writing them would fail. The question now is why it thinks they're out of date. And the answer is probably the time stamps combined with the fact that the beta is not considered a "release". The rebuild logic for releases is different from being on the dev branch in cmd/go. We need to get cmd/go into the release logic for betas.

Check out #13769, it might be related.

On Tue, 29 Dec 2015, 20:53 Russ Cox notifications@github.com wrote:

Oh! go get is trying to reinstall the standard library. I missed that. I
thought it was trying to read the files, not write them. It makes
sense that writing them would fail. The question now is why it thinks
they're out of date. And the answer is probably the time stamps combined
with the fact that the beta is not considered a "release". The rebuild
logic for releases is different from being on the dev branch in cmd/go. We
need to get cmd/go into the release logic for betas.

—
Reply to this email directly or view it on GitHub
#13713 (comment).

@rsc, I don't think your guess is correct, given this code in cmd/go:

// The runtime version string takes one of two forms:                                                                                                                               
// "go1.X[.Y]" for Go releases, and "devel +hash" at tip.                                                                                                                           
// Determine whether we are in a released copy by                                                                                                                                   
// inspecting the version.                                                                                                                                                          
var isGoRelease = strings.HasPrefix(runtime.Version(), "go1")

That would be true for go1.6beta2.

I had been thinking this didn't matter for the release because we wouldn't do another beta, but given what @bradfitz found it sounds like I need to figure this out for the release candidate. Noted.

I can't recreate this.

@omarkilani Can you still recreate this on tip? If so could you provide step-by-step instructions to reproduce the problem? Thanks.

Reproduced and debugged.

p.Standard = p.Goroot && p.ImportPath != "" && !strings.Contains(p.ImportPath, ".")

was meant to tease apart actual standard library in $GOROOT from other people dropping their own work in $GOROOT, as was common before $GOPATH came along. The idea was that other people should have domain names (with dots) in their paths, and the standard library did not. But vendoring introduces domain names into the standard library, and that vendored hpack package looks stale because it's not "standard", so it doesn't fall under the "released packages are not out of date" clause.

It looks like we want to replace the final clause above with something like:

(strings.HasPrefix(p.ImportPath, "cmd/") || strings.HasPrefix(p.ImportPath, "vendor/") || !strings.Contains(p.ImportPath, ".")

Will fix tomorrow.

CL https://golang.org/cl/18978 mentions this issue.

Friends, I feel current approach is generally broken.
As -a option re-introduces a strong wish to overwrite file from go distribution.

I'll file it separately.
Just a note to fellow googlers: check that you're not forcing to recompile "everything", and get

[alexander.petrossian@rhel7-build csearch]$ $GOROOT/bin/go install -x  -ldflags '-X main.Version=0.0.0' -v -a code.google.com/p/codesearch/cmd/cgrep code.google.com/p/codesearch/cmd/cindex code.google.com/p/codesearch/cmd/csearch
WORK=/tmp/go-build818453712
runtime/internal/sys
mkdir -p $WORK/runtime/internal/sys/_obj/
mkdir -p $WORK/runtime/internal/
cd /opt/go/src/runtime/internal/sys
/opt/go/pkg/tool/linux_amd64/compile -o $WORK/runtime/internal/sys.a -trimpath $WORK -p runtime/internal/sys -+ -complete -buildid c365bd5998b865c5a380468a16bb19b165ce27cf -D _/opt/go/src/runtime/internal/sys -I $WORK -pack ./arch_amd64.go ./stubs.go ./sys.go ./zgoarch_amd64.go ./zgoos_linux.go ./zversion.go
mkdir -p /opt/go/pkg/linux_amd64/runtime/internal/
cp $WORK/runtime/internal/sys.a /opt/go/pkg/linux_amd64/runtime/internal/sys.a
go install runtime/internal/sys: open /opt/go/pkg/linux_amd64/runtime/internal/sys.a: permission denied
[alexander.petrossian@rhel7-build csearch]$ $GOROOT/bin/go version
go version go1.6 linux/amd64
[alexander.petrossian@rhel7-build csearch]$

Locking this issue to prevent further discussion here. File new issues for new behaviors please.