After upgrade to 1.3.1, packages bytes and string are marked as stale:
$ go list -f '{{.Stale}}' bytes
true
$ go list -f '{{.Stale}}' strings
true

When you want to install a package that imports these packages (bytes and strings), go compiles and try to install them in /usr/lib/go/pkg/linux_amd64. As non-root user, you don't have the permission to write in this directory.

Hi,

I had the same issue. The following resolved it for me:

find /usr/lib/go -name "*.a" -exec touch -r `which go` {} \;

Hope this helps.

I too had the same error

I recompiled the package myself and that helped and also tried Makpoc find command and that helped too

What do you think the issue is Makpoc? I'm curious to how you came to conclusion about file time stamp

Also affected and confirming Makpoc's solution works.

Note that steps to reproduce might be misleading -- this will only happen if you go get something that actually depends on bytes/strings.

@szabba, it's actually not. Not only bytes and strings are marked as stale, but every stdlib package that comes with go. If you `sudo touch` bytes.a and strings.a and try to `go get` something that depends on other packages, you'll get some errors about other .a files.

Well that's weird. I had the same issue with bytes/strings, but packages that depended import (directly or indirectly) math (github.com/szabba/md/vect, github.com/szabba/md/newton) were go got just fine.

(I've reinstalled go from the repositories to check that it's still true on my machine.)

I've sniffed a bit around and some stdlib packages in community/go are stale and some aren't. See the attached file for how this looks on my system. Use the script below to generate the results on your machine (if your so inclined).

for pkg in `find /usr/lib/go | grep '\.a$' | sed '{s/\/usr\/lib\/go\/pkg\/linux_amd64\///; s/\.a$//}'`; do
echo $pkg `go list -f {{.Stale}} $pkg`
done 2> /dev/null | sort > out

EDIT: Change the linux_amd64 part in the sed script to the directory for your machine's architecture.

EDIT2: Oh, did you mean that some other stdlib packages will also cause the issue (as opposed to all)?

@szabba, hmm, you're right. I thought that every package is stale, but I've just checked output with your script and yes, some of them is stale and some of them is not. And stale list is same with yours. Sorry for inconvenience.

Well I wasn't right initally either. In the end we both got a better understanding of the problem and someone else might benefit from it too. Win/win.

Thanks for reporting. I will fix this as soon as humanly possible. I'm going on a cabin trip this weekend, but I might be able to fix it from my mobile phone over ssh. If another TU/dev wishes to fix it instead, just leave a short note here, please.

https://code.google.com/p/go/issues/detail?id=5064

quote:
I suggest that we update the docs to tell people to tell tar to preserve time stamps from the archive.

you may install every stale package
sudo go install <nameofpackage>

or install all

sudo go install all

and try to install you package in gopath

go get github.com/revel/cmd/revel (exemple)

Would running "go install all" in the go.install file (after the package has been installed/upgraded) be a possible solution?

Take a look at `go help packages` -- seems like if anything you should rather put `go install std`.

It conveys what you're tryin to do better and in the odd circumstance that the user under whom the install script runs has a GOPATH set -- it prevents you from automatically reinstalling everything they have go installed by hand.

I also have this problem. Any solutions yet? Downgrading to 1.3 is a temporary workaround for me.

After installing 1.3.1 Makpoc's oneliner works, so does

su -c 'go install std'

Updated the package to run "go install std" after upgrade/installation. Sorry about the slight delay.

Please confirm that go-2:1.3.1-2 now works as expected, it should appear in [community] any minute now.

Tested the steps to reproduce, and it works here.

Yes, it works. Tested with: 'go get github.com/gobuild/got'.

Tested it with the following AUR package which failed to build before the upgrade. It works fine now: https://aur.archlinux.org/packages/go-mtpfs-git/

Great, thanks for testing, closing this one.

I still see the problem:

go get github.com/nsf/gocode Thu Aug 28, 17:34
go install bytes: open /usr/lib/go/pkg/linux_amd64/bytes.a: permission denied
go install strings: open /usr/lib/go/pkg/linux_amd64/strings.a: permission denied

Miki Tebeka, if you run "go install std" as root, does it fix the problem?

I've created a new archline VM (based on 2014.10.01 and after installing go tried "go get github.com/nsf/gocode" - works for me :)

I guess you can close this one.

Tried removing "go install std" for go 1.7.5 and could not reproduce this error after installation. Will remove the .install file. Please re-open this issue if the issue should re-occur.