Re: [update] py-sphinx
On Sun, Feb 02, 2014 at 12:08:24PM +, Stuart Henderson wrote: On 2014/02/02 10:02, frantisek holop wrote: hmm, on Fri, Jan 31, 2014 at 11:39:42AM -0800, Martynas Venckus said that On 1/31/14, frantisek holop min...@obiit.org wrote: happy chinese new year of the horse, here is a simplish update for sphinx. i thought i'd try to give a hand to the MAINTAINER :) Thanks, however I don't use py-sphinx anymore. Could you remove me from MAINTAINER -- and maybe you're interested in taking it over yourself? this reminds me a scene from life of brian :] ok, here is an updated patch. i have removed the texmf test dependency i think it is not worth it, just skip those tests please test and commit. dependencies need checking to make sure that this doesn't change the generated files, as has happened in the past with some (but not all) deps after a previous py-sphinx update - realistically I think this should wait until after we're done with 5.5 release. The latex support in sphinx is important, so remove texmf from test deps is not a good idea. frantisek, I know texmf is really big but you only need download the distfile one time per year. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [update] py-sphinx
On Mon, Feb 03, 2014 at 09:07:51AM +0100, frantisek holop wrote: hmm, on Sun, Feb 02, 2014 at 11:05:51PM +0100, Juan Francisco Cantero Hurtado said that The latex support in sphinx is important, so remove texmf from test deps is not a good idea. frantisek, I know texmf is really big but you only need download the distfile one time per year. this is not about latex support in sphinx. some sphinx _tests_ use texmf, it's for sphix developers to make sure they dont break something when they make changes to the latex support. Sorry, I wasn't clear in my email. We use the regression tests in the packages to test if everything works correctly. These are also used when someone update some problematic dependency. If some test requires latex, the dependency is mandatory. If you read the CVS log, I was the user who requested the change to add latex to the test deps :) -- Juan Francisco Cantero Hurtado http://juanfra.info
Unbreak lang/seed7 on hppa
Brian asked me to compile and to test the last version of seed7 on hppa.
The result is a little weird, so let me know if you have a better fix or
just give me the OKs.
Apparently gmake doesn't honor ALL_TARGET on hppa. I tried also running
directly gmake -f makefile depend s7 s7c within WRKSRC or removing
ALL_TARGET from the port makefile and adding all: depend s7 s7c to
WRKSRC/makefile. Nothing worked. gmake doesn't run depend.
Index: Makefile
===
RCS file: /cvs/ports/lang/seed7/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile19 Jan 2014 20:21:01 - 1.14
+++ Makefile20 Feb 2014 21:08:32 -
@@ -1,8 +1,7 @@
# $OpenBSD: Makefile,v 1.14 2014/01/19 20:21:01 bcallah Exp $
-BROKEN-hppa = SIGILL compiling prg/s7c
-
V =20140119
+REVISION = 0
COMMENT = high-level, extensible programming language
DISTNAME = seed7_05_${V}
PKGNAME = seed7-${V}
@@ -26,7 +25,8 @@ MAKE_FLAGS = CC=${CC} LDFLAGS=-Wl,--g
MAKE_ENV +=S7_LIB_DIR=${TRUEPREFIX}/lib/seed7/bin \
SEED7_LIBRARY=${TRUEPREFIX}/lib/seed7/lib
MAKE_FILE =makefile
-ALL_TARGET = depend s7 s7c
+# Surprisingly, ALL_TARGET doesn't work on HPPA.
+#ALL_TARGET = depend s7 s7c
CFLAGS += -I${X11BASE}/include
@@ -36,6 +36,12 @@ WRKSRC = ${WRKDIST}/src
post-patch:
perl -pi -e s,-O2,${CFLAGS},g ${WRKSRC}/makefile
perl -pi -e s,/usr,${TRUEPREFIX},g ${WRKDIST}/doc/s7{,c}.1
+
+do-build:
+ cd ${WRKSRC} \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE}
depend \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7
\
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7c
do-install:
${INSTALL_PROGRAM} ${WRKDIST}/bin/s7{,c} ${PREFIX}/bin
Re: Unbreak lang/seed7 on hppa
On Fri, Feb 21, 2014 at 10:51:06AM +, Stuart Henderson wrote:
On 2014/02/20 23:07, Brian Callahan wrote:
Apparently gmake doesn't honor ALL_TARGET on hppa. I tried also running
directly gmake -f makefile depend s7 s7c within WRKSRC or removing
ALL_TARGET from the port makefile and adding all: depend s7 s7c to
WRKSRC/makefile. Nothing worked. gmake doesn't run depend.
Blah. That is pretty crappy. I really hope there's a better fix.
ALL_TARGET is just passed on the make command line, I see no reason at
all why that would fail to be honoured on hppa, I'd expect far more
failures than just this.
Is this instead a target dependency issue? If you do make a b c without
Makefile dependencies between them, I don't think there's any guarantee
that they will run in order.
+do-build:
+ cd ${WRKSRC} \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE}
depend \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7
\
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7c
Running the depend stage in pre-build and s7 s7c in ALL_TARGETS may work
and might be a bit nicer..
The last target fails:
gmake: ../bin/s7: Command not found
makefile:134: recipe for target '../prg/s7c' failed
gmake: *** [../prg/s7c] Error 127
gmake: *** Waiting for unfinished jobs
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: Unbreak lang/seed7 on hppa
On Thu, Feb 20, 2014 at 11:07:01PM -0500, Brian Callahan wrote:
On 2/20/2014 4:29 PM, Juan Francisco Cantero Hurtado wrote:
Brian asked me to compile and to test the last version of seed7 on hppa.
The result is a little weird, so let me know if you have a better fix or
just give me the OKs.
So I'm assuming it builds correctly with this fix? But does it work?
Yes, make package and make test work fine.
Apparently gmake doesn't honor ALL_TARGET on hppa. I tried also running
directly gmake -f makefile depend s7 s7c within WRKSRC or removing
ALL_TARGET from the port makefile and adding all: depend s7 s7c to
WRKSRC/makefile. Nothing worked. gmake doesn't run depend.
Blah. That is pretty crappy. I really hope there's a better fix.
~Brian
Index: Makefile
===
RCS file: /cvs/ports/lang/seed7/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile 19 Jan 2014 20:21:01 - 1.14
+++ Makefile 20 Feb 2014 21:08:32 -
@@ -1,8 +1,7 @@
# $OpenBSD: Makefile,v 1.14 2014/01/19 20:21:01 bcallah Exp $
-BROKEN-hppa = SIGILL compiling prg/s7c
-
V =20140119
+REVISION = 0
COMMENT = high-level, extensible programming language
DISTNAME = seed7_05_${V}
PKGNAME = seed7-${V}
@@ -26,7 +25,8 @@ MAKE_FLAGS = CC=${CC} LDFLAGS=-Wl,--g
MAKE_ENV +=S7_LIB_DIR=${TRUEPREFIX}/lib/seed7/bin \
SEED7_LIBRARY=${TRUEPREFIX}/lib/seed7/lib
MAKE_FILE =makefile
-ALL_TARGET =depend s7 s7c
+# Surprisingly, ALL_TARGET doesn't work on HPPA.
+#ALL_TARGET = depend s7 s7c
CFLAGS += -I${X11BASE}/include
@@ -36,6 +36,12 @@ WRKSRC = ${WRKDIST}/src
post-patch:
perl -pi -e s,-O2,${CFLAGS},g ${WRKSRC}/makefile
perl -pi -e s,/usr,${TRUEPREFIX},g ${WRKDIST}/doc/s7{,c}.1
+
+do-build:
+cd ${WRKSRC} \
+${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE}
depend \
+${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7
\
+${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7c
do-install:
${INSTALL_PROGRAM} ${WRKDIST}/bin/s7{,c} ${PREFIX}/bin
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: Unbreak lang/seed7 on hppa
On Fri, Feb 21, 2014 at 12:32:58PM +0100, Marc Espie wrote:
On Fri, Feb 21, 2014 at 10:51:06AM +, Stuart Henderson wrote:
Is this instead a target dependency issue? If you do make a b c without
Makefile dependencies between them, I don't think there's any guarantee
that they will run in order.
There isn't, indeed.
make in traditional non-parallel mode will tend to run them in order,
as lots of people don't know how to use make so that things are a bit
friendlier, but I don't know if gmake does the same, and it's certainly
not guaranteed.
I've found where is the error. I had MAKE_JOBS=2 in /etc/mk.conf.
On my other machines, I have PARALLEL_BUILD=NO so I was not seeing the
same error.
OK to unbreak the package on hppa? All tests pass.
Index: Makefile
===
RCS file: /usr/cvsync/ports/lang/seed7/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile19 Jan 2014 20:21:01 - 1.14
+++ Makefile21 Feb 2014 19:04:47 -
@@ -1,7 +1,5 @@
# $OpenBSD: Makefile,v 1.14 2014/01/19 20:21:01 bcallah Exp $
-BROKEN-hppa = SIGILL compiling prg/s7c
-
V =20140119
COMMENT = high-level, extensible programming language
DISTNAME = seed7_05_${V}
Re: Unbreak lang/seed7 on hppa
On Fri, Feb 21, 2014 at 09:29:29PM +0100, Marc Espie wrote: On Fri, Feb 21, 2014 at 08:07:47PM +0100, Juan Francisco Cantero Hurtado wrote: On Fri, Feb 21, 2014 at 12:32:58PM +0100, Marc Espie wrote: On Fri, Feb 21, 2014 at 10:51:06AM +, Stuart Henderson wrote: Is this instead a target dependency issue? If you do make a b c without Makefile dependencies between them, I don't think there's any guarantee that they will run in order. There isn't, indeed. make in traditional non-parallel mode will tend to run them in order, as lots of people don't know how to use make so that things are a bit friendlier, but I don't know if gmake does the same, and it's certainly not guaranteed. I've found where is the error. I had MAKE_JOBS=2 in /etc/mk.conf. On my other machines, I have PARALLEL_BUILD=NO so I was not seeing the same error. Don't *ever* put MAKE_JOBS=2 in /etc/mk.conf you're guaranteed to break things very badly. First error in one year and half :) . I will delete the variable from mk.conf. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [NEW] games/opentyrian
On Wed, Mar 12, 2014 at 07:39:29PM +0100, Pascal Schmid wrote: port of the DOS shoot-em-up Tyrian Tested on amd64 and macppc (both -current) I attached your ports with some changes. IMO, the ports are OK but I see a problem in data. Where the license says that we can distribute the tarball and the distfile? -- Juan Francisco Cantero Hurtado http://juanfra.info opentyrian.tar.gz Description: application/tar-gz
Re: [NEW] games/opentyrian
On Thu, Mar 13, 2014 at 05:09:15PM -0400, Brian Callahan wrote: On 03/13/14 16:02, Juan Francisco Cantero Hurtado wrote: On Wed, Mar 12, 2014 at 07:39:29PM +0100, Pascal Schmid wrote: port of the DOS shoot-em-up Tyrian Tested on amd64 and macppc (both -current) I attached your ports with some changes. IMO, the ports are OK but I see a problem in data. Where the license says that we can distribute the tarball and the distfile? I'm not sure what you're asking here. I think there is some confusion because there is a license file inside the data .zip but the website it is downloaded from has the following: Tyrian has been released as freeware by Jason Emery. So I'm not entirely sure what that means for us in terms of distribution. But this was a neat little game to waste an afternoon with, so ok for me after the license question gets resolved. Just to clarify. Pascal, we need to know if we can distribute the distfile from the openbsd servers and packaging the content of the distfile. The comment above of PERMIT_* in data needs more info about the permissions. If it is not possible, you can add a README file to the opentyrian port with the instructions to download and install the data files. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [NEW] games/opentyrian
On Fri, Mar 14, 2014 at 01:29:37PM +0100, Pascal Schmid wrote: On 03/14/2014 03:27 AM, Theo de Raadt wrote: That really doesn't mean anything. What we need is either an explicit release to the public domain, or a copyright notice with a license grant permitting distribution/modification/whatever is needed. An alternative would be to just package the game engine itself but avoid including the data; instead tell people (in MESSAGE or README) how to download and install it. For something to land in the our domain of software, it must either have the word Copyright or the words Public Domain. Without those words, the content has not been dragged into the right sphere, and all rights might still be privately held. Just to get this right: We can't include the data files - OK. But would it be OK to add a MESSAGE line to tell users how to download the files? Don't use a MESSAGE. Add a README file to the directory pkg and run make update-plist. I will import the port when you add the file. In case the website goes offline due to license reasons the port would be unusable. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: editors/zile 2.4.9 = 2.4.11
On Mon, Mar 17, 2014 at 11:49:58PM -0400, Brian Callahan wrote: Hi ports -- Here's a patch for Zile to update it to 2.4.11 - tested on amd64 and macppc. The patches are to prevent errors with our gcc (it is confused by the pragmas). The warning flags in the pragmas are flags I don't think our gcc even understands anyway. OK? I can't build zile. depbase=`echo src/funcs.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`; cc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I./src -I./lib -I./lib -DPATH_DOCDIR=\/usr/local/share/doc/zile\ -I/usr/local/include -I/usr/local/include -O2 -pipe -MT src/funcs.o -MD -MP -MF $depbase.Tpo -c -o src/funcs.o src/funcs.c mv -f $depbase.Tpo $depbase.Po src/funcs.c:1121: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic' src/funcs.c:1122: warning: unknown option after '#pragma GCC diagnostic' kind src/funcs.c: In function 'F_shell_command_on_region': src/funcs.c:1128: error: #pragma GCC diagnostic not allowed inside functions *** Error 1 in . (Makefile:2157 'src/funcs.o') *** Error 1 in . (Makefile:2280 'all-recursive') *** Error 1 in /usr/ports/pobj/zile-2.4.11/zile-2.4.11 (Makefile:1923 'all') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2686 '/usr/ports/pobj/zile-2.4.11/.build_done') *** Error 1 in /usr/ports/editors/zile (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'all') -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: editors/zile 2.4.9 = 2.4.11
On Tue, Mar 18, 2014 at 04:57:13PM -0400, Brian Callahan wrote: On 03/18/14 16:52, Juan Francisco Cantero Hurtado wrote: On Mon, Mar 17, 2014 at 11:49:58PM -0400, Brian Callahan wrote: Hi ports -- Here's a patch for Zile to update it to 2.4.11 - tested on amd64 and macppc. The patches are to prevent errors with our gcc (it is confused by the pragmas). The warning flags in the pragmas are flags I don't think our gcc even understands anyway. OK? I can't build zile. You didn't apply the patches. You'll probably notice that your editors/zile directory has some patches sitting in it. You're right. I forgot that patch doesn't create new dirs :( ok juanfra@ depbase=`echo src/funcs.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`; cc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I./src -I./lib -I./lib -DPATH_DOCDIR=\/usr/local/share/doc/zile\ -I/usr/local/include -I/usr/local/include -O2 -pipe -MT src/funcs.o -MD -MP -MF $depbase.Tpo -c -o src/funcs.o src/funcs.c mv -f $depbase.Tpo $depbase.Po src/funcs.c:1121: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic' src/funcs.c:1122: warning: unknown option after '#pragma GCC diagnostic' kind src/funcs.c: In function 'F_shell_command_on_region': src/funcs.c:1128: error: #pragma GCC diagnostic not allowed inside functions *** Error 1 in . (Makefile:2157 'src/funcs.o') *** Error 1 in . (Makefile:2280 'all-recursive') *** Error 1 in /usr/ports/pobj/zile-2.4.11/zile-2.4.11 (Makefile:1923 'all') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2686 '/usr/ports/pobj/zile-2.4.11/.build_done') *** Error 1 in /usr/ports/editors/zile (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'all') -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [UPDATE] mail/sylpheed
On Tue, Apr 08, 2014 at 07:01:15AM +0200, Remi Pointel wrote:
Hi,
this is the diff to update Sylpheed to 3.4.1.
Ok?
Your patch + some fixes. OK juanfra@
Index: Makefile
===
RCS file: /cvs/ports/mail/sylpheed/Makefile,v
retrieving revision 1.102
diff -u -p -r1.102 Makefile
--- Makefile20 Aug 2013 22:30:37 - 1.102
+++ Makefile8 Apr 2014 11:50:29 -
@@ -2,36 +2,35 @@
COMMENT = lightweight and user-friendly e-mail client
-DISTNAME = sylpheed-3.2.0
-REVISION = 0
+DISTNAME = sylpheed-3.4.1
-SHARED_LIBS += sylph-0 2.1 # 2.1
-SHARED_LIBS += sylpheed-plugin-0 2.1 # 2.1
+SHARED_LIBS += sylph-0 3.0 # 3.0
+SHARED_LIBS += sylpheed-plugin-0 3.0 # 3.0
-CATEGORIES=mail news x11
-HOMEPAGE= http://sylpheed.sraoss.jp/en
+CATEGORIES = mail news x11
+HOMEPAGE = http://sylpheed.sraoss.jp/en
# GPLv2 - LGPLv2
-PERMIT_PACKAGE_CDROM= Yes
+PERMIT_PACKAGE_CDROM = Yes
-MODULES = devel/gettext
+MODULES = devel/gettext
LIB_DEPENDS += x11/gtk+2 \
textproc/gtkspell \
security/gpgme
-WANTLIB += GL X11 Xau Xcomposite Xcursor Xdamage Xdmcp Xext Xfixes Xi
-WANTLIB += Xinerama Xrandr Xrender Xxf86vm c crypto atk-1.0 cairo
gdk_pixbuf-2.0
+WANTLIB += X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi
+WANTLIB += Xinerama Xrandr Xrender c crypto atk-1.0 cairo gdk_pixbuf-2.0
WANTLIB += pango-1.0 pangocairo-1.0 dbus-1 dbus-glib-1 gio-2.0 glib-2.0
-WANTLIB += gmodule-2.0 gobject-2.0 drm expat fontconfig freetype m pixman-1
+WANTLIB += gmodule-2.0 gobject-2.0 expat fontconfig freetype m pixman-1
WANTLIB += pthread pthread-stubs gthread-2.0 pcre enchant pangoft2-1.0
WANTLIB += png gpgme gpg-error gtkspell ssl stdc++ xcb xcb-render xcb-shm z
-WANTLIB += gtk-x11-2.0 gdk-x11-2.0 gtkspell assuan
+WANTLIB += gtk-x11-2.0 gdk-x11-2.0 gtkspell assuan ffi graphite2 harfbuzz
-RUN_DEPENDS= devel/desktop-file-utils
-MASTER_SITES = http://sylpheed.sraoss.jp/sylpheed/v3.2/
+RUN_DEPENDS = devel/desktop-file-utils
+MASTER_SITES = http://sylpheed.sraoss.jp/sylpheed/v3.4/
-CONFIGURE_STYLE= gnu
-CONFIGURE_ARGS=${CONFIGURE_SHARED} \
+CONFIGURE_STYLE = gnu
+CONFIGURE_ARGS = ${CONFIGURE_SHARED} \
--enable-ssl \
--enable-ipv6 \
--enable-gtkspell \
@@ -40,20 +39,20 @@ CONFIGURE_ARGS= ${CONFIGURE_SHARED} \
--disable-oniguruma \
--enable-gpgme \
--disable-updatecheck
-CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include \
+CONFIGURE_ENV =CPPFLAGS=-I${LOCALBASE}/include \
LDFLAGS=-L${LOCALBASE}/lib -pthread
-FLAVORS= compface
-FLAVOR?=
+FLAVORS = compface
+FLAVOR ?=
.if ${FLAVOR:Mcompface}
-LIB_DEPENDS+= mail/faces
-WANTLIB+= compface
+LIB_DEPENDS += mail/faces
+WANTLIB += compface
CONFIGURE_ARGS += --enable-compface
PERMIT_PACKAGE_CDROM = No fee
PERMIT_PACKAGE_FTP = Yes
.else
-CONFIGURE_ARGS+= --disable-compface
+CONFIGURE_ARGS += --disable-compface
.endif
.include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/mail/sylpheed/distinfo,v
retrieving revision 1.50
diff -u -p -r1.50 distinfo
--- distinfo12 Jul 2012 20:17:45 - 1.50
+++ distinfo8 Apr 2014 11:50:29 -
@@ -1,5 +1,2 @@
-MD5 (sylpheed-3.2.0.tar.gz) = Gvl/NfIqIDjQUEEJIJHyGg==
-RMD160 (sylpheed-3.2.0.tar.gz) = gWLE1Ffv8O6K4NXQVUh5yY4T2ts=
-SHA1 (sylpheed-3.2.0.tar.gz) = pBqOL8PF5JNfMMe6z/jXJQhUbjU=
-SHA256 (sylpheed-3.2.0.tar.gz) = lp6fL0uphuPLnJeRdtXpu42qxOsAQpDHwvrlobaUVcU=
-SIZE (sylpheed-3.2.0.tar.gz) = 4925789
+SHA256 (sylpheed-3.4.1.tar.gz) = IZaApOcg5spDD7Vhb5zRbN9PYEL/4HeU98yXbpjRgsw=
+SIZE (sylpheed-3.4.1.tar.gz) = 5139049
Index: pkg/PFRAG.shared
===
RCS file: pkg/PFRAG.shared
diff -N pkg/PFRAG.shared
--- pkg/PFRAG.shared10 Jan 2010 10:21:05 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,3 +0,0 @@
-@comment $OpenBSD: PFRAG.shared,v 1.1 2010/01/10 10:21:05 ajacoutot Exp $
-@lib lib/libsylph-0.so.${LIBsylph-0_VERSION}
-@lib lib/libsylpheed-plugin-0.so.${LIBsylpheed-plugin-0_VERSION}
Index: pkg/PLIST
===
RCS file: /cvs/ports/mail/sylpheed/pkg/PLIST,v
retrieving revision 1.36
diff -u -p -r1.36 PLIST
--- pkg/PLIST 8 May 2011 08:18:10 - 1.36
+++ pkg/PLIST 8 Apr 2014 11:50:29 -
@@ -1,6 +1,5 @@
@comment $OpenBSD: PLIST,v 1.36 2011/05/08 08:18:10 rpointel
Re: [PATCH] fix security/luasec build
On Sat, Apr 12, 2014 at 01:14:16PM -0400, James Turner wrote:
On Sat, Apr 12, 2014 at 06:22:31PM +0200, Henrik Friedrichsen wrote:
Hello,
This patch fixes a bug in which the lua library ssl.so is linked with ld
instead of cc.
This results in the stack-protector symbols being missing and therefore
generates a useless library which cannot be used in lua.
The patch sets the LD=cc to fix this.
For some reason this problem did not occur in -CURRENT until recently.
OK?
I can confirm. Updated diff attached with REVISION and use of ${CC}.
Can I get an ok? Tested on amd64.
OK juanfra@ with this additional change:
Index: Makefile
===
RCS file: /cvs/ports/security/luasec/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile20 Mar 2014 19:21:00 - 1.13
+++ Makefile14 Apr 2014 00:58:32 -
@@ -4,6 +4,7 @@ SHARED_ONLY=Yes
COMMENT= lua binding to OpenSSL to provide TLS/SSL communication
VERSION= 0.5
+REVISION= 0
DISTNAME= luasec-${VERSION}
CATEGORIES=security
MASTER_SITES= https://github.com/brunoos/luasec/archive/
@@ -20,7 +21,7 @@ NO_TEST= Yes
MODLUA_RUN_DEPENDS+= net/luasocket
WANTLIB+= crypto ssl
-MAKE_ENV+= INC_PATH=-I${MODLUA_INCL_DIR} SAVECFLAGS=${CFLAGS}
+MAKE_ENV+= INC_PATH=-I${MODLUA_INCL_DIR} SAVECFLAGS=${CFLAGS}
LD=${CC}
ALL_TARGET=bsd
WRKDIST= ${WRKDIR}/luasec-luasec-${VERSION}
Index: patches/patch-src_Makefile
===
RCS file: /cvs/ports/security/luasec/patches/patch-src_Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 patch-src_Makefile
--- patches/patch-src_Makefile 20 Mar 2014 19:21:00 - 1.4
+++ patches/patch-src_Makefile 14 Apr 2014 00:58:32 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-src_Makefile,v 1.4 2014/03/20 19:21:00 gsoares Exp $
src/Makefile.orig Wed Jan 29 17:43:33 2014
-+++ src/Makefile Thu Mar 20 15:59:36 2014
+--- src/Makefile.orig Wed Jan 29 21:43:33 2014
src/Makefile Mon Apr 14 02:57:11 2014
@@ -10,8 +10,8 @@ LIBS=-lssl -lcrypto -lluasocket
WARN=-Wall -pedantic
@@ -12,12 +12,3 @@ $OpenBSD: patch-src_Makefile,v 1.4 2014/
LNX_CFLAGS=-O2 -fPIC $(WARN) $(INCDIR) $(DEFS)
LNX_LDFLAGS=-O -fPIC -shared $(LIBDIR)
-@@ -22,7 +22,7 @@ MAC_LDFLAGS=-bundle -undefined dynamic_lookup $(LIBDIR
-
- INSTALL ?= install
- CC?= cc
--LD?= $(MYENV) cc
-+LD?= $(MYENV) $(CC)
- CFLAGS+= $(MYCFLAGS)
- LDFLAGS += $(MYLDFLAGS)
- DESTDIR ?= /
Re: [new] mpv 0.3.9, sndio still an issue
On Sat, May 03, 2014 at 06:15:31PM +0200, frantisek holop wrote: here is the latest release of mpv. to remind all willing developers about the sndio issue: https://github.com/mpv-player/mpv/issues/531 to make possible debugging even quicker, the mp3 file in question that always triggers this issue is available from (remove spaces): obiit . org/f/ 03-believe.notmp3 I made some changes to your port and fixed a little bug. I have two questions: - Where are you seeing the error 'undefined reference to __sync_fetch_and_add_8'? - Why the assembler code is disabled? -- Juan Francisco Cantero Hurtado http://juanfra.info mpv.tar.gz Description: application/tar-gz
Re: Problems linking again stdc++ and estdc++
On Mon, May 19, 2014 at 06:07:27PM +0200, Nils R wrote:
Stuart Henderson schrieb am 19.05.2014 15:57:
On 2014/05/19 15:22, Nils R wrote:
Hi ports@,
i'm currently porting the game engine for jagged alliance 2 [1]
to openbsd. If i clone the repository and do
# pkg_add sdl gmake gcc g++
$ CC=egcc CXX=eg++ gmake
the program builds and runs fine. It also ships with unittests,
which all pass. However, i now tried to build a port (see
attachment). It also builds, but when i run the unittests, the
following line is printed:
ja2:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.16.0 :
WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch,
relink your program
What can i do to link against estdc++?
This program *is* linking against estdc++, but a library it depends on
links against stdc++, hence the warning as the two conflicting libraries
are loaded into the same address space, so you can't be sure which one
is used for function calls and they don't have a fully compatible ABI.
(Note that this may work OK for some programs but this doesn't mean
it will work for every program).
This is an increasing problem again as we run into more and more
programs using features from newer language specifications not supported
by old compilers..
The funny thing is that if i compile it directly from git in my home folder,
the warning doesn't show up and all tests pass. With the ports version, the
warning shows and some tests fail.
The port is using egcc (gcc 4.8) because the port includes the gcc4
module. The code in your home uses gcc, i.e. gcc 4.2.
Please note that this port is a WIP, the license doesn't allow
commercial use, so i'm unsure if the package would be allowed on
cd or only on ftp.
The CD is commercial, so PERMIT_PACKAGE_CDROM cannot be set to yes.
(generally games need fairly careful checking, especially with
artwork/audio etc, even for ftp).
Yes, that's what i thought. This port is only for the engine though, to
play the game, one needs the official game data which does not come with
the port, so ftp distribution should be allowed.
DISTNAME = 9f7f461f0a2d
this isn't an acceptable distname for the ports tree, this would probably
want something like this:
DISTNAME= ja2-stracciatella-[something]
DISTFILES= ${DISTNAME}{9f7f461f0a2d}${EXTRACT_SUFX}
the [something] would usually be based on the date (e.g. 0.20140519) if
you cannot persuade upstream to make a real release.
Upstream offers releases, but i wanted to test the latest git to see if a
problem was fixed. For the real port, i will stick to releases of course.
# some source files contain a BOM which gcc 4.2.1 can't handle
If that's the only reason for using a gplv3 GCC, can these files just
be patched instead? Alternatively, how does clang handle them?
clang fails to build because of some problems with gtest, but i had no time
to look into it. Might not be a big issue though. Should i conclude from
this that clang is favoured over a gpl3 licensed gcc? If so, is there a
reason to favor non-gpl3 compilers for ports?
No. You can use whatever you want.
Both gcc 4.2 and 4.8 use the system binutils (a pretty old version). If
you need support for CPU instructions not supported by binutils 2.15,
try with clang.
Re: UPDATE: chicken-4.9.0.1
On Sat, Jun 28, 2014 at 10:19:18AM +0300, Timo Myyrä wrote: Hi, Here's a patch to update chicken to latest stable version. Seems pretty basic update but noticed an warning about chicken-install during fake/install phase: Warning: cannot run `chicken-install -update-db' when cross-compiling or DESTDIR is set Should make files be patched to run the chicken-install anyway or just leave a note for the user to run it manually? 'chicken-install -update-db' writes to /usr/local/lib/chicken/7/modules.db. If the user runs manually the command, pkg_add won't delete the dir the next time that the user updates the package. The version 4.8 doesn't have the file modules.db. Is it really necessary or we can ignore the warning?. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [new] mail/mu
On Tue, Jul 08, 2014 at 05:34:30PM +0200, Jérémie Courrèges-Anglas wrote: Aaron def...@gmail.com writes: Hola! ¡hola! mu is a Maildir index/searcher and emacs frontend (mu4e) for mail. Built and tested on amd64. A note for interested users: mu includes an emacs client but you can use the indexer with any mail client (i.e. mutt). It's like notmuch but even better. Perfect for mailing lists. Bonus feature: upstream is friendly. More info on it here: http://www.djcbsoftware.nl/code/mu/mu4e/index.html Suggestions? OK? I didn't look at the port, but this should wait until I finish cleaning up the ports tree so that multiple (two) emacs versions can be installed concurrently. BTW, he could create initially a package without the emacs bits :) -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: pkg_add -u fail on July 8 snap
On Wed, Jul 09, 2014 at 05:11:10AM -0500, Ed Ahlsen-Girard wrote: After upgrading to the July 8 snapshot I duly ran sysmerge, then pkg_add -u, and received this at the end of the output (preceding output was normal): [gcc-4.6.4p7].libs-gcc-4.6.4p4-gcc-4.8.3p0: internal conflict between gcc-4.8.3p0 and gcc-4.6.4p7 Can't install [gcj-4.6.4p4]gcj-4.8.3p0: can't resolve gcc-4.8.3p0 Can't install pdftk-2.02-2.02p0: can't resolve gcj-4.8.3p0 py-Pillow-2.4.0-2.4.0: ok Read shared items: ok Couldn't find updates for .libs-gcc-4.6.4p4, pdftk-2.02 Extracted 54077243 from 610265976 pkg_delete pdftk pkg_delete -a pkg_add pdftk -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: No KDE4 integration in LibreOffice
On Mon, Jul 14, 2014 at 07:15:30PM +0200, Vadim Zhukov wrote: Sorry, it won't happen. Upstream (LO) does a crazy thing, trying to compile same code both for KDE3 and KDE4. It doesn't work. If someone will come in, please, push such changes to LibreOffice upstream first: editors/libreoffice is complex enough already. Why not remove the kde3/qt3 support from the libreoffice port? :) Libreoffice works fine without the KDE support and I don't see the point of to integrate kde3/qt3 with LO these days. GTK+2 is probably more lightweight than QT3 on old machines. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: New dependencies for dulwich update
I reviewed the ports previously. Can someone give an additional OK?. The ports are pretty simple. On Wed, Oct 08, 2014 at 07:36:31AM +0200, Dmitrij D. Czarkoff wrote: Hi! The attached tarballs contain new dependency for dulwich - py-geventhttpclient - and its dependency - py-certifi. The former is trivial port; the latter was supposed to bundle Mozilla's cacert.pem, but is patched to point to /etc/ssl/cert.pem instead. Both ports are required for proper update of dukwich (devel/py-dulwich) to latest release version. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: New dependencies for dulwich update
On Wed, Oct 08, 2014 at 07:36:31AM +0200, Dmitrij D. Czarkoff wrote: Hi! The attached tarballs contain new dependency for dulwich - py-geventhttpclient - and its dependency - py-certifi. The former is trivial port; the latter was supposed to bundle Mozilla's cacert.pem, but is patched to point to /etc/ssl/cert.pem instead. Both ports are required for proper update of dukwich (devel/py-dulwich) to latest release version. You forgot to add the changes that I committed to openbsd-wip :) . Can you update the tarballs?. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: firefox cursors are all different
On Wed, Oct 08, 2014 at 10:23:47PM -0400, Ted Unangst wrote: I upgraded to a new snapshot and ran pkg_add -u. gio-querymodules shit its pants a few times, but otherwise seemed succesful. .libs-firefox-26.0p1+.libs-firefox-29.0.1+firefox-32.0-firefox-32.0: ok You can remove the old packages with 'pkg_delete -a'. If that command doesn't remove the old versions of firefox, try this: pkg_delete -n .libs-firefox-26.0p1 .libs-firefox-29.0.1 pkg_delete will show what packages depend of these versions. However, now the new firefox has these great big honking stupid cursors instead of the nice cursors it used to have. The arrow is too big, the I text cursor has an ugly outline, and the hand looks more like the poop emoji than a hand. How do I get the good cursors back? Are you seeing a hand like this https://i.imgur.com/toikxB5.png ? Firefox uses the default cursors of gtk. Probably your problem is related to the update of gtk and gnome-themes. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: New dependencies for dulwich update
On Sat, Oct 11, 2014 at 06:35:37PM +0200, Landry Breuil wrote: On Wed, Oct 08, 2014 at 04:50:48PM +0200, Juan Francisco Cantero Hurtado wrote: I reviewed the ports previously. Can someone give an additional OK?. The ports are pretty simple. On Wed, Oct 08, 2014 at 07:36:31AM +0200, Dmitrij D. Czarkoff wrote: Hi! The attached tarballs contain new dependency for dulwich - py-geventhttpclient - and its dependency - py-certifi. The former is trivial port; the latter was supposed to bundle Mozilla's cacert.pem, but is patched to point to /etc/ssl/cert.pem instead. Then if you dont bundle mozilla's certificates, you should fix COMMENT... and probably DESCR :) You should also use MODPY_EGG_VERSION for py-geventhttpclient (and update the PLIST to take it into account) Fixed. OK? -- Juan Francisco Cantero Hurtado http://juanfra.info py-certifi.tar.gz Description: Binary data py-geventhttpclient.tar.gz Description: Binary data
Re: UPDATE: lang/racket-minimal 6.2 pre-release
On Sun, Apr 19, 2015 at 04:43:41PM -0400, James Turner wrote: On Tue, Apr 14, 2015 at 08:38:26PM +0200, Juan Francisco Cantero Hurtado wrote: Attached is the pre-release version of racket 6.2. With the next release of racket, I will rename the package from racket to racket-minimal. Racket is transitioning to a model small core + packages, something like perl+cpan or ruby+gems. In fact, the old big package is just a racket distribution since racket 6.0. You can install any package as a regular user with this command: raco pkg install --jobs $(sysctl -n hw.ncpu) --auto --binary drracket The binaries are installed in ~/.racket/6.1.90.900/bin. Let me know if you see any error (please ignore the related to mred). I'm not asking for OKs yet, just tests from racket users :) -- Juan Francisco Cantero Hurtado http://juanfra.info Looks good here on amd64. Only thing I noticed was a blank WANTLIB += line in Makefile and alot of the mirrors don't have the pre release or the sha256 doesn't match. I did eventually get a mirror that matched the checksum. Thanks for the tests!. The blank WANTLIB is a placeholder for the libs loaded using libffi, which this version doesn't need. MASTER_SITES is a mix of mirrors with releases, pre-releases and snapshots (with some copies in my mirror, tuxfamily). I test a lot of snapshots, so I prefer to keep every mirror in the makefile. That's all :) . -- Juan Francisco Cantero Hurtado http://juanfra.info
NEW: lang/chibi-scheme
OK? Information for inst:chibi-scheme-0.7.2 Comment: interpreter of the R7RS Scheme programming language Description: Chibi-Scheme is a small interpreter of the version R7RS of the Scheme programming language. Maintainer: Juan Francisco Cantero Hurtado juan...@openbsd.org WWW: http://synthcode.com/wiki/chibi-scheme chibi-scheme.tar.gz Description: Binary data
Re: NEW: lang/chibi-scheme
On Sat, May 02, 2015 at 12:50:03PM -0400, James Turner wrote: On Mon, Apr 27, 2015 at 09:36:56PM +0200, Juan Francisco Cantero Hurtado wrote: OK? Juan, Everything looks good, but I noticed the version variable isn't set in the pkgconfig file. Should it be? Yes, thanks. The Makefile uses a variable to write the version within the pkgconfig file but the variable is empty. I opened a pull request with the changes. I attached a new tarball. -- Juan Francisco Cantero Hurtado http://juanfra.info chibi-scheme.tar.gz Description: Binary data
Re: NEW: lang/chibi-scheme
On Saturday 09 May 2015 18:45:37 Reinhold Straub wrote: On Mon, 27 Apr 2015 21:36:56 +0200 Juan Francisco Cantero Hurtado i...@juanfra.info wrote: OK? $ sudo make port-lib-depends-check failed termcap lookup on network at /usr/libdata/perl5/OpenBSD/ProgressMeter/Term.pm line 102. *** Error 255 in /usr/ports/mystuff/lang/chibi-scheme (/usr/ports/infrastructure/mk/bsd.port.mk:2289 '/usr/ports/pobj/chibi-scheme-0.7.2/fake-macppc/.saved_libs') (Tested on macppc) The error is unrelated to the port. Can you update your system and the ports tree and try again? -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: ECL-15.3.7
On Sun, May 17, 2015 at 10:08:37PM +0300, Timo Myyrä wrote: Hi, Here's update for ECL. Slightly tested on amd64 by building maxima port. This fixes the broken --enable-threads flag. I've disabled the threads as threaded build doesn't seem to work as build gets stuck in after compiling bootstrap compiler. I've opened an issue with upstream about it [1]. The tests don't work on my computer. Do you see the same errors? === Regression tests for ecl-15.3.7 cd build make check cd tests make make do-ansi ecl -norc -load config.lsp -eval '(ecl-tests::ensure-ansi-tests)' -eval '(ext:quit)' /dev/null ;;; Loading /usr/write-ports/pobj/ecl-15.3.7/ecl-15.3.7/build/tests/config.lsp An error occurred during initialization: The assertion (STRING-EQUAL ECL-CURL::URL http://; :END1 7) failed. *** Error 1 in build/tests (Makefile:31 'ansi-tests') *** Error 1 in build/tests (Makefile:9 'output.ecl/ansi.log') -- Juan Francisco Cantero Hurtado http://juanfra.info
UPDATE: lang/racket-minimal 6.2 pre-release
Attached is the pre-release version of racket 6.2. With the next release of racket, I will rename the package from racket to racket-minimal. Racket is transitioning to a model small core + packages, something like perl+cpan or ruby+gems. In fact, the old big package is just a racket distribution since racket 6.0. You can install any package as a regular user with this command: raco pkg install --jobs $(sysctl -n hw.ncpu) --auto --binary drracket The binaries are installed in ~/.racket/6.1.90.900/bin. Let me know if you see any error (please ignore the related to mred). I'm not asking for OKs yet, just tests from racket users :) -- Juan Francisco Cantero Hurtado http://juanfra.info racket-minimal.tar.gz Description: Binary data
Re: [update] samba-4.0.26
Oh, I think that I see where is the problem. The ports framework takes
tdb from the ports directory, instead of its own directory.
On Tue, Jun 16, 2015 at 06:05:25AM +, Ian Mcwilliam wrote:
Building out of mystuff directory fails. Building from the ports directory
works. Go figure...
Ian McWilliam
From: Juan Francisco Cantero Hurtado [i...@juanfra.info]
Sent: Saturday, 13 June 2015 1:26 AM
To: Ian Mcwilliam
Cc: Jérémie Courrèges-Anglas; Ian McWilliam; OpenBSD ports; d...@openbsd.org
Subject: Re: [update] samba-4.0.26
I've tried the patch with samba4 installed (which showed a different
error to yours) and without it. It builds fine without samba
installed.
Obviously you have the previous version of tds somewhere.
Try this: find /usr/lib /usr/local/lib -name '*tdb*'
On Fri, Jun 12, 2015 at 03:16:46AM +, Ian Mcwilliam wrote:
Still no dice even with cleaning everything up.
make clean=all
env SUBPACKAGE=-tdb make update
Brand spanking new usr/ports/* that has the empty plist/amd64 directory.
Same error, same bat channel.
=== Building package for samba-4.0.26
Create /usr/packages/amd64/all/samba-4.0.26.tgz
Error: Libraries in packing-lists in the ports tree
and libraries from installed packages don't match
--- /tmp/dep_cache.jIhQSC1pn/portstree-samba-4.0.26 Fri Jun 12 13:02:25
2015
+++ /tmp/dep_cache.jIhQSC1pn/inst-samba-4.0.26 Fri Jun 12 13:02:25 2015
@@ -24,7 +24,7 @@
-W ldb.0.0
-W pyldb-util.0.0
-W pytalloc-util.0.0
--W tdb.4.0
+-W tdb.5.0
-W tevent.0.0
-W lib/samba/nss_wrapper.0.0
-W lib/samba/socket_wrapper.0.0
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3243
'wantlib-args')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1956
'/usr/packages/amd64/all/samba-4.0.26.tgz')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2507
'_internal-package')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1978
'/usr/ports/update/amd64/samba-4.0.26')
*** Error 1 in /usr/mystuff/net/samba4
(/usr/ports/infrastructure/mk/bsd.port.mk:2487 'update')
ianm-openbsd:amd64 {131} pkg_info
alpine-2.20 UW e-mail client
aspell-0.60.6.1p2 spell checker designed to eventually replace Ispell
autoconf-2.13p3 automatically configure source code on many Un*x
platforms
autoconf-2.65p0 automatically configure source code on many Un*x
platforms
autoconf-2.67p0 automatically configure source code on many Un*x
platforms
autoconf-2.69p1 automatically configure source code on many Un*x
platforms
automake-1.14.1 GNU Standards-compliant Makefile generator
avahi-0.6.31p17 framework for Multicast DNS Service Discovery
bash-4.3.39 GNU Bourne Again Shell
bison-2.3p2 GNU parser generator
bzip2-1.0.6p1 block-sorting file compressor, unencumbered
cairo-1.14.2vector graphics library
cups-libs-2.0.3p0 CUPS libraries and headers
curl-7.42.1 get files from FTP, Gopher, HTTP or HTTPS servers
cvsps-2.1p0 generate patchsets from CVS repositories
cyrus-sasl-2.1.26p13 RFC SASL (Simple Authentication and Security
Layer)
db-4.6.21p1v0 Berkeley DB package, revision 4
dbus-1.8.18v0 message bus system
dbus-daemon-launch-helper-1.8.18 DBus setuid helper for starting system
services
docbook-4.5p1 technical documentation XML/SGML definitions
docbook-dsssl-1.79 modular DSSSL stylesheets for the DocBook DTD
docbook-xsl-1.68.1p5 docbook XSL modular stylesheet
dos2unix-7.2.2 convert DOS/MAC files to UNIX (line-endings/charset)
e2fsprogs-1.42.12p0 utilities to manipulate ext2 filesystems
gamin-0.1.10p21 file and directory monitoring system
gdbm-1.11p0 GNU dbm
gettext-0.19.4p0GNU gettext
git-2.4.3 GIT - Tree History Storage Tool
glib2-2.44.1general-purpose utility library
gmake-4.1p0 GNU make
gmp-5.0.2p3 library for arbitrary precision arithmetic
gnugetopt-1.1.6 GNU getopt(1) utility
gnutls-3.3.15 GNU Transport Layer Security library
gobject-introspection-1.44.0 GObject Introspection
gperf-3.0.4p0 perfect hash functions, to help write parsers
groff-1.22.3p1 GNU troff typesetter
help2man-1.46.6 generates simple manual pages from program output
icu4c-55.1p0International Components for Unicode
iniparser-3.1p1 ini file parsing library
intltool-0.51.0 internationalization tools
iso8879-1986p0 character entity sets from ISO 8879:1986 (SGML)
libdaemon-0.14p1lightweight C library that eases the writing of daemons
libelf-0.8.13p3 read, modify, create ELF files on any arch
libexecinfo-0.2p5v0 clone of backtrace facility found in the GNU libc
libffi-3.1p0Foreign Function Interface
libgcrypt-1.6.3 crypto library based on code used
Re: [update] samba-4.0.26
-x 2 root wheel 512 Jun 11 13:00 libelf-0.8.13p3
drwxr-xr-x 2 root wheel 512 Jun 11 12:44 libexecinfo-0.2p5v0
drwxr-xr-x 2 root wheel 512 Jun 11 13:16 libffi-3.1p0
drwxr-xr-x 2 root wheel 512 Jun 11 12:28 libgcrypt-1.6.3
drwxr-xr-x 2 root wheel 512 Jun 11 12:28 libgpg-error-1.19
drwxr-xr-x 2 root wheel 512 Jun 11 13:18 libiconv-1.14p3
drwxr-xr-x 2 root wheel 512 May 13 11:54 libidn-1.30
drwxr-xr-x 2 root wheel 512 Apr 9 14:29 libltdl-2.4.2p1
drwxr-xr-x 2 root wheel 512 Jun 11 13:16 libnettle-2.7.1p2
drwxr-xr-x 2 root wheel 512 Jun 11 12:50 libpaper-1.1.24p0
drwxr-xr-x 2 root wheel 512 Jun 11 12:46 libsigsegv-2.10p1
drwxr-xr-x 2 root wheel 512 Jun 11 13:16 libtasn1-4.5
drwxr-xr-x 2 root wheel 512 Apr 9 14:29 libtool-2.4.2p0
drwxr-xr-x 2 root wheel 512 Jun 11 13:12 libusb1-1.0.9p9
drwxr-xr-x 2 root wheel 512 Jun 11 12:28 libxml-2.9.2p0
drwxr-xr-x 2 root wheel 512 Jun 12 11:49 libxslt-1.1.28p1
drwxr-xr-x 2 root wheel 512 Jun 11 12:50 lynx-2.8.9pl6
drwxr-xr-x 2 root wheel 512 Jun 11 13:02 lzo2-2.09
drwxr-xr-x 2 root wheel 512 Jun 11 12:46 m4-1.4.17
drwxr-xr-x 2 root wheel 512 Jun 11 13:12 metaauto-1.0p1
drwxr-xr-x 2 root wheel 512 Jun 11 12:44 openldap-client-2.4.40
drwxr-xr-x 2 root wheel 512 Jun 11 13:18 openpam-20141014
drwxr-xr-x 2 root wheel 512 Jun 11 13:16 p11-kit-0.22.1p1
drwxr-xr-x 2 root wheel 512 Jun 11 11:43 p5-Error-0.17024
drwxr-xr-x 2 root wheel 512 Jun 11 12:54 p5-XML-Parser-2.44
drwxr-xr-x 2 root wheel 512 Jun 11 13:18 pcre-8.37p0
drwxr-xr-x 2 root wheel 512 May 13 12:07 pico-5.07p3
drwxr-xr-x 2 root wheel 512 Jun 11 13:02 png-1.6.17
drwxr-xr-x 2 root wheel 512 Jun 11 13:18 popt-1.16p0
drwxr-xr-x 2 root wheel 512 Jun 11 13:04 py-MarkupSafe-0.23
drwxr-xr-x 2 root wheel 512 Jun 11 13:04 py-beaker-1.6.2p3
drwxr-xr-x 2 root wheel 512 Jun 11 13:04 py-crypto-2.6.1p0
drwxr-xr-x 2 root wheel 512 Jun 11 12:05 py-dnspython-1.11.1
drwxr-xr-x 2 root wheel 512 Jun 11 12:08 py-libxml-2.9.2p0
drwxr-xr-x 2 root wheel 512 Jun 11 13:05 py-mako-0.9.1p1
drwxr-xr-x 2 root wheel 512 Jun 12 11:48 py-setuptools-3.4.4p2v0
drwxr-xr-x 2 root wheel 512 Jun 12 11:48 python-2.7.10
drwxr-xr-x 2 root wheel 512 Jun 11 11:43 rsync-3.1.1
drwxr-xr-x 2 root wheel 512 Jun 11 12:01 tcl-8.5.18
drwxr-xr-x 2 root wheel 512 Jun 11 11:38 tcsh-6.19.00
drwxr-xr-x 2 root wheel 512 Jun 11 12:01 tk-8.5.18
drwxr-xr-x 2 root wheel 512 Jun 11 12:05 unzip-6.0p7
drwxr-xr-x 2 root wheel 512 Apr 9 14:18 vmwh-1.1v0
drwxr-xr-x 2 root wheel 512 Apr 9 14:25 xclip-0.12p0
drwxr-xr-x 2 root wheel 512 Jun 11 12:50 xmlto-0.0.26p0
drwxr-xr-x 2 root wheel 512 Jun 11 12:45 xmltoman-0.4
drwxr-xr-x 2 root wheel 512 Jun 11 12:28 xz-5.2.1
ianm-openbsd:amd64 {136} dmesg | head
OpenBSD 5.7-current (GENERIC.MP) #0: Thu Jun 11 10:24:17 AEST 2015
r...@ianm-openbsd.uws-libsystems.edu.au:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3141468160 (2995MB)
avail mem = 3042451456 (2901MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version 6.00 date 07/31/2013
bios0: VMware, Inc. VMware Virtual Platform
Ian McWilliam
From: Juan Francisco Cantero Hurtado [i...@juanfra.info]
Sent: Friday, 12 June 2015 11:45 AM
To: Ian Mcwilliam
Cc: Jérémie Courrèges-Anglas; Ian McWilliam; OpenBSD ports; d...@openbsd.org
Subject: Re: [update] samba-4.0.26
You need to update the subpackage tdb before of to build samba.
IIRC, env SUBPACKAGE=-tdb make update
On Thu, Jun 11, 2015 at 11:44:30PM +, Ian Mcwilliam wrote:
Everything updated, kernel / userland / xenocara built about an hour
before trying to build. Fresh ports tree from the same time. My previous
attempts at building a newer samba 4.0.x failed at the packing stage due to
the perl stuff being in a different location so nothing should have been
registered anywhere. I'll clean out everything throughly today and see what
happens.
Ian McWilliam
From: Jérémie Courrèges-Anglas [j...@wxcvbn.org]
Sent: Thursday, 11 June 2015 7:43 PM
To: Ian Mcwilliam
Cc: Ian McWilliam; OpenBSD ports; d...@openbsd.org
Subject: Re: [update] samba-4.0.26
Ian Mcwilliam i.mcwill...@uws.edu.au writes:
Hmm, I see this.
=== Building package for samba-4.0.26
Create /usr/packages/amd64/all/samba-4.0.26.tgz
Error: Libraries in packing-lists in the ports tree
and libraries from installed packages don't match
--- /tmp/dep_cache.jj4UL4tjY/portstree-samba-4.0.26 Thu Jun 11
13:41:38 2015
+++ /tmp/dep_cache.jj4UL4tjY/inst-samba-4.0.26 Thu Jun 11 13:41:38 2015
Re: [update] samba-4.0.26
You need to update the subpackage tdb before of to build samba. IIRC, env SUBPACKAGE=-tdb make update On Thu, Jun 11, 2015 at 11:44:30PM +, Ian Mcwilliam wrote: Everything updated, kernel / userland / xenocara built about an hour before trying to build. Fresh ports tree from the same time. My previous attempts at building a newer samba 4.0.x failed at the packing stage due to the perl stuff being in a different location so nothing should have been registered anywhere. I'll clean out everything throughly today and see what happens. Ian McWilliam From: Jérémie Courrèges-Anglas [j...@wxcvbn.org] Sent: Thursday, 11 June 2015 7:43 PM To: Ian Mcwilliam Cc: Ian McWilliam; OpenBSD ports; d...@openbsd.org Subject: Re: [update] samba-4.0.26 Ian Mcwilliam i.mcwill...@uws.edu.au writes: Hmm, I see this. === Building package for samba-4.0.26 Create /usr/packages/amd64/all/samba-4.0.26.tgz Error: Libraries in packing-lists in the ports tree and libraries from installed packages don't match --- /tmp/dep_cache.jj4UL4tjY/portstree-samba-4.0.26 Thu Jun 11 13:41:38 2015 +++ /tmp/dep_cache.jj4UL4tjY/inst-samba-4.0.26 Thu Jun 11 13:41:38 2015 @@ -24,7 +24,7 @@ -W ldb.0.0 -W pyldb-util.0.0 -W pytalloc-util.0.0 --W tdb.4.0 +-W tdb.5.0 -W tevent.0.0 -W lib/samba/nss_wrapper.0.0 -W lib/samba/socket_wrapper.0.0 *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3242 'wantlib-args') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1955 '/usr/packages/amd64/all/samba-4.0.26.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2506 '_internal-package') *** Error 1 in /usr/mystuff/net/samba4 (/usr/ports/infrastructure/mk/bsd.port.mk:2486 'package') This looks like a local problem. Had you already built/installed samba-4.0.26 packages before? Please rebuild after make clean=all, with an up-to-date ports tree. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: Aria2-1.19.0
Can you add support for SFTP? It is a new feature and requires libssh2. On Tue, May 26, 2015 at 01:25:39PM -0300, Gonzalo L. Rodriguez wrote: Hi, Update for Aria2 to 1.19.0: http://sourceforge.net/projects/aria2/files/stable/aria2-1.19.0/ Ok? Comments? Cheers.- -- Sending from my toaster. Index: Makefile === RCS file: /cvs/ports/www/aria2/Makefile,v retrieving revision 1.32 diff -u -p -r1.32 Makefile --- Makefile 25 Mar 2015 13:46:26 - 1.32 +++ Makefile 26 May 2015 16:23:23 - @@ -2,7 +2,7 @@ BROKEN-alpha = MetalinkParserStateV4Impl.cc:219:1: internal compiler error: Segmentation fault COMMENT =lightweight multi-protocol multi-source download utility -DISTNAME = aria2-1.18.10 +DISTNAME = aria2-1.19.0 CATEGORIES = www HOMEPAGE = http://aria2.sourceforge.net/ Index: distinfo === RCS file: /cvs/ports/www/aria2/distinfo,v retrieving revision 1.21 diff -u -p -r1.21 distinfo --- distinfo 25 Mar 2015 13:46:26 - 1.21 +++ distinfo 26 May 2015 16:23:23 - @@ -1,2 +1,2 @@ -SHA256 (aria2-1.18.10.tar.gz) = dUBiSTCWEQ6oJr/mBXB5SVQpbYxtyl53/c/ok8fBZPA= -SIZE (aria2-1.18.10.tar.gz) = 3509405 +SHA256 (aria2-1.19.0.tar.gz) = jArA0O7xgO/r7L05mXle6fNSRA4jD0QN/HR9YKvPn+8= +SIZE (aria2-1.19.0.tar.gz) = 3532647 -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: plan9port: enable fontsrv(4)
On Thu, Jun 11, 2015 at 08:32:40AM +0200, Pascal Stumpf wrote:
On Wed, 10 Jun 2015 17:13:38 -0300, Gleydson Soares wrote:
Hi Pascal,
here is a diff[1] to enable fontsrv(4) support in ports/plan9/plan9port.
diff inline below.
fontsrv(4) provides an interface to use X11 fonts in plan9port. It is
useful, can be used to load anti-aliasing/TrueType fonts on acme.
eg:
fontsrv
acme -f /mnt/font/DejaVu Sans Mono/8a/font
for list all available fonts:
$ fontsrv
$ 9p ls font
or
$ fontsrv -p .
Well, by default it is enabled, but requires X11 headers and on openbsd the
plan9port/INSTALL script wasn't catching, therefore it was disabled.
so I did a patch to adjust it, append /usr/X11R6/include and
/usr/X11R6/include/freetype2 to X11 headers check in ${WRKSRC}/INSTALL file
script.
I already sent patch[2] upstream...
[1] http://shutupandhack.org/~gsoares/openbsd/plan9port-20140306p0.diff
[2] https://plan9port-review.googlesource.com/#/c/1290/
CC ports@ so others can also test and give us feedback.
comments, OK?
cheers,
gsoares.
? plan9port-20140306p0.diff
Index: Makefile
===
RCS file: /cvs/ports/plan9/plan9port/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile9 Mar 2014 20:26:48 - 1.5
+++ Makefile11 Jun 2015 05:12:54 -
@@ -6,6 +6,7 @@ BROKEN-powerpc =threading issues
COMMENT = Plan 9 from user space
DISTNAME = plan9port-20140306
+REVISION = 0
CATEGORIES = plan9
Index: patches/patch-INSTALL
===
RCS file: /cvs/ports/plan9/plan9port/patches/patch-INSTALL,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-INSTALL
--- patches/patch-INSTALL 9 Mar 2014 20:26:48 - 1.2
+++ patches/patch-INSTALL 11 Jun 2015 05:12:55 -
@@ -1,7 +1,24 @@
$OpenBSD: patch-INSTALL,v 1.2 2014/03/09 20:26:48 pascal Exp $
INSTALL.orig Thu Mar 6 11:00:08 2014
-+++ INSTALLSun Mar 9 20:58:02 2014
-@@ -150,7 +150,7 @@ cd src
+
+INSTALL: append /usr/X11R6/include and /usr/X11R6/include/freetype2 to
+X11 headers detection, so that enable fontsrv build on OpenBSD.
+
+patch sent upstream:
+https://plan9port-review.googlesource.com/#/c/1290/
+
+--- INSTALL.orig Thu Mar 6 07:00:08 2014
INSTALLWed Jun 10 16:52:29 2015
+@@ -128,7 +128,8 @@ fi
+ if [ `uname` != Darwin ]; then
+ # Determine whether fontsrv X11 files are available.
+ rm -f a.out
+- gcc -o a.out -c -Iinclude -I/usr/include -I/usr/local/include
-I/usr/include/freetype2 -I/usr/local/include/freetype2
src/cmd/fontsrv/x11.c /dev/null 21
++ gcc -o a.out -c -Iinclude -I/usr/include -I/usr/local/include
-I/usr/include/freetype2 -I/usr/local/include/freetype2 \
++ -I/usr/X11R6/include -I/usr/X11R6/include/freetype2
src/cmd/fontsrv/x11.c /dev/null 21
This should make use of ${X11BASE} instead of hardcoding /usr/X11R6.
Though in principle, /usr/local should be ${LOCALBASE} as well ...
In addition to pascal's comment, can you change also the lines with
gcc hardcoded to ${CC}?
+ if [ -f a.out ]; then
+ echo fontsrv dependencies found.
+ echo FONTSRV=fontsrv $PLAN9/config
+@@ -150,7 +151,7 @@ cd src
if $dobuild; then
if [ ! -x ../bin/mk ]; then
echo * Building mk...
@@ -10,7 +27,7 @@ $OpenBSD: patch-INSTALL,v 1.2 2014/03/09
fi
if [ ! -x ../bin/mk ]; then
echo * Error: mk failed to build.
-@@ -158,7 +158,6 @@ if $dobuild; then
+@@ -158,7 +159,6 @@ if $dobuild; then
fi
echo * Building everything (be patient)...
@@ -18,7 +35,7 @@ $OpenBSD: patch-INSTALL,v 1.2 2014/03/09
mk libs-nuke
mk all || exit 1
if [ ! -x $PLAN9/src/cmd/o.cleanname -o ! -x $PLAN9/src/cmd/acme/o.acme
]; then
-@@ -213,5 +212,5 @@ if $doinstall; then
+@@ -213,5 +213,5 @@ if $doinstall; then
echo PLAN9=$PLAN9 export PLAN9
echo ' PATH=$PATH:$PLAN9/bin export PATH'
fi
Index: pkg/PLIST
===
RCS file: /cvs/ports/plan9/plan9port/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 PLIST
--- pkg/PLIST 9 Mar 2014 20:26:48 - 1.3
+++ pkg/PLIST 11 Jun 2015 05:12:58 -
@@ -122,6 +122,7 @@ plan9/bin/doctype
@bin plan9/bin/factotum
@bin plan9/bin/file
@bin plan9/bin/fmt
+@bin plan9/bin/fontsrv
@bin plan9/bin/fortune
plan9/bin/fossil/
plan9/bin/fossil/conf
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: OpenMP in GCC
On Thu, Jun 11, 2015 at 12:03:27PM +0100, Stuart Henderson wrote: On 2015/06/11 11:37, Pascal Stumpf wrote: Though as your patch demonstrates, this needs more testing because some ports will start to pick up libgomp once it's supported. I can do an audit of everything that uses ports gcc, but that may take some time. Here are a few to look at for starters..(I haven't checked which compiler they use) audio/sox audio/libsoxr archivers/gcab audio/clementine games/supertuxkart graphics/libraw graphics/opencv graphics/libkdcraw graphics/blender graphics/inkscape graphics/enblend-enfuse graphics/ufraw graphics/darktable graphics/digikam-kde4 math/fftw3 math/ecm math/eigen3 math/R misc/libosinfo sysutils/libvirt lang/cython x11/gtk-vnc x11/spice-gtk And graphics/pdf2djvu, which has the openmp support disabled. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [update] net/icbirc 1.9
I don't use icbirc, so I can't test the update. However, I think that the patches included in the port should go upstream. On Fri, Aug 21, 2015 at 11:54:44AM +0200, Sebastien Marie wrote: Hi, Here a patch for updating net/icbirc to latest version 1.9. Daniel: thanks for this quick release :) Comments ? OK ? -- Sebastien Marie Index: Makefile === RCS file: /cvs/ports/net/icbirc/Makefile,v retrieving revision 1.15 diff -u -p -r1.15 Makefile --- Makefile 22 Jan 2015 21:17:47 - 1.15 +++ Makefile 21 Aug 2015 04:20:01 - @@ -2,8 +2,7 @@ COMMENT= proxy IRC client with ICB server -DISTNAME=icbirc-1.8 -REVISION=1 +DISTNAME=icbirc-1.9 CATEGORIES= net MASTER_SITES=http://www.benzedrine.ch/ Index: distinfo === RCS file: /cvs/ports/net/icbirc/distinfo,v retrieving revision 1.10 diff -u -p -r1.10 distinfo --- distinfo 18 Jan 2015 03:14:40 - 1.10 +++ distinfo 21 Aug 2015 04:20:01 - @@ -1,2 +1,2 @@ -SHA256 (icbirc-1.8.tar.gz) = 68TCSCrFMRSYdO53wYj2rc9QmGLKK2AOn+UFf1VezZI= -SIZE (icbirc-1.8.tar.gz) = 11061 +SHA256 (icbirc-1.9.tar.gz) = YbDg75DwRl50cstX4zJt8WwHTVkcnmeCo13xSSTzQeQ= +SIZE (icbirc-1.9.tar.gz) = 11070 Index: pkg/PLIST === RCS file: /cvs/ports/net/icbirc/pkg/PLIST,v retrieving revision 1.2 diff -u -p -r1.2 PLIST --- pkg/PLIST 15 Sep 2004 18:17:40 - 1.2 +++ pkg/PLIST 21 Aug 2015 04:20:01 - @@ -1,3 +1,3 @@ @comment $OpenBSD: PLIST,v 1.2 2004/09/15 18:17:40 espie Exp $ -bin/icbirc +@bin bin/icbirc @man man/man8/icbirc.8 -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: ECL-15.3.7
On Sat, Aug 22, 2015 at 11:31:17PM +0300, Timo Myyrä wrote:
Jasper Lievisse Adriaanse jas...@openbsd.org writes:
On Fri, Aug 21, 2015 at 11:43:57AM +0300, Timo Myyr?? wrote:
Hi,
I've been looking at this upgrade for a while.
The Makefile's CONFIGURE_ARGS enable-threads arg should be removed.
The current value 'pthreads' is incorrect and instead of failing it just
disables thread support. This is my mistake, I think I confused it with
boehm-gc when ecl was previously updated.
The default option for threads is 'auto' so the whole flag could be just
removed to enable threads support.
About the tests, currently they fail but upstream fixed the test material
fetching to use curl directly after 15.3.7 release. We could make curl an
test dependency.
And have it fetch files from the web during 'make test'? That sounds bad. If
possible we should mirror the file set somewhere so we can checksum it.
Yeah, it would make sense to verify the test data before using it.
Just to clarify jasper's words: the port only should to download data
during make fetch, everything else is forbidden.
Test the ports with env USE_SYSTRACE=Yes make something is always a
good idea :)
One issue that has prevented me from posting an update is that I get
following when doing 'make package':
LIB_DEPENDS devel/boehm-gc, -atomic not needed for lang/ecl?
|library atomic_ops-1.3 not found
I haven't figured out why its complaining about that.
Doesn't happen here; are you fully -current?
Yes, I should be pretty close to current. Though I had some other vague issue
with other ports as well I couldn't replicate on another computer running the
same snapshot. I'm assuming I've made some mistake in some update along the
path which is causing these. Probably easiest to do reinstall and check if
that
will help.
In any case, I think we should wait a bit. There's new release coming for
ECL and it would include some of the local patches.
Excellent.
Timo
21.8.2015, 10:38, Jasper Lievisse Adriaanse kirjoitti:
On Mon, May 18, 2015 at 02:39:31AM +0200, Juan Francisco Cantero Hurtado
wrote:
On Sun, May 17, 2015 at 10:08:37PM +0300, Timo Myyr? wrote:
Hi,
Here's update for ECL. Slightly tested on amd64 by building maxima
port. This
fixes the broken --enable-threads flag. I've disabled the threads as
threaded
build doesn't seem to work as build gets stuck in after compiling
bootstrap
compiler. I've opened an issue with upstream about it [1].
The tests don't work on my computer. Do you see the same errors?
It's the same as with the current in-tree version actually, so it's not a
regression.
=== Regression tests for ecl-15.3.7
cd build make check
cd tests make
make do-ansi
ecl -norc -load config.lsp -eval '(ecl-tests::ensure-ansi-tests)' -eval
'(ext:quit)' /dev/null
;;; Loading
/usr/write-ports/pobj/ecl-15.3.7/ecl-15.3.7/build/tests/config.lsp
An error occurred during initialization:
The assertion (STRING-EQUAL ECL-CURL::URL http://; :END1 7) failed.
*** Error 1 in build/tests (Makefile:31 'ansi-tests')
*** Error 1 in build/tests (Makefile:9 'output.ecl/ansi.log')
--
Juan Francisco Cantero Hurtado http://juanfra.info
Here's an updated diff which incorporates upstream's fix for the issue
Timo
reported. Maxima still seems happy.
OK?
Index: Makefile
===
RCS file: /cvs/ports/lang/ecl/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile 19 Jul 2015 02:14:57 - 1.24
+++ Makefile 21 Aug 2015 07:26:37 -
@@ -6,13 +6,11 @@ CATEGORIES =lang
BROKEN-sparc = infinite loop while building
BROKEN-arm =infinite loop while building
-V = 13.5.1
+V = 15.3.7
DISTNAME = ecl-$V
-SHARED_LIBS += ecl 3.0
+SHARED_LIBS += ecl 4.0
SHARED_ONLY = Yes
-REVISION = 1
-
HOMEPAGE = http://ecls.sourceforge.net/
SUBST_VARS =V
EXTRACT_SUFX = .tgz
@@ -41,6 +39,8 @@ LIB_DEPENDS += devel/gmp \
devel/boehm-gc,-main \
devel/boehm-gc,-atomic \
devel/libffi
+
+TEST_DEPENDS = ${BASE_PKGPATH}
WANTLIB += atomic_ops c ffi gc gmp m pthread
Index: distinfo
===
RCS file: /cvs/ports/lang/ecl/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo 11 Jun 2013 10:30:54 - 1.6
+++ distinfo 21 Aug 2015 07:26:37 -
@@ -1,2 +1,2 @@
-SHA256 (ecl-13.5.1.tgz) = +RxXzgZf6XSLyBBOGR5LLc/oVNY0MV/ngA3QphNHLKI=
-SIZE (ecl-13.5.1.tgz) = 9401163
+SHA256 (ecl-15.3.7.tgz) = Lcb/u/Hgp7EyPUmpkbofAFEnyj4VNlHZG6nmW9rslI8=
+SIZE (ecl-15.3.7.tgz) = 8755180
Index: patches/patch-src_c_unixint_d
Re: [update] lang/node 0.10.35 -> 4.2.1 (the freedom release)!
On Tue, Oct 20, 2015 at 05:40:13PM -0600, Aaron Bieber wrote:
[...]
>
> New version that includes an above fix and a fix for node-gyp, I
> mistakenly thought it was fixed when I removed the patch.
I made some changes to your diff. The port still linking against
libressl but I don't have more time today to look at this. Something
is using the wrong order for the directories, look the output of make.
- Why are you using gmake instead of ninja?
- "CCFLAGS" is not used in nodejs (run a grep within the code).
Index: Makefile
===
RCS file: /cvs/ports/lang/node/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile3 Feb 2015 15:48:20 - 1.33
+++ Makefile22 Oct 2015 02:43:06 -
@@ -8,7 +8,7 @@ ONLY_FOR_ARCHS= amd64 i386
COMMENT= V8 JavaScript for clients and servers
-NODE_VERSION= v0.10.35
+NODE_VERSION= v4.2.1
DISTNAME= node-${NODE_VERSION}
PKGNAME= ${DISTNAME:S/v//g}
@@ -24,33 +24,46 @@ PERMIT_PACKAGE_CDROM= Yes
MASTER_SITES= ${HOMEPAGE}dist/${NODE_VERSION}/
-MODULES= lang/python
+MODULES= gcc4 \
+ lang/python
-WANTLIB += c crypto execinfo kvm m pthread ssl stdc++ util z
+MODGCC4_LANGS =c c++
+MODGCC4_ARCHS =*
-LIB_DEPENDS= devel/libexecinfo
+WANTLIB += c execinfo kvm m pthread util z
+
+LIB_DEPENDS= devel/libexecinfo \
+ security/openssl
+
+NODE_ARCH= i386
+
+.if ${MACHINE_ARCH} == "amd64"
+NODE_ARCH= x86_64
+.endif
USE_GMAKE= Yes
-BUILD_DEPENDS= devel/gyp \
+BUILD_DEPENDS= devel/ninja \
sysutils/flock
-# node-gyp uses it at runtime
RUN_DEPENDS= devel/gmake \
- devel/gyp \
sysutils/flock
-TEST_TARGET= test
-CONFIGURE_STYLE= simple
-CONFIGURE_ARGS= --openssl-use-sys \
+TEST_TARGET= test
+CONFIGURE_STYLE=simple
+CONFIGURE_ARGS=--prefix=${PREFIX} \
+ --shared-openssl \
+ --shared-openssl-includes="${LOCALBASE}/include/eopenssl" \
+ --shared-openssl-libpath="${LOCALBASE}/lib/eopenssl" \
--shared-zlib
SUBST_VARS+= CFLAGS
-SUBST_VARS+= PREFIX
-SUBST_VARS+= LOCALBASE
-SUBST_VARS+= DISTFILES
+SUBST_VARS+= PREFIX
+SUBST_VARS+= LOCALBASE
+SUBST_VARS+= DISTFILES
+SUBST_VARS+= NODE_ARCH
-MAKE_ENV+= V=1 CXX=c++ CCFLAGS+="${CFLAGS}" CXXFLAGS="${CXXFLAGS}"
+MAKE_ENV+= V=1 CXX="${CXX}" CCFLAGS+="${CFLAGS}" CXXFLAGS="${CXXFLAGS}"
NO_CCACHE= Yes
Index: distinfo
===
RCS file: /cvs/ports/lang/node/distinfo,v
retrieving revision 1.23
diff -u -p -r1.23 distinfo
--- distinfo3 Feb 2015 15:48:20 - 1.23
+++ distinfo22 Oct 2015 02:43:06 -
@@ -1,2 +1,2 @@
-SHA256 (node-v0.10.35.tar.gz) = AENla7FyTLCdvclgov1u4307rbL5x1VistESNdqkCgM=
-SIZE (node-v0.10.35.tar.gz) = 14417025
+SHA256 (node-v4.2.1.tar.gz) = iGG59MO02zgPzaGacQwEMMPWLQPuF2xk22Pu+VpnJmM=
+SIZE (node-v4.2.1.tar.gz) = 22505860
Index: patches/patch-common_gypi
===
RCS file: /cvs/ports/lang/node/patches/patch-common_gypi,v
retrieving revision 1.5
diff -u -p -r1.5 patch-common_gypi
--- patches/patch-common_gypi 10 Jul 2014 19:53:30 - 1.5
+++ patches/patch-common_gypi 22 Oct 2015 02:43:06 -
@@ -1,17 +1,14 @@
$OpenBSD: patch-common_gypi,v 1.5 2014/07/10 19:53:30 landry Exp $
common.gypi.orig Fri May 2 02:47:47 2014
-+++ common.gypiThu Jul 10 16:15:20 2014
-@@ -170,9 +170,12 @@
+--- common.gypi.orig Wed Jan 14 10:19:02 2015
common.gypiWed Jan 14 10:21:39 2015
+@@ -274,6 +274,10 @@
+ 'ldflags': [
+ '-Wl,--export-dynamic',
],
- }],
- [ 'OS=="linux" or OS=="freebsd" or OS=="openbsd" or OS=="solaris"', {
--'cflags': [ '-Wall', '-Wextra', '-Wno-unused-parameter', '-pthread',
],
-+'cflags': [ '-Wall', '-Wextra', '-Wno-unused-parameter', '-pthread',
'-I${LOCALBASE}/include'],
- 'cflags_cc': [ '-fno-rtti', '-fno-exceptions' ],
- 'ldflags': [ '-pthread', '-rdynamic' ],
-+ 'libraries': [
-+'-L${LOCALBASE}/lib'
-+ ],
- 'target_conditions': [
- ['_type=="static_library"', {
- 'standalone_static_library': 1, # disable thin archive which
needs binutils >= 2.19
++ }],
++ ['OS=="openbsd"', {
++'cflags': [ '-I${LOCALBASE}/include/eopenssl',
'-I${LOCALBASE}/include' ],
++'libraries': [ '-L${LOCALBASE}/lib/eopenssl', '-L${LOCALBASE}/lib' ],
+ }]
+ ],
+ }
Index: patches/patch-deps_npm_node_modules_node-gyp_lib_configure_js
===
RCS file:
/cvs/ports/lang/node/patches/patch-deps_npm_node_modules_node-gyp_lib_configure_js,v
retrieving revision 1.3
diff -u -p -r1.3
Re: NEW: www/tbb - Tor Browser Bundle
On Mon, Nov 16, 2015 at 10:22:32AM -0600, attila wrote: > > Above and beyond what you point out, there's an issue I was hoping to > get feedback on: should noscript and https-everywhere be packaged > separatedly somehow or stay combined into tbb? Bundled with TBB. I'm not a fan of browser-extension-as-packages. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Clarification about out-of-date script
On Fri, Nov 06, 2015 at 08:50:57PM +0100, Markus Lude wrote: > On Fri, Nov 06, 2015 at 05:53:51PM +0100, Juan Francisco Cantero Hurtado > wrote: > > On Fri, Nov 06, 2015 at 09:18:09AM +0500, ?? ?? wrote: > > > On Wed, Nov 04, 2015 at 09:46:27AM +, Stuart Henderson wrote: > > > > On 2015/11/03 10:38, ?? ?? wrote: > > > > > On Tue, Nov 03, 2015 at 02:19:51AM +0100, Juan Francisco Cantero > > > > > Hurtado wrote: > > > > > > On Sun, Nov 01, 2015 at 11:41:21PM +0500, ?? ?? > > > > > > wrote: > > > > > > > Here is output on my system, OpenBSD 5.8, from out-of-date script: > > > > > > > > > > > > > > databases/postgresql,-server # @libxml-2.9.2p1 -> > > > > > > > @libxml-2.9.2p2 > > > > > > > devel/quirks # always-update -> quirks-2.114 > > > > > > > editors/libreoffice,-main # @libxslt-1.1.28p2 -> > > > > > > > @libxslt-1.1.28p3 > > > > > > > misc/shared-mime-info # @libxml-2.9.2p1 -> > > > > > > > @libxml-2.9.2p2 > > > > > > > multimedia/libbluray # @libxml-2.9.2p1 -> > > > > > > > @libxml-2.9.2p2 > > > > > > > print/cups,-libs # @gnutls-3.3.16 -> > > > > > > > @gnutls-3.3.16p0 > > > > > > > textproc/raptor# @libxslt-1.1.28p2 -> > > > > > > > @libxslt-1.1.28p3 > > > > > > > x11/gnome/librsvg # > > > > > > > @gdk-pixbuf-2.30.8p1,@libxml-2.9.2p1 -> > > > > > > > @gdk-pixbuf-2.30.8p3,@libxml-2.9.2p2 > > > > > > > x11/gtk+2,-main# @gdk-pixbuf-2.30.8p1 -> > > > > > > > @gdk-pixbuf-2.30.8p3 > > > > > > > x11/gtk+3,-guic# @gdk-pixbuf-2.30.8p1 -> > > > > > > > @gdk-pixbuf-2.30.8p3 > > > > > > > x11/kde/libs3,-main# @libxslt-1.1.28p2 -> > > > > > > > @libxslt-1.1.28p3 > > > > > > > > > > > > > > Am I right, that left column is ports/packages that can be > > > > > > > updated; right > > > > > > > column is reason why they need to be updated? > > > > > > > > > > > > Yes. > > > > > > > > > > > > > Also is it true that in my case I can ignore all this updates > > > > > > > because > > > > > > > all ports from left column are dynamicaly linked with already > > > > > > > updated > > > > > > > library from right column? > > > > > > > > > > > > No. Those ports use the outdated version of the library. > > > > > > > > > > Can You elaborate, please, I don't understand. E.g. shared-mime-info. > > > > > > > > > > $ ldd /usr/local/bin/update-mime-database | grep libxml > > > > > 1d0114c0 1d011515f000 rlib 01 0 > > > > > /usr/local/lib/libxml2.so.15.1 > > > > > > > > > > $ pkg_info | grep libxml > > > > > > > > > > > > > > > libxml-2.9.2p2 XML parsing library > > > > > > > > > > So libxml already updated. If I understand correctly: if libxml > > > > > updated and update-mime-database > > > > > _dynamicaly_ linked to it there is no need further intervention, is > > > > > not is so? > > > > > > > > > > Thanks. > > > > > > > > > > > > > Look in e.g. /var/db/pkg/shared-mime-info-1.5/+CONTENTS and you'll > > > > see that it records the dependency like this > > > > > > > > @depend textproc/libxml,-main:libxml-*:libxml-2.9.2p2 > > > > ... > > > > @wantlib xml2.15.1 > > > > > > > > out-of-date reports on any packages where the @depend line is out > > > > of date compared to the ports tree, even though the shared library > > > > itself (noted in the @wantlib line) hasn't changed incompatibly. > > > > > > I'm sorry for reiterate it over again and thanks for detailed > > > clarification. But if I understand it correctly I'am right with my > > > example above with update-mime-database? I already have newest > > > version libxml installed so de-facto there is no need updating > > > update-mime-database in such case? > > > > You doesn't have the newest version. There is always a good reason to > > change the REVISION of a port (look at the pX suffix). In this case, > > the version 2.9.2p2 includes two security fixes. > > He also has the new version installed. He just have a few packages > installed, which were build against the old version. If they use the > dynamic library, there's just the new one. Argh, you're right. I didn't have enough sleep hours this week. > > > In short, always update your packages. No exception. > > It's my prefered way too. No need to see if something still may use an > older library. > > Regards, > Markus > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Clarification about out-of-date script
On Tue, Nov 03, 2015 at 10:38:17AM +0500, Артур Истомин wrote: > On Tue, Nov 03, 2015 at 02:19:51AM +0100, Juan Francisco Cantero Hurtado > wrote: > > On Sun, Nov 01, 2015 at 11:41:21PM +0500, Артур Истомин wrote: > > > Here is output on my system, OpenBSD 5.8, from out-of-date script: > > > > > > databases/postgresql,-server # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > > devel/quirks # always-update -> quirks-2.114 > > > editors/libreoffice,-main # @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > > > misc/shared-mime-info # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > > multimedia/libbluray # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > > print/cups,-libs # @gnutls-3.3.16 -> @gnutls-3.3.16p0 > > > textproc/raptor# @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > > > x11/gnome/librsvg # @gdk-pixbuf-2.30.8p1,@libxml-2.9.2p1 -> > > > @gdk-pixbuf-2.30.8p3,@libxml-2.9.2p2 > > > x11/gtk+2,-main# @gdk-pixbuf-2.30.8p1 -> > > > @gdk-pixbuf-2.30.8p3 > > > x11/gtk+3,-guic# @gdk-pixbuf-2.30.8p1 -> > > > @gdk-pixbuf-2.30.8p3 > > > x11/kde/libs3,-main# @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > > > > > > Am I right, that left column is ports/packages that can be updated; right > > > column is reason why they need to be updated? > > > > Yes. > > > > > Also is it true that in my case I can ignore all this updates because > > > all ports from left column are dynamicaly linked with already updated > > > library from right column? > > > > No. Those ports use the outdated version of the library. > > Can You elaborate, please, I don't understand. E.g. shared-mime-info. > > $ ldd /usr/local/bin/update-mime-database | grep libxml > 1d0114c0 1d011515f000 rlib 01 0 > /usr/local/lib/libxml2.so.15.1 > > $ pkg_info | grep libxml > > > libxml-2.9.2p2 XML parsing library > > So libxml already updated. If I understand correctly: if libxml updated and > update-mime-database > _dynamicaly_ linked to it there is no need further intervention, is not is so? If a new version of a port doesn't change the version number of the lib, then the ports which depend of the lib will use the updated version. If there is an increase in the version number of the lib (SHARED_LIBS in the Makefile, unrelated to the version of the port), then the ports will use the outdated library. "pkg_info -A | grep ^\\." shows the outdated libs. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Clarification about out-of-date script
On Fri, Nov 06, 2015 at 09:18:09AM +0500, Артур Истомин wrote: > On Wed, Nov 04, 2015 at 09:46:27AM +, Stuart Henderson wrote: > > On 2015/11/03 10:38, Артур Истомин wrote: > > > On Tue, Nov 03, 2015 at 02:19:51AM +0100, Juan Francisco Cantero Hurtado > > > wrote: > > > > On Sun, Nov 01, 2015 at 11:41:21PM +0500, Артур Истомин wrote: > > > > > Here is output on my system, OpenBSD 5.8, from out-of-date script: > > > > > > > > > > databases/postgresql,-server # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > > > > devel/quirks # always-update -> quirks-2.114 > > > > > editors/libreoffice,-main # @libxslt-1.1.28p2 -> > > > > > @libxslt-1.1.28p3 > > > > > misc/shared-mime-info # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > > > > multimedia/libbluray # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > > > > print/cups,-libs # @gnutls-3.3.16 -> @gnutls-3.3.16p0 > > > > > textproc/raptor# @libxslt-1.1.28p2 -> > > > > > @libxslt-1.1.28p3 > > > > > x11/gnome/librsvg # @gdk-pixbuf-2.30.8p1,@libxml-2.9.2p1 > > > > > -> @gdk-pixbuf-2.30.8p3,@libxml-2.9.2p2 > > > > > x11/gtk+2,-main# @gdk-pixbuf-2.30.8p1 -> > > > > > @gdk-pixbuf-2.30.8p3 > > > > > x11/gtk+3,-guic# @gdk-pixbuf-2.30.8p1 -> > > > > > @gdk-pixbuf-2.30.8p3 > > > > > x11/kde/libs3,-main# @libxslt-1.1.28p2 -> > > > > > @libxslt-1.1.28p3 > > > > > > > > > > Am I right, that left column is ports/packages that can be updated; > > > > > right > > > > > column is reason why they need to be updated? > > > > > > > > Yes. > > > > > > > > > Also is it true that in my case I can ignore all this updates because > > > > > all ports from left column are dynamicaly linked with already updated > > > > > library from right column? > > > > > > > > No. Those ports use the outdated version of the library. > > > > > > Can You elaborate, please, I don't understand. E.g. shared-mime-info. > > > > > > $ ldd /usr/local/bin/update-mime-database | grep libxml > > > 1d0114c0 1d011515f000 rlib 01 0 > > > /usr/local/lib/libxml2.so.15.1 > > > > > > $ pkg_info | grep libxml > > > > > > > > > libxml-2.9.2p2 XML parsing library > > > > > > So libxml already updated. If I understand correctly: if libxml updated > > > and update-mime-database > > > _dynamicaly_ linked to it there is no need further intervention, is not > > > is so? > > > > > > Thanks. > > > > > > > Look in e.g. /var/db/pkg/shared-mime-info-1.5/+CONTENTS and you'll > > see that it records the dependency like this > > > > @depend textproc/libxml,-main:libxml-*:libxml-2.9.2p2 > > ... > > @wantlib xml2.15.1 > > > > out-of-date reports on any packages where the @depend line is out > > of date compared to the ports tree, even though the shared library > > itself (noted in the @wantlib line) hasn't changed incompatibly. > > I'm sorry for reiterate it over again and thanks for detailed > clarification. But if I understand it correctly I'am right with my > example above with update-mime-database? I already have newest > version libxml installed so de-facto there is no need updating > update-mime-database in such case? You doesn't have the newest version. There is always a good reason to change the REVISION of a port (look at the pX suffix). In this case, the version 2.9.2p2 includes two security fixes. In short, always update your packages. No exception. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Clarification about out-of-date script
On Sun, Nov 01, 2015 at 11:41:21PM +0500, Артур Истомин wrote: > Here is output on my system, OpenBSD 5.8, from out-of-date script: > > databases/postgresql,-server # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > devel/quirks # always-update -> quirks-2.114 > editors/libreoffice,-main # @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > misc/shared-mime-info # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > multimedia/libbluray # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > print/cups,-libs # @gnutls-3.3.16 -> @gnutls-3.3.16p0 > textproc/raptor# @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > x11/gnome/librsvg # @gdk-pixbuf-2.30.8p1,@libxml-2.9.2p1 -> > @gdk-pixbuf-2.30.8p3,@libxml-2.9.2p2 > x11/gtk+2,-main# @gdk-pixbuf-2.30.8p1 -> @gdk-pixbuf-2.30.8p3 > x11/gtk+3,-guic# @gdk-pixbuf-2.30.8p1 -> @gdk-pixbuf-2.30.8p3 > x11/kde/libs3,-main# @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > > Am I right, that left column is ports/packages that can be updated; right > column is reason why they need to be updated? Yes. > Also is it true that in my case I can ignore all this updates because > all ports from left column are dynamicaly linked with already updated > library from right column? No. Those ports use the outdated version of the library. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Qt 5 and C++11
On Sun, Oct 18, 2015 at 09:46:39AM +0200, Caspar Schutijser wrote: > On Sat, Oct 17, 2015 at 09:45:22PM +0100, Stuart Henderson wrote: > > This is mostly setup for doing builds as part of ports. And in > > that case, if you're writing a port which uses Qt5, you would set > > MODULES=x11/qt5 which automatically inserts a link or wrapper for the > > correct compiler at the head of the path so that calling it as 'g++' > > works. > > That's true. But I should have mentioned that I ran into this issue > because I'm working on an update for the Qt Creator port. When creating > a "Qt Quick Application", Qt Creator calls qmake-qt5 to create a > Makefile which then calls g++ with the -std=c++11 flag. In that context, > it is a problem that g++ doesn't actually support C++11. You could add a README file to qtcreator with the info about QMAKE_CXX. Or modify the launcher of qtcreator with the variable. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Threading support in lang/sbcl
I have the same question for other port. How to create flavors only
for some architectures?
On Sun, Oct 11, 2015 at 11:36:09PM +0200, Gregor Best wrote:
> > [...]
> > When threading support on openbsd is deemed mature enough, only then
> > will it become enabled in the default flavor.
> > [...]
>
> I've recently had a go at it again because I need threads for cl-rabbit.
> I've attached a patch that adds a 'threads' flavor, but haven't yet
> figured out how to disable the flavor for powerpc.
>
> Would you consider adding thread support as a flavor until it
> stabilized? How can I help with the powerpc port?
>
> --
> Gregor
> --
>
> Index: Makefile
> ===
> RCS file: /mnt/media/cvs/ports/lang/sbcl/Makefile,v
> retrieving revision 1.24
> diff -u -p -r1.24 Makefile
> --- Makefile 31 Aug 2015 18:37:30 - 1.24
> +++ Makefile 11 Oct 2015 21:28:20 -
> @@ -4,12 +4,14 @@
> ONLY_FOR_ARCHS = amd64 i386 powerpc
>
> COMMENT= compiler and runtime system for ANSI Common Lisp
> +COMMENT-threads= ${COMMENT} (with native threading support)
>
> V = 1.2.14
> DISTNAME=sbcl-${V}-source
> PKGNAME= sbcl-${V}
> WRKDIST= ${WRKDIR}/sbcl-${V}
> EXTRACT_SUFX=.tar.bz2
> +REVISION=1
>
> CATEGORIES= lang
> HOMEPAGE=http://www.sbcl.org/
> @@ -26,6 +28,7 @@ MODGCC4_LANGS= c
>
> WANTLIB= c m util
>
> +FLAVORS= threads
> PSEUDO_FLAVORS= native_bootstrap
> FLAVOR?=
>
> @@ -44,6 +47,12 @@ PORTHOME= ${TMPDIR}
> MAKE_ENV=GNUMAKE=${GMAKE} INSTALL_ROOT=${PREFIX} \
> MAN_DIR=${PREFIX}/man INFO_DIR=${PREFIX}/info
>
> +.if ${FLAVOR:Mthreads}
> +MAKE_ENV += LINKFLAGS="-pthread" LDFLAGS="-pthread"
> +CFLAGS += -pthread
> +BUILD_EXTRA += --with-sb-thread
> +.endif
> +
> # Upstream asks that packagers append something like this to the
> # version to distinguish official tarballs from third-party packages.
> .if defined(REVISION) && !empty(REVISION)
> @@ -61,7 +70,8 @@ pre-configure:
>
> do-build:
> cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} /bin/sh make.sh \
> - --prefix=${PREFIX} --xc-host="${BOOTSTRAP_CMD}"
> + --prefix=${PREFIX} --xc-host="${BOOTSTRAP_CMD}" \
> + ${BUILD_EXTRA}
> cd ${WRKSRC}/doc/manual && touch sbcl.texinfo && \
> ${SETENV} ${MAKE_ENV} ${GMAKE} asdf.info sbcl.info
>
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: update chicken-4.10.0
#\x))) -+ (bar (object-evict y))) -+ (assert (not (substring-index y foo 30 -+ -+(assert (string=? bde (string-translate* abcd -+ '((a . b) -+ (b . ) -+ (c . d) -+ (d . e) -+(assert (string=? bc (string-translate* abc -+ '((ab . b) -+(bc . WRONG) -+(assert (string=? x (string-translate* ab '((ab . x) -+(assert (string=? xy (string-translate* xyz '((z . ) - - ;; topological-sort - -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [patch] Test target PATH
I see the problem now. You can remove the symlinks from ${WRKDIR}/bin with:
pre-test:
---rm -f ${WRKDIR}/bin/chgrp
The problem with your patch is that you're modifying the environment
for thousands of ports and we can't test manually every port to see if
your changes are breaking something.
On Thu, Aug 27, 2015 at 12:47:24PM -0500, Matthew Martin wrote:
On Thu, Aug 27, 2015 at 11:50:19AM +0200, Juan Francisco Cantero Hurtado
wrote:
Can you try this in your port?
TEST_ENV=PATH=${PATH}:YOURPATH or TEST_ENV=PATH=YOURPATH:${PATH}
I don't think you're following the problem. It's not that anything needs
to be added to PATH; it's that the first element needs to be removed.
The PATH that ports uses is set by PORTPATH to be
${WRKDIR}/bin:/usr/bin:/bin:/usr/sbin:/sbin:${DEPBASE}/bin:${LOCALBASE}/bin:${X11BASE}/bin
With make test, ${WRKDIR}/bin only has install in it, so chgrp runs
/bin/chgrp. When make fake is run, a symlink from ${WRKDIR}/bin/chgrp to
/bin/echo is added. This resuls in make fake test using the chgrp in
${WRKDIR}/bin and the test failing since that chgrp doesn't change the
group. I am proposing to remove ${WRKDIR}/bin from PATH for tests so
that all commands work as expected.
-Matthew Martin
On Thu, Aug 27, 2015 at 12:37:22AM -0500, Matthew Martin wrote:
The zsh port fails an additional test when invoked with make clean fake
test instead of make clean test. This is because in its tests it
touch zerolength
chgrp $EGID zerolength
and then tests that zerolength has a group of EGID. Since make fake puts
a symlink in ${WRKDIR}/bin from chgrp to /bin/echo and ${WRKDIR}/bin is
first in the environment's PATH, the chgrp does nothing, and test
C02cond fails. With the below patch it completes successfully.
This patch does slightly change behavior as PATH can no longer be set in
TEST_ENV (which no ports seem to do anyway) and install is no longer the
perl wrapper in ${WRKDIR}/bin; however, during tests we probably
shouldn't be messing with install either.
- Matthew Martin
Index: infrastructure/mk/bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1298
diff -u -p -r1.1298 bsd.port.mk
--- infrastructure/mk/bsd.port.mk 19 Jul 2015 17:31:44 - 1.1298
+++ infrastructure/mk/bsd.port.mk 27 Aug 2015 03:53:55 -
@@ -809,7 +809,7 @@ FAKE_TARGET ?= ${INSTALL_TARGET}
TEST_TARGET ?= test
TEST_FLAGS ?=
-TEST_ENV ?=
+TEST_ENV +=
PATH=/usr/bin:/bin:/usr/sbin:/sbin:${DEPBASE}/bin:${LOCALBASE}/bin:${X11BASE}/bin
ALL_TEST_FLAGS = ${MAKE_FLAGS} ${TEST_FLAGS}
ALL_TEST_ENV = ${MAKE_ENV} ${TEST_ENV}
TEST_LOGFILE ?= ${WRKDIR}/test.log
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: [patch] Test target PATH
Can you try this in your port?
TEST_ENV=PATH=${PATH}:YOURPATH or TEST_ENV=PATH=YOURPATH:${PATH}
On Thu, Aug 27, 2015 at 12:37:22AM -0500, Matthew Martin wrote:
The zsh port fails an additional test when invoked with make clean fake
test instead of make clean test. This is because in its tests it
touch zerolength
chgrp $EGID zerolength
and then tests that zerolength has a group of EGID. Since make fake puts
a symlink in ${WRKDIR}/bin from chgrp to /bin/echo and ${WRKDIR}/bin is
first in the environment's PATH, the chgrp does nothing, and test
C02cond fails. With the below patch it completes successfully.
This patch does slightly change behavior as PATH can no longer be set in
TEST_ENV (which no ports seem to do anyway) and install is no longer the
perl wrapper in ${WRKDIR}/bin; however, during tests we probably
shouldn't be messing with install either.
- Matthew Martin
Index: infrastructure/mk/bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1298
diff -u -p -r1.1298 bsd.port.mk
--- infrastructure/mk/bsd.port.mk 19 Jul 2015 17:31:44 - 1.1298
+++ infrastructure/mk/bsd.port.mk 27 Aug 2015 03:53:55 -
@@ -809,7 +809,7 @@ FAKE_TARGET ?= ${INSTALL_TARGET}
TEST_TARGET ?= test
TEST_FLAGS ?=
-TEST_ENV ?=
+TEST_ENV +=
PATH=/usr/bin:/bin:/usr/sbin:/sbin:${DEPBASE}/bin:${LOCALBASE}/bin:${X11BASE}/bin
ALL_TEST_FLAGS = ${MAKE_FLAGS} ${TEST_FLAGS}
ALL_TEST_ENV = ${MAKE_ENV} ${TEST_ENV}
TEST_LOGFILE ?= ${WRKDIR}/test.log
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: update chicken-4.10.0
On Thu, Aug 27, 2015 at 12:40:43PM +0300, Timo Myyrä wrote:
Hmm,
I was remaking my changes but I can't seem to get the core package to work.
I've made changes to the bootstrap package, built and installed it.
When I tried to extract the chicken core I got following:
$ cd /usr/ports/mystuff/lang/chicken/core
$ make depends
=== chicken-4.10.0 depends on: chicken-bootstrap-=4.10.0 - default
chicken-bootstrap-4.9.0.1 does not match
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2112
'/usr/ports/pobj/chicken-4.10.0/.dep-STEM-ge-4.10.0-lang-chicken-bootstrap')
*** Error 1 in /usr/ports/mystuff/lang/chicken/core
(/usr/ports/infrastructure/mk/bsd.port.mk:2488 'depends')
$ pkg_info | grep chicken
chicken-bootstrap-4.10.0 practical and portable Scheme system
$
I have the new bootstrap installed but 'make depends' doesn't seem to find it.
I then tested it a bit by changing the core/Makefile BUILD_DEPENDS like
follows:
-BUILD_DEPENDS= lang/chicken/bootstrap=${V}
+BUILD_DEPENDS= lang/chicken/bootstrap=4.9.0
The build proceeded a bit further:
$ make depends
=== chicken-4.10.0 depends on: chicken-bootstrap-=4.9.0 -
chicken-bootstrap-4.10.0
=== chicken-4.10.0 depends on: gmake-* - gmake-4.1p0
=== Verifying specs: c m pthread
=== found c.81.0 m.9.0 pthread.19.0
=== Verifying specs: c m pthread
=== found c.81.0 m.9.0 pthread.19.0
=== chicken-4.10.0 depends on: chicken-* - not found
=== Verifying install for chicken-* in lang/chicken/core
=== Checking files for chicken-4.9.0.1p1
`/usr/ports/distfiles/chicken-4.9.0.1.tar.gz' is up to date.
(SHA256) chicken-4.9.0.1.tar.gz: OK
=== chicken-4.9.0.1p1 depends on: chicken-bootstrap-=4.9.0.1 -
chicken-bootstrap-4.10.0
...
The odd thing here is that now chicken-4.10.0 seems to depend on chicken-* and
tries to build the old chicken version although it should only require the
bootstrap to build. I'm a bit lost why the ports behaves like this.
chicken-core uses chicken-bootstrap from lang/chicken instead of
mystuff/lang/chicken. The ports framework will pick always the
dependencies from ${PORTSDIR} which is usually /usr/ports.
Move your patches to lang/chicken and the port will work
fine. Yesterday, I tested the update on sparc64 and it passed the
tests.
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: update chicken-4.10.0
Sorry for the double mail.
Can you remove the patch bootstrap/patches/patch-Makefile_bsd and to
modify C_COMPILER_OPTIONS within core/patches/patch-Makefile_bsd?
The GCC version in base supports -fwrapv.
On Wed, Aug 26, 2015 at 06:00:33PM +0200, Juan Francisco Cantero Hurtado wrote:
Can you update the patch?
Your core/patches/patch-data-structures_scm is outdated.
On Wed, Aug 12, 2015 at 09:54:56PM +0300, Timo Myyrä wrote:
Hi,
Here's an chicken update waiting for ports unlock.
Lightly tested on my thinkpad.
Timo
Index: Makefile.inc
===
RCS file: /cvs/ports/lang/chicken/Makefile.inc,v
retrieving revision 1.4
diff -u -u -p -r1.4 Makefile.inc
--- Makefile.inc4 Jul 2014 18:26:49 - 1.4
+++ Makefile.inc7 Aug 2015 19:38:47 -
@@ -2,7 +2,7 @@
COMMENT= practical and portable Scheme system
-V= 4.9.0.1
+V= 4.10.0
DISTNAME= chicken-${V}
MAINTAINER=Timo Myyra timo.my...@wickedbsd.net
@@ -30,6 +30,6 @@ FAKE_FLAGS= PREFIX=${TRUEPREFIX}
# Based on param.h:MACHINE_STACK_GROWS_UP
pre-build:
.if ${MACHINE_ARCH} == hppa || ${MACHINE_ARCH} == hppa64
- perl -pi -e 's/C_STACK_GROWS_DOWNWARD 1/C_STACK_GROWS_DOWNWARD 0/g'
${WRKSRC}/Makefile.bsd
+ sed -i 's/C_STACK_GROWS_DOWNWARD 1/C_STACK_GROWS_DOWNWARD 0/g'
${WRKSRC}/Makefile.bsd
.endif
Index: bootstrap/distinfo
===
RCS file: /cvs/ports/lang/chicken/bootstrap/distinfo,v
retrieving revision 1.2
diff -u -u -p -r1.2 distinfo
--- bootstrap/distinfo 4 Jul 2014 18:26:49 - 1.2
+++ bootstrap/distinfo 7 Aug 2015 19:38:47 -
@@ -1,2 +1,2 @@
-SHA256 (chicken-4.9.0.1.tar.gz) =
BN98Q5w2/BZEa9+hhuenAlj5EdLYJrUhao5rHLKqKBU=
-SIZE (chicken-4.9.0.1.tar.gz) = 4023371
+SHA256 (chicken-4.10.0.tar.gz) =
Dgf1q80RlhmGlQ2+qlpA20Ffihtl2v+cMA6bBbM0iZs=
+SIZE (chicken-4.10.0.tar.gz) = 4020442
Index: core/Makefile
===
RCS file: /cvs/ports/lang/chicken/core/Makefile,v
retrieving revision 1.5
diff -u -u -p -r1.5 Makefile
--- core/Makefile 16 Jun 2015 14:45:04 - 1.5
+++ core/Makefile 7 Aug 2015 19:38:47 -
@@ -2,9 +2,7 @@
SHARED_ONLY= Yes
-REVISION= 1
-
-SHARED_LIBS= chicken 3.0
+SHARED_LIBS= chicken 4.0 # 7
TEST_TARGET= check
TEST_DEPENDS= ${BUILD_PKGPATH}
Index: core/distinfo
===
RCS file: /cvs/ports/lang/chicken/core/distinfo,v
retrieving revision 1.2
diff -u -u -p -r1.2 distinfo
--- core/distinfo 4 Jul 2014 18:26:49 - 1.2
+++ core/distinfo 7 Aug 2015 19:38:47 -
@@ -1,2 +1,2 @@
-SHA256 (chicken-4.9.0.1.tar.gz) =
BN98Q5w2/BZEa9+hhuenAlj5EdLYJrUhao5rHLKqKBU=
-SIZE (chicken-4.9.0.1.tar.gz) = 4023371
+SHA256 (chicken-4.10.0.tar.gz) =
Dgf1q80RlhmGlQ2+qlpA20Ffihtl2v+cMA6bBbM0iZs=
+SIZE (chicken-4.10.0.tar.gz) = 4020442
Index: core/patches/patch-Makefile_bsd
===
RCS file: /cvs/ports/lang/chicken/core/patches/patch-Makefile_bsd,v
retrieving revision 1.2
diff -u -u -p -r1.2 patch-Makefile_bsd
--- core/patches/patch-Makefile_bsd 4 Jul 2014 18:26:49 - 1.2
+++ core/patches/patch-Makefile_bsd 7 Aug 2015 19:38:47 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-Makefile_bsd,v 1.2 2014/07/04 18:26:49 juanfra Exp $
Makefile.bsd.orig Wed Jun 18 16:52:58 2014
-+++ Makefile.bsd Wed Jun 18 16:53:35 2014
-@@ -36,7 +36,7 @@ SRCDIR = ./
+--- Makefile.bsd.orig Fri Jul 24 14:04:24 2015
Makefile.bsd Fri Jul 24 20:55:28 2015
+@@ -31,7 +31,7 @@ SRCDIR ?= ./
ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh)
# options
@@ -10,7 +10,7 @@ $OpenBSD: patch-Makefile_bsd,v 1.2 2014/
ifdef DEBUGBUILD
C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused
-@@ -50,10 +50,9 @@ endif
+@@ -45,10 +45,9 @@ endif
LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared
LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -shared
-Wl,-R$(RUNTIME_LINKER_PATH) -Wl,-L.
LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,-R$(RUNTIME_LINKER_PATH)
Index: core/patches/patch-data-structures_scm
===
RCS file: core/patches/patch-data-structures_scm
diff -N core/patches/patch-data-structures_scm
--- core/patches/patch-data-structures_scm 30 Jan 2015 14:30:30 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,37 +0,0 @@
-$OpenBSD: patch-data-structures_scm,v 1.1 2015/01/30 14:30:30 jasper Exp $
-
-Security fix for CVE-2014-9651
-http://lists.nongnu.org/archive/html/chicken-hackers/2014-12/msg0.html
-
data-structures.scm.orig Sat
Re: [NEW] fonts/huertatipografica-fonts
On 09/23/2015 04:14 AM, George Rosamond wrote: Four fonts from Huerta Tipografica. I used the same Makefile-style as fonts/league-fonts for dealing with four different DISTFILES with extraction, etc. DESCR: "A collection of fonts from Huerta Tipografica based in Madrid, Spain." They are from Argentina! :) I would prefer "A collection of fonts from Huerta Tipografica, a type foundry based in Argentina".
Re: Please add ICU as dependency to Boost (i.e. change the "--without-icu" to "--with-icu") - thoughts?
On Thu, Dec 17, 2015 at 06:27:07AM +0800, Tinker wrote: > Wait, in the interim, the brave user who wants ICU support system-wide now, > and who has ICU already installed in the system, can just switch the > "--without-icu" part to "--with-icu" in /usr/ports/devel/boost/Makefile , > and do "make; make install" right? $ make clean=all $ make $ make fake $ make port-lib-depends-check # fix WANTLIB $ make update-plist $ make reinstall > > > That will not break binary compatibility with precompiled packages, the only > thing would be that if some package is specifically incompatible with > Boost's ICU support, it'd go into undefined behavior, right? > > > On 2015-12-17 02:40, Landry Breuil wrote: > >On Wed, Dec 16, 2015 at 01:40:47PM +0100, Antoine Jacoutot wrote: > >>On Wed, Dec 16, 2015 at 01:32:21PM +0100, Jérémie Courrèges-Anglas > >>wrote: > >>> Tinker <ti...@openmailbox.org> writes: > >>> > >>> > On 2015-12-16 05:04, j...@wxcvbn.org wrote: > >>> >> Tinker <ti...@openmailbox.org> writes: > >>> >> > >>> >>> What would the decision be based on? > >>> >> > >>> >> I think that those points should be enough. > >>> >> - good reasons to use ICU in boost, not just "I need the ICU parts of > >>> >> Boost.". What would be the benefit for the ports tree? > >>> > > >>> > I need normalize() to do Unicode normalization! > >>> > >>> I'm glad to hear that you want to do Unicode normalization using ICU, > >>> that is not a valid answer to what I said above. > >>> > >>> We have one report here: > >>> > >>> http://marc.info/?l=openbsd-ports=144171504417490=2 > >>> > >>> jirib didn't confirm that ICU was the only thing needed to make his > >>> aegisub port work, and to my knowledge no existing port requires ICU in > >>> boost. The only benefit I can see so far is to have a boost package > >>> similar to other distros. > >> > >>I wonder if adding ICU support to boost would unbreak manik. > > > >On that topic i've filed https://github.com/mapnik/mapnik/issues/3202 > >upstream but didnt thought about that boost/icu thing. > > > >Either way, touching boost... here be dragons. > > > >Landry > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Firefox PDF rendering
On Mon, Dec 28, 2015 at 02:50:24PM +0100, Theo Buehler wrote:
> On Mon, Dec 28, 2015 at 08:23:32AM +0100, Matthieu Herrb wrote:
> > On Sun, Dec 27, 2015 at 10:05:24PM +, Stuart Henderson wrote:
> > > On 2015/12/26 19:11, Michael McConville wrote:
> > > > Is there a reason why Firefox often has ugly typography in PDFs
> > > > generated by LaTeX and the like? Most specifically, the t's are often
> > > > very fat.
> > > >
> > > > Here's an example:
> > > >
> > > > http://www.sccs.swarthmore.edu/~mmcconv1/dump/firefox-pdf.png
> > > >
> > > > IIRC, it's this way on some Linux distros too, so maybe it's
> > > > unavoidable. Is there any way around it?
> > > >
> > >
> > > I think this may happen if you have ghostscript-fonts installed.
> >
> > To my eyes this screenshot looks more like a document that used the
> > old bitmapped CM fonts rather than some PDF compatible ones. It may be
> > possible that it's the firefox PDF viewer that picks them from you
> > system, but more probalby it's at the PDF generation stage that the
> > damage was done.
> >
> > Michael, is the original PDF document available somewhere to check
> > that.
> >
> > Hint for (La)TeX document writers : use the lmodern package with
> > pdftex/pdflatex.
> > --
> > Matthieu Herrb
>
> It doesn't seem that \uspackage{lmodern} fixes this issue:
> Consider these two examples:
> https://people.math.ethz.ch/~thbuehle/fa_i/lorem-lmodern.pdf
> https://people.math.ethz.ch/~thbuehle/fa_i/lorem-nolmodern.pdf
> both have the same fat t that Mike described. Both were created with
> pdflatex, source code below.
>
> As I told Mike in private, setting "pdfjs.disableFontFace" to true
> in about:config apparently fixes this issue, but I don't know if there
> are other undesirable side-effects of doing this.
The problem are the Type1 fonts commonly used in the PDFs generated by
pdflatex. Firefox tries to convert the Type1 fonts to OTF but the
conversion is very buggy.
Firefox extracts the fonts embedded within the PDF files and load them
with @font-face. If you disable @font-face, Firefox will use (i guess)
the PDF standard fonts which will break the metrics of the document.
https://wiki.mozilla.org/PDF.js/fonts
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: Porting htop
On Fri, Jun 10, 2016 at 08:37:32PM +0200, Daniel Jakots wrote: > On Fri, 10 Jun 2016 14:27:09 -0400, Owl Owl <whootandah...@gmail.com> > wrote: > > > Folks, > > > > Looks like the latest version of htop can be compiled on OpenBSD now. > > Has anyone taken a peek at porting it over as a standard port/package? > > There's a WIP port [0] but there are still bugs which are easily > triggered in OpenBSD [1] > > [0] https://marc.info/?l=openbsd-ports=146172011613713=2 > [1] https://marc.info/?l=openbsd-ports=146283061630445=2 Also available in: https://github.com/jasperla/openbsd-wip/tree/master/sysutils/htop -- Juan Francisco Cantero Hurtado http://juanfra.info
UPDATE: lang/nim 0.14.2
Comments? OKs?
Index: Makefile
===
RCS file: /cvs/ports/lang/nim/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile22 Dec 2015 19:40:48 - 1.2
+++ Makefile10 Jun 2016 01:06:14 -
@@ -4,9 +4,8 @@ ONLY_FOR_ARCHS =i386 amd64
COMMENT = statically typed, imperative programming language
-VERSION = 0.11.2
+VERSION = 0.14.2
DISTNAME = nim-${VERSION}
-REVISION = 0
EXTRACT_SUFX = .tar.xz
CATEGORIES = lang
@@ -19,12 +18,23 @@ PERMIT_PACKAGE_CDROM = Yes
WANTLIB = c m
+post-patch:
+ mkdir -p ${WRKSRC}/nimcache-port
+ mkdir -p ${WRKSRC}/nimcache-port-test
+ perl -i -pe "s#NIM_PORT_PATH#${PATH}#" ${WRKSRC}/koch.nim
+ perl -i -pe "s#NIM_PORT_CACHE#${WRKSRC}/nimcache-port-test#" \
+ ${WRKSRC}/koch.nim
+
do-build:
- cd ${WRKDIST} && ${SETENV} CC="${CC}" LINKER="${CC}" \
- COMP_FLAGS="${CFLAGS}" sh build.sh
+ cd ${WRKSRC} && ${SETENV} CC="${CC}" LINKER="${CC}" \
+ CFLAGS="${CFLAGS}" sh build.sh
# slow machines can get a head of themselves and fail to link
- cd ${WRKSRC} && ${SETENV} bin/nim c --parallelBuild:1 koch
- cd ${WRKSRC} && ${SETENV} ./koch boot -d:release --parallelBuild:1
+ cd ${WRKSRC} && bin/nim c -d:release --parallelBuild:1 \
+ --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
+ --listCmd --putenv:"PATH=${PATH}" koch
+ cd ${WRKSRC} && ./koch boot -d:release --parallelBuild:1 \
+ --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \
+ --listCmd --putenv:"PATH=${PATH}"
do-install:
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
@@ -38,6 +48,9 @@ do-install:
${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${PREFIX}/share/examples/nim
do-test:
- cd ${WRKSRC} && ${SETENV} ./koch test all -d:release --parallelBuild:1
+ cd ${WRKSRC} && ${SETENV} ./koch test all -d:release \
+ --parallelBuild:1 --listFullPaths --listCmd \
+ --nimcache:"${WRKSRC}/nimcache-port-test" \
+ --putenv:"PATH=${PATH}"
.include
Index: distinfo
===
RCS file: /cvs/ports/lang/nim/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo19 Oct 2015 21:50:14 - 1.1.1.1
+++ distinfo10 Jun 2016 01:06:14 -
@@ -1,2 +1,2 @@
-SHA256 (nim-0.11.2.tar.xz) = VkDjZNi6zsgw8Bba89RCeRHEjOv5YnJOyQP+pdWnpBk=
-SIZE (nim-0.11.2.tar.xz) = 2587012
+SHA256 (nim-0.14.2.tar.xz) = Iryzjgru14n+jrmEB+cDc2X+uczY+k45oEZHJsW38vs=
+SIZE (nim-0.14.2.tar.xz) = 6462864
Index: patches/patch-build_sh
===
RCS file: /cvs/ports/lang/nim/patches/patch-build_sh,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-build_sh
--- patches/patch-build_sh 19 Oct 2015 21:50:14 - 1.1.1.1
+++ patches/patch-build_sh 10 Jun 2016 01:06:14 -
@@ -1,16 +1,16 @@
$OpenBSD: patch-build_sh,v 1.1.1.1 2015/10/19 21:50:14 juanfra Exp $
build.sh.orig Sun Sep 13 00:49:57 2015
-+++ build.sh Sun Sep 13 00:52:17 2015
+--- build.sh.orig Tue Jun 7 00:38:53 2016
build.sh Thu Jun 9 19:43:03 2016
@@ -26,9 +26,9 @@ do
esac
done
-CC="gcc"
-LINKER="gcc"
--COMP_FLAGS="-w -O3 -fno-strict-aliasing$extraBuildArgs"
+-COMP_FLAGS="${CPPFLAGS:-} ${CFLAGS:-} -w -O3
-fno-strict-aliasing$extraBuildArgs"
+#CC="gcc"
+#LINKER="gcc"
-+COMP_FLAGS="-w -fno-strict-aliasing$extraBuildArgs $COMP_FLAGS"
- LINK_FLAGS=""
++COMP_FLAGS="${CPPFLAGS:-} ${CFLAGS:-} -w -fno-strict-aliasing$extraBuildArgs"
+ LINK_FLAGS="${LDFLAGS:-} "
+ PS4=""
# platform detection
- ucpu=`uname -m`
Index: patches/patch-compiler_extccomp_nim
===
RCS file: /cvs/ports/lang/nim/patches/patch-compiler_extccomp_nim,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-compiler_extccomp_nim
--- patches/patch-compiler_extccomp_nim 19 Oct 2015 21:50:14 - 1.1.1.1
+++ patches/patch-compiler_extccomp_nim 10 Jun 2016 01:06:14 -
@@ -1,16 +1,16 @@
$OpenBSD: patch-compiler_extccomp_nim,v 1.1.1.1 2015/10/19 21:50:14 juanfra
Exp $
compiler/extccomp.nim.orig Sun Sep 13 00:55:21 2015
-+++ compiler/extccomp.nim Sun Sep 13 01:01:06 2015
-@@ -18,7 +18,7 @@ import
+--- compiler/extccomp.nim.orig Tue Jun 7 00:38:57 2016
compiler/extccomp.nim Thu Jun 9 19:46:54 2016
+@@ -21,7 +21,7 @@ from debuginfo import writeDebugInfo
type
TSystemCC* = enum
ccNone, ccGcc, ccLLVM_Gcc, ccCLang, ccLcc, ccBcc, ccDmc, ccWcc, ccVcc,
--ccTcc, ccPcc, ccUcc, ccIcl
-+ccTcc, ccPcc, ccUcc, ccIcl, ccEGcc
+-ccTcc, ccPcc, ccUcc, ccIcl, asmFasm
++ccTcc, ccPcc, ccUcc, ccIcl, asmFasm, ccEGcc
Re: UPDATE: lang/nim 0.14.2
On Wed, Jun 15, 2016 at 02:59:12AM +0200, Jakub Skrzypnik wrote: > Can I somehow show my appreciation for that? I'm going to learn Nim > soon, so the newest available version on OpenBSD (which I use on my > lap^Wdesktop) would be very helpful. ;) I committed the update just a minutes before of your mail. Please let me know if you find any problem with our package. With Nim, I'm never 100% sure that everything is working fine (in fact, some parts don't work on OpenBSD). -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Version Bump Request for uGet Download Manager
- #endif > - > -+#if defined __OpenBSD__ // Others? > -+#include > -+#endif > -+ > - // > > - // Time > - > Index: pkg/PLIST > === > RCS file: /cvs/ports/www/uget/pkg/PLIST,v > retrieving revision 1.4 > diff -u -p -r1.4 PLIST > --- pkg/PLIST 2 Jan 2016 08:51:47 - 1.4 > +++ pkg/PLIST 28 May 2016 19:40:31 - > @@ -49,8 +49,6 @@ share/locale/ka_GE/ > share/locale/ka_GE/LC_MESSAGES/ > share/locale/ka_GE/LC_MESSAGES/uget.mo > share/locale/kk/LC_MESSAGES/uget.mo > -share/locale/ku/ > -share/locale/ku/LC_MESSAGES/ > share/locale/ku/LC_MESSAGES/uget.mo > share/locale/or_IN/ > share/locale/or_IN/LC_MESSAGES/ > @@ -62,8 +60,6 @@ share/locale/sk_SK/ > share/locale/sk_SK/LC_MESSAGES/ > share/locale/sk_SK/LC_MESSAGES/uget.mo > share/locale/sr/LC_MESSAGES/uget.mo > -share/locale/sr@latin/ > -share/locale/sr@latin/LC_MESSAGES/ > share/locale/sr@latin/LC_MESSAGES/uget.mo > share/locale/sv/LC_MESSAGES/uget.mo > share/locale/tr/LC_MESSAGES/uget.mo > > > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Version Bump Request for uGet Download Manager
On Sun, May 29, 2016 at 03:01:37PM +0100, Stuart Henderson wrote:
> On 2016/05/29 05:39, Juan Francisco Cantero Hurtado wrote:
> > On Sat, May 28, 2016 at 08:41:51PM +0100, Stuart Henderson wrote:
> > > On 2016/05/28 11:20, Michael Tunnell wrote:
> > > > I'm not sure if this is the proper method for making these requests so I
> > > > apologize if it's not.
> > > >
> > > > I'd like to request that uGet be version bump from 2.0.4 to the latest
> > > > version of 2.0.8, released on 16 May, 2016.
> > >
> > > Ports diff below, but I don't use this so will need someone to test.
> >
> > Sorry, I didn't see your patch before of I committed the update :( . I
> > forgot to remove the patches.
>
> I've committed those.
>
> What should we do about the --check-certificate=false nonsense?
> There's some --disable-ipv6 in there as well. It's 2016, it's
> ridiculous to use these flags.
OK? I've tested the program without the options downloading an iso from
a https URL. Everything works fine.
Index: Makefile
===
RCS file: /cvs/ports/www/uget/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile29 May 2016 13:59:01 - 1.13
+++ Makefile29 May 2016 21:30:14 -
@@ -2,7 +2,7 @@
COMMENT = lightweight graphical download manager
DISTNAME = uget-2.0.8
-REVISION = 0
+REVISION = 1
CATEGORIES = www net x11
HOMEPAGE = http://ugetdm.com/
Index: patches/patch-tests_test-plugin+app_c
===
RCS file: patches/patch-tests_test-plugin+app_c
diff -N patches/patch-tests_test-plugin+app_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-tests_test-plugin+app_c 29 May 2016 21:30:14 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- tests/test-plugin+app.c.orig Sun May 29 23:23:28 2016
tests/test-plugin+app.cSun May 29 23:23:41 2016
+@@ -159,7 +159,7 @@ void test_setup_plugin_aria2 (void)
+ "C:\\Program Files\\uGet\\bin\\aria2c.exe");
+ #endif
+ uget_plugin_set (pinfo, UGET_PLUGIN_ARIA2_ARGUMENT,
+- "--enable-rpc=true -D --check-certificate=false");
++ "--enable-rpc=true -D");
+ uget_plugin_set (pinfo, UGET_PLUGIN_ARIA2_LAUNCH, (void*) TRUE);
+ uget_plugin_set (pinfo, UGET_PLUGIN_ARIA2_SHUTDOWN, (void*) TRUE);
+ ug_sleep (1000);
Index: patches/patch-uget_UgetAria2_c
===
RCS file: /cvs/ports/www/uget/patches/patch-uget_UgetAria2_c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-uget_UgetAria2_c
--- patches/patch-uget_UgetAria2_c 29 May 2016 13:59:01 - 1.2
+++ patches/patch-uget_UgetAria2_c 29 May 2016 21:30:14 -
@@ -1,12 +1,14 @@
$OpenBSD: patch-uget_UgetAria2_c,v 1.2 2016/05/29 13:59:01 sthen Exp $
uget/UgetAria2.c.orig Sun May 15 19:28:25 2016
-+++ uget/UgetAria2.c Sat May 28 20:30:26 2016
-@@ -53,7 +53,7 @@
+--- uget/UgetAria2.c.orig Sun May 15 20:28:25 2016
uget/UgetAria2.c Sun May 29 23:21:36 2016
+@@ -53,8 +53,8 @@
#define RPC_URI "http://localhost:6800/jsonrpc;
#define RPC_BATCH_LEN5
#define RPC_INTERVAL 500
-#define ARIA2_PATH "aria2c"
+-#define ARIA2_ARGS "--enable-rpc=true -D --check-certificate=false"
+#define ARIA2_PATH "${TRUEPREFIX}/bin/aria2c"
- #define ARIA2_ARGS "--enable-rpc=true -D --check-certificate=false"
++#define ARIA2_ARGS "--enable-rpc=true -D"
#if defined _WIN32 || defined _WIN64
+ #define ug_sleep Sleep
Index: patches/patch-uget_UgetAria2_c.orig
===
RCS file: patches/patch-uget_UgetAria2_c.orig
diff -N patches/patch-uget_UgetAria2_c.orig
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-uget_UgetAria2_c.orig 29 May 2016 21:30:14 -
@@ -0,0 +1,12 @@
+$OpenBSD: patch-uget_UgetAria2_c,v 1.2 2016/05/29 13:59:01 sthen Exp $
+--- uget/UgetAria2.c.orig Sun May 15 19:28:25 2016
uget/UgetAria2.c Sat May 28 20:30:26 2016
+@@ -53,7 +53,7 @@
+ #define RPC_URI "http://localhost:6800/jsonrpc;
+ #define RPC_BATCH_LEN5
+ #define RPC_INTERVAL 500
+-#define ARIA2_PATH "aria2c"
++#define ARIA2_PATH "${TRUEPREFIX}/bin/aria2c"
+ #define ARIA2_ARGS "--enable-rpc=true -D --check-certificate=false"
+
+ #if defined _WIN32 || defined _WIN64
Index: patches/patch-ui-gtk-1to2_UgSetting_c
===
RCS file: patches/patch-ui-gtk-1to2_UgSetting_c
diff -N patches/patc
Re: UPDATE: lang/nim 0.14.2
On miércoles, 15 de junio de 2016 10:54:24 (CEST) Stuart Henderson wrote: > On 2016/06/15 04:17, Juan Francisco Cantero Hurtado wrote: > > On Wed, Jun 15, 2016 at 02:59:12AM +0200, Jakub Skrzypnik wrote: > > > Can I somehow show my appreciation for that? I'm going to learn > > > Nim > > > soon, so the newest available version on OpenBSD (which I use on > > > my > > > lap^Wdesktop) would be very helpful. ;) > > > > I committed the update just a minutes before of your mail. Please > > let me know if you find any problem with our package. With Nim, I'm > > never 100% sure that everything is working fine (in fact, some > > parts don't work on OpenBSD). > > The distfile mismatches. Thanks. I added an additional MASTER_SITES with the old tarball. I need a few hour to test the new tarball. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: DPB incorrectly building all multi-packages
On Sun, Jun 19, 2016 at 06:57:19PM +0100, Rob wrote: > Hi, > > I’ve been pulling my hair out for the past week trying to find out why I > can’t build multi-packages using dpb(1) on 5.9, or rather why dpb(1) is > choosing to build all of a ports sub-packages. > > I have been trying to build databases/postgresql,-server, among other. > Unfortunately, this builds all of the PostgreSQL sub packages (e.g. > -plpython, -docs). The command line I’m using is: > > # /usr/ports/infrastructure/bin/dpb databases/postgresql,-server > > I’ve tried searching, but I’ve been unable to find any other people reporting > this problem. Digging through the source I can see that > SUBDIR=databases/postgresql gets set within DPB::Vars::run_command() when > ‘make dump-vars’ is run and this shows all of the sub/multi-packages, these > then get enabled and added to the build queue. I think if > SUBDIR=databases/postgresql,-server was set this would eliminate the problem. > > Am I correct in assuming dpb(1) supports this type of pkgpath (e.g. > databases/postgresql,-server)? If so, does this functionality work as > expected under a vanilla 5.9, from the release ISO or built from the > OPENBSD_5_9 CVS tag? > When a package uses multi-packages, the port framework builds the code one time and divides the result in various subpackages. That is the reason why you can't just to build one subpackage. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: quake2 update
On Wed, Jan 13, 2016 at 12:08:54PM -0500, Brandon Mercer wrote:
> cje...@openbsd.org
> Cc:
> Bcc:
> Subject: games/quake2 update
> Reply-To:
>
> Inspired by the recent dhewm3 work, I decided to try quake2 again only
> to find that it does not work. There was some dialogue by folks earlier
> to get the existing port, that has been broken for the better part of
> two years, replaced with yquake2. Because yquake2 is different than
> quake2, I propose we import this new, working version and then delete
> the existing port. This diff was sent out by jsg@ some time ago before a
> fun bikeshedding session. Looking for OK's to import this:
>
> bmercer@
I can't test the port but please add "SHARED_ONLY=Yes", remove
PFRAG.shared and update PLIST.
>
> Index: yquake2/Makefile
> ===
> RCS file: yquake2/Makefile
> diff -N yquake2/Makefile
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ yquake2/Makefile 13 Jan 2016 16:51:48 -
> @@ -0,0 +1,34 @@
> +# $OpenBSD$
> +
> +COMMENT= Yamagi Quake II
> +N= yquake2
> +V= 5.32
> +PKGNAME= ${N}-${V}
> +DISTNAME=quake2-${V}
> +CATEGORIES= games
> +
> +HOMEPAGE=http://www.yamagi.org/quake2/
> +MASTER_SITES=http://deponie.yamagi.org/quake2/
> +EXTRACT_SUFX=.tar.xz
> +
> +# GPLv2
> +PERMIT_PACKAGE_CDROM= Yes
> +
> +WANTLIB += GL SDL2 c jpeg m ogg pthread vorbis vorbisfile z
> +
> +LIB_DEPENDS= audio/libvorbis \
> + graphics/jpeg \
> + devel/sdl2
> +
> +MAKE_ENV+= VERBOSE=1
> +USE_GMAKE= Yes
> +
> +do-install:
> + ${INSTALL_DATA_DIR} ${PREFIX}/share/${N}
> + ${INSTALL_PROGRAM} ${WRKBUILD}/release/{quake2,q2ded} \
> + ${PREFIX}/share/${N}/
> + ${INSTALL_DATA_DIR} ${PREFIX}/share/${N}/baseq2
> + ${INSTALL_PROGRAM} ${WRKBUILD}/release/baseq2/game.so \
> + ${PREFIX}/share/${N}/baseq2/
> +
> +.include
> Index: yquake2/distinfo
> ===
> RCS file: yquake2/distinfo
> diff -N yquake2/distinfo
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ yquake2/distinfo 13 Jan 2016 16:26:47 -
> @@ -0,0 +1,2 @@
> +SHA256 (quake2-5.32.tar.xz) = v8eAMlSp0iiIVU1a8lL//iEts9qwYxY3u5BFhhuOUIw=
> +SIZE (quake2-5.32.tar.xz) = 1692720
> Index: yquake2/pkg/DESCR
> ===
> RCS file: yquake2/pkg/DESCR
> diff -N yquake2/pkg/DESCR
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ yquake2/pkg/DESCR 13 Jan 2016 16:26:47 -
> @@ -0,0 +1,7 @@
> +Yamagi Quake II is an enhanced client for id Software's Quake II. The
> +main focus is an unchanged single player experience like back in 1997,
> +thus the gameplay and the graphics are unaltered. Over 1000 bugs were
> +fixed and an extensive code audit done, making Yamagi Quake II one of
> +the most solid Quake II implementations available. Other than most ports
> +Yamagi Quake II is full 64 bit clean, so it works perfectly on modern 64
> +bit processors and operating systems.
> Index: yquake2/pkg/PFRAG.shared
> ===
> RCS file: yquake2/pkg/PFRAG.shared
> diff -N yquake2/pkg/PFRAG.shared
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ yquake2/pkg/PFRAG.shared 13 Jan 2016 16:26:47 -
> @@ -0,0 +1,2 @@
> +@comment $OpenBSD$
> +share/yquake2/baseq2/game.so
> Index: yquake2/pkg/PLIST
> ===
> RCS file: yquake2/pkg/PLIST
> diff -N yquake2/pkg/PLIST
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ yquake2/pkg/PLIST 13 Jan 2016 16:26:47 -
> @@ -0,0 +1,6 @@
> +@comment $OpenBSD$
> +%%SHARED%%
> +share/yquake2/
> +share/yquake2/baseq2/
> +@bin share/yquake2/q2ded
> +@bin share/yquake2/quake2
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: textproc/zathura: missing RUN_DEPENDS
On Thu, Feb 04, 2016 at 08:49:37AM +0100, Landry Breuil wrote: > On Thu, Feb 04, 2016 at 03:05:24AM +0100, Juan Francisco Cantero Hurtado > wrote: > > When I install a zathura plugin because I only want a viewer for that > > format, pkg_add will not install also the main package. Without the > > core package, the plugin is useless. > > > > While here, change the COMMENT. > > > > The patch is very simple. OK? > > I *think* there was a reason for this...dunno if this was circular > dependencies at build time or something like this. > Maybe look into the ports@ archives for justifications ? Sorry, I didn't read your reply before of to commit the change. The plugins depend of core at build time. I only changed the RUN_DEPENDS. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: lang/gcc on macppc
On Thu, Feb 04, 2016 at 12:29:05AM -0500, Michael McConville wrote: > I'm getting the below error when building the GCC port on a Power Mac G5 > running the most recent snapshot. It fails reliably when I retry the > build, so it doesn't seem like an Act of God(TM) caused by a kernel or > hardware bug. > > The build is successful with Ada disabled. For ada bugs, add always to tobiasu@ to the CC. > > Is this a known issue? Let me know if a full build log would be useful. > > > true DO=all multi-do # gmake > gmake[4]: Leaving directory '/home/build/build-powerpc/libbacktrace' > gmake[3]: Leaving directory '/home/build/build-powerpc/libbacktrace' > gmake[3]: Entering directory '/home/build/build-powerpc/libcpp' > test -f config.h || (rm -f stamp-h1 && gmake stamp-h1) > gmake[3]: Leaving directory '/home/build/build-powerpc/libcpp' > gmake[3]: Entering directory '/home/build/build-powerpc/libdecnumber' > gmake[3]: Nothing to be done for 'all'. > gmake[3]: Leaving directory '/home/build/build-powerpc/libdecnumber' > gmake[3]: Entering directory '/home/build/build-powerpc/gcc' > /home/build/build-powerpc/./prev-gcc/gnatbind -nostdinc -I- -I. -Iada > -I/home/build/gcc-4.9.3/gcc/ada -I/home/build/gcc-4.9.3/gcc/ada/gcc-interface > -o b_gnat1.adb -n ada/gnat1drv.ali > > raised CONSTRAINT_ERROR : SIGBUS > /home/build/gcc-4.9.3/gcc/ada/gcc-interface/Make-lang.in:932: recipe for > target 'ada/b_gnat1.adb' failed > gmake[3]: *** [ada/b_gnat1.adb] Error 1 > gmake[3]: Leaving directory '/home/build/build-powerpc/gcc' > Makefile:4256: recipe for target 'all-stage2-gcc' failed > gmake[2]: *** [all-stage2-gcc] Error 2 > gmake[2]: Leaving directory '/home/build/build-powerpc' > Makefile:18532: recipe for target 'stage2-bubble' failed > gmake[1]: *** [stage2-bubble] Error 2 > gmake[1]: Leaving directory '/home/build/build-powerpc' > Makefile:18551: recipe for target 'bootstrap2' failed > gmake: *** [bootstrap2] Error 2 > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: lang/gcc on macppc
On Thu, Feb 04, 2016 at 03:40:48PM +0100, Martin Pieuchot wrote: > On 04/02/16(Thu) 00:29, Michael McConville wrote: > > I'm getting the below error when building the GCC port on a Power Mac G5 > > running the most recent snapshot. It fails reliably when I retry the > > build, so it doesn't seem like an Act of God(TM) caused by a kernel or > > hardware bug. > > > > The build is successful with Ada disabled. > > > > Is this a known issue? Let me know if a full build log would be useful. > > Are you using GENERIC.MP or GENERIC? Does it make a difference? > > Could it be related to a bug in our binutils? > > macppc is starting to be unusable as desktop because nobody is spending > time to ensure the ports build and run correctly. Someone with enough skills should work with landry@ to reduce the bulk build times. The packages are almost always outdated because a full bulk build takes weeks(?). A slow architecture without a weekly update to the packages is not going to attract a lot of desktop users :( -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Firefox 44 font change
On Sun, Feb 07, 2016 at 08:57:42PM +, Christian Weisgerber wrote: > On 2016-02-03, Juan Francisco Cantero Hurtado <i...@juanfra.info> wrote: > > >> Firefox 44 appears to have snuck in a change in font handling: > >> > >> Bitmap fonts are no longer used. At least that's what I see with > >> only the default fonts installed (xenocara defaults plus ghostscript > >> since that gets pulled in as a dependency). > > > > Search the string "font." in about:config. The text in bold are > > non-default values. Look if you have the file > > .config/fontconfig/fonts.conf. Firefox uses these about:config > > settings and fontconfig to select the fonts. > > All default values, no ~/.config/fontconfig/. > > > Open "ja.wikipedia.org", click with the secondary button of your mouse > > in any line of text and click in "Inspect Element". Click in > > "Inspector" and "Fonts". It will show which font is used to render > > that text. > > DejaVu Sans. (Which doesn't have glyphs for Japanese.) > > You are treating this like a bug report. That wasn't my intention. I gave you those instructions because I've seen some web pages using a very weird fonts selection in the past and other people could compare the info with their browser. That's all :) > I assumed it was some conscious upstream change. (I see the same > on FreeBSD.) I don't consider it a problem, but I thought I'd bring > it up _before_ ports lock, because people always get worked up over > any Firefox changes. > > So am I to understand that this is not a general change in Firefox > font handling? > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > -- Juan Francisco Cantero Hurtado http://juanfra.info
Haskell on PowerPC (Was: Questions about PowerMac G5 (fan control, haskell) ?)
Moving the thread to ports@ On Sun, Jan 31, 2016 at 09:16:07PM +0100, Christoph R. Murauer wrote: > Hello ! > > Thanks for your answer. > > > The GHC port doesn't work on powerpc. > > Any chances (have no machine to try it) to build the community / older > version of ghc ? > > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: dpb weird behavior. Can anyone reproduce it?
On Sun, Jan 31, 2016 at 08:22:02AM +0100, Marc Espie wrote: > On Sun, Jan 31, 2016 at 04:19:00AM +0100, Juan Francisco Cantero Hurtado > wrote: > > -current, amd64, base and ports tree updated. > > > > Probably some details are irrelevant but I don't know where is the > > problem exactly. > > > > Here are the steps: > > - Create a shellscript with this content: > > #!/bin/sh > > /usr/ports/infrastructure/bin/dpb -m -D COLOR=0 -D NO_CURSOR=1 -D > > ALWAYS_CLEAN=1 -D WAIT_TIMEOUT=0 -q -c -j 4 -p 4 -f 0 -u -U -r -R > > > > - Run as a regular user "doas ./your_script.sh". > > - Wait until dpb is using the 4 slots to "build" the packages. > > - Press Ctrl+c > > - Run top -CHIS -s 1 > > > > Do you see gcc, make, as, ld, etc running in top? > > > > I see a lot of processes related to the build running for a very long > > time. I tried with zsh and ksh. "fg" doesn't show processes running in > > the background. > > Don't do that. ^C doesn't "pass" through doas. You have to kill dpb as root > as well. > > In general, I tend to do tmux/doas sh, THEN start dpb, that way I can kill it, > and everything that depends on it with ^C. > > You can only kill stuff you own easily. > Thanks for the help!. Maybe I didn't look closely at the remaining processes in the past. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: graphics/djvulibre: fix a bug in documents with duplicate page titles
On Wed, Feb 03, 2016 at 03:08:53AM +0100, Juan Francisco Cantero Hurtado wrote:
> The patch adds support for documents with duplicate page titles. I
> need this change to update pdf2djvu to the latest version.
>
> I've not tested any djvu viewer, just the conversion. So any test is
> welcome.
Tested with zathura-djvu and everything works fine.
>
> OK?
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/djvulibre/Makefile,v
> retrieving revision 1.34
> diff -u -p -r1.34 Makefile
> --- Makefile 12 May 2015 16:10:27 - 1.34
> +++ Makefile 3 Feb 2016 01:53:18 -
> @@ -3,6 +3,7 @@
> COMMENT= view, decode and encode DjVu files
>
> DISTNAME=djvulibre-3.5.27
> +REVISION=0
> SHARED_LIBS= djvulibre 26.0# 27.0
> CATEGORIES= graphics print
>
> Index: patches/patch-libdjvu_DjVmDir_cpp
> ===
> RCS file: patches/patch-libdjvu_DjVmDir_cpp
> diff -N patches/patch-libdjvu_DjVmDir_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-libdjvu_DjVmDir_cpp 3 Feb 2016 01:53:18 -
> @@ -0,0 +1,94 @@
> +$OpenBSD$
> +
> +"accept documents with duplicate page titles"
> +
> +http://sourceforge.net/p/djvu/djvulibre-git/ci/77a4dca8dd3acd0acc1680fa14a352c11084e25d/
> +https://bitbucket.org/jwilk/pdf2djvu/issues/113/duplicate-page-title-1
> +
> +--- libdjvu/DjVmDir.cpp.orig Tue Jul 8 23:15:07 2014
> libdjvu/DjVmDir.cpp Wed Feb 3 01:51:28 2016
> +@@ -223,7 +223,6 @@ DjVmDir::decode(const GP )
> +page2file.resize(-1);
> +name2file.empty();
> +id2file.empty();
> +- title2file.empty();
> +
> +int ver=str.read8();
> +bool bundled=(ver & 0x80)!=0;
> +@@ -375,18 +374,6 @@ DjVmDir::decode(const GP )
> + G_THROW( ERR_MSG("DjVmDir.dupl_id") "\t" + file->id);
> +id2file[file->id]=file;
> + }
> +-
> +- // Generate title2file map
> +- for(pos=files_list;pos;++pos)
> +- {
> +- GP file=files_list[pos];
> +- if (file->title.length())
> +- {
> +- if (title2file.contains(file->title))
> +- G_THROW( ERR_MSG("DjVmDir.dupl_title") "\t" + file->title);
> +- title2file[file->title]=file;
> +- }
> +- }
> +}
> + }
> +
> +@@ -556,11 +543,19 @@ DjVmDir::id_to_file(const GUTF8String ) const
> + }
> +
> + GP
> +-DjVmDir::title_to_file(const GUTF8String ) const
> ++DjVmDir::title_to_file(const GUTF8String , GPosition spos) const
> + {
> +- GCriticalSectionLock lock((GCriticalSection *) _lock);
> +- GPosition pos;
> +- return (title2file.contains(title,
> pos))?title2file[pos]:(GP(0));
> ++ if (! title)
> ++return 0;
> ++ GCriticalSectionLock lock((GCriticalSection *) _lock);
> ++ if (! spos)
> ++for (GPosition pos = spos; pos; ++pos)
> ++ if (files_list[pos]->is_page() && files_list[pos]->title == title)
> ++return files_list[pos];
> ++ for (GPosition pos = files_list; pos; ++pos)
> ++if (files_list[pos]->is_page() && files_list[pos]->title == title)
> ++ return files_list[pos];
> ++ return 0;
> + }
> +
> + GP
> +@@ -661,14 +656,7 @@ DjVmDir::insert_file(const GP & file, int pos_nu
> + G_THROW( ERR_MSG("DjVmDir.dupl_name2") "\t" + file->name);
> +name2file[file->name]=file;
> +id2file[file->id]=file;
> +- if (file->title.length())
> +- {
> +- if (title2file.contains(file->title))
> +- // duplicate titles may become ok some day
> +- G_THROW( ERR_MSG("DjVmDir.dupl_title2") "\t" + file->title);
> +- title2file[file->title]=file;
> +- }
> +-
> ++
> + // Make sure that there is no more than one file with shared
> annotations
> +if (file->is_shared_anno())
> +{
> +@@ -727,7 +715,6 @@ DjVmDir::delete_file(const GUTF8String )
> + {
> + name2file.del(f->name);
> + id2file.del(f->id);
> +- title2file.del(f->title);
> + if (f->is_page())
> + {
> + for(int page=0;page<page2file.size();page++)
> +@@ -788,9 +775,7 @@ DjVmDir::set_file_title(const GUTF8String , const G
> +if (!id2file.contains(id, pos))
> + G_THROW( ERR_MSG("DjVmDir.no_info") "\t" + GUTF8String(id));
> +GP file=id2file[pos];
> +- title2file.del(file->title);
> +file->title=title;
textproc/zathura: missing RUN_DEPENDS
When I install a zathura plugin because I only want a viewer for that
format, pkg_add will not install also the main package. Without the
core package, the plugin is useless.
While here, change the COMMENT.
The patch is very simple. OK?
Index: core/Makefile
===
RCS file: /cvs/ports/textproc/zathura/core/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- core/Makefile 20 Sep 2015 07:33:44 - 1.3
+++ core/Makefile 4 Feb 2016 01:53:39 -
@@ -1,7 +1,8 @@
# $OpenBSD: Makefile,v 1.3 2015/09/20 07:33:44 landry Exp $
V =0.3.3
-COMMENT = PDF viewer with vi-like keybindings
+REVISION = 0
+COMMENT = multi-format document viewer with vi-like keybindings
DISTNAME = zathura-${V}
CATEGORIES = textproc x11
Index: plugins/Makefile.inc
===
RCS file: /cvs/ports/textproc/zathura/plugins/Makefile.inc,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile.inc
--- plugins/Makefile.inc25 Aug 2015 14:23:25 - 1.4
+++ plugins/Makefile.inc4 Feb 2016 01:53:39 -
@@ -8,7 +8,8 @@ PERMIT_PACKAGE_CDROM ?= Yes
PERMIT_PACKAGE_FTP ?= Yes
PERMIT_DISTFILES_FTP ?=Yes
-RUN_DEPENDS ?= devel/desktop-file-utils
+RUN_DEPENDS ?= devel/desktop-file-utils \
+ textproc/zathura/core
LIB_DEPENDS += x11/girara
BUILD_DEPENDS ?= textproc/zathura/core
Index: plugins/cb/Makefile
===
RCS file: /cvs/ports/textproc/zathura/plugins/cb/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- plugins/cb/Makefile 25 Aug 2015 14:23:25 - 1.3
+++ plugins/cb/Makefile 4 Feb 2016 01:53:39 -
@@ -3,7 +3,7 @@
V =0.1.2
COMMENT = comic book plugin for zathura
DISTNAME = zathura-cb-${V}
-REVISION = 1
+REVISION = 2
HOMEPAGE = http://pwmt.org/projects/zathura/plugins/zathura-cb/
Index: plugins/djvu/Makefile
===
RCS file: /cvs/ports/textproc/zathura/plugins/djvu/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- plugins/djvu/Makefile 25 Aug 2015 14:23:25 - 1.3
+++ plugins/djvu/Makefile 4 Feb 2016 01:53:39 -
@@ -3,7 +3,7 @@
V =0.2.3
COMMENT = djvu plugin for zathura
DISTNAME = zathura-djvu-${V}
-REVISION = 1
+REVISION = 2
HOMEPAGE = http://pwmt.org/projects/zathura/plugins/zathura-djvu
Index: plugins/mupdf/Makefile
===
RCS file: /cvs/ports/textproc/zathura/plugins/mupdf/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- plugins/mupdf/Makefile 25 Aug 2015 14:23:25 - 1.6
+++ plugins/mupdf/Makefile 4 Feb 2016 01:53:39 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.6 2015/08/25 14:23:25 sthen Exp $
V =0.2.7
-REVISION = 2
+REVISION = 3
COMMENT = mupdf pdf plugin for zathura
DISTNAME = zathura-pdf-mupdf-${V}
Index: plugins/poppler/Makefile
===
RCS file: /cvs/ports/textproc/zathura/plugins/poppler/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- plugins/poppler/Makefile25 Aug 2015 14:23:25 - 1.4
+++ plugins/poppler/Makefile4 Feb 2016 01:53:39 -
@@ -3,7 +3,7 @@
V =0.2.5
COMMENT = poppler pdf plugin for zathura
DISTNAME = zathura-pdf-poppler-${V}
-REVISION = 1
+REVISION = 2
HOMEPAGE = http://pwmt.org/projects/zathura/plugins/zathura-pdf-poppler/
Index: plugins/ps/Makefile
===
RCS file: /cvs/ports/textproc/zathura/plugins/ps/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- plugins/ps/Makefile 25 Aug 2015 14:23:25 - 1.4
+++ plugins/ps/Makefile 4 Feb 2016 01:53:39 -
@@ -3,7 +3,7 @@
V =0.2.2
COMMENT = spectre postscript plugin for zathura
DISTNAME = zathura-ps-${V}
-REVISION = 2
+REVISION = 3
HOMEPAGE = http://pwmt.org/projects/zathura/plugins/zathura-ps/
Re: Firefox 44 font change
On Wed, Feb 03, 2016 at 10:56:48PM +0100, Christian Weisgerber wrote:
> Firefox 44 appears to have snuck in a change in font handling:
>
> Bitmap fonts are no longer used. At least that's what I see with
> only the default fonts installed (xenocara defaults plus ghostscript
> since that gets pulled in as a dependency).
>
> This has two effects I noticed:
>
> (1) For Latin script which is otherwise rendered with DejaVu,
> some butt-ugly bitmap font (Lucida, I think) would occasionally
> sneak through on some sites. This no longer happens.
>
> (2) The default CJK fonts are no longer displayed, easily verifiable
> under {ja,ko,zh}.wikipedia.org. I now only get squares with
> Unicode numbers.
>
> Now, I'm not saying this is necessarily a bad thing. I doubt anybody
> will complain about (1). People who actually read CJK text and are
> potentially affected by (2) probably have better fonts installed
> anyway since those shipped with xenocara are really poor.
>
> Landry tells me he can't reproduce this, which is even weirder.
Search the string "font." in about:config. The text in bold are
non-default values. Look if you have the file
.config/fontconfig/fonts.conf. Firefox uses these about:config
settings and fontconfig to select the fonts.
Open "ja.wikipedia.org", click with the secondary button of your mouse
in any line of text and click in "Inspect Element". Click in
"Inspector" and "Fonts". It will show which font is used to render
that text.
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: NEW: py-Fabric
On Tue, Jan 19, 2016 at 12:25:47PM +0100, Pablo Méndez Hernández wrote: > $ cat sysutils/py-Fabric/pkg/DESCR > Fabric is a Python (2.5-2.7) library and command-line tool for streamlining > the > use of SSH for application deployment or systems administration tasks. > > It provides a basic suite of operations for executing local or remote shell > commands (normally or via sudo) and uploading/downloading files, as well as > auxiliary functionality such as prompting the running user for input, or > aborting execution. I've attached an updated version of the port with changes from Pablo and me. The only missing part is one dependency for the tests (an outdated version of fudge). I would like to import the port before of the cvs lock. Comments? OK? -- Juan Francisco Cantero Hurtado http://juanfra.info py-fabric.tgz Description: GNU Unix tar archive
dpb weird behavior. Can anyone reproduce it?
-current, amd64, base and ports tree updated. Probably some details are irrelevant but I don't know where is the problem exactly. Here are the steps: - Create a shellscript with this content: #!/bin/sh /usr/ports/infrastructure/bin/dpb -m -D COLOR=0 -D NO_CURSOR=1 -D ALWAYS_CLEAN=1 -D WAIT_TIMEOUT=0 -q -c -j 4 -p 4 -f 0 -u -U -r -R - Run as a regular user "doas ./your_script.sh". - Wait until dpb is using the 4 slots to "build" the packages. - Press Ctrl+c - Run top -CHIS -s 1 Do you see gcc, make, as, ld, etc running in top? I see a lot of processes related to the build running for a very long time. I tried with zsh and ksh. "fg" doesn't show processes running in the background. -- Juan Francisco Cantero Hurtado http://juanfra.info
graphics/djvulibre: fix a bug in documents with duplicate page titles
The patch adds support for documents with duplicate page titles. I
need this change to update pdf2djvu to the latest version.
I've not tested any djvu viewer, just the conversion. So any test is
welcome.
OK?
Index: Makefile
===
RCS file: /cvs/ports/graphics/djvulibre/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- Makefile12 May 2015 16:10:27 - 1.34
+++ Makefile3 Feb 2016 01:53:18 -
@@ -3,6 +3,7 @@
COMMENT= view, decode and encode DjVu files
DISTNAME= djvulibre-3.5.27
+REVISION= 0
SHARED_LIBS= djvulibre 26.0# 27.0
CATEGORIES=graphics print
Index: patches/patch-libdjvu_DjVmDir_cpp
===
RCS file: patches/patch-libdjvu_DjVmDir_cpp
diff -N patches/patch-libdjvu_DjVmDir_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-libdjvu_DjVmDir_cpp 3 Feb 2016 01:53:18 -
@@ -0,0 +1,94 @@
+$OpenBSD$
+
+"accept documents with duplicate page titles"
+
+http://sourceforge.net/p/djvu/djvulibre-git/ci/77a4dca8dd3acd0acc1680fa14a352c11084e25d/
+https://bitbucket.org/jwilk/pdf2djvu/issues/113/duplicate-page-title-1
+
+--- libdjvu/DjVmDir.cpp.orig Tue Jul 8 23:15:07 2014
libdjvu/DjVmDir.cppWed Feb 3 01:51:28 2016
+@@ -223,7 +223,6 @@ DjVmDir::decode(const GP )
+page2file.resize(-1);
+name2file.empty();
+id2file.empty();
+- title2file.empty();
+
+int ver=str.read8();
+bool bundled=(ver & 0x80)!=0;
+@@ -375,18 +374,6 @@ DjVmDir::decode(const GP )
+ G_THROW( ERR_MSG("DjVmDir.dupl_id") "\t" + file->id);
+ id2file[file->id]=file;
+ }
+-
+- // Generate title2file map
+- for(pos=files_list;pos;++pos)
+- {
+- GP file=files_list[pos];
+- if (file->title.length())
+- {
+-if (title2file.contains(file->title))
+- G_THROW( ERR_MSG("DjVmDir.dupl_title") "\t" + file->title);
+-title2file[file->title]=file;
+- }
+- }
+}
+ }
+
+@@ -556,11 +543,19 @@ DjVmDir::id_to_file(const GUTF8String ) const
+ }
+
+ GP
+-DjVmDir::title_to_file(const GUTF8String ) const
++DjVmDir::title_to_file(const GUTF8String , GPosition spos) const
+ {
+- GCriticalSectionLock lock((GCriticalSection *) _lock);
+- GPosition pos;
+- return (title2file.contains(title,
pos))?title2file[pos]:(GP(0));
++ if (! title)
++return 0;
++ GCriticalSectionLock lock((GCriticalSection *) _lock);
++ if (! spos)
++for (GPosition pos = spos; pos; ++pos)
++ if (files_list[pos]->is_page() && files_list[pos]->title == title)
++return files_list[pos];
++ for (GPosition pos = files_list; pos; ++pos)
++if (files_list[pos]->is_page() && files_list[pos]->title == title)
++ return files_list[pos];
++ return 0;
+ }
+
+ GP
+@@ -661,14 +656,7 @@ DjVmDir::insert_file(const GP & file, int pos_nu
+ G_THROW( ERR_MSG("DjVmDir.dupl_name2") "\t" + file->name);
+name2file[file->name]=file;
+id2file[file->id]=file;
+- if (file->title.length())
+- {
+- if (title2file.contains(file->title))
+- // duplicate titles may become ok some day
+- G_THROW( ERR_MSG("DjVmDir.dupl_title2") "\t" + file->title);
+- title2file[file->title]=file;
+- }
+-
++
+ // Make sure that there is no more than one file with shared annotations
+if (file->is_shared_anno())
+{
+@@ -727,7 +715,6 @@ DjVmDir::delete_file(const GUTF8String )
+ {
+ name2file.del(f->name);
+ id2file.del(f->id);
+- title2file.del(f->title);
+ if (f->is_page())
+ {
+ for(int page=0;pagetitle);
+file->title=title;
+- title2file[title]=file;
+ }
+
+ GPList
Index: patches/patch-libdjvu_DjVmDir_h
===
RCS file: patches/patch-libdjvu_DjVmDir_h
diff -N patches/patch-libdjvu_DjVmDir_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-libdjvu_DjVmDir_h 3 Feb 2016 01:53:18 -
@@ -0,0 +1,41 @@
+$OpenBSD$
+
+"accept documents with duplicate page titles"
+
+http://sourceforge.net/p/djvu/djvulibre-git/ci/77a4dca8dd3acd0acc1680fa14a352c11084e25d/
+https://bitbucket.org/jwilk/pdf2djvu/issues/113/duplicate-page-title-1
+
+--- libdjvu/DjVmDir.h.orig Tue Jul 8 23:15:07 2014
libdjvu/DjVmDir.h Wed Feb 3 01:51:28 2016
+@@ -181,7 +181,8 @@ class DJVUAPI DjVmDir : public GPEnabled (public)
+ /** Translates file IDs to file records. */
+GP id_to_file(const GUTF8String ) const;
+ /** Translates file shortcuts to file records. */
+-
Re: pkg_add (_pfetch) - Permission denied for /root/.netrc
On Mon, Feb 22, 2016 at 10:22:12PM +0100, Marc Espie wrote:
> On Mon, Feb 22, 2016 at 09:08:09PM +, Stuart Henderson wrote:
> > On 2016/02/22 15:46, Jiri B wrote:
> > > Hi,
> > >
> > > I did quick install and then I executed 'pkg_add -iv $packages'
> > > under root user.
> > >
> > > The output get spammed with:
> > >
> > > ftp: /root/.netrc: Permission denied
> > >
> > > IIUC this is caused by 'drop_priviledge_and_setup_env' function
> > > in PackageRepository.pm which changes uid to '_pfetch' which
> > > spawns /bin/sh that cannot access root's homedir.
> > >
> > > OpenBSD 5.9 #1880 Sat Feb 20 2016
> > >
> > > * su - root
> > > * export PKG_PATH=$path
> > > * pkg_add -vi $package
> > > * observe terminal
> > >
> > > j.
> > >
> >
> > Confirmed.
> >
> > I guess most of us haven't noticed this yet because we are using
> > HTTP in PKG_PATH because it's so much faster.
>
> Nope, .netrc is ftp's lair. I don't get why ftp (run as pfetch) will try
> to access root's .netrc.
>
> But I'm going to look at it later tonight.
Jiri, can you try this patch?
cd /usr/src
patch -p1 -i thepatchfile
cd /usr/src/usr.sbin/pkg_add
make clean
make obj
make
make install
diff --git a/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm
b/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm
index 8bb8f51..d949bcf 100644
--- a/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm
+++ b/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm
@@ -600,6 +600,7 @@ sub grab_object
$ftp,
@extra,
"-o",
+ "-n",
"-", $self->url($object->{name})
or $self->{state}->fatal("Can't run ".OpenBSD::Paths->ftp.": #1", $!);
}
Re: Updating stable packages with dpb
On Sat, Feb 27, 2016 at 05:55:30PM +0500, Артур Истомин wrote: > I'm now trying to use dpb for updating packages on OpenBSD 5.8. > My steps: > > pkg_delete -a > /usr/ports/infrastructure/bin/out-of-date | tee report > /usr/ports/infrastructure/bin/dpb -R report > > Is it possible dpb to download all prebuild packages from > OpenBSD's mirrors and build only updated in ports tree? Yes, download the packages from a rsync mirror (like rsync://mirror.yandex.ru/openbsd/5.8/packages/amd64/) to the packages directory (usually /usr/ports/packages/amd64/all) and run dpb. It will only build the packages with a different signature. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: pkg_add (_pfetch) - Permission denied for /root/.netrc
On Mon, Feb 22, 2016 at 10:30:08PM +0100, Juan Francisco Cantero Hurtado wrote:
> On Mon, Feb 22, 2016 at 10:22:12PM +0100, Marc Espie wrote:
> > On Mon, Feb 22, 2016 at 09:08:09PM +, Stuart Henderson wrote:
> > > On 2016/02/22 15:46, Jiri B wrote:
> > > > Hi,
> > > >
> > > > I did quick install and then I executed 'pkg_add -iv $packages'
> > > > under root user.
> > > >
> > > > The output get spammed with:
> > > >
> > > > ftp: /root/.netrc: Permission denied
> > > >
> > > > IIUC this is caused by 'drop_priviledge_and_setup_env' function
> > > > in PackageRepository.pm which changes uid to '_pfetch' which
> > > > spawns /bin/sh that cannot access root's homedir.
> > > >
> > > > OpenBSD 5.9 #1880 Sat Feb 20 2016
> > > >
> > > > * su - root
> > > > * export PKG_PATH=$path
> > > > * pkg_add -vi $package
> > > > * observe terminal
> > > >
> > > > j.
> > > >
> > >
> > > Confirmed.
> > >
> > > I guess most of us haven't noticed this yet because we are using
> > > HTTP in PKG_PATH because it's so much faster.
> >
> > Nope, .netrc is ftp's lair. I don't get why ftp (run as pfetch) will try
> > to access root's .netrc.
> >
> > But I'm going to look at it later tonight.
>
> Jiri, can you try this patch?
>
> cd /usr/src
> patch -p1 -i thepatchfile
> cd /usr/src/usr.sbin/pkg_add
> make clean
> make obj
> make
> make install
>
> diff --git a/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm
> b/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm
> index 8bb8f51..d949bcf 100644
> --- a/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm
> +++ b/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm
> @@ -600,6 +600,7 @@ sub grab_object
> $ftp,
> @extra,
> "-o",
> + "-n",
> "-", $self->url($object->{name})
> or $self->{state}->fatal("Can't run ".OpenBSD::Paths->ftp.": #1", $!);
> }
Ignore the patch, the -n switch breaks the downloads.
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: update fonts/hack-fonts
OK juanfra@.
If you're the MAINTAINER of a port and the update is so
straightforward like this, you don't need OKs from other devs :)
On Thu, Jan 21, 2016 at 03:16:12PM -0500, Michael McConville wrote:
> I don't know why this used the zip archive. Maybe gzip archives weren't
> available when it started.
>
> ok?
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/fonts/hack-fonts/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile 30 Nov 2015 14:09:33 - 1.3
> +++ Makefile 21 Jan 2016 20:14:15 -
> @@ -4,7 +4,7 @@ PKG_ARCH =*
>
> COMMENT =typeface designed for source code
>
> -V = 2.018
> +V = 2.019
> DISTNAME = Hack-v${V:S/./_/}-otf
> PKGNAME =hack-fonts-$V
> CATEGORIES = fonts
> @@ -16,7 +16,6 @@ MAINTAINER =Michael McConville <mmcco@
> PERMIT_PACKAGE_CDROM = Yes
>
> MASTER_SITES =
> https://github.com/chrissimpkins/Hack/releases/download/v$V/
> -EXTRACT_SUFX = .zip
>
> WRKDIST =${WRKDIR}
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/fonts/hack-fonts/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- distinfo 30 Nov 2015 14:09:33 - 1.2
> +++ distinfo 21 Jan 2016 20:14:15 -
> @@ -1,2 +1,2 @@
> -SHA256 (Hack-v2_018-otf.zip) = Q99xiVy4tbDhTyiAqM4mFwZNzDbPIp5WgvHgZROkYEY=
> -SIZE (Hack-v2_018-otf.zip) = 466060
> +SHA256 (Hack-v2_019-otf.tar.gz) =
> /oOGKnFSijpLWVCzyRwqHxLrwZsujzGtl4J73o+4ckI=
> +SIZE (Hack-v2_019-otf.tar.gz) = 464176
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: update fonts/hack-fonts
On Thu, Jan 21, 2016 at 11:34:15PM +0100, Antoine Jacoutot wrote: > On Thu, Jan 21, 2016 at 11:00:15PM +0100, Juan Francisco Cantero Hurtado > wrote: > > OK juanfra@. > > > > If you're the MAINTAINER of a port and the update is so > > straightforward like this, you don't need OKs from other devs :) > > Technically you do. > Unless you're ready to get yelled at when something breaks in a bulk. In this case, the patch is just a minimal update for a font. I'm not saying that he should commit anything without to ask before to other people affected :) -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: LLVM update (again)
On Sun, Jan 24, 2016 at 12:07:03AM +, Stuart Henderson wrote:
> I wouldn't say that this works well with gcc. I would recommend against
> keeping multiple versions of a port without a good and specific reason.
In the gcc case, the latest version is imported, people works on their
ports and when everything works fine with the latest version, this is
promoted as the default version and the older version is deleted. If
some of my ports are broken, I can change MODGCC4_VER and to work
individually in one port without to break other packages which I use
but I don't know how to help to fix the problems.
In addition to that, I would like various versions of llvm (not just
clang) because more and more interpreters/compilers depend of llvm and
we can't have updated packages because for any reason we can't update
llvm due to some conflict with other packages. (example: rubinius
deletion or people wasting their time trying to build an updated llvm
during the first attemps to port rust)
That said, I'm obviously not going to maintain llvm and others will do
the hard work, so my request is just a hope and not a red line or
something similar :)
>
>
> On 23 January 2016 22:16:16 GMT+00:00, Juan Francisco Cantero Hurtado
> <i...@juanfra.info> wrote:
> >Can you modify the structure of devel/llvm/ to something like
> >devel/llvm/version/? With lang/gcc works pretty well, we can work with
> >the latest version while the ports tree uses the stable version by
> >default.
> >
> >
> >On Sat, Jan 23, 2016 at 07:39:22PM +0100, Pascal Stumpf wrote:
> >> So here's an updated diff for LLVM 3.7.1. With landry@'s recent
> >commit,
> >> xulrunner is no longer a showstopper.
> >>
> >>
> >> Index: Makefile
> >> ===
> >> RCS file: /cvs/ports/devel/llvm/Makefile,v
> >> retrieving revision 1.108
> >> diff -u -p -r1.108 Makefile
> >> --- Makefile 24 Aug 2015 07:45:56 - 1.108
> >> +++ Makefile 23 Jan 2016 18:38:51 -
> >> @@ -8,14 +8,17 @@ DPB_PROPERTIES = parallel
> >>
> >> COMMENT = modular, fast C/C++/ObjC compiler, static analyzer and
> >tools
> >>
> >> -LLVM_V = 3.5
> >> -DISTNAME =llvm-${LLVM_V}.20140228
> >> -REVISION =35
> >> +LLVM_V = 3.7.1
> >> +DISTNAME =llvm-${LLVM_V}.src
> >> +PKGNAME = llvm-${LLVM_V}
> >> CATEGORIES = devel
> >> -MASTER_SITES =http://comstyle.com/source/
> >> +DISTFILES = llvm-${LLVM_V}.src${EXTRACT_SUFX} \
> >> + cfe-${LLVM_V}.src${EXTRACT_SUFX}
> >> +MASTER_SITES =http://www.llvm.org/releases/${LLVM_V}/
> >> EXTRACT_SUFX =.tar.xz
> >>
> >> -SHARED_LIBS = clang 1.0
> >> +SHARED_LIBS = clang 2.0 \
> >> + LTO 0.0
> >>
> >> # packager notes in http://llvm.org/docs/Packaging.html
> >> HOMEPAGE =http://www.llvm.org/
> >> @@ -25,15 +28,21 @@ MAINTAINER=Brad Smith <b...@comstyle.co
> >> # BSD
> >> PERMIT_PACKAGE_CDROM =Yes
> >>
> >> -WANTLIB = c m pthread stdc++ z
> >> +WANTLIB = c m pthread z
> >>
> >> MODULES = devel/cmake \
> >> - lang/python
> >> + lang/python \
> >> + gcc4
> >>
> >> -TEST_DEPENDS =devel/dejagnu \
> >> - shells/bash
> >> +MODGCC4_LANGS = c c++
> >> +MODGCC4_ARCHS = *
> >> +
> >> +TEST_DEPENDS =devel/dejagnu \
> >> + shells/bash \
> >> + lang/gcc/${MODGCC4_VERSION},-c++
> >> BUILD_DEPENDS += textproc/py-sphinx
> >> -RUN_DEPENDS +=devel/gtest
> >> +RUN_DEPENDS +=devel/gtest \
> >> + lang/gcc/${MODGCC4_VERSION},-c++
> >>
> >> SEPARATE_BUILD = Yes
> >> CONFIGURE_ARGS = -DLLVM_ENABLE_FFI:Bool=False \
> >> @@ -47,22 +56,34 @@ CONFIGURE_ARGS = -DLLVM_ENABLE_FFI:Bool=
> >> # introduced when PIE was enabled
> >> .if ${MACHINE_ARCH} == "powerpc"
> >> CONFIGURE_ARGS += -DCMAKE_EXE_LINKER_FLAGS="-Wl,--relax -nopie"
> >> +CONFIGURE_ARGS += -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--relax -nopie"
> >> .endif
> >>
> >> TEST_TARGET = check
> >>
> >> +# XXX sync
> >> +GCC_VER = 4.9.3
> >> +.if ${MACHINE_ARCH} == "amd64"
> >> +GCC_CONFIG
Re: LLVM update (again)
On Sun, Jan 24, 2016 at 01:28:34PM +0100, Pascal Stumpf wrote:
> On Sun, 24 Jan 2016 04:13:47 +0100, Juan Francisco Cantero Hurtado wrote:
> > On Sun, Jan 24, 2016 at 12:07:03AM +, Stuart Henderson wrote:
> > > I wouldn't say that this works well with gcc. I would recommend against
> > > keeping multiple versions of a port without a good and specific reason.
> >
> > In the gcc case, the latest version is imported, people works on their
> > ports and when everything works fine with the latest version, this is
> > promoted as the default version and the older version is deleted. If
> > some of my ports are broken, I can change MODGCC4_VER and to work
> > individually in one port without to break other packages which I use
> > but I don't know how to help to fix the problems.
>
> That's more of a side effect. The actual reason the split is still
> there is the fact that some architectures tend to get broken by GCC
> upstream frequently. Right now, alpha is stuck on 4.6.
>
> So far, there has been no need for an arch-based split in LLVM (thank
> god). Regarding the update process, I see no reason why this can't be
> done like with any other port (submit update, bulk build, fix bugs,
> repeat).
>
> In addition, the LLVM development process is more streamlined. They
> focus more on getting the current trunk up to a decent state than
> maintaining a bazillion 3.x branches. The 3.4 version we have in our
> tree is *ancient* by their standards. Using it is like using OpenBSD
> 5.4 and then coming to misc@ with a bug report. You will get told to
> retry with -current. Rightfully.
>
>
> > In addition to that, I would like various versions of llvm (not just
> > clang) because more and more interpreters/compilers depend of llvm and
> > we can't have updated packages because for any reason we can't update
> > llvm due to some conflict with other packages. (example: rubinius
> > deletion or people wasting their time trying to build an updated llvm
> > during the first attemps to port rust)
>
> But that is not the case right now. Nothing in the tree is specifically
> stuck on LLVM 3.4. If that changes, I'd be happy to revisit the
> decision.
Just to clarify. I was not asking to keep 3.4 in the tree. I was
thinking in future releases of LLVM.
Anyway, a lot of opposition to my idea, so go ahead with the update.
>
> > That said, I'm obviously not going to maintain llvm and others will do
> > the hard work, so my request is just a hope and not a red line or
> > something similar :)
> >
> > >
> > >
> > > On 23 January 2016 22:16:16 GMT+00:00, Juan Francisco Cantero Hurtado
> > > <i...@juanfra.info> wrote:
> > > >Can you modify the structure of devel/llvm/ to something like
> > > >devel/llvm/version/? With lang/gcc works pretty well, we can work with
> > > >the latest version while the ports tree uses the stable version by
> > > >default.
> > > >
> > > >
> > > >On Sat, Jan 23, 2016 at 07:39:22PM +0100, Pascal Stumpf wrote:
> > > >> So here's an updated diff for LLVM 3.7.1. With landry@'s recent
> > > >commit,
> > > >> xulrunner is no longer a showstopper.
> > > >>
> > > >>
> > > >> Index: Makefile
> > > >> ===
> > > >> RCS file: /cvs/ports/devel/llvm/Makefile,v
> > > >> retrieving revision 1.108
> > > >> diff -u -p -r1.108 Makefile
> > > >> --- Makefile 24 Aug 2015 07:45:56 - 1.108
> > > >> +++ Makefile 23 Jan 2016 18:38:51 -
> > > >> @@ -8,14 +8,17 @@ DPB_PROPERTIES = parallel
> > > >>
> > > >> COMMENT = modular, fast C/C++/ObjC compiler, static analyzer and
> > > >tools
> > > >>
> > > >> -LLVM_V = 3.5
> > > >> -DISTNAME =llvm-${LLVM_V}.20140228
> > > >> -REVISION =35
> > > >> +LLVM_V = 3.7.1
> > > >> +DISTNAME =llvm-${LLVM_V}.src
> > > >> +PKGNAME = llvm-${LLVM_V}
> > > >> CATEGORIES = devel
> > > >> -MASTER_SITES =http://comstyle.com/source/
> > > >> +DISTFILES = llvm-${LLVM_V}.src${EXTRACT_SUFX} \
> > > >> + cfe-${LLVM_V}.src${EXTRACT_SUFX}
> > > >> +MASTER_SITES =http://www.llvm.org/releases/${LLVM_V}/
> > > >> EXTRACT_SUFX =.tar.xz
> > > >>
> > > >&g
Re: NEW: htop 2.0.0
On Mon, Feb 15, 2016 at 09:47:54PM +, Pedro de Oliveira wrote: > Hi again, > > Here is an updated version, with two patches from github, it now also > passes portcheck. > I believe that in the next version both patches will already be in upstream. > > https://github.com/hishamhm/htop/pull/398 > https://github.com/hishamhm/htop/pull/376 I've attached an updated version of your port. You forgot to double-check some parts :) > > On Sun, Feb 14, 2016 at 10:08 PM, Juan Francisco Cantero Hurtado > <i...@juanfra.info> wrote: > > On Thu, Feb 11, 2016 at 08:53:42PM -0500, Michael McConville wrote: > >> Pedro de Oliveira wrote: > >> > Hi, > >> > > >> > Attached is a new port for sysutils/htop.The new 2.0.0 release now > >> > supports OpenBSD. > >> > It's my first port, so be easy! > >> > > >> > Any comments? OK to import? > >> > > >> > Regards, > >> > Pedro de Oliveira > >> > >> Hi, Pedro. > >> > >> I wrote the OpenBSD-specific htop code. I was planning on making a > >> proper port ASAP; thanks for beating me to it! :-) I'll try to review > >> it this weekend. > >> > >> It's too late to get it into 5.9, sadly. This gives us more time to > >> improve the OS-specific code, though. > >> > >> If you want to help with that, you could review and test this patch by > >> juanfra@: > >> > >> https://github.com/hishamhm/htop/pull/376 > > > > I've seeing a bunch of double-free and use-after-free in htop. Please, > > run your tests with "MALLOC_OPTIONS=CFGJU htop" and fix the code > > yourself in the upstream github repo if you can. -- Juan Francisco Cantero Hurtado http://juanfra.info htop.tgz Description: GNU Unix tar archive
Re: [UPDATE] plan9/drawterm (switch to new source repository)
On Sat, Feb 20, 2016 at 08:56:39PM -0500, s...@stanleylieber.com wrote: > Supercedes most recent update. The original drawterm is effectively > abandoned by its author. This update switches to a new fork that is > currenlty being maintained against the 9front fork of Plan 9. Latest > revision from 20160220. > > This update: > > - fixes a glitch in graphics rendering, primarily noticed > when viewing images in the web browser mothra(1). > > - defaults to new dp9ik authentication and rcpu(1) connection > method, devolving to the old p9sk1 and cpu(1). > > - adds new cryptographic support from 9front libmp and libsec > libraries. > > Also updated my e-mail address from stanley.lie...@gmail.com > to s...@stanleylieber.com, because I am transitioning away from > Google services. > > Tested only on amd64. > > http://openbsd.stanleylieber.com/drawterm/drawterm-port-20160220.tgz > > It would be great if this could make it into 5.9. Most users of > drawterm on OpenBSD will want to take advantage of dp9ik and rcpu(1). Too late for 5.9. Sorry. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: NEW: htop 2.0.0
On Thu, Feb 11, 2016 at 08:53:42PM -0500, Michael McConville wrote: > Pedro de Oliveira wrote: > > Hi, > > > > Attached is a new port for sysutils/htop.The new 2.0.0 release now > > supports OpenBSD. > > It's my first port, so be easy! > > > > Any comments? OK to import? > > > > Regards, > > Pedro de Oliveira > > Hi, Pedro. > > I wrote the OpenBSD-specific htop code. I was planning on making a > proper port ASAP; thanks for beating me to it! :-) I'll try to review > it this weekend. > > It's too late to get it into 5.9, sadly. This gives us more time to > improve the OS-specific code, though. > > If you want to help with that, you could review and test this patch by > juanfra@: > > https://github.com/hishamhm/htop/pull/376 I've seeing a bunch of double-free and use-after-free in htop. Please, run your tests with "MALLOC_OPTIONS=CFGJU htop" and fix the code yourself in the upstream github repo if you can. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: editors/libreoffice: missing dependency gtk+3 [?]
On Fri, Mar 11, 2016 at 04:53:42PM -0500, Michael Reed wrote: > Hi, > > I started experiencing crashes with the libreoffice port when it was > updated from 5.0.42 -> 5.1.03 [1]. It would bail out with this error > message: > > terminate called after throwing an instance of > 'com::sun::star::uno::DeploymentException' > > After some googling and grepping, I figured out that installing gtk+3 > fixes the issue. It seems like gtk+3 is used in at least one place in > libreoffice: > > $ ldd /usr/local/lib/libreoffice/program/liblibreofficekitgtk.so | grep > libgtk > 109ff822e000 109ff8d73000 rlib 0 1 0 > /usr/local/lib/libgtk-3.so.1800.0 That's correct. > > $ pkg_info -L gtk+3 | grep /usr/local/lib/libgtk-3.so.1800.0 > /usr/local/lib/libgtk-3.so.1800.0 > > ... which is weird, as the libreoffice UI doesn't look like any GTK3 app > I've ever seen. Anyway, I'm confused as to why I need to install gtk+3 > manually, as the following information makes me believe it should be > automatically pulled in as a dependency: > > $ pkg_info -f libreoffice | grep ^@depend | grep gtk > @depend x11/gtk+2,-main:gtk+2-*:gtk+2-2.24.30 > @depend x11/gtk+3,-guic:gtk-update-icon-cache-*:gtk-update- -guic is a subpackage. It's only used to generate the icons cache. Maybe the MAINTAINER forgot to add gtk+3 to the WANTLIBs. > > I thought that there might be something wrong with my system, but > pkg_check(8) didn't turn up anything useful so I'm not sure. > > [1]: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/editors/libreoffice/Makefile?rev=1.141=text/x-cvsweb-markup > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: LLVM 3.7.1 on powerpc
On Sun, Mar 13, 2016 at 11:14:43PM +0100, hans wrote: > The new port of LLVM (3.7.1 as currently present in ports) > comes a much longer way to actually building on macppc. > However, it eventually fails with > > # make > ===> Building for llvm-3.7.1p0 > [1/2] : && /usr/ports/pobj/llvm-3.7.1/bin/c++ -O2 -pipe-fPIC > -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings > -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long > -Wno-maybe-uninitialized -Wno-comment -std=c++11 -ffunction-sections > -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing > -DNDEBUG -Wl,--relax -nopie -Wl,-allow-shlib-undefined-Wl,-O3 > tools/clang/tools/c-arcmt-test/CMakeFiles/c-arcmt-test.dir/c-arcmt-test.c.o > -o bin/c-arcmt-test -L/usr/ports/pobj/llvm-3.7.1/build-powerpc/lib -lclang > -Wl,-rpath,"\$ORIGIN/../lib" -Wl,-rpath-link,/usr/X11R6/lib && : > FAILED: : && /usr/ports/pobj/llvm-3.7.1/bin/c++ -O2 -pipe-fPIC > -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings > -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long > -Wno-maybe-uninitialized -Wno-comment -std=c++11 -ffunction-sections > -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing > -DNDEBUG -Wl,--relax -nopie -Wl,-allow-shlib-undefined-Wl,-O3 > tools/clang/tools/c-arcmt-test/CMakeFiles/c-arcmt-test.dir/c-arcmt-test.c.o > -o bin/c-arcmt-test -L/usr/ports/pobj/llvm-3.7.1/build-powerpc/lib -lclang > -Wl,-rpath,"\$ORIGIN/../lib" -Wl,-rpath-link,/usr/X11R6/lib && : > /usr/ports/pobj/llvm-3.7.1/build-powerpc/lib/libclang.so.2.0:(.sdata+0x0): > multiple definition of `__dso_handle' > /usr/lib/crtbegin.o:(.sdata+0x0): first defined here > /usr/bin/ld: Disabling relaxation: it will not work with multiple definitions > /usr/ports/pobj/llvm-3.7.1/build-powerpc/lib/libclang.so.2.0:(.openbsd.randomdata+0x0): > multiple definition of `__guard_local' > /usr/lib/crtbegin.o:(.openbsd.randomdata+0x0): first defined here > /usr/ports/pobj/llvm-3.7.1/build-powerpc/lib/libclang.so.2.0: warning: > warning: sprintf() is often misused, please use snprintf() > collect2: error: ld returned 1 exit status > ninja: build stopped: subcommand failed. > *** Error 1 in . (/usr/ports/devel/cmake/cmake.port.mk:31 'do-build': @cd > /usr/ports/pobj/llvm-3.7.1/build-powerpc && exec /usr/bin/env -i L...) > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2750 > '/usr/ports/pobj/llvm-3.7.1/build-powerpc/.build_done') > *** Error 1 in /usr/ports/devel/llvm > (/usr/ports/infrastructure/mk/bsd.port.mk:2476 'all') > > Indeed, the symbols __dso_handle and __guard_local defined > in libclang.so.2.0 are also defined in /usr/lib/crtbegin.o > > Is this a powerpc specific problem? Yes, known bug. https://marc.info/?l=openbsd-ports=145475539902448=2 > It builds fine on amd64. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: building 5.8 stable with ports, lynx is wrong
The URLs are fixed in the -stable branch. Follow the instructions in http://www.openbsd.org/anoncvs.html#using . Use "ports" instead of "src" in the cvs command. On Tue, Mar 08, 2016 at 09:56:07PM -0500, Implausibility wrote: > There is still a problem with lynx in OpenBSD 5.8, and it sounds related to > this issue, as it's complaining that the appropriate version number can't be > found. > > I downloaded ports.tar.gz today (dated August 10th, 2015), and building > firefox fails because lynx can't be built -- there's a 404 error while it's > trying to download the specified version number. > > I'm rather new to OpenBSD, so how do I get a fresher copy of either... > - the ports archive > - the makefile for lynx in /usr/ports > - lynx so that the build system will recognize it as having been installed > > ...? > > Thanks. > > > > On Feb 1, 2016, at 7:15 PM, sven falempin <sven.falem...@gmail.com> wrote: > > > > On Mon, Feb 1, 2016 at 5:19 PM, Stuart Henderson <st...@openbsd.org> wrote: > > > >> On 2016/02/01 16:21, sven falempin wrote: > >>> On Mon, Feb 1, 2016 at 3:22 PM, Stuart Henderson <st...@openbsd.org> > >> wrote: > >>> > >>>> On 2016/02/01 14:36, sven falempin wrote: > >>>>> Also ftp disagree on the minor > >>>>> base is 4, and france is 8 > >>>> > >>>> I can't make sense of your email. > >>>> > >> > >> Oh, you are talking about the distfile mirroring. This is only done > >> periodically. > >> > >>> base is 4: > >> > >> This would have been clearer if you had said 'ftp.openbsd.org' instead > >> of 'base', and especially if you had mentioned 'distfiles'. Most people > >> here will think 'base' is talking about 'the base OS'. > >> > >>> http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/lynx2.8.9dev.8.tar.bz2 > >>> france is 8: > >>> http://ftp.openbsd.org/pub/OpenBSD/distfiles/lynx2.8.9dev.4.tar.bz2 > >>> Makefile is 6: > >>> lynx2.8.9dev.6.tar.bz2 > >> > >> The port Makefile and the packages in snapshots are for lynx2.8.9dev.8. > >> > >> ftp.openbsd.org should catch up in distfiles/ sometime, but it's not > >> very important, this is only used as a backup if the main server > >> listed in the port's Makefile as MASTER_SITES is down, or if the > >> file has been removed from there. > >> > >> > > it is not important, but the .8 is not building , patch does not apply , > > while .4 is building. > > > > and master site is down :-( since friday > > > > the patch put the home page to openbsd instead of lynx, > > > > even more important :D > > > > -- > > - > > () ascii ribbon campaign - against html e-mail > > /\ > > > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [update] ecl-16.2 take 2
On Sat, Mar 12, 2016 at 08:33:54AM +0200, Timo Myyrä wrote:
> Hi,
>
> Seems my ports@ subscription had dropped so the late reply.
>
> Your right in that patching the missing file is a bit ugly.
> Here's take 2 to use pre-build step to issue simple copy.
>
> Timo
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ecl/Makefile,v
> retrieving revision 1.27
> diff -u -u -p -r1.27 Makefile
> --- Makefile 25 Jan 2016 19:52:07 - 1.27
> +++ Makefile 12 Mar 2016 06:36:04 -
> @@ -7,9 +7,9 @@ BROKEN-mips64 = ecl_min fails
> BROKEN-sparc = infinite loop while building
> BROKEN-arm = infinite loop while building
>
> -V = 16.0.0
> +V = 16.1.2
> DISTNAME = ecl-$V
> -SHARED_LIBS += ecl 4.0
> +SHARED_LIBS += ecl 5.0
> SHARED_ONLY =Yes
>
> HOMEPAGE = https://common-lisp.net/project/ecl/
> @@ -20,7 +20,7 @@ EXTRACT_SUFX = .tgz
> # GPLv2 or later
> PERMIT_PACKAGE_CDROM = Yes
>
> -MASTER_SITES = ${HOMEPAGE}files/
> +MASTER_SITES = ${HOMEPAGE}files/release/${V}/
>
> CONFIGURE_STYLE =gnu
> TEST_TARGET =check
> @@ -45,5 +45,9 @@ LIB_DEPENDS += devel/gmp \
> devel/libffi
>
> TEST_DEPENDS = ${BASE_PKGPATH}
> +
> +# XXX: Workaround for missing Copyright file
> +pre-build:
> + @cp ${WRKSRC}/{LICENSE,Copyright}
I would prefer "post-patch" instead of "pre-build".
BTW, why do you need copy manually the file?
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/ecl/distinfo,v
> retrieving revision 1.7
> diff -u -u -p -r1.7 distinfo
> --- distinfo 29 Aug 2015 14:48:34 - 1.7
> +++ distinfo 12 Mar 2016 06:36:04 -
> @@ -1,2 +1,2 @@
> -SHA256 (ecl-16.0.0.tgz) = ND7Uw+SQZWJ1emA5uFzhbTPdXoAB10AEk2eVmD468DM=
> -SIZE (ecl-16.0.0.tgz) = 8009304
> +SHA256 (ecl-16.1.2.tgz) = LUgrGgpPvV2IFDRRcDInnYCMtkBeIt2R721zNTRGS5k=
> +SIZE (ecl-16.1.2.tgz) = 7449461
> Index: patches/patch-src_configure
> ===
> RCS file: /cvs/ports/lang/ecl/patches/patch-src_configure,v
> retrieving revision 1.6
> diff -u -u -p -r1.6 patch-src_configure
> --- patches/patch-src_configure 29 Aug 2015 14:48:34 - 1.6
> +++ patches/patch-src_configure 12 Mar 2016 06:36:04 -
> @@ -1,16 +1,16 @@
> -$OpenBSD: patch-src_configure,v 1.6 2015/08/29 14:48:34 jasper Exp $
> src/configure.orig Mon Aug 24 15:30:10 2015
> -+++ src/configureMon Aug 24 15:31:21 2015
> -@@ -4948,7 +4948,7 @@ case "${host_os}" in
> - BUNDLE_LDFLAGS="-shared ${LDFLAGS}"
> - ECL_LDRPATH="-Wl,--rpath,~A"
> - clibs="-lpthread -lm"
> --SONAME="${SHAREDPREFIX}ecl.${SHAREDEXT}.SOVERSION"
> -+SONAME="${SHAREDPREFIX}ecl.${SHAREDEXT}.${ECLLIB_VERSION}"
> - SONAME_LDFLAGS="-Wl,-soname,SONAME"
> - ;;
> - solaris*)
> -@@ -9376,7 +9376,7 @@ if test ${enable_shared} = "yes"; then
> +$OpenBSD$
> +--- src/configure.orig Thu Mar 10 22:19:22 2016
> src/configureThu Mar 10 22:20:21 2016
> +@@ -4966,7 +4966,7 @@ LSP_FEATURES="(cons :android ${LSP_FEATURES})"
> + BUNDLE_LDFLAGS="-shared ${LDFLAGS}"
> + ECL_LDRPATH="-Wl,--rpath,~A"
> + clibs="-lpthread -lm"
> +- SONAME="${SHAREDPREFIX}ecl.${SHAREDEXT}.SOVERSION"
> ++SONAME="${SHAREDPREFIX}ecl.${SHAREDEXT}.${ECLLIB_VERSION}"
> + SONAME_LDFLAGS="-Wl,-soname,SONAME"
> + ;;
> + solaris*)
> +@@ -9455,7 +9455,7 @@ if test ${enable_shared} = "yes"; then
>
> $as_echo "#define ENABLE_DLOPEN 1" >>confdefs.h
>
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: Maven-based projects vs. our build process
On Tue, Mar 15, 2016 at 12:56:22PM -0400, Bryan C. Everly wrote:
> Hi,
>
> I have several maven-based projects that I'd like to create ports for, but
> our build process makes that challenging.
>
> Maven (for those who don't know) likes to download additional files as it
> compiles which is a non-starter for our build process. A solution that I
> have found to work around this is to run maven once, let it cache the files
> locally, turn them into a tarball which I then place in my "files"
> directory and make the real port run maven in offline mode from the cached
> files in the tarball.
Upload the tarball to somewhere and use {pre,post,do}-configure,build,etc
to build the port. (look in man bsd.port.mk)
You can use various distfiles per port.
>
> This process works, but it sure seems awkward.
>
> Does anyone have any suggestions on how I could make this better?
>
> Or even better, perhaps I'm missing an understanding of part of the build
> infrastructure that I could get educated on. :-)
>
> Thanks,
> Bryan
--
Juan Francisco Cantero Hurtado http://juanfra.info
UPDATE: lang/go 1.6
I just ran "make test" on amd64, so any additional tests are welcome.
OK?
Index: Makefile
===
RCS file: /cvs/ports/lang/go/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile14 Jan 2016 12:11:50 - 1.28
+++ Makefile29 Mar 2016 01:26:05 -
@@ -4,7 +4,7 @@ ONLY_FOR_ARCHS =${GO_ARCHS}
COMMENT = Go programming language
-VERSION = 1.5.3
+VERSION = 1.6
EXTRACT_SUFX = .src.tar.gz
DISTNAME = go${VERSION}
PKGNAME = go-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/lang/go/distinfo,v
retrieving revision 1.15
diff -u -p -r1.15 distinfo
--- distinfo14 Jan 2016 12:11:50 - 1.15
+++ distinfo29 Mar 2016 01:26:05 -
@@ -1,2 +1,2 @@
-SHA256 (go1.5.3.src.tar.gz) = dU4G2rHDGrFo/J254yWWc0AV6p4kvETK5/I39BfOTv4=
-SIZE (go1.5.3.src.tar.gz) = 12057623
+SHA256 (go1.6.src.tar.gz) = qWzOjOQ6m/mypMfUcLx+4MsAQQ2oFZgGgcg1Mhjc8UY=
+SIZE (go1.6.src.tar.gz) = 12613308
Index: pkg/PLIST
===
RCS file: /cvs/ports/lang/go/pkg/PLIST,v
retrieving revision 1.13
diff -u -p -r1.13 PLIST
--- pkg/PLIST 5 Dec 2015 05:01:24 - 1.13
+++ pkg/PLIST 29 Mar 2016 01:26:05 -
@@ -74,6 +74,7 @@ go/doc/go1.2.html
go/doc/go1.3.html
go/doc/go1.4.html
go/doc/go1.5.html
+go/doc/go1.6.html
go/doc/go1.html
go/doc/go1compat.html
go/doc/go_faq.html
@@ -182,8 +183,14 @@ go/misc/cgo/errors/
go/misc/cgo/errors/err1.go
go/misc/cgo/errors/err2.go
go/misc/cgo/errors/err3.go
+go/misc/cgo/errors/issue11097a.go
+go/misc/cgo/errors/issue11097b.go
+go/misc/cgo/errors/issue13129.go
+go/misc/cgo/errors/issue13423.go
+go/misc/cgo/errors/issue13635.go
go/misc/cgo/errors/issue7757.go
go/misc/cgo/errors/issue8442.go
+go/misc/cgo/errors/ptr.go
go/misc/cgo/errors/test.bash
go/misc/cgo/gmp/
go/misc/cgo/gmp/fib.go
@@ -221,6 +228,7 @@ go/misc/cgo/test/callback_c_gccgo.c
go/misc/cgo/test/cflags.go
go/misc/cgo/test/cgo_linux_test.go
go/misc/cgo/test/cgo_test.go
+go/misc/cgo/test/cgo_unix_test.go
go/misc/cgo/test/cthread.go
go/misc/cgo/test/cthread_unix.c
go/misc/cgo/test/cthread_windows.c
@@ -228,12 +236,18 @@ go/misc/cgo/test/duplicate_symbol.go
go/misc/cgo/test/env.go
go/misc/cgo/test/exports.go
go/misc/cgo/test/fpvar.go
+go/misc/cgo/test/gcc68255/
+go/misc/cgo/test/gcc68255.go
+go/misc/cgo/test/gcc68255/a.go
+go/misc/cgo/test/gcc68255/c.c
+go/misc/cgo/test/gcc68255/c.h
go/misc/cgo/test/helpers.go
go/misc/cgo/test/issue10303.go
go/misc/cgo/test/issue11925.go
go/misc/cgo/test/issue12030.go
go/misc/cgo/test/issue1222.go
go/misc/cgo/test/issue1328.go
+go/misc/cgo/test/issue13402.go
go/misc/cgo/test/issue1560.go
go/misc/cgo/test/issue1635.go
go/misc/cgo/test/issue2462.go
@@ -245,6 +259,7 @@ go/misc/cgo/test/issue3729w.go
go/misc/cgo/test/issue3741.go
go/misc/cgo/test/issue3775.go
go/misc/cgo/test/issue3945.go
+go/misc/cgo/test/issue4029.c
go/misc/cgo/test/issue4029.go
go/misc/cgo/test/issue4029w.go
go/misc/cgo/test/issue4054a.go
@@ -311,8 +326,14 @@ go/misc/cgo/test/issue9400/asm_ppc64x.s
go/misc/cgo/test/issue9400/gccgo.go
go/misc/cgo/test/issue9400/stubs.go
go/misc/cgo/test/issue9400_linux.go
+go/misc/cgo/test/issue9510.go
+go/misc/cgo/test/issue9510a/
+go/misc/cgo/test/issue9510a/a.go
+go/misc/cgo/test/issue9510b/
+go/misc/cgo/test/issue9510b/b.go
go/misc/cgo/test/issue9557.go
go/misc/cgo/test/setgid_linux.go
+go/misc/cgo/test/sigaltstack.go
go/misc/cgo/test/sigprocmask_linux.c
go/misc/cgo/test/sigprocmask_linux.go
go/misc/cgo/test/sleep_windows_386.go
@@ -320,9 +341,18 @@ go/misc/cgo/testasan/
go/misc/cgo/testasan/main.go
go/misc/cgo/testcarchive/
go/misc/cgo/testcarchive/main.c
+go/misc/cgo/testcarchive/main2.c
+go/misc/cgo/testcarchive/main3.c
+go/misc/cgo/testcarchive/main4.c
go/misc/cgo/testcarchive/src/
go/misc/cgo/testcarchive/src/libgo/
go/misc/cgo/testcarchive/src/libgo/libgo.go
+go/misc/cgo/testcarchive/src/libgo2/
+go/misc/cgo/testcarchive/src/libgo2/libgo2.go
+go/misc/cgo/testcarchive/src/libgo3/
+go/misc/cgo/testcarchive/src/libgo3/libgo3.go
+go/misc/cgo/testcarchive/src/libgo4/
+go/misc/cgo/testcarchive/src/libgo4/libgo4.go
go/misc/cgo/testcarchive/src/p/
go/misc/cgo/testcarchive/src/p/p.go
go/misc/cgo/testcarchive/test.bash
@@ -331,11 +361,19 @@ go/misc/cgo/testcshared/main0.c
go/misc/cgo/testcshared/main1.c
go/misc/cgo/testcshared/main2.c
go/misc/cgo/testcshared/main3.c
+go/misc/cgo/testcshared/main4.c
+go/misc/cgo/testcshared/main5.c
go/misc/cgo/testcshared/src/
go/misc/cgo/testcshared/src/libgo/
go/misc/cgo/testcshared/src/libgo/libgo.go
go/misc/cgo/testcshared/src/libgo2/
+go/misc/cgo/testcshared/src/libgo2/dup2.go
+go/misc/cgo/testcshared/src/libgo2/dup3.go
go/misc/cgo/testcshared/src/libgo2/libgo2.go
+go/misc/cgo/testcshared/src/libgo4/
Re: UPDATE: lang/go 1.6
On Tue, Apr 05, 2016 at 06:42:06PM +0100, Stuart Henderson wrote: > On 2016/04/05 00:51, Juan Francisco Cantero Hurtado wrote: > > > > > > Here is the whole go update as a single huge diff including lang/go, > > > devel/go-tools, three new go ports, websocketd update and net/websocketd > > > removal. The changes to juanfra@'s lang/go diff boil down to simplified > > > install stage - I copy over everything and then remove bootstrap. > > > > > > I considered removing tests, but upstream says that go implementation > > > should serve a reference for good practices in go development, so these > > > tests may serve a reference implementation purposes. > > > > > > OK? > > > > Sorry for the delay. > > > > - Use "@comment" for the bootstrap lines in PLIST > > It's easier to handle updates if you rm rather than @comment. > But let's hear what the maintainer says first :-) Why is easier? update-plist would keep the lines with @comment, right? -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: lang/go 1.6
On Tue, Apr 05, 2016 at 09:29:59PM +0100, Stuart Henderson wrote:
> On 2016/04/05 21:15, Juan Francisco Cantero Hurtado wrote:
> > On Tue, Apr 05, 2016 at 06:42:06PM +0100, Stuart Henderson wrote:
> > > On 2016/04/05 00:51, Juan Francisco Cantero Hurtado wrote:
> > > > >
> > > > > Here is the whole go update as a single huge diff including lang/go,
> > > > > devel/go-tools, three new go ports, websocketd update and
> > > > > net/websocketd
> > > > > removal. The changes to juanfra@'s lang/go diff boil down to
> > > > > simplified
> > > > > install stage - I copy over everything and then remove bootstrap.
> > > > >
> > > > > I considered removing tests, but upstream says that go implementation
> > > > > should serve a reference for good practices in go development, so
> > > > > these
> > > > > tests may serve a reference implementation purposes.
> > > > >
> > > > > OK?
> > > >
> > > > Sorry for the delay.
> > > >
> > > > - Use "@comment" for the bootstrap lines in PLIST
> > >
> > > It's easier to handle updates if you rm rather than @comment.
> > > But let's hear what the maintainer says first :-)
> >
> > Why is easier? update-plist would keep the lines with @comment, right?
>
> Yes and that is part of the problem, it will keep *all* the lines with
> @comment (even if some of the files are removed), but it won't add any
> new @comment markers for files in the same directory.
>
> For the same reason it's usually better to rm *.la rather than add them
> as @comments.
Forget about my comment. I didn't see the line "rm -R
${GOROOT}/pkg/bootstrap" in the Makefile. The files will not show up
again in the future in the PLIST.
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: www/nostromo
Can you change the COMMENT to something like "simple, fast and secure HTTP server" and the HOMEPAGE to http://www.nazgul.ch/dev_nostromo.html? On Tue, Apr 12, 2016 at 11:31:51PM +0200, Marcus Glocker wrote: > Update to nostromo-1.9.6 > > > Index: www/nostromo/Makefile > === > RCS file: /cvs/ports/www/nostromo/Makefile,v > retrieving revision 1.40 > diff -u -p -u -p -r1.40 Makefile > --- www/nostromo/Makefile 11 Mar 2013 11:44:43 - 1.40 > +++ www/nostromo/Makefile 12 Apr 2016 21:11:22 - > @@ -2,7 +2,7 @@ > > COMMENT= Nostromo webserver > > -DISTNAME=nostromo-1.9.5 > +DISTNAME=nostromo-1.9.6 > CATEGORIES= www > MASTER_SITES=http://www.nazgul.ch/dev/ > > Index: www/nostromo/distinfo > === > RCS file: /cvs/ports/www/nostromo/distinfo,v > retrieving revision 1.31 > diff -u -p -u -p -r1.31 distinfo > --- www/nostromo/distinfo 18 Jan 2015 03:15:39 - 1.31 > +++ www/nostromo/distinfo 12 Apr 2016 21:11:22 - > @@ -1,2 +1,2 @@ > -SHA256 (nostromo-1.9.5.tar.gz) = X2JXgoXgJElAa0bPBqeIj+PcSpC+31jMGFI7rWL2uRQ= > -SIZE (nostromo-1.9.5.tar.gz) = 47798 > +SHA256 (nostromo-1.9.6.tar.gz) = VBSU7P6v7FjAh2zMkMwjsG4BRPb0ICmvRMfNsfQR6Os= > +SIZE (nostromo-1.9.6.tar.gz) = 50937 > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: UPDATE: lang/go 1.6
On Tue, Apr 05, 2016 at 11:43:30PM +0200, Dmitrij D. Czarkoff wrote:
> Juan Francisco Cantero Hurtado said:
> > The files will not show up again in the future in the PLIST.
>
> Indeed. Also
>
> > - I would prefer to keep the old behavior in do-install. INSTALL_* will
> > use the correct permissions for every type of file/dir.
>
> We currently install everything (except bin/go and bin/gofmt) with
> INSTALL_DATA, thus stripping executable bits from several tools and
> scripts. I am not sure it is a good idea. FWIW I switched do-install
> to cp because tests of some package wanted to use some script from go's
> own tests, and assumed that it has 'x' permission bit set. Provided
> that we don't package much software in go, it may be worth keeping
> closer to upstream.
>
> Tracking permissions manually and using INSTALL_{PROGRAM,SCRIPT} when
> needed would require much effort with no real benefit. Just using cp
> instead we get
>
> $ find /usr/local/go -type f -exec stat -f '%Su %Sg %Sp' {} + | sort | uniq
> -c
> 7483 root bin -r--r--r--
> 34 root bin -r-xr-xr-x
>
> with two lines of shell commands. Even if permission changes will be
> required in future, it will likely be easier to chmod individual files.
Yes, maybe I'm being too conservative here.
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: [update] SABnzbd to 1.0.0
On Wed, Mar 16, 2016 at 02:28:30PM +1300, Carlin Bingham wrote:
> On Tue, Mar 15, 2016 at 11:42:56PM +, Stuart Henderson wrote:
> > There is a proper uploaded tarball,
> > https://github.com/sabnzbd/sabnzbd/releases/download/1.0.0/SABnzbd-1.0.0-src.tar.gz
> > - please use this rather than a tag-based checkout (get rid of the GH_
> > variables).
>
> This better?
>
>
> Index: news/sabnzbd/Makefile
> ===
> RCS file: /cvs/ports/news/sabnzbd/Makefile,v
> retrieving revision 1.7
> diff -u -p -u -r1.7 Makefile
> --- news/sabnzbd/Makefile 2 Nov 2015 11:56:54 - 1.7
> +++ news/sabnzbd/Makefile 16 Mar 2016 01:14:33 -
> @@ -1,18 +1,18 @@
> # $OpenBSD: Makefile,v 1.7 2015/11/02 11:56:54 espie Exp $
>
> COMMENT =retrieve and process nzb-files via web interface
> -VERSION =0.7.20
> +VERSION =1.0.0
> DISTNAME = SABnzbd-${VERSION}-src
> PKGNAME =sabnzbd-${VERSION}
> CATEGORIES = news
> HOMEPAGE = http://sabnzbd.org/
> MAINTAINER = Marcus Glocker
> -REVISION = 0
>
> # GPLv2
> PERMIT_PACKAGE_CDROM = Yes
>
> -MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=sabnzbdplus/}
> +MASTER_SITES =
> https://github.com/sabnzbd/sabnzbd/releases/download/${VERSION}/
> +EXTRACT_SUFX = .tar.gz
EXTRACT_SUFX always defaults to .tar.gz.
>
> MODULES =lang/python
>
> Index: news/sabnzbd/distinfo
> ===
> RCS file: /cvs/ports/news/sabnzbd/distinfo,v
> retrieving revision 1.3
> diff -u -p -u -r1.3 distinfo
> --- news/sabnzbd/distinfo 17 Apr 2015 11:43:09 - 1.3
> +++ news/sabnzbd/distinfo 16 Mar 2016 01:14:33 -
> @@ -1,2 +1,2 @@
> -SHA256 (SABnzbd-0.7.20-src.tar.gz) =
> ILOkYToOze3k/f62KK6AbkWKwab7aEMGMo3U7R+vh0I=
> -SIZE (SABnzbd-0.7.20-src.tar.gz) = 2389762
> +SHA256 (SABnzbd-1.0.0-src.tar.gz) =
> dXPfr9bztR6Jn0dDbeDgs9joOlaOKm8PPaCqofPUz6o=
> +SIZE (SABnzbd-1.0.0-src.tar.gz) = 2973807
> Index: news/sabnzbd/pkg/PLIST
> ===
> RCS file: /cvs/ports/news/sabnzbd/pkg/PLIST,v
> retrieving revision 1.3
> diff -u -p -u -r1.3 PLIST
> --- news/sabnzbd/pkg/PLIST17 Apr 2015 11:43:09 - 1.3
> +++ news/sabnzbd/pkg/PLIST16 Mar 2016 01:14:34 -
> @@ -9,29 +9,32 @@ bin/sabnzbd
> @group
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/ABOUT.txt
> -lib/python${MODPY_VERSION}/site-packages/sabnzbd/CHANGELOG.txt
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/COPYRIGHT.txt
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/GPL2.txt
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/GPL3.txt
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/INSTALL.txt
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/ISSUES.txt
> +lib/python${MODPY_VERSION}/site-packages/sabnzbd/LICENSE.txt
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/PKG-INFO
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/README.txt
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/SABHelper.py
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/SABHelper.pyc
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/SABnzbd.py
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/SABnzbd.pyc
> -lib/python${MODPY_VERSION}/site-packages/sabnzbd/Sample-PostProc.cmd
> -lib/python${MODPY_VERSION}/site-packages/sabnzbd/Sample-PostProc.sh
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/LICENSE.txt
> +lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/Patch-for-CP-3.8.0.diff
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/VERSION.txt
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/__init__.py
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/__init__.pyc
> -lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpcgifs.py
> -lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpcgifs.pyc
> +lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/__main__.py
> +lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/__main__.pyc
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpchecker.py
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpchecker.pyc
> +lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpcompat.py
> +lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpcompat.pyc
> +lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpcompat_subprocess.py
> +lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpcompat_subprocess.pyc
> lib/python${MODPY_VERSION}/site-packages/sabnzbd/cherrypy/_cpconfig.py
>
Re: UPDATE: lang/go 1.6
On Sun, Apr 03, 2016 at 06:56:13AM +0200, Dmitrij D. Czarkoff wrote: > Dmitrij D. Czarkoff said: > > Dmitrij D. Czarkoff said: > > > Juan Francisco Cantero Hurtado said: > > > > I just ran "make test" on amd64, so any additional tests are welcome. > > > > > > > > OK? > > > > > > Corresponding update to devel/go-tools. > > > > In previous versions go-tools did not include present and html2article > > tools. This happened because both tools had dependencies on golang > > extra packages from golang.org/x/net which were not available in ports. > > For the sake of completeness I've ported golang.org/x/net and its > > dependencies golang.org/x/crypto and golang.org/x/text. > > > > As golang.org/x/net/websocket (net/go-websocket) is a part of > > golang.org/x/net package set, I suggest to remove it in favor of the > > whole package set. > > > > I have also updated net/websocketd, the only port depending on > > net/go-websocket. > > > > OKs? > > Here is the whole go update as a single huge diff including lang/go, > devel/go-tools, three new go ports, websocketd update and net/websocketd > removal. The changes to juanfra@'s lang/go diff boil down to simplified > install stage - I copy over everything and then remove bootstrap. > > I considered removing tests, but upstream says that go implementation > should serve a reference for good practices in go development, so these > tests may serve a reference implementation purposes. > > OK? Sorry for the delay. - Use "@comment" for the bootstrap lines in PLIST - I would prefer to keep the old behavior in do-install. INSTALL_* will use the correct permissions for every type of file/dir. With those changes, OK juanfra@ to everything. Please wait until the kspillner@ OK for the removal and the jsing@ OK for the go update. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: NEW: devel/stagit
On Tue, Apr 26, 2016 at 01:59:34AM +0200, Jeremie Courreges-Anglas wrote:
> Juan Francisco Cantero Hurtado <i...@juanfra.info> writes:
>
> > On Sat, Apr 23, 2016 at 01:40:15PM +0200, Michael wrote:
> >> > In patch-Makefile, don't remove the variables "COMPATSRC =" and
> >> > "COMPATOBJ =". You deleted "${COMPATSRC}" and "${COMPATOBJ}", so that
> >> > change is not needed. I prefer to keep the patches as small as possible.
> >> >
> >> > In patch-stagit_c and patch-stagit-index_c, add an "#ifdef __OpenBSD__"
> >> > instead of delete the include. Send both patches to upstream.
> >> >
> >> > In the Makefile:
> >> > - Add an space before of each "="
> >> > - Remove "V" and add the version number to "DISTNAME"
> >>
> >> Thanks for the input. Attached the fixed port.
> >> Again, tested on latest amd64 snapshot.
> >>
> >> Any other comments?
> >
> > Thanks. I moved CATEGORIES to www and added git2 to WANTLIB.
> >
> > I need an additional OK to commit the port. Anyone?
>
> I don't find pkg/DESCR very helpful, maybe something like the following?
>
> stagit generates static HTML pages for a git repository, making it a
> light alternative for gitweb or cgit.
>
> Also, the #ifdef __OpenBSD__ could be dropped, they don't serve any
> purpose.
>
> With these concerns addressed, ok jca@
I added your suggestion to DESCR and moved the #ifndef to compat.h. He
could send the patch directly to upstream.
OK?
--
Juan Francisco Cantero Hurtado http://juanfra.info
stagit.tgz
Description: GNU Unix tar archive
Re: [lang/go] missing segments
On Thu, Apr 21, 2016 at 12:20:17AM +0100, Edd Barrett wrote:
> On Thu, Jul 23, 2015 at 04:05:21PM +0200, Fritjof Bornebusch wrote:
> > Hi ports@,
> >
> > while working on a port that uses lang/go it looks like there are some
> > segments missing.
> > The install(1) command says the following:
> >
> > BFD: /fake-amd64/usr/local/bin/st827dDR: warning: allocated section
> > `.gosymtab' not in segment
> > BFD: /fake-amd64/usr/local/bin/st827dDR: warning: allocated section
> > `.gnu.version_r' not in segment
>
> A few of us have started seeing messages like this. I only started
> seeing these messages when I upgraded from go-1.5.3 to 1.5.4.
>
> E.g. 'make fake' in net/syncthing from openbsd-wip:
>
> ---8<---
> ===> Faking installation for syncthing-0.12.22
> install -d -m 755 /usr/ports/pobj/syncthing-0.12.22/fake-amd64
> /usr/ports/pobj/syncthing-0.12.22/bin/install -c -s -m 755
> /usr/ports/pobj/syncthing-0.12.22/go/src/github.com/syncthing/syncthing/bin/syncthing
> /usr/ports/pobj/syncthing-0.12.22/fake-amd64/usr/local/bin/
> BFD: /usr/ports/pobj/syncthing-0.12.22/fake-amd64/usr/local/bin//stoBJG4T:
> warning: allocated section `.gosymtab' not in segment
> BFD: /usr/ports/pobj/syncthing-0.12.22/fake-amd64/usr/local/bin//stoBJG4T:
> warning: allocated section `.gnu.version_r' not in segment
> /usr/ports/pobj/syncthing-0.12.22/bin/install -c -m 644
> /usr/ports/pobj/syncthing-0.12.22/go/src/github.com/syncthing/syncthing/man/*.{1,5,7}
> /usr/ports/pobj/syncthing-0.12.22/fake-amd64/usr/local/man/
> --->8---
>
> I also noticed similar stuff when building go itself.
Can you try this patch?
diff --git lang/go/go.port.mk lang/go/go.port.mk
index 2fd3db0..92f24af 100644
--- lang/go/go.port.mk
+++ lang/go/go.port.mk
@@ -33,6 +33,9 @@ TEST_TARGET ?=${ALL_TARGET}
SEPARATE_BUILD ?= Yes
WRKSRC ?= ${MODGO_WORKSPACE}/src/${ALL_TARGET}
+# We never should use the standard "strip" command against go binaries
+INSTALL_STRIP=
+
MODGO_SETUP_WORKSPACE =mkdir -p ${WRKSRC:H}; mv ${MODGO_SUBDIR}
${WRKSRC};
CATEGORIES += lang/go
Re: NEW: htop 2.0.0
On Tue, Apr 26, 2016 at 11:28:52PM +0200, Jeremie Courreges-Anglas wrote: > Amit Kulkarni <amitk...@gmail.com> writes: > > > This fell through the cracks. Can somebody please import it now that ports > > is unlocked? > > Importing it now would perhaps get more bug reports, but we already know > that there were unsolved issues: > > >> > I've seeing a bunch of double-free and use-after-free in htop. Please, > >> > run your tests with "MALLOC_OPTIONS=CFGJU htop" and fix the code > >> > yourself in the upstream github repo if you can. I've attached an updated port. Now it uses the "debug" target by default, so you can get a backtrace with the symbols included to send a better bug report to upstream. -- Juan Francisco Cantero Hurtado http://juanfra.info htop.tgz Description: GNU Unix tar archive
macppc users: What ports are failing at runtime?
This email is only for the macppc users using -current or 5.9. Can you tell me what ports are failing at runtime? Can you reproduce the bug or it's random? Any additional info is welcome (but don't send me the dmesg :P ). I would like give a try to the problematic ports and hopefully to find a workaround for some of them. -- Juan Francisco Cantero Hurtado http://juanfra.info
