Re: new: lang/go - take 2

2012-03-29 Thread Joel Sing
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

2012-03-29 Thread Sergey Bronnikov
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

2012-03-29 Thread Joel Sing
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

2012-03-29 Thread Stuart Henderson
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

2012-03-29 Thread Joel Sing
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

2012-03-29 Thread Sergey Bronnikov
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

2012-03-29 Thread Juan Francisco Cantero Hurtado
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

2012-03-25 Thread Joel Sing
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

2012-03-25 Thread Juan Francisco Cantero Hurtado
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

2012-03-22 Thread Joel Sing
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

2012-03-22 Thread Joel Sing
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

2012-03-22 Thread Joel Sing
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

2012-03-22 Thread Juan Francisco Cantero Hurtado
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

2012-03-21 Thread Joel Sing
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

2012-03-21 Thread Stuart Henderson
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

2012-03-21 Thread Ted Unangst
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

2012-03-21 Thread Juan Francisco Cantero Hurtado
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