-1 to extending go env
+1 to go tool bugreport; most distros ship with a similar tool that grabs
all the logs and other info the need.

On Mon, Aug 8, 2016 at 1:55 PM, Brad Fitzpatrick notifications@github.com
wrote:

We've been getting a ton of macOS Sierra Beta bug reports. Everybody
includes the go env output, but the output doesn't say the kernel or OS
version.

If we included that somehow (or had a go tool bugreport subcommand), it'd
make bug triage easier.

/cc @adg https://github.com/adg @quentinmit
https://github.com/quentinmit @davecheney
https://github.com/davecheney

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16635, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcAy1ElfEtfcGzewgaxXIYp3LHNPR0ks5qdqi3gaJpZM4Jer5B
.

'go tool bugreport' seems like an excellent idea. It could also provide the markdown formatting that many people forget, making bugs hard to read. I wonder what (if any) the relationship should be with #11695. E.g. 'go tool bugreport' could just spit out text, or it could open a prefilled website page at bug.golang.org or...

I took a quick look at this, since I was already poking at 'go env'. It occurs to me that instead of dumping everything every time, we might want something like:

$ go bugreport
go version devel darwin/amd64
GOARCH=amd64 GOOS=darwin
$ go bugreport os
kernel_version="Darwin 15.6.0"
os_version="OS X 10.11.6 (15G31)"
$ go bugreport cgo
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pp/0010hzld5b12h_92j5th082r0000gn/T/go-build912243668=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
$ go bugreport all
go version devel darwin/amd64
GOARCH=amd64 GOOS=darwin
kernel_version="Darwin 15.6.0"
os_version="OS X 10.11.6 (15G31)"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pp/0010hzld5b12h_92j5th082r0000gn/T/go-build529064732=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/josh"
GORACE=""
GOROOT="/Users/josh/go/tip"
GOTOOLDIR="/Users/josh/go/tip/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pp/0010hzld5b12h_92j5th082r0000gn/T/go-build160036787=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

The downside is there might have to be a back-and-forth in which triage asks the reporter to run go bugreport xyz. The upside is initial bug reports are more concise and privacy-protecting. And we can add new (and fairly specialized) bugreport subcommands as needed, e.g. to get gdb version, to get ARM cpu info, to get various kernel configs, etc. And use go bugreport all for a full dump, in the cases in which we're mystified and want to just see everything.

Opinions about subcommands before I send a CL?

To be clear, I'm not asking for new ideas for subcommands. The question is: Do people like the design of having go bugreport be minimalist and using subcommands for further investigation?

Opinions, @quentinmit @bradfitz @adg @davecheney @minux?

I'd rather have just go bug and have it dump markdown with all the info.

The user can redact as they see fitting.

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

This broke the build, because during bootstrap "net/http" is not available.

Proposed fix is to use existing helper: https://go-review.googlesource.com/#/c/28531/

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