Bug 652987 - Review Request: go - The Go programming language
Review Request: go - The Go programming language
Status: CLOSED DUPLICATE of bug 950281
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kyle McMartin
Fedora Extras Quality Assurance
AwaitingSubmitter
:
: 610934 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-13 18:31 EST by W. Michael Petullo
Modified: 2015-08-31 23:53 EDT (History)
25 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-09 22:19:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description W. Michael Petullo 2010-11-13 18:31:20 EST
Spec URL: http://www.flyn.org/SRPMS/go.spec
SRPM URL: http://www.flyn.org/SRPMS/go-20101102-1.fc14.src.rpm
Description:
The Go programming language is an open source project to make programmers
more productive. Go is expressive, concise, clean, and efficient. Its
concurrency mechanisms make it easy to write programs that get the most
out of multicore and networked machines, while its novel type system
enables flexible and modular program construction. Go compiles quickly
to machine code yet has the convenience of garbage collection and the
power of run-time reflection. It's a fast, statically typed, compiled
language that feels like a dynamically typed, interpreted language.
Comment 1 W. Michael Petullo 2010-11-13 18:31:47 EST
*** Bug 610934 has been marked as a duplicate of this bug. ***
Comment 2 W. Michael Petullo 2010-11-13 18:34:20 EST
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.
Comment 3 Ed Marshall 2010-11-13 22:45:09 EST
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
Comment 4 Brandon 2010-11-14 09:18:04 EST
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.
Comment 5 Jason Tibbitts 2010-11-14 10:29:14 EST
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).
Comment 6 Michel Alexandre Salim 2010-11-14 17:43:02 EST
Will review once the legal situation is clarified. FWIW I think Google will be willing to relicense; WebM was in this situation earlier on.
Comment 7 Tom "spot" Callaway 2010-11-15 09:04:00 EST
Emailed cdibona @ Google.
Comment 8 Renich Bon Ciric 2011-01-19 01:09:37 EST
any word on this?
Comment 9 Tom "spot" Callaway 2011-01-19 10:29:48 EST
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).
Comment 10 W. Michael Petullo 2011-01-19 11:47:16 EST
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."
Comment 11 Tom "spot" Callaway 2011-01-19 12:22:52 EST
Lifting FE-Legal
Comment 12 d. johnson 2011-01-20 23:18:16 EST
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'
Comment 13 W. Michael Petullo 2011-01-20 23:33:59 EST
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
Comment 14 Renich Bon Ciric 2011-01-20 23:53:56 EST
(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.
Comment 15 Renich Bon Ciric 2011-01-20 23:56:26 EST
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
Comment 16 W. Michael Petullo 2011-01-21 17:42:55 EST
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.
Comment 17 d. johnson 2011-01-21 20:27:48 EST
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.
Comment 18 W. Michael Petullo 2011-01-23 14:35:31 EST
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
Comment 19 Renich Bon Ciric 2011-01-25 00:11:16 EST
Can somebody link this request to this bug, please?
http://code.google.com/p/go/issues/detail?id=1280
Comment 20 Russ Cox 2011-01-25 07:03:58 EST
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@swtch.com
Comment 21 Ed Marshall 2011-01-25 08:39:03 EST
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.)
Comment 22 Russ Cox 2011-01-25 09:55:28 EST
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.
Comment 23 Renich Bon Ciric 2011-01-27 13:48:18 EST
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!
Comment 24 Renich Bon Ciric 2011-01-27 18:46:45 EST
(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
Comment 25 d. johnson 2011-01-27 20:33:01 EST
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
Comment 26 Ed Marshall 2011-01-27 20:56:22 EST
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.
Comment 27 Renich Bon Ciric 2011-01-28 04:49:33 EST
(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
Comment 28 Jens Petersen 2011-01-28 07:08:15 EST
(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.
Comment 29 Renich Bon Ciric 2011-01-31 18:00:10 EST
(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
Comment 30 Jason Tibbitts 2011-01-31 18:29:46 EST
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?
Comment 31 Renich Bon Ciric 2011-01-31 19:08:53 EST
(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.
Comment 32 Renich Bon Ciric 2011-01-31 19:26:23 EST
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?
Comment 33 Jens Petersen 2011-01-31 20:40:31 EST
(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.
Comment 34 Renich Bon Ciric 2011-01-31 23:09:19 EST
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! ;)
Comment 35 Renich Bon Ciric 2011-02-02 03:14:15 EST
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?
Comment 36 W. Michael Petullo 2011-02-04 12:39:43 EST
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 .
Comment 37 Michel Alexandre Salim 2011-04-06 07:46:59 EDT
Just a question -- who'll be the primary maintainer of this package? I see specs from both Renich and Michael.
Comment 38 Renich Bon Ciric 2011-04-06 13:50:20 EDT
(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.
Comment 39 W. Michael Petullo 2011-04-06 14:19:03 EDT
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.
Comment 40 Renich Bon Ciric 2011-04-06 15:20:45 EDT
(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! ;)
Comment 41 Renich Bon Ciric 2011-05-17 03:19:56 EDT
ping?
Comment 42 W. Michael Petullo 2011-06-22 16:57:40 EDT
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)
Comment 43 Jens Petersen 2011-06-22 20:19:55 EDT
(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?
Comment 44 W. Michael Petullo 2011-06-23 00:23:24 EDT
(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.
Comment 45 Renich Bon Ciric 2011-06-24 21:26:33 EDT
(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.
Comment 46 W. Michael Petullo 2011-08-30 15:23:04 EDT
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
Comment 47 W. Michael Petullo 2011-08-31 11:46:45 EDT
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
Comment 48 W. Michael Petullo 2011-08-31 15:04:15 EDT
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
Comment 49 Albert Strasheim 2012-02-08 00:24:02 EST
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.
Comment 50 Renich Bon Ciric 2012-02-08 01:01:44 EST
well, I'm definitelly interested in co-maintaining. W. Michael Petullo is supposed to be the main maintainer... but hasn't published yet.
Comment 51 Albert Strasheim 2012-03-14 02:58:49 EDT
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.
Comment 52 W. Michael Petullo 2012-03-14 11:47:27 EDT
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.
Comment 53 Renich Bon Ciric 2012-03-14 19:12:27 EDT
(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. ;)
Comment 54 Albert Strasheim 2012-03-15 12:12:11 EDT
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?
Comment 55 Dan Horák 2012-03-15 12:51:30 EDT
Just a question - is there a need for another go compiler when one is already in gcc?
Comment 56 Albert Strasheim 2012-03-15 14:20:02 EDT
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
Comment 57 Jason Tibbitts 2012-04-24 20:17:17 EDT
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.
Comment 58 Renich Bon Ciric 2012-06-28 04:18:15 EDT
ping
Comment 59 Renich Bon Ciric 2012-08-28 07:02:32 EDT
is anybody working on this one?
Comment 60 Adam Goode 2013-03-31 22:54:59 EDT
I guess I will try my hand at packaging this.
Comment 61 Michel Alexandre Salim 2013-04-02 08:44:11 EDT
(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.
Comment 62 Adam Goode 2013-04-09 22:19:07 EDT

*** This bug has been marked as a duplicate of bug 950281 ***
Comment 63 Peter Lemenkov 2013-04-10 01:07:15 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.