Bug 652987

*** Bug 610934 has been marked as a duplicate of this bug. ***

I presently list the license as "BSD-like" because I have not yet been able to find the appropriate short form of Go's license. This is a place holder.

http://golang.org/LICENSE

3-clause BSD, plus a patent grant and reciprocity requirement; can that be listed as simply "BSD" per the licensing guidelines, or would legal have to approve the modified version?

http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License:_field
http://fedoraproject.org/wiki/Licensing#Good_Licenses

I ran into the following issues.

1) Upstream didn't want it packaged. They don't have a stable 1.0 yet, was the reason.

2) Time

Take over from me if you want. I'm busy doing ambassador work these days and I'm a huge noob at packaging. Someone else would do a much better job.

If you want to ask legal questions, you need to make sure the legal folks see them.  Adding FE-Legal blocker (or you can ask on the legal mailing list).

Will review once the legal situation is clarified. FWIW I think Google will be willing to relicense; WebM was in this situation earlier on.

Emailed cdibona @ Google.

any word on this?

Upstream split the patent grant out of the copyright license in their source control:

http://code.google.com/p/go/source/detail?spec=svnae87c054a037ab8de431ca7dff3d433ab54144da&r=1149e001c22afd0e88541ebf763a74bf7cc18ba6

So, if you update the package to at least that changelevel, it should be just BSD, and there are no more legal concerns (that I am aware of).

Spec URL: http://www.flyn.org/SRPMS/go.spec
SRPM URL: http://www.flyn.org/SRPMS/go-20101208-1.fc14.src.rpm

New version contains split patent notes. I have updated the license to "BSD."

Lifting FE-Legal

The .spec file needs a little tweaking.

Add - BuildRequires: ed, bison

Without these, it does not build.


See also: http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries

Additional formatting issues can be found from 'rpmlint go*.rpm'

Spec URL: http://www.flyn.org/SRPMS/go.spec
SRPM URL: http://www.flyn.org/SRPMS/go-20101208-2.fc14.src.rpm

Added ed and bison requirement.

I am aware of the policy on static libraries. However, go *is* a development package. So go-devel does not really make sence. For example, there is no gcc-devel, and gcc ships /usr/lib/gcc/x86_64-redhat-linux/4.5.1/32/libgcc.a, etc.

Can you provide your output from rpmlint? I get:

$ rpmlint go-20101208-1.fc14.src.rpm 
Traceback (most recent call last):
  File "/usr/share/rpmlint/rpmlint.py", line 364, in <module>
    main()
  File "/usr/share/rpmlint/rpmlint.py", line 84, in main
    loadCheck(c)
  File "/usr/share/rpmlint/rpmlint.py", line 68, in loadCheck
    imp.load_module(name, fobj, pathname, description)
  File "/usr/share/rpmlint/TagsCheck.py", line 928, in <module>
    'Your release tag must match the regular expression ' + release_ext + '.',
TypeError: cannot concatenate 'str' and 'NoneType' objects

(In reply to comment #13)
> Can you provide your output from rpmlint? I get:
> 
> $ rpmlint go-20101208-1.fc14.src.rpm 
> Traceback (most recent call last):
>   File "/usr/share/rpmlint/rpmlint.py", line 364, in <module>
>     main()
>   File "/usr/share/rpmlint/rpmlint.py", line 84, in main
>     loadCheck(c)
>   File "/usr/share/rpmlint/rpmlint.py", line 68, in loadCheck
>     imp.load_module(name, fobj, pathname, description)
>   File "/usr/share/rpmlint/TagsCheck.py", line 928, in <module>
>     'Your release tag must match the regular expression ' + release_ext + '.',
> TypeError: cannot concatenate 'str' and 'NoneType' objects

[renich@introdesk SPECS]$ rpmlint go
(none): E: no installed packages by name go
0 packages and 0 specfiles checked; 0 errors, 0 warnings.
[renich@introdesk SPECS]$ rpmlint go-20101208-2.fc14.src.rpm 
go.src: W: name-repeated-in-summary C Go
go.src: W: spelling-error %description -l en_US multicore -> multicolor, Multics, multichannel
go.src:10: W: mixed-use-of-spaces-and-tabs (spaces: line 10, tab: line 1)
go.src: W: invalid-url Source0: go-20101208.tar.gz
1 packages and 0 specfiles checked; 0 errors, 4 warnings.

Also, keep in mind that go asks for: 

    setsebool -P allow_execstack 1

Also, It's not building for me because it complaints about the build id; at the debug info generation I think...


*** You need to add /builddir/build/BUILD/go-20101208/bin to your $PATH. ***
The compiler is 6g.
The binaries expect /builddir/build/BUILD/go-20101208 to be copied or moved to /usr/lib64/go/.
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.IrHtND
+ umask 022
+ cd /builddir/build/BUILD
+ '[' /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64 '!=' / ']'
+ rm -rf /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64
++ dirname /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64
+ mkdir -p /builddir/build/BUILDROOT
+ mkdir /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64
+ cd go-20101208
+ LANG=C
+ export LANG
+ unset DISPLAY
+ install -d -m 755 /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64/usr/bin
+ install -d -m 755 /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64/usr/lib64/go/
+ install -p -m 755 bin/6a bin/6c bin/6cov bin/6g bin/6l bin/6nm bin/6prof bin/cgo bin/ebnflint bin/godefs bin/godoc bin/gofmt bin/goinstall bin/gomake bin/gopack bin/gopprof bin/gotest bin/gotry bin/goyacc bin/hgpatch bin/quietgcc /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64/usr/bin
+ cp -pR pkg/ /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64/usr/lib64/go/
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/go-20101208
extracting debug info from /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64/usr/bin/ebnflint
/usr/lib/rpm/debugedit: /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64/usr/bin/ebnflint: Unknown debugging section .debug_gdb_scripts
*** ERROR: No build ID note found in /builddir/build/BUILDROOT/go-20101208-2.fc14.x86_64/usr/bin/ebnflint
error: Bad exit status from /var/tmp/rpm-tmp.IrHtND (%install)
    Bad exit status from /var/tmp/rpm-tmp.IrHtND (%install)
RPM build errors:
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/go.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/mock/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.7/site-packages/mock/util.py", line 317, in do
    raise mock.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/go.spec']
LEAVE do --> EXCEPTION RAISED

Spec URL: http://www.flyn.org/SRPMS/go.spec
SRPM URL: http://www.flyn.org/SRPMS/go-20101208-3.fc14.src.rpm

I'm not really sure how to handle the "setsebool -P allow_execstack 1" problem because setting this on the Fedora build servers is probably not permitted.

> go.src: W: name-repeated-in-summary C Go

Any suggestions for a different summary?

> go.src:10: W: mixed-use-of-spaces-and-tabs (spaces: line 10, tab: line 1)

Fixed.

> go.src: W: invalid-url Source0: go-20101208.tar.gz

This is generated from mercurial as noted in the comments.

Your package really should not require execstack.

"The package maintainer can turn off execstack when linking the app by adding
"-Wl,-z,noexecstack" to the LDFLAGS (or CFLAGS) in the Makefile."

If you need more information, D. Walsh's blog is an excellent resource, or come to irc ( #fedora or #fedora-selinux ) and it can be explained easier there.

Do not be concerned with the "invalid-url" one as much, because like you said, it is built from a scm tag.


You can also run "rpmlint" upon your finished product.  I was unable to make it build before, or I would have.


Example:

koji build dist-f14 --scratch --arch=x86_64 go-20101208-3.fc14.src.rpm


Then you can view the logs, fix any errors, and rpmlint the final product.

The Go SELinux executable stack issue is documented here:

http://code.google.com/p/go/issues/detail?id=47

As another issue, I am not sure what is causing this error:

/usr/lib/rpm/debugedit: /builddir/build/BUILDROOT/go-20101208-3.fc14.x86_64/usr/bin/goyacc: Unknown debugging section .debug_gdb_scripts

I don't see this when building locally, only with koji.

Apparently related, I also see:

$ gdb goyacc 
GNU gdb (GDB) Fedora (7.2-26.fc14)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mike/Source/rpms/BUILDROOT/go-20101208-3.fc14.x86_64/usr/bin/goyacc...
warning: Loadable segment ".interp" outside of ELF segments
done.
Loading Go Runtime support.
(gdb

Can somebody link this request to this bug, please?
http://code.google.com/p/go/issues/detail?id=1280

Are you sure the setsebool flip is necessary?
I don't know much about that functionality but I have found that
on a Fedora system running under Xen (on slicehost.com) the Go
installation prints a warning about setsebool but then runs just fine.

On that system:

$ cat /etc/issue
Fedora release 10 (Cambridge)
Kernel \r on an \m (\l)

$ uname -a
Linux [elided] 2.6.24-24-xen #1 SMP Tue Aug 18 18:15:39 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux
$ 

I've been meaning to find out why the warning gets printed
without being necessary, but I haven't had time to dig in.
If there are any experts out there, I'd be happy to hear from them.

rsc

Russ, sorry for the very rudimentary question, but is SELinux actually enabled on your slice? A quick "/usr/sbin/selinuxenabled && echo enabled" ought to confirm.

(I spent a bit of time trying to get SELinux working with Slicehost's kernels a year or two ago with the assistance of their support team, but without success. These days, you can run your own kernel, but it looks like you're running one of theirs with F10 right now.)

Ed, thanks for the note.  I've never used SELinux so I didn't
know even that much.  The current build script uses 
[ -d /selinux -a -f /selinux/booleans/allow_execstack ]
to decide whether to print the warning.  I will change it
to also test the exit status of selinuxenabled.

Thanks again.

Guys, for what is worth, here's a spec that builds.
http://fedorapeople.org/~renich/go.spec


Can somebody tell me what to do with the go/src dir? It seems applications need, at least, the Make.inc and Make.pkg files in order to compile:

Example:
http://www.getwebgo.com/ (this one is used by other go projects as well)
  -> https://github.com/hoisie/web.go/blob/master/Makefile#L1

I could put it in /usr/share/go and add a symlink maybe? Or put the Make.* in /usr/lib64/go/src ???

/me is a newbie packager!

(In reply to comment #23)
> Guys, for what is worth, here's a spec that builds.
> http://fedorapeople.org/~renich/go.spec

err... sorry, for the sake of order, I changed the location to:
http://fedorapeople.org/~renich/SPECS/go.spec
http://fedorapeople.org/~renich/SRPMS/go-20110120-3.fc14.src.rpm

Thank you Renich. This version does indeed build in koji.


rpmlint has a few complaints about it however.

go.x86_64: E: statically-linked-binary /usr/bin/goinstall
go.x86_64: E: statically-linked-binary /usr/bin/ebnflint
go.x86_64: E: statically-linked-binary /usr/bin/gofmt
go.x86_64: E: statically-linked-binary /usr/bin/godoc
go.x86_64: E: statically-linked-binary /usr/bin/govet
go.x86_64: E: statically-linked-binary /usr/bin/goyacc
go.x86_64: E: statically-linked-binary /usr/bin/cgo
go.x86_64: E: statically-linked-binary /usr/bin/hgpatch

4 packages and 0 specfiles checked; 8 errors, 325 warnings.

The above errors should really be fixed, http://fedoraproject.org/wiki/Packaging/Guidelines#Staticly_Linking_Executables

A bunch of static libraries were built, and should be in a -static package rather than the main one if included at all. http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries

Many of the binaries are without manual pages or documentation. (Upstream?)


Trivial .spec fix?

go.x86_64: W: spurious-executable-perm /usr/share/doc/go-20110120/progs/run
go.x86_64: W: spurious-executable-perm /usr/share/doc/go-20110120/prog.sh
go.x86_64: W: spurious-executable-perm /usr/share/doc/go-20110120/makehtml
go.x86_64: W: non-conffile-in-etc /etc/bash_completion.d/go
go.x86_64: W: spurious-executable-perm /usr/share/doc/go-20110120/codelab/wiki/test.sh

These subpackages should likely include a LICENSE file if nothing else:

go-emacs.x86_64: W: no-documentation
go-vim.x86_64: W: no-documentation

The static libraries you're seeing are most likely the go runtime (used for linking at compile-time). They're required to build anything useful with Go; distributing them separately would just cripple the primary package. The Go build system doesn't support building and linking packages (ie. the runtime) as shared libraries yet, and according to Ian a few days ago, it isn't even on the roadmap right now:

https://groups.google.com/d/msg/golang-nuts/LGk2Fw1EGY4/1UB88cSJClYJ

The statically-linked binaries you called out are actually written in Go, and are not linked against system libraries, but are instead linked against the static libraries above.

So in both cases, Go is behaving as designed. :) Remember, this is a complete compiler toolchain, it's not a typical application.

(In reply to comment #25)
> Thank you Renich. This version does indeed build in koji.
> 
> 
> rpmlint has a few complaints about it however.
> 
> go.x86_64: E: statically-linked-binary /usr/bin/goinstall
> go.x86_64: E: statically-linked-binary /usr/bin/ebnflint
> go.x86_64: E: statically-linked-binary /usr/bin/gofmt
> go.x86_64: E: statically-linked-binary /usr/bin/godoc
> go.x86_64: E: statically-linked-binary /usr/bin/govet
> go.x86_64: E: statically-linked-binary /usr/bin/goyacc
> go.x86_64: E: statically-linked-binary /usr/bin/cgo
> go.x86_64: E: statically-linked-binary /usr/bin/hgpatch
> 
> 4 packages and 0 specfiles checked; 8 errors, 325 warnings.
> 
> The above errors should really be fixed,
> http://fedoraproject.org/wiki/Packaging/Guidelines#Staticly_Linking_Executables
> 
> A bunch of static libraries were built, and should be in a -static package
> rather than the main one if included at all.
> http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries

Well, I'll see where your discussion with Ed Marshall culminates; not sure of what to do.

> Many of the binaries are without manual pages or documentation. (Upstream?)

Yeah, upstream... let's see if it's possible to generate documentation.
 
> Trivial .spec fix?
> 
> go.x86_64: W: spurious-executable-perm /usr/share/doc/go-20110120/progs/run
> go.x86_64: W: spurious-executable-perm /usr/share/doc/go-20110120/prog.sh
> go.x86_64: W: spurious-executable-perm /usr/share/doc/go-20110120/makehtml
> go.x86_64: W: non-conffile-in-etc /etc/bash_completion.d/go
> go.x86_64: W: spurious-executable-perm
> /usr/share/doc/go-20110120/codelab/wiki/test.sh

Done, I eliminated, for now, the executable files from docs and renamed bash_completion/go to go.bash

> These subpackages should likely include a LICENSE file if nothing else:
> 
> go-emacs.x86_64: W: no-documentation
> go-vim.x86_64: W: no-documentation

done.

Posted:
http://renich.fedorapeople.org/SPECS/go.spec
http://renich.fedorapeople.org/SRPMS/go-20110120-4.fc14.src.rpm

(In reply to comment #27)
> > Many of the binaries are without manual pages or documentation. (Upstream?)
> 
> Yeah, upstream... let's see if it's possible to generate documentation.

I think the "godoc" command can provides documentation for go's commands also.

> > go-emacs.x86_64: W: no-documentation

I think it should be named emacs-go to conform with the Packaging:Emacs
naming guidelines.

(In reply to comment #28)
> I think the "godoc" command can provides documentation for go's commands also.

I have added info on this to README.Fedora

> I think it should be named emacs-go to conform with the Packaging:Emacs
> naming guidelines.

Yes; thank You. I've changed not only emacs but vim to reflect this:
emacs-go
vim-go

Please, review:
http://renich.fedorapeople.org/SPECS/go.spec
http://renich.fedorapeople.org/SRPMS/go-20110120-6.fc14.src.rpm

Is it really a good idea ask folks to report bugs directly to you via email in README.Fedora?  What happens if the package changes ownership?  How will any potential comaintainers see bug reports?  Will you run your own bug tracker as well?

(In reply to comment #30)
> Is it really a good idea ask folks to report bugs directly to you via email in
> README.Fedora?  What happens if the package changes ownership?  How will any
> potential comaintainers see bug reports?  Will you run your own bug tracker as
> well?

Oh yeah, that...

For the time being, I have a temporal repo and that part of the readme is just for the moment; if somebody installs it.

As soon as this review passes, I will remove that.

Sorry for not being clear about this.

About the name. It has been suggested on the #fedora-devel IRC channel that the name could be golang.

Can go devs input on this?

(In reply to comment #32)
> About the name. It has been suggested on the #fedora-devel IRC channel that the
> name could be golang.

That was me - maybe it was more a "reality check" question. :)

But having heard that there are many more potential packages
in the pipeline (http://godashboard.appspot.com/project?tag=cgo)
it maybe be good to use "go-" as a prefix for naming go libraries
and bindings perhaps.

Another comment was that somebody should start drafting packaging guidelines. If anybody in the list has some experience with this or has some pointers, I'm willing to do the reading, thinking and writing necessary.

Please show me the way, Fedorian Masters! ;)

For the sake of clarity, there's this:
http://code.google.com/p/go/issues/detail?id=1239#c3

So, given that, what do you think about /usr/lib64/go/src?

There has recently been some discussion on the golang-nuts mailing list about packaging Go for Ubuntu and OpenSUSE. See http://groups.google.com/group/golang-nuts/browse_thread/thread/a378126d7d061f0e .

Just a question -- who'll be the primary maintainer of this package? I see specs from both Renich and Michael.

(In reply to comment #37)
> Just a question -- who'll be the primary maintainer of this package? I see
> specs from both Renich and Michael.

I'm a total newbie on this. I just got sponsored for synapse and libzeitgeist. I have no objection on being co-maintainer.

I would be happy to maintain this package. I maintain several Fedora packages and anticipate using Go a lot in the near future. I volunteer to be the primary maintainer with Renich as a co-maintainer.

(In reply to comment #39)
> I would be happy to maintain this package. I maintain several Fedora packages
> and anticipate using Go a lot in the near future. I volunteer to be the primary
> maintainer with Renich as a co-maintainer.

This would be awesome! ;)

ping?

Something seems to have changed. Have you tried to build on Fedora 15 with GCC 4.6.0?

I get the following error when trying to build the package. I think -j2 is supposed to be a make argument; I can't find where it is being added to quietgcc's command line.

[...]
rm -f *.[568vq] parser.out peano.out tree.out


%%%% making lib9 %%%%

quietgcc -I"/home/mike/Source/rpms/BUILD/go-20110201.1/include" -j2 -ggdb -c "/home/mike/Source/rpms/BUILD/go-20110201.1/src/lib9/_p9dir.c"
quietgcc -I"/home/mike/Source/rpms/BUILD/go-20110201.1/include" -j2 -ggdb -c "/home/mike/Source/rpms/BUILD/go-20110201.1/src/lib9/_exits.c"
quietgcc -I"/home/mike/Source/rpms/BUILD/go-20110201.1/include" -j2 -ggdb -c "/home/mike/Source/rpms/BUILD/go-20110201.1/src/lib9/argv0.c"
quietgcc -I"/home/mike/Source/rpms/BUILD/go-20110201.1/include" -j2 -ggdb -c "/home/mike/Source/rpms/BUILD/go-20110201.1/src/lib9/atoi.c"
gcc: error: unrecognized option '-j2'
gcc: error: unrecognized option '-j2'
make: *** [_p9dir.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [_exits.o] Error 1
gcc: error: unrecognized option '-j2'
gcc: error: unrecognized option '-j2'
make: *** [argv0.o] Error 1
make: *** [atoi.o] Error 1
make: *** wait: No child processes.  Stop.
error: Bad exit status from /tmp/rpm-tmp.8yRNJI (%build)

(In reply to comment #42)
> I get the following error when trying to build the package. I think -j2 is
> supposed to be a make argument; I can't find where it is being added to
> quietgcc's command line.

Probably from _smp_mflags?

(In reply to comment #43)
>> I get the following error when trying to build the package. I think -j2 is
>> supposed to be a make argument; I can't find where it is being added to
>> quietgcc's command line.

> Probably from _smp_mflags?

That is correct. I had to remove "_smp_mflags" and "--build-id."

I also noticed that the RPM specification builds using "all.bash". "make.bash" is much faster because it does not run the extensive test suite. Should we use "make.bash"?

Finally, it might be nice to be able to install both the 32-bit and 64-bit Go compilers simultaneously. This is a bit odd, though I think it would be possible.

(In reply to comment #44)
> > Probably from _smp_mflags?
> 
> That is correct. I had to remove "_smp_mflags" and "--build-id."
> 
> I also noticed that the RPM specification builds using "all.bash". "make.bash"
> is much faster because it does not run the extensive test suite. Should we use
> "make.bash"?
> 
> Finally, it might be nice to be able to install both the 32-bit and 64-bit Go
> compilers simultaneously. This is a bit odd, though I think it would be
> possible.

The docs separation is important too. Tell me what can I do to help.

Spec URL: http://www.flyn.org/SRPMS/go.spec
SRPM URL: http://www.flyn.org/SRPMS/go-r59-1.fc15.src.rpm

- Updated to release.r59
- Use make.bash, not all.bash, to speed up build
- Build both 32- and 64-bit compilers
- Remove _smp_mflags and --build-id; broke build on F15
- Small formatting fixes

Spec URL: http://www.flyn.org/SRPMS/go.spec
SRPM URL: http://www.flyn.org/SRPMS/go-r59-2.fc15.src.rpm

- Require mercurial to build

Spec URL: http://www.flyn.org/SRPMS/go.spec
SRPM URL: http://www.flyn.org/SRPMS/go-r59-3.fc15.src.rpm

- Require glibc-devel.i686 on x86_64
- Do not try to build 64-bit on i686

Anyone still working on this? There's been a lot of changes in the Go source tree of late. A plan has to be made to package go.crypto, go.net, etc. separately.

well, I'm definitelly interested in co-maintaining. W. Michael Petullo is supposed to be the main maintainer... but hasn't published yet.

The Go 1 release is approaching. Any updates here?

I am thinking of putting together a spec file so that multiple versions of the Go SDK can be installed in parallel. It will allow users to switch between them using alternatives like you can when multiple Java SDKs are installed.

It would make it easy to test out weeklies in between stable releases of Go 1.

We could then also package extra stuff like go.crypto, goprotobuf, etc. to work with the releases they are compatible with.

Potentially this could also allow switching between a /usr/bin/go that uses gccgo instead of [568]g by default.

Another thought: it would be useful to make an ARM package for the Fedora ARM on Raspberry Pi effort.

Go for it. I have not had the time to update this proposed package in a while. It sounds like you have some good ideas. I'd be happy to transition into a role of reviewer.

(In reply to comment #51)
> The Go 1 release is approaching. Any updates here?
> 
> I am thinking of putting together a spec file so that multiple versions of the
> Go SDK can be installed in parallel. It will allow users to switch between them
> using alternatives like you can when multiple Java SDKs are installed.
> 
> It would make it easy to test out weeklies in between stable releases of Go 1.
> 
> We could then also package extra stuff like go.crypto, goprotobuf, etc. to work
> with the releases they are compatible with.
> 
> Potentially this could also allow switching between a /usr/bin/go that uses
> gccgo instead of [568]g by default.
> 
> Another thought: it would be useful to make an ARM package for the Fedora ARM
> on Raspberry Pi effort.

Let me know how can I help. I can help co-maintaining this one. ;)

A few ideas:

Since godoc needs all the source, I was thinking of splitting off a go-doc package that has the godoc binary and the sources.

As far as I understand, cross-compiling is easy these days, so we could build:

default packages:

go.i686 <-- contains 386 packages and 8g, 8c, 8l
go.x86_64 <-- contains amd64 packages and 6g, 6c, 6l
go.armv5tel <-- contains arm packages and 5g, 5c, 5l, GOARM=5
go.armv7hl <-- contains arm packages and 5g, 5c, 5l, GOARM=6

and then all the cross-compilers. maybe it's not necessary to build all combinations.

go-amd64.i686 (useful for testing cross-compiler building infrastructure)
go-386.x86_64 (useful for testing cross-compiler building infrastructure)

go-armv5tel.i686
go-armv5tel.x86_64

go-armv7hl.i686 (or we could call this go-arm6?)
go-armv7hl.x86_64

go-armv5tel could be called go-arm5.

go-armv7hl could be called go-arm6.

Feedback please?

Just a question - is there a need for another go compiler when one is already in gcc?

The two compilers have different aims.

I'm guessing here, but I think that after Go 1 we might see releases of the Google version every few weeks, mostly with bugfixes and backwards-compatible API enhancements. Many people will want to use these releases before the new API features make it in into the slower release cycle of GCC.

Even more guessing: At some point in the distant future (a few years), there will be a pre-Go 2 version of the Google compiler where they will try out new language features before implementing it in the GCC version.

http://blog.golang.org/2011/10/preview-of-go-version-1.html

So what's the status here?  If someone else is going to submit their package for review, they should do so in a new ticket and close this one.

ping

is anybody working on this one?

I guess I will try my hand at packaging this.

(In reply to comment #60)
> I guess I will try my hand at packaging this.

In which case, please start a new review request, and mark this one as a duplicate. All of us Cc:ed here will then be able to follow the new review request automatically.

*** This bug has been marked as a duplicate of bug 950281 ***

(In reply to comment #61)
> (In reply to comment #60)
> > I guess I will try my hand at packaging this.
> 
> All of us Cc:ed here will then be able to follow the new review
> request automatically.

Nope, unfortunately. This is a long-standing (for years) Bugzilla issue which nobody is able to fix.