Re: new: lang/go - take 2
Go 1 was released yesterday - the attached is an updated port. Any further comments? Any oks? On Monday 26 March 2012, Joel Sing wrote: A new version - this updates the port to the 2012-03-22 weekly release (effectively Go v1 RC2) and fixes the issue with the regress path for the go binary. ok? On Friday 23 March 2012, Joel Sing wrote: Attached is an updated version of the port for Go: - Version numbering is now 1.0preMMDD as suggested by sthen. - Fixed PLIST issue so that the port now works correctly on both amd64 and i386. - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be able to use the sysarch() syscall in order to setup TLS. ok? On Thursday 22 March 2012, Joel Sing wrote: The attached is an initial port for the Go programming language (www.golang.org). A little background - Go is approaching a Go version1 release and at that point it will have a stable API. Unfortunately, for several reasons Go version 1 will not be officially supported on OpenBSD, however there are only a few issues that prevent this - the diffs included in the port address known outstanding issues for the OpenBSD runtime, which will let us provide a working port. Open questions: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. 3. License - Go is released under a BSD-style license, however some parts (like the documentation) are under other licenses (Creative Commons Attribution 3.0 License). How do we handle this? -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand go-port.tar.gz Description: application/tgz
Re: new: lang/go - take 2
I got following error on any Go example from http://golang.org ~/tmp/go$ go build pi.go # runtime /usr/local/go/src/pkg/runtime/extern.go:121: undefined: defaultGoroot /usr/local/go/src/pkg/runtime/extern.go:130: undefined: theVersion /usr/local/go/src/pkg/runtime/extern.go:135: undefined: theGoos /usr/local/go/src/pkg/runtime/extern.go:135: cannot use theGoos as type string in const initializer /usr/local/go/src/pkg/runtime/extern.go:139: undefined: theGoarch /usr/local/go/src/pkg/runtime/extern.go:139: cannot use theGoarch as type string in const initializer ~/tmp/go$ On 01:05 Fri 30 Mar , Joel Sing wrote: Go 1 was released yesterday - the attached is an updated port. Any further comments? Any oks? On Monday 26 March 2012, Joel Sing wrote: A new version - this updates the port to the 2012-03-22 weekly release (effectively Go v1 RC2) and fixes the issue with the regress path for the go binary. ok? On Friday 23 March 2012, Joel Sing wrote: Attached is an updated version of the port for Go: - Version numbering is now 1.0preMMDD as suggested by sthen. - Fixed PLIST issue so that the port now works correctly on both amd64 and i386. - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be able to use the sysarch() syscall in order to setup TLS. ok? On Thursday 22 March 2012, Joel Sing wrote: The attached is an initial port for the Go programming language (www.golang.org). A little background - Go is approaching a Go version1 release and at that point it will have a stable API. Unfortunately, for several reasons Go version 1 will not be officially supported on OpenBSD, however there are only a few issues that prevent this - the diffs included in the port address known outstanding issues for the OpenBSD runtime, which will let us provide a working port. Open questions: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. 3. License - Go is released under a BSD-style license, however some parts (like the documentation) are under other licenses (Creative Commons Attribution 3.0 License). How do we handle this? -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand
Re: new: lang/go - take 2
On Friday 30 March 2012, Sergey Bronnikov wrote: I got following error on any Go example from http://golang.org ~/tmp/go$ go build pi.go # runtime /usr/local/go/src/pkg/runtime/extern.go:121: undefined: defaultGoroot /usr/local/go/src/pkg/runtime/extern.go:130: undefined: theVersion /usr/local/go/src/pkg/runtime/extern.go:135: undefined: theGoos /usr/local/go/src/pkg/runtime/extern.go:135: cannot use theGoos as type string in const initializer /usr/local/go/src/pkg/runtime/extern.go:139: undefined: theGoarch /usr/local/go/src/pkg/runtime/extern.go:139: cannot use theGoarch as type string in const initializer ~/tmp/go$ Ugh, looks like I messed up the PLIST. Try the attached version instead :) On 01:05 Fri 30 Mar , Joel Sing wrote: Go 1 was released yesterday - the attached is an updated port. Any further comments? Any oks? On Monday 26 March 2012, Joel Sing wrote: A new version - this updates the port to the 2012-03-22 weekly release (effectively Go v1 RC2) and fixes the issue with the regress path for the go binary. ok? On Friday 23 March 2012, Joel Sing wrote: Attached is an updated version of the port for Go: - Version numbering is now 1.0preMMDD as suggested by sthen. - Fixed PLIST issue so that the port now works correctly on both amd64 and i386. - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be able to use the sysarch() syscall in order to setup TLS. ok? On Thursday 22 March 2012, Joel Sing wrote: The attached is an initial port for the Go programming language (www.golang.org). A little background - Go is approaching a Go version1 release and at that point it will have a stable API. Unfortunately, for several reasons Go version 1 will not be officially supported on OpenBSD, however there are only a few issues that prevent this - the diffs included in the port address known outstanding issues for the OpenBSD runtime, which will let us provide a working port. Open questions: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. 3. License - Go is released under a BSD-style license, however some parts (like the documentation) are under other licenses (Creative Commons Attribution 3.0 License). How do we handle this? -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand go-port.tar.gz Description: application/tgz
Re: new: lang/go - take 2
On 2012/03/30 01:05, Joel Sing wrote:
Go 1 was released yesterday - the attached is an updated port.
Any further comments? Any oks?
The diff below rolls the files which are common between i386/amd64
(just with a different directory name) into PLIST using a substituted
variable for the dir name, this should make it a bit simpler to fix
up the plists after running make update-plist when updating the
port.
--- Makefile
+++ Makefile
@@ -28,6 +28,7 @@ BUILD_DEPENDS = shells/bash
SEPARATE_BUILD = simple
CONFIGURE_STYLE = None
+SUBST_VARS = GOCFG
WRKDIST = ${WRKDIR}/go
WRKSRC = ${WRKDIST}/src
@@ -45,6 +46,7 @@ GOARCH = 386
PKG_ARGS +=-Damd64=0
PKG_ARGS +=-Di386=1
.endif
+GOCFG =/${GOOS}_${GOARCH}
do-configure:
. if ${GOARCH} == unknown
--- pkg/PFRAG.amd64
+++ pkg/PFRAG.amd64
@@ -1,182 +1,16 @@
@comment $OpenBSD$
-go/pkg/obj/openbsd_amd64/
-go/pkg/obj/openbsd_amd64/lib9.a
-go/pkg/obj/openbsd_amd64/libbio.a
-go/pkg/obj/openbsd_amd64/libcc.a
-go/pkg/obj/openbsd_amd64/libgc.a
-go/pkg/obj/openbsd_amd64/libmach.a
-go/pkg/openbsd_amd64/
-go/pkg/openbsd_amd64/archive/
-go/pkg/openbsd_amd64/archive/tar.a
-go/pkg/openbsd_amd64/archive/zip.a
-go/pkg/openbsd_amd64/bufio.a
-go/pkg/openbsd_amd64/bytes.a
-go/pkg/openbsd_amd64/cgocall.h
-go/pkg/openbsd_amd64/compress/
-go/pkg/openbsd_amd64/compress/bzip2.a
-go/pkg/openbsd_amd64/compress/flate.a
-go/pkg/openbsd_amd64/compress/gzip.a
-go/pkg/openbsd_amd64/compress/lzw.a
-go/pkg/openbsd_amd64/compress/zlib.a
-go/pkg/openbsd_amd64/container/
-go/pkg/openbsd_amd64/container/heap.a
-go/pkg/openbsd_amd64/container/list.a
-go/pkg/openbsd_amd64/container/ring.a
-go/pkg/openbsd_amd64/crypto/
-go/pkg/openbsd_amd64/crypto.a
-go/pkg/openbsd_amd64/crypto/aes.a
-go/pkg/openbsd_amd64/crypto/cipher.a
-go/pkg/openbsd_amd64/crypto/des.a
-go/pkg/openbsd_amd64/crypto/dsa.a
-go/pkg/openbsd_amd64/crypto/ecdsa.a
-go/pkg/openbsd_amd64/crypto/elliptic.a
-go/pkg/openbsd_amd64/crypto/hmac.a
-go/pkg/openbsd_amd64/crypto/md5.a
-go/pkg/openbsd_amd64/crypto/rand.a
-go/pkg/openbsd_amd64/crypto/rc4.a
-go/pkg/openbsd_amd64/crypto/rsa.a
-go/pkg/openbsd_amd64/crypto/sha1.a
-go/pkg/openbsd_amd64/crypto/sha256.a
-go/pkg/openbsd_amd64/crypto/sha512.a
-go/pkg/openbsd_amd64/crypto/subtle.a
-go/pkg/openbsd_amd64/crypto/tls.a
-go/pkg/openbsd_amd64/crypto/x509/
-go/pkg/openbsd_amd64/crypto/x509.a
-go/pkg/openbsd_amd64/crypto/x509/pkix.a
-go/pkg/openbsd_amd64/database/
-go/pkg/openbsd_amd64/database/sql/
-go/pkg/openbsd_amd64/database/sql.a
-go/pkg/openbsd_amd64/database/sql/driver.a
-go/pkg/openbsd_amd64/debug/
-go/pkg/openbsd_amd64/debug/dwarf.a
-go/pkg/openbsd_amd64/debug/elf.a
-go/pkg/openbsd_amd64/debug/gosym.a
-go/pkg/openbsd_amd64/debug/macho.a
-go/pkg/openbsd_amd64/debug/pe.a
-go/pkg/openbsd_amd64/encoding/
-go/pkg/openbsd_amd64/encoding/ascii85.a
-go/pkg/openbsd_amd64/encoding/asn1.a
-go/pkg/openbsd_amd64/encoding/base32.a
-go/pkg/openbsd_amd64/encoding/base64.a
-go/pkg/openbsd_amd64/encoding/binary.a
-go/pkg/openbsd_amd64/encoding/csv.a
-go/pkg/openbsd_amd64/encoding/gob.a
-go/pkg/openbsd_amd64/encoding/hex.a
-go/pkg/openbsd_amd64/encoding/json.a
-go/pkg/openbsd_amd64/encoding/pem.a
-go/pkg/openbsd_amd64/encoding/xml.a
-go/pkg/openbsd_amd64/errors.a
-go/pkg/openbsd_amd64/expvar.a
-go/pkg/openbsd_amd64/flag.a
-go/pkg/openbsd_amd64/fmt.a
-go/pkg/openbsd_amd64/go/
-go/pkg/openbsd_amd64/go/ast.a
-go/pkg/openbsd_amd64/go/build.a
-go/pkg/openbsd_amd64/go/doc.a
-go/pkg/openbsd_amd64/go/parser.a
-go/pkg/openbsd_amd64/go/printer.a
-go/pkg/openbsd_amd64/go/scanner.a
-go/pkg/openbsd_amd64/go/token.a
-go/pkg/openbsd_amd64/hash/
-go/pkg/openbsd_amd64/hash.a
-go/pkg/openbsd_amd64/hash/adler32.a
-go/pkg/openbsd_amd64/hash/crc32.a
-go/pkg/openbsd_amd64/hash/crc64.a
-go/pkg/openbsd_amd64/hash/fnv.a
-go/pkg/openbsd_amd64/html/
-go/pkg/openbsd_amd64/html.a
-go/pkg/openbsd_amd64/html/template.a
-go/pkg/openbsd_amd64/image/
-go/pkg/openbsd_amd64/image.a
-go/pkg/openbsd_amd64/image/color.a
-go/pkg/openbsd_amd64/image/draw.a
-go/pkg/openbsd_amd64/image/gif.a
-go/pkg/openbsd_amd64/image/jpeg.a
-go/pkg/openbsd_amd64/image/png.a
-go/pkg/openbsd_amd64/index/
-go/pkg/openbsd_amd64/index/suffixarray.a
-go/pkg/openbsd_amd64/io/
-go/pkg/openbsd_amd64/io.a
-go/pkg/openbsd_amd64/io/ioutil.a
-go/pkg/openbsd_amd64/log/
-go/pkg/openbsd_amd64/log.a
-go/pkg/openbsd_amd64/log/syslog.a
-go/pkg/openbsd_amd64/math/
-go/pkg/openbsd_amd64/math.a
-go/pkg/openbsd_amd64/math/big.a
-go/pkg/openbsd_amd64/math/cmplx.a
-go/pkg/openbsd_amd64/math/rand.a
-go/pkg/openbsd_amd64/mime/
-go/pkg/openbsd_amd64/mime.a
-go/pkg/openbsd_amd64/mime/multipart.a
-go/pkg/openbsd_amd64/net/
-go/pkg/openbsd_amd64/net.a
-go/pkg/openbsd_amd64/net/http/
-go/pkg/openbsd_amd64/net/http.a
-go/pkg/openbsd_amd64/net/http/cgi.a
-go/pkg/openbsd_amd64/net/http/fcgi.a
-go/pkg/openbsd_amd64/net/http/httptest.a
Re: new: lang/go - take 2
On Friday 30 March 2012, Stuart Henderson wrote: On 2012/03/30 01:05, Joel Sing wrote: Go 1 was released yesterday - the attached is an updated port. Any further comments? Any oks? The diff below rolls the files which are common between i386/amd64 (just with a different directory name) into PLIST using a substituted variable for the dir name, this should make it a bit simpler to fix up the plists after running make update-plist when updating the port. Ah, that's neat and shrinks the PFRAG files considerably. Thanks! Updated port attached which combines this with the corrected PLIST. -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand go-port.tar.gz Description: application/tgz
Re: new: lang/go - take 2
On 03:10 Fri 30 Mar , Joel Sing wrote: Updated port attached which combines this with the corrected PLIST. same errors for me: ~/tmp/go$ go build pi.go # runtime /usr/local/go/src/pkg/runtime/extern.go:121: undefined: defaultGoroot /usr/local/go/src/pkg/runtime/extern.go:130: undefined: theVersion /usr/local/go/src/pkg/runtime/extern.go:135: undefined: theGoos /usr/local/go/src/pkg/runtime/extern.go:135: cannot use theGoos as type string in const initializer /usr/local/go/src/pkg/runtime/extern.go:139: undefined: theGoarch /usr/local/go/src/pkg/runtime/extern.go:139: cannot use theGoarch as type string in const initializer ~/tmp/go$
Re: new: lang/go - take 2
On Fri, Mar 30, 2012 at 03:10:45AM +1100, Joel Sing wrote: On Friday 30 March 2012, Stuart Henderson wrote: On 2012/03/30 01:05, Joel Sing wrote: Go 1 was released yesterday - the attached is an updated port. Any further comments? Any oks? The diff below rolls the files which are common between i386/amd64 (just with a different directory name) into PLIST using a substituted variable for the dir name, this should make it a bit simpler to fix up the plists after running make update-plist when updating the port. Ah, that's neat and shrinks the PFRAG files considerably. Thanks! Updated port attached which combines this with the corrected PLIST. Tested on i386, with and without systrace. ALL TESTS PASSED :) -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: new: lang/go - take 2
A new version - this updates the port to the 2012-03-22 weekly release (effectively Go v1 RC2) and fixes the issue with the regress path for the go binary. ok? On Friday 23 March 2012, Joel Sing wrote: Attached is an updated version of the port for Go: - Version numbering is now 1.0preMMDD as suggested by sthen. - Fixed PLIST issue so that the port now works correctly on both amd64 and i386. - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be able to use the sysarch() syscall in order to setup TLS. ok? On Thursday 22 March 2012, Joel Sing wrote: The attached is an initial port for the Go programming language (www.golang.org). A little background - Go is approaching a Go version1 release and at that point it will have a stable API. Unfortunately, for several reasons Go version 1 will not be officially supported on OpenBSD, however there are only a few issues that prevent this - the diffs included in the port address known outstanding issues for the OpenBSD runtime, which will let us provide a working port. Open questions: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. 3. License - Go is released under a BSD-style license, however some parts (like the documentation) are under other licenses (Creative Commons Attribution 3.0 License). How do we handle this? -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand go-port.tar.gz Description: application/tgz
Re: new: lang/go - take 2
On Mon, Mar 26, 2012 at 01:16:59AM +1100, Joel Sing wrote: On Friday 23 March 2012, Juan Francisco Cantero Hurtado wrote: On Fri, Mar 23, 2012 at 01:08:48AM +1100, Joel Sing wrote: Attached is an updated version of the port for Go: - Version numbering is now 1.0preMMDD as suggested by sthen. - Fixed PLIST issue so that the port now works correctly on both amd64 and i386. - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be able to use the sysarch() syscall in order to setup TLS. ok? Thanks for the testing and feedback. make package works perfect with USE_SYSTRACE. Just a warning in the fake step: strip: /usr/ports/pobj/go-1.0pre20120313/fake-i386/usr/local/go/pkg/tool/openbsd_3 86/pprof: File format not recognized. pprof is a Perl script, so there is no surprise that strip cannot work out what to do. Not sure if there is some easy way to tell strip to not touch this file. I don't know if this is the correct behavior or not, but make regress uses the go command installed on /usr/local, not the go binary in the build directory. No, that would be a bug - fixed, thanks. Your last port is working OK. All tests passed. make regress with and without go installed, both fail. I've attached the logs of make regress. This is strange - it works fine for me on both amd64 and i386 . The failing part is: # Testing packages. # unicode/utf16 mkdir /tmp/go-build584473652/unicode/utf16/_test/unicode/: invalid argument # unicode/utf8 mkdir /tmp/go-build584473652/unicode/utf8: invalid argument I'm not sure why mkdir is failing with invalid argument - I cannot trigger this on any of my systems even when using USE_SYSTRACE. Is there something about your system configuration that could be triggering this? I've tried again the old port. Now all work without errors and also pass all the tests (installing the package). This is very curious. My config is nothing special. The only change in my system the last days is I've updated the base and kernel. I update the system one or two times per week. I use a script with all the steps indicated in the faq, so I never forget some step. Anyway, the port is working :D . Thanks a lot for your work. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: new: lang/go
On Thursday 22 March 2012, Ted Unangst wrote: On Thu, Mar 22, 2012, Joel Sing wrote: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? My understanding is that the weekly releases will be a lot less interesting/recommended after version 1. This is correct. Just plain go should suffice until and if version 2 is released. I don't think we need to provide a weekly port unless people are expected to use it for something other than hacking on go itself. That is a fair call. Having also discussed this with a Go core team member, it would seem that I was pre-empting things when I probably do not need to. We can deal with this down the track if/when the need arises. 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. some things, like ruby, pile everything under /usr/local/lib/ruby, but I find that more annoying because the lib directory is already full of real files. I've been waiting for them to make a stable release for a while now. -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand
Re: new: lang/go
On Thursday 22 March 2012, Stuart Henderson wrote: On 2012/03/22 02:09, Joel Sing wrote: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. How about 1.0pre2012mmdd? pkg_add knows how to handle these. Works for me. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? I would probably go for ports/lang/go/1.0, ports/lang/go/2.0, etc. For some things .../stable/ and .../devel/ would be more appropriate, though I think that's probably not the case for this. I had a chat with a Go core team member and it would seem that I was probably planning too far ahead. For the time being I think we should stick with a ports/go/lang port for Go version 1 and we can revisit this in several years time when the next version appears. 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. This wouldn't be the end of the world, we have a similar layout with Java. You should plan to have the main version number in the directory name to allow for multiple versions to be installed together. The preferred install location is /usr/local/go, so if there are no major objections then we should probably run with this. This is where the official Go distributions will be installed and it would be nice if it was consistent across platforms. 3. License - Go is released under a BSD-style license, however some parts (like the documentation) are under other licenses (Creative Commons Attribution 3.0 License). How do we handle this? Just list the various relevant licenses in the comment next to the PERMIT_* markers, e.g. # software: BSD, documentation: CC-BY-3.0 Okay, thanks. -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand
Re: new: lang/go - take 2
Attached is an updated version of the port for Go: - Version numbering is now 1.0preMMDD as suggested by sthen. - Fixed PLIST issue so that the port now works correctly on both amd64 and i386. - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be able to use the sysarch() syscall in order to setup TLS. ok? On Thursday 22 March 2012, Joel Sing wrote: The attached is an initial port for the Go programming language (www.golang.org). A little background - Go is approaching a Go version1 release and at that point it will have a stable API. Unfortunately, for several reasons Go version 1 will not be officially supported on OpenBSD, however there are only a few issues that prevent this - the diffs included in the port address known outstanding issues for the OpenBSD runtime, which will let us provide a working port. Open questions: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. 3. License - Go is released under a BSD-style license, however some parts (like the documentation) are under other licenses (Creative Commons Attribution 3.0 License). How do we handle this? -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand go-port.tar.gz Description: application/tgz
Re: new: lang/go - take 2
On Fri, Mar 23, 2012 at 01:08:48AM +1100, Joel Sing wrote: Attached is an updated version of the port for Go: - Version numbering is now 1.0preMMDD as suggested by sthen. - Fixed PLIST issue so that the port now works correctly on both amd64 and i386. - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be able to use the sysarch() syscall in order to setup TLS. ok? make package works perfect with USE_SYSTRACE. Just a warning in the fake step: strip: /usr/ports/pobj/go-1.0pre20120313/fake-i386/usr/local/go/pkg/tool/openbsd_386/pprof: File format not recognized. I don't know if this is the correct behavior or not, but make regress uses the go command installed on /usr/local, not the go binary in the build directory. make regress with and without go installed, both fail. I've attached the logs of make regress. -- Juan Francisco Cantero Hurtado http://juanfra.info logs-goport.tar.gz Description: application/tar-gz
new: lang/go
The attached is an initial port for the Go programming language (www.golang.org). A little background - Go is approaching a Go version1 release and at that point it will have a stable API. Unfortunately, for several reasons Go version 1 will not be officially supported on OpenBSD, however there are only a few issues that prevent this - the diffs included in the port address known outstanding issues for the OpenBSD runtime, which will let us provide a working port. Open questions: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. 3. License - Go is released under a BSD-style license, however some parts (like the documentation) are under other licenses (Creative Commons Attribution 3.0 License). How do we handle this? -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand go-port.tar.gz Description: application/tgz
Re: new: lang/go
On 2012/03/22 02:09, Joel Sing wrote: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. How about 1.0pre2012mmdd? pkg_add knows how to handle these. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? I would probably go for ports/lang/go/1.0, ports/lang/go/2.0, etc. For some things .../stable/ and .../devel/ would be more appropriate, though I think that's probably not the case for this. 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. This wouldn't be the end of the world, we have a similar layout with Java. You should plan to have the main version number in the directory name to allow for multiple versions to be installed together. 3. License - Go is released under a BSD-style license, however some parts (like the documentation) are under other licenses (Creative Commons Attribution 3.0 License). How do we handle this? Just list the various relevant licenses in the comment next to the PERMIT_* markers, e.g. # software: BSD, documentation: CC-BY-3.0
Re: new: lang/go
On Thu, Mar 22, 2012, Joel Sing wrote: 1. Version numbering - in some ways once Go version 1 is release the versioning will be somewhat like Python and in the future you may want to install Go version 1 and Go version 2 on the same machine (different APIs for example). However, during the development phase there are weekly tagged releases that are simply -MM-DD versioned. For this reason I'm thinking that the version numbering should be 0.MMDD for now and 1.0 for the version 1 release. Continued development could then follow on the 0.MMDD releases. Or should we have two packages - a go-weekly package and a go package? My understanding is that the weekly releases will be a lot less interesting/recommended after version 1. Just plain go should suffice until and if version 2 is released. I don't think we need to provide a weekly port unless people are expected to use it for something other than hacking on go itself. 2. The installation locations is going to get somewhat messy - due to some of the internals of Go's design everything except a few user binaries (so documentaiton, libraries, source code, etc) needs to be under a single directory. For now I've used the recommended default of /usr/local/go, however this is not really acceptable for OpenBSD. Suggestions as to what would be the closest suitable location? I plan on talking with upstream re being able to split this so that we at least have tool/libexec type binaries and libraries separated out from the docs/source. some things, like ruby, pile everything under /usr/local/lib/ruby, but I find that more annoying because the lib directory is already full of real files. I've been waiting for them to make a stable release for a while now.
Re: new: lang/go
On Thu, Mar 22, 2012 at 02:09:26AM +1100, Joel Sing wrote: The attached is an initial port for the Go programming language (www.golang.org). A little background - Go is approaching a Go version1 release and at that point it will have a stable API. Unfortunately, for several reasons Go version 1 will not be officially supported on OpenBSD, however there are only a few issues that prevent this - the diffs included in the port address known outstanding issues for the OpenBSD runtime, which will let us provide a working port. Thanks for your work. I compiled golang a few months ago and all worked perfect, except the tests :( . I've compiled your port with env USE_SYSTRACE=YES make package. The build fails: +++ Wed Mar 21 20:37:18 CET 2012 === Checking files for go-0.20120313 `/usr/ports/distfiles/go.weekly.2012-03-13.src.tar.gz' is up to date. (SHA256) go.weekly.2012-03-13.src.tar.gz: OK === Verifying update for bash-* in shells/bash === Returning to build of go-0.20120313 === go-0.20120313 depends on: bash-* - bash-4.2.24 === Verifying update for bison-* in devel/bison === Returning to build of go-0.20120313 === go-0.20120313 depends on: bison-* - bison-2.3 === Verifying update for ccache-* in devel/ccache === Returning to build of go-0.20120313 === go-0.20120313 depends on: ccache-* - ccache-3.1.7 === Verifying specs: c m c m === found c.62.0 m.7.0 === Extracting for go-0.20120313 === Patching for go-0.20120313 === Configuring for go-0.20120313 Nothing to configure... === Building for go-0.20120313 # Building C bootstrap tool. cmd/dist # Building compilers and Go bootstrap tool for host, openbsd/386. lib9 libbio libmach misc/pprof cmd/addr2line /usr/ports/pobj/go-0.20120313/go/pkg/obj/openbsd_386/libmach.a(sym.o)(.text+0x2081): In function `syminit': /usr/ports/pobj/go-0.20120313/go/src/libmach/sym.c:303: warning: strcpy() is almost always misused, please use strlcpy() cmd/cov /usr/ports/pobj/go-0.20120313/go/pkg/obj/openbsd_386/libmach.a(sym.o)(.text+0x2081): In function `syminit': /usr/ports/pobj/go-0.20120313/go/src/libmach/sym.c:303: warning: strcpy() is almost always misused, please use strlcpy() cmd/nm /usr/ports/pobj/go-0.20120313/go/pkg/obj/openbsd_386/libmach.a(sym.o)(.text+0x2081): In function `syminit': /usr/ports/pobj/go-0.20120313/go/src/libmach/sym.c:303: warning: strcpy() is almost always misused, please use strlcpy() cmd/objdump /usr/ports/pobj/go-0.20120313/go/pkg/obj/openbsd_386/libmach.a(sym.o)(.text+0x2081): In function `syminit': /usr/ports/pobj/go-0.20120313/go/src/libmach/sym.c:303: warning: strcpy() is almost always misused, please use strlcpy() cmd/pack /var/tmp/go-cbuild-OdjOdo/ar.o(.text+0x6cc): In function `arstrdup': /usr/ports/pobj/go-0.20120313/go/src/cmd/pack/ar.c:1651: warning: strcpy() is almost always misused, please use strlcpy() cmd/prof /usr/ports/pobj/go-0.20120313/go/pkg/obj/openbsd_386/libmach.a(sym.o)(.text+0x2081): In function `syminit': /usr/ports/pobj/go-0.20120313/go/src/libmach/sym.c:303: warning: strcpy() is almost always misused, please use strlcpy() cmd/cc cmd/gc cmd/8l /var/tmp/go-cbuild-OdjOdo/dwarf.o(.text+0x10bb): In function `defptrto': /usr/ports/pobj/go-0.20120313/go/src/cmd/8l/../ld/dwarf.c:1187: warning: strcpy() is almost always misused, please use strlcpy() /var/tmp/go-cbuild-OdjOdo/lib.o(.text+0x20c3): In function `addlib': /usr/ports/pobj/go-0.20120313/go/src/cmd/8l/../ld/lib.c:167: warning: strcat() is almost always misused, please use strlcat() cmd/8a /var/tmp/go-cbuild-OdjOdo/lex.o(.text+0xa09): In function `macexpand': /usr/ports/pobj/go-0.20120313/go/src/cmd/8a/../cc/macbody:399: warning: strcpy() is almost always misused, please use strlcpy() /var/tmp/go-cbuild-OdjOdo/lex.o(.text+0x154f): In function `macinc': /usr/ports/pobj/go-0.20120313/go/src/cmd/8a/../cc/macbody:580: warning: strcat() is almost always misused, please use strlcat() cmd/8c /usr/ports/pobj/go-0.20120313/go/pkg/obj/openbsd_386/libcc.a(lex.o)(.text+0x1447): In function `slookup': /usr/ports/pobj/go-0.20120313/go/src/cmd/cc/lex.c:358: warning: strcpy() is almost always misused, please use strlcpy() /var/tmp/go-cbuild-OdjOdo/list.o(.text+0x3a6): In function `Dconv': /usr/ports/pobj/go-0.20120313/go/src/cmd/8c/list.c:192: warning: strcat() is almost always misused, please use strlcat() cmd/8g /var/tmp/go-cbuild-OdjOdo/gobj.o(.text+0x5f4): In function `dgostringptr': /usr/ports/pobj/go-0.20120313/go/src/cmd/8g/gobj.c:460: warning: strcpy() is almost always misused, please use strlcpy() /var/tmp/go-cbuild-OdjOdo/list.o(.text+0x441): In function `Dconv': /usr/ports/pobj/go-0.20120313/go/src/cmd/8g/list.c:158: warning: strcat() is almost always misused, please use strlcat() pkg/runtime pkg/errors pkg/sync/atomic pkg/sync pkg/io pkg/unicode pkg/unicode/utf8 pkg/unicode/utf16 pkg/bytes pkg/math pkg/strings pkg/strconv pkg/bufio pkg/sort pkg/container/heap pkg/encoding/base64 pkg/syscall pkg/time pkg/os pkg/reflect pkg/fmt
