CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/12/03 03:11:07 Modified files: graphics/colord: Makefile distinfo graphics/colord/patches: patch-configure patch-etc_colord_conf_in patch-src_Makefile_in patch-src_cd-main_c patch-src_cd-profile-store_c patch-src_cd-profile_c graphics/colord/pkg: PLIST Log message: Update to colord-0.1.25.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pas...@cvs.openbsd.org 2012/12/03 03:32:48 Added files: x11/kde/office3/patches: patch-filters_kword_msword_conversion_cpp patch-filters_kword_msword_document_cpp patch-filters_kword_msword_tablehandler_cpp patch-filters_kword_msword_texthandler_cpp Log message: Adapt to wv2 changes; sorry for the breakage. same diff from brad@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/12/03 04:17:04 Modified files: mail/cyrus-imapd: Makefile distinfo mail/cyrus-imapd/patches: patch-configure patch-lib_imapoptions patch-man_imapd_conf_5 Added files: mail/cyrus-imapd/pkg: DESCR PLIST README Removed files: mail/cyrus-imapd/pkg: DESCR-main DESCR-perl PLIST-main PLIST-perl README-main Log message: Update to cyrus-imapd-2.4.17. Merge both subpackages into one -- it made sense when the port was not SHARED_ONLY but it's been for a while now. Use /nonexistent for the _cyrus user homedir.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/12/03 04:17:23 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: 'cyrus-imapd-perl' = 'cyrus-imapd'
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/12/03 06:08:08 Modified files: www/py-httplib2: Makefile www/py-httplib2/pkg: DESCR Log message: minor style nit
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/12/03 07:12:34 Modified files: net/ocsync : Makefile distinfo Log message: Bugfix update to ocsync-0.60.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/12/03 07:48:51 Modified files: japanese/mecab : Makefile Log message: mark broken on mips64 for the same reason it's broken on hppa (lack of atomic ops)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/12/03 08:34:42 Modified files: print/cups-pk-helper: Makefile Log message: add HOMEPAGE ok aja@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/12/03 08:48:56 Modified files: net/gssdp : Makefile Log message: add a HOMEPAGE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/12/03 08:52:12 Modified files: print/cups-pk-helper: Makefile distinfo Removed files: print/cups-pk-helper/patches: patch-src_cups_c Log message: Minor update to cups-pk-helper-0.2.4.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/12/03 08:59:30 Modified files: graphics/libungif: Makefile Log message: add license
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2012/12/03 09:21:25 Modified files: www/mollify: Makefile distinfo www/mollify/pkg: PLIST Log message: update to mollify 1.8.9.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/12/03 10:15:11 Modified files: x11/gnome/shell: Makefile Log message: Drop useless RUN_DEPENDS.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2012/12/03 13:08:46 Modified files: devel/coccinelle: Makefile Log message: Bump revision after ocaml update. ok from anil and @jasper
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2012/12/03 14:26:50 Modified files: editors/nvi-m17n: Makefile Added files: editors/nvi-m17n/patches: patch-build_configure_in patch-ex_ex_script_c Removed files: editors/nvi-m17n/patches: patch-build_configure Log message: use openpty(); ex_script.c part from millert@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2012/12/03 14:44:04 Modified files: editors/nvi-m17n: Makefile Log message: fix wantlib
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2012/12/03 15:30:26 Modified files: converters/wv2 : Makefile x11/kde/office3: Makefile Log message: Further tweaks for Pacal's sloppy wv2 update. ok kili@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2012/12/03 16:10:37 Modified files: www/squid : Makefile Log message: Don't allow autoconf to pick up et/com_err.h from e2fsprogs. dpb build failure reported by naddy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2012/12/03 23:30:20 Modified files: lang/ghc : Makefile Log message: Fix license comment: the package now also contains a (patched) libgmp, which is LGPLv3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2012/12/03 23:53:06 Modified files: databases/ocaml-sqlite3: Makefile distinfo Log message: update to new upstream version. ok by @avsm and @jasper
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2012/12/03 23:54:25 Modified files: devel/cil : Makefile Log message: update HOMEPAGE ok by @jasper and @avsm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2012/12/03 23:55:30 Modified files: devel/ocaml-calendar: Makefile Log message: update HOMEPAGE ok by @avsm and @jasper
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2012/12/03 23:56:39 Modified files: devel/ocaml-lambda-term: Makefile distinfo Log message: update to version 1.3 ok by @avsm, @jasper
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2012/12/03 23:57:39 Modified files: devel/ocaml-lwt: Makefile distinfo Log message: update to version 2.4.2 ok by @avsm, @jasper
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2012/12/04 00:01:07 Modified files: lang/ocamlduce : Makefile distinfo Log message: - update to version 3.12.1 - make use of bsd.port.arch.mk properties - update MASTER_SITES but still doesn't work with the current ocaml. ok by @avsm, @jasper
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: chr...@cvs.openbsd.org 2012/12/04 00:02:08 Modified files: textproc/ocaml-xmlm: Makefile distinfo textproc/ocaml-xmlm/pkg: PFRAG.native Added files: textproc/ocaml-xmlm/pkg: PFRAG.dynlink-native Log message: update to version 1.1.1 ok by @avsm, @jasper
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/12/04 00:10:53 Modified files: devel/libgee06 : Makefile distinfo Log message: Bugfix update to libgee06-0.6.7.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/12/04 00:14:34 Modified files: devel/libgee : Makefile distinfo Removed files: devel/libgee/patches: patch-gee_Makefile_in Log message: Bugfix update to libgee-0.8.3.
Re: enable graphics context in x11/wxWidgets
On Mon, Dec 3, 2012 at 12:29 AM, Edd Barrett vex...@gmail.com wrote:
Hi,
It turns out a load of the fs-uae launcher does not render properly due
to our wxWidgets port not having graphics context support. The following
diff enables it.
If you wish to test this with fs-use then rebuild py-wxWidgets too.
OK?
ok for me.
Index: Makefile
===
RCS file: /cvs/ports/x11/wxWidgets/Makefile,v
retrieving revision 1.43
diff -u -p -u -r1.43 Makefile
--- Makefile6 Nov 2012 09:37:14 - 1.43
+++ Makefile2 Dec 2012 23:20:15 -
@@ -9,7 +9,7 @@ V = 2.8.12
DISTNAME = wxWidgets-${V}
PKGNAME-main = wxWidgets-gtk2-${V}
PKGNAME-media =wxWidgets-media-${V}
-REVISION-main =7
+REVISION-main =8
REVISION-media =3
CATEGORIES = x11
MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=wxwindows/}
@@ -50,8 +50,8 @@ WANTLIB += GL SM X11 Xcomposite Xcursor
WANTLIB += Xi Xinerama Xrandr Xrender Xxf86vm atk-1.0 expat
WANTLIB += fontconfig freetype gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0
WANTLIB += glib-2.0 gobject-2.0 gthread-2.0 gtk-x11-2.0
-WANTLIB += jpeg m pango-1.0 pangoft2-1.0 pixman-1 png pthread-stubs
-WANTLIB += stdc++ tiff xcb xcb-render xcb-shm z
+WANTLIB += jpeg m pango-1.0 pangoft2-1.0 pixman-1 png pthread
+WANTLIB += pthread-stubs stdc++ tiff xcb xcb-render xcb-shm z
MODULES= devel/gettext
@@ -90,7 +90,8 @@ CONFIGURE_ARGS =--disable-backtrace \
--with-odbc \
--with-opengl \
--with-sdl \
- --without-gnomeprint
+ --without-gnomeprint \
+ --enable-graphics_ctx
CONFIGURE_ENV =CPPFLAGS=-I${LOCALBASE}/include
-I${LOCALBASE}/include/libpng -I${X11BASE}/include \
LDFLAGS=-L${LOCALBASE}/lib -L${X11BASE}/lib \
ac_cv_lib_esd_esd_close=no
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: enable graphics context in x11/wxWidgets
On 2012/12/02 23:29, Edd Barrett wrote: Hi, It turns out a load of the fs-uae launcher does not render properly due to our wxWidgets port not having graphics context support. The following diff enables it. Did you check at least a sample of other programs which use wxWidgets to make sure that they still work OK? This adds a dependency on libpthread, remember that this is special because it *must* be linked to binaries as it overrides weak symbols in libc (I think this is the #1 general problem affecting the ports tree at the moment), it cannot be pulled in by inter-library dependencies.
Re: UPDATE: Spectrwm-2.1.1
Someone? :) - Forwarded message from Gonzalo L. R. gonz...@x61.com.ar - From: Gonzalo L. R. gonz...@x61.com.ar To: Ports Mailing List ports@openbsd.org Date: Wed, 28 Nov 2012 11:43:19 -0300 Subject: UPDATE: Spectrwm-2.1.1 Hi, Update for Spectrwm to 2.1.1: * Avoid a free on an uninitialized variable by setting optval to NULL. * Fix fparseln flags to remove escape characters in the result. * Fix issue where rapid window crossing events might get ignored. * Validate bound spawn programs after conf is loaded. * Fix move/resize to bail if the window gets destroyed. * Fix bar clock not getting updated during periods of inactivity. Ok? Comments? Chers. -- Sending from my VCR... Index: Makefile === RCS file: /cvs/ports/x11/spectrwm/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- Makefile5 Nov 2012 12:12:36 - 1.5 +++ Makefile28 Nov 2012 14:41:46 - @@ -4,7 +4,7 @@ COMMENT=small tiling window manager SHARED_LIBS= swmhack 1.0 -DISTNAME= spectrwm-2.1.0 +DISTNAME= spectrwm-2.1.1 EXTRACT_SUFX= .tgz CATEGORIES=x11 Index: distinfo === RCS file: /cvs/ports/x11/spectrwm/distinfo,v retrieving revision 1.5 diff -u -p -r1.5 distinfo --- distinfo5 Nov 2012 12:12:36 - 1.5 +++ distinfo28 Nov 2012 14:41:46 - @@ -1,2 +1,2 @@ -SHA256 (spectrwm-2.1.0.tgz) = G6smd9UWrHLgW47wVjdbIfCF9PVjuPVo+cGM0q1+xAU= -SIZE (spectrwm-2.1.0.tgz) = 106087 +SHA256 (spectrwm-2.1.1.tgz) = Q7EZPyGXS5dJOuYgNhvhuQV1HM6VgPwmZT/Y6m1wcSE= +SIZE (spectrwm-2.1.1.tgz) = 106471 Index: patches/patch-spectrwm_c === RCS file: /cvs/ports/x11/spectrwm/patches/patch-spectrwm_c,v retrieving revision 1.3 diff -u -p -r1.3 patch-spectrwm_c --- patches/patch-spectrwm_c5 Sep 2012 20:33:43 - 1.3 +++ patches/patch-spectrwm_c28 Nov 2012 14:41:46 - @@ -1,7 +1,7 @@ $OpenBSD: patch-spectrwm_c,v 1.3 2012/09/05 20:33:43 gonzalo Exp $ spectrwm.c.origMon Aug 27 13:13:11 2012 -+++ spectrwm.c Wed Sep 5 08:56:28 2012 -@@ -260,7 +260,7 @@ u_int32_t swm_debug = 0 +--- spectrwm.c.origWed Nov 28 11:02:13 2012 spectrwm.c Wed Nov 28 11:36:23 2012 +@@ -261,7 +261,7 @@ u_int32_t swm_debug = 0 #define SWM_CONF_KEYMAPPING (1) #ifndef SWM_LIB - End forwarded message - -- Sending from my VCR...
Re: enable graphics context in x11/wxWidgets
Not yet, but I'll do some testing soon. Good point. On 3 Dec 2012 09:57, Stuart Henderson s...@spacehopper.org wrote: On 2012/12/02 23:29, Edd Barrett wrote: Hi, It turns out a load of the fs-uae launcher does not render properly due to our wxWidgets port not having graphics context support. The following diff enables it. Did you check at least a sample of other programs which use wxWidgets to make sure that they still work OK? This adds a dependency on libpthread, remember that this is special because it *must* be linked to binaries as it overrides weak symbols in libc (I think this is the #1 general problem affecting the ports tree at the moment), it cannot be pulled in by inter-library dependencies.
Enable cabal test-suites for hs-ports by default?
Hi,
I'd like to add --enable-tests by default in ghc.port.mk, unless a
hs-ports has set NO_REGRESS=Yes. However, this will have negative
impact on build times. Not much yet (see below), but as time goes
by, more and more hs-ports may include test-suites, so I better ask
before I just do such a change (proposed diff at the end of this
mail).
We currently have a total of 28 hs-ports which use the test-suite
feature of Cabal. One problem is that one *has* to configure those
ports with --enable-tests or a make regress will *always* fail
(noticed by sthen@ the other day while reviewing the new devel/hs-async
port). The next problem is that --enable-tests causes the test-suites
to be compiled and link during the build stage, not during the
regress stage. So, setting --enable-tests by default in ghc.port.mk
obviously will have an impact at the build time, even if you're not
going to make regress at all.
From those 28 ports, only the 9 ports listed below are buildable
with --enable-tests and without NO_REGRESS=Yes. Building them with
--enable-tests set in ghc.port.mk takes those times (measuring mere
build time, not extract/patch/configure):
1st run: 147.87 real 117.49 user17.80 sys
2nd run: 142.19 real 117.69 user17.72 sys
And building them without --enable-tests set:
1st run: 99.50 real83.72 user11.38 sys
2nd run: 101.19 real85.14 user11.30 sys
devel/hs-aeson, devel/hs-async, devel/hs-base64-bytestring,
devel/hs-concurrent-extra, devel/hs-lifted-base, devel/hs-network,
devel/hs-network-conduit, devel/hs-split, devel/hs-unordered-containers
Most of the remaining ports are failing during configure time,
because --enable-regress causes them to require some dependencies
we don't yet have in the ports tree. For now, they'll just get
NO_REGRESS=Yes:
archivers/hs-zlib-bindings, devel/hs-blaze-builder-conduit,
devel/hs-blaze-textual, devel/hs-conduit, devel/hs-hashable,
devel/hs-monad-par, devel/hs-simple-sendfile, lang/feldspar/language,
lang/hs-syntactic, net/hs-HTTP, security/hs-mwc-random, security/hs-skein,
textproc/hs-blaze-html, textproc/hs-blaze-markup, www/hs-clientsession,
www/hs-http-types, www/hs-warp
Two ports fail during build and need NO_REGRESS=Yes, too:
devel/hs-text, textproc/hs-attoparsec
Should this go in?
Ciao,
Kili
here's the diff that would go in:
Index: lang/ghc/ghc.port.mk
===
RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.26
diff -u -p -r1.26 ghc.port.mk
--- lang/ghc/ghc.port.mk8 Nov 2012 22:21:45 - 1.26
+++ lang/ghc/ghc.port.mk3 Dec 2012 21:26:03 -
@@ -57,6 +57,10 @@ MODGHC_SETUP_CONF_ARGS +=--docdir=\$$da
MODGHC_SETUP_CONF_ARGS += --libsubdir=ghc/\$$pkgid
. endif
+. if !${NO_REGRESS:L:Myes}
+MODGHC_SETUP_CONF_ARGS += --enable-tests
+. endif
+
. if ${MODGHC_BUILD:L:Mhaddock}
BUILD_DEPENDS += devel/haddock \
lang/ghc,-doc
Index: archivers/hs-zlib-bindings/Makefile
===
RCS file: /cvs/ports/archivers/hs-zlib-bindings/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- archivers/hs-zlib-bindings/Makefile 28 Oct 2012 23:24:28 - 1.7
+++ archivers/hs-zlib-bindings/Makefile 3 Dec 2012 21:26:03 -
@@ -19,4 +19,7 @@ MODGHC_BUILD =cabal hackage haddock re
RUN_DEPENDS = archivers/hs-zlib=0.5.2.0,0.6
BUILD_DEPENDS =${RUN_DEPENDS}
+# Missing dependencies (hs-hspec).
+NO_REGRESS = Yes
+
.include bsd.port.mk
Index: devel/hs-async/Makefile
===
RCS file: /cvs/ports/devel/hs-async/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- devel/hs-async/Makefile 2 Dec 2012 20:10:22 - 1.1.1.1
+++ devel/hs-async/Makefile 3 Dec 2012 21:26:03 -
@@ -20,8 +20,4 @@ MODGHC_BUILD =cabal hackage haddock re
BUILD_DEPENDS =${RUN_DEPENDS}
RUN_DEPENDS = devel/hs-stm=2.2,2.5
-# Needs --enable-test, which will probably set by ghc.port.mk soon
-# (when I have some numbers about build times).
-NO_REGRESS = Yes
-
.include bsd.port.mk
Index: devel/hs-blaze-builder-conduit/Makefile
===
RCS file: /cvs/ports/devel/hs-blaze-builder-conduit/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- devel/hs-blaze-builder-conduit/Makefile 28 Oct 2012 23:26:38 -
1.2
+++ devel/hs-blaze-builder-conduit/Makefile 3 Dec 2012 21:26:03 -
@@ -25,4 +25,7 @@ RUN_DEPENDS = devel/hs-blaze-builder=0
devel/hs-text=0.11 \
devel/hs-transformers=0.2.2,0.4
+# Missing dependencies (hs-hspec).
+NO_REGRESS = Yes
+
.include bsd.port.mk
Remove net/slirp?
Does anybody still use net/slirp? It will need a PTY allocation fix, but I noticed that the code is from 1996. FreeBSD has a newer version, from 2004, but marks it # serious LP64 issues ONLY_FOR_ARCHS= i386 So does it even work? I don't want to remove something that still works, but neither do I want to preserve a nonfunctional port. This looks pretty historical: --- SLiRP is a (C)SLIP/PPP emulator which allows users with normal shell accounts act as if they had a (C)SLIP/PPP account. This allows users to use Netscape/Mosaic, ftp, telnet, etc. from their home machine, as if they had a real (C)SLIP/PPP connection (with limitations). --- -- Christian naddy Weisgerber na...@mips.inka.de
Re: Remove net/slirp?
On 2012/12/03 21:35, Christian Weisgerber wrote: Does anybody still use net/slirp? It will need a PTY allocation fix, but I noticed that the code is from 1996. FreeBSD has a newer version, from 2004, but marks it # serious LP64 issues ONLY_FOR_ARCHS= i386 So does it even work? This code ended up in qemu where it does now work on LP64 so it's probably rescuable should somebody feel the need. I don't want to remove something that still works, but neither do I want to preserve a nonfunctional port. This looks pretty historical: Yes, it is mostly meant for people who have dialup modem access to a UNIX server but no SLIP/PPP. A somewhat uncommon situation these days. I don't object to removing it, if sometime after that someone wants to fix LP64 issues and PTY allocation I wouldn't object to bringing it back either. :) --- SLiRP is a (C)SLIP/PPP emulator which allows users with normal shell accounts act as if they had a (C)SLIP/PPP account. This allows users to use Netscape/Mosaic, ftp, telnet, etc. from their home machine, as if they had a real (C)SLIP/PPP connection (with limitations). ---
Re: UPDATE: audio/deadbeef
On Fri, Nov 30, 2012 at 11:28:12AM +, Stuart Henderson wrote: On 2012/11/30 05:47, Brad Smith wrote: - Original message - On 2012/11/28 23:14, Brad Smith wrote: On Thu, Nov 29, 2012 at 12:14:33AM +0600, Alexandr Shadchin wrote: On Mon, Nov 19, 2012 at 11:33:09PM +0600, Alexandr Shadchin wrote: Hi, This update package deadbeef to the latest release 0.5.6. Tested on amd64. Split package on -main, -gtk2 and -gtk3. Please make review this change. Comments ? OK ? Fix BUILD_DEPENDS. The gtk2 sub-package should have a @pkgpath marker so upgrading from the older package to the new main + gtk2 package set will have the expected result. good luck getting that to work ;) Am I crazy for expecting that to actually work? I was fairly certain it would but maybe it is another thing with the pkg tools that doesn't work. The gtk2 package is named deadbeef-gtk2-0.5.6, so it isn't considered as a replacement for deadbeef-0.5.5, so pkg_add -u doesn't consult the deadbeef-gtk2 package at all to even see the @pkgpath line. One thing that could be done would be to name the -main package something like deadbeef-core-0.5.6, name the -gtk2 package deadbeef-0.5.6, remove @pkgpath in PLIST-main, add @pkgpath in PLIST-gtk2, and add @conflicts as necessary. Ewww. That's pretty awful. More than this would need Quirks.pm to be able to do version comparisons rather than the fast hash lookups, but doing those checks for every updated package will slow down pkg_add -u .. Or better yet get rid of the nonsense of splitting up the port and not having to worry about this stuff at all. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
