Bug#779503: support gccgo, at least on architectures where golang is not available

2015-03-31 Thread Tianon Gravi
On 31 March 2015 at 14:36, Matthias Klose wrote: > Does your testing goes beyond docker.io? If no, I would claim your testing is > dubious at best ;) There are certainly still issues, but to me it starts to > look usable. There are other dubious things like how golang-gotools is built > in > D

Bug#779503: support gccgo, at least on architectures where golang is not available

2015-03-31 Thread Matthias Klose
> The "go" implementation bundled there is not fully-baked. For > example, using "go get" to download a project didn't bother > downloading the dependencies like it should, thus causing the build to > fail really hard with a screen-full of errors. GCC 5 is not yet released. That's why it is in ex

Bug#779503: support gccgo, at least on architectures where golang is not available

2015-03-31 Thread Tianon Gravi
On 31 March 2015 at 14:10, Matthias Klose wrote: > There is a deficiency in dh-golang, which doesn't make things verbose at all, > even when setting DH_VERBOSE=1. You can get more information about invoked > commands by using -x. Maybe there are more things to pass, but I'm not a > golang > main

Bug#779503: support gccgo, at least on architectures where golang is not available

2015-03-31 Thread Matthias Klose
> Worse yet, I tried building the newly-merged-upstream[1] docker gccgo > support using it, and the "go build" invocation failed to produce a > binary at the location specified by "-o", but did so with a zero exit > code indicating success, which is much more alarming. Even adding > "-v" to the bu

Bug#779503: support gccgo, at least on architectures where golang is not available

2015-03-17 Thread Tianon Gravi
On 4 March 2015 at 17:54, Tianon Gravi wrote: > Doesn't the "go" binary support co-installability and use via the > "-compiler" flag too? How will that play into this proposal? After spending some time with the gccgo-5 package in experimental (that now has these alternatives baked in...), I'm ac

Bug#779503: [Docker-maint] Bug#779503: support gccgo, at least on architectures where golang is not available

2015-03-04 Thread Tianon Gravi
On 1 March 2015 at 09:32, Matthias Klose wrote: > golang-go seems to ship gofmt directly, and handling go via alternatives. Is > there a specific reason for that? Can we make that consistent? If handling via > alternatives, then I would suggest some priority change, in that golang maybe > uses a

Bug#779503: support gccgo, at least on architectures where golang is not available

2015-03-01 Thread Matthias Klose
Package: golang-go Tags: stretch gccgo in experimental (depending on gccgo-5) now provides the commands go-5 and gofmt-5, and claims to be compatible with Go 1.4. golang-go seems to ship gofmt directly, and handling go via alternatives. Is there a specific reason for that? Can we make that consi