[Bug 1022983] New: Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Bug ID: 1022983
           Summary: Consider updating Rawhide to Go 1.2 release candidate
           Product: Fedora
           Version: rawhide
         Component: golang
          Assignee: [e-mail]
          Reporter: [e-mail]
        QA Contact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]

Go 1.2 is in code freeze, with a release date scheduled for December 1.

Go 1.2 release candidate 2 was released last week:
https://groups.google.com/forum/#!topic/Golang-Nuts/5enxY7gSLB4

I think we should update golang in Rawhide (but not F20 or F19) to the release
candidate, so we can start testing builds against it and making any necessary
adjustments.

For docker's in-container init process, we need the go-net libs but we also
want the binary to be static; this isn't possible in 1.1 but will be in 1.2.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Peter Lemenkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|[e-mail]. |
                   |org                         |
                 CC|                            |[e-mail].
                   |                            |org

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Peter Lemenkov]

2013/10/24  :
...
> You are receiving this mail because:
> You are on the CC list for the bug.
> Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fCGXa3vB9j&a=cc_unsubscribe

^^^ This will be fixed soon by the Bugzilla administrator.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #1 from Peter Lemenkov  ---
Love the idea! Actually I'd rather update golang in F20 as well not just in
F21/Rawhide.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Peter Lemenkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://tip.golang.org/doc/g
                   |                            |o1.2

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #2 from Matthew Miller  ---
(In reply to Peter Lemenkov from comment #1)
> Love the idea! Actually I'd rather update golang in F20 as well not just in
> F21/Rawhide.

I think that's a little risky with the F20 schedule, where our release is
scheduled for just 2 days after theirs (and our bits will have to all be in
place the week before, for mirroring). So, we'd be shipping a RC with F20.
We've done such things before, but in my opinion it'd best to do a post-release
update.

But if the RC does seem to be stable and works with the packages we're shipping
(currently to my knowledge, just etcd and docker real-soon-now), maybe it's
worth the risk.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #3 from Matthew Miller  ---
Although I see that as I was writing this, the beta slipped by a week, pushing
everything back. If it slips by _another_ week and Go stays on schedule (and
from their docs it looks like they have a hard commitment to doing so), there
may be no issue at all. But I suppose we shouldn't plan on that. :)

We could do the update in Rawhide now and then decide on what to do for F20
after the beta has shipped. Normally I'd frown on that (because we are totally
going around the whole release management process) but this is pretty clearly
on the fringe/bleeding edge and we know it doesn't affect anything else.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #4 from Adam Miller  ---
Go 1.2 builds on F20 but appears to fail one of the tests ... I'm going to look
into it more as I find time but didn't want to remain silent on the BZ.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #5 from Matthew Miller  ---
(In reply to Adam Miller from comment #4)
> Go 1.2 builds on F20 but appears to fail one of the tests ... I'm going to
> look into it more as I find time but didn't want to remain silent on the BZ.

In the specfile (in both %build and %check) we have

export PATH="$PATH":"$GOROOT"/bin

which means that the system path is first, and so if you have another go
package installed that gets called first in the tests. Is that what you're
running into? Try making it

export PATH=$GOROOT/bin:$PATH

(Quotes shouldn't be necessary, but whatever.)

On my F19 and F20 systems, with that switched, the tests pass. (And they don't
pass if I have the older golang installed and the path the other way.)

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #6 from Adam Miller  ---
I was building in mock which shouldn't have had any other version of Go
installed in the chroot.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #7 from Adam Miller  ---
For reference, this is the issue I'm seeing building in mock:

--- FAIL: TestCgoTraceback (0.83 seconds)
        crash_cgo_test.go:33: expected "OK\n", but got "#
command-line-arguments\n/tmp/go-build563671405/main.go: In 
function '_cgo_65eb2f8ba551_Cfunc_foo':\n/tmp/go-build563671405/main.go:31:49:
warning: unused variable 'a' [-Wunused
-variable]\nOK\n"
FAIL
FAIL    runtime 15.451s

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #8 from Matthew Miller  ---
(In reply to Adam Miller from comment #6)
> I was building in mock which shouldn't have had any other version of Go
> installed in the chroot.

Aw, too bad, because that's an easy fix. (It should probably be changed in the
specfile anyway.)  I'll dig deeper.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #9 from Adam Miller  ---
Also, because I'm bad at making a complete thought before commenting on this
particular BZ here is the SRPM I have that fails that test in mock for both F20
and Rawhide

http://maxamillion.fedorapeople.org/golang-1.2rc2-1.fc19.src.rpm

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #10 from Matthew Miller  ---
(In reply to Adam Miller from comment #7)
> For reference, this is the issue I'm seeing building in mock:
>
> --- FAIL: TestCgoTraceback (0.83 seconds)
>         crash_cgo_test.go:33: expected "OK\n", but got "#
> command-line-arguments\n/tmp/go-build563671405/main.go: In 
> function
> '_cgo_65eb2f8ba551_Cfunc_foo':\n/tmp/go-build563671405/main.go:31:49:
> warning: unused variable 'a' [-Wunused
> -variable]\nOK\n"
> FAIL
> FAIL    runtime 15.451s

Okay, yeah, I can reproduce this when I'm trying to update the RPM rather than
just building it by hand. When I comment out the "mygcc" part, though, it works
fine. So, it's something to do with that.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #11 from Matthew Miller  ---
RC3 is out now, by the way
https://groups.google.com/forum/#!msg/golang-nuts/7FXy8x7Oqyg/_mfUwUdnyXIJ

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #12 from Matthew Miller  ---
Same error happens in rc3, btw.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #13 from Matthew Miller  ---
This is especially fun to debug because go cleans up the temporary directory it
was using to build right after it exits, making it really hard to find where
the error is. Neat.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #14 from Matthew Miller  ---
Okay, so, here is the test code that is failing:

main.go:
-----------------
package main

/* void foo(void) {} */
import "C"

import (
        "fmt"
        "runtime"
)

func main() {
        C.foo()
        buf := make([]byte, 1)
        runtime.Stack(buf, true)
        fmt.Printf("OK\n")
}
--------------------
$ go run main.go
# command-line-arguments
./main.go: In function ‘_cgo_92e4c70c8af1_Cfunc_foo’:
./main.go:30:49: warning: unused variable ‘a’ [-Wunused-variable]
OK

but only if CC points to the version which wraps the $RPM_OPT_FLAGS

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #15 from Matthew Miller  ---
And in the generated code, here is our unused "a":

void
_cgo_92e4c70c8af1_Cfunc_foo(void *v)
{
        struct {
                char unused;
        } __attribute__((__packed__, __gcc_struct__)) *a = v;
        foo();
}

Now, without going deeply into what that's all about, I've got no idea if this
is a bug or intentional in this test.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #16 from Matthew Miller  ---
Soooooo, this means that:

1. Unsetting CC at the top of the %check file should work
2. This is probably the right thing to do, because we're not using a wrapper at
runtime

EXCEPT

unsetting CC didn't work. I had to set CC to /usr/bin/gcc to make it work.
That's confusing (and why I jumped through the hoops above). Why's that? Uh oh:

$ grep mygcc . -r
Binary file ./bin/go matches
./src/cmd/go/zdefaultcc.go:const defaultCC =
`/home/mattdm/rpmbuild/BUILD/go/zz/mygcc`
./src/cmd/cgo/zdefaultcc.go:const defaultCC =
`/home/mattdm/rpmbuild/BUILD/go/zz/mygcc`
Binary file ./pkg/tool/linux_amd64/cgo matches

We've got the path to the gcc wrapper in the build tree built into the whole
thing -- looks like golang 1.2 wants to keep using the wrapper it was built
with. That seems logical, but raises some... interesting questions.

a) Should all go programs built by the go compiler use our RPM flags? (That is,
should we _ship_ the mygcc wrapper?)
b) If so, might that introduce horrible bugs?
c) If not, should we seek an exception for building golang itself?

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Vincent Batts  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #17 from Vincent Batts  ---
Another note, the upgrade to go1.2 is going to require a couple of additional
things. Two subcommands currently in core 'golang' package and source repo are
being moved their go.tools repo (`go doc` and `go vet`), namely so they can
have a separate release from the compiler.
So making a spec for code.google.com/p/go.tools, that provide sub packages that
will include these commands.
  code.google.com/p/go.tools/cmd/godoc
  code.google.com/p/go.tools/cmd/vet

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #18 from Vincent Batts  ---
like
http://hashbangbash.com/~vbatts/rpmbuild/SRPMS/golang-googlecode-tools-0-0.0...

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #19 from Vincent Batts  ---
update: i have separated out the godoc from the golang into subpackage
golang-godoc. And 'golang' will require /usr/bin/godoc. Seamless for current
fedora/epel releases.

We have the review in progess for the go.tools
https://bugzilla.redhat.com/show_bug.cgi?id=1029068 which will provide it's own
-godoc. 
This way an upgrade of golang to go1.2, will no long produce a golang-godoc,
and could install either existing golang-godoc or that from go.tools. We could
even have an explicit require on the go.tools subpackage.

[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #20 from Matthew Miller  ---
Any comment on the "mygcc" issue?

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Matthew Miller  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Consider updating Rawhide   |Update to Go 1.2
                   |to Go 1.2 release candidate |

--- Comment #21 from Matthew Miller  ---
Official release is here: http://blog.golang.org/go12

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #22 from Vincent Batts  ---
release! cool.

So the failure on unused variables is tied up in $RPM_OPT_FLAGS $RPM_LD_FLAGS.
I've tried a variety of ways to work around this, but I feel that seeking an
exception for this package will be best.

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #23 from Vincent Batts  ---
raised the discussion here
https://groups.google.com/forum/#!topic/golang-nuts/SJn48BkCUqA

Will open issue against golang, based on response from Ian Taylor.

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Fedora Update System  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |MODIFIED

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #24 from Fedora Update System  ---
golang-1.2-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/golang-1.2-1.el6

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #25 from Fedora Update System  ---
golang-1.2-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/golang-1.2-1.fc19

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

--- Comment #26 from Fedora Update System  ---
golang-1.2-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/golang-1.2-1.fc20

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Fedora Update System  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|MODIFIED                    |ON_QA

--- Comment #27 from Fedora Update System  ---
Package golang-1.2-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing golang-1.2-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-22742/golang-1.2-1.fc20
then log in and leave karma (feedback).

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Fedora Update System  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ON_QA                       |CLOSED
   Fixed In Version|                            |golang-1.2-1.fc20
         Resolution|---                         |ERRATA
        Last Closed|                            |2014-01-14 03:44:31

--- Comment #28 from Fedora Update System  ---
golang-1.2-1.fc20 has been pushed to the Fedora 20 stable repository.  If
problems still persist, please make note of it in this bug report.

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Fedora Update System  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
   Fixed In Version|golang-1.2-1.fc20           |golang-1.2-1.fc19

--- Comment #29 from Fedora Update System  ---
golang-1.2-1.fc19 has been pushed to the Fedora 19 stable repository.  If
problems still persist, please make note of it in this bug report.

[Bug 1022983] Update to Go 1.2

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1022983

Fedora Update System  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
   Fixed In Version|golang-1.2-1.fc19           |golang-1.2-1.el6

--- Comment #30 from Fedora Update System  ---
golang-1.2-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If
problems still persist, please make note of it in this bug report.