Re: UPDATE: lang/go 1.6

[Matthew Dempsky]

2016-03-28 18:42 GMT-07:00 Juan Francisco Cantero Hurtado :
> @@ -448,6 +501,7 @@ go/pkg/bootstrap/pkg${GOCFG}/bootstrap/c
>  go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/arm64.a
>  go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/big.a
>  go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/gc.a
> +go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/mips64.a
>  go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/ppc64.a
>  go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/x86.a
>  go/pkg/bootstrap/pkg${GOCFG}/bootstrap/internal/

FYI, the official Go binary releases do not include the pkg/bootstrap
directory.  It shouldn't cause any problems either, but it's just a
waste of disk space.

Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction

[Matthew Dempsky]

I seem to recall a bug where some CPU models don't properly set
registers after a CPUID instruction (e.g.,
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/locore.s#rev1.150).
Is it possible this CPU is one of those?  Maybe Go needs similar
workarounds?

A way to test that hypothesis would be to add

MOVL $0, BX
MOVL $0, CX
MOVL $0, DX

before each of these CPUID instructions:

src/cmd/dist/cpuid_386.s:9: CPUID
src/runtime/asm_386.s:30: CPUID
src/runtime/asm_386.s:47: CPUID

On Fri, Aug 7, 2015 at 3:22 PM, Ted Unangst t...@tedunangst.com wrote:
 Stuart Henderson wrote:

 I don't think a flavour is warranted, i386 packages are meant to run
 on all supported CPUs so if the runtime detection is insufficient
 we should just always set this variable.

 talk to upstream? this sounds like a bug if the runtime detection is
 insufficient. unconditionally disabling sse would be a pessimization for most
 users.

Re: Update: ninja-1.5.1

[Matthew Dempsky]

ok with me if none of the test builds expose brokenness.

Re: [update] lang/go 1.3

[Matthew Dempsky]

On Sun, Jun 29, 2014 at 9:19 AM, Joel Sing j...@sing.id.au wrote:
 Longer answer, these particular ones should be - all of the source
 (including 386, amd64, arm, etc) always get installed. However, the ones
 you've spotted (runtime/z*.c) are generated during the build and should
 be only installed for the given architecture.

That's why I pointed out the runtime/z* files specifically, and not
any of the hundreds of other _386 and _amd64 files in PLIST. :)

 Revised diff follows...

ok matthew

Re: [update] lang/go 1.3

[Matthew Dempsky]

On Fri, Jun 20, 2014 at 08:44:11PM +1000, Joel Sing wrote:
 Index: pkg/PFRAG.amd64
 ===
 RCS file: /cvs/ports/lang/go/pkg/PFRAG.amd64,v
 retrieving revision 1.3
 diff -u -p -r1.3 PFRAG.amd64
 --- pkg/PFRAG.amd64   2 Dec 2013 15:35:49 -   1.3
 +++ pkg/PFRAG.amd64   20 Jun 2014 10:40:46 -
 @@ -1,5 +1,4 @@
  @comment $OpenBSD: PFRAG.amd64,v 1.3 2013/12/02 15:35:49 jsing Exp $
 -go/src/cmd/6l/enam.c
  go/src/pkg/runtime/zasm_openbsd_amd64.h
  go/src/pkg/runtime/zgoarch_amd64.go
  go/src/pkg/runtime/zmalloc_openbsd_amd64.c
 Index: pkg/PFRAG.i386
 ===
 RCS file: /cvs/ports/lang/go/pkg/PFRAG.i386,v
 retrieving revision 1.3
 diff -u -p -r1.3 PFRAG.i386
 --- pkg/PFRAG.i3862 Dec 2013 15:35:49 -   1.3
 +++ pkg/PFRAG.i38620 Jun 2014 10:40:46 -
 @@ -1,5 +1,4 @@
  @comment $OpenBSD: PFRAG.i386,v 1.3 2013/12/02 15:35:49 jsing Exp $
 -go/src/cmd/8l/enam.c
  go/src/pkg/runtime/zasm_openbsd_386.h
  go/src/pkg/runtime/zgoarch_386.go
  go/src/pkg/runtime/zmalloc_openbsd_386.c
 Index: pkg/PLIST
 ===
 RCS file: /cvs/ports/lang/go/pkg/PLIST,v
 retrieving revision 1.9
 diff -u -p -r1.9 PLIST
 --- pkg/PLIST 25 Mar 2014 13:21:20 -  1.9
 +++ pkg/PLIST 20 Jun 2014 10:40:48 -
[...]
 @@ -2862,7 +3097,17 @@ go/src/pkg/runtime/vlop_arm_test.go
  go/src/pkg/runtime/vlrt_386.c
  go/src/pkg/runtime/vlrt_arm.c
  go/src/pkg/runtime/zaexperiment.h
 +go/src/pkg/runtime/zalg_openbsd_386.c
 +go/src/pkg/runtime/zchan_openbsd_386.c
 +go/src/pkg/runtime/zcomplex_openbsd_386.c
 +go/src/pkg/runtime/zcpuprof_openbsd_386.c
  go/src/pkg/runtime/zgoos_openbsd.go
 +go/src/pkg/runtime/zhashmap_openbsd_386.c
 +go/src/pkg/runtime/ziface_openbsd_386.c
 +go/src/pkg/runtime/zlfstack_openbsd_386.c
 +go/src/pkg/runtime/zrdebug_openbsd_386.c
 +go/src/pkg/runtime/zslice_openbsd_386.c
 +go/src/pkg/runtime/zsymtab_openbsd_386.c
  go/src/pkg/runtime/zversion.go
  go/src/pkg/sort/
  go/src/pkg/sort/example_interface_test.go

This seems wrong.  Shouldn't the _386.c files go into PFRAG.i386, and
corresponding _amd64.c files should be added to PFRAG.amd64?

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2014/06/18 14:49:15

Modified files:
x11/xsel   : Makefile 
Added files:
x11/xsel/patches: patch-xsel_c 

Log message:
Fix xsel to use long for 32-bit properties, per Xlib's crazy API.

Pointed out by patrick keshishian on misc
ok naddy

Re: NEW: net/ucspi-tcp

[Matthew Dempsky]

On Tue, May 27, 2014 at 2:14 PM, Jérémie Courrèges-Anglas
j...@wxcvbn.org wrote:
 No proper license, approval required for patches and/or no
 redistribution of binary packages, bla, bla.  I may not remember the
 details well enough; like most people that were interested in
 daemontools/qmail/djbdns/blah, but stopped using them long time ago.

FWIW, most of DJB's code has been public domain for a while now:
http://cr.yp.to/distributors.html

In particular, ucspi-tcp has been public domain for 6+ years now.

Re: POSIX standard as manual pages

[Matthew Dempsky]

Just curious, are the older POSIX standards available as man pages
too?  Is there a way to install them side-by-side?

I'm by far most interested in the current up-to-date standard, but
being able to easily cross-reference older revisions is sometimes
handy.  (E.g., when trying to make sure we're still compliant with
older standards.)

On Fri, May 9, 2014 at 8:18 AM, Vadim Zhukov persg...@gmail.com wrote:
 09.05.2014 17:17 пользователь Ingo Schwarze schwa...@usta.de написал:

 Hi Dmitrij and Vadim,

 Vadim Zhukov wrote on Fri, May 09, 2014 at 11:57:28AM +0400:
  09.05.2014 2:03 Dmitrij D. Czarkoff czark...@gmail.com:

  Why not shorten man-pages-posix to just posix?

 That's what i originally suggested, too:

   From: Ingo Schwarze schwa...@usta.de
   Date: Fri, 24 Jan 2014 00:45:56 +0100
   To: Vadim Zhukov persg...@gmail.com
   Cc: ports@openbsd.org
   Subject: Re: POSIX standard as manual pages
   [...]
   Do not install these manuals to /usr/local/man/,
   but to a dedicated directory, something like
 /usr/local/share/doc/posix/man/man{1,3}/*.{1,3}

 One advantage is that if any other POSIX documentation should ever
 show up in ports, it could go into share/doc/posix, too.
 There is no danger of clashes, posix/man is quite clear,
 man-pages-posix/man somewhat redundant.

  It's upstream name, FWIW.

 The argument that a port should follow upstream's name (unless it is
 very badly chosen) and that most subdirectories of /usr/local/share/doc/
 follow the respective ports' names is a valid one.

  I won't mind to change actual folder if there will be a real reason.
  You won't go to this folder directly anyway, will you?

 I already have your port installed because it is useful for me
 when doing work regarding POSIX conformance and when doing work
 regarding HISTORY sections.  I already cd'ed into that directory
 several times, mostly to do multiple consecutive grep -R commands.
 Given that all this is still man(7), not mdoc(7), the new apropos
 is not yet very helpful, so searching still needs to be done the
 old way.

 This is a good point, thank you for input. The packages are for people, not
 the other direction. So if people use this directory, err, directly, then
 it's better to have an exception. I'll rename the folder when I'll get my
 laptop back to normal operation.

 Then again, i don't feel strongly either way, both paths seem
 acceptable to me.  It's your port, and you are more used to ports
 naming conventions, so you should decide this detail, i think.

 Yours,
   Ingo

Re: amd64 bulk breakage 2013-12-29

[Matthew Dempsky]

On Mon, Dec 30, 2013 at 9:47 AM, Christian Weisgerber
na...@mips.inka.de wrote:
 math/octave undefined reference to `__guard'

That's odd.  Can you send me the build logs from this (or put them
somewhere I can access them)?

Re: amd64 bulk breakage 2013-12-29

[Matthew Dempsky]

On Mon, Dec 30, 2013 at 12:13 PM, Pascal Stumpf pascal.stu...@cubes.de wrote:
 I don't have logs, but the problem is that lang/g77 still emits
 references go __guard.  The following diff should fix it (currently
 compiling math/octave).

Ah, makes sense.  Diff looks ok to me assuming it builds successfully.

Re: x11/blackbox: time_t fix (too late i see .. but please read)

[Matthew Dempsky]

On Sun, Aug 18, 2013 at 2:43 AM, patrick keshishian sids...@boxsoft.com wrote:
 + bt::timeval::timeval(const ::timeval t)
 +-  : tv_sec(t.tv_sec), tv_usec(t.tv_usec)
 +-{ }
 ++{ tv_sec = t.tv_sec; tv_usec = t.tv_usec; }

What's the point of these changes?

Re: unbreak smtp-vilter

[Matthew Dempsky]

On Fri, Aug 9, 2013 at 9:45 AM, Ian Darwin i...@darwinsys.com wrote:
 +-LDADD+=   -nostdlib
 ++LDADD+=   --nodefaultlib

Hm, I would think this needs to be -nodefaultlibs instead of
--nodefaultlib (i.e., only one hyphen and add the s).

Re: unbreak smtp-vilter

[Matthew Dempsky]

Looks ok to me, but I haven't tested it or anything.

On Fri, Aug 9, 2013 at 10:26 AM, Ian Darwin i...@darwinsys.com wrote:
 Sharper cluestick from matthew@.

 OK now?

 Index: Makefile
 ===
 RCS file: /cvs/ports/mail/smtp-vilter/Makefile,v
 retrieving revision 1.53
 diff -u -p -r1.53 Makefile
 --- Makefile9 May 2013 18:47:53 -   1.53
 +++ Makefile9 Aug 2013 17:25:11 -
 @@ -3,7 +3,7 @@
  COMMENT=   sendmail milter to scan messages for viruses and spam

  DISTNAME=  smtp-vilter-1.3.8
 -REVISION=  0
 +REVISION=  1

  CATEGORIES=mail

 Index: patches/patch-backend_vilter-attachment_Makefile
 ===
 RCS file: patches/patch-backend_vilter-attachment_Makefile
 diff -N patches/patch-backend_vilter-attachment_Makefile
 --- /dev/null   1 Jan 1970 00:00:00 -
 +++ patches/patch-backend_vilter-attachment_Makefile9 Aug 2013 17:25:11 
 -
 @@ -0,0 +1,12 @@
 +$OpenBSD$
 +--- backend/vilter-attachment/Makefile.origSat May  4 07:07:11 2013
  backend/vilter-attachment/Makefile Fri Aug  9 12:19:15 2013
 +@@ -22,7 +22,7 @@ LIBDIR=  /usr/pkg/lib/smtp-vilter
 + CFLAGS+=  -I/usr/src/gnu/usr.sbin/sendmail/include
 + .endif
 +
 +-LDADD+=   -nostdlib
 ++LDADD+=   -nodefaultlibs
 +
 + beforeinstall:
 +   -mkdir -p ${DESTDIR}${LIBDIR}
 Index: patches/patch-backend_vilter-clamd_Makefile
 ===
 RCS file: patches/patch-backend_vilter-clamd_Makefile
 diff -N patches/patch-backend_vilter-clamd_Makefile
 --- /dev/null   1 Jan 1970 00:00:00 -
 +++ patches/patch-backend_vilter-clamd_Makefile 9 Aug 2013 17:25:11 -
 @@ -0,0 +1,12 @@
 +$OpenBSD$
 +--- backend/vilter-clamd/Makefile.orig Sat May  4 07:05:12 2013
  backend/vilter-clamd/Makefile  Fri Aug  9 12:19:18 2013
 +@@ -22,7 +22,7 @@ LIBDIR=  /usr/pkg/lib/smtp-vilter
 + CFLAGS+=  -I/usr/src/gnu/usr.sbin/sendmail/include
 + .endif
 +
 +-LDADD+=   -nostdlib
 ++LDADD+=   -nodefaultlibs
 +
 + beforeinstall:
 +   -mkdir -p ${DESTDIR}${LIBDIR}
 Index: patches/patch-backend_vilter-icap_Makefile
 ===
 RCS file: patches/patch-backend_vilter-icap_Makefile
 diff -N patches/patch-backend_vilter-icap_Makefile
 --- /dev/null   1 Jan 1970 00:00:00 -
 +++ patches/patch-backend_vilter-icap_Makefile  9 Aug 2013 17:25:11 -
 @@ -0,0 +1,12 @@
 +$OpenBSD$
 +--- backend/vilter-icap/Makefile.orig  Sat May  4 07:08:28 2013
  backend/vilter-icap/Makefile   Fri Aug  9 12:19:21 2013
 +@@ -22,7 +22,7 @@ LIBDIR=  /usr/pkg/lib/smtp-vilter
 + CFLAGS+=  -I/usr/src/gnu/usr.sbin/sendmail/include
 + .endif
 +
 +-LDADD+=   -nostdlib
 ++LDADD+=   -nodefaultlibs
 +
 + beforeinstall:
 +   -mkdir -p ${DESTDIR}${LIBDIR}
 Index: patches/patch-backend_vilter-regex_Makefile
 ===
 RCS file: patches/patch-backend_vilter-regex_Makefile
 diff -N patches/patch-backend_vilter-regex_Makefile
 --- /dev/null   1 Jan 1970 00:00:00 -
 +++ patches/patch-backend_vilter-regex_Makefile 9 Aug 2013 17:25:11 -
 @@ -0,0 +1,12 @@
 +$OpenBSD$
 +--- backend/vilter-regex/Makefile.orig Sat May  4 07:10:56 2013
  backend/vilter-regex/Makefile  Fri Aug  9 12:19:25 2013
 +@@ -22,7 +22,7 @@ LIBDIR=  /usr/pkg/lib/smtp-vilter
 + CFLAGS+=  -I/usr/src/gnu/usr.sbin/sendmail/include
 + .endif
 +
 +-LDADD+=   -nostdlib
 ++LDADD+=   -nodefaultlibs
 +
 + beforeinstall:
 +   -mkdir -p ${DESTDIR}${LIBDIR}
 Index: patches/patch-backend_vilter-spamd_Makefile
 ===
 RCS file: patches/patch-backend_vilter-spamd_Makefile
 diff -N patches/patch-backend_vilter-spamd_Makefile
 --- /dev/null   1 Jan 1970 00:00:00 -
 +++ patches/patch-backend_vilter-spamd_Makefile 9 Aug 2013 17:25:11 -
 @@ -0,0 +1,12 @@
 +$OpenBSD$
 +--- backend/vilter-spamd/Makefile.orig Sat May  4 07:11:57 2013
  backend/vilter-spamd/Makefile  Fri Aug  9 12:19:29 2013
 +@@ -22,7 +22,7 @@ LIBDIR=  /usr/pkg/lib/smtp-vilter
 + CFLAGS+=  -I/usr/src/gnu/usr.sbin/sendmail/include
 + .endif
 +
 +-LDADD+=   -nostdlib
 ++LDADD+=   -nodefaultlibs
 +
 + beforeinstall:
 +   -mkdir -p ${DESTDIR}${LIBDIR}

Re: UPDATE: LLVM 3.3

[Matthew Dempsky]

On Thu, Jul 18, 2013 at 9:56 AM, Stuart Henderson st...@openbsd.org wrote:

 On 2013/07/18 22:48, Jonathan Gray wrote:
   @comment lib/libgtest.a
   @comment lib/libgtest_main.a
  +lib/libgtest.so
  +lib/libgtest_main.so

 presumably the above 4 lines want replacing with

 @comment lib/libgtest.so
 @comment lib/libgtest_main.so

 ...?

 (not sure why this was originally commented, but presumably it should stay
 commented?)


Probably to avoid conflicting with devel/gtest, and I agree it should stay
commented.

Re: UPDATE: emulators/mupen64plus

[Matthew Dempsky]

On Sun, Jul 7, 2013 at 8:36 PM, Anthony J. Bentley anth...@cathet.uswrote:

 Upstream released another graphics plugin, video-glide64mk2, but I haven't
 made a port for it because it #includes thread, which doesn't seem to
 appear with either GCC 4.6 or clang.


Is the source file C or C++?

Re: Ninja build failures on sgi and mips64el

[Matthew Dempsky]

There's an unaligned word access in ninja's murmurhash implementation:
https://github.com/martine/ninja/blob/master/src/hash_map.h

We need to change

unsigned int k = *(unsigned int *)data;

to

unsigned int k;
memcpy(k, data, sizeof k);

and it should fix the unaligned accesses on strict arches like sparc64 and mips.

Sorry, I'm not able to fix this myself right now, but I can help
upstream the fix tomorrow.  (I'm of course ok with any ports fix for
this.)


On Mon, Jul 1, 2013 at 10:24 AM, James Turner jtur...@openbsd.org wrote:
 Mathew,

 I just wanted to let you know we have discovered some build failures on
 sgi and mips64el during the Build ninja using itself phase. It looks
 like something is segfaulting. Below is the build output although it
 isn't very helpful.

 I can test diffs on mips64el and plan on trying to compile with debug
 symbols to see if I can get more info out of the core file that is left.

 Building ninja using itself...
 *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd
 /usr/obj/ports/ninja-1.3.4/ninja-1.3.4  /usr/bin/env -i CXX=c++CC=cc 
 PYTHONUS...)
 *** Error 1 in devel/ninja
 (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done')
 *** Error 1 in devel/ninja
 (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build')
 === Exiting devel/ninja with an error
 /bin/sh: exit 1: not found
 *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147'build')
 Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist

 --
 James Turner

Re: Ninja build failures on sgi and mips64el

[Matthew Dempsky]

Jasper (or someone) will have to.  My OpenBSD workstation is down
until at least tomorrow.

Glad to hear that fix worked though.

On Mon, Jul 1, 2013 at 1:40 PM, David Coppa dco...@gmail.com wrote:
 On Mon, Jul 1, 2013 at 10:37 PM, Jasper Lievisse Adriaanse
 jas...@openbsd.org wrote:
 This fixes the build on mips64.

 Thanks a lot, Mathew.

 Please go ahead and commit it, you or Jasper ;)

 Ciao,
 David

 On Mon, Jul 01, 2013 at 10:36:09AM -0700, Matthew Dempsky wrote:
 There's an unaligned word access in ninja's murmurhash implementation:
 https://github.com/martine/ninja/blob/master/src/hash_map.h

 We need to change

 unsigned int k = *(unsigned int *)data;

 to

 unsigned int k;
 memcpy(k, data, sizeof k);

 and it should fix the unaligned accesses on strict arches like sparc64 and 
 mips.

 Sorry, I'm not able to fix this myself right now, but I can help
 upstream the fix tomorrow.  (I'm of course ok with any ports fix for
 this.)


 On Mon, Jul 1, 2013 at 10:24 AM, James Turner jtur...@openbsd.org wrote:
  Mathew,
 
  I just wanted to let you know we have discovered some build failures on
  sgi and mips64el during the Build ninja using itself phase. It looks
  like something is segfaulting. Below is the build output although it
  isn't very helpful.
 
  I can test diffs on mips64el and plan on trying to compile with debug
  symbols to see if I can get more info out of the core file that is left.
 
  Building ninja using itself...
  *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd
  /usr/obj/ports/ninja-1.3.4/ninja-1.3.4  /usr/bin/env -i CXX=c++CC=cc 
  PYTHONUS...)
  *** Error 1 in devel/ninja
  (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done')
  *** Error 1 in devel/ninja
  (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build')
  === Exiting devel/ninja with an error
  /bin/sh: exit 1: not found
  *** Error 127 in /usr/ports 
  (infrastructure/mk/bsd.port.subdir.mk:147'build')
  Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist
 
  --
  James Turner


 --
 Regards,

 Jasper Lievisse Adriaanse,
 Engineering team M:tier

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2013/06/14 10:39:39

Modified files:
devel/ninja: Makefile distinfo 
devel/ninja/pkg: DESCR PLIST 

Log message:
Update devel/ninja to v1.3.4.  Also, install asciidocs and
shell/editor integration scripts.

ok espie

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2013/05/21 10:06:52

Modified files:
devel/ninja: Makefile distinfo 
Removed files:
devel/ninja/patches: patch-src_subprocess-posix_cc 

Log message:
Update devel/ninja to v1.3.3.

ok (and COMMENT tweak) dcoppa

Update devel/ninja to 1.3.3

[Matthew Dempsky]

This updates ninja to 1.3.3, which includes the OpenBSD patches
upstream and is the official version now used to build and test
Chrome.

ok?

Index: Makefile
===
RCS file: /cvs/ports/devel/ninja/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile2 May 2013 19:09:18 -   1.1.1.1
+++ Makefile21 May 2013 06:06:17 -
@@ -1,7 +1,7 @@
 # $OpenBSD: Makefile,v 1.1.1.1 2013/05/02 19:09:18 matthew Exp $
 
 COMMENT =  a small build system with a focus on speed
-V =1.2.0
+V =1.3.3
 DISTNAME = ninja-${V}
 CATEGORIES =   devel
 HOMEPAGE = http://martine.github.io/ninja/
Index: distinfo
===
RCS file: /cvs/ports/devel/ninja/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo2 May 2013 19:09:18 -   1.1.1.1
+++ distinfo21 May 2013 06:06:17 -
@@ -1,2 +1,2 @@
-SHA256 (ninja-1.2.0.tar.gz) = gToeZQ9Q7W6X01O7zjMTSNOet/2tT7pT5Kmb59qTnnI=
-SIZE (ninja-1.2.0.tar.gz) = 136233
+SHA256 (ninja-1.3.3.tar.gz) = YhKvacK9ubbnpKW0WAJIOuv7XYln5DeYH6ZvDaPRej4=
+SIZE (ninja-1.3.3.tar.gz) = 147703
Index: patches/patch-src_subprocess-posix_cc
===
RCS file: patches/patch-src_subprocess-posix_cc
diff -N patches/patch-src_subprocess-posix_cc
--- patches/patch-src_subprocess-posix_cc   2 May 2013 19:09:18 -   
1.1.1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,70 +0,0 @@
-$OpenBSD: patch-src_subprocess-posix_cc,v 1.1.1.1 2013/05/02 19:09:18 matthew 
Exp $
 src/subprocess-posix.cc.orig   Fri Apr  5 09:36:12 2013
-+++ src/subprocess-posix.ccThu May  2 12:01:23 2013
-@@ -25,13 +25,6 @@
- #include string.h
- #include sys/wait.h
- 
--// Older versions of glibc (like 2.4) won't find this in poll.h.  glibc
--// 2.4 keeps it in asm-generic/poll.h, though attempting to include that
--// will redefine the pollfd structure.
--#ifndef POLLRDHUP
--#define POLLRDHUP 0x2000
--#endif
--
- #include util.h
- 
- Subprocess::Subprocess() : fd_(-1), pid_(-1) {
-@@ -49,12 +42,12 @@ bool Subprocess::Start(SubprocessSet* set, const strin
-   if (pipe(output_pipe)  0)
- Fatal(pipe: %s, strerror(errno));
-   fd_ = output_pipe[0];
--#if !defined(linux)
--  // On linux we use ppoll in DoWork(); elsewhere we use pselect and so must
--  // avoid overly-large FDs.
-+#if !defined(linux)  !defined(__OpenBSD__)
-+  // On Linux and OpenBSD, we use ppoll in DoWork(); elsewhere we use pselect
-+  // and so must avoid overly-large FDs.
-   if (fd_ = static_castint(FD_SETSIZE))
- Fatal(pipe: %s, strerror(EMFILE));
--#endif  // !linux
-+#endif  // !linux  !__OpenBSD__
-   SetCloseOnExec(fd_);
- 
-   pid_ = fork();
-@@ -189,7 +182,7 @@ Subprocess *SubprocessSet::Add(const string command) 
-   return subprocess;
- }
- 
--#ifdef linux
-+#if defined(linux) || defined(__OpenBSD__)
- bool SubprocessSet::DoWork() {
-   vectorpollfd fds;
-   nfds_t nfds = 0;
-@@ -199,7 +192,7 @@ bool SubprocessSet::DoWork() {
- int fd = (*i)-fd_;
- if (fd  0)
-   continue;
--pollfd pfd = { fd, POLLIN | POLLPRI | POLLRDHUP, 0 };
-+pollfd pfd = { fd, POLLIN | POLLPRI, 0 };
- fds.push_back(pfd);
- ++nfds;
-   }
-@@ -236,7 +229,7 @@ bool SubprocessSet::DoWork() {
-   return false;
- }
- 
--#else  // linux
-+#else  // linux || __OpenBSD__
- bool SubprocessSet::DoWork() {
-   fd_set set;
-   int nfds = 0;
-@@ -279,7 +272,7 @@ bool SubprocessSet::DoWork() {
- 
-   return false;
- }
--#endif  // linux
-+#endif  // linux || __OpenBSD__
- 
- Subprocess* SubprocessSet::NextFinished() {
-   if (finished_.empty())

Re: wip eclipse for testing

[Matthew Dempsky]

On Mon, May 13, 2013 at 7:08 PM, frantisek holop min...@obiit.org wrote:
 i would like to test the wip eclipse port
 but there is no way i could build that monster
 on my netbook.  what are my options?

By wip eclipse port, do you mean
https://github.com/jasperla/openbsd-wip/tree/master/devel/eclipse?

If so, that port doesn't actually build all of eclipse.  It downloads
a prebuilt Linux Eclipse release, just rebuilds the native shared
libraries, and replaces them in the Linux release.

You'll probably need more memory to run it than to build it. :)

Re: tedu lang/ghc?

[Matthew Dempsky]

On Tue, May 7, 2013 at 2:50 PM, Matthias Kilian k...@outback.escape.de wrote:
 Spoiler: I'm not talking about Haskell but about ghc here.

To ask a possibly dumb question, what are our other options for
Haskell at the moment?  E.g., it looks like x11/xmonad depends on
lang/ghc, so does removing ghc mean removing xmonad?

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2013/05/02 13:09:18

Log message:
Initial import of ninja, a simple build system with a focus on speed.

ok dcoppa, sthen

Status:

Vendor Tag: matthew
Release Tags:   matthew_2013-May-02

N ports/devel/ninja/Makefile
N ports/devel/ninja/distinfo
N ports/devel/ninja/patches/patch-src_subprocess-posix_cc
N ports/devel/ninja/pkg/DESCR
N ports/devel/ninja/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2013/05/02 13:11:10

Modified files:
devel  : Makefile 

Log message:
+ninja

Re: [NEW] devel/ninja

[Matthew Dempsky]

On Thu, May 2, 2013 at 12:40 AM, David Coppa dco...@gmail.com wrote:
 Python is only needed for building ninja, so I've added MODPY_RUNDEP=No.

No, it's needed at run time too for the ninja -t browse functionality too.

 patch-bootstrap_py is not needed, 'cause ninja only wants libc,
 libm and libstdc++ that come all from base.

Ok by me.  For the regress tests, it wants to build/link against
gtest, but I didn't try to wire that up to the Makefile.

 I've added a patch 'patch-src_util_cc' to get the number of cpus
 on OpenBSD too (just a couple of extra #ifdefs, the code is the
 same as for FreeBSD).

I don't think that's necessary.  We already support
sysconf(_SC_NPROCESSORS_ONLN), which is implemented by just grabbing
the hw.ncpu sysctl anyway.

Re: [NEW] devel/ninja

[Matthew Dempsky]

On Thu, May 2, 2013 at 2:21 AM, David Coppa dco...@gmail.com wrote:
 Ah... Didn't spot this.

No problem.  I almost didn't notice it either until I decided to run
grep python src/*.cc. :)

 So, ok dcoppa@ to import this.

Thanks, I'll import it tomorrow then.  It's too late for me to risk a
botched cvs import right now. :)

[NEW] devel/ninja

[Matthew Dempsky]

Attached is a port of the Ninja build system: http://martine.github.io/ninja/

It needs ppoll() support, so you'll need to test with a recent release
snapshot containing libc.so.68.1.

The patches to add OpenBSD support have already been merged upstream
(https://github.com/martine/ninja/pull/565), so they'll be included in
the next upstream release.

ok?


$ cat pkg/DESCR
Ninja is a small build system with a focus on speed.

Re: [NEW] devel/ninja

[Matthew Dempsky]

On Wed, May 01, 2013 at 03:24:25PM -0700, Matthew Dempsky wrote:
 Attached is a port of the Ninja build system: http://martine.github.io/ninja/

D'oh, attached for real this time...


ninja.tar.gz
Description: application/tar-gz

Re: [bug] chromium problem since 26.0.1410.43

[Matthew Dempsky]

On Thu, Apr 11, 2013 at 4:54 AM, Kenneth R Westerback
kwesterb...@rogers.com wrote:
 On Thu, Apr 11, 2013 at 05:11:15AM +, Ted Unangst wrote:
 Visiting www.apple.com displays the sad tab and this (repeating):
 [5303:600661216:0411/005904:ERROR:omnibox_view_gtk.cc(431)] Not implemented 
 reached in virtual void OmniboxViewGtk::ApplyCaretVisibility()

 Runing as env G_SLICE=always-malloc chrome helps a little, but not really.
 It's still pretty useless.


 I see these same messages on amd64, but I have not been experiencing any
 crashes.

FWIW, the ApplyCaretVisibility() warnings were removed recently from
trunk, as apparently they're considered harmless:

https://code.google.com/p/chromium/issues/detail?id=172302
https://codereview.chromium.org/12470003

Re: lang/go build failing on i386

[Matthew Dempsky]

On Thu, Sep 13, 2012 at 11:26:39PM +0100, Stuart Henderson wrote:
 Seeing this repeatably fail in my current i386 build, the go port hasn't
 changed, anyone have an idea what might be doing it?

As mentioned on icb, the Go linker doesn't set a PT_NOTE segment for
OpenBSD identification like it does for NetBSD executables.  However,
it does set EI_OSABI to ELFOSABI_OPENBSD, and it probably wouldn't
hurt for the kernel to skip the PT_NOTE check in that case.

Please try this diff to see if it fixes lang/go.  (Sorry, untested.)


Index: exec_elf.c
===
RCS file: /cvs/src/sys/kern/exec_elf.c,v
retrieving revision 1.88
diff -u -p -r1.88 exec_elf.c
--- exec_elf.c  11 Sep 2012 15:44:19 -  1.88
+++ exec_elf.c  13 Sep 2012 23:07:36 -
@@ -592,7 +592,8 @@ ELFNAME2(exec,makecmds)(struct proc *p, 
 * set the ep_emul field in the exec package structure.
 */
error = ENOEXEC;
-   if (ELFNAME(os_pt_note)(p, epp, epp-ep_hdr, OpenBSD, 8, 4) != 0) {
+   if (eh-e_ident[EI_OSABI] != ELFOSABI_OPENBSD 
+   ELFNAME(os_pt_note)(p, epp, epp-ep_hdr, OpenBSD, 8, 4) != 0) {
for (i = 0; ELFNAME(probes)[i].func != NULL  error; i++)
error = (*ELFNAME(probes)[i].func)(p, epp, interp, 
pos);
if (error)

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2012/09/05 18:57:54

Modified files:
lang/erlang: Makefile 
Added files:
lang/erlang/patches: patch-erts_configure_in 

Log message:
Link DSOs with 'cc -shared' instead of 'ld -shared' so that
__guard_local is defined appropriately.

ok nigel

Fix lang/erlang

[Matthew Dempsky]

This fixes erlang to properly link its shared objects on OpenBSD, and
lets at least devel/rebar now build.

make update-plist tells me there's a new pkg/PLIST, but then fails
to write it for some currently unknown reason.  I don't expect the
plist actually changes with this, but someone might double check that.

ok?

Index: Makefile
===
RCS file: /cvs/ports/lang/erlang/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- Makefile30 Aug 2012 20:54:59 -  1.51
+++ Makefile5 Sep 2012 22:08:33 -
@@ -7,7 +7,7 @@ V=  R15B01
 DISTNAME=  otp_src_${V}
 PKGNAME=   erlang-15b.01
 EPOCH= 0
-REVISION=  0
+REVISION=  1
 CATEGORIES=lang
 
 # Erlang Public License
@@ -41,6 +41,7 @@ USE_GROFF =   Yes
 CONFIGURE_STYLE=autoconf no-autoheader
 CONFIGURE_ENV= LDFLAGS=${LDFLAGS} -pthread
 AUTOCONF_VERSION=2.59
+AUTOCONF_DIR=  ${WRKSRC} ${WRKSRC}/erts
 MODGNU_CONFIG_GUESS_DIRS=  ${WRKSRC}/erts/autoconf \
${WRKSRC}/lib/erl_interface/src/auxdir
 
Index: patches/patch-erts_configure_in
===
RCS file: patches/patch-erts_configure_in
diff -N patches/patch-erts_configure_in
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-erts_configure_in 5 Sep 2012 22:08:33 -
@@ -0,0 +1,15 @@
+$OpenBSD$
+--- erts/configure.in.orig Sun Apr  1 11:15:00 2012
 erts/configure.in  Wed Sep  5 14:52:08 2012
+@@ -3548,6 +3548,11 @@ case $host_os in
+   DED_LDFLAGS=-m32 $DED_LDFLAGS
+   fi
+   ;;  
++  openbsd*)
++  DED_LD=$CC
++  DED_LD_FLAG_RUNTIME_LIBRARY_PATH=$CFLAG_RUNTIME_LIBRARY_PATH
++  DED_LDFLAGS=-shared
++  ;;
+   osf*)
+   # NOTE! Whitespace after -rpath is important.
+   DED_LD_FLAG_RUNTIME_LIBRARY_PATH=-rpath 

Re: libc.so.66.0 (system): bad major

[Matthew Dempsky]

On Sun, Aug 26, 2012 at 10:25 PM, Scott McEachern sc...@blackstaff.ca wrote:
 ===  Installing groff-1.21p8 from /usr/ports/packages/amd64/all/
 Can't install groff-1.21p8 because of libraries
 |library c.65.0 not found
 | /usr/lib/libc.so.66.0 (system): bad major
 *** Error code 1

I suspect you compiled the groff package against an older snapshot
which had libc.so.65.0.  The new snapshots have libc.so.66.0 now, and
if you did a clean reinstall of base then you no longer have
libc.so.65.0.

I thought the ports tools are supposed to gracefully handle this, but
maybe not.  Try deleting the groff package and rebuilding it from
source to see if that helps.

Re: UPDATE: GCC - update library link spec for libpthread

[Matthew Dempsky]

On Thu, Aug 16, 2012 at 7:55 AM, Brad Smith b...@comstyle.com wrote:
 Update the GCC ports to sync the OpenBSD LIB_SPEC with the base gcc4
 for the new libpthread handling.

 Tested with gcc 3.3/4.2/4.6 on amd64.

Looks right to me.  ok matthew

Re: [WIP] devel/eclipse4/sdk

[Matthew Dempsky]

On Wed, Jun 6, 2012 at 6:25 AM, Stefan Sperling s...@openbsd.org wrote:
 Any news?

I just committed devel/eclipse4/sdk to the openbsd-wip repo on github:
https://github.com/jasperla/openbsd-wip/tree/master/devel/eclipse4/sdk

This port is based on the recent 4.2 release instead of 4.1.2.  Some
very quick testing looks like it works okay on amd64.  I also faked
building it with MACHINE_ARCH=i386 and it seemed to compile okay, so I
think I've now accounted for the version discrepancies between
Eclipse's x86 and x86_64 releases.  I think I've fixed all of the
other issues reported in this thread so far.

Re: GSlice: failed to allocate

[Matthew Dempsky]

On Sat, Jun 23, 2012 at 12:21 AM, Steven Mestdagh ste...@openbsd.org wrote:
 just upgraded to the latest amd64 snapshot and packages.
 has anyone else seen this error?

Sorry, that's my fault. :(  I fixed posix_memalign() in libc to handle
large alignment requests.  I knew glib would start taking advantage of
it, but I was just thinking of it as a bugfix so I didn't think to
bump the shlib version.  In retrospect, that was a mistake.

Re: Bulk build test for mbsnrtowcs() and wcsnrtombs()?

[Matthew Dempsky]

(FYI, naddy@ already helped me with a bulk build test of this diff;
I'm just waiting on code reviews from a few developers now.)

On Mon, Jun 4, 2012 at 3:58 AM, Brett brett.ma...@gmx.com wrote:
 In case it is helpful, stuff I used a lot since rebuilding (and all working 
 as before):

 xxxterm, mplayer, dnsmasq, leafpad, rxvt-unicode, dmenu, jwm, xcursor-themes, 
 snownews, getmail, centerim, mupdf, vitunes, sylpheed (3.2.0beta7, not the 
 ports version).

Cool, thanks for the report.  Are you testing with an ASCII or UTF-8 locale?

Bulk build test for mbsnrtowcs() and wcsnrtombs()?

[Matthew Dempsky]

Diff below adds mbsnrtowcs() and wcsnrtombs(), which are new POSIX
2008 functions.  I'd appreciate if someone could run this through a
bulk build and let me know if anything breaks or misbehaves.

Thanks!


Index: include/wchar.h
===
RCS file: /home/mdempsky/anoncvs/cvs/src/include/wchar.h,v
retrieving revision 1.22
diff -u -p -r1.22 wchar.h
--- include/wchar.h 5 Jan 2012 20:37:50 -   1.22
+++ include/wchar.h 25 May 2012 06:01:50 -
@@ -158,6 +158,11 @@ unsigned long int wcstoul(const wchar_t 
 wchar_t*wcsdup(const wchar_t *);
 int wcscasecmp(const wchar_t *, const wchar_t *);
 int wcsncasecmp(const wchar_t *, const wchar_t *, size_t);
+
+size_t mbsnrtowcs(wchar_t * __restrict, const char ** __restrict, size_t,
+size_t, mbstate_t * __restrict);
+size_t wcsnrtombs(char * __restrict, const wchar_t ** __restrict, size_t,
+size_t, mbstate_t * __restrict);
 #endif
 
 #if __ISO_C_VISIBLE = 1999
Index: lib/libc/locale/multibyte_citrus.c
===
RCS file: /home/mdempsky/anoncvs/cvs/src/lib/libc/locale/multibyte_citrus.c,v
retrieving revision 1.1
diff -u -p -r1.1 multibyte_citrus.c
--- lib/libc/locale/multibyte_citrus.c  27 Jul 2010 16:59:04 -  1.1
+++ lib/libc/locale/multibyte_citrus.c  25 May 2012 16:45:00 -
@@ -30,6 +30,7 @@
 #include sys/cdefs.h
 #include sys/types.h
 #include errno.h
+#include limits.h
 #include wchar.h
 
 #include citrus_ctype.h
@@ -65,7 +66,19 @@ mbrtowc(wchar_t *pwc, const char *s, siz
 }
 
 size_t
-mbsrtowcs(wchar_t *pwcs, const char **s, size_t n, mbstate_t *ps)
+mbsrtowcs(wchar_t *dst, const char **src, size_t len, mbstate_t *ps)
+{
+   static mbstate_t mbs;
+   struct _citrus_ctype_rec *cc;
+
+   if (ps == NULL)
+   ps = mbs;
+   return (mbsnrtowcs(dst, src, SIZE_MAX, len, ps));
+}
+
+size_t
+mbsnrtowcs(wchar_t *dst, const char **src, size_t nmc, size_t len,
+mbstate_t *ps)
 {
static mbstate_t mbs;
struct _citrus_ctype_rec *cc;
@@ -73,7 +86,8 @@ mbsrtowcs(wchar_t *pwcs, const char **s,
if (ps == NULL)
ps = mbs;
cc = _CurrentRuneLocale-rl_citrus_ctype;
-   return (*cc-cc_ops-co_mbsrtowcs)(pwcs, s, n, _ps_to_private(ps));
+   return (*cc-cc_ops-co_mbsnrtowcs)(dst, src, nmc, len,
+   _ps_to_private(ps));
 }
 
 size_t
@@ -89,7 +103,18 @@ wcrtomb(char *s, wchar_t wc, mbstate_t *
 }
 
 size_t
-wcsrtombs(char *s, const wchar_t **ppwcs, size_t n, mbstate_t *ps)
+wcsrtombs(char *dst, const wchar_t **src, size_t len, mbstate_t *ps)
+{
+   static mbstate_t mbs;
+
+   if (ps == NULL)
+   ps = mbs;
+   return (wcsnrtombs(dst, src, SIZE_MAX, len, ps));
+}
+
+size_t
+wcsnrtombs(char *dst, const wchar_t **src, size_t nwc, size_t len,
+mbstate_t *ps)
 {
static mbstate_t mbs;
struct _citrus_ctype_rec *cc;
@@ -97,5 +122,6 @@ wcsrtombs(char *s, const wchar_t **ppwcs
if (ps == NULL)
ps = mbs;
cc = _CurrentRuneLocale-rl_citrus_ctype;
-   return (*cc-cc_ops-co_wcsrtombs)(s, ppwcs, n, _ps_to_private(ps));
+   return (*cc-cc_ops-co_wcsnrtombs)(dst, src, nwc, len,
+   _ps_to_private(ps));
 }
Index: lib/libc/citrus/citrus_ctype_local.h
===
RCS file: /home/mdempsky/anoncvs/cvs/src/lib/libc/citrus/citrus_ctype_local.h,v
retrieving revision 1.2
diff -u -p -r1.2 citrus_ctype_local.h
--- lib/libc/citrus/citrus_ctype_local.h27 Jul 2010 16:59:03 -  
1.2
+++ lib/libc/citrus/citrus_ctype_local.h25 May 2012 01:36:32 -
@@ -36,43 +36,45 @@ size_t  _citrus_##_e_##_ctype_mbrtowc(wch
  const char * __restrict, size_t,  \
  void * __restrict);   \
 int_citrus_##_e_##_ctype_mbsinit(const void * __restrict); \
-size_t _citrus_##_e_##_ctype_mbsrtowcs(wchar_t * __restrict,   \
-   const char ** __restrict,   \
-   size_t, void * __restrict); \
+size_t _citrus_##_e_##_ctype_mbsnrtowcs(wchar_t * __restrict,  \
+const char ** __restrict,  \
+size_t, size_t,\
+void * __restrict);\
 size_t _citrus_##_e_##_ctype_wcrtomb(char * __restrict, wchar_t,   \
  void * __restrict);   \
-size_t _citrus_##_e_##_ctype_wcsrtombs(char * __restrict,  \
-   const wchar_t ** __restrict,\
-   size_t, void * __restrict); \
+size_t _citrus_##_e_##_ctype_wcsnrtombs(char * __restrict, \
+

Re: [WIP] devel/eclipse4/sdk

[Matthew Dempsky]

On Sun, May 20, 2012 at 2:26 PM, Stefan Unterweger ste...@aleturo.com wrote:
 You have missed a build dependency on 'archivers/unzip'.

Good catch, thanks.  I'll fix that in the next version I mail out.

 However, even if everything seems to build, it still fails at the end
 when trying to install it. It seems as if there is some JAR file
 missing, but I don't understand the build process well enough to guess
 what might be failing here. I've unpacked all the distfiles to see
 whether there's just some problem in picking the JAR up, but it isn't
 there anywhere in the ports directory.

Yeah, for some reason the i386 and amd64 Eclipse distribution jars use
slightly different versions of some of the bundled components.  I'll
make sure the next version handles this correctly.

 Thanks in the meantime for your effort. :o)

Thanks for testing!

Re: c++ headers w/ -pedantic, overflow in implicit constant conversion

[Matthew Dempsky]

Oh even if it's not signed that ternary branch will still be in code. I
see. Hm.
On May 10, 2012 9:23 AM, Matthew Dempsky matt...@dempsky.org wrote:

Re: Combining ports built with PCC and GCC

[Matthew Dempsky]

On Tue, May 8, 2012 at 7:43 PM, Brett brett.ma...@gmx.com wrote:
 I am wondering if this will work ok the other way round?

In theory, GCC and PCC should implement the same ABI and so it should
work either way.

In practice, good luck.

Re: memory compile sizes

[Matthew Dempsky]

On Thu, Apr 19, 2012 at 7:26 AM, Marc Espie es...@nerim.net wrote:
 On Thu, Apr 19, 2012 at 02:57:57PM +0100, Stuart Henderson wrote:
 On 2012/04/19 15:42, Marc Espie wrote:
  Yeah, the only issue so far is that the make-wrapper process is C code, so
  it needs to be compiled and deployed on every host

 we ship with a wrapper in base ;)

 /usr/bin/time -l

 Up to a point. This means parsing the log files to find that entry.

Nah, just direct time's output to a different file:

$ cat logtime
#!/bin/sh
fn=$1; shift
exec /usr/bin/time -l sh -c 'exec $@ 29 9-' -- $@ 92 2$fn
$ ./logtime time.out sh -c 'echo stdout; echo stderr 2'
stdout
stderr
$ cat time.out
0.00 real 0.00 user 0.00 sys
   504  maximum resident set size
 0  average shared memory size
 0  average unshared data size
 0  average unshared stack size
   146  minor page faults
 0  major page faults
 0  swaps
 0  block input operations
 0  block output operations
 0  messages sent
 0  messages received
 0  signals received
 0  voluntary context switches
 0  involuntary context switches

:)

 It's feasible,
 but not really nice... and /usr/bin/time will fail on some signals.

Hm, how so?

Re: memory compile sizes

[Matthew Dempsky]

On Tue, Apr 24, 2012 at 2:42 PM, Marc Espie es...@nerim.net wrote:
 Well, yuck, this makes for ways too many extra processes just for that.

There are no more processes than your wrapper program, and only two
more execs of /bin/sh. Considering make's primary task is forking and
exec'ing /bin/sh processes, I doubt you'd notice the overhead. :P

Anyway, it was a tongue-in-cheek proposal.

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2012/04/12 16:27:20

Modified files:
devel/jdk/1.7  : Makefile 
devel/jdk/1.7/patches: 
   
patch-jdk_src_share_classes_java_lang_ClassLoader_java 

Log message:
Fix our patch for ClassLoader.loadLibrary().  Make sure that we prefer
libfoo.so.10.0 over libfoo.so.9, and fix the regex to prevent false
positive matches.

ok kurt@

UPDATE: math/cgal

[Matthew Dempsky]

Diff below updates CGAL from 3.8 to 3.9.  A few remarks:

  * cgal-3.8 has to be uninstalled before cgal-3.9 can be built.  The
package tries to include older installed headers from
/usr/local/include before the newer packaged headers, so many
prototypes are missing or wrong.  (I spent a little while
investigating if this could be resolved somehow, but I'm pretty
clueless with CMake and failed to figure it out.)

  * I renamed /usr/local/share/doc/CGAL-3.9 to /usr/local/share/doc/CGAL.

  * I bumped all the shared library versions; not sure if major bumps
are really necessary, but it didn't seem worth looking into more
closely.

  * Switched to .tar.xz since CGAL doesn't build on VAX anyway (due to
IEEE floating point hardware dependencies for fenv.h).

Quickly tested that OpenSCAD still compiles and runs on amd64.

Index: Makefile
===
RCS file: /home/mdempsky/anoncvs/cvs/ports/math/cgal/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile16 Sep 2011 10:31:22 -  1.4
+++ Makefile29 Nov 2011 22:09:18 -
@@ -5,15 +5,14 @@ NOT_FOR_ARCHS =   vax
 
 COMMENT =  Computational Geometry Algorithms Library
 
-DISTNAME = CGAL-3.8
+DISTNAME = CGAL-3.9
 PKGNAME =  ${DISTNAME:L}
-REVISION = 1
 
 SHARED_ONLY =  Yes
-SHARED_LIBS =  CGAL0.0 \
-   CGAL_Core   0.0 \
-   CGAL_ImageIO0.0 \
-   CGAL_Qt40.0 
+SHARED_LIBS =  CGAL1.0 \
+   CGAL_Core   1.0 \
+   CGAL_ImageIO1.0 \
+   CGAL_Qt41.0 
 
 CATEGORIES =   math
 
@@ -29,8 +28,10 @@ PERMIT_DISTFILES_FTP =   Yes
 WANTLIB =  GL GLU ICE SM X11 Xext boost_thread-mt gmp gmpxx \
lib/qt4/QtGui lib/qt4/QtOpenGL m=5.3 mpfr stdc++ z
 
+EXTRACT_SUFX = .tar.xz
+
 # Awkward hosting site; see https://gforge.inria.fr/frs/?group_id=52 for files 
index.
-MASTER_SITES = https://gforge.inria.fr/frs/download.php/28500/
+MASTER_SITES = https://gforge.inria.fr/frs/download.php/29122/
 
 MODULES =  devel/cmake \
x11/qt4
@@ -45,5 +46,8 @@ CONFIGURE_ENV = CFLAGS=${CFLAGS
 
 post-patch:
rm ${WRKSRC}/scripts/cgal_make_macosx_app
+
+post-install:
+   cd ${PREFIX}/share/doc  mv CGAL-3.9 CGAL
 
 .include bsd.port.mk
Index: distinfo
===
RCS file: /home/mdempsky/anoncvs/cvs/ports/math/cgal/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo29 Apr 2011 17:47:50 -  1.1.1.1
+++ distinfo29 Nov 2011 21:33:52 -
@@ -1,5 +1,5 @@
-MD5 (CGAL-3.8.tar.gz) = uKeeYuTYuotknYFa670cCg==
-RMD160 (CGAL-3.8.tar.gz) = Xl4TI65FPZKOhbT2p2R/nW0pc9A=
-SHA1 (CGAL-3.8.tar.gz) = I3SN8eYNYtoWbS45VzKuL+J0MX0=
-SHA256 (CGAL-3.8.tar.gz) = se3VGIYTTPCG0XmCxQ9xAleBFWHSiLQ5rzprxjI4ntQ=
-SIZE (CGAL-3.8.tar.gz) = 14112547
+MD5 (CGAL-3.9.tar.xz) = VCSQ4j0R211BmkNnkBaQCA==
+RMD160 (CGAL-3.9.tar.xz) = A0CDe7V4JNvwg2HiW/u5G9AaFmg=
+SHA1 (CGAL-3.9.tar.xz) = SL/4erJuATtYPuNPAhpgJcS4HN8=
+SHA256 (CGAL-3.9.tar.xz) = pdUPN4ixrNNKIO+EwHH462burMXhJ2ApLW98D/BBAiw=
+SIZE (CGAL-3.9.tar.xz) = 9853500
Index: pkg/PLIST
===
RCS file: /home/mdempsky/anoncvs/cvs/ports/math/cgal/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST   25 Jun 2011 19:12:36 -  1.2
+++ pkg/PLIST   29 Nov 2011 21:59:53 -
@@ -162,6 +162,7 @@ include/CGAL/Arr_default_dcel.h
 include/CGAL/Arr_default_overlay_traits.h
 include/CGAL/Arr_enums.h
 include/CGAL/Arr_extended_dcel.h
+include/CGAL/Arr_extended_rational_arc_traits_d_1.h
 include/CGAL/Arr_face_index_map.h
 include/CGAL/Arr_face_map.h
 include/CGAL/Arr_geodesic_arc_on_sphere_partition_traits_2.h
@@ -181,7 +182,6 @@ include/CGAL/Arr_geometry_traits/Conic_x
 include/CGAL/Arr_geometry_traits/Consolidated_curve_data_aux.h
 include/CGAL/Arr_geometry_traits/Curve_data_aux.h
 include/CGAL/Arr_geometry_traits/Hyperbolic_arc_2.h
-include/CGAL/Arr_geometry_traits/One_root_number.h
 include/CGAL/Arr_geometry_traits/Polyline_2.h
 include/CGAL/Arr_geometry_traits/Rational_arc_2.h
 include/CGAL/Arr_geometry_traits/Segment_assertions.h
@@ -223,7 +223,19 @@ include/CGAL/Arr_point_location/Trapezoi
 include/CGAL/Arr_point_location/Trapezoidal_decomposition_2_iostream.h
 include/CGAL/Arr_point_location/Trapezoidal_decomposition_2_misc.h
 include/CGAL/Arr_polyline_traits_2.h
+include/CGAL/Arr_rat_arc/
+include/CGAL/Arr_rat_arc/Algebraic_point_2.h
+include/CGAL/Arr_rat_arc/Base_rational_arc_ds_1.h
+include/CGAL/Arr_rat_arc/Cache.h
+include/CGAL/Arr_rat_arc/Rational_arc_d_1.h
+include/CGAL/Arr_rat_arc/Rational_function.h

Re: Allow clang++ to work on OpenBSD

[Matthew Dempsky]

On Wed, Nov 23, 2011 at 9:04 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
 Hard to tell if you don't explain what the problem is,

The problem is clang++ is stricter about C and C++ rules than GCC is.
E.g., it doesn't like conflicting prototypes, whereas GCC will happily
ignore them in certain cases.  See
http://marc.info/?l=openbsd-portsm=129783295016631w=2 for more
background.

Re: systrace: intercept_get_string: string too long

[Matthew Dempsky]

On Tue, Oct 18, 2011 at 12:33 AM, Stuart Henderson s...@spacehopper.org wrote:
 nothing to do with systrace, you need to uninstall samba
 and/or .libs-samba before building.

Not entirely true.  systrace only supports extracting strings up to
8192 bytes long, and that includes inspecting arguments to execve(2).
When gmake sees a command with some shell syntax (some of Samba's
Makefiles have comments at the end of their linking commands), it
execve(2)s sh, -c, cmd arg1 arg2 ... instead of execve(2)ing
cmd, arg1, arg2, ... directly.  When linking hundreds of objects
into a single library, the cmd arg1 arg2 ... string can exceed 8192
bytes.

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/09/18 17:29:51

Modified files:
infrastructure/db: systrace.filter 

Log message:
Add rules for USE_SYSTRACE to support *at(2) system calls.

ok jasper@, sthen@

Eliminate mention of xz/sparc issues in bsd.port.mk.5

[Matthew Dempsky]

bsd.port.mk no longer warns about xz/sparc issues, so it seems like
bsd.port.mk.5 shouldn't need to either.

ok?

Index: bsd.port.mk.5
===
RCS file: /home/mdempsky/anoncvs/cvs/src/share/man/man5/bsd.port.mk.5,v
retrieving revision 1.284
diff -u -p -r1.284 bsd.port.mk.5
--- bsd.port.mk.5   15 Jul 2011 23:11:59 -  1.284
+++ bsd.port.mk.5   29 Aug 2011 16:21:56 -
@@ -1130,7 +1130,7 @@ do
 done
 .Ed
 The use of xz archives is discouraged, as it makes things impossible to
-build on vax and very annoying on sparc.
+build on vax.
 .It Ev EXTRACT_ONLY
 Set if not all ${DISTFILES} should be extracted at do-extract stage.
 Default value is ${DISTFILES}.

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/08/16 12:09:10

Modified files:
cad/openscad   : Makefile distinfo 

Log message:
update to 2011.06; ok landry@

Update cad/openscad to 2011.06

[Matthew Dempsky]

Fixes a few minor Makefile issues I noticed while looking at this
again:

  - Doesn't need cmake to build.

  - Pass VERSION=${V} to qmake so that the embedded version strings
will be consistent rather than varying by build date.

  - No need to run ${SUBST_CMD} on openscad.pro; there are no
substitutions to be made.

  - Eliminate trailing white space.

ok?

Index: Makefile
===
RCS file: /home/mdempsky/anoncvs/cvs/ports/cad/openscad/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile29 Apr 2011 18:55:37 -  1.1.1.1
+++ Makefile16 Aug 2011 16:21:49 -
@@ -2,7 +2,7 @@
 
 COMMENT =  the programmer's solid 3D CAD modeller
 
-V =2011.04
+V =2011.06
 DISTNAME = openscad-${V}
 
 CATEGORIES =   cad
@@ -26,7 +26,6 @@ DISTFILES =   openscad-${V}.src.tar.gz
 
 MODULES =  x11/qt4
 BUILD_DEPENDS =devel/bison \
-   devel/cmake \
devel/flex \
math/eigen2
 LIB_DEPENDS =  devel/boost \
@@ -35,16 +34,17 @@ LIB_DEPENDS =   devel/boost \
graphics/glew \
graphics/opencsg \
math/cgal
-   
-CONFIGURE_ENV =EIGEN2DIR=${LOCALBASE}/include/eigen2
+
+QMAKE_ENV =EIGEN2DIR=${LOCALBASE}/include/eigen2
+QMAKE_FLAGS =  VERSION=${V}
 MAKE_ENV = INSTALL_ROOT=${DESTDIR}
 
 pre-configure:
-   ${SUBST_CMD} ${WRKSRC}/openscad.pro
ln -sf ${LOCALBASE}/bin/gflex ${WRKDIR}/bin/flex
ln -sf ${LOCALBASE}/bin/bison ${WRKDIR}/bin/yacc
 
 do-configure:
-   cd ${WRKSRC}  ${SETENV} ${CONFIGURE_ENV} qmake4 openscad.pro
+   cd ${WRKSRC}  \
+   ${SETENV} ${QMAKE_ENV} qmake4 ${QMAKE_FLAGS} openscad.pro
 
 .include bsd.port.mk
Index: distinfo
===
RCS file: /home/mdempsky/anoncvs/cvs/ports/cad/openscad/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo29 Apr 2011 18:55:37 -  1.1.1.1
+++ distinfo16 Aug 2011 16:21:59 -
@@ -1,5 +1,5 @@
-MD5 (openscad-2011.04.src.tar.gz) = 8fNqSmkCinD5F71nz45hyA==
-RMD160 (openscad-2011.04.src.tar.gz) = JGStMhXnSpVuek59AEghww481NI=
-SHA1 (openscad-2011.04.src.tar.gz) = AicvVzoRmbBLlizm93pWNio9hP0=
-SHA256 (openscad-2011.04.src.tar.gz) = 
BmOK6MeK62wVsVQDs09yIpiUcz6vV9SpiLZQPfU1wDY=
-SIZE (openscad-2011.04.src.tar.gz) = 918915
+MD5 (openscad-2011.06.src.tar.gz) = uEAkPPGi910BEPlskmZZXA==
+RMD160 (openscad-2011.06.src.tar.gz) = 1dS1JT81GS/GrQNmQfy/F/22zS0=
+SHA1 (openscad-2011.06.src.tar.gz) = MPHXJmHvVTWdlbaxb9oAW7gXfks=
+SHA256 (openscad-2011.06.src.tar.gz) = 
aTwMoDNjnFLD0tEfTVN5Y9w6O8DS46LmPaRg9omMMNs=
+SIZE (openscad-2011.06.src.tar.gz) = 920506

Re: systrace problem with mkdirat and openat

[Matthew Dempsky]

On Sat, Jul 23, 2011 at 9:43 AM, Markus Lude markus.l...@gmx.de wrote:
 systrace: deny user: markus, prog: /usr/local/bin/gtar, pid:
 25619(0)[31757], policy: /usr/bin/make, filters: 197, syscall:
 native-mkdirat(318), args: 24
 /usr/local/bin/gtar: git-1.7.5: Cannot mkdir: Operation not permitted

This is a known limitation of USE_SYSTRACE at the moment.  Until
systrace(8) understands the new *at(8) system calls, you'll need to
either disable USE_SYSTRACE or install from packages.

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/07/12 12:08:41

Modified files:
misc/findutils : Makefile 
Added files:
misc/findutils/patches: patch-gnulib_lib_openat_h 

Log message:
Temporary workaround until I get an ok to add AT_REMOVEDIR to fcntl.h.

ok naddy@

Re: devel/snappy

[Matthew Dempsky]

On Sat, Jul 9, 2011 at 8:23 PM, Piotr Sikora piotr.sik...@frickle.com wrote:
 I started looking at this myself a few days ago in case it
 might be any use for hibernate support (then I spotted it was
 C++ and figured probably not) so I had half a port in my
 tree already ;-)

 It comes with C bindings (snappy-c.h), so this shouldn't be a problem,
 unless there is some no C++ in base policy?

Not strictly, but the kernel at least doesn't even support linking
with C++ code.

Re: gtar, xz (was: Re: CVS: cvs.openbsd.org: ports)

[Matthew Dempsky]

On Wed, Jun 15, 2011 at 3:11 PM, Amit Kulkarni amitk...@gmail.com wrote:
 devel/coccinelle?

That looks awesome.  Has anyone played with using it for OpenBSD code
(e.g., kernel and base)?

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/04/29 11:47:51

Log message:
CGAL 3.8 port; needs recent libm (i.e., fenv.h) to build

Status:

Vendor Tag: matthew
Release Tags:   matthew_2011-Apr-29

N ports/math/cgal/Makefile
N ports/math/cgal/distinfo
N ports/math/cgal/pkg/DESCR
N ports/math/cgal/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/04/29 11:55:50

Modified files:
math   : Makefile 

Log message:
add cgal

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/04/29 12:00:04

Log message:
Add OpenCSG 1.3.1.

ok landry@

OpenCSG is a library that does image-based CSG rendering using OpenGL.
OpenCSG is written in C++ and supports most modern graphics hardware.

CSG is short for Constructive Solid Geometry and denotes an approach
to model complex 3D-shapes using simpler ones. I.e., two shapes can be
combined by taking the union of them, by intersecting them, or by
subtracting one shape of the other. The most basic shapes, which are
not result of such a CSG operation, are called primitives. Primitives
must be solid, i.e., they must have a clearly defined interior and
exterior. By construction, a CSG shape is also solid then.

Image-based CSG rendering (also z-buffer CSG rendering) is a term that
denotes algorithms for rendering CSG shapes without an explicit
calculation of the geometric boundary of a CSG shape. Such algorithms
use frame-buffer settings of the graphics hardware, e.g., the depth
and stencil buffer, to compose CSG shapes. OpenCSG implements a
variety of those algorithms, namely the Goldfeather algorithm and the
SCS algorithm, both of them in several variants.

Status:

Vendor Tag: matthew
Release Tags:   matthew_2011-Apr-29

N ports/graphics/opencsg/Makefile
N ports/graphics/opencsg/distinfo
N ports/graphics/opencsg/patches/patch-src_src_pro
N ports/graphics/opencsg/pkg/DESCR
N ports/graphics/opencsg/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/04/29 12:15:04

Modified files:
graphics   : Makefile 

Log message:
add opencsg

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/04/29 12:55:37

Log message:
Add cad/openscad.

ok landry@

OpenSCAD is a software for creating 3D CAD objects.

Unlike most free software for creating 3D models, it does not focus on
the artistic aspects of 3D modelling but instead on the CAD aspects.
Thus it is more suitable for creating 3D models of machine parts but
perhaps not when creating computer-animated movies.

OpenSCAD is not an interactive modeller. Instead it is something like
a 3D-compiler that reads in a script file that describes the object
and renders the 3D model from this script file. This gives designers
full control over the modelling process and enables them to easily
change any step in the modelling process or make designes that are
defined by configurable parameters.

Status:

Vendor Tag: matthew
Release Tags:   matthew_2011-Apr-29

N ports/cad/openscad/Makefile
N ports/cad/openscad/distinfo
N ports/cad/openscad/patches/patch-boost_pri
N ports/cad/openscad/pkg/DESCR
N ports/cad/openscad/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/04/29 12:56:45

Modified files:
cad: Makefile 

Log message:
add openscad

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/04/29 19:07:14

Modified files:
math/cgal  : Makefile 

Log message:
cgal needs m=5.3 for fenv.h support

Re: [NEW] graphics/opencsg

[Matthew Dempsky]

Ping?

On Mon, Apr 18, 2011 at 03:08:42PM -0700, Matthew Dempsky wrote:
 Attached is a port for graphics/opencsg; you can also find it at
 https://github.com/mdempsky/openbsd-stuff/tree/master/ports/graphics/opencsg
 
 The port's pretty simple, but a few things I want to check first:
 
   1. The port only builds a shared object; should/must I patch it to
  build a static library too?  Or mark it as only for shared
  arches?
 
   2. The main code is licensed GPLv2 (with an exception for linking
  against the CGAL library), but it bundles GLEW (BSD) and
  RenderTexture (zlib).  I patched the build files to use
  graphics/glew instead of the bundled GLEW.  Is it correct to
  summarize this as GPLv2 with CGAL exception?  (RenderTexture is
  only used internally; it's not intentionally exposed to users,
  though currently the symbols are still visible in the resulting
  .so.)
 
   3. Should I make a separate RenderTexture port instead, and patch
  OpenCSG to depend on that?
 
   4. libopencsg.so depends on symbols from libGLEW.so, but upstream
  doesn't actually link it against libGLEW.so, so I only added
  graphics/glew to BUILD_DEPENDS rather than LIB_DEPENDS.  Is this
  correct, or should I patch it to link against libGLEW.so and/or
  add to LIB_DEPENDS instead?

[NEW] math/cgal

[Matthew Dempsky]

The attached port is for the Computational Geometry Algorithms Library
(see http://www.cgal.org).  You can also find my port on github at
https://github.com/mdempsky/openbsd-stuff/tree/master/ports/math/cgal.

Be advised that this port depends on fenv.h support in libm, which
martynas@ just committed / enabled.  (However, vax doesn't support
fenv.h, so should I add an explicit NOT_FOR_ARCHS=vax?)

ok?


cgal.tar.gz
Description: application/tar-gz

[NEW] cad/openscad

[Matthew Dempsky]

Attached is a port for OpenSCAD, The Programmers Solid 3D CAD
Modeller.  It depends on my two other outstanding ports,
graphics/opencsg and math/cgal.  Also, as with those, you can find the
port on my github page at
https://github.com/mdempsky/openbsd-stuff/tree/master/ports/cad/openscad

ok?


openscad.tar.gz
Description: application/tar-gz

Re: [NEW] math/cgal

[Matthew Dempsky]

On Thu, Apr 28, 2011 at 3:13 PM, Landry Breuil lan...@rhaalovely.net wrote:
 Yes for the latter.

Will do then.

 Bah, CGAL packages so many headers..

Yeah... =/

If you think that's bad, you should check out my OpenCASCADE port:
https://github.com/mdempsky/openbsd-stuff/blob/master/ports/cad/opencascade/pkg/PLIST
https://github.com/mdempsky/openbsd-stuff/blob/master/ports/cad/opencascade/pkg/PFRAG.shared

(Still badly WIP, and I just discovered they've cranked the version
twice since I last even looked at it... ugh.)

 You're missing the $OpenBSD$ Rcs ids in Makefile's comment, and do we
 really need bin/make_macosx_app_zomg ??

I doubt it, but I figured since it was installed by default that I'd
leave it in.  I'm happy to remove it.

 Otherwise reads good, same comment applies to openscad.

Cool.  I'll fix that one up too, and then send another email with updated ports.

Re: [NEW] graphics/opencsg

[Matthew Dempsky]

On Thu, Apr 28, 2011 at 2:39 PM, Landry Breuil lan...@rhaalovely.net wrote:
   3. Should I make a separate RenderTexture port instead, and patch
      OpenCSG to depend on that?

 That would be better, if more stuff want to depend on it later. If not..
 your call.

I think I'll leave it bundled for the time being then.  It's just one
.cpp and one .h file, and RenderTexture upstream doesn't even bother
distributing a real Makefile with it.

   4. libopencsg.so depends on symbols from libGLEW.so, but upstream
      doesn't actually link it against libGLEW.so, so I only added
      graphics/glew to BUILD_DEPENDS rather than LIB_DEPENDS.  Is this
      correct, or should I patch it to link against libGLEW.so and/or
      add to LIB_DEPENDS instead?

 It all depends if a binary linked with it fails at runtime or not. I'm
 not sure if there are previous similar things with libGL*.so.
 Explicitely linking with it might be safer.

Will do.

[NEW] graphics/opencsg

[Matthew Dempsky]

Attached is a port for graphics/opencsg; you can also find it at
https://github.com/mdempsky/openbsd-stuff/tree/master/ports/graphics/opencsg

The port's pretty simple, but a few things I want to check first:

  1. The port only builds a shared object; should/must I patch it to
 build a static library too?  Or mark it as only for shared
 arches?

  2. The main code is licensed GPLv2 (with an exception for linking
 against the CGAL library), but it bundles GLEW (BSD) and
 RenderTexture (zlib).  I patched the build files to use
 graphics/glew instead of the bundled GLEW.  Is it correct to
 summarize this as GPLv2 with CGAL exception?  (RenderTexture is
 only used internally; it's not intentionally exposed to users,
 though currently the symbols are still visible in the resulting
 .so.)

  3. Should I make a separate RenderTexture port instead, and patch
 OpenCSG to depend on that?

  4. libopencsg.so depends on symbols from libGLEW.so, but upstream
 doesn't actually link it against libGLEW.so, so I only added
 graphics/glew to BUILD_DEPENDS rather than LIB_DEPENDS.  Is this
 correct, or should I patch it to link against libGLEW.so and/or
 add to LIB_DEPENDS instead?


opencsg-1.3.1.tar.gz
Description: application/tar-gz

Re: Making clang++ actually work ( WAS Re: Changing llvm/clang++ to use libstdc++ from ports instead of base)

[Matthew Dempsky]

On Fri, Apr 08, 2011 at 12:43:03PM -0500, Amit Kulkarni wrote:
 I am in the process of updating llvm+clang from 2.8 == 2.9
 (maintainer is ports@).

jsg@ already has an update for this.  I believe he's just checking for
broken dependencies now.

 Will some guru please find time to investigate this issue?

I'm hardly a guru on this topic, but I think the diff below should
resolve the problem.  I'm double checking now that this doesn't cause
any build problems for base+xenocara, but it'd be nice if someone
could test to see if it causes problems for the ports tree.  (This
only affects gcc4 arches.)


Index: gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h
===
RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v
retrieving revision 1.2
diff -u -p gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h
--- gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h 26 May 2010 
11:23:06 -  1.2
+++ gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h 8 Apr 2011 
18:13:19 -
@@ -35,12 +35,5 @@
 // file will come before all others.
 
 #define _GLIBCXX_USE_C99 1
-#define _GLIBCXX_USE_C99_CHECK 1
-#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999))
-#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1
-#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || 
!defined __LONG_LONG_SUPPORTED)
-#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1
-#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE
-typedef __builtin_va_list __gnuc_va_list;
 
 #endif

Re: boost warning fix

[Matthew Dempsky]

On Tue, Mar 29, 2011 at 8:15 AM, Federico G. Schwindt fg...@lodoss.net wrote:
  Comments? Any OKs?

I think this changes the ABI, so you should probably bump the soname
if you're going to commit this.

However, it seems like a deliberate decision on their part to omit the
virtual tag here (not familiar with context to know why, but since
it's protected, I can imagine it's safe), so I'm inclined to leave it
alone.

Updating Eclipse?

[Matthew Dempsky]

Is anyone working on (or have plans to work on) updating the Eclipse
port?  The version in tree appears to have languished behind quite a
bit.

FreeBSD appears to have a port for 3.6.1; haven't looked yet how
useful it is for OpenBSD though:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/eclipse-devel/

Re: re emacs23 update

[Matthew Dempsky]

On Tue, Mar 15, 2011 at 9:35 AM, Manuel Giraud
manuel.gir...@univ-nantes.fr wrote:
 Here's the new version of emacs 23 port. Tested and ok on i386 GENERIC.MP

In post-install, since bin/emacs and bin/emacs-${VERSION} are hard
linked to the same file, you only need to chmod -t one of them.

Shouldn't you get rid of the REVISION-{el,main} = 0 lines too, since
it's a version bump?

Building on amd64 fails because of not finding tsang-b5.el.gz.  You'll
need to do something like:

post-install:
chmod -t ${PREFIX}/bin/emacs
.if ${MACHINE_ARCH} == amd64 || ${MACHINE_ARCH} == mips64
gzip -f ${PREFIX}/share/emacs/${VERSION}/leim/quail/tsang-b5.el

post-extract:
touch ${WRKSRC}/leim/quail/tsang-b5.el
.endif

Re: emacs 23.2 (the return)

[Matthew Dempsky]

On Thu, Mar 10, 2011 at 6:46 AM, Manuel Giraud
manuel.gir...@univ-nantes.fr wrote:
 It is an obsolete feature but it seems to be caused by the emacs install
 process. Don't know if it worth the effort to fight for it upstream.

post-install can easily fix it up.

However, I don't understand exactly what @bin signifies, so I don't
know if it's worth fixing or not either.  But if so, the existing
emacs ports might deserve a rev bump to fix them as well.

Re: emacs 23.2 (the return)

[Matthew Dempsky]

On Wed, Mar 9, 2011 at 5:07 AM, Manuel Giraud
manuel.gir...@univ-nantes.fr wrote:
 Anyone to test on other archs (and eventually, we'll have more recent
 emacs in OpenBSD 5.0) ?

Seems to work on amd64.

I noticed that make port-lib-depends-check says that the X11-xcb
WANTLIB is extraneous.

Also, is it correct that bin/emacs and bin/emacs-${VERSION} aren't
marked as @bin in pkg/PLIST-main?  It seems to be because the
executables are installed with the sticky bit.

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2011/03/07 23:22:16

Log message:
Import dfu-programmer 0.5.4.

Tweaks and ok jasper@.

Status:

Vendor Tag: matthew
Release Tags:   matthew_2011-Mar-08

N ports/devel/dfu-programmer/Makefile
N ports/devel/dfu-programmer/distinfo
N ports/devel/dfu-programmer/pkg/DESCR
N ports/devel/dfu-programmer/pkg/PLIST

No conflicts created by this import

NEW: devel/dfu-programmer 0.5.4

[Matthew Dempsky]

Attached is a port for dfu-programmer (http://dfu-programmer.sf.net/).
To build it successfully, you'll need to ensure you have r1.8 or newer
of /usr/include/stdarg.h installed.

I've tested on amd64 by successfully updating the 8u2 firmware on my
Arduino Uno.

(I know the ports tree is still locked for new directories; just
sending this out in advance.)


dfu-programmer.tar.gz
Description: application/tar-gz

UPDATE: www/chromium 9.0.597.107

[Matthew Dempsky]

The diff below updates chromium to 9.0.597.107 (the latest stable
channel release), which fixes multiple security issues[1].

Additionally, it removes the vestigial LINK=/usr/bin/g++ environment
variable, enables SSE2 support on amd64, and fixes a bad #ifdef patch
(noticed by a failed attempt to build with Clang).

No immediately noticeable regressions on amd64.

ok?

[1] 
http://googlechromereleases.blogspot.com/2011/02/stable-channel-update_28.html


Index: Makefile
===
RCS file: /cvs/ports/www/chromium/Makefile,v
retrieving revision 1.25
diff -u -p Makefile
--- Makefile2 Mar 2011 11:11:31 -   1.25
+++ Makefile3 Mar 2011 06:12:45 -
@@ -4,11 +4,9 @@ ONLY_FOR_ARCHS=i386 amd64
 
 COMMENT=   Chromium browser
 
-V= 9.0.597.94
+V= 9.0.597.107
 DISTNAME=  chromium-${V}
 
-REVISION=  1
-
 CATEGORIES=www
 
 HOMEPAGE=  http://sightly.net/peter/openbsd/chromium/
@@ -61,8 +59,7 @@ LIB_DEPENDS=  devel/libexecinfo \
 
 # Set BUILDTYPE to Debug (or omit it) for a debug build
 BUILDTYPE= Release
-MAKE_ENV=  BUILDTYPE=${BUILDTYPE} V=1 \
-   LINK=/usr/bin/g++
+MAKE_ENV=  BUILDTYPE=${BUILDTYPE} V=1
 
 USE_GMAKE= Yes
 
@@ -85,8 +82,10 @@ GYP_DEFS=-Duse_system_bzip2=1 \
-Duse_system_vpx=1 \
-Duse_system_zlib=0 \
-Ddisable_nacl=1 \
-   -Ddisable_sse2=1 \
-DOS=openbsd
+.if ${MACHINE_ARCH} != amd64
+GYP_DEFS+= -Ddisable_sse2=1
+.endif
 
 pre-configure:
@ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python
Index: distinfo
===
RCS file: /cvs/ports/www/chromium/distinfo,v
retrieving revision 1.5
diff -u -p distinfo
--- distinfo12 Feb 2011 10:42:43 -  1.5
+++ distinfo3 Mar 2011 06:12:45 -
@@ -1,5 +1,5 @@
-MD5 (chromium-9.0.597.94.tar.bz2) = QThrPfdDV18jJcTGTW17xw==
-RMD160 (chromium-9.0.597.94.tar.bz2) = WBbCjd+usxxbiqiC3iJIx4D4yww=
-SHA1 (chromium-9.0.597.94.tar.bz2) = SocNpBriV4HkgG7CyVcDKC/MxNg=
-SHA256 (chromium-9.0.597.94.tar.bz2) = 
cZTZmaA7tUgTzEn5eN2I9bCM3UDO5Ny+T/VjnAyj6NU=
-SIZE (chromium-9.0.597.94.tar.bz2) = 140800844
+MD5 (chromium-9.0.597.107.tar.bz2) = RUHyuE31gWGCYu/hWJAbLw==
+RMD160 (chromium-9.0.597.107.tar.bz2) = fuyAs2P8xHtGDppUwhlA0wnMB50=
+SHA1 (chromium-9.0.597.107.tar.bz2) = TryT4gL4f3JO/7F0RZw/XCoQyc0=
+SHA256 (chromium-9.0.597.107.tar.bz2) = 
H95jUBfNJ44JJCR43jRpFm3Yn5PJXOZ6z438Z93fgVk=
+SIZE (chromium-9.0.597.107.tar.bz2) = 141198237
Index: patches/patch-app_gfx_gl_gl_context_egl_cc
===
RCS file: /cvs/ports/www/chromium/patches/patch-app_gfx_gl_gl_context_egl_cc,v
retrieving revision 1.1
diff -u -p patches/patch-app_gfx_gl_gl_context_egl_cc
--- patches/patch-app_gfx_gl_gl_context_egl_cc  8 Feb 2011 09:43:02 -   
1.1
+++ patches/patch-app_gfx_gl_gl_context_egl_cc  3 Mar 2011 06:12:45 -
@@ -15,7 +15,7 @@ $OpenBSD: patch-app_gfx_gl_gl_context_egl_cc,v 1.1 201
  return true;
  
 -#ifdef OS_LINUX
-+#ifdef OS_LINUX || defined(OS_OPENBSD)
++#if defined(OS_LINUX) || defined(OS_OPENBSD)
EGLNativeDisplayType native_display = x11_util::GetXDisplay();
  #else
EGLNativeDisplayType native_display = EGL_DEFAULT_DISPLAY;
Index: patches/patch-gpu_gpu_gyp
===
RCS file: /cvs/ports/www/chromium/patches/patch-gpu_gpu_gyp,v
retrieving revision 1.2
diff -u -p patches/patch-gpu_gpu_gyp
--- patches/patch-gpu_gpu_gyp   8 Feb 2011 09:43:02 -   1.2
+++ patches/patch-gpu_gpu_gyp   3 Mar 2011 06:12:45 -
@@ -1,7 +1,7 @@
 $OpenBSD: patch-gpu_gpu_gyp,v 1.2 2011/02/08 09:43:02 espie Exp $
 gpu/gpu.gyp.orig   Fri Jan 21 10:19:48 2011
-+++ gpu/gpu.gypSun Jan 23 23:27:34 2011
-@@ -180,7 +180,7 @@
+--- gpu/gpu.gyp.orig   Fri Feb 18 02:22:12 2011
 gpu/gpu.gypWed Mar  2 18:00:11 2011
+@@ -206,7 +206,7 @@
  'command_buffer/service/texture_manager.cc',
],
'conditions': [
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/chromium/pkg/PLIST,v
retrieving revision 1.4
diff -u -p pkg/PLIST
--- pkg/PLIST   8 Feb 2011 09:43:02 -   1.4
+++ pkg/PLIST   3 Mar 2011 06:12:45 -
@@ -1,7 +1,7 @@
 @comment $OpenBSD: PLIST,v 1.4 2011/02/08 09:43:02 espie Exp $
 bin/chrome
 chrome/
-chrome/chrome
+@bin chrome/chrome
 chrome/chrome.pak
 chrome/ffmpegsumo_nolink
 chrome/libffmpegsumo.so

Re: Changing llvm/clang++ to use libstdc++ from ports instead of base

[Matthew Dempsky]

On Wed, Feb 16, 2011 at 11:00 AM, Amit Kulkarni amitk...@gmail.com wrote:
 I did as Matthew said. I just defined the checks to be 0, then
 followed rebuilding gcc4 instructions in FAQ/current.html by
 rebuilding the libstdc++ headers (rm -rf /usr/include/g++ etc...).

I think we can just get rid of the *_{CHECK,DYNAMIC} defines
altogether.  E.g., Ubuntu doesn't bother putting them in their
os_defines.h.

Anyway, there's also at least a libc __cxa_finalize fix needed for
clang++ to be usable.  I'll put together some diffs to send out post
unlock and try to keep the release-testing distractions to a minimum
in the mean time. :)

Changing llvm/clang++ to use libstdc++ from ports instead of base

[Matthew Dempsky]

I know the trees locked right now, but I thought I'd send this out now
so it doesn't get lost.

Right now, clang++ tries to use libstdc++ from base (from g++ 4.2.1),
but even incredibly trivial programs fail to compile with it (e.g.,
hello world using iostream).  Using the libstdc++ from ports (i.e.,
g++ 4.2.4) seems to work much better.

Anyway, the hacky diff below makes a few changes:

  1. Searches for C++ header files from and links against ports
 libstdc++ instead of base libstdc++.  (Also, FWIW, libstdc++
 4.2.4 appears to still be GPL2+, not GPL3+ like the rest of GCC
 4.2.4; maybe worth investigating bringing into base.)

  2. When linking with -pthread, pass -lpthread to ld(1) instead of
 -pthread.

  3. Eliminates the -L/opt/gcc4/... patch hunk that only affected
 AuroraUX's driver code, not OpenBSD's.

I expect the literal /usr/local strings will need to be fixed
somehow, but not sure the best solution.  Also, I feel weird about
adding -L/usr/local/lib to the linker line, but eg++ already has this
behavior, so maybe it's okay (and should be done by default, not just
for C++ code).

I can't yet build Chromium with this diff (weird segmentation faults
in resulting executables that I haven't investigated yet), but it at
least gets further than crashing on the very first C++ file. :)


Index: patches/patch-tools_clang_lib_Driver_Tools_cpp
===
RCS file: /cvs/ports/devel/llvm/patches/patch-tools_clang_lib_Driver_Tools_cpp,v
retrieving revision 1.6
diff -N -u -p patches/patch-tools_clang_lib_Driver_Tools_cpp
--- patches/patch-tools_clang_lib_Driver_Tools_cpp  13 Jan 2011 00:15:50 
-  1.6
+++ patches/patch-tools_clang_lib_Driver_Tools_cpp  15 Feb 2011 18:50:21 
-
@@ -1,12 +1,22 @@
 $OpenBSD: patch-tools_clang_lib_Driver_Tools_cpp,v 1.6 2011/01/13 00:15:50 
jeremy Exp $
 --- tools/clang/lib/Driver/Tools.cpp.orig  Thu Sep  2 16:59:25 2010
-+++ tools/clang/lib/Driver/Tools.cpp   Thu Jan  6 11:29:39 2011
-@@ -2631,7 +2631,7 @@ void auroraux::Link::ConstructJob(Compilation C, cons
 tools/clang/lib/Driver/Tools.cpp   Mon Feb 14 17:32:05 2011
+@@ -2778,7 +2778,8 @@
+   if (!Args.hasArg(options::OPT_nostdlib) 
+   !Args.hasArg(options::OPT_nodefaultlibs)) {
+ if (D.CCCIsCXX) {
+-  CmdArgs.push_back(-lstdc++);
++  CmdArgs.push_back(-L/usr/local/lib);
++  CmdArgs.push_back(-lestdc++);
+   CmdArgs.push_back(-lm);
+ }
  
-   CmdArgs.push_back(Args.MakeArgString(-L/opt/gcc4/lib/gcc/
-+ getToolChain().getTripleString()
--   + /4.2.4));
-+   + /4.2.1));
+@@ -2787,7 +2788,7 @@
+ CmdArgs.push_back(-lgcc);
  
-   Args.AddAllArgs(CmdArgs, options::OPT_L);
-   Args.AddAllArgs(CmdArgs, options::OPT_T_Group);
+ if (Args.hasArg(options::OPT_pthread))
+-  CmdArgs.push_back(-pthread);
++  CmdArgs.push_back(-lpthread);
+ if (!Args.hasArg(options::OPT_shared))
+   CmdArgs.push_back(-lc);
+ CmdArgs.push_back(-lgcc);
Index: patches/patch-tools_clang_lib_Frontend_InitHeaderSearch_cpp
===
RCS file: 
/cvs/ports/devel/llvm/patches/Attic/patch-tools_clang_lib_Frontend_InitHeaderSearch_cpp,v
diff -N -u -p patches/patch-tools_clang_lib_Frontend_InitHeaderSearch_cpp
--- /dev/null   15 Feb 2011 11:50:21 -
+++ patches/patch-tools_clang_lib_Frontend_InitHeaderSearch_cpp 15 Feb 2011 
18:50:21 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- tools/clang/lib/Frontend/InitHeaderSearch.cpp.orig Fri Sep  3 09:45:53 2010
 tools/clang/lib/Frontend/InitHeaderSearch.cpp  Mon Feb 14 16:27:35 2011
+@@ -751,7 +751,7 @@
+ std::string t = triple.getTriple();
+ if (t.substr(0, 6) == x86_64)
+   t.replace(0, 6, amd64);
+-AddGnuCPlusPlusIncludePaths(/usr/include/g++,
++AddGnuCPlusPlusIncludePaths(/usr/local/include/c++/4.2.4,
+ t, , , triple);
+ break;
+   }

Re: Changing llvm/clang++ to use libstdc++ from ports instead of base

[Matthew Dempsky]

On Tue, Feb 15, 2011 at 11:57:44PM +0100, Marc Espie wrote:
 Finding out why it doesn't work with g++ from src would be 
 the correct approach.

Investigating further, it seems to boil down to _GLIBCXX_USE_C99_CHECK
in /usr/include/g++/*/bits/os_defines.h.  Including cstdio from base
effectively feeds the following to the compiler:

typedef unsigned long size_t;

extern C {
int snprintf(char *, size_t, const char *, ...)
  __attribute__((__format__ (printf, 3, 4)))
  __attribute__((__nonnull__ (3)))
  __attribute__((__bounded__ (__string__,1,2)));
}

namespace std {
  extern C int
  (snprintf)(char * restrict, size_t, const char * restrict, ...);
  using ::snprintf;
}

g++ doesn't mind the conflicting definitions for snprintf (it doesn't
seem to care about *any* conflicts actually; you could put int
snprintf(double x) and it's still happy), but clang++ does.

We don't define anything in os_defines.h in libstdc++ from ports, so
the the second chunk of code above never gets included.

Perhaps we can get rid of _GLIBCXX_USE_C99_CHECK (along with the other
*_CHECK defines) since it's apparently useless even with g++ and just
causes compile trouble with clang++?  Also, maybe useful to add
_GLIBCXX_USE_C99 to ports libstdc++?  (I'll test these ideas out
later.)

Re: potential qemu crash fix, please test

[Matthew Dempsky]

On Mon, Jan 24, 2011 at 03:43:30PM +, Federico G. Schwindt wrote:
 +--- net/socket.c.origMon Jan 24 15:34:58 2011
  net/socket.c Mon Jan 24 15:35:01 2011
 +@@ -195,7 +195,7 @@ static int net_socket_mcast_create(struct sockaddr_in 
 + /* Force mcast msgs to loopback (eg. several QEMUs in same host */
 + val = 1;
 + ret=setsockopt(fd, IPPROTO_IP, IP_MULTICAST_LOOP,
 +-   (const char *)val, sizeof(val));
 ++   (const char *)val, sizeof(char));
 + if (ret  0) {
 + perror(setsockopt(SOL_IP, IP_MULTICAST_LOOP));
 + goto fail;

Won't this break on sparc64, since it's a big-endian architecture?

Re: allow sshguard to build on gcc 3.x

[Matthew Dempsky]

On Mon, Sep 20, 2010 at 12:01 PM, Todd C. Miller
todd.mil...@courtesan.com wrote:
 Apparently gcc 3.x doesn't like:

    const char *restrict addresses[]

 But is OK with:

    const char **restrict addresses

I'm pretty sure you want const char * restrict * addresses instead.

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2010/09/17 07:07:55

Modified files:
www/surf   : Makefile distinfo 

Log message:
Update surf to 0.4.1.

ok landry@

Update surf to 0.4.1

[Matthew Dempsky]

The diff below updates surf to 0.4.1, notably fixing GMail support for
me.

ok?

Index: Makefile
===
RCS file: /cvs/ports/www/surf/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile7 Jun 2010 07:24:00 -   1.4
+++ Makefile17 Sep 2010 11:54:54 -
@@ -2,7 +2,7 @@
 
 COMMENT =  simple webbrowser based on webkit/gtk+
 
-DISTNAME = surf-0.4
+DISTNAME = surf-0.4.1
 CATEGORIES =   www
 HOMEPAGE = http://surf.suckless.org/
 
Index: distinfo
===
RCS file: /cvs/ports/www/surf/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo7 Jun 2010 07:24:00 -   1.2
+++ distinfo17 Sep 2010 11:54:54 -
@@ -1,5 +1,5 @@
-MD5 (surf-0.4.tar.gz) = Gn8b8hny2guXwggCvPSYxw==
-RMD160 (surf-0.4.tar.gz) = qG2unidvZ1gEzKqm6dOEc5Ygts8=
-SHA1 (surf-0.4.tar.gz) = nLy88g9v05ZBjP91dED1lwoCVMo=
-SHA256 (surf-0.4.tar.gz) = 9F+L6YpHiUpdk2Vu5KICZqH5ybqd+9O+0l339qxHmcU=
-SIZE (surf-0.4.tar.gz) = 10089
+MD5 (surf-0.4.1.tar.gz) = KKx6bRk9JYRKprHbd/y6+g==
+RMD160 (surf-0.4.1.tar.gz) = kV4y8aW4OCgMV8pEFl0kZUvBFpA=
+SHA1 (surf-0.4.1.tar.gz) = L2qhnEirZh3K/Tj/c9RQydxGpZk=
+SHA256 (surf-0.4.1.tar.gz) = k3Cbo+hLryEYZ26WpbLl1BdvKMNceC//2AplwKW+pUY=
+SIZE (surf-0.4.1.tar.gz) = 10102

Re: [NEW] emacs 23.2

[Matthew Dempsky]

On Tue, Jul 27, 2010 at 2:45 AM, Manuel Giraud
manuel.gir...@univ-nantes.fr wrote:
 New version with correct WANTLIB and LIB_DEPENDS usage and a wishful
 thinking remove of the propolice workaround for powerpc.

Any update on this port?  I just built it on amd64, and it seems okay so far.

CVS: cvs.openbsd.org: ports

[Matthew Dempsky]

CVSROOT:/cvs
Module name:ports
Changes by: matt...@cvs.openbsd.org 2010/06/28 00:03:23

Modified files:
geo/openbsd-developers: Makefile 
geo/openbsd-developers/files: OpenBSD 

Log message:
Add my coordinates to geo/openbsd-developers.

ok landry@

Re: tint patch cleanups and wantlib fix

[Matthew Dempsky]

On Sun, May 9, 2010 at 9:28 AM, Edd Barrett vex...@gmail.com wrote:
  +#if defined(__OpenBSD__)
 -+      if (close(apm_fd) == -1)
 ++      if ((apm_fd != NULL)  (close(apm_fd) == -1))
  +              warn(cannot close /dev/apm);
  +#endif

It seems wrong to use NULL (a pointer value) as a file descriptor
value.  Can I suggest changing apm_fd's initialization from NULL to
-1, and similarly comparing against -1 instead of NULL here?

Re: mplayer

[Matthew Dempsky]

Would it be difficult to make it instead just print a warning about
userldt instead of erroring out?

Re: chromium comes to town

[Matthew Dempsky]

On Fri, Sep 5, 2008 at 8:54 PM, Rajneesh N. Shetty
[EMAIL PROTECTED] wrote:
 I coud'nt install Google's Chrome browser on my machine

Chrome only works on Windows.  Source code builds some framework stuff
on some other platforms, but nothing useful yet.

Give it a few months.

Re: Ports with possible 64-bit problems

[Matthew Dempsky]

On Mon, Jun 30, 2008 at 8:31 AM, Christian Weisgerber
[EMAIL PROTECTED] wrote:
 A grep over a recent set of amd64 bulk build logs shows these ports
 generating warnings that indicate possible 64-bit problems:

I'm looking at the Erlang port's build logs, and I see some warning:
cast from pointer to integer of different size messages.  Are there
any other messages to look out for?

Re: Modifying software written to a Standards document - was Re: DRM in xpdf

[Matthew Dempsky]

On Sun, Apr 27, 2008 at 12:53 AM, Predrag Punosevac
[EMAIL PROTECTED] wrote:
  I hate to disagree with somebody who sounds like my fellow countryman but
 DRM has NO use. I also teach at the University and I some time prepare
 slides too which use over layers and even more fancy stuff. Any decant
 software for preparing slides (in my case I use Powerdot Latex class of
 presentation) has so called note mode. In note mode you can choose to put up
 to 4 slides on the single sheet of the paper for purposes of printing hand
 outs for your students. You may also include additional rule lines for
 taking the notes. Note mode will ignore over layers (which are in essence
 separate slides) or any other additional stuff.

Zvezdan did say I also always posted a 4 up version of the slides
with *no* protection -- 4 slides per page with animations turned into
a final picture after the last step.

His use case for PDF's DRM was simply to protect students from
accidentally printing the animated slides instead of the still 4-up
slides.

Re: Modifying software written to a Standards document - was Re: DRM in xpdf

[Matthew Dempsky]

On Sat, Apr 26, 2008 at 6:29 PM, Zvezdan Petkovic [EMAIL PROTECTED] wrote:
  Replacing a protection with a message of intent of the author is probably a
 good idea.

Maybe for the xpdf maintainer (e.g., a --soft-drm configure option),
but that definitely seems way too intrusive a patch for maintainence
within the ports tree.

In lieu of that, a simpler solution would seem to be to title your
links to the slides as Printer-friendly sides (no animation) and
Screen-friendly slides (animation).  Hopefully university students
can read, and if not, they should learn quickly after paying for a 200
page printout. :-)

Re: New port: databases/tinycdb

[Matthew Dempsky]

On Sun, Apr 20, 2008 at 6:52 PM,  [EMAIL PROTECTED] wrote:
  I didn't see anything conclusive in that thread... just an allusion
  toward a tinydns licensing problem, specifically the file format.

djbdns (including tinydns) has been placed into the public domain; see
http://cr.yp.to/distributors.html.

  I also note that databases/py-cdb, which is already in the ports tree,
  is a slightly modified version of DJB's original cdb-0.75 code plus
  python glue, and relicensed as GPL.

py-cdb includes cdb.c, cdb.h, cdb_make.c, cdb_make.h, and cdb_hash.c
from cdb-0.75, which are all placed into the publicdomain.  py-cdb
does not include any copyrighted code from cdb-0.75.

Re: Emacs 22 port?

[Matthew Dempsky]

On Mon, Apr 14, 2008 at 12:42 PM, Eric Faurot [EMAIL PROTECTED] wrote:
  This is a work-in-progress port of emacs 22.2 based on a post
  by Fulvio Ciriaco. Contributions are most welcome.

Cool.

patch below adds a gtk flavor for using the gtk toolkit instead of the
default one.  I'm not sure about the LIB_DEPENDS part though; I just
put the major versions from the system I tested on and confirmed that
it works and passed make lib-depends-check.

Also, I fixed the PLIST-{main,el} files to catch a few new .el.gz
files that snuck into PLIST-main.

(Sorry if the Makefile diff wraps; I'm not sure how to fit 80 columns
with library-specs. :-()


diff -rpu emacs22/Makefile /usr/ports/editors/emacs22/Makefile
--- emacs22/MakefileFri Apr 11 14:11:35 2008
+++ /usr/ports/editors/emacs22/Makefile Mon Apr 14 14:21:48 2008
@@ -26,7 +26,7 @@ MULTI_PACKAGES=   -main -el

 USE_GMAKE= Yes

-FLAVORS=   no_x11
+FLAVORS=   no_x11 gtk
 FLAVOR?=

 GCCARCH=   ${MACHINE_ARCH}-unknown-openbsd${OPSYS_VER}
@@ -51,6 +51,24 @@ SUBST_VARS=  GCCARCH VERSION
 WANTLIB-main=  c m ncurses ossaudio
 .if ${FLAVOR:L:Mno_x11}
 CONFIGURE_ARGS+=   --with-x=no
+.elif ${FLAVOR:L:Mgtk}
+USE_X11=Yes
+CONFIGURE_ARGS+=   --with-x-toolkit=gtk
+LIB_DEPENDS-main=  
gtk-x11-2.0.=1200,gdk_pixbuf-2.0.=1200,gdk-x11-2.0.=1200::x11/gtk+2
\
+   atk-1.0.=2009::devel/atk \
+   cairo.=7::graphics/cairo \
+   
glib-2.0.=1400,gmodule-2.0.=1400,gobject-2.0.=1400::devel/glib2 \
+   glitz.=2::graphics/glitz \
+   iconv.=4::converters/libiconv \
+   intl.=4::devel/gettext \
+   jpeg.=62::graphics/jpeg \
+   
pango-1.0.=1400,pangocairo-1.0.=1400,pangoft2-1.0.=1400::devel/pango \
+   png.=6::graphics/png \
+   tiff.=38::graphics/tiff \
+   ungif.=5::graphics/libungif
+WANTLIB-main+= ICE SM X11 Xau Xcomposite Xcursor Xdamage Xdmcp Xext
+WANTLIB-main+= Xfixes Xft Xi Xinerama Xpm Xrandr Xrender expat 
fontconfig
+WANTLIB-main+= freetype pthread z
 .else
 USE_X11=Yes
 LIB_DEPENDS-main=  ungif.=5::graphics/libungif \
diff -rpu emacs22/pkg/PLIST-el /usr/ports/editors/emacs22/pkg/PLIST-el
--- emacs22/pkg/PLIST-elFri Apr 11 14:36:21 2008
+++ /usr/ports/editors/emacs22/pkg/PLIST-el Mon Apr 14 15:31:50 2008
@@ -690,6 +690,7 @@ share/emacs/${VERSION}/lisp/net/rcirc.el.gz
 share/emacs/${VERSION}/lisp/net/rcompile.el.gz
 share/emacs/${VERSION}/lisp/net/rlogin.el.gz
 share/emacs/${VERSION}/lisp/net/snmp-mode.el.gz
+share/emacs/${VERSION}/lisp/net/socks.el.gz
 share/emacs/${VERSION}/lisp/net/telnet.el.gz
 share/emacs/${VERSION}/lisp/net/tls.el.gz
 share/emacs/${VERSION}/lisp/net/tramp-ftp.el.gz
@@ -851,6 +852,8 @@ share/emacs/${VERSION}/lisp/progmodes/sh-script.el.gz
 share/emacs/${VERSION}/lisp/progmodes/simula.el.gz
 share/emacs/${VERSION}/lisp/progmodes/sql.el.gz
 share/emacs/${VERSION}/lisp/progmodes/tcl.el.gz
+share/emacs/${VERSION}/lisp/progmodes/vera-mode.el.gz
+share/emacs/${VERSION}/lisp/progmodes/verilog-mode.el.gz
 share/emacs/${VERSION}/lisp/progmodes/vhdl-mode.el.gz
 share/emacs/${VERSION}/lisp/progmodes/which-func.el.gz
 share/emacs/${VERSION}/lisp/progmodes/xscheme.el.gz
@@ -910,8 +913,10 @@ share/emacs/${VERSION}/lisp/term/xterm.el.gz
 share/emacs/${VERSION}/lisp/terminal.el.gz
 share/emacs/${VERSION}/lisp/textmodes/artist.el.gz
 share/emacs/${VERSION}/lisp/textmodes/bib-mode.el.gz
+share/emacs/${VERSION}/lisp/textmodes/bibtex-style.el.gz
 share/emacs/${VERSION}/lisp/textmodes/bibtex.el.gz
 share/emacs/${VERSION}/lisp/textmodes/conf-mode.el.gz
+share/emacs/${VERSION}/lisp/textmodes/css-mode.el.gz
 share/emacs/${VERSION}/lisp/textmodes/dns-mode.el.gz
 share/emacs/${VERSION}/lisp/textmodes/enriched.el.gz
 share/emacs/${VERSION}/lisp/textmodes/fill.el.gz
@@ -994,9 +999,13 @@ share/emacs/${VERSION}/lisp/url/url.el.gz
 share/emacs/${VERSION}/lisp/url/vc-dav.el.gz
 share/emacs/${VERSION}/lisp/userlock.el.gz
 share/emacs/${VERSION}/lisp/vc-arch.el.gz
+share/emacs/${VERSION}/lisp/vc-bzr.el.gz
 share/emacs/${VERSION}/lisp/vc-cvs.el.gz
+share/emacs/${VERSION}/lisp/vc-git.el.gz
+share/emacs/${VERSION}/lisp/vc-hg.el.gz
 share/emacs/${VERSION}/lisp/vc-hooks.el.gz
 share/emacs/${VERSION}/lisp/vc-mcvs.el.gz
+share/emacs/${VERSION}/lisp/vc-mtn.el.gz
 share/emacs/${VERSION}/lisp/vc-rcs.el.gz
 share/emacs/${VERSION}/lisp/vc-sccs.el.gz
 share/emacs/${VERSION}/lisp/vc-svn.el.gz
diff -rpu emacs22/pkg/PLIST-main /usr/ports/editors/emacs22/pkg/PLIST-main
--- emacs22/pkg/PLIST-main  Mon Apr 14 11:50:27 2008
+++ /usr/ports/editors/emacs22/pkg/PLIST-main   Mon Apr 14 15:31:52 2008
@@ -1298,7 +1298,6 @@ share/emacs/${VERSION}/lisp/net/rcirc.elc
 share/emacs/${VERSION}/lisp/net/rcompile.elc
 share/emacs/${VERSION}/lisp/net/rlogin.elc
 

Re: Emacs 22 port?

[Matthew Dempsky]

On Mon, Apr 14, 2008 at 3:38 PM, Matthew Dempsky [EMAIL PROTECTED] wrote:
  patch below adds a gtk flavor for using the gtk toolkit instead of the
  default one.  I'm not sure about the LIB_DEPENDS part though; I just
  put the major versions from the system I tested on and confirmed that
  it works and passed make lib-depends-check.

Oh, additionally moving the CONFIGURE_ARGS+=
--without-toolkit-scroll-bars line into only the default flavor's
section lets the gtk flavor use the gtk scroll bars (duh).

(No diff; I figure the change is easy enough to reproduce.)

Re: Trascend Solid State Disk 1Gbyte

[Matthew Dempsky]

On Sat, Apr 12, 2008 at 11:58 PM, Marco [EMAIL PROTECTED] wrote:
  Do you have notice, howto work fine the device in Subject?

http://www.openbsd.org/faq/faq14.html#flashmem

Emacs 22 port?

[Matthew Dempsky]

Is anyone working on an Emacs 22 port?  I thought I'd check before
making a redundant effort.

Re: Update: Erlang/OTP R12B-2

[Matthew Dempsky]

This builds, installs, and runs fine on amd64 for me.

On Wed, Apr 9, 2008 at 12:54 PM, Jon Olsson [EMAIL PROTECTED] wrote:
 Attached is a patch which updates Erlang to the latest release R12B-2, for 
 more
  info: http://www.erlang.org/download/otp_src_R12B-2.readme

   Makefile |  120 
 +++
   distinfo |   30 +++
   patches/patch-lib_stdlib_src_dets_v9_erl |   13 ---
   pkg/PLIST|   57 +++---
   4 files changed, 122 insertions(+), 98 deletions(-)

  --
  Jon

Re: Privoxy stable release is 3.0.8

[Matthew Dempsky]

On Wed, Apr 2, 2008 at 2:48 PM, Mike Erdely [EMAIL PROTECTED] wrote:
  -@@ -344,7 +344,7 @@ char *strdup( const char *s )
  -
  -if (result != NULL)
  -{
  --  strcpy( result, s );
  -+  strlcpy( result, s, sizeof(result) );
  -}
  -
  -return( result );

It seems worth pointing out that this patch is an example of
carelessly replacing strcpy with strlcpy.  result here is a pointer,
not a fixed size array, so sizeof(result) just returns 4 or 8 instead
of the buffer size.  (Of course, OpenBSD provides strdup in libc, so
this code isn't used, patched or not.)

Re: Privoxy stable release is 3.0.8

[Matthew Dempsky]

On Wed, Apr 2, 2008 at 4:10 PM, Mike Erdely [EMAIL PROTECTED] wrote:
  For what it's worth, that section of code was wrapped in:
  #ifdef __MINGW32__
  char *strdup...
  #endif /* def __MINGW32__ */

Right, that's why I said:

   (Of course, OpenBSD provides strdup in libc, so
   this code isn't used, patched or not.)

I noticed the result != NULL check in the context before the strlcpy
change while quickly reviewing the diff, and thought it was
suspicious.  After investigating further to confirm that it's a bug
(were someone to try to use it on mingw32 after porting strlcpy...), I
thought I'd just point it out as an example of how carelessly
replacing strcpy with strlcpy can break ports.