[CHANGE] devel/jdk/1.6 use jamvm bootstrap
The following diff changes the default bootstrap depend from jdk/1.5 to
lang/jamvm + Eclipse compiler (ecj).
Tested on i386 and amd64: builds ok, builds native_bootstrap ok and jdk/1.7
ok.
After this goes in we can remove jdk/1.5 which is EOL since 2009.
okay?
Index: Makefile
===
RCS file: /cvs/ports/devel/jdk/1.6/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile9 Apr 2011 00:38:09 - 1.22
+++ Makefile1 Oct 2011 18:00:21 -
@@ -8,9 +8,9 @@ COMMENT-jre=Java2(TM) Standard Edition
V= 1.6.0.03
PKGNAME= jdk-${V}
PKGNAME-main= jdk-${V}
-REVISION-main =13
+REVISION-main =14
PKGNAME-jre= jre-${V}
-REVISION-jre = 13
+REVISION-jre = 14
CATEGORIES=devel/jdk java
@@ -29,6 +29,7 @@ DISTFILES=${JRLSRC} \
${JRLBIN} \
${JRLMOZ} \
${PATCHSET}
+DIST_SUBDIR= jdk
MASTER_SITES= http://download.java.net/jdk6/6u3/promoted/b05/
@@ -102,8 +103,22 @@ ERRORS += Fatal: This flavor requires a
BUILD_DEPENDS+=jdk-=1.6,1.7:devel/jdk/1.6
MAKE_ENV+= ALT_BOOTDIR=${LOCALBASE}/${JDKHOME}
.else
-BUILD_DEPENDS+=jdk-=1.5,1.6:devel/jdk/1.5
-MAKE_ENV+= ALT_BOOTDIR=${LOCALBASE}/jdk-1.5.0
+DISTFILES+=bsd-jdk16-gensrc.tar.gz \
+ xalan-j_2_7_0-bin.tar.gz \
+ ecj-3.7.1.jar
+FETCH_MANUALLY+= Get the file:
+FETCH_MANUALLY+= bsd-jdk16-gensrc.tar.gz
+FETCH_MANUALLY+= from
http:://www.intricatesoftware.com/distfiles/bsd-jdk16-gensrc.tar.gz
+FETCH_MANUALLY+= Get the Apache Xalan Java file:
+FETCH_MANUALLY+= xalan-j_2_7_0-bin.tar.gz
+FETCH_MANUALLY+= from http://archive.apache.org/dist/xml/xalan-j/;
+FETCH_MANUALLY+= Get the Eclipse Java Compiler file:
+FETCH_MANUALLY+= ecj-3.7.1.jar
+FETCH_MANUALLY+= from
http://download.eclipse.org/eclipse/downloads/drops/R-3.7.1-201109091335/ecj-3.7.1.jar;
+BUILD_DEPENDS+=lang/jamvm=1.5.4
+MAKE_ENV+= ALT_BOOTDIR=${WRKDIST} \
+ ALT_BOOTSTRAP=yes \
+ ECJ_JAR=${FULLDISTDIR}/ecj-3.7.1.jar
.endif
.if !${FLAVOR:L:Mno_web}
@@ -164,6 +179,16 @@ post-extract:
pre-patch:
@cd ${WRKDIR} \
${PATCH} -p0 -z .orig.bsd --quiet ${WRKDIR}/jdk16.patches
+
+.if !${FLAVOR:L:Mnative_bootstrap}
+post-patch:
+ @cd ${WRKDIR}/bin \
+ ${CHMOD} +x bootscript
+.for prog in java javac javah jar
+ @cd ${WRKDIR}/bin \
+ ln -s bootscript ${prog}
+.endfor
+.endif
post-build:
@rm -rf ${JDKIMAGEDIR}/man/ja \
Index: distinfo
===
RCS file: /cvs/ports/devel/jdk/1.6/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo17 Mar 2008 03:28:26 - 1.2
+++ distinfo1 Oct 2011 18:00:21 -
@@ -1,20 +1,35 @@
-MD5 (bsd-jdk16-patches-4.tar.bz2) = YyBltgOkKKYDg9t/DLBM3w==
-MD5 (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = i28bjY3sBRwYOFU5ERFB7A==
-MD5 (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) =
bcr3rxYhFhet/11nKot59A==
-MD5 (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = gzkDefufMZPpOp1e7Vsx2Q==
-RMD160 (bsd-jdk16-patches-4.tar.bz2) = uejP2jkrnE/N6uIs1eiqI6jk2GA=
-RMD160 (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) =
fxvCv48G8stpoPfAsC32v6s2cn0=
-RMD160 (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) =
6KePLdZ5CJHIE0i1UpkmkryDaXE=
-RMD160 (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) =
eSRJxzWuLx5FTpC900Bbski15AQ=
-SHA1 (bsd-jdk16-patches-4.tar.bz2) = iUIf2iB8nGMEftEynEEf3HclN8Q=
-SHA1 (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = xhtWgGJxWxRwvW/B5V+oG+c0iMU=
-SHA1 (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) =
Sb8hpRWgp7n0W373J3/J09dvkwk=
-SHA1 (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = EqmNoH2CNAWabtr/pgWe/yY35GE=
-SHA256 (bsd-jdk16-patches-4.tar.bz2) =
XcdTvuFWdvNbBjD4dP3QnhUoIUTdSiXPEiLnwogB+MY=
-SHA256 (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) =
C7zELB/3uA2OPqXMB7mmB3j+x6gmc7QrPlS7mnqy6b4=
-SHA256 (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) =
M23boc1LxqlLzRGFUMXHo6gI5Lvjm7ITQkupiD8gCcQ=
-SHA256 (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) =
0ci9lFhM1SgY46HcPwOxELOSQ9VRJQSgnAbFHAadK/k=
-SIZE (bsd-jdk16-patches-4.tar.bz2) = 960930
-SIZE (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = 2116124
-SIZE (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) = 8608204
-SIZE (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = 116791442
+MD5 (jdk/bsd-jdk16-gensrc.tar.gz) = YqixvW5QHuntj2X5muIYEw==
+MD5 (jdk/bsd-jdk16-patches-4.tar.bz2) = YyBltgOkKKYDg9t/DLBM3w==
+MD5 (jdk/ecj-3.7.1.jar) = XdYKNUidOpzUsUklWSoBZQ==
+MD5 (jdk/jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) =
Re: [CHANGE] devel/jdk/1.6 use jamvm bootstrap
On Saturday 01 October 2011 14:08:18 Kurt Miller wrote:
The following diff changes the default bootstrap depend from jdk/1.5 to
lang/jamvm + Eclipse compiler (ecj).
Tested on i386 and amd64: builds ok, builds native_bootstrap ok and jdk/1.7
ok.
After this goes in we can remove jdk/1.5 which is EOL since 2009.
okay?
The in-lined patch got line wrapped by my mailer. Attached is the same diff.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/devel/jdk/1.6/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile 9 Apr 2011 00:38:09 - 1.22
+++ Makefile 1 Oct 2011 18:00:21 -
@@ -8,9 +8,9 @@ COMMENT-jre= Java2(TM) Standard Edition
V= 1.6.0.03
PKGNAME= jdk-${V}
PKGNAME-main= jdk-${V}
-REVISION-main = 13
+REVISION-main = 14
PKGNAME-jre= jre-${V}
-REVISION-jre = 13
+REVISION-jre = 14
CATEGORIES= devel/jdk java
@@ -29,6 +29,7 @@ DISTFILES= ${JRLSRC} \
${JRLBIN} \
${JRLMOZ} \
${PATCHSET}
+DIST_SUBDIR= jdk
MASTER_SITES= http://download.java.net/jdk6/6u3/promoted/b05/
@@ -102,8 +103,22 @@ ERRORS += Fatal: This flavor requires a
BUILD_DEPENDS+= jdk-=1.6,1.7:devel/jdk/1.6
MAKE_ENV+= ALT_BOOTDIR=${LOCALBASE}/${JDKHOME}
.else
-BUILD_DEPENDS+= jdk-=1.5,1.6:devel/jdk/1.5
-MAKE_ENV+= ALT_BOOTDIR=${LOCALBASE}/jdk-1.5.0
+DISTFILES+= bsd-jdk16-gensrc.tar.gz \
+ xalan-j_2_7_0-bin.tar.gz \
+ ecj-3.7.1.jar
+FETCH_MANUALLY+= Get the file:
+FETCH_MANUALLY+= bsd-jdk16-gensrc.tar.gz
+FETCH_MANUALLY+= from http:://www.intricatesoftware.com/distfiles/bsd-jdk16-gensrc.tar.gz
+FETCH_MANUALLY+= Get the Apache Xalan Java file:
+FETCH_MANUALLY+= xalan-j_2_7_0-bin.tar.gz
+FETCH_MANUALLY+= from http://archive.apache.org/dist/xml/xalan-j/;
+FETCH_MANUALLY+= Get the Eclipse Java Compiler file:
+FETCH_MANUALLY+= ecj-3.7.1.jar
+FETCH_MANUALLY+= from http://download.eclipse.org/eclipse/downloads/drops/R-3.7.1-201109091335/ecj-3.7.1.jar;
+BUILD_DEPENDS+= lang/jamvm=1.5.4
+MAKE_ENV+= ALT_BOOTDIR=${WRKDIST} \
+ ALT_BOOTSTRAP=yes \
+ ECJ_JAR=${FULLDISTDIR}/ecj-3.7.1.jar
.endif
.if !${FLAVOR:L:Mno_web}
@@ -164,6 +179,16 @@ post-extract:
pre-patch:
@cd ${WRKDIR} \
${PATCH} -p0 -z .orig.bsd --quiet ${WRKDIR}/jdk16.patches
+
+.if !${FLAVOR:L:Mnative_bootstrap}
+post-patch:
+ @cd ${WRKDIR}/bin \
+ ${CHMOD} +x bootscript
+.for prog in java javac javah jar
+ @cd ${WRKDIR}/bin \
+ ln -s bootscript ${prog}
+.endfor
+.endif
post-build:
@rm -rf ${JDKIMAGEDIR}/man/ja \
Index: distinfo
===
RCS file: /cvs/ports/devel/jdk/1.6/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo 17 Mar 2008 03:28:26 - 1.2
+++ distinfo 1 Oct 2011 18:00:21 -
@@ -1,20 +1,35 @@
-MD5 (bsd-jdk16-patches-4.tar.bz2) = YyBltgOkKKYDg9t/DLBM3w==
-MD5 (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = i28bjY3sBRwYOFU5ERFB7A==
-MD5 (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) = bcr3rxYhFhet/11nKot59A==
-MD5 (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = gzkDefufMZPpOp1e7Vsx2Q==
-RMD160 (bsd-jdk16-patches-4.tar.bz2) = uejP2jkrnE/N6uIs1eiqI6jk2GA=
-RMD160 (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = fxvCv48G8stpoPfAsC32v6s2cn0=
-RMD160 (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) = 6KePLdZ5CJHIE0i1UpkmkryDaXE=
-RMD160 (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = eSRJxzWuLx5FTpC900Bbski15AQ=
-SHA1 (bsd-jdk16-patches-4.tar.bz2) = iUIf2iB8nGMEftEynEEf3HclN8Q=
-SHA1 (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = xhtWgGJxWxRwvW/B5V+oG+c0iMU=
-SHA1 (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) = Sb8hpRWgp7n0W373J3/J09dvkwk=
-SHA1 (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = EqmNoH2CNAWabtr/pgWe/yY35GE=
-SHA256 (bsd-jdk16-patches-4.tar.bz2) = XcdTvuFWdvNbBjD4dP3QnhUoIUTdSiXPEiLnwogB+MY=
-SHA256 (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = C7zELB/3uA2OPqXMB7mmB3j+x6gmc7QrPlS7mnqy6b4=
-SHA256 (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) = M23boc1LxqlLzRGFUMXHo6gI5Lvjm7ITQkupiD8gCcQ=
-SHA256 (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = 0ci9lFhM1SgY46HcPwOxELOSQ9VRJQSgnAbFHAadK/k=
-SIZE (bsd-jdk16-patches-4.tar.bz2) = 960930
-SIZE (jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = 2116124
-SIZE (jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) = 8608204
-SIZE (jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = 116791442
+MD5 (jdk/bsd-jdk16-gensrc.tar.gz) = YqixvW5QHuntj2X5muIYEw==
+MD5 (jdk/bsd-jdk16-patches-4.tar.bz2) = YyBltgOkKKYDg9t/DLBM3w==
+MD5 (jdk/ecj-3.7.1.jar) = XdYKNUidOpzUsUklWSoBZQ==
+MD5 (jdk/jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar) = i28bjY3sBRwYOFU5ERFB7A==
+MD5 (jdk/jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar) = bcr3rxYhFhet/11nKot59A==
+MD5 (jdk/jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar) = gzkDefufMZPpOp1e7Vsx2Q==
+MD5 (jdk/xalan-j_2_7_0-bin.tar.gz) = 1SbQhIyIYHzk46Ck7bddUA==
+RMD160 (jdk/bsd-jdk16-gensrc.tar.gz) = Jzug24cPOLB/Sydx+OT4icgpG5c=
+RMD160 (jdk/bsd-jdk16-patches-4.tar.bz2
Re: [CHANGE] devel/jdk/1.6 use jamvm bootstrap
On Sunday 02 October 2011 09:51:25 Amit Kulkarni wrote: The following diff changes the default bootstrap depend from jdk/1.5 to lang/jamvm + Eclipse compiler (ecj). Tested on i386 and amd64: builds ok, builds native_bootstrap ok and jdk/1.7 ok. After this goes in we can remove jdk/1.5 which is EOL since 2009. lang/kaffe can also be removed, right? its old, and somewhat unmaintained... Yes, that is correct. -Kurt
Re: [CHANGE] devel/jdk/1.6 use jamvm bootstrap
Hi Amit, On Thursday 06 October 2011 02:20:42 pm Amit Kulkarni wrote: The following diff changes the default bootstrap depend from jdk/1.5 to lang/jamvm + Eclipse compiler (ecj). Tested on i386 and amd64: builds ok, builds native_bootstrap ok and jdk/1.7 ok. After this goes in we can remove jdk/1.5 which is EOL since 2009. okay? The in-lined patch got line wrapped by my mailer. Attached is the same diff. -Kurt Smooth upgrade... I had to move stuff from distfiles to distfiles/jdk. No problems found on amd64. couple more crusty ports removed!!! Thanks. Kurt, The plan is to keep 1.6 u3 around to bootstrap 1.7 and future 1.8, and concentrate more on upcoming versions only, right? i.e use 1.7 and discourage 1.6 because of securtiy concerns? No plans here. Just plans to have plans. Idealy someone (or me eventually) switches 1.6 to OpenJDK 1.6 so we get 1.6 packages but we loose the Sun plugin. I doubt that will happen this release though. icedtea-web will be the plugin we rely upon in the future. Regards, -Kurt
[REMOVE] devel/jdk/1.5 lang/kaffe
Now that we can boostrap 1.6 with jamvm it is time to remove EOL/unmaintained
by upstream java ports; devel/jdk/1.5 and lang/kaffe.
All 1.3+ 1.4+ and 1.5+ ports require a bump due to change in RUN_DEPENDS. A
close look at java.port.mk would be appreciated. Thanks.
Index: databases/db/v4/Makefile
===
RCS file: /cvs/ports/databases/db/v4/Makefile,v
retrieving revision 1.53
diff -u -p -r1.53 Makefile
--- databases/db/v4/Makefile16 Sep 2011 08:48:02 - 1.53
+++ databases/db/v4/Makefile7 Oct 2011 02:32:32 -
@@ -14,7 +14,7 @@ PKGNAME-tcl= db-tcl-${VERSION}
EPOCH-main=0
EPOCH-java=0
EPOCH-tcl= 0
-REVISION-java =0
+REVISION-java =1
REVISION-tcl = 0
DBLIBDIR= lib/db4
SHARED_LIBS += db 5.0 # .0.0
Index: databases/jxplorer/Makefile
===
RCS file: /cvs/ports/databases/jxplorer/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- databases/jxplorer/Makefile 16 Sep 2011 08:48:02 - 1.10
+++ databases/jxplorer/Makefile 7 Oct 2011 02:32:32 -
@@ -5,7 +5,7 @@ COMMENT=standards compliant LDAP browse
V= 3.2
DISTNAME= JXv${V}deploy
PKGNAME= jxplorer-${V}
-REVISION= 6
+REVISION= 7
EXTRACT_SUFX= .zip
CATEGORIES=databases net
Index: databases/postgresql-jdbc/Makefile
===
RCS file: /cvs/ports/databases/postgresql-jdbc/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- databases/postgresql-jdbc/Makefile 16 Sep 2011 08:48:03 - 1.15
+++ databases/postgresql-jdbc/Makefile 7 Oct 2011 02:32:32 -
@@ -9,7 +9,7 @@ PKGNAME-main= postgresql-jdbc-${V:S/-/.
PKGNAME-docs= postgresql-jdbc-docs-${V:S/-/./}
PKG_ARCH-docs= *
CATEGORIES=databases
-REVISION-main =0
+REVISION-main =1
MULTI_PACKAGES=-main -docs
Index: devel/apache-ant/Makefile
===
RCS file: /cvs/ports/devel/apache-ant/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- devel/apache-ant/Makefile 16 Sep 2011 09:24:48 - 1.26
+++ devel/apache-ant/Makefile 7 Oct 2011 02:32:33 -
@@ -3,7 +3,7 @@
COMMENT=build tool for java applications
DISTNAME= apache-ant-1.8.2
-REVISION= 1
+REVISION= 2
CATEGORIES=devel
HOMEPAGE= http://ant.apache.org/
Index: devel/eclipse/sdk/Makefile
===
RCS file: /cvs/ports/devel/eclipse/sdk/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- devel/eclipse/sdk/Makefile 16 Sep 2011 09:24:49 - 1.66
+++ devel/eclipse/sdk/Makefile 7 Oct 2011 02:32:34 -
@@ -12,7 +12,7 @@ ECLIPSE_VER= 3.2.2
DISTNAME= eclipse-sourceBuild-srcIncluded-${ECLIPSE_VER}
PKGNAME= eclipse-sdk-${ECLIPSE_VER}
PKGNAME-main= eclipse-sdk-${ECLIPSE_VER}
-REVISION-main= 18
+REVISION-main= 19
PKGNAME-swt= swt-${ECLIPSE_VER}
REVISION-swt= 4
PKGNAME-gnome= swt-gnome-${ECLIPSE_VER}
Index: devel/ivy/Makefile
===
RCS file: /cvs/ports/devel/ivy/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- devel/ivy/Makefile 16 Sep 2011 09:24:51 - 1.18
+++ devel/ivy/Makefile 7 Oct 2011 02:32:35 -
@@ -5,7 +5,7 @@ COMMENT=dependency manager for Java
VERSION= 1.4.1
DISTNAME= ivy-${VERSION}-bin
PKGNAME= ivy-${VERSION}
-REVISION = 10
+REVISION = 11
CATEGORIES=devel
WRKDIST= ${WRKDIR}/ivy-${VERSION}
Index: devel/jakarta-servletapi/Makefile
===
RCS file: /cvs/ports/devel/jakarta-servletapi/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- devel/jakarta-servletapi/Makefile 16 Sep 2011 09:24:51 - 1.22
+++ devel/jakarta-servletapi/Makefile 7 Oct 2011 02:32:35 -
@@ -4,7 +4,7 @@ COMMENT=implementation of the JSP and J
V= 3.2.4
DISTNAME= jakarta-servletapi-${V}
-REVISION= 12
+REVISION= 13
CATEGORIES=www devel
MASTER_SITES=
http://archive.apache.org/dist/jakarta/tomcat-3/archive/v${V}/bin/
EXTRACT_SUFX= .zip
Index: devel/jdk/Makefile
===
RCS file: /cvs/ports/devel/jdk/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- devel/jdk/Makefile 1 Feb 2010 17:00:13 - 1.23
+++ devel/jdk/Makefile 7 Oct 2011 02:32:35 -
@@ -1,7 +1,6 @@
# $OpenBSD: Makefile,v 1.23 2010/02/01 17:00:13 espie Exp $
SUBDIR =
-SUBDIR +=
Re: HEADS-UP porters (rthreads)
On Sunday 19 February 2012 4:33:35 pm Amit Kulkarni wrote: As you probably noticed, rthreads (kernel threads) are now enabled by default. However there is no guarantee that this will last if we can't fix everything that needs fixing in time. When working with ports and when you remove/add a thread related patch (like removing an old userland threads hack) it is _mandatory_ that you get a review and OK from sthen@ naddy@ espie@ and/or myself. The reason is that we are keeping track of these changes in case we need to revert to using userland threads. For the porters that already have committed such diffs to the ports tree, please get in touch with us so we can add it to our tracking list. Any question, ask the people previously listed. Thank you! PS : test! test! test! we _do_ want rthreads to stay :) There is some problem building sun's jdk 1.6 (devel/jdk/1.6) and lang/mono. Note this is with stock current (src,xenocara,ports) as of friday feb 17... CC'ing kurt@ and robert@. Can somebody look in there if they have time? Thanks for the report. rthreads doesn't have functional pthread_suspend_np() support yet, so ports using it will not work. That covers most garbage collection based applications like the jdk and mono. When pthread_suspend_np() is functional we can try these applications again. -Kurt
Re: HEADS-UP porters (rthreads)
On Monday 20 February 2012 3:09:08 pm Ted Unangst wrote: On Mon, Feb 20, 2012, Kurt Miller wrote: On Sunday 19 February 2012 4:33:35 pm Amit Kulkarni wrote: There is some problem building sun's jdk 1.6 (devel/jdk/1.6) and lang/mono. Note this is with stock current (src,xenocara,ports) as of friday feb 17... CC'ing kurt@ and robert@. Can somebody look in there if they have time? What is the problem? guenther@ mentioned to me that pthread_suspend_np() suspends the whole process not just the specified thread. Is that not the case? Thanks for the report. rthreads doesn't have functional pthread_suspend_np() support yet, so ports using it will not work. That covers most garbage collection based applications like the jdk and mono. When pthread_suspend_np() is functional we can try these applications again. If the problem is just that the main thread can't be suspended, that's been fixed for ages I think. We just need to fix the library. Index: rthread_sched.c === RCS file: /home/tedu/cvs/src/lib/librthread/rthread_sched.c,v retrieving revision 1.10 diff -u -p -r1.10 rthread_sched.c --- rthread_sched.c 19 Feb 2012 02:07:48 - 1.10 +++ rthread_sched.c 20 Feb 2012 20:06:15 - @@ -136,13 +136,8 @@ pthread_suspend_np(pthread_t thread) if (thread == pthread_self()) return (EDEADLK); - /* - * XXX Avoid a bug in current signal handling by refusing to - * suspend the main thread. - */ - if (thread != _initial_thread) - if (kill(thread-tid, SIGSTOP) == -1) - errn = errno; + if (kill(thread-tid, SIGSTOP) == -1) + errn = errno; return (errn); }
Re: www/jakarta-tomcat/v3
From: Kevin [EMAIL PROTECTED] On 7/1/05, Kurt Miller [EMAIL PROTECTED] wrote: Does anyone who uses this want to maintain it? I don't want to. It needs updating to the current version, kill INSTALL scripts, use @sample, etc. If no one steps up, I'd like to remove it before the next release. At the risk of asking the completely obvious, you _are_ just talking about V3, correct? FWIW, in the small circle of people I know using Tomcat, I know of no one still on 3, but I thought it safer to ask than not. :-) Yes, just v3. v4 v5 I maintain and will stay. -Kurt
Re: Java plugin doesn't work (current)
From: Hannah Schroeter [EMAIL PROTECTED] Hello! In current (updated on Monday), I installed jdk-1.4.2p2-with_ipv6 from ports, and after installation it suggests putting a link for a Mozilla/Firefox Java plugin to an appropriate place. Yet, it doesn't work (tried the interactive map stuff from www.map24.de, with mozilla-firefox-1.0.4). Nothing too important for me, just that the suggestion is worded as if it would work. Would I have better chances with the 1.5 JDK? From DESR: with_ipv6 Build the jdk/jre with ipv6 support. When the jdk/jre is built with this flavor, java will create only ipv6 sockets by default. Since ipv4 to ipv6 address mapping is disabled on OpenBSD, using ipv4 addresses will fail. Consequently, you may only use ipv6 addresses or you can start java with -Djava.net.preferIPv4Stack=true and can only use ipv4 addresses. Since you've compiled with ipv6, you can try adding -Djava.net.preferIPv4Stack=true to file:///usr/local/jdk-1.4.2/jre/ControlPanel.html - Advanced Tab - Java Runtime Parameters Also, I've had one person report that setting ulimits was not enough, they had to change login.conf for their login class instead (IIRC). -Kurt
Re: devel/eclipse/sdk and USE_SYSTRACE=Yes failure
From: Matthias Kilian [EMAIL PROTECTED] FYI: With USE_SYSTRACE=Yes in /etc/mk.conf a build of devel/eclipse/sdk on a seven days old -current system fails with the following error: Thanks for the report. My bad. _SYSTRACE_CMD is called already by bsd.port.mk on the do-build target and I called it again in my do-build. It is too late to fix this for release as building with USE_SYSTRACE is not the default. I will fix it post release. -Kurt
Re: devel/eclipse/sdk and USE_SYSTRACE=Yes failure
On Friday 26 August 2005 10:37 am, Kurt Miller wrote: From: Matthias Kilian [EMAIL PROTECTED] FYI: With USE_SYSTRACE=Yes in /etc/mk.conf a build of devel/eclipse/sdk on a seven days old -current system fails with the following error: Thanks for the report. My bad. _SYSTRACE_CMD is called already by bsd.port.mk on the do-build target and I called it again in my do-build. It is too late to fix this for release as building with USE_SYSTRACE is not the default. I will fix it post release. Change of heart. Fixing this doesn't change the package so it made it. -Kurt
Re: building jdk 1.5 ports on openbsd 3.7
On Thursday 22 September 2005 10:56 am, Allan P. Magmanlac wrote: Hello, I was trying to build jdk 1.5 on openbsd3.7 using ports collection, however I get various errors. So many of them. Sounds like your using a -current ports tree with 3.7. (jdk/1.5 was committed after 3.7) (i.e Stop in /usr/ports/devel/jdk/1.4/ (line 1817 of /usr/ports/infrastructure/mk/bsd.port.mk) Error code 1 Stop in /usr/ports/devel/jdk/1.5/ (line 1344 of /usr/ports/infrastructure/mk/bsd.port.mk). I downloaded some packages from sun already and other patches. Is there an easy way to have jdk installed on this system? Thank you.
Re: VLC - Coredump and/or Seg-Faults on AMD64
On Thursday 29 September 2005 04:18 am, frantisek holop wrote: hmm, on Wed, Sep 28, 2005 at 08:49:13PM -0500, Jolan Luff said that hm you never used it before so maybe it has been working forever up until all the recent ld.so hackery. notice how vlc is all plugins. i'm surprised your brain isn't marked BROKEN or something. no need to get offensive because it's your port. and while the ld.so hackery is over why don't you mark it BROKEN then so we, the _idiots_, the low life forms can get a clue? aren't ports following -current? -f ld.so is still being worked on... The OP said 3.8 -release so ls.so hacking in -current is unrelated.
Re: Build of devel/eclipse hangs
Hi Matthias, Thanks for the detailed report. The problem you are seeing looks exactly like a problem that was fixed about 10 days ago. Are you sure you are running -current userland? -Kurt On Monday 03 October 2005 03:00 pm, Matthias Kilian wrote: Hi, when trying to build deve/eclipse, the build hangs after some time. From eclipse-sdk-3.1p2.log: [...] | [echo] TARGET: compiler [tons of verbose ant blurb] | [javac] [total 10074ms] | [echo] UPDATE ecj.jar | | BUILD SUCCESSFUL | Total time: 15 seconds | Assuming RHEL CLASSPATH compatible. | [echo] TARGET: compiler2 | [echo] compilerArg -encoding ISO-8859-1 | [echo] build compiler org.eclipse.jdt.core.JDTCompilerAdapter | [echo] UPDATE ecj.jar | | BUILD SUCCESSFUL | Total time: 13 seconds | Assuming RHEL CLASSPATH compatible. | [echo] Deleting jars to recompile... At this point, the java process just eats up CPU time. A quick ktrace(1)/kdump(1) gives the following: |478 java EMUL native |478 java CALL sigreturn(0xcfbd12ec) |478 java RET sigreturn JUSTRETURN |478 java PSIG SIGSEGV caught handler=0x8c54e28 mask=0x0 | addr=0x8293c000 trapno=2 478 java CALL write(0x4,0xcfbd12c7,0x1) |478 java RET write -1 errno 35 Resource temporarily unavailable |478 java CALL sigreturn(0xcfbd12ec) |478 java RET sigreturn JUSTRETURN |478 java PSIG SIGSEGV caught handler=0x8c54e28 mask=0x0 | addr=0x8293c000 trapno=2 [...] And so on, ad infinitum. I'm using a two days old -current (oct. 1th, 15:00 UTC) on i386 and the following limits: time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 716800 stack(kbytes)32768 lockedmem(kbytes)316673 memory(kbytes) 948592 nofiles(descriptors) 128 processes128 malloc.conf is AJFG, USE_SYSTRACE is Yes, but I had the same problem some days ago an tried with systrace and malloc.conf disabled, without any success. All packages (except eclipse, of course) are uptodate, including the 1.4 JDK. Could anyone please try to reproduce this problem? Ciao, Kili
Re: Build of devel/eclipse hangs
On Tuesday 04 October 2005 06:18 pm, Matthias Kilian wrote: On Mon, Oct 03, 2005 at 05:06:20PM -0400, Kurt Miller wrote: In that case, I made some commits today that might effect this. Not sure if mirrors have them yet. make sure your tree has revision 1.59 or later of src/libexec/ld.so/dlfcn.c to be sure you have the latest corrections. No change, same problem as before. And, yes: I updated and rebuilt all (kernel and complete user land). However, I didn't rebuild the jdk, since I didn't see any changes in gcc and binutils for the last three days. I'll retry with a snapshot in a few days if nobody can reproduce this with -current. So far I can't reproduce it. I'm still working on ld.so. When that stablizes I can come back to this. -Kurt
Re: mozilla-firefox += README.OpenBSD
On Wednesday 02 November 2005 02:19 pm, Ray Lai wrote:
On Wed, Nov 02, 2005 at 01:18:47PM -0500, Ian Darwin wrote:
+Firefox looks for plugins in ~/.mozilla/plugins and in the directorie(s)
named +in the environment variable MOZ_PLUGIN_PATH.
I think `directories' is better than `directorie(s)'. The singular
form of `directories' isn't `directorie', anyway.
Also, what format should multiple directories be listed in?
Colon-separated? If so, would this sentence be better:
Firefox looks for plugins in ~/.mozilla/plugins and in a
colon-separated list of directories stored in the environment
variable MOZ_PLUGIN_PATH.
Actually, MOZ_PLUGIN_PATH can't be overwritten right now. Currently,
firefox looks in three directories for plugins. Keep the same text
as before (just move it to README.OpenBSD):
Firefox looks for plugins in ~/.mozilla/plugins
${LOCALBASE}/mozilla-firefox/plugins
and ${LOCALBASE}/lib/mozilla-plugins.
-Kurt
Re: Mozilla Firefox 1.5rc1
On Thursday 03 November 2005 08:24 am, Peter Strömberg wrote: tested on i386, amd64 and macppc in venice patch -E is recomended Tested on sparc64 with remote X ok. Themes working ok, but I haven't found an extension that is 1.5rc1 compatible. Anyone know of one? -Kurt
Re: plugins for xchat port (i386)
On Tuesday 22 November 2005 02:37 pm, Damien Couderc wrote: On Fri, 18 Nov 2005 16:51:31 +0100 Markus Hennecke [EMAIL PROTECTED] wrote: Robert Szasz wrote: Is there a way to get the xchat port to support plugins again? This is an update for the stable port bumping the version to 2.4.5 and enabling the perl plugin. Please apply the patch from the xchat directory with `zcat xchat.patch.gz | patch -p0` from inside the xchat directory. I hope that patching the configure script is the right way to tell libtool to include the DynaLoader.a and libintl.a files in the linking process of the perl plugin. I should look at his this week end. As far as i know the plugins didn't work on OpenBSD due to a dlsym() incompatibility. The work Dale and I did to ld.so in -current should have eliminated compatibility problems such as this. :) Bring it to my attention if you find otherwise. -Kurt
Re: Jdk-1.5 Openbsd 3.8 port build problem
Did not not get my reply to this question when you sent it to me directly? Was this box upgraded from 3.6 or before and rm -rf /usr/include/g++ not done durring the upgrade? (see http://www.openbsd.org/faq/upgrade37.html) It looks like your c++ headers are screwed. Does building something like mozilla work? -Kurt On Monday 28 November 2005 03:54 pm, Price, Joe wrote: OpenBSD bsdutil.ceccontrols.com 3.8 GENERIC#138 i386 Packages installed: autoconf-2.13p0 automatically configure source code on many Un*x platforms autoconf-2.57 automatically configure source code on many Un*x platforms autoconf-2.59 automatically configure source code on many Un*x platforms bash-3.0.16p1-static GNU Bourne Again Shell bzip2-1.0.3 block-sorting file compressor, unencumbered gettext-0.10.40p3 GNU gettext ghostscript-fonts-6.0 35 standard PostScript fonts with Adobe name aliases glib-1.2.10p0 useful routines for C programming gmake-3.80p1GNU make gtar-1.15.1p2 GNU version of the traditional tar archiver gtk+-1.2.10p3 General Toolkit for X11 GUI help2man-1.29 GNU help2man iodbc-2.50.3ODBC 2.x driver manager jdk-1.3.1p2 Java2(TM) Standard Edition Dev Kit v1.3.1 jdk-1.4.2p2 Java2(TM) Standard Edition Dev Kit v1.4.2 jdk-linux-1.3.1_15 Java Development Kit for Java 2 Standard Edition 1.3 libiconv-1.9.2p1character set conversion library metaauto-0.5wrapper for gnu auto* mod_auth_ldap-1.6.0p1 Apache LDAP authentication module mysql-client-4.0.24 multithreaded SQL database (client) mysql-server-4.0.24p1 multithreaded SQL database (server) nmap-3.81 scan ports and fingerprint stack of network hosts nspr-4.4.1 Netscape Portable Runtime openldap-client-2.2.27p0 Open source LDAP software (client) openmotif-2.1.30.5p0 Motif toolkit p5-DBD-mysql-3.0002 MySQL drivers for the Perl DBI p5-DBI-1.45p1 unified perl interface for database access p5-Net-Daemon-0.38 extension for portable daemons p5-PlRPC-0.2018 module for writing rpc servers and clients pcre-4.5p1 perl-compatible regular expression library popt-1.7getopt(3)-like library with a number of enhancements redhat_base-8.0p5 Linux compatibility package based on RedHat 8.0 rpm-3.0.6p2 redhat package manager screen-4.0.2multi-screen window manager squid-2.5.STABLE10 WWW and FTP proxy cache and accelerator tcsh-6.13.00p0-static extended C-shell with many useful features unzip-5.52 extract, list test files in a ZIP archive zip-2.3p0 create/update ZIP files compatible with PKZip(tm) My [abbreviated] output: === jdk-1.5.0p1 depends on: gtar-* - found === jdk-1.5.0p1 depends on: zip-* - found === jdk-1.5.0p1 depends on: jdk-1.4* - found === jdk-1.5.0p1 depends on: gmake-3.80p1 - found === jdk-1.5.0p1 depends on: unzip-* - found === jdk-1.5.0p1 depends on: bzip2-* - found === jdk-1.5.0p1 depends on: Xm.2 (openmotif-*) - found === jdk-1.5.0p1 depends on: iconv.2 (libiconv-*) - found === Checking files for jdk-1.5.0p1 `/usr/ports/distfiles/jdk-1_5_0-src-scsl.zip' is up to date. `/usr/ports/distfiles/jdk-1_5_0-bin-scsl.zip' is up to date. `/usr/ports/distfiles/bsd-jdk15-patches-1.tar.bz2' is up to date. Checksum OK for jdk-1_5_0-src-scsl.zip. (sha1) Checksum OK for jdk-1_5_0-bin-scsl.zip. (sha1) Checksum OK for bsd-jdk15-patches-1.tar.bz2. (sha1) === Extracting for jdk-1.5.0p1 === Patching for jdk-1.5.0p1 === Configuring for jdk-1.5.0p1 === Building for jdk-1.5.0p1 *** WARNING: you may see an error such as *** virtual memory exhausted *** when building this package. If you do you must increase *** your limits. See the man page for your shell and look *** for the 'limit' or 'ulimit' command. You may also want to *** see the login.conf(5) manual page. *** Some examples are: *** csh(1) and tcsh(1): limit datasize kbytes of memory OUTPUTDIR = /usr/ports/devel/jdk/1.5/w-jdk-1.5.0p1/control/build/bsd-i586 Build Tool Settings: UNIXCOMMAND_PATH = /bin/ COMPILER_PATH = /usr/bin/ DEVTOOLS_PATH = /usr/local/bin/ USRBIN_PATH = /usr/bin/ MOTIF_DIR = /usr/local CC_VER = 3.3.5 ZIP_VER = 2.3 PATH = /usr/ports/devel/jdk/1.5/w-jdk-1.5.0p1/bin:/usr/bin:/bin:/usr/sbin:/s bin :/usr/local/bin:/usr/local/bin:/usr/X11R6/bin TMPDIR = /usr/ports/devel/jdk/1.5/w-jdk-1.5.0p1/control/build/bsd-i586/tmp Build Directives: USE_ONLY_BOOTDIR_TOOLS = USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = J2RE_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = PARALLEL_COMPILES = false PARALLEL_COMPILE_JOBS = 2 FASTDEBUG = false INCREMENTAL_BUILD = false Build Platform Settings: PLATFORM = bsd ARCH = i586 LIBARCH = i386
Re: hardened php as flavour?
On Tuesday 29 November 2005 11:23 am, frantisek holop wrote: hi there, looking at the hardened php project, it being just a patch, does not the ports framework make it quite easy to make a flavour of php which could actually be php5-hardened or some such? -f devel/jdk/1.4 has an example of how to do that. -Kurt
Re: NEW: jamvm-1.4.0+classpath-0.19 for i386
On Tuesday 29 November 2005 08:05 am, you wrote: Jacob Meuser jakemsr at jakemsr.com writes: why are you specifying AUTOMAKE_VERSION and AUTOCONF_VERSION if you aren't using automake or autoconf? I copied the Makefile from another port I was working on; I was expecting the worse :) wouldn't java be a more appropriate category than devel? Yes; I started out thinking that java would be the right category. But: jdk, jakarta-servletapi, apache-ant. are in devel; jikes and kaffe are in lang; and fastjar is in archivers. Go figure. Majority rules? It might make send to put them all under java. Your thinking about things wrong. By way of example, if the thing your porting is an audio application, then it goes into catagory audio as its first catagory (even if it is written in java). java can be the second catagory to help with cross refefencing things. Since all the programming languages are in lang (except for devel/jdk), I think CATAGORY = lang java is right for both jamvm and classpath. port directories do not have version numbers. sometimes there may be foo/bar and foo/bar2 or some such, but those only exist if there is good reason to have two generations of a package in the ports tree. Good comment; I'm anticipating the need for multiple releases. Classpath is a moving target. They've been producing developer release every two months. Although 0.19 sounds like they are just getting started they are 96% of the way to a conforming JDK 1.4 class library, and within five mauve tests of a conforming JDK 1.2. So I expect to see at least two more classpath developer releases *before* OpenBSD 3.9. On the other side of the coin is the jit/jvm space. There is a very strong push for jit/jvm developers to operate out of the box with the classpath releases. Some projects are already there, others are about to catch up. Before 0.19 most projects did a special classpath integration. So, for example, you see gcc 3.4 stuck back at something like 0.12; btw gcc 4.1 will take classpath out of the box soon; cacao-0.93 already does. Kaffe is getting there (so I hear.) JamVM is easy because it already was there. All this is to say that here's classpath/0.19 and expect classpath/0.20 and /0.21 about 6 months out, depending on the timing of the jits and jvms. Lots of harmony. There is also the related issue of parallel installations, which I have not addressed yet and won't until I get a second jit/jvm in play. I still dont see the reason for having mutiple jamvm ports or classpath ports. If as you say vm's are moving toward decoupling, then one classpath port should suffice. can jamvm be built or run without a classpath package installed? It must have a BUILD_DEPEND and RUN_DEPEND on classpath if not. You've recevied a lot of feedback so far. Please incorporate it into new versions of your ports. Look at other ports for examples. The whole ports tree is full of examples of how to do things right. Make sure you read the documentation that is available to you like bsd.port.mk(5), ports(5) and http://www.openbsd.org/porting.html too. It will help you catch your own mistakes. -Kurt
Re: UPDATE: mozilla-firefox-1.5
On Tuesday 06 December 2005 08:17 pm, Jolan Luff wrote: On Fri, Dec 02, 2005 at 09:20:09AM -0500, Kurt Miller wrote: On Friday 02 December 2005 08:39 am, Christian Weisgerber wrote: Peter Str?mberg [EMAIL PROTECTED] wrote: We'll have to add --enable-official-branding to CONFIGURE_ARGS to get the right brand.dtd file. Yes, with that I get Firefox. Unfortunately, we can't use --enable-official-branding without permission from moz.org. They have started to enforce their trademarks. We can use Firefox Community Edition branding in the mean time. See: http://www.mozilla.org/foundation/trademarks/policy.html http://www.mozilla.org/foundation/trademarks/l10n-policy.html Bernd's latest patch includes the branding change and also remove some old freetype patches that are not needed anymore. It still says Deer Park prevented this site from opening a popup window. Also, I believe patch-xpcom_io_nsNativeCharsetUtils_cpp might be unnecessary now. Please test Bernd's latest patch so we can get it in. Works fine on amd64 and i386 here. It doesn't work via remote X11 on macppc though. Yea, I'm seeing it fail on mappc too (not remote X). I debugged it a little and found that we are hitting this cairo bug: https://bugs.freedesktop.org/show_bug.cgi?id=4505 Seems to be related to 8 bpp Depth. -Kurt
Re: UPDATE: mozilla-firefox-1.5
On Thursday 08 December 2005 10:53 am, Kurt Miller wrote: On Tuesday 06 December 2005 08:17 pm, Jolan Luff wrote: On Fri, Dec 02, 2005 at 09:20:09AM -0500, Kurt Miller wrote: On Friday 02 December 2005 08:39 am, Christian Weisgerber wrote: Peter Str?mberg [EMAIL PROTECTED] wrote: We'll have to add --enable-official-branding to CONFIGURE_ARGS to get the right brand.dtd file. Yes, with that I get Firefox. Unfortunately, we can't use --enable-official-branding without permission from moz.org. They have started to enforce their trademarks. We can use Firefox Community Edition branding in the mean time. See: http://www.mozilla.org/foundation/trademarks/policy.html http://www.mozilla.org/foundation/trademarks/l10n-policy.html Bernd's latest patch includes the branding change and also remove some old freetype patches that are not needed anymore. It still says Deer Park prevented this site from opening a popup window. Also, I believe patch-xpcom_io_nsNativeCharsetUtils_cpp might be unnecessary now. Missed this the first time. Good catch the patch-xpcom_io_nsNativeCharsetUtils_cpp patch is not needed too. I think Bernd noted one more place to fix Deer Park and might have this one fixed too. Please test Bernd's latest patch so we can get it in. Works fine on amd64 and i386 here. It doesn't work via remote X11 on macppc though. Yea, I'm seeing it fail on mappc too (not remote X). I debugged it a little and found that we are hitting this cairo bug: https://bugs.freedesktop.org/show_bug.cgi?id=4505 Seems to be related to 8 bpp Depth. Regarding the crashes: they are from a cairo bug and effect all the gtk+2 apps I've tried. I've been able to reproduce it on multiple platforms in multiple apps. All you need to do is have your X server in Depth 8 and ssh -X to another box to run something like gftp to see it. For macpcc I can reproduce it locally (again Depth 8). Funny thing is I can't reproduce it locally on i386, but remote i386 fails too. Since this is a generic problem and not firefox specific I think firefox should not be held up by it. -Kurt
Re: graphics/cairo fix for 8bpp stuff
On Tuesday 13 December 2005 03:13 pm, Mark Kettenis wrote: Actually, it's not the pixel depth that matters, but the fact that the code basically assumes that all the world is TrueColor, and that 8bpp visuals almost never are. With this, firefix seems to be happy on my iMac with wsfb. Hmm, it stops the segfaults but can you read the fonts in something like gftp or gaim? I can't on my PowerBook G4, with wsfb or using ssh -X at Depth 8 to anything. -Kurt
Re: java core dump
I haven't seen this one before, but I've fixed two MToolkit issues since you build 1.5. If you can reproduce it with the -current port, I'll look at it when I have time. -Kurt On Sunday 08 January 2006 04:30 am, Alf Schlichting wrote: Hello! While running the JAP-proxy from http://anon.inf.tu-dresden.de/jap/JAP.jar with $ java -jar JAP.jar java core-dumped after clicking on the exit-button. This seems not to be repeatable. The port was built some time ago, the system is a snapshot from around Dec. 26, i believe. Alf [EMAIL PROTECTED]:13$ uname -a OpenBSD werkel.rechners.lemarit.com 3.8 GENERIC#459 i386 [EMAIL PROTECTED]:14$ ls -lc /usr/local/jdk-1.5.0/bin/java -rwxr-xr-x 1 root bin 60900 Aug 12 23:52 /usr/local/jdk-1.5.0/bin/java* crash message in xterm: [EMAIL PROTECTED]:17$ [2006/01/07-09:13:50, Error] AnonServiceImpl received connectionError [2006/01/07-09:13:50, Error] AnonProxy received connectionError [2006/01/07-09:13:50, Error] JAPController received connectionError # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x04960253, pid=7329, tid=0x8021d400 # # Java VM: Java HotSpot(TM) Client VM (1.5.0-p1-_02_aug_2005_08_25 mixed mode) # Problematic frame: # C [libmawt.so+0x59253] Java_sun_awt_motif_MPanelPeer_pRestack+0x58 # # An error report file with more information is saved as hs_err_pid7329.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # [1] + Abort trap java -jar JAP.jar (core dumped) [EMAIL PROTECTED]:17$ gdb: [EMAIL PROTECTED]:1$ gdb -q /usr/local/jdk-1.5.0/bin/java java.core (no debugging symbols found) Core was generated by `java'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libpthread.so.6.2...done. Loaded symbols for /usr/lib/libpthread.so.6.2 Symbols already loaded for /usr/lib/libpthread.so.6.2 Reading symbols from /usr/lib/libc.so.38.4...done. Loaded symbols for /usr/lib/libc.so.38.4 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/client/libjvm.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/client/libjvm.so Reading symbols from /usr/lib/libm.so.2.1...done. Loaded symbols for /usr/lib/libm.so.2.1 Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/native_threads/libhpi.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/native_threads/libhpi.so Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/libverify.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/libverify.so Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/libjava.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/libjava.so Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/libzip.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/libzip.so Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/libawt.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/libawt.so Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/libmlib_image.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/libmlib_image.so Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/motif21/libmawt.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/motif21/libmawt.so Reading symbols from /usr/local/lib/libXm.so.3.0...done. Loaded symbols for /usr/local/lib/libXm.so.3.0 Reading symbols from /usr/X11R6/lib/libXp.so.9.0...done. Loaded symbols for /usr/X11R6/lib/libXp.so.9.0 Reading symbols from /usr/X11R6/lib/libXtst.so.9.0...done. Loaded symbols for /usr/X11R6/lib/libXtst.so.9.0 Reading symbols from /usr/X11R6/lib/libXext.so.9.0...done. Loaded symbols for /usr/X11R6/lib/libXext.so.9.0 Reading symbols from /usr/X11R6/lib/libXt.so.9.0...done. Loaded symbols for /usr/X11R6/lib/libXt.so.9.0 Reading symbols from /usr/X11R6/lib/libX11.so.9.0...done. Loaded symbols for /usr/X11R6/lib/libX11.so.9.0 Reading symbols from /usr/X11R6/lib/libSM.so.8.0...done. Loaded symbols for /usr/X11R6/lib/libSM.so.8.0 Reading symbols from /usr/X11R6/lib/libICE.so.8.0...done. Loaded symbols for /usr/X11R6/lib/libICE.so.8.0 Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/libfontmanager.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/libfontmanager.so Reading symbols from /usr/X11R6/lib/libXcursor.so.3.0...done. Loaded symbols for /usr/X11R6/lib/libXcursor.so.3.0 Reading symbols from /usr/X11R6/lib/libXrender.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libXrender.so.4.0 Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/libnet.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/libnet.so Reading symbols from /usr/local/jdk-1.5.0/jre/lib/i386/libnio.so...done. Loaded symbols for /usr/local/jdk-1.5.0/jre/lib/i386/libnio.so #0 0x0356369d in kill () from
Re: Java 1.5 fails to build
On Saturday 14 January 2006 14:12, you wrote: On Saturday 14 January 2006 14:13, knitti wrote: On 1/14/06, viq [EMAIL PROTECTED] wrote: Any ideas/pointers what to do with this? i386 (in vmware), snapshot from jan 9 did it build for you in an earlier occasion? That's the first time I'm trying, thus the question about success stories. building java needs a metric assload of memory, as it seems. last time I built it (-stable, pre x-mas) the whole mem usage exceeded 300 mb (i386) an hour after starting the build, before it was at about 40 mb, don't know at which point it reaches its max. Hmm, I'll watch the memory usage now. The system has 256 ram, 300 swap. That should be enough memory for the build. I'm looking into a similar problem in 1.4 right now. The segfault is random and the few times I caught it in gdb, I didn't get a backtrace that led me to the problem. The breakage occured somewhere after the Dec 22 snapshot. i guess i could try with half a gig of ram, maybe then it'll finish. it could also be a variation on this: http://www.bitwizard.nl/sig11/ thank's, i'll look there. --knitti
Re: Java 1.5 fails to build
On Sunday 15 January 2006 3:28 am, viq wrote: On Sunday 15 January 2006 05:20, Tobias Ulmer wrote: On Sat, Jan 14, 2006 at 10:52:10PM -0500, Kurt Miller wrote: That should be enough memory for the build. I'm looking into a similar problem in 1.4 right now. The segfault is random and the few times I caught it in gdb, I didn't get a backtrace that led me to the problem. The breakage occured somewhere after the Dec 22 snapshot. I had that too and a ports tree update solved it for me. see http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/jdk/1.4/Makefile and http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/jdk/1.5/Makefile or rather http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/jdk/1.5/patches/pat ch-j2se_src_share_bin_java_c as that is what was changed (for both 1.4 and 1.5) Which is present in my ports tree... I committed that to fix another problem. The -current random segfault is a different problem and has nothing to do with how much memory you have or disk space available. -Kurt
Re: Java 1.5 fails to build
On Sunday 15 January 2006 5:50 pm, viq wrote: Yes, apparently. Any idea what could this be? I'll run now several kernel builds on the linux host to verify the hardware is not causing problems. Don't bother - its not a hardware problem. Anyone using the recent snaps will see it. When a solution is found I'll be sure to send a note to [EMAIL PROTECTED] -Kurt
jdk status in current
1.3: build fixed 1.4: build fixed 1.5: not fixed yet. 1.5 will take me a week or two. i386/hotspot is full of datatype assuptions that are wrong. I fixed them in 1.4 a long time ago, but never got around to it for 1.5. -Kurt
Re: jdk status in current
On Wednesday 18 January 2006 10:19 am, Kurt Miller wrote: 1.3: build fixed 1.4: build fixed 1.5: not fixed yet. 1.5 is fixed now too. 1.5 will take me a week or two. i386/hotspot is full of datatype assuptions that are wrong. I fixed them in 1.4 a long time ago, but never got around to it for 1.5.
Re: Error making devel/jdk
On Saturday 18 February 2006 7:30 pm, Aaron Hsu wrote: I'm trying to get the Java plugin for my browsers (Opera and Firefox), and from what I can tell from the documentation, this is done by installing the jdk package. The documentation I read said that only the 1.3 and 1.4 version have plugins for browsers, so I chose 1.4. Doing a make after installing the requisite files to /usr/ports/distfiles gives: bad class file: /usr/ports/devel/jdk/1.4/w-jdk-1.4.2p3/control/build/ \ bsd-i586/classes/javax/swing/JList.class illegal start of class file Please remove or make sure it appears in the correct subdirectory of the classpath. JList list, ^ 1 error Could someone explain this to me, as well as how to fix it? Please don't cross post. If you have a problem building a port mail it to the maintainer and/or [EMAIL PROTECTED] I rarely read misc@ due to the signal to noise ratio. I can't say that I've seen this one before. Why not delete the file in question and restart the build as the error message suggests? If indeed the file is corrupted, perhaps you have bad memory or a failing hard drive. -Kurt
add admin subpackage to iodbc
MAINTAINER timeout
I ported a database design app that wants to use the graphical
odbc admin app, so I added it as a subpackage. Look okay?
Index: Makefile
===
RCS file: /cvs/ports/databases/iodbc/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile28 Oct 2006 11:19:20 - 1.11
+++ Makefile13 Dec 2006 20:59:58 -
@@ -1,12 +1,18 @@
# $OpenBSD: Makefile,v 1.11 2006/10/28 11:19:20 espie Exp $
-COMMENT= ODBC 3.x driver manager
+COMMENT-main= ODBC 3.x driver manager
+COMMENT-admin= ODBC 3.x driver manager admin application
-DISTNAME= libiodbc-3.52.4
-PKGNAME= ${DISTNAME:S/lib//}
+V= 3.52.4
+DISTNAME= libiodbc-${V}
+PKGNAME= iodbc-${V}
+PKGNAME-main= iodbc-${V}
+PKGNAME-admin= iodbc-admin-${V}
CATEGORIES=databases
SHARED_LIBS += iodbcinst3.15 # .3.15
SHARED_LIBS += iodbc3.15 # .3.15
+SHARED_LIBS += iodbcadm 3.15 # .3.15
+SHARED_LIBS += drvproxy 3.15 # .3.15
HOMEPAGE= http://www.iodbc.org/
@@ -17,7 +23,6 @@
PERMIT_PACKAGE_FTP=yes
PERMIT_DISTFILES_CDROM=yes
PERMIT_DISTFILES_FTP= yes
-WANTLIB= c pthread
MASTER_SITES= ${HOMEPAGE}downloads/iODBC/
@@ -25,8 +30,15 @@
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS= --with-iodbc-inidir=${SYSCONFDIR}/iodbc \
- --disable-gui \
--disable-libodbc
+
+MULTI_PACKAGES=-main -admin
+
+WANTLIB-main= c pthread
+
+LIB_DEPENDS-admin= gtk,gdk::x11/gtk+ \
+ iodbc,iodbcinst::databases/iodbc,-main
+WANTLIB-admin= X11 Xext Xi c glib gmodule iconv intl m pthread
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/iodbc
Index: pkg/DESCR
===
RCS file: pkg/DESCR
diff -N pkg/DESCR
--- pkg/DESCR 15 Dec 2003 21:42:16 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,11 +0,0 @@
-iODBC (intrinsic Open Database Connectivity) driver manager
-is compatible with ODBC 2.x specification and performs exactly
-same jobs of ODBC 2.x driver manager(i.e. driver loading,
-Parameters and function sequence checking, driver's function
-Invoking, etc.). Any ODBC driver works with ODBC 2.0 driver
-Manager will also work with iODBC driver manager and vice versa.
-
-Applications (using ODBC function calls) linked with
-iODBC driver manager will be able to simultaneously access
-different type of data sources within one process through
-suitable iODBC drivers.
Index: pkg/DESCR-admin
===
RCS file: pkg/DESCR-admin
diff -N pkg/DESCR-admin
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/DESCR-admin 13 Dec 2006 20:59:58 -
@@ -0,0 +1,2 @@
+iODBC (intrinsic Open Database Connectivity) driver manager
+graphical administration application.
Index: pkg/DESCR-main
===
RCS file: pkg/DESCR-main
diff -N pkg/DESCR-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/DESCR-main 13 Dec 2006 20:59:58 -
@@ -0,0 +1,11 @@
+iODBC (intrinsic Open Database Connectivity) driver manager
+is compatible with ODBC 2.x specification and performs exactly
+same jobs of ODBC 2.x driver manager(i.e. driver loading,
+Parameters and function sequence checking, driver's function
+Invoking, etc.). Any ODBC driver works with ODBC 2.0 driver
+Manager will also work with iODBC driver manager and vice versa.
+
+Applications (using ODBC function calls) linked with
+iODBC driver manager will be able to simultaneously access
+different type of data sources within one process through
+suitable iODBC drivers.
Index: pkg/PFRAG.shared
===
RCS file: pkg/PFRAG.shared
diff -N pkg/PFRAG.shared
--- pkg/PFRAG.shared18 Jul 2006 19:44:27 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,3 +0,0 @@
[EMAIL PROTECTED] $OpenBSD: PFRAG.shared,v 1.4 2006/07/18 19:44:27 alek Exp $
[EMAIL PROTECTED] lib/libiodbc.so.${LIBiodbc_VERSION}
[EMAIL PROTECTED] lib/libiodbcinst.so.${LIBiodbcinst_VERSION}
Index: pkg/PFRAG.shared-admin
===
RCS file: pkg/PFRAG.shared-admin
diff -N pkg/PFRAG.shared-admin
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/PFRAG.shared-admin 13 Dec 2006 20:59:58 -
@@ -0,0 +1,3 @@
[EMAIL PROTECTED] $OpenBSD$
[EMAIL PROTECTED] lib/libdrvproxy.so.${LIBdrvproxy_VERSION}
[EMAIL PROTECTED] lib/libiodbcadm.so.${LIBiodbcadm_VERSION}
Index: pkg/PFRAG.shared-main
===
RCS file: pkg/PFRAG.shared-main
diff -N pkg/PFRAG.shared-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/PFRAG.shared-main 13 Dec 2006 20:59:58 -
@@ -0,0 +1,3 @@
[EMAIL
Re: java on openbsd 4.0?
On Monday 08 January 2007 8:38 pm, bofh wrote: ... data(kbytes) 1048576 ... [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP ... real mem = 3219894272 (3144428K) Nice bug report (i.e. had everything I needed to deduce the reason), but please post port building problems on ports@ and/or to maintainer. I easily could have missed your email due to the signal to noise ratio on [EMAIL PROTECTED] The problem is that the jdk sizes the default memory usage based on real mem installed in the box so with systems with lots of real mem it can set the useage higher then the 1G datasize limit. I thought I fixed this before but perhaps the fix was i386 only. I'll look into it again and send a patch for you to test. -Kurt
Re: java on openbsd 4.0?
On Tuesday 09 January 2007 2:27 pm, J.C. Roberts wrote: Building and installing the lang/jdk/1.3, lang/jdk/1.3-linux and lang/jdk/1.4 ports of 4.0-STABLE worked perfectly. Though I can't test the 1G issue you mentioned, I did hit an issue building the lang/kaffe dependency while trying to build the devel/jdk/1.5 port. I've managed to repeat the error on the second attempt when just trying to build /lang/kaffe The 'easy' part works just fine ;-) # make completes successuflly The problem is when building the package. # make package this dies a miserable death... You might want to note that the error below is sligtly different than the one posted to misc@ on the first time through. Somehow junk is getting appended to one of the path names. Documeowwve below and javaoosowxuownonowmkwssxozuwo in the error previously posted error sent to [EMAIL PROTECTED] Yea that sure is unusual. Kinda looks like memory or disk problems at first glance especially since it changes and has random values. There also is a possibility this is due to pthreads. I changed how pthreads deals with pipes in -current to work-around a random OOo build failure see mostly on mp systems. Did you by chance pipe stdout and/or stderr somewhere (i.e. tee, portslogger)? Making install in lib gmake[3]: Entering directory `/usr/ports/lang/kaffe/w-kaffe-1.1.7p2/build-i386/libraries/javalib/external/classpath/lib' true top_builddir=.. top_srcdir=/usr/ports/lang/kaffe/w-kaffe-1.1.7p2/kaffe-1.1.7/libraries/javalib/external/classpath /bin/sh ./gen-classlist.sh standard Adding java source files from srcdir '/usr/ports/lang/kaffe/w-kaffe-1.1.7p2/kaffe-1.1.7/libraries/javalib/external/classpath'. Adding java source files from VM directory /usr/ports/lang/kaffe/w-kaffe-1.1.7p2/kaffe-1.1.7/libraries/javalib/vmspecific Adding generated files in builddir '..'. gmake[3]: *** No rule to make target `/usr/ports/lang/kaffe/w-kaffe-1.1.7p2/kaffe-1.1.7/libraries/javalib/external/classpath/javax/swing/event/Documeowwve~', needed by `compile-classes'. Stop. gmake[3]: Leaving directory `/usr/ports/lang/kaffe/w-kaffe-1.1.7p2/build-i386/libraries/javalib/external/classpath/lib' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/kaffe/w-kaffe-1.1.7p2/build-i386/libraries/javalib/external/classpath' gmake[1]: *** [install-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/lang/kaffe/w-kaffe-1.1.7p2/build-i386/libraries/javalib' gmake: *** [install-recursive] Error 1 *** Error code 2 Stop in /usr/ports/lang/kaffe (line 1995 of /usr/ports/infrastructure/mk/bsd.port.mk). $ The error smells weird so I'll try updating -stable again just to make sure I don't have something corrupted. Since the last time I updated ports two weeks ago, I had to fsck this box due to a power loss during a bad storm, so the problem might be on my end. And of course, my dmesg. OpenBSD 4.0-stable (GENERIC.MP) #2: Fri Dec 29 07:50:04 PST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Xeon(TM) CPU 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real mem = 1072754688 (1047612K) avail mem = 970498048 (947752K) using 4256 buffers containing 53739520 bytes (52480K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(00) BIOS, date 11/01/04, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf0450 (114 entries) bios0: Dell Computer Corporation Precision WorkStation 530 MT apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfba00/224 (12 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801BA LPC rev 0x00) pcibios0: PCI bus #4 is the last bus bios0: ROM list: 0xc/0x8800 0xc8800/0x2800 mainbus0: Intel MP Specification (Version 1.4) (DELL WS 530 ) cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99 MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(TM) CPU 2.00GHz (GenuineIntel 686-class) 2 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM mainbus0: bus 0 is type PCI mainbus0: bus 1 is type PCI mainbus0: bus 2 is type PCI mainbus0: bus 3 is type PCI mainbus0: bus 4 is type PCI mainbus0: bus 5 is type ISA ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82860 Host rev 0x04: rng active, 7Kb/sec ppb0 at pci0 dev 1 function 0 Intel 82850/82860 AGP rev 0x04 pci1 at ppb0 bus 1 vga1 at pci1 dev 0
Re: UPDATE: mozilla-firefox-2.0.0.1
On Tuesday 09 January 2007 12:56 pm, Kurt Miller wrote: On Thursday 21 December 2006 3:02 am, Martynas Venckus wrote: Hi, Please test the diff below. Bugs fixed for Firefox 2.0.0.1: ~183 in total; 42 crashers, 3 memory leaks, 41 regressions and 4 privacy-related bugs. http://www.mozilla.org/projects/security/known-vulnerabilities.html#firefox2.0.0.1 I've been testing 2.0.0.1 for a week. (i386) http://www.altroot.org/mozilla-firefox-2.0.0.1.patch I've updated the firefox 2.0.0.1 diff for -current, dropped two custom behavior patches, added -devel subpackage for the vlc plugin and other minor changes. This has been working well for me on i386 for the last two weeks. I've also briefly tested macppc and sparc64. However there has been reports of printing having issues on at least amd64. Please test this diff and confirm if printing is working ok for you especially on amd64. The printing issue has been tracked down. Firefox will silently fail to print if it runs out of file descriptors. This will be committed in a day or two unless other problems are reported, so test test test please. :) -Kurt
Re: UPDATE: mozilla-firefox-2.0.0.1
On Wednesday 10 January 2007 3:48 am, steven mestdagh wrote: Kurt Miller [2007-01-09, 16:45:34]: On Tuesday 09 January 2007 12:56 pm, Kurt Miller wrote: On Thursday 21 December 2006 3:02 am, Martynas Venckus wrote: Hi, Please test the diff below. Bugs fixed for Firefox 2.0.0.1: ~183 in total; 42 crashers, 3 memory leaks, 41 regressions and 4 privacy-related bugs. http://www.mozilla.org/projects/security/known-vulnerabilities.html#firefox2.0.0.1 I've been testing 2.0.0.1 for a week. (i386) http://www.altroot.org/mozilla-firefox-2.0.0.1.patch I've updated the firefox 2.0.0.1 diff for -current, dropped two custom behavior patches, added -devel subpackage for the vlc plugin and other minor changes. This has been working well for me on i386 for the last two weeks. I've also briefly tested macppc and sparc64. However there has been reports of printing having issues on at least amd64. Please test this diff and confirm if printing is working ok for you especially on amd64. The printing issue has been tracked down. Firefox will silently fail to print if it runs out of file descriptors. This will be committed in a day or two unless other problems are reported, so test test test please. :) there's a small issue with upgrading. a package containing older shared libraries is left behind, and it causes stuff like ./regxpcom:/usr/local/mozilla-firefox/components/libpipnss.so.19.0: /usr/local/mozilla-firefox/libssl3.so.18.0 : WARNING: symbol(SSL_ImplementedCiphers) size mismatch, relink your program mozilla-firefox-2.0.0.1 (installing): complete moreover, firefox fails to start until you have removed those libraries (e.g. pkg_delete .libs-mozilla-firefox-1.5.0.9). i feel a lot of questions coming from people who upgrade their packages and 'firefox does not work'. so maybe this should at least be mentioned somewhere? $ firefox /usr/local/mozilla-firefox/firefox-bin:/usr/local/mozilla-firefox/components/libpipnss.so.19.0: /usr/local/mozilla-firefox/libssl3.so.18.0 : WARNING: symbol(SSL_ImplementedCiphers) size mismatch, relink your program /usr/local/mozilla-firefox/firefox-bin:/usr/local/mozilla-firefox/components/libpipnss.so.19.0: /usr/local/mozilla-firefox/libssl3.so.18.0 : WARNING: symbol(SSL_ImplementedCiphers) size mismatch, relink your program /usr/local/mozilla-firefox/firefox-bin:/usr/local/mozilla-firefox/components/libpipnss.so.19.0: undefined symbol 'SEC_RegisterDefaultHttpClient' lazy binding failed! oh, it also wanted to open a non-existent page on startup http://www.mozilla.org/projects/firefox/2.0.0.1/whatsnew/ Here's a new version that deals with the transition to system nss better. Both the issue raised above and also another one with libnssckbi that Martynas raised are fixed now. I also added a note about the printer issue to README.OpenBSD per Martynas's suggestion. The 404 page has been reported to mozilla.org, if they don't add a page before release we can change the startup.homepage_override_url property easily enough later. -Kurt firefox2.diff.gz Description: GNU Zip compressed data
Re: [4.0] sixxs-aiccu-2007-01-07
I would like to point out that the aixxs-aiccu client isn't needed at all in most cases. Simply use /etc/hostname.gif0 with the appropriate 'up giftunnel' and 'up inet6' lines and set your default ipv6 route. Nothing more is needed. However, if your IPv6 host is behind a router or firewall that blocks protocol 41 then using aiccu for its AYIYA tunneling protocol makes sense. The port that comes with the sixxs distfile is outdated. Attached is a proper port for -current that I created to use AYIYA. aiccu.tar.gz Description: application/tgz
Re: [4.0] sixxs-aiccu-2007-01-07
On Thursday 18 January 2007 3:22 pm, Christian Weisgerber wrote: I'm attaching my port, which takes some cosmetic inspiration from kurt's. It does not include the cumbersome gnutls dependency, since the SixXS TIC servers currently do not support TLS anyway. (Confirmed by SixXS staff). I've only tested this with my heartbeat gif(4) tunnel. Now with aiccu-20070115. A quick test of AYIYA with the 20070115 version fails to work. verbose messages don't show any problems. :( The 20060725 version works. I'll look into it a bit and see what I can find out. -Kurt
Re: [4.0] sixxs-aiccu-2007-01-07
On Thursday 18 January 2007 3:22 pm, you wrote: I'm attaching my port, which takes some cosmetic inspiration from kurt's. It does not include the cumbersome gnutls dependency, since the SixXS TIC servers currently do not support TLS anyway. (Confirmed by SixXS staff). I've only tested this with my heartbeat gif(4) tunnel. Now with aiccu-20070115. I'm fed up with SixXS. I've been completely locked out of posting to the forum or problem tickets. There is a person there who is abusing his power and taking it out on me. I submitted a brief problem report which was closed as invalid for not providing enough information. So I opened a new one with all the details and the same guy marked it invalid because he could ping6 me (I was running the old version of aiccu which works). So I opened it again explaining that but instead it was closed again. Now I'm unable to submit new trouble tickets or post my issue even to the forum. https://noc.sixxs.net/tickets/?msg=tickets-476902 https://noc.sixxs.net/tickets/?msg=tickets-476846 https://noc.sixxs.net/tickets/?msg=tickets-476528 Perhaps someone else could persue the ayiya problems with the 2007.01.15 version of aiccu on OpenBSD. I suggest you use the forum instead of the trouble ticket system since then at least the rude support person there can't hide behind invalid and duplicate trouble tickets that don't show up anywhere. -Kurt
Re: Problems compiling openoffice
sorry folks this is my fault. I removed a patch that should have been trimmed down instead. I will be committing the fix for it as soon as my next build of devel/jdk/1.5 completes. thanks for the reports. On Thursday 01 February 2007 12:36 am, STeve Andre' wrote: Trying to compile the openoffice monster gives me the error listed below. I've tried this multiple times, this last time after recreating my ports tree. This is on a -current system compiled on 1/30. Given the complexities of both Java and Openoffice, I'm rather puzzled. Have others built oo lately? This is the first time in several weeks for me. Thanks, STeve Andre' /usr/local/jdk-1.5.0/bin/java -Xms256m -Xmx256m -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -cp .:../../unxobsd.pro/class:/usr/local/jdk-1.5.0/jre/lib/rt.jar:.:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/xml-apis.jar:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/xercesImpl.jar:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/xt.jar:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/unoil.jar:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/ridl.jar:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/jurt.jar:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/jut.jar:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/xmlsearch.jar:/usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/solver/680/unxobsd.pro/bin/xmlhelp.jar:/usr/local/lib/db4/db.jar com.sun.star.help.HelpLinker @/tmp/mkk19031 Exception in thread main java.lang.UnsatisfiedLinkError: no db_java in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1684) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:992) at com.sleepycat.db.db_javaJNI.clinit(db_javaJNI.java:34) at com.sleepycat.db.Db.init(Db.java:3276) at com.sun.star.help.HelpLinker.link(HelpLinker.java:369) at com.sun.star.help.HelpLinker.main(HelpLinker.java:228) dmake: Error code 1, while making '../../unxobsd.pro/bin/sbasic_en-US.zip' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /usr/ports/editors/openoffice/w-openoffice-2.1.0p3/OOE680_m6/helpcontent2/util/sbasic dmake: Error code 1, while making 'build_instsetoo_native' '---* *---' *** Error code 255 Stop in /usr/ports/editors/openoffice (line 185 of Makefile). *** Error code 1 Stop in /usr/ports/editors/openoffice (line 2063 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/editors/openoffice (line 1370 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/editors/openoffice (line 1861 of /usr/ports/infrastructure/mk/bsd.port.mk).
libtool: preserve -pthread in dependency_libs
Probably too late in the cycle to commit this, but
anyway...
libs built with libtool and -pthread drop the need for
-pthread in dependency_libs. This diff adds -pthread to
dependency_libs so any libs depending on it will link
with -pthread too.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/devel/libtool/Makefile,v
retrieving revision 1.60
diff -u -r1.60 Makefile
--- Makefile21 Nov 2006 11:31:39 - 1.60
+++ Makefile9 Feb 2007 22:51:38 -
@@ -6,7 +6,7 @@
VERSION= 1.5.22
DISTNAME= libtool-${VERSION}
-PKGNAME-main= ${DISTNAME}p7
+PKGNAME-main= ${DISTNAME}p8
PKGNAME-ltdl= libltdl-${VERSION}p1
SHARED_LIBS= ltdl 4.3
MODGNU_SHARED_LIBS=ltdl '-no-undefined'
Index: patches/patch-ltmain_in
===
RCS file: /cvs/ports/devel/libtool/patches/patch-ltmain_in,v
retrieving revision 1.24
diff -u -r1.24 patch-ltmain_in
--- patches/patch-ltmain_in 23 Oct 2006 13:55:07 - 1.24
+++ patches/patch-ltmain_in 9 Feb 2007 22:51:38 -
@@ -1,7 +1,15 @@
$OpenBSD: patch-ltmain_in,v 1.24 2006/10/23 13:55:07 espie Exp $
ltmain.in.orig Sun Dec 18 22:43:52 2005
-+++ ltmain.in Sat Oct 21 16:07:13 2006
-@@ -2073,6 +2073,17 @@ EOF
+--- ltmain.in.orig Sun Dec 18 16:43:52 2005
ltmain.in Fri Feb 9 16:42:11 2007
+@@ -1604,6 +1604,7 @@ EOF
+ compiler_flags=$compiler_flags $arg
+ compile_command=$compile_command $arg
+ finalize_command=$finalize_command $arg
++ deplibs=$deplibs $arg
+ continue
+ ;;
+
+@@ -2073,6 +2074,17 @@ EOF
;;
esac
for pass in $passes; do
@@ -19,7 +27,15 @@
if test $linkmode,$pass = lib,link ||
test $linkmode,$pass = prog,scan; then
libs=$deplibs
-@@ -2334,20 +2345,20 @@ EOF
+@@ -2100,6 +2112,7 @@ EOF
+ finalize_deplibs=$deplib $finalize_deplibs
+ else
+ compiler_flags=$compiler_flags $deplib
++ test $linkmode = lib newdependency_libs=$deplib
$newdependency_libs
+ fi
+ continue
+ ;;
+@@ -2334,20 +2347,20 @@ EOF
# It is a libtool convenience library, so add in its objects.
convenience=$convenience $ladir/$objdir/$old_library
old_convenience=$old_convenience $ladir/$objdir/$old_library
@@ -50,7 +66,7 @@
continue
fi # $pass = conv
-@@ -2542,7 +2553,7 @@ EOF
+@@ -2542,7 +2555,7 @@ EOF
{ test $use_static_libs = no || test -z $old_library; }; then
if test $installed = no; then
notinst_deplibs=$notinst_deplibs $lib
@@ -59,7 +75,7 @@
fi
# This is a shared library
-@@ -2741,7 +2752,7 @@ EOF
+@@ -2741,7 +2754,7 @@ EOF
add_dir=
add=
# Finalize command for both is simple: just hardcode it.
@@ -68,7 +84,7 @@
add=$libdir/$linklib
elif test $hardcode_minus_L = yes; then
add_dir=-L$libdir
-@@ -3359,6 +3370,20 @@ EOF
+@@ -3359,6 +3372,20 @@ EOF
major=
versuffix=
verstring=
@@ -89,7 +105,7 @@
fi
# Check to see if the archive will have undefined symbols.
-@@ -6257,40 +6282,6 @@ relink_command=\$relink_command\
+@@ -6257,40 +6284,6 @@ relink_command=\$relink_command\
# Exit here if they wanted silent mode.
test $show = : exit $EXIT_SUCCESS
Re: SIGPIPE in pt_Send (libnspr4)
On Monday 05 March 2007 2:38:19 am Gregory Steuck wrote: I am running i386-current-Feb-14. Firefox frequently crashes on me with a stack trace below. Does anybody know if this has been fixed in newer current (which I should upgrade to anyway, but not tonight). The relvant packages are from Feb 14 snapshot: mozilla-firefox-2.0.0.1p0 nss-3.11.4p1 (gdb) run Starting program: /usr/local/mozilla-firefox/firefox-bin [New process 21520] [New process 21520, thread 0x856dd800] [New process 21520, thread 0x7d86e400] [New process 21520, thread 0x7d97] Program received signal SIGPIPE, Broken pipe. [Switching to process 21520, thread 0x7d97] 0x0b2894e9 in sendto () from /usr/lib/libc.so.40.3 SIPPIPE is normal. Issue the following command before 'run' to tell gdb to let them be handled/ignored by firefox (i.e. SIG_IGN) without interrupting the debug session. (gdb) handle SIGPIPE nostop noprint -Kurt
Re: SIGSEGV in nsFrameManager::GetPrimaryFrameFor in mozilla-firefox-2.0.0.1p0 (was: SIGPIPE in pt_Send (libnspr4))
On Tuesday 06 March 2007 1:37:33 am Gregory Steuck wrote: But there are crashes and this is one I caught: [New process 12726, thread 0x82258400] Program received signal SIGPIPE, Broken pipe. Program received signal SIGSEGV, Segmentation fault. [Switching to process 12726, thread 0x8a21b000] 0x0c9c6b42 in nsFrameManager::GetPrimaryFrameFor(nsIContent*) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0 (gdb) where #0 0x0c9c6b42 in nsFrameManager::GetPrimaryFrameFor(nsIContent*) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0 Ok now we're getting somewhere. :-) I should have mentioned in my first email that you should be running gdb on the -debug flavor package. Running gdb on the non-debug pkg is helpful but with the debug flavor you should get line numbers and they really help the process along. ;-) I looked briefly at GetPrimaryFrameFor() in ./mozilla/layout/base/nsFrameManager.cpp, but without line numbers I can't make any progress. It can be any number of null pointer de-refs or the like. Here's what I suggest you do; Update your ports tree to -current, make sure you have nspr-4.6.5 installed (to fix the issue Martynas pointed out), build install the debug flavor of firefox 2.0.0.2p1, catch the segfault again. Open a bug report at mozilla.org with the stack trace with line numbers and include any other relevant info like how to reproduce, architecture, ulimits, etc. Send ports@ the link to the bug report and I'll add whatever comments I can come up with to the bug report. -Kurt
libtool: preserve -pthread in dependency_libs
libs built with libtool and -pthread drop the need for
-pthread in dependency_libs. This diff adds -pthread to
dependency_libs so any libs depending on it will link
with -pthread too.
This removes the need for hack to add -pthread to
dependency_libs in devel/glib2.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/devel/libtool/Makefile,v
retrieving revision 1.61
diff -u -r1.61 Makefile
--- Makefile14 Feb 2007 22:05:07 - 1.61
+++ Makefile15 Mar 2007 19:57:32 -
@@ -6,7 +6,7 @@
VERSION= 1.5.22
DISTNAME= libtool-${VERSION}
-PKGNAME-main= ${DISTNAME}p8
+PKGNAME-main= ${DISTNAME}p9
PKGNAME-ltdl= libltdl-${VERSION}p1
SHARED_LIBS= ltdl 4.3
MODGNU_SHARED_LIBS=ltdl '-no-undefined'
Index: patches/patch-ltmain_in
===
RCS file: /cvs/ports/devel/libtool/patches/patch-ltmain_in,v
retrieving revision 1.24
diff -u -r1.24 patch-ltmain_in
--- patches/patch-ltmain_in 23 Oct 2006 13:55:07 - 1.24
+++ patches/patch-ltmain_in 15 Mar 2007 19:57:32 -
@@ -1,7 +1,15 @@
$OpenBSD: patch-ltmain_in,v 1.24 2006/10/23 13:55:07 espie Exp $
ltmain.in.orig Sun Dec 18 22:43:52 2005
-+++ ltmain.in Sat Oct 21 16:07:13 2006
-@@ -2073,6 +2073,17 @@ EOF
+--- ltmain.in.orig Sun Dec 18 16:43:52 2005
ltmain.in Fri Feb 9 16:42:11 2007
+@@ -1604,6 +1604,7 @@ EOF
+ compiler_flags=$compiler_flags $arg
+ compile_command=$compile_command $arg
+ finalize_command=$finalize_command $arg
++ deplibs=$deplibs $arg
+ continue
+ ;;
+
+@@ -2073,6 +2074,17 @@ EOF
;;
esac
for pass in $passes; do
@@ -19,7 +27,15 @@
if test $linkmode,$pass = lib,link ||
test $linkmode,$pass = prog,scan; then
libs=$deplibs
-@@ -2334,20 +2345,20 @@ EOF
+@@ -2100,6 +2112,7 @@ EOF
+ finalize_deplibs=$deplib $finalize_deplibs
+ else
+ compiler_flags=$compiler_flags $deplib
++ test $linkmode = lib newdependency_libs=$deplib
$newdependency_libs
+ fi
+ continue
+ ;;
+@@ -2334,20 +2347,20 @@ EOF
# It is a libtool convenience library, so add in its objects.
convenience=$convenience $ladir/$objdir/$old_library
old_convenience=$old_convenience $ladir/$objdir/$old_library
@@ -50,7 +66,7 @@
continue
fi # $pass = conv
-@@ -2542,7 +2553,7 @@ EOF
+@@ -2542,7 +2555,7 @@ EOF
{ test $use_static_libs = no || test -z $old_library; }; then
if test $installed = no; then
notinst_deplibs=$notinst_deplibs $lib
@@ -59,7 +75,7 @@
fi
# This is a shared library
-@@ -2741,7 +2752,7 @@ EOF
+@@ -2741,7 +2754,7 @@ EOF
add_dir=
add=
# Finalize command for both is simple: just hardcode it.
@@ -68,7 +84,7 @@
add=$libdir/$linklib
elif test $hardcode_minus_L = yes; then
add_dir=-L$libdir
-@@ -3359,6 +3370,20 @@ EOF
+@@ -3359,6 +3372,20 @@ EOF
major=
versuffix=
verstring=
@@ -89,7 +105,7 @@
fi
# Check to see if the archive will have undefined symbols.
-@@ -6257,40 +6282,6 @@ relink_command=\$relink_command\
+@@ -6257,40 +6284,6 @@ relink_command=\$relink_command\
# Exit here if they wanted silent mode.
test $show = : exit $EXIT_SUCCESS
Re: Crashes with SVG image in mozilla-firefox
On Thursday 15 March 2007 4:07:48 pm Mikolaj Kucharski wrote: Hi, When I open html with embedded SVG image I've got random crashes of Firefox when I click with right button and try to navigate menu or when I open main menu e.g. to check in help-about browser version. An example page is here http://www.ba.infn.it/~zito/xml/embed.html Thanks for the report. I reproduced w/the debug version and have this backtrace info. Most likely suspect is cairo. (gdb) bt #0 0x06bf63c8 in memcpy () from /usr/lib/libc.so.40.3 #1 0x0051e9cd in NoSwap () from /usr/X11R6/lib/libX11.so.9.0 #2 0x0051f9e7 in SendZImage () from /usr/X11R6/lib/libX11.so.9.0 #3 0x0051ff10 in XPutImage () from /usr/X11R6/lib/libX11.so.9.0 #4 0x05f337c3 in _draw_image_surface (surface=0x84532400, image=0x840cae00, dst_x=0, dst_y=0) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-xlib-surface.c:1215 #5 0x05f33a06 in _cairo_xlib_surface_clone_similar (abstract_surface=0x84532600, src=0x840cae00, clone_out=0xcfbd0940) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-xlib-surface.c:1326 #6 0x05f12fc0 in _cairo_surface_clone_similar (surface=0x84532600, src=0x840cae00, clone_out=0xcfbd0940) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-surface.c:1017 #7 0x05f1990e in _cairo_pattern_acquire_surface_for_surface (pattern=0xcfbd07cc, dst=0x84532600, x=0, y=0, width=87, height=15, out=0xcfbd0940, attr=0xcfbd094c) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-pattern.c:1142 #8 0x05f19bc4 in _cairo_pattern_acquire_surface (pattern=0xcfbd07cc, dst=0x84532600, x=0, y=0, width=87, height=15, surface_out=0xcfbd0940, attributes=0xcfbd094c) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-pattern.c:1255 #9 0x05f19dfa in _cairo_pattern_acquire_surfaces (src=0xcfbd0bac, mask=0xcfbd0a8c, dst=0x84532600, src_x=0, src_y=95, mask_x=0, mask_y=0, width=87, height=15, src_out=0xcfbd0944, mask_out=0xcfbd0940, src_attributes=0xcfbd099c, mask_attributes=0xcfbd094c) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-pattern.c:1363 #10 0x05f34283 in _cairo_xlib_surface_composite (op=CAIRO_OPERATOR_ADD, src_pattern=0xcfbd0bac, mask_pattern=0xcfbd0a8c, abstract_dst=0x84532600, src_x=0, src_y=95, mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=87, height=15) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-xlib-surface.c:1734 #11 0x05f131af in _cairo_surface_composite (op=CAIRO_OPERATOR_ADD, src=0xcfbd0bac, mask=0xcfbd0a8c, dst=0x84532600, src_x=0, src_y=95, mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=87, height=15) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-surface.c:1103 #12 0x05f109d8 in _cairo_scaled_font_show_glyphs (scaled_font=0x881a6400, op=CAIRO_OPERATOR_ADD, pattern=0xcfbd0bac, surface=0x84532600, source_x=0, source_y=95, dest_x=0, dest_y=0, width=87, height=15, glyphs=0x810a5400, num_glyphs=41) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-scaled-font.c:997 ---Type return to continue, or q return to quit--- #13 0x05f15c75 in _cairo_surface_old_show_glyphs_draw_func (closure=0xcfbd0dfc, op=CAIRO_OPERATOR_ADD, src=0xcfbd0bac, dst=0x84532600, dst_x=0, dst_y=95, extents=0xcfbd0e1c) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-surface-fallback.c:890 #14 0x05f14960 in _create_composite_mask_pattern (mask_pattern=0xcfbd0cbc, clip=0x84532884, draw_func=0x5f15a9f _cairo_surface_old_show_glyphs_draw_func, draw_closure=0xcfbd0dfc, dst=0x81b3ce00, extents=0xcfbd0e1c) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-surface-fallback.c:127 #15 0x05f14a08 in _clip_and_composite_with_mask (clip=0x84532884, op=CAIRO_OPERATOR_OVER, src=0xcfbd0edc, draw_func=0x5f15a9f _cairo_surface_old_show_glyphs_draw_func, draw_closure=0xcfbd0dfc, dst=0x81b3ce00, extents=0xcfbd0e1c) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-surface-fallback.c:165 #16 0x05f14e65 in _clip_and_composite (clip=0x84532884, op=CAIRO_OPERATOR_OVER, src=0xcfbd0edc, draw_func=0x5f15a9f _cairo_surface_old_show_glyphs_draw_func, draw_closure=0xcfbd0dfc, dst=0x81b3ce00, extents=0xcfbd0e1c) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-surface-fallback.c:379 #17 0x05f15da0 in _cairo_surface_fallback_show_glyphs (surface=0x81b3ce00, op=CAIRO_OPERATOR_OVER, source=0xcfbd0edc, glyphs=0x810a5400, num_glyphs=41, scaled_font=0x881a6400) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-surface-fallback.c:941 #18 0x05f14326 in _cairo_surface_show_glyphs (surface=0x81b3ce00, op=CAIRO_OPERATOR_OVER, source=0xcfbd0f9c, glyphs=0x810a5400, num_glyphs=41, scaled_font=0x881a6400) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-surface.c:1837 #19 0x05f06caa in _cairo_gstate_show_glyphs (gstate=0x84532800, glyphs=0x7d0fb800, num_glyphs=41) at /usr/obj/ports/cairo-1.2.6/cairo-1.2.6/src/cairo-gstate.c:1449 #20 0x05f0120e in cairo_show_text (cr=0x848fec40, utf8=0xcfbd125c Mouse over the circle to change its size.) at
Re: Crashes with SVG image in mozilla-firefox
On Saturday 17 March 2007 9:41:27 am Eric Faurot wrote: On 3/17/07, Matthieu Herrb [EMAIL PROTECTED] wrote: Yes, it seems that cairo is feeding an invalid XImage structure to XPutImage. Right, I found it (patch attached). I tested it at depth 8, 16 and 24 with XRender on and off. I think it should go into 4.1 Execlent! Committed, thank you. -Kurt
Update: www/tomcat/v5 5.5.23
Straightforward update to 5.5.23.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/www/tomcat/v5/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- Makefile25 Nov 2006 07:42:58 - 1.2
+++ Makefile27 Mar 2007 21:11:34 -
@@ -4,11 +4,12 @@
COMMENT-admin= administration web application
COMMENT-examples=example applications and documentation
-V= 5.5.20
+V= 5.5.23
DISTNAME= apache-tomcat-${V}
-PKGNAME-main= tomcat-${V}p0
-PKGNAME-admin= tomcat-admin-${V}p0
-PKGNAME-examples=tomcat-examples-${V}p0
+PKGNAME= tomcat-${V}
+PKGNAME-main= tomcat-${V}
+PKGNAME-admin= tomcat-admin-${V}
+PKGNAME-examples=tomcat-examples-${V}
CATEGORIES=www
DISTFILES= ${DISTNAME}.tar.gz \
Index: distinfo
===
RCS file: /cvs/ports/www/tomcat/v5/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- distinfo25 Oct 2006 18:10:18 - 1.1.1.1
+++ distinfo27 Mar 2007 21:11:34 -
@@ -1,12 +1,15 @@
-MD5 (apache-tomcat-5.5.20-admin.tar.gz) = e779d0694dad09b4adbe890eb04c5057
-MD5 (apache-tomcat-5.5.20-fulldocs.tar.gz) = dbb500aa9cd8c75a784062ebdca25778
-MD5 (apache-tomcat-5.5.20.tar.gz) = 2efa171cddb9f85ed19ef6f21b2c7d31
-RMD160 (apache-tomcat-5.5.20-admin.tar.gz) =
3d4172856c27360764ab888481f39de557157ccd
-RMD160 (apache-tomcat-5.5.20-fulldocs.tar.gz) =
1ae90360e292871d038b18d24e9f6fd548407bbb
-RMD160 (apache-tomcat-5.5.20.tar.gz) = 93c422347a28b5159301f8f7799d59fdb58c43c6
-SHA1 (apache-tomcat-5.5.20-admin.tar.gz) =
b4575c721d0c035dad1241ccbf893158c80f3a1d
-SHA1 (apache-tomcat-5.5.20-fulldocs.tar.gz) =
7090c1e398a940b45bf2893469ab33e896d8a724
-SHA1 (apache-tomcat-5.5.20.tar.gz) = 70316421f72291bbce3fe6e79bff39f526132946
-SIZE (apache-tomcat-5.5.20-admin.tar.gz) = 2330527
-SIZE (apache-tomcat-5.5.20-fulldocs.tar.gz) = 2992420
-SIZE (apache-tomcat-5.5.20.tar.gz) = 5949295
+MD5 (apache-tomcat-5.5.23-admin.tar.gz) = 7d48a07234c68289435df9694e068039
+MD5 (apache-tomcat-5.5.23-fulldocs.tar.gz) = 033fca9535e2efa536ebeed317b2091e
+MD5 (apache-tomcat-5.5.23.tar.gz) = 7a4cc2e00c7d2c9d9c4437ede337f832
+RMD160 (apache-tomcat-5.5.23-admin.tar.gz) =
dd5fd831c8ba646524c21b4da988e34d5a43485b
+RMD160 (apache-tomcat-5.5.23-fulldocs.tar.gz) =
9be62386550b235784b7baa769124a0dcd9a7271
+RMD160 (apache-tomcat-5.5.23.tar.gz) = 9173e12cf70d741c8b3b73812a3f9c49c7147417
+SHA1 (apache-tomcat-5.5.23-admin.tar.gz) =
5a4874d9b339e32ff2377e9c0057fd9c88d09465
+SHA1 (apache-tomcat-5.5.23-fulldocs.tar.gz) =
2121353ef7a7164588989981e50490f6eecbe8ad
+SHA1 (apache-tomcat-5.5.23.tar.gz) = 81a095ccd3c6b03a882b8b91bdfe46a32fa373b5
+SHA256 (apache-tomcat-5.5.23-admin.tar.gz) =
83167ca2ca17ef39c6b91f284050762ead5d294d1a18f2619b56075538ed315b
+SHA256 (apache-tomcat-5.5.23-fulldocs.tar.gz) =
e44ce839a1424738570033057182b573ca259cd5b4388e9f509278721a637273
+SHA256 (apache-tomcat-5.5.23.tar.gz) =
2948a0d6da10ff3760d58a4c73857424cfcdf7ce267ca030d94efaad11b59f81
+SIZE (apache-tomcat-5.5.23-admin.tar.gz) = 2323422
+SIZE (apache-tomcat-5.5.23-fulldocs.tar.gz) = 3021063
+SIZE (apache-tomcat-5.5.23.tar.gz) = 5977561
Index: patches/patch-bin_catalina_sh
===
RCS file: /cvs/ports/www/tomcat/v5/patches/patch-bin_catalina_sh,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-bin_catalina_sh
--- patches/patch-bin_catalina_sh 25 Oct 2006 18:10:18 - 1.1.1.1
+++ patches/patch-bin_catalina_sh 27 Mar 2007 21:11:34 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-bin_catalina_sh,v 1.1.1.1 2006/10/25 18:10:18 kurt Exp $
bin/catalina.sh.orig Sat Aug 28 20:02:20 2004
-+++ bin/catalina.shThu Oct 14 09:14:40 2004
-@@ -107,7 +107,7 @@ fi
+--- bin/catalina.sh.orig Mon Mar 5 10:26:02 2007
bin/catalina.shTue Mar 27 13:37:25 2007
+@@ -135,7 +135,7 @@ fi
CLASSPATH=$CLASSPATH:$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/commons-logging-api.jar
if [ -z $CATALINA_BASE ] ; then
Index: patches/patch-bin_setclasspath_sh
===
RCS file: /cvs/ports/www/tomcat/v5/patches/patch-bin_setclasspath_sh,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-bin_setclasspath_sh
--- patches/patch-bin_setclasspath_sh 25 Oct 2006 18:10:18 - 1.1.1.1
+++ patches/patch-bin_setclasspath_sh 27 Mar 2007 21:11:34 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-bin_setclasspath_sh,v 1.1.1.1 2006/10/25 18:10:18 kurt Exp $
bin/setclasspath.sh.orig Mon Jul 31 13:01:05 2006
-+++ bin/setclasspath.shMon Jul 31 13:02:44 2006
+--- bin/setclasspath.sh.orig Mon Mar 5 10:26:01 2007
bin/setclasspath.shTue Mar 27 13:37:25 2007
@@ -8,6 +8,11 @@
# First clear out the user classpath
CLASSPATH=
@@ -13,7 +13,7 @@
# Make sure prerequisite environment variables are set
if [ -z $JAVA_HOME -a
NEW: www/tomcat/native
COMMENT=apache portable runtime integration library for tomcat $ cat pkg/DESCR This package provides a library with JNI wrappers for APR used by Tomcat (libtcnative). When installed, tomcat will load the library upon startup and provides superior scalability, performance, and better integration with native server technologies. Tomcat 5 and up can make use of this library. Tested lightly on i386 with tomcat 5.5.23 -Kurt tomcat-native.tar.gz Description: application/tgz
Re: NEW: www/tomcat/native
On Tuesday 27 March 2007 5:22:48 pm Kurt Miller wrote: COMMENT=apache portable runtime integration library for tomcat $ cat pkg/DESCR This package provides a library with JNI wrappers for APR used by Tomcat (libtcnative). When installed, tomcat will load the library upon startup and provides superior scalability, performance, and better integration with native server technologies. Tomcat 5 and up can make use of this library. Tested lightly on i386 with tomcat 5.5.23 Errr, too lightly tested. Forget this for the moment... -Kurt
Re: Binary upgrade of mozilla-thunderbird fails on OpenBSD 4.1
On Wednesday 09 May 2007 8:42:23 am jeraklo wrote: Suspected line reads: Checking for collisions with .libs-mozilla-thunderbird-1.5.0.10... some found Could anyone explain what to do next ? It looks like you previously upgraded to 1.5.0.10, downgraded to 1.5.0.9p1 and now you're upgrading again to 1.5.0.10. When you downgraded pkg tools kept the 1.5.0.10 libs around in the .libs-mozilla-thunderbird-1.5.0.10 package. Just pkg_delete .libs-mozilla-thunderbird-1.5.0.10 to have the upgrade work again. I like to remove any .libs packages that are no longer needed after upgrading. If pkg_delete lets you delete it then it is not used anymore by other installed packages. ls /var/db/pkg/.libs-* for a list. -Kurt
Re: wine-0.9.37, ntdll.so loading fails, gdb output included
Please email the list the updated port so that people who
may be interested in helping you can reproduce the problem.
On Saturday 19 May 2007 2:32:19 pm Vortechz wrote:
Jacob probably recognizes this:
Starting program: /usr/local/bin/wine /emul/w/windows/sol.exe
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 31915, thread 0x8891a000]
0x06a4dbec in _dl_malloc () from /usr/libexec/ld.so
(gdb) bt
#0 0x06a4dbec in _dl_malloc () from /usr/libexec/ld.so
#1 0x06a4e50a in _dl_opendir () from /usr/libexec/ld.so
#2 0x06a4e938 in _dl_find_shlib () from /usr/libexec/ld.so
#3 0x06a4ebe3 in _dl_load_shlib_hint () from /usr/libexec/ld.so
#4 0x06a4ee5c in _dl_load_shlib () from /usr/libexec/ld.so
#5 0x06a4c66d in dlopen () from /usr/libexec/ld.so
#6 0x0a667d54 in wine_dlopen (
filename=0x7d4d014a /usr/local/lib/../lib/wine/ntdll.dll.so, flag=2,
error=0xcfbcaff0 \020°¼Ï, errorsize=1024) at loader.c:703
#7 0x0a667cb6 in wine_init (argc=16392, argv=0xcfbcafa0,
error=0xcfbcaff0 \020°¼Ï, error_size=1024) at loader.c:655
#8 0x1c000f92 in main (argc=2, argv=0xcfbcb46c) at main.c:111
* Now, I want to know more about what ld.so is doing:
(gdb) symbol /usr/libexec/ld.so
Load new symbol table from /usr/libexec/ld.so? (y or n) y
Reading symbols from /usr/libexec/ld.so...done.
(gdb) run /emul/w/windows/sol.exe
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/bin/wine /emul/w/windows/sol.exe
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 17606, thread 0x7f924000]
0x084f9bec in ?? () from /usr/libexec/ld.so
(gdb) bt
#0 0x084f9bec in ?? () from /usr/libexec/ld.so
#1 0x284f718c in ?? () from /usr/libexec/ld.so
#2 0x0008 in ?? ()
#3 0xcfbf5ee8 in ?? ()
#4 0x084fa50a in ?? () from /usr/libexec/ld.so
#5 0x4000 in dladdr ()
Cannot access memory at address 0x3fc8
* 0x3fc8 seem to be constant and appears at every try
* Next...I compiled ld.so and loaded symbols from ld.so and util.o
in /usr/src/libexec/ld.so/ (stupid move?) to get this:
[Switching to process 31541, thread 0x831a3000]
0x04468bec in _dl_malloc () from /usr/libexec/ld.so
(gdb) bt
#0 0x04468bec in _dl_malloc () from /usr/libexec/ld.so
#1 0x0446950a in _dl_opendir () from /usr/libexec/ld.so
#2 0x04469938 in _dl_find_shlib () from /usr/libexec/ld.so
#3 0x04469be3 in _dl_load_shlib_hint () from /usr/libexec/ld.so
#4 0x04469e5c in _dl_load_shlib () from /usr/libexec/ld.so
#5 0x0446766d in dlopen () from /usr/libexec/ld.so
#6 0x0d731d54 in wine_dlopen (
filename=0x877dd14a /usr/local/lib/../lib/wine/ntdll.dll.so, flag=2,
error=0xcfbd5074 \224P½Ï, errorsize=1024) at loader.c:703
#7 0x0d731cb6 in wine_init (argc=16392, argv=0xcfbd5020,
error=0xcfbd5074 \224P½Ï, error_size=1024) at loader.c:655
#8 0x1c000f92 in ?? ()
#9 0x0002 in __stack_smash_handler ()
#10 0xcfbd54f0 in ?? ()
#11 0xcfbd5074 in ?? ()
#12 0x0400 in ?? ()
#13 0x3c00 in ?? ()
#14 0x0020 in __stack_smash_handler ()
#15 0x0030 in _dl_strdup ()
Cannot access memory at address 0x20
* I'm lost here.!
* util.c has a stack protector dummy...
void __stack_smash_handler(char [], int);
void
__stack_smash_handler(char func[], int damaged)
{
_dl_exit(127);
}
* _dl_exit is essentially (an asm wrapper for syscall) _exit(127)
* I don't know what to do now...except screaming for HLP.
Jacob Meuser-2 wrote:
On Sun, May 13, 2007 at 12:38:30AM +0200, Vortechz Anderson wrote:
wine-0.9.37 compiles on OpenBSD 4.1, except the dnsapi
Execution leads to segfault.
(Note: Generic kernel _has_ SYSV MSG/SHM/SEMand I
have not forgot sysctl machdep.userldt=1)
I know there are some issues about wine's use of
kernel threads on OpenBSD. I am clueless about the
true
problem though. If possible, I would like
some comments on the ktrace kdump.
looks familiar.
before you even get to problems with threads, you have problems
with wine wanting to control where things are located.
I've got a port of 0.9.10 that gets a little farther than
what you got here. loads libwine and libc, but cannot load
ntdll.dll.so.
try setting 'ac_cv_cflags__Wl___section_start__interp_0x7bf00400=no'
in your environment before running configure and see if that
gets you any farther.
definitely not a trivial port.
// V.A.
25268 ktrace RET ktrace 0
25268 ktrace CALL
execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8)
25268 ktrace NAMI /bin/wine
25268 ktrace RET execve -1 errno 2 No such file
or directory
25268 ktrace CALL
execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8)
25268 ktrace NAMI /sbin/wine
25268 ktrace RET execve -1 errno 2 No such file
or directory
25268 ktrace CALL
Re: Eclipse crashing
On Sunday 01 July 2007 11:38:44 pm Keith Richardson wrote: Hi, Eclipse was working fine for a while after initial install but now keeps on crashing on me randomly. It will start up fine and then, during some action (expanding a folder, build the application, etc...) it will crash. Attached is the crash log and a backtrace. I still have the core if anyone needs any more output from the resulting core. I am running 4.1-release and 4.1-stable ports. 4.1 was a clean install. From the information you provided (which was great) this appears to be a non-OpenBSD related hotspot crash. You could try the -current port which is now at update 11 srcs and might fix this for you. cd /usr/ports/devel/jdk; cvs -q up -PAd java.port.mk; cd 1.5; cvs -q up -PAd Disclaimer: using -current ports on -stable/-release is not supported, however this isolated case should work and at some point I may back-port the updates into -stable anyway. Let me know of any porting issues off list. -Kurt
Re: UPDATE: devel/boehm-gc (6.2 = 7.0)
On Sunday 15 July 2007 1:45:20 pm Benoit Chesneau wrote: I tested on cvs version with i386. I have no warning yet. Juste one thing why don't you use -DGC_OPENBSD_THREADS flag to enable use of pthread. It worked. Defining GC_OPENBSD_THREADS is not sufficient for enabling thread support in boehm. Use the configure arg --enable-threads=pthreads test thread support in boehm. Try a make regress and you will see the current show stopper. Find enclosed last version of boehm-gc 6.8 I was worked before new port for 7.0 was published. It contain more patching about it. I didn't have time yet to put them in 7.0 Hope it could help. I reviewed the patches in 6.8. I suspect thread support was not fully enabled when you tested it. There's nothing in the patches to get past the stop world deadlocks that happen when thread support is properly enabled. Other patches are incorrect such as the SIGRTMIN/MAX bit. Userland pthreads has limitations. Conceptually it sits between the program and the kernel and simulates actual threads. It does this by doing things like converting all file descriptors to non-blocking and managing all blocking operations. For signals it manages signal masks, intercepts signal delivery and manages the delivery of the singals to the threads. There are cases where pthreads defers delivery of a signal to a thread because interrupting the current operation would be bad. boehm uses signals to interrupt threads, grab the current stack pointer and put them to sleep in the signal handler using sigsupend(). So when a thread is in a state where the signal is deferred the process deadlocks. There's no good work-around for this problem. Thread support for boehm-gc will need to wait for rthreads (real kernel supported threads). One last thing to note. If you attempt to use non-threaded boehm-gc in a threaded program, expect failures ranging from immediate deadlock to crashes since only the main thread will be garbage collected without locking. -Kurt
Re: UPDATE: devel/gettext 0.16.1
On Wednesday 01 August 2007 12:12:15 pm Christian Weisgerber wrote: If anybody remembers what the static const struct - static struct patches were for, let me know. IIRC, gcc on alpha was generating relocations in read only segments and causing ld.so to segfault. I'm not sure if this is still needed for alpha or not. I think subversion also had this issue on alpha too. -Kurt
Re: www/minimo: shlibsign core dump
On Wednesday 08 March 2006 10:11 pm, Peter Valchev wrote:
While trying to build www/minimo on amd64 -current
shlibsign coredumps.
..
This is caused by patch-nsprpub_pr_src_misc_prdtoa_c which I
added in order to fix a similar crash on Zaurus. The patch
ripped out the mozilla implementation of strtod(3) with the
one taken directly from our libc. I have no clue why this
broke amd64 and have not figured it out yet. Feel free to
hack at it.
freedtoa should be removed since our strtod(3) dtoa
implementation uses a static var to handle result
allocation, but doesn't always return that. Also since
static vars are in use in places, I added back in
the locks to protect them and added one more to
protect the dtoa return value too.
This fixes the build on sparc64 for me and I expect
it should help stability elsewhere too.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/www/minimo/Makefile,v
retrieving revision 1.17
diff -u -r1.17 Makefile
--- Makefile 27 Mar 2006 04:23:29 - 1.17
+++ Makefile 19 Apr 2006 21:44:57 -
@@ -5,7 +5,7 @@
COMMENT= mini mozilla
DISTNAME= minimo-20050802
-PKGNAME= ${DISTNAME}p6
+PKGNAME= ${DISTNAME}p7
SO_VERSION= 2.0
# NOTE: Must bump minor version if any shlib's are removed from the
# components dir to avoid pkg_add -r issues.
Index: patches/patch-nsprpub_pr_src_misc_prdtoa_c
===
RCS file: /cvs/ports/www/minimo/patches/patch-nsprpub_pr_src_misc_prdtoa_c,v
retrieving revision 1.2
diff -u -r1.2 patch-nsprpub_pr_src_misc_prdtoa_c
--- patches/patch-nsprpub_pr_src_misc_prdtoa_c 5 Feb 2006 02:39:18 - 1.2
+++ patches/patch-nsprpub_pr_src_misc_prdtoa_c 19 Apr 2006 21:44:57 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-nsprpub_pr_src_misc_prdtoa_c,v 1.2 2006/02/05 02:39:18 pvalchev Exp $
nsprpub/pr/src/misc/prdtoa.c.orig Tue Apr 27 18:34:07 2004
-+++ nsprpub/pr/src/misc/prdtoa.c Sat Feb 4 18:47:53 2006
+--- nsprpub/pr/src/misc/prdtoa.c.orig Tue Apr 27 20:34:07 2004
nsprpub/pr/src/misc/prdtoa.c Wed Apr 19 17:24:23 2006
@@ -1,82 +1,8 @@
-/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
-/* * BEGIN LICENSE BLOCK *
@@ -166,7 +166,7 @@
* #define KR_headers for old-style C function headers.
* #define Bad_float_h if your system lacks a float.h or if it does not
* define some or all of DBL_DIG, DBL_MAX_10_EXP, DBL_MAX_EXP,
-@@ -175,89 +87,82 @@ void _PR_CleanupDtoa(void)
+@@ -175,89 +87,85 @@ void _PR_CleanupDtoa(void)
* if memory is available and otherwise does something you deem
* appropriate. If MALLOC is undefined, malloc will be invoked
* directly -- and assumed always to succeed.
@@ -247,12 +247,13 @@
+#define ACQUIRE_DTOA_LOCK(n)PR_Lock(dtoa_lock[n])
+#define FREE_DTOA_LOCK(n) PR_Unlock(dtoa_lock[n])
+
-+static PRLock *dtoa_lock[2];
++static PRLock *dtoa_lock[3];
+
+void _PR_InitDtoa(void)
+{
+dtoa_lock[0] = PR_NewLock();
+dtoa_lock[1] = PR_NewLock();
++dtoa_lock[2] = PR_NewLock();
+}
+
+void _PR_CleanupDtoa(void)
@@ -261,6 +262,8 @@
+dtoa_lock[0] = NULL;
+PR_DestroyLock(dtoa_lock[1]);
+dtoa_lock[1] = NULL;
++PR_DestroyLock(dtoa_lock[2]);
++dtoa_lock[2] = NULL;
+
+/* FIXME: deal with freelist and p5s. */
+}
@@ -318,7 +321,7 @@
#ifdef MALLOC
#ifdef KR_headers
-@@ -269,42 +174,32 @@ extern void *MALLOC(size_t);
+@@ -269,42 +177,32 @@ extern void *MALLOC(size_t);
#define MALLOC malloc
#endif
@@ -373,7 +376,7 @@
#define DBL_MAX 7.2370055773322621e+75
#endif
-@@ -313,27 +208,16 @@ static double private_mem[PRIVATE_mem],
+@@ -313,27 +211,16 @@ static double private_mem[PRIVATE_mem],
#define DBL_MAX_10_EXP 38
#define DBL_MAX_EXP 127
#define FLT_RADIX 2
@@ -403,7 +406,7 @@
#ifndef __MATH_H__
#include math.h
#endif
-@@ -350,37 +234,43 @@ extern C {
+@@ -350,37 +237,43 @@ extern C {
#endif
#endif
@@ -464,7 +467,7 @@
#define Storeinc(a,b,c) (((unsigned short *)a)[1] = (unsigned short)b, \
((unsigned short *)a)[0] = (unsigned short)c, a++)
#else
-@@ -394,7 +284,7 @@ typedef union { double d; ULong L[2]; }
+@@ -394,7 +287,7 @@ typedef union { double d; ULong L[2]; }
/* Quick_max = floor((P-1)*log(FLT_RADIX)/log(10) - 1) */
/* Int_max = floor(P*log(FLT_RADIX)/log(10) - 1) */
@@ -473,7 +476,7 @@
#define Exp_shift 20
#define Exp_shift1 20
#define Exp_msk10x10
-@@ -402,6 +292,7 @@ typedef union { double d; ULong L[2]; }
+@@ -402,6 +295,7 @@ typedef union { double d; ULong L[2]; }
#define Exp_mask 0x7ff0
#define P 53
#define Bias 1023
@@ -481,7 +484,7 @@
#define Emin (-1022)
#define Exp_1 0x3ff0
#define Exp_11 0x3ff0
-@@ -419,38 +310,11 @@ typedef union { double d; ULong L[2]; }
+@@ -419,38 +313,11 @@ typedef union { double d; ULong L[2]; }
#define Tiny1 1
#define Quick_max 14
#define Int_max 14
@@ -521,7 +524,7 @@
#define
Re: Java Binaries
On Thursday 20 April 2006 8:12 am, Edd Barrett wrote: Hi, One of my friends recently pointed out that FreeBSD are distributing Java 5 binaries and actually are licensed to do so from Sun Microsystems! I'm not sure how long thats been happening, but has anyone made any effort to try to bag a similar agreement for OpenBSD? If not I am willing to give it a try (with the consent of the OBSD developers). I think have an email address of a Java Core developer I met at JavaUK06. There are two primary reasons why we will not be able to distribute java binaries: 1) Legal: The OpenBSD project is a collection of individuals. There is no legal entity associated with the project like a Foundation or non-profit org. That means there is no singal point of contact for Sun to contract with and shield the developers from liability. 2) Political: Even if #1 were solved, the binaries would come with a binary only license that is incompatible with the projects goals. On the other hand, I have applied as an individual to Sun's scholarship program to get access to the test kit for 1.5 (JCK). I was approved by the scholarship committee and now waiting on Sun to get them. -Kurt
Re: Java Binaries
On Thursday 20 April 2006 11:34 am, Hannah Schroeter wrote: On Thu, Apr 20, 2006 at 09:32:52AM -0400, Kurt Miller wrote: On Thursday 20 April 2006 8:12 am, Edd Barrett wrote: One of my friends recently pointed out that FreeBSD are distributing Java 5 binaries and actually are licensed to do so from Sun Microsystems! I'm not sure how long thats been happening, but has anyone made any effort to try to bag a similar agreement for OpenBSD? If not I am willing to give it a try (with the consent of the OBSD developers). I think have an email address of a Java Core developer I met at JavaUK06. There are two primary reasons why we will not be able to distribute java binaries: 1) Legal: The OpenBSD project is a collection of individuals. There is no legal entity associated with the project like a Foundation or non-profit org. That means there is no singal point of contact for Sun to contract with and shield the developers from liability. 2) Political: Even if #1 were solved, the binaries would come with a binary only license that is incompatible with the projects goals. IIRC the project goals mostly apply to base, while the rules for licencing in ports/packages are less strict. E.g. no new GPL stuff in base, but new GPL ports/packages are ok. Even more restrictive licences are accepted, e.g. in textproc/glimpse, where OpenBSD mirrors distfiles and distributes packages via ftp (but not on CDs because of the licence conditions). Sorry. I wasn't too clear about that. The binaries are only distributeable via a click through license that would need to be hosted somewhere. Hosting that click through license on the project web site is what I was referring to. The binary would not be able to be mirrored too. On the other hand, I have applied as an individual to Sun's scholarship program to get access to the test kit for 1.5 (JCK). I was approved by the scholarship committee and now waiting on Sun to get them. Do you know without having to check whether it'd be possible for an individual to obtain such a licence from Sun and distribute inofficial (wrt the OpenBSD project) Java packages then? Or would that bee too risky from a legal POV? I wouldn't put my assets (house, retirement, etc) at risk to lawsuits from Sun or users of the binaries. I don't think anyone would really want to do that. -Kurt
Re: UPDATE+FIX: graphics/cairo
On Monday 27 March 2006 7:39 am, Eric Faurot wrote:
Hi all,
Here is a diff -N -u updating cairo to 1.0.4.
The diff didn't apply cleanly. I've attached a working
one in case anyone else would like to try.
More importantly, I have written a (rather simple) workaround to
support PseudoColor and StaticColor modes on X11. It is not too fast,
especially on a remote display, but at least it does not crash (I
hope). It should even produce reasonnable output, provided that
colormaps are not changed too much after the first calls to cairo
drawing functions. It might even work on StaticGray/GrayScale
displays.
I have tested it on macppc with both wscons and ati drivers, with
local server, through ssh -X and ssh -Y. Sample code for testing
can be found at:
http://webcvs.cairographics.org/cairo-demo/X11/
Please test and report, especially those who are stuck with 8 bit
displays. I do not plan to write something more complicated/efficient
for now. So, if someone is interested in improving that fix, please do
so.
Thanks for writing a fix for the lack of PseudoColor and
StaticColor support in cairo. I tried it and it does fix
the segfault and seems to work well enough. I think your
update should go in. Anyone see a reason why it shouldn't?
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/graphics/cairo/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile 10 Jan 2006 08:59:16 - 1.5
+++ Makefile 28 Apr 2006 17:02:04 -
@@ -2,9 +2,9 @@
COMMENT= vector graphics library
-PKGNAME= ${DISTNAME}p0
-DISTNAME= cairo-1.0.2
-SHARED_LIBS= cairo 4.3
+PKGNAME= ${DISTNAME}
+DISTNAME= cairo-1.0.4
+SHARED_LIBS= cairo 4.4
CATEGORIES= graphics
HOMEPAGE= http://cairographics.org/introduction
Index: distinfo
===
RCS file: /cvs/ports/graphics/cairo/distinfo,v
retrieving revision 1.2
diff -u -r1.2 distinfo
--- distinfo 4 Nov 2005 01:12:58 - 1.2
+++ distinfo 28 Apr 2006 17:02:04 -
@@ -1,4 +1,4 @@
-MD5 (cairo-1.0.2.tar.gz) = d0b7111a14f90ec3afa777ec40c44984
-RMD160 (cairo-1.0.2.tar.gz) = 59f309974fdac86253ed9a4d00e564a2fac310eb
-SHA1 (cairo-1.0.2.tar.gz) = 3a425049499b0b067ed4dc60d94b4d0819c0841b
-SIZE (cairo-1.0.2.tar.gz) = 1458903
+MD5 (cairo-1.0.4.tar.gz) = 9002b0e69b3f94831a22d3f2a7735ce2
+RMD160 (cairo-1.0.4.tar.gz) = 40403971bcb6ed9cd4379e8e13a52f515db886cb
+SHA1 (cairo-1.0.4.tar.gz) = 89e72202e5b51a8914fce60f52f7c51ecdea982a
+SIZE (cairo-1.0.4.tar.gz) = 1475777
Index: patches/patch-cairo_pc_in
===
RCS file: /cvs/ports/graphics/cairo/patches/patch-cairo_pc_in,v
retrieving revision 1.1
diff -u -r1.1 patch-cairo_pc_in
--- patches/patch-cairo_pc_in 10 Jan 2006 08:59:17 - 1.1
+++ patches/patch-cairo_pc_in 28 Apr 2006 17:02:04 -
@@ -1,7 +1,7 @@
-$OpenBSD: patch-cairo_pc_in,v 1.1 2006/01/10 08:59:17 matthieu Exp $
cairo.pc.orig Thu Aug 18 00:57:45 2005
-+++ cairo.pc.in Mon Jan 2 22:51:03 2006
-@@ -8,5 +8,5 @@
+$OpenBSD$
+--- cairo.pc.in.orig Tue Mar 14 03:08:44 2006
cairo.pc.in Thu Mar 23 14:27:36 2006
+@@ -8,5 +8,5 @@ Description: Multi-platform 2D graphics
Version: @VERSION@
@PKGCONFIG_REQUIRES@: @FREETYPE_REQUIRES@ @XRENDER_REQUIRES@ @PNG_REQUIRES@ @GLITZ_REQUIRES@
Index: patches/patch-configure
===
RCS file: /cvs/ports/graphics/cairo/patches/patch-configure,v
retrieving revision 1.2
diff -u -r1.2 patch-configure
--- patches/patch-configure 4 Nov 2005 01:12:58 - 1.2
+++ patches/patch-configure 28 Apr 2006 17:02:04 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-configure,v 1.2 2005/11/04 01:12:58 naddy Exp $
configure.orig Tue Oct 4 02:48:32 2005
-+++ configure Fri Nov 4 01:35:40 2005
-@@ -24143,7 +24143,8 @@ fi;
+--- configure.orig Wed Mar 15 20:04:32 2006
configure Thu Mar 23 14:27:36 2006
+@@ -23996,7 +23996,8 @@ fi;
if test x$use_png = xyes; then
use_png=no
# libpng13 is GnuWin32's libpng-1.2.8 :-(
Index: patches/patch-src_cairo-xlib-surface_c
===
RCS file: patches/patch-src_cairo-xlib-surface_c
diff -N patches/patch-src_cairo-xlib-surface_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_cairo-xlib-surface_c 28 Apr 2006 17:02:04 -
@@ -0,0 +1,383 @@
+$OpenBSD$
+--- src/cairo-xlib-surface.c.orig Wed Mar 15 16:26:51 2006
src/cairo-xlib-surface.c Sun Mar 26 21:00:36 2006
+@@ -72,6 +72,8 @@ _native_byte_order_lsb (void);
+
+ #define CAIRO_ASSUME_PIXMAP 20
+
++struct clut_r3g3b2;
++
+ struct _cairo_xlib_surface {
+ cairo_surface_t base;
+
+@@ -117,6 +119,9 @@ struct _cairo_xlib_surface {
+ int num_clip_rects;
+
+ XRenderPictFormat *format;
++
++struct clut_r3g3b2 *clut;
++
+ };
+
+ #define CAIRO_SURFACE_RENDER_AT_LEAST(surface, major, minor) \
+@@ -416,6 +421,160 @@
Re: jdk 1.5 charset patch
Ok I see what's happening now. KOI8_U strikes again but this time its related to the new bootstrap method. It works for me because the last time I built the jdk was with native_bootstrap. I'll work on a proper solution. -Kurt
Re: Java ports: source vs. binary?
On Thursday 20 July 2006 12:12 pm, you wrote: We need some sort of policy how to deal with software written in Java. We have a number of ports that are basically just wrappers that install pre-compiled Java byte code. Additional ports in this style have been proposed. Actual Java source may or may not be available, but it is certainly not used by the ports in question. All the ports I maintain have src available. IFAIK all java ports have src available. There have been various replies to this thread that assume otherwise but please take a moment to look first. Please stop continuing this FUD. Some people--Marc Balmer has been very outspoken--dislike this approach, because we are just wrapping other people's binaries. Lets be clear here, these are java byte-code binaries that run inside the jvm. No native executable is installed from a third party. Instead, ports should fetch the source and newly compile the code. The counter argument from the Java people is that Java byte code is machine-independent, compiling it afresh will just produce the very same binaries, adding build time for no gain. An additional complication is that passing around binary archives seems well-accepted in the Java scene, posing problems of obtaining the actual source code and exploding dependency requirements. It is not a matter of accessing the source code. It is a matter of trust, build time and unnecessary complications to porting new java programs to OpenBSD. Take tomcat for example. Apache has been distributing this for many many years. There are no native componets to tomcat. Pure java byte-code. The same byte-code runs on Windows, Linux, Solaris, *BSD, etc. etc. The whole world trusts the byte code released by Apache. Why should we not? If we convert tomcat/v4 to build from src for example, there will be a *significant* increase in package build time on arm and sparc especially. Currenly devel/jdk/1.3 doesn't even need to be built by bulk package builders to package tomcat/v4. Building tomcat from src in ports will add unnecessary complications of exploding the number of dependencies. For what gain? How are we going to deal with this? Some preliminary discussion at the last hackathon produced the opinion that even Java ports should be built from source by all means. However, that discussion didn't include any of our porters who are interested in Java... The source requirement may render various ports impossible or impracticably difficult. We'll need to decide whether we put our foot down here. For the last few years, java on OpenBSD has been mostly a one man show. I was hoping by now there would be more involvement from other folks. If we take what I consider to be an unreasonable stance on this we might as well delete all the java ports because who is going to do the work and maintain it all? I certainly cant. -Kurt
Re: Java ports: source vs. binary?
Some preliminary discussion at the last hackathon produced the opinion that even Java ports should be built from source by all means. That is the root of this debate - built from source by all means. We don't have this now in the ports tree so please don't selectively apply this rule to java ports. There is a point at which building from source does not make sense or the benefits don't outweigh the effort to make it happen. While it has been pointed out that java ports can be built on fast architectures and shared with the slower archs. The realities of how java applications are built are being ignored. It is common practice for a project to include components in full from other projects by way of incorporating jar files. Let's expore this phenomena with just Eclipse and Tomcat. We build Eclipse from source, but a closer look at what you get from the source distfile reveals that a full copy of tomcat binaries (jar files) is included along with ant, junit, lucene and more. The included versions of tomcat and junit don't match our ports of these. Should we take the time to hack out these included components and force them to be built from source or to use our ports versions? What exactly do we gain by that and who is going to the work and maintain it? Continuing the analysis with Tomcat we will see that things are sightly different here but a PITA for other reasons. Let's ignore for a moment any included jar files and take a look at the release notes for the three versions of Tomcat we have. There you will find an assortment of common dependencies with different version requirements. So shall we make multiple ports of these dependencies just so that we can produce the same byte-code all over again? Oh yea and who is volunteering do all that useless busy work? I think it is time that we accept reality of the common practices of how java software is made and adapt to it. Trying to force the common practices of how C applications are built on java applications does not make sense. A few years ago I took it upon myself to get java running on OpenBSD as well as other operating systems. Now that that goal is comming to fution must I and other java oriented developers jump through flaming hoops just to port java applications to OpenBSD? -Kurt
Re: Java ports: source vs. binary?
PORTS WITH NATIVE DEPENDENCIES == Ports that require native platform support are a different matter. Right now we have explicit ports dependencies on the Sun JDK tool chain in the ports that are built from source. With respect to building packages from source the most compatiable JDK is selected (Sun's). I don't intend to change that or add flavors to have them built from open-source JDK's. This creates an a problem for *alternative* tool chains. For example, after some fumbling around I can fake out our Eclipse package, which has explicit dependencies on the Sun JDK, and run it on classpath, jamvm, and cacao. Ian and I have been working on this recently. Our intent to to expand the RUN_DEPENDS in java.port.mk to allow alternative tool chains to be used to run applications. To the best of my knowledge there is not way way to tell the ports system make sure a 1.4.2 JVM is installed. (This would be a categorical dependency, rather than a dependency on a specific version or series of versions.) The good news is that our JDK built binaries are perfectly compatible with these alternative tools. (The FUD about compatibility issues is just that.) There is no reason why I should have to hack a package to use its native binaries and jars. Tool chain dependencies are the most significant issue in my opinion. In addition to expanding RUN_DEPENDS we also working on unifying java application startup scripts so that things just work for the alternative jvms too. I'm not sure if these things will make it for 4.0 yet. -Kurt
Re: lang/scheme48 new port, request for assistance
On Saturday 22 July 2006 7:44 pm, Aaron W. Hsu wrote: ... Basically, Scheme allows external C libraries to access the scheme48vm's internal C structures through a scheme48.h header file. One such program (http://magic.xmog.com) is using a postgresql.c wrapper file to provide special wrappers to my Scheme programs. In doing so, it utilizes some of the internal structures (functions, variables, etc.) declared in scheme48.h. However, when I load this software (further instructions on reproducing the exact error are below), and run the proper commands, the program faults out (segfault) giving me errors that it cannot find the functions internal to scheme48vm It sounds like you need to link the executable with -Wl,-E. Read man 1 ld -E option to understand why. -Kurt
Re: [SOLVED] Re: lang/scheme48 new port, request for assistance
Aaron W. Hsu wrote: On Thu, Jul 27, 2006 at 09:07:09AM -0400, Kurt Miller wrote: On Saturday 22 July 2006 7:44 pm, Aaron W. Hsu wrote: ... Basically, Scheme allows external C libraries to access the scheme48vm's internal C structures through a scheme48.h header file. One such program (http://magic.xmog.com) is using a postgresql.c wrapper file to provide special wrappers to my Scheme programs. In doing so, it utilizes some of the internal structures (functions, variables, etc.) declared in scheme48.h. However, when I load this software (further instructions on reproducing the exact error are below), and run the proper commands, the program faults out (segfault) giving me errors that it cannot find the functions internal to scheme48vm It sounds like you need to link the executable with -Wl,-E. Read man 1 ld -E option to understand why. Yes, this problem was solved thanks to some help at [EMAIL PROTECTED] That was the issue. This has been fixed when I submitted the port more officially to the list. In the end, it boiled down to LDFLAGS=-Wl,--export-dynamic. Ahh good. I missed that you fixed it already - behind on my emails. -Kurt
Re: new: www/jakarta-tomcat/v5.5
On Thursday 03 August 2006 4:57 pm, Matt Jibson wrote: This is a copy of the tomcat v5 port with changes for 5.5. A notable change from the v5 port that should be considered for the v5 port is that there were some configuration files that were installed with the -examples package, but the contexts were installed with the base package. These have been moved to the base PLIST: Catalina/localhost/admin.xml Catalina/localhost/host-manager.xml Catalina/localhost/manager.xml Thanks for the update. It came too close to the lock to get this in for 4.0, but I'll get this in when the tree unlocks. Send me a reminder if I forget. My feeling is that we don't need a v5 and a v5.5 tomcat port. IIRC, the 5.0.X series isn't getting bug fixes, just the 5.5.x series. -Kurt
Re: xmame fails package creation on macppc
On Monday 14 August 2006 5:06 pm, Matthias Kilian wrote:
Linking xmame.x11 ...
[...]
/usr/lib/crt0.o(.text+0x58): In function `_start':
: relocation truncated to fit: R_PPC_REL24 exit
/usr/lib/crtbegin.o(.text+0x134): In function `__register_frame_info':
: relocation truncated to fit: R_PPC_REL24 atexit
xmame.obj/artwork.o(.text+0x4d0): In function `artwork_create_display':
: relocation truncated to fit: R_PPC_REL24 memset
xmame.obj/artwork.o(.text+0x1668): In function `artwork_show':
: relocation truncated to fit: R_PPC_REL24 strcmp
xmame.obj/artwork.o(.text+0x4dac): In function `artwork_load_artwork_file':
: relocation truncated to fit: R_PPC_REL24 __stack_smash_handler
xmame.obj/artwork.o(.text+0x4dd0): In function `artwork_load_artwork_file':
: relocation truncated to fit: R_PPC_REL24 sprintf
xmame.obj/artwork.o(.text+0x5120): In function `open_and_read_png':
: relocation truncated to fit: R_PPC_REL24 free
xmame.obj/artwork.o(.text+0x5280): In function `load_bitmap':
: relocation truncated to fit: R_PPC_REL24 free
xmame.obj/artwork.o(.text+0x54f0): In function `load_bitmap':
: relocation truncated to fit: R_PPC_REL24 free
xmame.obj/artwork.o(.text+0x55f0): In function `load_alpha_bitmap':
: relocation truncated to fit: R_PPC_REL24 free
xmame.obj/artwork.o(.text+0x5838): In function `load_alpha_bitmap':
: additional relocation overflows omitted from the output
gmake[1]: *** [xmame.x11] Error 1
This is because the resulting executable is too large for
the 24bit offsets in the branch instruction on macppc.
Using -Wl,--relax will fix this.
Wasn't there something similar some weeks ago?
Yea that was sane-backends - it was the same problem but
in that case it was caused by a bug in the code instead
of it actually being too big.
Here's the update to get xmame to build on macppc:
Index: Makefile
===
RCS file: /cvs/ports/emulators/xmame/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- Makefile6 Jun 2006 09:23:16 - 1.23
+++ Makefile15 Aug 2006 22:48:39 -
@@ -7,9 +7,9 @@
VERSION= 0.104
DISTNAME= xmame-${VERSION}
-PKGNAME= xmame+xmess-${VERSION}
-PKGNAME-mame= xmame-${VERSION}
-PKGNAME-mess= xmess-${VERSION}
+PKGNAME= xmame+xmess-${VERSION}p0
+PKGNAME-mame= xmame-${VERSION}p0
+PKGNAME-mess= xmess-${VERSION}p0
CATEGORIES=emulators games
MASTER_SITES= ${HOMEPAGE}/download/ \
@@ -100,6 +100,10 @@
.elif ${MACHINE_ARCH} == hppa || ${MACHINE_ARCH} == powerpc || \
${MACHINE_ARCH} == sparc
MAKE_FLAGS+= MY_CPU=risc
+.endif
+
+.if ${MACHINE_ARCH} == powerpc
+MAKE_FLAGS+= LD=${CC} -Wl,-s,--relax
.endif
LIB_DEPENDS+= expat::textproc/expat
Re: gstreamer gst-register dumps core
Since we don't record libstdc++ as NEEDED in shared
libs, it can cause issues when one is dlopen()'ed that
requires it. Both gstreamer-arts and gstreamer-sidplay
plugins are dlopen() and depend on libs that need
libstdc++ so I think the best way to deal with this
is to have them explicitly link in libstdc++.
Also fix an extra pthread WANTLIB on the dvdnav plugin.
Index: Makefile
===
RCS file: /cvs/ports/devel/gstreamer-plugins/Makefile,v
retrieving revision 1.17
diff -u -r1.17 Makefile
--- Makefile10 Aug 2006 22:30:48 - 1.17
+++ Makefile16 Aug 2006 21:56:17 -
@@ -5,7 +5,7 @@
VERSION= 0.8.11
PATCHLEVEL=
DISTNAME= gst-plugins-${VERSION}
-PKGNAME= gstreamer-plugins-${VERSION}p7
+PKGNAME= gstreamer-plugins-${VERSION}p8
SHARED_LIBS= gstgconf-0.81.0 \
gstinterfaces-0.8 1.0 \
gstmedia-info-0.8 1.0 \
@@ -94,7 +94,7 @@
# arts
COMMENT-arts= GStreamer plugin for interfacing with KDE arts
WANTLIB-arts= vorbis vorbisenc pthread audiofile ossaudio mad ogg \
- esd vorbisfile
+ esd vorbisfile stdc++
DEPENDS-arts= artsflow,mcop,artsflow_idl,artsc::x11/kde/arts3
OPTIONS-arts= arts artsc
@@ -115,7 +115,6 @@
COMMENT-dvdnav=GStreamer plugin for DVD playback with menus
DEPENDS-dvdnav=dvdnav::multimedia/libdvdnav \
dvdread::devel/libdvdread
-WANTLIB-dvdnav=pthread
# dvdreadsrc
COMMENT-dvdread= GStreamer plugin for DVD playback
@@ -190,6 +189,7 @@
# sidplay
COMMENT-sidplay= GStreamer plugin for playing SID files
+WANTLIB-sidplay= stdc++
DEPENDS-sidplay= sidplay::audio/libsidplay
# sndfile
@@ -216,7 +216,7 @@
.for PLUGIN in ${PLUGINS}
COMMENT-${PLUGIN}?=GStreamer plugin for ${PLUGIN}
-PKGNAME-${PLUGIN}?=gstreamer-${PLUGIN}-${VERSION}${PATCHLEVEL}p7
+PKGNAME-${PLUGIN}?=gstreamer-${PLUGIN}-${VERSION}${PATCHLEVEL}p8
OPTIONS-${PLUGIN}?=${PLUGIN}
. if defined(PACKAGING)
.if ${SUBPACKAGE} == -${PLUGIN}
Index: patches/patch-configure
===
RCS file: /cvs/ports/devel/gstreamer-plugins/patches/patch-configure,v
retrieving revision 1.5
diff -u -r1.5 patch-configure
--- patches/patch-configure 20 Mar 2006 15:33:21 - 1.5
+++ patches/patch-configure 16 Aug 2006 21:56:17 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-configure,v 1.5 2006/03/20 15:33:21 espie Exp $
configure.orig Sun Sep 4 14:21:34 2005
-+++ configure Mon Mar 20 16:28:55 2006
+--- configure.orig Sun Sep 4 08:21:34 2005
configure Wed Aug 16 17:24:06 2006
@@ -28114,7 +28114,7 @@ DEFAULT_AUDIOSRC=osssrc
DEFAULT_VIDEOSRC=v4lsrc
DEFAULT_VISUALIZER=goom
@@ -19,7 +19,15 @@
else
HAVE_XVIDEO=no
fi
-@@ -42153,7 +42153,7 @@ fi
+@@ -38321,6 +38321,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
+ if test x$no_arts = x ; then
+ echo $as_me:$LINENO: result: yes 5
+ echo ${ECHO_T}yes 6
++ARTS_LIBS=-lstdc++
+ HAVE_ARTS=yes
+ else
+ echo $as_me:$LINENO: result: no 5
+@@ -42153,7 +42154,7 @@ fi
DVDNAV_CFLAGS=
HAVE_DVDNAV=no
else
@@ -28,3 +36,12 @@
DVDNAV_LIBS=`dvdnav-config --plugin-libs `
else
DVDNAV_LIBS=`dvdnav-config --libs `
+@@ -53328,7 +53329,7 @@ echo ${ECHO_T}$HAVE_SIDPLAY 6
+ fi
+
+ SIDPLAY_CFLAGS=
+-SIDPLAY_LIBS=-lsidplay
++SIDPLAY_LIBS=-lsidplay -lstdc++
+
+
+
Re: Ports folder...
On Monday 28 August 2006 3:15 pm, Thorsten Glaser wrote: I hope people who want control back start using the MirPorts Framework. Can you stop advertising your fork of OpenBSD on our lists please? It is getting quite annoying and you've been asked before to stop.
Re: Trouble building jdk-1.5 on 4.0-beta
On Monday 21 August 2006 7:26 am, you wrote: Hi! I'm having some trouble compiling 1.5 jdk with the aug. 16 snapshots. It complains about missing ZoneInfoMappings. Details below. Any advice on how to proceed? Actually the missing ZoneInfoMappings is ok, but the NPE is not. It seems like its choking on your timezone setting. How is your timezone setup (i.e. /etc/localtime)? Is it a symlink or a copy of the timezone file and which one is it set to?
Re: Trouble building jdk-1.5 on 4.0-beta
On Tuesday 29 August 2006 7:35 am, Schöberle Dániel wrote:
# ls -l /etc/localtime
lrwxr-xr-x 1 root wheel 25 Aug 1 18:55 /etc/localtime -
/usr/share/zoneinfo/GMT+0
So it turns out that building the jdk while a system's
timezone is set to GMT offset 0 will cause this failure.
Here's an update to fix that case (for after unlock):
Index: Makefile
===
RCS file: /cvs/ports/devel/jdk/1.5/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- Makefile28 Jul 2006 13:18:45 - 1.23
+++ Makefile31 Aug 2006 13:47:25 -
@@ -6,8 +6,8 @@
COMMENT-jre= Java2(TM) Standard Edition Runtime Environment v${V}
V= 1.5.0
DISTNAME= jdk-1_5_0
-PKGNAME= jdk-${V}p19
-PKGNAME-jre= jre-${V}p19
+PKGNAME= jdk-${V}p20
+PKGNAME-jre= jre-${V}p20
CATEGORIES=devel/jdk java
Index: patches/patch-j2se_src_share_classes_java_util_TimeZone_java
===
RCS file: patches/patch-j2se_src_share_classes_java_util_TimeZone_java
diff -N patches/patch-j2se_src_share_classes_java_util_TimeZone_java
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-j2se_src_share_classes_java_util_TimeZone_java31 Aug
2006 13:47:26 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+--- j2se/src/share/classes/java/util/TimeZone.java.origWed Aug 30
13:18:08 2006
j2se/src/share/classes/java/util/TimeZone.java Wed Aug 30 13:19:26 2006
+@@ -748,15 +748,13 @@ abstract public class TimeZone implement
+ }
+ int gmtOffset = (hours * 60 + num) * 60 * 1000;
+
++ zi = ZoneInfoFile.getCustomTimeZone(id, negative ? -gmtOffset :
gmtOffset);
+ if (gmtOffset == 0) {
+- zi = ZoneInfoFile.getZoneInfo(GMT_ID);
+ if (negative) {
+ zi.setID(GMT-00:00);
+ } else {
+ zi.setID(GMT+00:00);
+ }
+- } else {
+- zi = ZoneInfoFile.getCustomTimeZone(id, negative ? -gmtOffset :
gmtOffset);
+ }
+ return zi;
+ }
Re: undefined*symbol*'pthread_* ' errors in gnome snapshot package
Thanks for the report. librsvg-2.9.5p5 is the package that is
failing in your report. It is failing because it has a shared lib
that is threaded which is dlopen()'ed by gdk-pixbuf-query-loaders
which is unthreaded. For this to work gdk-pixbuf-query-loaders
must be linked with -pthread.
This update differs from the one Mikolaj Kucharski posted
by only modifying gdk-pixbuf-query-loaders and should not
cause a WANTLIB ripple effect on ports that depend on gtk+2.
A similar patch exists in NetBSD's gtk+2 port.
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
retrieving revision 1.40
diff -u -r1.40 Makefile
--- Makefile10 Jul 2006 14:47:32 - 1.40
+++ Makefile1 Sep 2006 21:19:22 -
@@ -7,7 +7,7 @@
VERSION= 2.8.20
DISTNAME= gtk+-${VERSION}
-PKGNAME= gtk+2-${VERSION}
+PKGNAME= gtk+2-${VERSION}p0
PKGNAME-docs= gtk+2-docs-${VERSION}
CATEGORIES=x11 devel
@@ -32,7 +32,7 @@
.if ${SUBPACKAGE} != -docs
WANTLIB= X11 Xcursor Xext Xfixes Xi Xinerama Xrender \
- Xrandr c cairo fontconfig freetype glitz m z
+ Xrandr c cairo fontconfig freetype glitz m
pthread z
MODULES= devel/gettext
LIB_DEPENDS=
glib-2.0.1000.0,gmodule-2.0.1000.0,gobject-2.0.1000.0::devel/glib2 \
Index: patches/patch-gdk-pixbuf_Makefile_in
===
RCS file: /cvs/ports/x11/gtk+2/patches/patch-gdk-pixbuf_Makefile_in,v
retrieving revision 1.12
diff -u -r1.12 patch-gdk-pixbuf_Makefile_in
--- patches/patch-gdk-pixbuf_Makefile_in28 May 2006 10:07:25 -
1.12
+++ patches/patch-gdk-pixbuf_Makefile_in1 Sep 2006 21:19:22 -
@@ -1,6 +1,15 @@
$OpenBSD: patch-gdk-pixbuf_Makefile_in,v 1.12 2006/05/28 10:07:25 steven Exp $
gdk-pixbuf/Makefile.in.origFri Dec 9 13:28:12 2005
-+++ gdk-pixbuf/Makefile.in Sat May 13 16:59:37 2006
+--- gdk-pixbuf/Makefile.in.origSun Jul 2 09:57:38 2006
gdk-pixbuf/Makefile.in Fri Sep 1 16:16:21 2006
+@@ -526,7 +526,7 @@ gdk_pixbuf_csource_SOURCES = gdk-pixbuf-
+ gdk_pixbuf_csource_LDADD = $(LDADDS)
+
+ gdk_pixbuf_query_loaders_DEPENDENCIES = $(DEPS)
+-gdk_pixbuf_query_loaders_LDADD = $(LDADDS)
++gdk_pixbuf_query_loaders_LDADD = $(LDADDS) -pthread
+
+ gdk_pixbuf_query_loaders_SOURCES = queryloaders.c
+
@@ -1604,13 +1604,6 @@ install-data-hook: install-ms-lib instal
@if $(RUN_QUERY_LOADER_TEST) ; then \
$(mkinstalldirs) $(DESTDIR)$(sysconfdir)/gtk-2.0 ; \
Re: Unable to build jdk-1.4.2p7 on OpenBSD/i386 3.9-GENERIC
On Monday 04 September 2006 1:53 am, Bruno Carnazzi wrote: Hi misc, I can't build jdk-1.4.2p7 on my openbsd box (3.9 running in MS-VirtualServer)... Can somebody help ? jdk-1.3.1p6, jre-1.3.1p6 and jdk-linux-1.3.1_16 succeeded. ... if [ -r ./../../deploy/make/Makefile ]; then \ ( cd ./../../deploy/make; gmake sanity EXTERNALSANITYCONTROL=true CONTROL_TOPDIR=/usr/obj/ports/jdk-1.4.2p7/control CONTROL_TOPDIR_NAME=control ALT_OUTPUTD IR=/usr/obj/ports/jdk-1.4.2p7/control/build/bsd-i586 ARCH_DATA_MODEL=32 MILESTONE=p7 BUILD_NUMBER=_04_sep_2006_03_38 ALT_JAVAWS_BOOTDIR=/usr/obj/ports/jdk-1. 4.2p7/control/build/bsd-i586 ; ); \ fi Abort trap (core dumped) Abort trap (core dumped) What's core-dumping here? (i.e. find /usr/obj/ports/jdk-1.4.2p7 -name \*.core) Is this a restarted failed build? If so, please make clean and try again. Moved to ports@ where this belongs.
Re: tomcat update rename
On Thursday 05 October 2006 2:50 pm, Matt Jibson wrote: On 10/5/06, Kurt Miller [EMAIL PROTECTED] wrote: The Tomcat project is no longer called Jakarta-Tomcat so instead of a normal update (cvs diff) the attached is intended to be imported new under www/tomcat and www/jakarta-tomcat be removed. Both v4 and v5 have been updated. v4 - 4.1.34 (almost out of beta) and v5 to 5.1.20. The new versions contain a subpackage for the admin webapp so that can be optionally left out now. As before the examples subpackage contains the example webapps and docs that a production server would not install, but is handy for testing the other packages. Any comments or issues? Do you mean 5.5.20 instead of 5.1.20? Yup. I forgot the @pkgpath parts to deal with the name change so here's an updated version (I also tweaked MESSAGE and DESCR) -Kurt tomcat.tar.gz Description: application/tgz
Re: openoffice build issues: i386 -current
Hi Josh, On Tuesday 17 October 2006 8:36 am, Josh Grosse wrote: I've been having trouble building the OO port lately; my last successful build was 2.0.3m179p0. Are you by chance building on multiprocessor system? I've noticed similar issues and was about to revert the part of the port makefile that enables parallel builds. ... Looking through the build output for Error code I found that there were a set of failures to compile audio related modules, though the make continued on. The failed builds were: audispatch.c, auevents.c, auutil.c, auprocess.c, auvoxware.c, and Graph.c. I have patches comming for these. Thanks for the report. -Kurt
Re: openoffice build issues: i386 -current
On Tuesday 17 October 2006 11:21 am, Josh Grosse wrote: On Tue, Oct 17, 2006 at 10:48:07AM -0400, Kurt Miller wrote: Hi Josh, On Tuesday 17 October 2006 8:36 am, Josh Grosse wrote: I've been having trouble building the OO port lately; my last successful build was 2.0.3m179p0. Are you by chance building on multiprocessor system? I've noticed similar issues and was about to revert the part of the port makefile that enables parallel builds. No, it's a uniprocessor GENERIC + RaidFrame. Ok thanks. I assumed the problems were only with mp systems but I guess that's not it. It will need to be investigated. For now you can just continue the build if it fails mysteriously. I'll be committing what I have built up tonight or tomorrow but the build failures will likely continue until that's fixed. -Kurt
Re: OpenOffice, db, java
Fritz Elfert wrote: On Sunday 05 November 2006 10:03, viq wrote: db v4 seems to be hard coded to depend on java 1.3 (for the -java subpackage/flavor) OpenOffice wants java 1.4 or newer. It's nice to have a new java installed, and I already have 1.5 built and installed. Is there a way to have only one version of java installed, or if I want OpenOffice running I will have to have all 3 versions of java installed? Actually, *at runtime* OOo doesn't depend on java at all. It's just the RUN_DEPENDS in the Makefile. In my own port, i have left them out intentionally. At runtime, in Options/Java you then can configure a JVM (including parameters and classpath) of your choice. Note: WIthout java, some functionality will be missing. E.g. the Wizards. If you invoke a function which depends on java and it can't find a JVM, a messagebox will pop up. What you just described in your note is a java runtime dependency. So yes indeed OOo does have a runtime java that needs to be controlled. For example, I don't want people trying to run OOo with a pre p9 1.4 jdk that has internal libz in it. The runtime java depend is contained in the openoffice-java subpackage, so the base package doesn't require java. If you can demonstrate that some of the files contained in the PLIST-java or PFRAG-shared-java pkg lists can be used without java installed, I would be happy to move them into the base package. For example, I did that with the help file that require java to build but don't need java to run. @kurt: You probably should reconsider your recent change of dependencies. Even the system db4.jar should work nicely with a 1.5 JVM. Yes the current run depends for db-java allow the user to use any jdk or jre 1.3 and higher. There is no need to restrict that to 1.5 when 1.3 would work fine. It is ok that OOo needs a 1.4+ and higher jdk or jre and db-java is 1.3+. Its pretty simple. A user who wishes to run OOo java features can simply build and install any 1.4+ or higher jdk, then install the openoffice-java subpackage and all the runtime depends will be satisfied.
Re: OpenOffice, db, java
viq wrote: On 05/11/06, Robert Nagy [EMAIL PROTECTED] wrote: In the meantime I've had a discussion with Kurt and we are leaving the 1.3+ dependency. You mean db-java, right? Also, does this form of dependency, 1.3+, is going to accept 1.4 or 1.5, or it only means that both say 1.3.1 and 1.3.27 are going to work? So, for now it is going to stay that way: /usr/ports/editors/openoffice:123$ make full-all-depends | sort ... jasper-1.701.0p1 javaPathHelper-0.2p0 jdk-1.3.1p7 jdk-1.4.2p9 jdk-linux-1.3.1_16p0 jpeg-6bp3 ... ? We want to provide as much functionality as we can by default. Yup, I can certainly understand that. I guess what I'm asking is whether the same functionality can be achieved while having less than all possible versions of java installed on the system ;) If you are building ports you may get unexpected build depends. That's just the way it goes. Remember the goal is to create quality packages, not faster builds. Once db-java is available via snapshots, you can get away building OOo with just devel/jdk/1.4 by installing it before the db-java package.
[update] www/mozilla-firefox internal nspr - devel/nspr
Same reasoning as for minimo. patch -E recommended.
Please test. Thanks.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/www/mozilla-firefox/Makefile,v
retrieving revision 1.58
diff -u -r1.58 Makefile
--- Makefile 10 Nov 2006 14:15:49 - 1.58
+++ Makefile 10 Nov 2006 20:25:04 -
@@ -6,7 +6,7 @@
VER= 1.5.0.8
DISTNAME= mozilla
-PKGNAME= mozilla-firefox-${VER}
+PKGNAME= mozilla-firefox-${VER}p0
SO_VERSION= 16.0
# NOTE: Must bump minor version if any shlib's are removed from the
# components dir to avoid pkg_add -r issues.
@@ -14,8 +14,8 @@
browserdirprovider caps chrome commandlines composer cookie docshell \
editor embedcomponents fileview gfx_gtk gfxps gfxpsshar gkgfx \
gklayout gkplugin gtkembedmoz gtkxtbin htmlpars i18n imglib2 inspector \
- jar50 jsd jsj mork mozfind mozjs necko necko2 nsappshell nspr4 nss3 \
- nssckbi oji permissions pipboot pipnss pippki plc4 plds4 pref rdf \
+ jar50 jsd jsj mork mozfind mozjs necko necko2 nsappshell nss3 \
+ nssckbi oji permissions pipboot pipnss pippki pref rdf \
remoteservice searchservice smime3 softokn3 ssl3 system-pref \
toolkitcomps transformiix txmgr uconv ucvmath universalchardet \
webbrwsr websrvcs widget_gtk2 xmlextras xpcom xpcom_compat \
@@ -36,8 +36,7 @@
pthread z \
atk-1.0 cairo glib-2.0 gmodule-2.0 gobject-2.0 \
jpeg pango-1.0 pangocairo-1.0 \
- pangoft2-1.0 png
-WANTLIB+= stdc++
+ pangoft2-1.0 png stdc++
MASTER_SITES= http://ftp.eu.mozilla.org/pub/mozilla.org/firefox/releases/${VER}/source/ \
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/${VER}/source/
@@ -48,7 +47,8 @@
BUILD_DEPENDS= :libIDL-*:devel/libIDL \
:zip-=2.3:archivers/zip \
:pkgconfig-*:devel/pkgconfig
-LIB_DEPENDS= gdk-x11-2.0,gdk_pixbuf-2.0,gtk-x11-2.0::x11/gtk+2
+LIB_DEPENDS= gdk-x11-2.0,gdk_pixbuf-2.0,gtk-x11-2.0::x11/gtk+2 \
+ nspr4.=17,plc4.=17,plds4.=17::devel/nspr
VMEM_WARNING= Yes
@@ -58,16 +58,15 @@
NO_REGRESS= Yes
SUBST_VARS= LOCALBASE SO_VERSION
-MODGNU_CONFIG_GUESS_DIRS= ${WRKSRC}/build/autoconf \
-${WRKSRC}/nsprpub/build/autoconf
+MODGNU_CONFIG_GUESS_DIRS= ${WRKSRC}/build/autoconf
AUTOCONF_VERSION= 2.13
CONFIGURE_STYLE= autoconf no-autoheader
CONFIGURE_ARGS= --with-system-jpeg=${LOCALBASE} \
--with-system-png=${LOCALBASE} \
--with-system-zlib=/usr/lib \
+ --with-system-nspr \
--with-pthreads \
- --without-system-nspr \
--enable-xft \
--enable-optimize=-Os \
--enable-default-toolkit=gtk2 \
@@ -103,11 +102,9 @@
pre-configure:
@cd ${WRKSRC}/browser/base/branding/ cp aboutCredits.png about.png
- @cd ${WRKSRC}/nsprpub ${SETENV} ${AUTOCONF_ENV} ${AUTOCONF}
@perl -pi -e 's|_LOCALBASE_|${LOCALBASE}|g; s|_X11BASE_|${X11BASE}|g' \
${WRKSRC}/browser/app/mozilla.in
@perl -pi -e 's|_SO_VERSION_|${SO_VERSION}|g' \
- ${WRKSRC}/nsprpub/pr/include/md/_openbsd.h \
${WRKSRC}/xpcom/components/nsNativeComponentLoader.cpp
do-install:
Index: patches/patch-nsprpub_config_rules_mk
===
RCS file: patches/patch-nsprpub_config_rules_mk
diff -N patches/patch-nsprpub_config_rules_mk
--- patches/patch-nsprpub_config_rules_mk 5 May 2006 10:14:21 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-nsprpub_config_rules_mk,v 1.3 2006/05/05 10:14:21 bernd Exp $
nsprpub/config/rules.mk.orig Thu Feb 23 00:03:11 2006
-+++ nsprpub/config/rules.mk Wed May 3 13:25:55 2006
-@@ -232,7 +232,7 @@ ifdef RELEASE_HEADERS
- $(NSINSTALL) -t -m 0644 $(RELEASE_HEADERS) $(DESTDIR)$(includedir)/$(include_subdir)
- endif
- ifdef RELEASE_LIBS
-- $(NSINSTALL) -t -m 0755 $(RELEASE_LIBS) $(DESTDIR)$(libdir)/$(lib_subdir)
-+ $(NSINSTALL) -t -m 0444 $(RELEASE_LIBS) $(DESTDIR)$(libdir)/$(lib_subdir)
- endif
- +$(LOOP_OVER_DIRS)
-
Index: patches/patch-nsprpub_configure_in
===
RCS file: patches/patch-nsprpub_configure_in
diff -N patches/patch-nsprpub_configure_in
--- patches/patch-nsprpub_configure_in 5 May 2006 10:14:21 - 1.5
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-nsprpub_configure_in,v 1.5 2006/05/05 10:14:21 bernd Exp $
nsprpub/configure.in.orig Thu Feb 23 00:03:11 2006
-+++ nsprpub/configure.in Wed May 3 13:25:55 2006
-@@ -1704,9 +1704,11 @@ mips-sony-newsos*)
- AC_DEFINE(OPENBSD)
- AC_DEFINE(HAVE_BSD_FLOCK)
- AC_DEFINE(HAVE_SOCKLEN_T)
-+AC_DEFINE(_PR_HAVE_GETPROTO_R)
-+AC_DEFINE(_PR_HAVE_GETPROTO_R_INT)
- CFLAGS=$CFLAGS -ansi -Wall
- CXXFLAGS=$CXXFLAGS -ansi -Wall
--DLL_SUFFIX=so.1.0
-+DLL_SUFFIX=so.${SO_VERSION}
- DSO_CFLAGS=-fPIC
- MDCPUCFG_H=_openbsd.cfg
- PR_MD_CSRCS=openbsd.c
Index: patches/patch-nsprpub_pr_include_md__openbsd_h
===
RCS file: patches/patch-nsprpub_pr_include_md__openbsd_h
diff -N
[update] mail/mozilla-thunderbird internal nspr - devel/nspr
Same reasoning as for minimo. patch -E recommended.
Please test. Thanks.
-Kurt
(sorry if this comes through twice)
Index: Makefile
===
RCS file: /cvs/ports/mail/mozilla-thunderbird/Makefile,v
retrieving revision 1.45
diff -u -r1.45 Makefile
--- Makefile 10 Nov 2006 14:16:41 - 1.45
+++ Makefile 10 Nov 2006 20:48:17 -
@@ -6,7 +6,7 @@
VER= 1.5.0.8
DISTNAME= mozilla
-PKGNAME= mozilla-thunderbird-${VER}
+PKGNAME= mozilla-thunderbird-${VER}p0
SO_VERSION= 10.0
# NOTE: Must bump minor version if any shlib's are removed from the
# components dir to avoid pkg_add -r issues.
@@ -14,8 +14,8 @@
composer docshell editor embedcomponents fileview gfx_gtk gfxps \
gfxpsshar gkgfx gklayout gtkembedmoz gtkxtbin htmlpars i18n imglib2 \
import jar50 jsd ldap50 mail mailcomps mork mozfind mozjs mozldap \
- msgsmime myspell necko necko2 nsappshell nspr4 nss3 nssckbi pipboot \
- pipnss pippki plc4 plds4 pref prldap50 rdf remoteservice smime3 \
+ msgsmime myspell necko necko2 nsappshell nss3 nssckbi pipboot \
+ pipnss pippki pref prldap50 rdf remoteservice smime3 \
softokn3 spellchecker ssl3 system-pref toolkitcomps txmgr uconv \
universalchardet wallet walletviewers webbrwsr websrvcs widget_gtk2 \
xmlextras xpcom xpcom_compat xpcom_compat_c xpcom_core xpconnect \
@@ -34,8 +34,7 @@
PERMIT_DISTFILES_FTP= Yes
WANTLIB= X11 Xext Xft Xrender Xinerama Xt c fontconfig freetype m pthread z \
atk-1.0 cairo glib-2.0 gmodule-2.0 gobject-2.0 \
- jpeg pango-1.0 pangoft2-1.0 pangocairo-1.0 png
-WANTLIB+= stdc++
+ jpeg pango-1.0 pangoft2-1.0 pangocairo-1.0 png stdc++
MASTER_SITES= http://ftp.eu.mozilla.org/pub/mozilla.org/thunderbird/releases/${VER}/source/ \
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/${VER}/source/
@@ -46,7 +45,8 @@
BUILD_DEPENDS= :libIDL-*:devel/libIDL \
:zip-=2.3:archivers/zip \
:pkgconfig-*:devel/pkgconfig
-LIB_DEPENDS= gdk-x11-2.0,gdk_pixbuf-2.0,gtk-x11-2.0::x11/gtk+2
+LIB_DEPENDS= gdk-x11-2.0,gdk_pixbuf-2.0,gtk-x11-2.0::x11/gtk+2 \
+ nspr4.=17,plc4.=17,plds4.=17::devel/nspr
VMEM_WARNING= Yes
@@ -57,7 +57,6 @@
SUBST_VARS= LOCALBASE SO_VERSION
MODGNU_CONFIG_GUESS_DIRS= ${WRKSRC}/build/autoconf \
-${WRKSRC}/nsprpub/build/autoconf \
${WRKSRC}/directory/c-sdk/config/autoconf
AUTOCONF_VERSION= 2.13
@@ -65,8 +64,8 @@
CONFIGURE_ARGS= --with-system-jpeg=${LOCALBASE} \
--with-system-png=${LOCALBASE} \
--with-system-zlib=/usr/lib \
+ --with-system-nspr \
--with-pthreads \
- --without-system-nspr \
--enable-xft \
--enable-optimize=-Os \
--enable-default-toolkit=gtk2 \
Index: patches/patch-nsprpub_config_rules_mk
===
RCS file: patches/patch-nsprpub_config_rules_mk
diff -N patches/patch-nsprpub_config_rules_mk
--- patches/patch-nsprpub_config_rules_mk 2 Jul 2006 15:54:55 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-nsprpub_config_rules_mk,v 1.3 2006/07/02 15:54:55 steven Exp $
nsprpub/config/rules.mk.orig Thu Feb 23 00:03:11 2006
-+++ nsprpub/config/rules.mk Thu Jun 29 08:50:40 2006
-@@ -232,7 +232,7 @@ ifdef RELEASE_HEADERS
- $(NSINSTALL) -t -m 0644 $(RELEASE_HEADERS) $(DESTDIR)$(includedir)/$(include_subdir)
- endif
- ifdef RELEASE_LIBS
-- $(NSINSTALL) -t -m 0755 $(RELEASE_LIBS) $(DESTDIR)$(libdir)/$(lib_subdir)
-+ $(NSINSTALL) -t -m 0444 $(RELEASE_LIBS) $(DESTDIR)$(libdir)/$(lib_subdir)
- endif
- +$(LOOP_OVER_DIRS)
-
Index: patches/patch-nsprpub_configure_in
===
RCS file: patches/patch-nsprpub_configure_in
diff -N patches/patch-nsprpub_configure_in
--- patches/patch-nsprpub_configure_in 2 Jul 2006 15:54:55 - 1.6
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-nsprpub_configure_in,v 1.6 2006/07/02 15:54:55 steven Exp $
nsprpub/configure.in.orig Thu Feb 23 00:03:11 2006
-+++ nsprpub/configure.in Thu Jun 29 08:50:40 2006
-@@ -1704,9 +1704,11 @@ mips-sony-newsos*)
- AC_DEFINE(OPENBSD)
- AC_DEFINE(HAVE_BSD_FLOCK)
- AC_DEFINE(HAVE_SOCKLEN_T)
-+AC_DEFINE(_PR_HAVE_GETPROTO_R)
-+AC_DEFINE(_PR_HAVE_GETPROTO_R_INT)
- CFLAGS=$CFLAGS -ansi -Wall
- CXXFLAGS=$CXXFLAGS -ansi -Wall
--DLL_SUFFIX=so.1.0
-+DLL_SUFFIX=so.${SO_VERSION}
- DSO_CFLAGS=-fPIC
- MDCPUCFG_H=_openbsd.cfg
- PR_MD_CSRCS=openbsd.c
Index: patches/patch-nsprpub_pr_include_md__openbsd_h
===
RCS file: patches/patch-nsprpub_pr_include_md__openbsd_h
diff -N patches/patch-nsprpub_pr_include_md__openbsd_h
--- patches/patch-nsprpub_pr_include_md__openbsd_h 23 Jan 2006 12:34:06 - 1.6
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-nsprpub_pr_include_md__openbsd_h,v 1.6 2006/01/23 12:34:06 wilfried Exp $
nsprpub/pr/include/md/_openbsd.h.orig Wed Apr 28 02:33:44 2004
Re: java on openbsd
On Tuesday 14 November 2006 8:07 am, you wrote: However, whenever I run java, I get a Can't detect initial thread stack location - find_vma failed error. This is for sun's jdk 1.5.06 as well as one of the newer 1.6 versions. IBM's jdk1.4 says it cannot read or write (not sure exactly anymore) to /proc/. I've tried running all three versions as root to check for permission errors, but it makes no difference. I've googled for hours trying to find a solution, but can't seem to fix it. Our linux emulation doesn't support the features needed by linux jdk binaries (1.4 and up). Our native jdk's work quite well (especially devel/jdk/1.5) but you need to build from source. -Kurt
Re: NEW: www/mozilla-seamonkey 1.0.6
On Saturday 02 December 2006 2:46 pm, James Wright wrote: Nikolay Sturm wrote: * James Wright [2006-12-02]: latest -stable mozilla seamonkey (the next generation suite) version 1.0.6 (equivalent to the 1.5.0.8 releases of firefox/thunderbird), What is the point of this port? Is there anything genuine in seamonkey that is not in firefox and friends? Nikolay integrated chatzilla/composer/mail and news, no need to go through hoops to get firefox and thunderbird to work together, the same advantages the suite has but using the new rendering engine for 'modern' websites, same network layer. its really for people who used and got used to the suite but want to use it on modern websites and against newer servers. This should positioned as a replacement for the old mozilla suite (www/mozilla) with a -devel subpackage and updates to www/galeon and www/epiphany to use it. My next update to eclipse will be able to use seamonkey to build, so there's no need to update that. Actually I'm planning on adding a firefox -devel package at some point and switching eclipse over to use that instead. If you update your diff to include a -devel subpackage and create diffs for galeon and ephiphay to use it, I think this would be a worthwhile addition to the ports tree. -Kurt
Re: Enigmail Thunderbird: Enigmime Service not available
On Monday 18 December 2006 4:35 am, Stephan A. Rickauer wrote: When trying to sign messages in thunderbird, I'll get Enigmime Service not available. Failed to initialize Enigmail. on OpenBSD 4.0 Snapshot (2006-12-15), i386. enigmail-0.94.1 (installed as requested by install-message) mozilla-thunderbird-1.5.0.8p1 nspr-4.6.4p1 installed from [2] Is this a known issue? I've found [1] where someone got something similar, but thinks there are no enigmail or thunderbird packages - so probably irrelevant. Let me know if I can help any further. [1] http://marc.theaimsgroup.com/?l=openbsd-miscm=115797922208966w=2 [2] http://mirror.switch.ch/ftp/pub/OpenBSD/snapshots/packages/i386/ This is working for me with the same versions of the packages you listed. I built them myself instead of from snapshots though. AFAICT, system nss doesn't effect this. Have you tried some of the suggestions in the install message like creating a new profile? -Kurt
Re: Enigmail Thunderbird: Enigmime Service not available
On Tuesday 19 December 2006 3:05 am, Stephan A. Rickauer wrote: Kurt Miller wrote: This is working for me with the same versions of the packages you listed. I built them myself instead of from snapshots though. AFAICT, system nss doesn't effect this. Have you tried some of the suggestions in the install message like creating a new profile? After the problems with the packages I've also compiled from ports and had the same effect. Since I've migrated my profile from linux originally, I did move it away first and started a brand new ~/.thunderbird from scratch. Not sure what it could be at the moment. Perhaps you are picking up an old shared lib from a .libs package. What does ls -d /var/db/pkg/.libs-* show? Try pkg_deleting the ones that are not needed anymore - keep note of what you pkg_delete. Also could you capture your LD_DEBUG output and send to me? export LD_DEBUG=1 nohup thunderbird reproduce the problem, exit thunderbird and send me the nohup.out file gzip'ed. -Kurt
Re: Enigmail Thunderbird: Enigmime Service not available
On Tuesday 19 December 2006 3:05 am, Stephan A. Rickauer wrote:
Kurt Miller wrote:
This is working for me with the same versions of the packages
you listed. I built them myself instead of from snapshots though.
AFAICT, system nss doesn't effect this. Have you tried some
of the suggestions in the install message like creating a new
profile?
After the problems with the packages I've also compiled from ports and
had the same effect. Since I've migrated my profile from linux
originally, I did move it away first and started a brand new
~/.thunderbird from scratch.
I still can't reproduce your particular problem, but
I have noticed that enigmail installs its shared lib
in the ~/.thunderbird profile dir. This is going to
be problematic for upgrades.
Please uninstall enigmail from thunderbird (Tools -
Extensions - Enigmail - Uninstall) and try the
attached diff. It installs enigmail into the global
extensions dir.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/mail/enigmail/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile 3 Oct 2006 21:10:16 - 1.1.1.1
+++ Makefile 19 Dec 2006 23:12:54 -
@@ -8,8 +8,12 @@
VER= 0.94.1
DISTNAME= enigmail-${VER}
+PKGNAME= enigmail-${VER}p0
CATEGORIES= mail security
+# note - when thunderbird gets bumped, enigmail needs to be bumped to match
+SHARED_LIBS= enigmime 11.0
+
HOMEPAGE= http://enigmail.mozdev.org/
# mozilla public license or GPL
@@ -21,14 +25,16 @@
MASTER_SITES= http://www.mozilla-enigmail.org/downloads/src/
THUNDERBIRD_DIR=mail/mozilla-thunderbird
-BUILD_DEPENDS= ::${THUNDERBIRD_DIR}:configure
-RUN_DEPENDS= :mozilla-thunderbird-=1.5:${THUNDERBIRD_DIR} \
- ::security/gnupg
+BUILD_DEPENDS= ::${THUNDERBIRD_DIR}:configure \
+ ::archivers/unzip
+RUN_DEPENDS= ::security/gnupg
+
+LIB_DEPENDS= mozilla-thunderbird/xpcom,mozilla-thunderbird/xpcom_compat,mozilla-thunderbird/xpcom_core::${THUNDERBIRD_DIR}
+WANTLIB= c m nspr4 plc4 plds4
USE_X11= Yes
USE_GMAKE= Yes
NO_REGRESS= Yes
-SUBST_VARS= VER ENIGMAIL_XPI GNU_ARCH
MOZBASE= ${WRKDIR}/${THUNDERBIRD_DIR}/mozilla
MOZBIN= ${MOZBASE}/dist/bin
@@ -38,6 +44,10 @@
GNU_ARCH= ${MACHINE_ARCH:S/amd64/x86_64/}
ENIGMAIL_XPI= ${DISTNAME}-${OPSYS:L}-${GNU_ARCH}.xpi
+# unzip ${ENIGMAIL_XPI} and inspect install.rdf for GUID
+GUID= {847b3a00-7ab1-11d4-8f02-006008948af5}
+GLOBALDIR= ${PREFIX}/mozilla-thunderbird/extensions/${GUID}
+
post-extract:
@mv ${WRKDIST} ${MOZBASE}/mailnews/extensions
@@ -52,7 +62,7 @@
@cd ${WRKSRC} ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} xpi
do-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/enigmail
- ${INSTALL_DATA} ${MOZBIN}/${ENIGMAIL_XPI} ${PREFIX}/share/enigmail
+ ${INSTALL_DATA_DIR} ${GLOBALDIR}
+ unzip -q ${MOZBIN}/${ENIGMAIL_XPI} -d ${GLOBALDIR}
.include bsd.port.mk
Index: pkg/MESSAGE
===
RCS file: pkg/MESSAGE
diff -N pkg/MESSAGE
--- pkg/MESSAGE 3 Oct 2006 21:10:16 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,3 +0,0 @@
-To activate the Enigmail extension, users should install the file
-${PREFIX}/share/enigmail/${ENIGMAIL_XPI}
-into their own profile via the menu: Tools - Extensions - Install
Index: pkg/PFRAG.shared
===
RCS file: pkg/PFRAG.shared
diff -N pkg/PFRAG.shared
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/PFRAG.shared 19 Dec 2006 23:12:54 -
@@ -0,0 +1,2 @@
[EMAIL PROTECTED] $OpenBSD$
[EMAIL PROTECTED] mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/components/libenigmime.so.${LIBenigmime_VERSION}
Index: pkg/PLIST
===
RCS file: /cvs/ports/mail/enigmail/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 PLIST
--- pkg/PLIST 3 Oct 2006 21:10:16 - 1.1.1.1
+++ pkg/PLIST 19 Dec 2006 23:12:54 -
@@ -1,3 +1,22 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2006/10/03 21:10:16 steven Exp $
-share/enigmail/
-share/enigmail/enigmail-${VER}-openbsd-${GNU_ARCH}.xpi
+%%SHARED%%
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/chrome/
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/chrome.manifest
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/chrome/enigmail-skin-tbird.jar
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/chrome/enigmail-skin.jar
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/chrome/enigmail.jar
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/components/
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/components/enigmail.js
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/components/enigmail.xpt
+mozilla-thunderbird/extensions/{847b3a00-7ab1-11d4-8f02
Re: Enigmail Thunderbird: Enigmime Service not available
I sent this yesterday but it got lost by my isp.
On Wednesday 20 December 2006 3:31 am, Stephan A. Rickauer wrote:
Kurt Miller wrote:
On Tuesday 19 December 2006 3:05 am, Stephan A. Rickauer wrote:
Kurt Miller wrote:
This is working for me with the same versions of the packages
you listed. I built them myself instead of from snapshots though.
AFAICT, system nss doesn't effect this. Have you tried some
of the suggestions in the install message like creating a new
profile?
After the problems with the packages I've also compiled from ports and
had the same effect. Since I've migrated my profile from linux
originally, I did move it away first and started a brand new
~/.thunderbird from scratch.
I still can't reproduce your particular problem, but
I have noticed that enigmail installs its shared lib
in the ~/.thunderbird profile dir. This is going to
be problematic for upgrades.
Please uninstall enigmail from thunderbird (Tools -
Extensions - Enigmail - Uninstall) and try the
attached diff. It installs enigmail into the global
extensions dir.
I've done so. Your diff applies cleanly, 'make' worked, 'make install'
failed and complained about missing enigmime library. I thought I might
have a messed up ports tree, so I wiped it out and cvs'ed it completely
from scratch. Applying your diff, 'make' and 'make install' worked fine
then.
Starting thunderbird with the previously removed enigmail extension
showed enigmail installed again, without having to go over the Extension
Manager. However, my problem persists: Enigmime service unavailable.
enigmail's shared lib version (SO_VERSION) must match
thunderbird's or thunderbird doesn't see it. This appears
to be the problem you've been having all along. First
it was outdated shared libs in ~/.thunderbird. Now that's
fixed you are still seeing the problem because you've got
thunderbird installed with SO_VERSION 12.0 (from the nss
patch), but enigmail with SO_VERSION 11.0.
At a minimum the LIB_DEPENDS in my patch will need to
be tightened up to exactly match the thunderbird package
it was intended to be matched with. That means both
SO_VERSION and LIB_DEPENDS in enigmail will need to be
manually kept in synch after each update to thunderbird.
That's not ideal. Not sure yet if a better solution
will be found.
I've attached an updated diff that should work with
thunderbird 1.5.0.9 that was just committed.
I've redone this step with LD_DEBUG=1 and have another nohup attached.
This is really curious, because no one seems to be able to reproduce
this problem. ;(
One question. In your previous mail you've asked me to pkg_delete
whatever is no longer needed. I didn't quite understand what you meant
by that, so I've missed that step so far.
That was a shot in the dark. You didn't have any .libs packages
left over from upgrades so there was nothing to pkg_delete.
-Kurt
Index: Makefile
===
RCS file: /cvs/ports/mail/enigmail/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile 3 Oct 2006 21:10:16 - 1.1.1.1
+++ Makefile 21 Dec 2006 20:21:37 -
@@ -8,8 +8,11 @@
VER= 0.94.1
DISTNAME= enigmail-${VER}
+PKGNAME= enigmail-${VER}p0
CATEGORIES= mail security
+SHARED_LIBS= enigmime 12.0
+
HOMEPAGE= http://enigmail.mozdev.org/
# mozilla public license or GPL
@@ -21,14 +24,16 @@
MASTER_SITES= http://www.mozilla-enigmail.org/downloads/src/
THUNDERBIRD_DIR=mail/mozilla-thunderbird
-BUILD_DEPENDS= ::${THUNDERBIRD_DIR}:configure
-RUN_DEPENDS= :mozilla-thunderbird-=1.5:${THUNDERBIRD_DIR} \
- ::security/gnupg
+BUILD_DEPENDS= ::${THUNDERBIRD_DIR}:configure \
+ ::archivers/unzip
+RUN_DEPENDS= ::security/gnupg
+
+LIB_DEPENDS= mozilla-thunderbird/xpcom,mozilla-thunderbird/xpcom_compat,mozilla-thunderbird/xpcom_core:mozilla-thunderbird-1.5.0.9:${THUNDERBIRD_DIR}
+WANTLIB= c m nspr4 plc4 plds4
USE_X11= Yes
USE_GMAKE= Yes
NO_REGRESS= Yes
-SUBST_VARS= VER ENIGMAIL_XPI GNU_ARCH
MOZBASE= ${WRKDIR}/${THUNDERBIRD_DIR}/mozilla
MOZBIN= ${MOZBASE}/dist/bin
@@ -38,6 +43,10 @@
GNU_ARCH= ${MACHINE_ARCH:S/amd64/x86_64/}
ENIGMAIL_XPI= ${DISTNAME}-${OPSYS:L}-${GNU_ARCH}.xpi
+# unzip ${ENIGMAIL_XPI} and inspect install.rdf for GUID
+GUID= {847b3a00-7ab1-11d4-8f02-006008948af5}
+GLOBALDIR= ${PREFIX}/mozilla-thunderbird/extensions/${GUID}
+
post-extract:
@mv ${WRKDIST} ${MOZBASE}/mailnews/extensions
@@ -52,7 +61,9 @@
@cd ${WRKSRC} ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} xpi
do-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/enigmail
- ${INSTALL_DATA} ${MOZBIN}/${ENIGMAIL_XPI} ${PREFIX}/share/enigmail
+ echo ${THUNDERBIRD_PKG}
+ ${INSTALL_DATA_DIR} ${GLOBALDIR}
+ unzip -q ${MOZBIN}/${ENIGMAIL_XPI} -d ${GLOBALDIR}
.include bsd.port.mk
+
Index: pkg/MESSAGE
===
RCS file: pkg/MESSAGE
diff -N pkg/MESSAGE
--- pkg/MESSAGE 3 Oct 2006 21:10:16 - 1.1.1.1
Re: porting advice
On Tuesday 25 September 2007 09:51:57 am mcb, inc. wrote: Hmmm, list has been silent on this question. Well, I have another. The same package also has an optional java-based component. Would the election to include this part be best handled with flavors? And if so, should the flavor pull in a default java system if one isn't found or should it fail loudly early in the build? Here is some general advise on how to select between a flavor or a multi-package... feature Y == some optional feature that most users don't want or perhaps has heavy additional RUN_DEPENDS (like java), WANTLIB or LIB_DEPENDS. The way to choose between a FLAVOR or a multi-package goes like this: If by adding feature Y some file within the existing PLIST/PFRAG changes then you must use a FLAVOR for feature Y. For example if the program or shared libs optionally compile in new code when feature Y is added then it must be a FLAVOR and stop here. There's an exception to this rule but it requires the porter to look at what changed in the main package to see if the author did something like using dlopen() to handle gracefully the possibility the optional feature is missing. If the porter doesn't know how to make that evaluation then just stop here too. On the other hand, if by adding feature Y you only get additional files added to your PLIST/PFRAG then a multi-package is by far preferred. It is preferred because it makes it easier on the users who install packages. To get feature Y just add the multi-package for it instead of a completely new flavored package. The additional depends associated with feature Y are only placed on the Y multi package so the main package doesn't depend on them. Remember its all about the packages. They are the final product and generally speaking we don't care about heavy BUILD_DEPENDS. It's the RUN_DEPENDS, WANTLIB and LIB_DEPENDS that effect the packages. In many cases if feature Y is for java it falls into multi-packages, but you need to evaluate it for your particular port. -Kurt
Re: bug with boehm-gc ?
On Monday 08 October 2007 12:49:14 pm Benoit Chesneau wrote: When I launch gdb, it seems to be an error with boehm-gc. Here is the full backtrace and ktrace dump : http://babilu.metavers.net/openbsd/inkscape/inkscape_backtrace.txt From the innkscape_backtrace.txt file: ... Program received signal SIGSEGV, Segmentation fault. ... #0 0x4b27e80f in GC_find_limit_openbsd (p=0xb3c040  2â, up=1, bound=0xe233a0 ) at os_dep.c:562 The function GC_find_limit_openbsd() intentionally segfaults to find the bounds of accessable memory. This is not what's causing your 'assertion failed' error. To get past the GC_find_limit_openbsd() just continue the app - you may get more then one in GC_find_limit_openbsd(). -Kurt
Re: [audio/amarok] segmentation fault
On Monday 08 October 2007 8:56:52 pm Gilles Chehade wrote:
Hi,
The maintainer of this port being the mailing list according to
ports/INDEX, here's what happens when I use freshly installed amarok on
-current/amd64:
felix:gilles {112} amarok
Amarok: [Loader] Starting amarokapp..
Amarok: [Loader] Don't run gdb, valgrind, etc. against this binary! Use
amarokapp. amarokapp:/usr/lib/libstdc++.so.44.0: undefined symbol
'__cxa_atexit' lazy binding failed!
Amarok: [Loader] amarokapp probably crashed!
felix:gilles {113} nm /usr/lib/libstdc++.so.44.0 |grep '__cxa_atexit'
U __cxa_atexit
felix:gilles {114}
Gilles
One of amarok's depends was not upgraded and is still using
pre-flag day libc. upgrade all the packages to properly move
past the flag day.
-Kurt
Re: Eyesbeyond Mirror
On Wednesday 24 October 2007 4:26:12 pm Tim Donahue wrote: Does anywhere know if there is eyesbeyond.com mirror? The site is currently down and that is preventing building the jdk, so if there is a mirror I'd love to know about it. Sorry no mirror. I let the owner know though. - Kurt
Re: mozilla is backwards (as usual)
On Friday 26 October 2007 11:41:03 am Marc Espie wrote: I was commenting yesterday that mozilla does things backwards (of course they're SPECIAL). On every other application out there, if you hold control and move the scroll wheel up, you get things bigger (I checked with opera, konqueror, and yes, internet explorer as well). Mozilla does it the other way. I'd like this to be consistent. Anyone objects to fixing that ? In general I've resisted attempts by developers to customize firefox to their individual preferences. Can this behavior be controlled via the about:config page? If so it would be much better to leave the default behavior and individuals can customize their preferences via about:config.
Re: Problem with devel/jdk/1.7
Thanks for the report. I'll look into it. You can cd /usr/ports/devel/jdk/1.5 and 'make install' to get around the script problem. -Kurt
Re: Could anyone get Neils Provos's SpyBye compiled successfully on 4.2/amd64
On Tuesday 13 November 2007 10:10:14 am Siju George wrote: Hi, I tried to get http://www.monkey.org/~provos/spybye-0.3.tar.gz complied on OpenBSD 4.2/amd64 as per instructions on http://www.spybye.org/index.php?/pages/installation.html It gives the following error. Could somebody help me fix it? Thank you so much Kind Regards Siju ... gcc -O2 -g -Wall -o spybye spybye.o utils.o status.o spybye.gen.o log.o atomicio.o virus.o proxy.o strnstr.o strncasestr.o -L/usr/local/lib -levent -L/usr/local/lib -liconv -lz -lbz2 -lgmp -L/usr/local/lib -lcurl -L/usr/local/lib -lidn -lssl -lcrypto -lz -lclamav /usr/local/lib/libgmp.so.7.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libevent.so.2.0: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libcurl.so.6.0: warning: sprintf() is often misused, please use snprintf() /usr/local/lib/libbz2.so.10.4: warning: strcat() is almost always misused, please use strlcat() /usr/local/lib/libclamav.so.4.2: undefined reference to `pthread_create' /usr/local/lib/libclamav.so.4.2: undefined reference to `pthread_mutex_unlock' /usr/local/lib/libclamav.so.4.2: undefined reference to `pthread_mutex_lock' /usr/local/lib/libclamav.so.4.2: undefined reference to `pthread_join' collect2: ld returned 1 exit status Shared lib /usr/local/lib/libclamav.so.4.2 is threaded so you need to adjust the linking of spybye to include -pthread too (i.e. add it to the above gcc command). -Kurt
Re: bsd-jdk15-patches-6 openoffice
On Thursday 13 December 2007 7:44:00 am Beavis wrote: Does anyone know if there is an alternative download link for bsd-jdk15-patches-6.tar.bz2 on eyesbeyond? I can't seem to download the patch that I need to build openoffice. any help is greatly appreciated. Use the link download the latest BSD JDK 1.5.0 patchset to get newer patchsets under the JRL.
Re: JDK BROKEN lines in Makefile broken?
On Wednesday 16 January 2008 3:51:22 pm Castle, Shane wrote: When I tried to run make in /usr/ports/devel/jdk/1.7 (-current, after cvs up -Pd), here's what I got: # make /bin/sh: no closing quote *** Error code I don't see this running a -current system. I suspect you are running a -current port with an older system and/or ports tree, which is not supported. I should caution you that 1.7 is not complete, is a work in progress (currently stalled due to lack of time), and outdated (b24 is the current version right now). -Kurt
Re: JDK 1.5 packaging error on 4.2
On Thursday 17 January 2008 12:29:08 pm Dave Steinberg wrote: Hi ports@, I've got a freshly installed OpenBSD 4.2 x86 machine that I've used to build the 1.5.x JDK. The build works fine, but upon the make package step, I get reports of 3 missing files and the build fails: A packaging problem went unnoticed with the no_web FLAVOR at release time. It's fix in -current. To fix this in -stable you can delete any references to libnative_chmod in the pkg/P* files. I just realized that this shared lib is a linux shared lib that is not referenced by anything in the jdk (and would have not worked if it did). Also, move the two lines with lib/deploy/ in them from both PLIST-main and PLIST-jre and add them to PFRAG.no-no_web-main and PFRAG.no-no_web-jre respectively. Alternatively, JC Roberts mentioned today that he made a -stable update diff for 1.5. Perhaps he could forward that diff to you. === Building package for jdk-1.5.0.12-no_web Create /usr/ports/packages/i386/all/jdk-1.5.0.12-no_web.tgz Switching to /usr/ports/devel/jdk/1.5/pkg/PFRAG.client_vm-main Error in package: /var/tmp/jdk-1.5.0.12-no_web/fake-i386-no_web//usr/local/jdk-1.5.0/jre/lib/ deploy/ffjcext.zip does not exist Error in package: /var/tmp/jdk-1.5.0.12-no_web/fake-i386-no_web//usr/local/jdk-1.5.0/jre/lib/ i386/libnative_chmod.so does not exist Error in package: /var/tmp/jdk-1.5.0.12-no_web/fake-i386-no_web//usr/local/jdk-1.5.0/jre/lib/ i386/libnative_chmod_g.so does not exist You'll probably notice that the above is a non-standard location. I set WRKOBJDIR=/var/tmp in my ~/.profile because my /usr/ports is mounted via NFS. I made sure that my /var partition didn't have any funny mount options - at the moment its only 'softdep'. The NFS area has 'noatime' set, fwiw. So far my searches haven't yielded anything fruitful to debug this. Does anyone have any suggestions I might try? PS - Please CC me on replies, I read the list in digest mode normally. Thanks for your time,
Re: JDK 1.5 packaging error on 4.2
On Thursday 17 January 2008 10:34:56 pm Dave Steinberg wrote:
Kurt Miller wrote:
snip
To fix this in -stable you can delete any references to libnative_chmod
in the pkg/P* files. I just realized that this shared lib is a linux
shared lib that is not referenced by anything in the jdk (and would have
not worked if it did). Also, move the two lines with lib/deploy/ in them
from both PLIST-main and PLIST-jre and add them to PFRAG.no-no_web-main
and PFRAG.no-no_web-jre respectively.
I did the above, but the ffjcext.zip file was still throwing errors.
Removing that from the PLIST-{jre,main} files naturally allowed things
to build, but I am curious what the missing file is. Taking a wild
guess, I thought maybe it had something to do with a FireFox extension
(the 'ff' in 'ffjcext'), which of course, I don't care about in the
no_web flavor! Did I guess right?
The ffjcext.zip file is part of the plugin files that are excluded with the
no_web FLAVOR. That file and the previous line for the lib/deploy/ directory
belong in the PFRAG.no-no_web-main, PFRAG.no-no_web-jre files. If you ever
want the plugin they need to be there.
Re: PATCH: devel/sdl
On Friday 25 January 2008 5:17:28 am Antti Harri wrote: On Fri, 25 Jan 2008, Peter Strömberg wrote: Eh, why not just use libGL.so so it will find any available version? I thought about this too. But what version will it use when there are multiple version installed? For example libGL.so.5.1 and libGL.so.6.0. If you don't specify a major.minor in the name passed dlopen() it will select the one with the highest major then highest minor after that. Like we do in firefox: patch-gfx_src_psshared_nsCUPSShim_cpp:-mCupsLib = PR_LoadLibrary(libcups.so.2); patch-gfx_src_psshared_nsCUPSShim_cpp:+ mCupsLib = PR_LoadLibrary(libcups.so); patch-modules_libpref_src_init_all_js:-pref(font.freetype2.shared-librar y, libfreetype.so.6); patch-modules_libpref_src_init_all_js:+pref(font.freetype2.shared-librar y, libfreetype.so); patch-widget_src_gtk2_nsSound_cpp:-elib = PR_LoadLibrary(libesd.so.0); patch-widget_src_gtk2_nsSound_cpp:+ elib = PR_LoadLibrary(libesd.so); With sdl it is loaded on runtime, it can also be overridden using and environment variable. Does that matter? Less knobs == better.
Re: [PATCH] devel/eclipse/sdk: small error in eclipse.desktop
On Wednesday 27 February 2008 2:11:45 pm Stefan Sperling wrote: Hi Kurt, I'm forced to use eclipse for a project at uni, and I was very happy and grateful when discovering the OpenBSD port for it in the tree, so that installing the thing was not a PITA. Anyway, the .desktop file provided with the eclipse port seems to have a small error. When I used the menu entry to start eclipse, it complained about the JDK being missing. Starting eclipse from the command line worked though. The eclipse port installs a wrapper script in /usr/local/bin/eclipse, which sets up the proper path to the java VM prior to launching the IDE itself which is installed as /usr/local/eclipse/eclipse. The .desktop file does not point to the wrapper script, but points directly to /usr/local/eclipse/eclipse. Making the .desktop file use the wrapper script fixed the issue for me: Thanks for the report. The fix has been committed. -Kurt
Re: new: thinkingrock
On Tuesday 18 March 2008 2:52:08 am Nikolay Sturm wrote: Hi, attached is a port of thinkingrock: Thinking Rock is a free software application for collecting and processing your thoughts following the GTD methodology. The archive contains a patched java.port.mk which will be committed soon. Feedback welcome. This is a pure java app requiring a jdk or jre 1.5 or greater. You can use javaPathHelper to make launching on OpenBSD work for any jdk or jre that satisfies the RUN_DEPEND. For example: - change MODJAVA_VER to 1.5+ - add the depend on javaPathHelper - replace the existing patch for patch-platform6_lib_nbexec with the one in /usr/ports/devel/netbeans/patches/patch-core_launcher_unix_nbexec - adjust patch-bin_thinkingrock to do something like this: JAVA_HOME=`javaPathHelper -h thinkingrock` jdkhome=$JAVA_HOME export PATH=$JAVA_HOME/bin:$PATH
Re: new: thinkingrock
On Thursday 20 March 2008 2:17:27 am Nikolay Sturm wrote: * Nikolay Sturm [2008-03-18]: Thinking Rock is a free software application for collecting and processing your thoughts following the GTD methodology. Updated port attached: - fixed PERMIT_*_CDROM, thanks to Andreas Bihlmaier - use javaPathHelper as suggested by kurt@ Feedback welcome, especially with other jdks/jres than 1.5. JAVA_HOME=/usr/local/jdk-1.6.0 thinkingrock and JAVA_HOME=/usr/local/jre-1.6.0 thinkingrock work fine but 1.7 failed to launch it. It appears I need to bring in some more of IcedTea's patches. I will look into that issue. thinkingrock is okay to go in now though. -Kurt
