Hi,

The output from "go test" is just a warning.
If you run "go test -i github.com/ogier/pflag" and then "go test github.com/ogier/pflag", the warning disappears.

The version of Go that is used is the latest release, version 1.0.1.

If this is still an issue for you, please report it upstream at:
http://code.google.com/p/go/issues/list

You should also be able to avoid the warning if you package pflag by using the Go Package Guidelines, if that's an alternative for you:
https://wiki.archlinux.org/index.php/Go_Package_Guidelines

Best regards,
Alexander Rødseth

The "go test" warning is really an error, I think. The command succeeds because all Go standard packages are shipped with source code alongside. Every single run of "go test" rebuilds all the standard library modules from source in a temporary location, then runs the tests which succeed, but this shouldn't be necessary.

The "go test -i" invocation is a shortcut for running "go install" on all out-of-date dependencies, which in my case is much of the standard library. This fails, as with all other commands to build/install custom packages, because I don't have permissions to write to system libraries.

$ go test -i github.com/ogier/pflag
go install runtime: open /usr/lib/go/pkg/linux_amd64/runtime.a: permission denied

If you want to replicate this, install Arch's Go package to a system location, run 'export GOPATH=~/go' or similar, and run the series of commands as an unprivileged user. I probably should have mentioned this in the original report, I apologize.

If I run the following:

~% mkdir go
~% export GOPATH=~/go
~% go get github.com/ogier/pflag

I get:

go install runtime: open /usr/lib/go/pkg/linux_amd64/runtime.a: permission denied

If I run:

~% go test github.com/ogier/pflag

I get:

warning: building out-of-date packages:
runtime
errors
sync/atomic
sync
io
math
syscall
time
os
unicode/utf8
strconv
reflect
fmt
sort
unicode
strings
bytes
flag
bufio
text/tabwriter
runtime/pprof
testing
regexp/syntax
regexp
installing these packages with 'go test -i github.com/ogier/pflag' will speed future tests.

ok github.com/ogier/pflag 0.006s


The test itself seems to run fine (although ~/go is completely empty, are there other commands needed to reproduce?)

What is the expected behavior?

Anyone knows is there are additional steps that needs to be taken when installing Go to make sure the installed packages looks up to date from the viewpoint of "go test"?

Since the files that comes with the "go" package is the files from the latest release version of go (1.0.1), I would assume that the warning message is inaccurate?

Alright, here are some clearer steps to repro. It uses a battle-tested library from the Go authors, just to clarify that this isn't just a problem with my Go package.

All of the following should be run as a normal user with no permissions for /usr/lib/go/pkg

$ mkdir ~/go
$ export GOROOT=~/go
$ go get code.google.com/p/go.crypto/bcrypt
go install runtime: open /usr/lib/go/pkg/linux_amd64/runtime.a: permission denied
$ go test code.google.com/p/go.crypto/bcrypt
warning: building out-of-date packages:
runtime
errors
math
unicode/utf8
strconv
code.google.com/p/go.crypto/blowfish
sync/atomic
sync
io
unicode
bytes
bufio
crypto/cipher
crypto/aes
reflect
encoding/binary
syscall
time
os
fmt
math/rand
strings
math/big
crypto/rand
crypto/subtle
encoding/base64
sort
flag
text/tabwriter
runtime/pprof
testing
regexp/syntax
regexp
installing these packages with 'go test -i code.google.com/p/go.crypto/bcrypt' will speed future tests.

ok code.google.com/p/go.crypto/bcrypt 4.082s

What is the expected result? That the warnings should not appear or that an .a file should appear somewhere in ~/go where it's currently not? (I assume the latter).

Updating the go package to use all.bash.

Packaged go-bcrypt (https://aur.archlinux.org/packages.php?ID=59173) just to demonstrate that it can be compiled as a regular user too (if "sudo go" is not desirable).

Expected result is no warnings. The .a files are being generated in the correct place (Go places all compiled .a files in a location relative to their source). The issue is that they shouldn't need to be generated at all.

As for the whole packaging issue, it is definitely still possible to build a package, I have no doubt about that. The issue is that the most recent release, go-2:1.0.1-1, breaks the Go compiler such that it cannot be used in the standard way, with GOPATH set as an unpriveleged user. For example, the intro material at http://golang.org/doc/code.html fails.

The go intro material should work either with "sudo" or if packaged as Arch Linux packages.

When it comes to the claim that the go package breaks the Go compiler, may you please clarify/specify what it breaks? Is there an environment variable that should not have been set or are any files placed in sub-optimal locations on the system?

IMO, it's the "go" tool itself that makes it problematic to build code as a regular user when using a system wide install of Go. No other compiler on Arch Linux have any problems similar to this (that I know of).

In any case, I'm open for suggestions and ready to make changes that may improve the situation.

Does the latest update of the "go" package fix this bug?

The reason the go tooling is particularly problematic is that Go's standard library is distributed in source form. The Go PKGBUILD should recompile all modules into .a files available in /usr/lib/go/pkg but for whatever reason, this didn't happen in the most recent 1.0.1 release. This is basically like distributing gcc version 4.7 with gcc-libs version 4.6, except it is worse because Go deliberately has no stable ABI.

I really think this is just an error in packaging: the standard library wasn't recompiled for 1.0.1, and doing so will fix this bug.

Thanks for the good answer, does the "all.bash" version work for you (go-2:1.0.1-2, signed 2012-05-10 12:42 UTC).

Sorry, Flyspray doesn't issue 302 redirects after posting, so refreshing the page can repost old comments if you don't click the right confirmation.

I still get the same errors in go-2:1.0.1-2.

No worries.

I'll try adding a recompilation of the system libraries as the final part of the installation process, to see if it helps.

Hmm, little brainwave. Is it possible that this is entirely due to timestamps? As in, depending on the order in which pacman touches the source files in /usr/lib/go/src and .a files in /usr/lib/go/pkg the standard packages may or may not be considered out of date?

That might very well be. I'll try to look into it after the weekend.