Re: NEW: devel/stagit
On Tue, Apr 26, 2016 at 02:33:26AM +0200, Juan Francisco Cantero Hurtado wrote: I added your suggestion to DESCR and moved the #ifndef to compat.h. He could send the patch directly to upstream. Thanks for the effort so far. I have contact with one of the upstream devs and it was indicated to me that a patch with #ifdef is not going to happen. The new DESCR looks good to me. Regards, Michael
Re: [NEW] www/pnp4nagios
On Fri, April 1, 2016 12:29, Kirill Bychkov wrote: > On Mon, March 21, 2016 22:34, Kirill Bychkov wrote: >> On Mon, March 21, 2016 11:53, Vadim Zhukov wrote: >>> 2016-03-20 10:35 GMT+03:00 Kirill Bychkov : On Fri, March 11, 2016 12:16, Kirill Bychkov wrote: > On Thu, March 10, 2016 23:22, Vadim Zhukov wrote: >> 2016-03-09 17:08 GMT+03:00 Kirill Bychkov : >>> On Thu, March 3, 2016 16:57, Kirill Bychkov wrote: Him guys! This is a port of PNP4Nagios, an addon for Nafios and Oconga for analyzing performance data and storing it in RRD. Current port is partially based on an old one from henning@ [1] and tested for more than a month with Icinga 1.x processing data from about 400 hosts. It could be splitted to Nagios and Icinga 2.x flavors if there are some interest in them and one can test it with. [1] http://marc.info/?l=openbsd-ports&m=140803165912579&w=2 Comments? OKs? >>> Objections? :) > Hi, I still hope to get this in. pnp4nagios.tar.gz Description: application/gzip
Re: [NEW] net/profanity and net/libstrophe
On 2016/04/26 10:36, Stuart Henderson wrote: > What problem do you see with tests? They work for me as-is, even > if cmocka was not installed during 'make configure'. > > It's not a LIB_DEPENDS. Oh, it all becomes clear :)
Re: [NEW] net/profanity and net/libstrophe
What problem do you see with tests? They work for me as-is, even if cmocka was not installed during 'make configure'. It's not a LIB_DEPENDS.
Re: [NEW] www/pnp4nagios
2016-04-26 12:00 GMT+03:00 Kirill Bychkov : > On Fri, April 1, 2016 12:29, Kirill Bychkov wrote: >> On Mon, March 21, 2016 22:34, Kirill Bychkov wrote: >>> On Mon, March 21, 2016 11:53, Vadim Zhukov wrote: 2016-03-20 10:35 GMT+03:00 Kirill Bychkov : > On Fri, March 11, 2016 12:16, Kirill Bychkov wrote: >> On Thu, March 10, 2016 23:22, Vadim Zhukov wrote: >>> 2016-03-09 17:08 GMT+03:00 Kirill Bychkov : On Thu, March 3, 2016 16:57, Kirill Bychkov wrote: > Him guys! > This is a port of PNP4Nagios, an addon for Nafios and Oconga for > analyzing > performance data and storing it in RRD. > Current port is partially based on an old one from henning@ [1] and > tested > for more than a month with Icinga 1.x processing data from about 400 > hosts. > It could be splitted to Nagios and Icinga 2.x flavors if there are > some > interest in them and one can test it with. > > [1] http://marc.info/?l=openbsd-ports&m=140803165912579&w=2 > > Comments? OKs? Objections? :) > >> > Hi, > I still hope to get this in. I like it. okay zhuk@. -- WBR, Vadim Zhukov
NEW comms/wammu and friends
Hi, This is a ports for wammu and it's dependencies - gammu and py-gammu. I'm using wammu to backup contacts from my old Samsung phone. All ports are also available from openbsd-wip. Comments? OKs? wammu/pkg/DESCR: Wammu is a program to manage data in your cell phone such as contacts, calendar or messages. It is built on Gammu library, which provides abstraction layer to work with different cell phones from different vendors (including Nokia, Sony-Ericsson, Motorola, Samsung, Siemens, Huawei and others). gammu/pkg/DESCR: Gammu command line utility provides access to wide range of phone features, however support level differs from phone to phone and you might want to check Gammu Phone Database for user experiences with various phones. Generally following features are supported: * Call listing, initiating and handling * SMS retrieval, backup and sending * MMS retrieval * Phonebook listing, export and import (also from standard formats such as vCard) * Calendar and tasks listing, export and import (also from standard formats such as vCalendar or iCalendar) * Retrieval of phone and network information * Access to phone file system. py-gammu/pkg/DESCR: Python bindings which allow you to use (most) of Gammu functionality from Python language. wammu.tar.gz Description: application/gzip gammu.tar.gz Description: application/gzip py-gammu.tar.gz Description: application/gzip
Re: devel/scons fixes
On Thu, Apr 21, 2016 at 06:45:38PM +0200, Ingo Feinerer wrote: > Hi, > > I was working on a port which uses devel/scons. Following changes to > scons.port.mk were necessary which appear to fix general problems: > > - use the proper path separator ":" as otherwise all but the first path > are ignored > - ensure that MODSCONS_ENV is seen by MODSCONS_BIN > > Comments? If all the other ports that use scons.port.mk build fine with it, then yes please. Your fix makes totally sense. Landry
Mozilla's Firefox Stable now uses GTK3 by default
Mozilla configures building of Firefox Stable 46 for Gnu/Linux to use cairo-gtk3 toolkit by default. Does OpenBSD's port is going to use it soon by default? Does OpenBSD's port delay this change waiting for some bugs related to this change to be resolved by upstream developers?
Re: NEW: devel/stagit
Juan Francisco Cantero Hurtado writes:
> On Tue, Apr 26, 2016 at 01:59:34AM +0200, Jeremie Courreges-Anglas wrote:
>> Juan Francisco Cantero Hurtado 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.
I think we really should drop the #ifdef, for they are bad portability
practice. Also upstream confirmed that they won't go this way.
Remember that not only OpenBSD provides strlcpy/strlcat/reallocarray.
> OK?
GITINC and GITLIB used hardcoded /usr/local in config.mk, here's an
updated tarball to use LOCALBASE instead.
ok jca@ to import
stagit.tgz
Description: Binary data
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: new: sysutils/udfclient
Josh Grosse writes: > On Mon, Apr 25, 2016 at 07:49:50PM -0400, Josh Grosse wrote: >> > - one typo in README >> >> Only one? I'd been finding them each time I opened the file. I must >> have found about 30. And plenty of misinformation, too. I'd like to >> clarify one section, which I'll add here: > > It would help if I would remember to include things. :) > I've added disklabels to the discussion of the first 0x8000 bytes. Well here's an updated tarball then, still looking for other reviews / oks. udfclient.tgz Description: Binary data -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Mozilla's Firefox Stable now uses GTK3 by default
On Tue, Apr 26, 2016 at 02:04:33PM +0200, Lampshade wrote: > Mozilla configures building of Firefox Stable 46 for Gnu/Linux > to use cairo-gtk3 toolkit by default. > Does OpenBSD's port is going to use it soon by default? That's the plan. > Does OpenBSD's port delay this change waiting for some bugs > related to this change to be resolved by upstream developers? There's at least https://bugzilla.mozilla.org/show_bug.cgi?id=1230955 Landry
Re: [new port] graphics/glfw
Gregor Best writes: > On Thu, Feb 11, 2016 at 06:44:29PM +0100, Gregor Best wrote: >> And because I'm a really smart cookie, of course I forgot two patches. >> Attached is an updated port that actually works. >> [...] > > Ping? Looks sane, a quick look didn't reveal anything that could use it out there, but if it's useful to you it may be useful to others. Updated tarball, with patches refreshed with ''make update-patches''. portcheck detacted missing $OpenBSD$ markers. Can I get another review / ok to import? glfw.tgz Description: Binary data -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Update: netpbm 10.74.02
There is a major new release in the "super stable" release series
(which is the only one with tarballs) that would take us from 10.35
to 10.47. While a lot newer than 10.35, it is still years out of
date. In particular, it still hasn't caught up with libpng >1.4.
After manually redoing the 900-line patch-converter_other_pngtopnm_c,
I figured that spending this much effort on code that is already way
obsolete doesn't make sense.
We need to bite the bullet. The diff below brings us up to 10.74
from the "advanced" release series, i.e., the very latest releases.
Unfortunately, releases there are only marked in Subversion, so we
have to create our own distfiles when we update the port. I have
included a convenience target in Makefile for this purpose.
The new code now also comes with a regression test suite. I started
patching out the GNU-isms but eventually decided it wasn't worth
the effort and added the dependencies.
Finally, the port now uses srand_deterministic(). There are a lot
of tools that take seed values on the command line, which was broken.
Comments? OK?
PS: The Makefile patches are mostly about our idea of how to build
shared and static libraries. If we followed upstream and created
the static lib (which nothing uses...) from the -fPIC object files,
this would be much simpler. On the other hand, these patches aren't
particularly intrusive or hard to maintaun. *shrug*
Index: Makefile
===
RCS file: /cvs/ports/graphics/netpbm/Makefile,v
retrieving revision 1.74
diff -u -p -r1.74 Makefile
--- Makefile9 Mar 2016 18:22:52 - 1.74
+++ Makefile26 Apr 2016 12:30:53 -
@@ -1,44 +1,74 @@
# $OpenBSD: Makefile,v 1.74 2016/03/09 18:22:52 naddy Exp $
-COMMENT= toolkit for converting images between different formats
+COMMENT= toolkit for manipulation and conversion of graphic images
-DISTNAME= netpbm-10.35.97
-SHARED_LIBS= netpbm 2.0
+DISTNAME= netpbm-10.74.02
+SHARED_LIBS= netpbm 3.0
CATEGORIES=graphics
HOMEPAGE= http://netpbm.sourceforge.net/
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB += X11 Xau Xdmcp c jasper jbig jpeg m png pthread pthread-stubs
-WANTLIB += tiff xcb xml2 z
+WANTLIB= X11 c jasper jbig jpeg m png tiff xml2 z
-MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=netpbm/}
-EXTRACT_SUFX= .tgz
+MASTER_SITES= http://shell.uugrn.org/~naddy/
+EXTRACT_SUFX= .tar.xz
-MODULES= converters/libiconv
LIB_DEPENDS= graphics/tiff \
graphics/jpeg \
graphics/png \
- graphics/jbigkit>=2.0 \
+ graphics/jbigkit \
graphics/jasper \
textproc/libxml
USE_GMAKE= Yes
MAKE_FILE= GNUmakefile
-ALL_TARGET=
INSTALL_TARGET=install.bin install.lib install.data \
install.hdr install.staticlib
MAKE_FLAGS=CC="${CC}" \
LIBnetpbm_VERSION=${LIBnetpbm_VERSION}
-FAKE_FLAGS=PKGDIR="${WRKINST}${TRUEPREFIX}"
+# programs can take seed on command line
+MAKE_FLAGS+= CFLAGS_CONFIG="-Dsrand=srand_deterministic"
-pre-build:
- ${SUBST_CMD} ${WRKSRC}/pm_config.in.h
- cp ${FILESDIR}/Makefile.config.OpenBSD ${WRKSRC}/Makefile.config
-# Missing in some releases
- cd ${WRKSRC}; buildtools/stamp-date >lib/compile.h
+FAKE_FLAGS=pkgdir="${WRKINST}${TRUEPREFIX}"
-NO_TEST= Yes
+do-configure:
+ cp ${FILESDIR}/config.mk ${WRKSRC}
+
+TEST_DEPENDS= shells/bash sysutils/coreutils
+TEST_TARGET= check
+TEST_FLAGS=pkgdir="${WRKINST}${PREFIX}" \
+ resultdir="${WRKDIR}/tests" \
+ RGBDEF="${WRKINST}${PREFIX}/share/netpbm/rgb.txt"
+
+# cp -v, head -c, mv -T, seq
+pre-test:
+ @for i in cp head mv seq; do \
+ ln -s ${LOCALBASE}/bin/g$$i ${WRKDIR}/bin/$$i; \
+ done
+ @sed -i '1 s:^.*bin/bash:#!${LOCALBASE}/bin/bash:' \
+ ${WRKSRC}/test/Execute-Tests ${WRKSRC}/test/*.test
+
+# must run after fake
+test: fake
+
+# Get the latest release in a release series from Netpbm Subversion.
+# Requires devel/subversion.
+distfile:
+ @REPO=https://svn.code.sf.net/p/netpbm/code; \
+ SERIES=advanced; \
+ REV=`svn info $$REPO/$$SERIES/version.mk | \
+ sed -n 's/Last Changed Rev: //p'`; \
+ VERSION=`(svn cat -r$$REV $$REPO/$$SERIES/version.mk; \
+ echo 'all:'; \
+ echo ' @printf "%02d.%02d.%02d" \\'; \
+ echo ' $${NETPBM_MAJOR_RELEASE} \\'; \
+ echo ' $${NETPBM_MINOR_RELEASE} \\'; \
+ echo ' $${NETPBM_POINT_RELEASE}'; \
+ ) | make -f-`; \
+ svn export -r$$REV $$REPO/$$SERIES "netpbm-$$VERSION"; \
+ tar cf - "netpbm-$$VERSION" | xz >"netpbm-$$VERSION".tar.xz; \
+ rm -rf "netpbm-$$VERSION"
.include
Index: distinfo
===
RCS file: /cvs/ports/graphics/netpbm/distinfo,
Re: [update] graphics/p5-Image-ExifTool
patrick keshishian writes: > no frills update: 10.00 -> 10.10 > full change log: > http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-10.10/Changes Committed, thanks. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Update: netpbm 10.74.02
Christian Weisgerber writes:
> There is a major new release in the "super stable" release series
> (which is the only one with tarballs) that would take us from 10.35
> to 10.47. While a lot newer than 10.35, it is still years out of
> date. In particular, it still hasn't caught up with libpng >1.4.
> After manually redoing the 900-line patch-converter_other_pngtopnm_c,
> I figured that spending this much effort on code that is already way
> obsolete doesn't make sense.
>
> We need to bite the bullet. The diff below brings us up to 10.74
> from the "advanced" release series, i.e., the very latest releases.
> Unfortunately, releases there are only marked in Subversion, so we
> have to create our own distfiles when we update the port. I have
> included a convenience target in Makefile for this purpose.
>
> The new code now also comes with a regression test suite. I started
> patching out the GNU-isms but eventually decided it wasn't worth
> the effort and added the dependencies.
>
> Finally, the port now uses srand_deterministic(). There are a lot
> of tools that take seed values on the command line, which was broken.
>
> Comments? OK?
Looks fine to me, thanks for working on this.
The header location change means that a few fixes are needed in the
ports tree. Those declare a lib-depends on netpbm.
Index: converters/ppmtoTbmp/Makefile
===
RCS file: /cvs/ports/converters/ppmtoTbmp/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- converters/ppmtoTbmp/Makefile 28 Oct 2014 08:18:30 - 1.13
+++ converters/ppmtoTbmp/Makefile 26 Apr 2016 13:57:56 -
@@ -3,7 +3,7 @@
COMMENT= PPM to Pilot bitmap converter
DISTNAME= ppmtoTbmp-1.1
-REVISION= 2
+REVISION= 3
CATEGORIES=converters graphics
HOMEPAGE= http://www.isaac.cs.berkeley.edu/pilot/
@@ -15,7 +15,7 @@ WANTLIB= c m netpbm
MASTER_SITES= ${HOMEPAGE}
-MAKE_FLAGS=CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
+MAKE_FLAGS=CFLAGS="${CFLAGS} -I${LOCALBASE}/include
-I${LOCALBASE}/include/netpbm" \
LDLIBS="-L${LOCALBASE}/lib -lnetpbm -lm"
LIB_DEPENDS= graphics/netpbm
Index: graphics/vid/Makefile
===
RCS file: /cvs/ports/graphics/vid/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- graphics/vid/Makefile 10 Oct 2013 02:08:23 - 1.17
+++ graphics/vid/Makefile 26 Apr 2016 13:52:36 -
@@ -3,7 +3,7 @@
COMMENT= get images from USB cameras using the OV511(+) chipsets
DISTNAME= vid-1.0.1
-REVISION= 5
+REVISION= 6
CATEGORIES=graphics
HOMEPAGE= http://ovtvid-bsd.sourceforge.net/
Index: graphics/vid/patches/patch-README
===
RCS file: /cvs/ports/graphics/vid/patches/patch-README,v
retrieving revision 1.1
diff -u -p -r1.1 patch-README
--- graphics/vid/patches/patch-README 20 Jan 2003 18:54:14 - 1.1
+++ graphics/vid/patches/patch-README 26 Apr 2016 13:50:10 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-README,v 1.1 2003/01/20 18:54:14 sturm Exp $
README.origSun May 7 22:59:03 2000
-+++ README Sun Jan 19 11:41:56 2003
+--- README.origMon May 8 06:59:03 2000
README Tue Apr 26 15:49:36 2016
@@ -1,4 +1,5 @@
-NetBSD/FreeBSD Simple OV511 video capture program, version 1.0 (2000-04-26)
+FreeBSD/NetBSD/OpenBSD Simple OV511 video capture program
@@ -8,7 +8,7 @@ $OpenBSD: patch-README,v 1.1 2003/01/20
This is a simple image capture program for USB webcams based on the
OmniVision Technologies OV511 bridge chip attached to an OV7610 CCD
-@@ -61,3 +62,5 @@ http://members.home.com/housel/ for upda
+@@ -61,3 +62,5 @@ http://members.home.com/housel/ for updates.
-Peter S. Housel-
Index: graphics/vid/patches/patch-vid_c
===
RCS file: /cvs/ports/graphics/vid/patches/patch-vid_c,v
retrieving revision 1.3
diff -u -p -r1.3 patch-vid_c
--- graphics/vid/patches/patch-vid_c20 Jan 2003 18:54:14 - 1.3
+++ graphics/vid/patches/patch-vid_c26 Apr 2016 13:50:10 -
@@ -1,6 +1,15 @@
$OpenBSD: patch-vid_c,v 1.3 2003/01/20 18:54:14 sturm Exp $
--- vid.c.orig Mon May 8 06:59:03 2000
-+++ vid.c Mon Jan 20 17:56:47 2003
vid.c Tue Apr 26 15:50:06 2016
+@@ -37,7 +37,7 @@
+
+ #include
+
+-#include
++#include
+
+ #include "vid.h"
+
@@ -48,15 +48,15 @@ ov511_reg_read(int fd, int reg) {
struct usb_ctl_request ur;
unsigned char data[1024];
@@ -25,7 +34,7 @@ $OpenBSD: patch-vid_c,v 1.3 2003/01/20 1
if(ioctl(fd, USB_DO_REQUEST, &ur) < 0) {
return -1;
-@@ -72,15 +72,15 @@ ov511_reg_write(int fd, int reg, int val
+@@ -72,15 +72,15 @@ ov511_reg_write(int fd, int reg, int val) {
data[0] = val;
@@ -63,8 +72,8 @@ $OpenBSD: patch-vid_c,v 1.3
Re: UPDATE: devel/pylint 1.5.5
On Sun, 17 Apr 2016 17:41:31 +0500, Alexandr Shadchin wrote: > Hi, > > This diff updates pylint to the latest release. > Tested on amd64. > > * update for py-logilab-common to 1.2.0 > * new port py-astroid 1.4.5 (py-logilab-astng -> py-astroid) + quirks > * add python3 flavor for all > * take maintainer > > Comments ? OK ? > Just one nits, in devel/py-logilab-common can you move py-mxDateTime to a TEST_DEPENDS only? It's only present in test/unittest_date.py and even running without it (like when using python3) is fine as the tests are just skipped. With that ok danj@ the whole.
Re: [new port] graphics/glfw
On 2016/04/26 15:01, Jeremie Courreges-Anglas wrote: > Gregor Best writes: > > > On Thu, Feb 11, 2016 at 06:44:29PM +0100, Gregor Best wrote: > >> And because I'm a really smart cookie, of course I forgot two patches. > >> Attached is an updated port that actually works. > >> [...] > > > > Ping? > > Looks sane, a quick look didn't reveal anything that could use it out > there, but if it's useful to you it may be useful to others. > > Updated tarball, with patches refreshed with ''make update-patches''. > portcheck detacted missing $OpenBSD$ markers. > > Can I get another review / ok to import? The port is OK with me, but glfw appears in build logs, so some things might pick it up. lang/io has some code to look for GLFW but is looking for the header in GL/glfw.h so doesn't pick it up automatically. This means things shouldn't break by importing this, but might want a look sometime. (modules/FindGLFW.cmake) textproc/mupdf might be able to use it but shouldn't automaticaly pick anything up. devel/codeblocks may also do; trying it now.
Re: Update: netpbm 10.74.02
Jeremie Courreges-Anglas writes:
> Christian Weisgerber writes:
>
>> There is a major new release in the "super stable" release series
>> (which is the only one with tarballs) that would take us from 10.35
>> to 10.47. While a lot newer than 10.35, it is still years out of
>> date. In particular, it still hasn't caught up with libpng >1.4.
>> After manually redoing the 900-line patch-converter_other_pngtopnm_c,
>> I figured that spending this much effort on code that is already way
>> obsolete doesn't make sense.
>>
>> We need to bite the bullet. The diff below brings us up to 10.74
>> from the "advanced" release series, i.e., the very latest releases.
>> Unfortunately, releases there are only marked in Subversion, so we
>> have to create our own distfiles when we update the port. I have
>> included a convenience target in Makefile for this purpose.
>>
>> The new code now also comes with a regression test suite. I started
>> patching out the GNU-isms but eventually decided it wasn't worth
>> the effort and added the dependencies.
>>
>> Finally, the port now uses srand_deterministic(). There are a lot
>> of tools that take seed values on the command line, which was broken.
>>
>> Comments? OK?
>
> Looks fine to me, thanks for working on this.
>
> The header location change means that a few fixes are needed in the
> ports tree. Those declare a lib-depends on netpbm.
As naddy points out, no need for bumps.
Index: converters/ppmtoTbmp/Makefile
===
RCS file: /cvs/ports/converters/ppmtoTbmp/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- converters/ppmtoTbmp/Makefile 28 Oct 2014 08:18:30 - 1.13
+++ converters/ppmtoTbmp/Makefile 26 Apr 2016 14:37:56 -
@@ -15,7 +15,7 @@ WANTLIB= c m netpbm
MASTER_SITES= ${HOMEPAGE}
-MAKE_FLAGS=CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
+MAKE_FLAGS=CFLAGS="${CFLAGS} -I${LOCALBASE}/include
-I${LOCALBASE}/include/netpbm" \
LDLIBS="-L${LOCALBASE}/lib -lnetpbm -lm"
LIB_DEPENDS= graphics/netpbm
Index: graphics/vid/patches/patch-README
===
RCS file: /cvs/ports/graphics/vid/patches/patch-README,v
retrieving revision 1.1
diff -u -p -r1.1 patch-README
--- graphics/vid/patches/patch-README 20 Jan 2003 18:54:14 - 1.1
+++ graphics/vid/patches/patch-README 26 Apr 2016 13:50:10 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-README,v 1.1 2003/01/20 18:54:14 sturm Exp $
README.origSun May 7 22:59:03 2000
-+++ README Sun Jan 19 11:41:56 2003
+--- README.origMon May 8 06:59:03 2000
README Tue Apr 26 15:49:36 2016
@@ -1,4 +1,5 @@
-NetBSD/FreeBSD Simple OV511 video capture program, version 1.0 (2000-04-26)
+FreeBSD/NetBSD/OpenBSD Simple OV511 video capture program
@@ -8,7 +8,7 @@ $OpenBSD: patch-README,v 1.1 2003/01/20
This is a simple image capture program for USB webcams based on the
OmniVision Technologies OV511 bridge chip attached to an OV7610 CCD
-@@ -61,3 +62,5 @@ http://members.home.com/housel/ for upda
+@@ -61,3 +62,5 @@ http://members.home.com/housel/ for updates.
-Peter S. Housel-
Index: graphics/vid/patches/patch-vid_c
===
RCS file: /cvs/ports/graphics/vid/patches/patch-vid_c,v
retrieving revision 1.3
diff -u -p -r1.3 patch-vid_c
--- graphics/vid/patches/patch-vid_c20 Jan 2003 18:54:14 - 1.3
+++ graphics/vid/patches/patch-vid_c26 Apr 2016 13:50:10 -
@@ -1,6 +1,15 @@
$OpenBSD: patch-vid_c,v 1.3 2003/01/20 18:54:14 sturm Exp $
--- vid.c.orig Mon May 8 06:59:03 2000
-+++ vid.c Mon Jan 20 17:56:47 2003
vid.c Tue Apr 26 15:50:06 2016
+@@ -37,7 +37,7 @@
+
+ #include
+
+-#include
++#include
+
+ #include "vid.h"
+
@@ -48,15 +48,15 @@ ov511_reg_read(int fd, int reg) {
struct usb_ctl_request ur;
unsigned char data[1024];
@@ -25,7 +34,7 @@ $OpenBSD: patch-vid_c,v 1.3 2003/01/20 1
if(ioctl(fd, USB_DO_REQUEST, &ur) < 0) {
return -1;
-@@ -72,15 +72,15 @@ ov511_reg_write(int fd, int reg, int val
+@@ -72,15 +72,15 @@ ov511_reg_write(int fd, int reg, int val) {
data[0] = val;
@@ -63,8 +72,8 @@ $OpenBSD: patch-vid_c,v 1.3 2003/01/20 1
+ int isplus; /* bridge is OV511+ if true, else OV511 */
+ int is20;/* sensor is OV7620 if true, else OV7610 */
+ int bufsize; /* size of packet buffer */
-+
++
/* pnm_init(&argc, argv); *//* required for PNM programs? */
while(++argv, --argc) {
@@ -135,7 +144,7 @@ $OpenBSD: patch-vid_c,v 1.3 2003/01/20 1
/* reset the OV511 */
if(ov511_reg_write(fd, OV511_REG_RST, 0x7f) < 0)
-@@ -398,23 +412,56 @@ main(int argc, char *argv[]) {
+@@ -398,24 +412,57 @@ main(int argc, char *argv[]) {
if(ov511_reg_write(fd, OV511_REG_CE_EN, 0x0) < 0)
exit(1);
@
Re: [new port] graphics/glfw
Stuart Henderson writes: > On 2016/04/26 15:01, Jeremie Courreges-Anglas wrote: >> Gregor Best writes: >> >> > On Thu, Feb 11, 2016 at 06:44:29PM +0100, Gregor Best wrote: >> >> And because I'm a really smart cookie, of course I forgot two patches. >> >> Attached is an updated port that actually works. >> >> [...] >> > >> > Ping? >> >> Looks sane, a quick look didn't reveal anything that could use it out >> there, but if it's useful to you it may be useful to others. >> >> Updated tarball, with patches refreshed with ''make update-patches''. >> portcheck detacted missing $OpenBSD$ markers. >> >> Can I get another review / ok to import? > > The port is OK with me, but glfw appears in build logs, so some > things might pick it up. > > lang/io has some code to look for GLFW but is looking for the header > in GL/glfw.h so doesn't pick it up automatically. This means things > shouldn't break by importing this, but might want a look sometime. > (modules/FindGLFW.cmake) > > textproc/mupdf might be able to use it but shouldn't automaticaly > pick anything up. > > devel/codeblocks may also do; trying it now. Thanks for looking at this. Gregor, I just imported glfw. Cheers, -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [new port] graphics/glfw
On Tue, Apr 26, 2016 at 05:32:34PM +0200, Jeremie Courreges-Anglas wrote: > [...] > Gregor, I just imported glfw. > [...] Wonderful, thanks a lot, to both of you :) -- Gregor
NEW: net/ntopng
-- -- ntopng is a network traffic probe that shows network usage in a high level of detail. It provides a web-based UI allowing you to visualize traffic flows broken down by host, country, port, application (via deep packet inspection), AS number, etc. Flow information can also be dumped to ElasticSearch or MySQL/MariaDB. -- -- ok to import? this is a devel snapshot because the last release crashes when parsing json over http. ntopng.tgz Description: application/tar-gz
Re: NEW: net/ntopng
On 2016/04/26 18:42, Stuart Henderson wrote: > -- -- > ntopng is a network traffic probe that shows network usage in a high level > of detail. It provides a web-based UI allowing you to visualize traffic flows > broken down by host, country, port, application (via deep packet inspection), > AS number, etc. Flow information can also be dumped to ElasticSearch or > MySQL/MariaDB. > -- -- > > ok to import? > > this is a devel snapshot because the last release crashes when parsing > json over http. oops, here's a replacement distinfo, thanks jca: SHA256 (nDPI-dev-20160426.tar.gz) = PabbyIABK69280Cj406bIqwJizteujouVWaxNqemIhE= SHA256 (ntopng-2.3pre20160426.tar.gz) = V8CUmPJRJTofnllR4kMpkLUPr42w11ZYIdX4CpMcQ1Q= SIZE (nDPI-dev-20160426.tar.gz) = 6953268 SIZE (ntopng-2.3pre20160426.tar.gz) = 27653065 SHA256 (nDPI-dev-20160426.tar.gz) = PabbyIABK69280Cj406bIqwJizteujouVWaxNqemIhE= SHA256 (ntopng-2.3pre20160426.tar.gz) = V8CUmPJRJTofnllR4kMpkLUPr42w11ZYIdX4CpMcQ1Q= SIZE (nDPI-dev-20160426.tar.gz) = 6953268 SIZE (ntopng-2.3pre20160426.tar.gz) = 27653065
Re: multibyte character issues in ports
Ingo Schwarze usta.de> writes: > If anybody is aware of any annoying multibyte character issues in > ports land, feel free to tell me... Obviously, i don't promise to > fix it, but at least i'll have a look and try if i can come up > with a reasonable idea. (in)famous netbeans "output window garbage" bug? http://marc.info/?l=openbsd-ports&m=144754218814325&w=2
Re: NEW: net/ntopng
Stuart Henderson writes: > -- -- > ntopng is a network traffic probe that shows network usage in a high level > of detail. It provides a web-based UI allowing you to visualize traffic flows > broken down by host, country, port, application (via deep packet inspection), > AS number, etc. Flow information can also be dumped to ElasticSearch or > MySQL/MariaDB. > -- -- > > ok to import? > > this is a devel snapshot because the last release crashes when parsing > json over http. Works pretty fine here, but looks like it picks up libldap: [...] Asking ports for dependency nghttp2-1.9.1(www/nghttp2) Asking ports for dependency libidn-1.32p0(devel/libidn) ntopng-2.3pre20160426(net/ntopng): Missing lib: lber.12 (/usr/local/bin/ntopng) (NOT REACHABLE) Missing lib: ldap.13 (/usr/local/bin/ntopng) (NOT REACHABLE) *** Error 1 in target 'port-lib-depends-check' (ignored) With or without ldap "support", ok jca@ to import it PS: struct bpf_timeval strikes again! :) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
help about merging PLIST and PFRAG.$flavor
Hi, I'm working on a port (recoll desktop indexer) and it can be built without GUI and with QT4 GUI. My question is: how to handle PLIST when most of the files are same for both version of the app but each version add just couple of files more? Should I have 'no_x11' flavor and a flavor for 'gui' and one PLIST with '%%no_x11%%' and '%%qui%%'? I'm not sure if I can have two flavors and no "default"... An advise is appreciated. j.
Fwd: NEW: htop 2.0.0
This fell through the cracks. Can somebody please import it now that ports is unlocked? thanks -- Forwarded message -- From: Juan Francisco Cantero Hurtado Date: Mon, Feb 15, 2016 at 10:34 PM Subject: Re: NEW: htop 2.0.0 To: ports@openbsd.org 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 > 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: Fwd: NEW: htop 2.0.0
Amit Kulkarni 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. > thanks > > -- Forwarded message -- > From: Juan Francisco Cantero Hurtado > Date: Mon, Feb 15, 2016 at 10:34 PM > Subject: Re: NEW: htop 2.0.0 > To: ports@openbsd.org > > > 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 >> 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 > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Trimming KDE 3
So there is a strong agreement that KDE 3 should be trimmed. Before aja@ goes tedu and remove whole x11/kde with all dependants, here is a proposal that keeps some unique parts of KDE 3, while removing most heavy parts. This should help bulk builders by minimizing time spent in tagged builds. Further plans include trimming of x11/kde/base3 and, maybe, others, allowing to get rid of dpb tags entirely. There are three lists below. I'm asking all interested parties take attention at the third one, and tell your opinions (either in public or privately, at your option). Thank you all in advance for reading. :) 1. Things going to go: editors/kilehave KDE4+ counterpart games/kslidehave KDE4+ counterpart (palapeli) graphics/digikamhave KDE4+ counterpart graphics/gwenview have KDE4+ counterpart graphics/gwenview-i18n have KDE4+ counterpart graphics/kimdabause Digikam, dude! graphics/kipi-plugins have KDE4+ counterpart graphics/libkdcraw have KDE4+ counterpart graphics/libkexif have KDE4+ counterpart graphics/libkexiv2 have KDE4+ counterpart graphics/libkipihave KDE4+ counterpart misc/ktimeclock one more reminder with ugly interface? multimedia/k3b have KDE4+ counterpart multimedia/kaffeine have KDE4+ counterpart net/ktorrenthave KDE4+ counterpart productivity/taskjugglerwe want to get rid of x11/kde/pim3 sysutils/filelight have KDE4+ counterpart sysutils/krenamehave KDE4+ counterpart x11/kde/addons3 unuseful without KDE desktop x11/kde/admin3 outdated x11/kde/edu3have KDE4+ counterparts x11/kde/games3 have KDE4+ counterparts x11/kde/graphics3 have KDE4+ counterparts x11/kde/multimedia3 have KDE4+ counterparts x11/kde/network3have KDE4+ counterparts, a lot of holes x11/kde/pim3have KDE4+ counterparts, a lot of holes x11/kde/sdk3outdated x11/kde/utils3 have KDE4+ counterparts x11/kde/webdev outdated x11/kmplayerETOOMANYMPLAYERS x11/quadkonsole superseded by Yakuake and tmux x11/tellico have KDE4+ counterpart x11/yakuake have KDE4+ counterpart x11/qinxunuseful without KDE desktop 2. Things going to stay for now: cad/klogic should be updated to KDE4+ version games/kbilliardsunique, not ported to KDE4+ games/taxipilot unique, not ported to KDE4+ inputmethods/uim,-kde last thing to go math/kstunique, not ported to KDE4+ multimedia/kguitar unique, not ported to KDE4+ sysutils/knutclient should be updated to KDE4+ version x11/kde/accessibility3 last thing to go x11/kde/arts3 required by x11/kde/libs3 x11/kde/base3 common dependency x11/kde/libs3 common dependency 3. Things that I'm not sure about: audio/amarokvery friendly player, but what about Clementine? devel/kdbg any users? mail/kbiff any users? x11/kdirstatdoes filelight supersede it? x11/krusaderthe only x11/kde/bindings3 user x11/kde/bindings3 only for krusader x11/kde/okleany users? x11/kde/toys3 any users? x11/kountdown any users?
Re: NEW: htop 2.0.0
On Tue, Apr 26, 2016 at 11:28:52PM +0200, Jeremie Courreges-Anglas wrote: > Amit Kulkarni 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
Re: NEW: htop 2.0.0
On Wed, 27 Apr 2016, Juan Francisco Cantero Hurtado wrote: > On Tue, Apr 26, 2016 at 11:28:52PM +0200, Jeremie Courreges-Anglas wrote: > > Amit Kulkarni 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. Thanks for re-packaging! This looks way better than top.
Re: multibyte character issues in ports
Alexey Suslikov wrote: > Ingo Schwarze usta.de> writes: > > > If anybody is aware of any annoying multibyte character issues in > > ports land, feel free to tell me... Obviously, i don't promise to > > fix it, but at least i'll have a look and try if i can come up > > with a reasonable idea. > > (in)famous netbeans "output window garbage" bug? Java has its own unicode support. There is nothing here for us to fix.
