Re: pecl redis (PHP extension for interfacing with Redis)
On 2015/11/24 18:04, Stephen Graf wrote: > Is anyone working on a port for pecl redis, a PHP extension for interfacing > with Redis (https://pecl.php.net/package/redis)? > > It seems that it is becoming a required item for ownCloud version 8.2. > OwnCloud has been an openBSD package since release 5.7 and is at level 8.1 > in release 5.8. > > The pecl redis package produces a single library, redis.so, that can be > added to the PHP libraries. I have been able to build and integrate the > package with openBSD 5.8, PHP 5.6 and ownCloud 8.2.1. However I have never > worked in the openBSD ports system and frankly my coding skills are no > longer what they used to be. > The pecl-* ports are pretty straightforward, try copying one of the existing ones as a starting point and modifying, if you get stuck then tar up what you have and send it to ports@.
Re: update libsndfile to 1.0.26
On 2015/11/25 08:27, Jan Stary wrote: > On Nov 24 23:16:21, h...@stare.cz wrote: > > Tested on amd64, i386 and armv7. > > Please re-test everywhere. > > Also, I only tested the sndfile-* binaries and audio/sox > - please test your favourite audio applications using sndfile, too. > > Jan > Some exported functions were removed, so this one does need a major bump (no need to send a new diff just for that though). removed: pchk4_find pchk4_store Otherwise looks good to me, I'll test on macppc, I can commit this later if nobody runs into problems with it. There don't seem to be huge changes, but it was 4 years since the last upstream release so being slightly cautious :)
Re: update libsndfile to 1.0.26
On 2015/11/25 10:29, Stuart Henderson wrote: > On 2015/11/25 08:27, Jan Stary wrote: > > On Nov 24 23:16:21, h...@stare.cz wrote: > > > Tested on amd64, i386 and armv7. > > > Please re-test everywhere. > > > > Also, I only tested the sndfile-* binaries and audio/sox > > - please test your favourite audio applications using sndfile, too. > > > > Jan > > > > Some exported functions were removed, so this one does need a major > bump (no need to send a new diff just for that though). > > removed: > pchk4_find > pchk4_store > > Otherwise looks good to me, I'll test on macppc, I can commit this > later if nobody runs into problems with it. > > There don't seem to be huge changes, but it was 4 years since the > last upstream release so being slightly cautious :) > There are a number of test failures on macppc, though they occur in the existing version too so I don't think they should block the update but might be worth talking to upstream about. G72x/g72x_test all g723_test: Max error of 585 at postion 3013. ok ./test_main Testing big endian conversions : ok Testing little endian conversions: ok test_endswap_short : ok test_endswap_int : ok test_endswap_int64_t : ok test_psf_put_be16: ok test_psf_put_be32: ok test_psf_put_be64: ok test_float_convert : ok test_double_convert : Line 88 : Test 7, little endian error 1e-09 -> 1.86264506943368e-09. If I comment out test_double_convert() to allow it to continue I get this from test_file_io: Testing file open: ok Testing file write : ok Testing file read: Line 166: error at index 0 (1160008829 != 931333980). Line 166: error at index 1 (1415418996 != 1134461122). (snip *lots* of lines like the above) Then onto test-wrapper (disabling set -e so it continues after error) we have problems with pcm24 and a few others, I'll attach the log for that. sh test_wrapper.sh OpenBSD mala.spacehopper.org 5.8 GENERIC#6 macppc Pedantic header test : ok error_number_test : . ok error_value_test : error.aiff .. ok error_close_test : error_close.wav . ok no_file_test : no_file.wav . ok zero_length_test : zero_length.wav . ok bad_wav_test : bad_wav.wav . ok lrintf_test: . ok pcm_test_bits_8: pcm-s8.raw .. ok pcm_test_bits_8: pcm-u8.raw .. ok pcm_test_bits_16 : le-pcm16.raw ok pcm_test_bits_16 : be-pcm16.raw ok pcm_test_bits_24 : le-pcm24.raw Line 913: double : Incorrect sample (#631 : 2103123.00 => -1.00). ulaw_test : encoder . ok ulaw_test : decoder . ok alaw_test : encoder . ok alaw_test : decoder . ok dwvw_test : dwvw12.raw .. ok dwvw_test : dwvw16.raw .. ok dwvw_test : dwvw24.raw .. ok version_test : (none) .. ok float_norm_test: float.wav ... ok double_norm_test : double.wav .. ok format_tests : (null) .. ok calc_peak_test (1 channels): be-peak.raw . ok calc_peak_test (1 channels): le-peak.raw . ok calc_peak_test (7 channels): be-peak.raw . ok calc_peak_test (7 channels): le-peak.raw . ok truncate_test : truncate.raw ok truncate_test : truncate.au . ok instrument_test: instrument.wav .. ok instrument_test: instrument.aiff . ok current_sf_info_test : current.wav . ok broadcast_test : broadcast.wav ... ok broadcast_rdwr_test: broadcast.wav ... ok broadcast_test : broadcast.wavex . ok broadcast_rdwr_test: broadcast.wavex . ok broadcast_test : broadcast.rf64 .. ok broadcast_rdwr_test: broadcast.rf64 .. ok broadcast_coding_history_test : coding_history.wav .. ok broadcast_coding_history_size : coding_hist_size.wav ok
Re: DES in libc
On 2015/11/25 08:24, Jan Stary wrote: > A rewording like that is below. Omitting the (3), as other names do > in guide.html, unless they are links to man.cgi. But apart from that, > should it say something like "we have a crypt() in libc, but don't use it"? No problem using it - it's just that the function that is in a separate library on some OS, but in libc on OpenBSD. Though it probably is worth calling out that it's not DES. > --- guide.html.orig 2015-11-24 19:46:48.0 +0100 > +++ guide.html2015-11-25 08:19:34.0 +0100 > @@ -1149,7 +1149,7 @@ And then the update. > instead of blindly installing files. > OpenBSD does NOT compress man pages. > OpenBSD does NOT require -lcrypt. > - DES encryption is part of the standard libc. > + A crypt function is implemented in the standard > libc. I'm going to commit it like this which I think covers everything; + OpenBSD does NOT require -lcrypt, -ldl, or -lrt. + The functions provided by these libraries are part of libc. + The crypt() function does not support DES, only bcrypt. - we can make further tweaks if wanted.
update misc/sent 0.2
Hi, please find below an update to sent 0.2. This release fixes several serious segfaults and issues. OK? Regards, Joerg Index: Makefile === RCS file: /cvs/ports/misc/sent/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile14 Nov 2015 19:38:55 - 1.1.1.1 +++ Makefile25 Nov 2015 11:41:25 - @@ -2,7 +2,7 @@ COMMENT= simple plaintext presentation tool -DISTNAME= sent-0.1 +DISTNAME= sent-0.2 CATEGORIES=misc productivity Index: distinfo === RCS file: /cvs/ports/misc/sent/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo14 Nov 2015 19:38:55 - 1.1.1.1 +++ distinfo25 Nov 2015 11:41:25 - @@ -1,2 +1,2 @@ -SHA256 (sent-0.1.tar.gz) = n2qlu+r4O7WEqD9DcJ3rHCnODTiNCzr1sMxgEPHA0CU= -SIZE (sent-0.1.tar.gz) = 13837 +SHA256 (sent-0.2.tar.gz) = U7lh+dkqJ3pkCN9wJbSm3q5rZVp5c4PJNEIpDkU5EHY= +SIZE (sent-0.2.tar.gz) = 13479
Re: update libsndfile to 1.0.26
On Nov 25 10:54:43, st...@openbsd.org wrote: > There are a number of test failures on macppc, though they occur in > the existing version too so I don't think they should block the update > but might be worth talking to upstream about. Thanks, I will dig up my old MacMini and look into this. Jan
update mail/opensmtpd-extras to 201511230108
Hi,
please find below an update for opensmtpd-extras to the most recent
snapshot. This also now installs table-ldap, table-passwd, and
table-sqlite which are likely going to be removed from base soon.
OK?
Thanks,
Regards,
Joerg
Index: Makefile
===
RCS file: /cvs/ports/mail/opensmtpd-extras/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile19 Jan 2015 14:08:02 - 1.4
+++ Makefile25 Nov 2015 13:23:03 -
@@ -1,52 +1,128 @@
# $OpenBSD: Makefile,v 1.4 2015/01/19 14:08:02 giovanni Exp $
-COMMENT-main= extra tools for OpenSMTPD
-COMMENT-python=Python bindings for OpenSMTPD
-COMMENT-mysql= OpenSMTPD authentication support for MySQL
-COMMENT-pgsql= OpenSMTPD authentication support for PostgreSQL
-
-V= 20150119
-DISTNAME= OpenSMTPD-extras-${V}
-PKGNAME-main= ${DISTNAME:L}
-PKGNAME-mysql= opensmtpd-extras-mysql-${V}
-PKGNAME-pgsql= opensmtpd-extras-pgsql-${V}
-PKGNAME-python=opensmtpd-extras-python-${V}
-CATEGORIES=mail
-
-HOMEPAGE= http://www.opensmtpd.org/
-
-MAINTAINER=Giovanni Bechis
-
-GH_PROJECT=OpenSMTPD-extras
-GH_ACCOUNT=OpenSMTPD
-GH_COMMIT= a9cc8a03f6ae16008d23f766d621192a52c59893
+COMMENT-main= extras for smtpd
+COMMENT-lua= extras with lua bindings for smtpd
+COMMENT-mysql= mysql based smtpd table support
+COMMENT-pgsql= postgresql based smtpd table support
+COMMENT-python=extras with python bindings for smtpd
+COMMENT-redis= redis based smtpd table support
+
+V= 201511230108
+DISTNAME= opensmtpd-extras-${V}
+PKGNAME-main= ${DISTNAME}
+PKGNAME-lua= opensmtpd-extras-lua-${V}
+PKGNAME-mysql= opensmtpd-extras-mysql-${V}
+PKGNAME-pgsql= opensmtpd-extras-pgsql-${V}
+PKGNAME-python=opensmtpd-extras-python-${V}
+PKGNAME-redis= opensmtpd-extras-redis-${V}
+
+CATEGORIES=mail
-MULTI_PACKAGES=-main -mysql -pgsql -python
+HOMEPAGE= https://www.opensmtpd.org/
-PREFIX=/usr
+MAINTAINER=Giovanni Bechis
+
+MULTI_PACKAGES=-main -lua -mysql -pgsql -python -redis
+
+PREFIX=/usr
# BSD
PERMIT_PACKAGE_CDROM= Yes
-MODULES= lang/python
-CONFIGURE_STYLE= none
-
+WANTLIB= c crypto event ssl m util sqlite3 perl
+WANTLIB-lua= c crypto event ssl m ${MODLUA_WANTLIB}
+WANTLIB-mysql= c crypto event ssl m z pthread stdc++ mysqlclient
+WANTLIB-pgsql= c crypto event ssl pq
+WANTLIB-python=c crypto event ssl m util pthread
${MODPY_WANTLIB}
+WANTLIB-redis= c crypto event ssl hiredis
+
+MASTER_SITES= ${HOMEPAGE}archives/
+
+AUTOCONF_VERSION= 2.69
+AUTOMAKE_VERSION= 1.15
+
+BUILD_DEPENDS= ${MODGNU_AUTOCONF_DEPENDS} \
+ ${MODGNU_AUTOMAKE_DEPENDS}
+LIB_DEPENDS-lua= ${MODLUA_LIB_DEPENDS}
LIB_DEPENDS-mysql= databases/mariadb,-main
LIB_DEPENDS-pgsql= databases/postgresql,-main
-
-WANTLIB-main= c util
-WANTLIB-mysql= c mysqlclient pthread util
-WANTLIB-pgsql= c pq util
-WANTLIB-python=c ${MODPY_WANTLIB} pthread util
-
-MODPY_RUNDEP= No
+LIB_DEPENDS-python=${MODPY_LIB_DEPENDS}
+LIB_DEPENDS-redis= databases/libhiredis
+RUN_DEPENDS-main= security/clamav \
+ mail/p5-Mail-SpamAssassin
+RUN_DEPENDS-lua= ${MODLUA_RUN_DEPENDS}
RUN_DEPENDS-python=${MODPY_RUN_DEPENDS}
-WRKDIST= ${WRKDIR}/${GH_PROJECT}-${GH_COMMIT}/extras
+CONFIGURE_STYLE= gnu
+CONFIGURE_ARGS=--bindir=${LOCALBASE}/bin \
+ --sbindir=${LOCALBASE}/sbin \
+ --mandir=${LOCALBASE}/man \
+ --libexecdir=${PREFIX}/libexec \
+ --sysconfdir=${SYSCONFDIR} \
+ --with-cppflags="${CFLAGS} -I${LOCALBASE}/include
-I${LOCALBASE}/include/postgresql" \
+ --with-filter-clamav \
+ --with-filter-dkim-signer \
+ --with-filter-dnsbl \
+ --with-filter-monkey \
+ --with-filter-pause \
+ --with-filter-perl \
+ --with-filter-regex \
+ --with-filter-spamassassin \
+ --with-filter-stub \
+ --with-filter-trace \
+ --with-filter-void \
+ --with-queue-null \
+ --with-queue-ram \
+ --with-queue-stub \
+ --with-scheduler-ram \
+ --with-scheduler-stub \
+ --with-table-ldap \
+ --with-table-passwd \
+ --with-table-socketmap \
+
Re: update misc/sent 0.2
Joerg Jung wrote: > please find below an update to sent 0.2. > This release fixes several serious segfaults and issues. > > OK? Works for me. ok mmcc@ It's too bad that they put big gray borders around PNGs now, though... > Index: Makefile > === > RCS file: /cvs/ports/misc/sent/Makefile,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 Makefile > --- Makefile 14 Nov 2015 19:38:55 - 1.1.1.1 > +++ Makefile 25 Nov 2015 11:41:25 - > @@ -2,7 +2,7 @@ > > COMMENT= simple plaintext presentation tool > > -DISTNAME=sent-0.1 > +DISTNAME=sent-0.2 > > CATEGORIES= misc productivity > > Index: distinfo > === > RCS file: /cvs/ports/misc/sent/distinfo,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 distinfo > --- distinfo 14 Nov 2015 19:38:55 - 1.1.1.1 > +++ distinfo 25 Nov 2015 11:41:25 - > @@ -1,2 +1,2 @@ > -SHA256 (sent-0.1.tar.gz) = n2qlu+r4O7WEqD9DcJ3rHCnODTiNCzr1sMxgEPHA0CU= > -SIZE (sent-0.1.tar.gz) = 13837 > +SHA256 (sent-0.2.tar.gz) = U7lh+dkqJ3pkCN9wJbSm3q5rZVp5c4PJNEIpDkU5EHY= > +SIZE (sent-0.2.tar.gz) = 13479 >
Re: pecl redis (PHP extension for interfacing with Redis)
> The pecl-* ports are pretty straightforward, try copying one of the > existing ones as a starting point and modifying, if you get stuck > then tar up what you have and send it to ports@. Here's a shot a one. I really have no time to test this... So any test, comment, OK are appreciated. -- Antoine pecl-redis.tgz Description: application/tar-gz
Autotools and Ordering of Object Files in Crypto++ Library
Hi Everyone, Sorry about the extra noise. I noticed this issue when examining a cut-over from GNUmakefile to Autotools. Many distros do it, so I wanted to provide a "heads up". Crypto++ has a specific order for certain object files to avoid the C++ Initialization Order Fiasco (http://www.parashift.com/c++-faq/static-init-order.html). Its detailed in Step 3 of https://cryptopp.com/wiki/Static_Initialization_Order_Fiasco#Remediations. * The short of it is, this is the exact order the library uses, and we recommend you do the same: 1. cryptlib.o 2. cpu.o 3. don't care about the rest cryptlib.o must be first in both the static archive and shared object when linking. That's because nearly every other class depends upon objects in cryptlib.o being constructed first. cpu.o is second for X86/X32/X64. On the family of platforms, we need CPU detection features to run second. If its not X86/X32/X64, then you can exclude cpu.cpp from the build (there are others that can be omitted for non-X86/X32/X64 systems; see below). The rests are don't cares. As far as I know, their only dependency is that cryptlib.o and cpu.o objects are created first. * We enforce this order in our Makefile (https://github.com/weidai11/cryptopp/blob/master/GNUmakefile#L236): # List cryptlib.cpp first and cpu.cpp second in an attempt to tame C++ static initialization problems. SRCS := cryptlib.cpp cpu.cpp $(filter-out cryptlib.cpp cpu.cpp pch.cpp simple.cpp winpipes.cpp cryptlib_bds.cpp,$(wildcard *.cpp)) # No need for CPU or RDRAND on non-X86 systems. X32 is represented with X64. ifeq ($(IS_X86)$(IS_X86_64),00) SRCS := $(filter-out cpu.cpp rdrand.cpp, $(SRCS)) endif ... # List of objects with crytlib.o and cpu.o at the first and second index position OBJS := $(SRCS:.cpp=.o) * Jeff
Success with flashrom and PCEngines APU2 BIOS upgrade
Hello Stuart & list, FYI I successfully used the flashrom port found here: https://github.com/jasperla/openbsd-wip/tree/master/sysutils/flashrom to update the BIOS of the new APU2 from PCEngines without problems. Port was build on OpenBSD 5.8-current, amd64 and i386. Many Thanks ! Mathias Reference: openbsd-tech thread on PCEngines APU2 http://marc.info/?t=14463160272&r=1&w=2
Re: Success with flashrom and PCEngines APU2 BIOS upgrade
On 2015/11/25 21:20, Mathias Schmocker wrote: > Hello Stuart & list, > > FYI I successfully used the flashrom port found here: > https://github.com/jasperla/openbsd-wip/tree/master/sysutils/flashrom > to update the BIOS of the new APU2 from PCEngines without problems. > > Port was build on OpenBSD 5.8-current, amd64 and i386. > > Many Thanks ! > Mathias > > Reference: openbsd-tech thread on PCEngines APU2 > http://marc.info/?t=14463160272&r=1&w=2 > Thanks - last time this came up we reached a bit of an impasse with the diff to emulate 8/16 bit PCI access in pciutils though, which is why it's still sitting in openbsd-wip. (If anyone digs out the old mails, ignore the aperture driver wild goose chase, this is a "reboot into securelevel=-1" port, which I think is fair enough given its usage - the only remaining issue afaik was 8/16 bit access).
Re: py-qt5
2015-11-24 4:17 GMT+03:00 Stuart Henderson : > Based on the py-qt4 port, though I haven't figured out which if > any modules should be zapped so I've not done the "only --enable > a list of named modules" thing that py-qt4 does. Any comments? The port looks good for me, and builds fine here on amd64. Okay zhuk@ -- WBR, Vadim Zhukov
