new net/purple-hangouts
Attached is an updated version of Brian Callahan's port of net/purple-hangouts. (https://marc.info/?l=openbsd-ports&m=151484340626848&w=2) I contacted Brian who said: --8<---cut here---start->8--- I don't use it so take over maintainer and send it to the list it wasn't ever imported either --8<---cut here---end--->8--- I have been successfully using this with bitlbee for several months now. This is one of the bitlbee plugins listed here (https://wiki.bitlbee.org/). I have not tested it with pidgin. setup: --8<---cut here---start->8--- ac add hangouts ac add hangouts u...@gmail.com ac hangouts on Receive in a PM: Authorization Code https://www.youtube.com/watch?v=hlDhp-eNLMU Please follow the YouTube video to get the OAuth code The video shows how to obtain the OAuth code from a web browser. --8<---cut here---end--->8--- purple-hangouts.tar.gz Description: purple-hangouts.tar.gz
Re: [portgen] Don't strip then add prefix on PKGNAME
On Sat, Apr 20, 2019 at 10:39:28PM -0400, Daniel Jakots wrote:
> On Sat, 20 Apr 2019 19:22:07 -0700, Andrew Hewus Fresh
> wrote:
>
> > tl;dr, fixes portgen(1) for python modules that have distnames that
> > start with py-.
>
> Thanks for working on that!
>
> One suggestion, does a DISTNAME of "python-foo" is renamed to "py-foo"
> by portgen(1)?
>
> The first result (as an example) in my grep is archivers/py-lzo:
> MODPY_EGG_VERSION = 1.08
> DISTNAME = python-lzo-${MODPY_EGG_VERSION}
> PKGNAME = py-lzo-${MODPY_EGG_VERSION}
>
> I haven't tested it but it would be great if it worked :)
Here, give it a try :-) The other change is committed so you will have
to cvs up.
Index: infrastructure/lib/OpenBSD/PortGen//Port/PyPI.pm
===
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm,v
retrieving revision 1.2
diff -u -p -r1.2 PyPI.pm
--- infrastructure/lib/OpenBSD/PortGen//Port/PyPI.pm21 Apr 2019 03:47:40
- 1.2
+++ infrastructure/lib/OpenBSD/PortGen//Port/PyPI.pm21 Apr 2019 05:03:20
-
@@ -66,8 +66,13 @@ sub fill_in_makefile
$self->set_comment( $di->{info}{summary} );
$self->set_other( 'MODPY_EGG_VERSION', $di->{info}{version} );
$self->set_distname( "$di->{info}{name}" . '-${MODPY_EGG_VERSION}' );
- $self->set_other( 'PKGNAME', 'py-${DISTNAME}' )
- unless $di->{info}->{name} =~ /^py-/;
+ my $pkgname = $di->{info}->{name};
+ if ($pkgname =~ /^python-/) {
+ $self->set_other( 'PKGNAME', '${DISTNAME:S/^python-/py-/}' );
+ }
+ elsif ($pkgname !~ /^py-/) {
+ $self->set_other( 'PKGNAME', 'py-${DISTNAME}' );
+ }
$self->set_modules('lang/python');
$self->set_categories('pypi');
$self->set_other( 'HOMEPAGE', $di->{info}{home_page} );
Re: [portgen] Don't strip then add prefix on PKGNAME
On Sat, Apr 20, 2019 at 10:44:39PM -0400, Kurt Mosiejczuk wrote:
> On Sat, Apr 20, 2019 at 10:39:28PM -0400, Daniel Jakots wrote:
> > On Sat, 20 Apr 2019 19:22:07 -0700, Andrew Hewus Fresh
> > wrote:
>
> > > tl;dr, fixes portgen(1) for python modules that have distnames that
> > > start with py-.
>
> > Thanks for working on that!
>
> > One suggestion, does a DISTNAME of "python-foo" is renamed to "py-foo"
> > by portgen(1)?
I actually had a comment in the email suggesting that could be done
fairly easily (and would be a straight-forward patch), but then deleted
it as the email was already really long. I didn't even see that
specific one because I was distracted by the ones that do:
PKGNAME=${DISTNAME:S/python/py/}
We also have a lot of places where we do this, but seems prone to error.
PKGNAME=${DISTNAME:S/^py/py-/}
and a few like this that I don't have enough python porting experience
to know if we should do that if the DISTNAME has any uppercase in it.
PKGNAME=py-${DISTNAME:L}
> > The first result (as an example) in my grep is archivers/py-lzo:
> > MODPY_EGG_VERSION = 1.08
> > DISTNAME = python-lzo-${MODPY_EGG_VERSION}
> > PKGNAME = py-lzo-${MODPY_EGG_VERSION}
>
> > I haven't tested it but it would be great if it worked :)
>
> It doesn't. Not yet. You end up with py-python-foo. I tried with the
> already existing python-dateutil and got py-python-dateutil.
Dangit kurt, I'm trying to keep these patches focused :-D
I can work up a patch tomorrow for S/^python-/py-/
l8rZ,
--
andrew - http://afresh1.com
Life's unfair - but root password helps!
[ports-gcc] Unbreak security/suricata
> http://build-failures.rhaalovely.net/powerpc/last/security/suricata.log
> http://build-failures.rhaalovely.net/sparc64/last/security/suricata.log
Suricata is one of these ports having issues with thread local storage
with base-gcc and C99.
This diff defines COMPILER, so we use ports-gcc instead. I also made
the spacing consistent in the Makefile.
It has been built and installed on macppc/ports-gcc-{8,4.9}
successfully.
Any comments?
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/security/suricata/Makefile,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 Makefile
--- Makefile19 Apr 2019 12:22:27 - 1.18
+++ Makefile21 Apr 2019 02:49:19 -
@@ -4,11 +4,11 @@ COMMENT = high performance network IDS,
SURICATA_V = 4.1.3
SUPDATE_V =1.0.4
-REVISION = 4
+REVISION = 5
DISTNAME = suricata-${SURICATA_V}
CATEGORIES = security
-SHARED_LIBS += htp 0.0 # 2.0
+SHARED_LIBS += htp 0.0 # 2.0
HOMEPAGE = https://suricata-ids.org/
@@ -21,12 +21,12 @@ PERMIT_PACKAGE_CDROM= Yes
MASTER_SITES = https://www.openinfosecfoundation.org/download/
# uses pledge()
-WANTLIB += c iconv jansson lz4 lzma magic net nspr4 nss3 nssutil3 pcap
-WANTLIB += pcre plc4 plds4 pthread smime3 ssl3 yaml-0 z
+WANTLIB += c iconv jansson lz4 lzma magic net nspr4 nss3 nssutil3 pcap
+WANTLIB += pcre plc4 plds4 pthread smime3 ssl3 yaml-0 z
MODULES = lang/python
-BUILD_DEPENDS = textproc/py-sphinx \
+BUILD_DEPENDS =textproc/py-sphinx \
textproc/py-yaml
RUN_DEPENDS = textproc/py-yaml
@@ -42,17 +42,19 @@ LIB_DEPENDS = archivers/lz4 \
net/libnet/1.1 \
security/nss
+COMPILER = base-clang ports-gcc
+
CONFIGURE_STYLE = autoconf
AUTOCONF_VERSION = 2.69
-CONFIGURE_ENV = ac_cv_path_HAVE_PDFLATEX= \
- ac_cv_path_HAVE_GIT_CMD=
+CONFIGURE_ENV =ac_cv_path_HAVE_PDFLATEX= \
+ ac_cv_path_HAVE_GIT_CMD=
CONFIGURE_ARGS = --disable-gccmarch-native \
--enable-ipfw \
--disable-rust
-SUBST_VARS = VARBASE SURICATA_V SUPDATE_V
+SUBST_VARS = VARBASE SURICATA_V SUPDATE_V
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/suricata/rules
Re: [portgen] Don't strip then add prefix on PKGNAME
On Sat, 20 Apr 2019 19:22:07 -0700, Andrew Hewus Fresh
wrote:
> tl;dr, fixes portgen(1) for python modules that have distnames that
> start with py-.
Thanks for working on that!
One suggestion, does a DISTNAME of "python-foo" is renamed to "py-foo"
by portgen(1)?
The first result (as an example) in my grep is archivers/py-lzo:
MODPY_EGG_VERSION = 1.08
DISTNAME = python-lzo-${MODPY_EGG_VERSION}
PKGNAME = py-lzo-${MODPY_EGG_VERSION}
I haven't tested it but it would be great if it worked :)
[portgen] Don't strip then add prefix on PKGNAME
tl;dr, fixes portgen(1) for python modules that have distnames that
start with py-.
I'm not quite sure why things were done this way, I'm assuming it was
for ruby, but it was getting us into a loop that unsurprisingly confuses
the ports system.
$ portgen py py-cpuinfo
Problem with variable expansion chain: FULLPKGNAME -> PKGNAME -> DISTNAME ->
PKGNAME
Variable PKGNAME is recursive.
and we get this, which is definitely not right:
DISTNAME = py-${PKGNAME}
PKGNAME = py-${DISTNAME}
With this patch, we instead get the much better looking:
DISTNAME = py-cpuinfo-${MODPY_EGG_VERSION}
(and no PKGNAME line)
The different languages all handle the prefix slightly differently. Ruby
ports don't include a prefix on the PKGNAME, only the FULLPKGNAME. While
perl ports get p5- on the PKGNAME automatically. Python ports
specify py- manually which is converted to py3- for the FULLPKGNAME of
he python3 FLAVOR.
Since ruby ports don't expect `ruby-` to be part of the PKGNAME I
patched Ruby.pm to strip it if necessary. There are 9 ports I found
where DISTNAME starts with ruby- and four of them strip it from PKGNAME
and set DISTNAME=ruby-${PKGNAME} while the other five set
PKGNAME=${DISTNAME:S/^ruby-//}, so I used the easier one that is used
more times. Tested with ruby-hmac and at least the DISTNAME/PKGNAME
seem right. We could fix it in ruby.port.mk to default PKGNAME to
${DISTNAME:S/^ruby-//}, but not sure it's that important.
A perl DISTNAME that starts with p5- will cause it to create a PKGNAME
that starts with a duplicated p5-p5-, but I didn't find anything in-tree
that has that and although I'm not sure if it's required by the CPAN,
the dist's name is, at least by convention, the same as the main module
with the "::" converted to "-". I'd probably fix that in cpan.port.mk
by changing to `PKGNAME ?= p5-${DISTNAME:S/^p5-//}`.
We could probably remove a lot of `PKGNAME = py-${DISTNAME}` lines from
the Makefiles with a `PKGNAME ?= py-${DISTNAME:S/^py-//}` in python.port.mk.
$ grep -l 'py-${DISTNAME}' /usr/ports/*/py-*/Makefile | wc -l
324
OK?
Index: infrastructure/lib/OpenBSD/PortGen/Port.pm
===
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port.pm,v
retrieving revision 1.4
diff -u -p -r1.4 Port.pm
--- infrastructure/lib/OpenBSD/PortGen/Port.pm 2 May 2017 11:30:03 -
1.4
+++ infrastructure/lib/OpenBSD/PortGen/Port.pm 21 Apr 2019 01:47:25 -
@@ -115,15 +115,7 @@ sub set_distname
{
my ( $self, $distname ) = @_;
- my $prefix = $self->ecosystem_prefix();
-
- # use foo-bar instead of foo-foo-bar as PKGNAME
- if ( $distname =~ /^$prefix/ ) {
- $self->{PKGNAME} = ( $distname =~ s/^$prefix//r );
- $self->{DISTNAME} = $prefix . '${PKGNAME}';
- } else {
- $self->{DISTNAME} = $distname;
- }
+ $self->{DISTNAME} = $distname;
}
sub set_license
Index: infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm
===
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PyPI.pm
--- infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 18 Jan 2016 18:08:20
- 1.1.1.1
+++ infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 21 Apr 2019 01:47:25
-
@@ -66,7 +66,8 @@ sub fill_in_makefile
$self->set_comment( $di->{info}{summary} );
$self->set_other( 'MODPY_EGG_VERSION', $di->{info}{version} );
$self->set_distname( "$di->{info}{name}" . '-${MODPY_EGG_VERSION}' );
- $self->set_other( 'PKGNAME', 'py-${DISTNAME}' );
+ $self->set_other( 'PKGNAME', 'py-${DISTNAME}' )
+ unless $di->{info}->{name} =~ /^py-/;
$self->set_modules('lang/python');
$self->set_categories('pypi');
$self->set_other( 'HOMEPAGE', $di->{info}{home_page} );
Index: infrastructure/lib/OpenBSD/PortGen/Port/Ruby.pm
===
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/Ruby.pm,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Ruby.pm
--- infrastructure/lib/OpenBSD/PortGen/Port/Ruby.pm 18 Jan 2016 18:08:20
- 1.1.1.1
+++ infrastructure/lib/OpenBSD/PortGen/Port/Ruby.pm 21 Apr 2019 01:47:25
-
@@ -69,6 +69,8 @@ sub fill_in_makefile
$self->set_comment( $vi->{summary} );
$self->set_distname("$di->{name}-$di->{version}");
+ $self->set_other( 'PKGNAME', '${DISTNAME:S/ruby-//}' )
+ if $di->{name} =~ /^ruby-/;
$self->set_modules('lang/ruby');
$self->set_categories('ruby');
$self->set_other( 'HOMEPAGE', $di->{homepage_uri} );
[ports-gcc-8] Unbreak security/steghide, fix tests
> Arguments.h:103:22: error: 'constexpr' needed for in-class
> initialization of static data member
It's again due to the fact that gcc-8 uses C++14 as its default C++
standard.
Expanding the use of C++03 to any compiler fixes the build on
macppc/ports-gcc-8.
The test suite was partly broken because some Perl code assumed that
'.' was still in @INC. I've fixed that as well. Tests are failing the
same way on macppc and amd64.
Any comment?
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/security/steghide/Makefile,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 Makefile
--- Makefile24 Oct 2018 14:28:10 - 1.16
+++ Makefile21 Apr 2019 00:23:32 -
@@ -3,7 +3,7 @@
COMMENT = software able to hide data in various kind of files
DISTNAME = steghide-0.5.1
-REVISION = 6
+REVISION = 7
CATEGORIES = security
HOMEPAGE = http://steghide.sf.net/
@@ -28,9 +28,6 @@ AUTOCONF_VERSION =2.57
CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib -liconv -lintl"
-.include
-.if ${PROPERTIES:Mclang}
CXXFLAGS +=-std=c++03
-.endif
.include
Index: patches/patch-tests_st_embparameters_pl
===
RCS file: patches/patch-tests_st_embparameters_pl
diff -N patches/patch-tests_st_embparameters_pl
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-tests_st_embparameters_pl 21 Apr 2019 00:23:32 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+Fix test with Perl 5.26+ (no . in @INC)
+
+Index: tests/st_embparameters.pl
+--- tests/st_embparameters.pl.orig
tests/st_embparameters.pl
+@@ -1,4 +1,5 @@
+ #!/usr/bin/perl -w
++BEGIN { push @INC, '.'; }
+ use STSupport;
+
+ use constant EMPTY => {e => "none", Z => "", K => "", "-check" => ""} ;
Index: patches/patch-tests_st_fileformats_pl
===
RCS file: patches/patch-tests_st_fileformats_pl
diff -N patches/patch-tests_st_fileformats_pl
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-tests_st_fileformats_pl 21 Apr 2019 00:23:32 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+Fix test with Perl 5.26+ (no . in @INC)
+
+Index: tests/st_fileformats.pl
+--- tests/st_fileformats.pl.orig
tests/st_fileformats.pl
+@@ -1,4 +1,5 @@
+ #!/usr/bin/perl -w
++BEGIN { push @INC, '.'; }
+ use STSupport;
+
+ use constant EMPTY => {e => "none", Z => "", K => "", "-check" => ""} ;
[ports-gcc-8] Unbreak multimedia/libmp4v2
> src/cmeta.cpp:1386:16: error: converting to 'bool' from
> 'std::nullptr_t' requires direct-initialization [-fpermissive]
> return NULL;
Again, it breaks because it wants C++<11. Building libmp4v2
with C++03 for any compiler fixes the issue.
It has been successfully tested on macppc/ports-gcc-8.
Any comments?
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/multimedia/libmp4v2/Makefile,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 Makefile
--- Makefile24 Oct 2018 14:28:08 - 1.18
+++ Makefile20 Apr 2019 22:51:41 -
@@ -4,7 +4,7 @@ COMMENT = read and manipulate the MP4 c
DISTNAME = mp4v2-1.9.1
PKGNAME = lib${DISTNAME}
-REVISION = 5
+REVISION = 6
CATEGORIES = multimedia audio
SHARED_LIBS = mp4v2 4.0 #1.9
@@ -27,9 +27,6 @@ USE_GMAKE = Yes
MAKE_FILE =GNUmakefile
CONFIGURE_STYLE = gnu
-.include
-.if ${PROPERTIES:Mclang}
CXXFLAGS +=-std=c++03
-.endif
.include
[ports-gcc] Unbreak comms/hackrf on big endian archs
> http://build-failures.rhaalovely.net/sparc64/last/comms/hackrf.log
> http://build-failures.rhaalovely.net/powerpc/last/comms/hackrf.log
Big endianness cannot be detected with base-gcc.
I've not much to say, using ports-gcc instead just works :)
Works fine on macppc/ports-gcc-{8,4.9}.
OK?
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/comms/hackrf/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 Makefile
--- Makefile20 Nov 2018 12:46:09 - 1.1.1.1
+++ Makefile20 Apr 2019 22:13:01 -
@@ -3,6 +3,7 @@
COMMENT = host software for the HackRF One SDR
V =2018.01.1
+REVISION = 0
DISTNAME = hackrf-$V
SHARED_LIBS += hackrf0.0 # 0.5
@@ -25,6 +26,8 @@ EXTRACT_SUFX =.tar.xz
MODULES = devel/cmake
LIB_DEPENDS = devel/libusb1 \
math/fftw3,float
+
+COMPILER = base-clang ports-gcc
CONFIGURE_ARGS = -DCMAKE_C_FLAGS="${CFLAGS} -I$
{LOCALBASE}/include"
[ports-gcc-8 / all] Unbreak comms/hylafax, build with C++14
Hi ports,
Hylafax doesn't build with ports-gcc-8:
> FaxRecvInfo.c++:115:20: error: ISO C++ forbids comparison between
> pointer and integer [-fpermissive]
Using C++03 like we're doing currently with base-clang doesn't help. It
appears that Debian has fixes [0] for gcc>=7, i used them.
The diff i propose here:
- moves HOMEPAGE to https (including in the README)
- allows building with C++14 and thus the removal of clang-specific
flags (it still works with gcc-4.9 and its default C++98)
- makes portcheck(1) happy: add a RCS tag to a patch that had none,
change lines with more than 80 chars and remove trailing whitespaces.
It builds and installs fine on macppc/ports-gcc-{8,4.9} and amd64.
Any comment?
Charlène.
[0]
https://sources.debian.org/patches/hylafax/3:6.0.6-8.1/828_gcc7.patch/
Index: Makefile
===
RCS file: /cvs/ports/comms/hylafax/Makefile,v
retrieving revision 1.84
diff -u -p -u -p -r1.84 Makefile
--- Makefile24 Oct 2018 14:27:59 - 1.84
+++ Makefile20 Apr 2019 17:37:32 -
@@ -2,10 +2,10 @@
COMMENT= send/receive faxes and share modems
DISTNAME= hylafax-6.0.6
-REVISION = 13
+REVISION= 14
CATEGORIES=comms
-HOMEPAGE= http://www.HylaFAX.org/
+HOMEPAGE= https://www.HylaFAX.org/
MASTER_SITES= http://ftp.hylafax.org/source/ \
ftp://ftp.hylafax.org/source/ \
@@ -21,7 +21,7 @@ FLAVOR?=
WANTLIB= c iconv intl jbig m ${COMPILER_LIBCXX} tiff util z
-COMPILER = base-clang ports-gcc base-gcc
+COMPILER= base-clang ports-gcc base-gcc
BUILD_DEPENDS= print/ghostscript/gnu
RUN_DEPENDS= print/ghostscript/gnu \
@@ -51,11 +51,6 @@ CONFIGURE_ENV+= CCOMPILER="${CC}" CXXCO
CONFIGURE_ARGS+= --with-PAGESIZE=A4
.endif
-.include
-.if ${PROPERTIES:Mclang}
-CXXFLAGS +=-std=c++03
-.endif
-
FAKE_FLAGS=ROOT=${WRKINST} SPOOL=${PREFIX}/libdata/hylafax
NO_TEST= Yes
@@ -64,6 +59,7 @@ pre-configure:
${SUBST_CMD} ${WRKSRC}/configure
post-install:
- echo "FontMap: ${LOCALBASE}/share/fonts/ghostscript"
>${PREFIX}/libdata/hylafax/etc/hyla.conf
+ echo "FontMap: ${LOCALBASE}/share/fonts/ghostscript" \
+ >${PREFIX}/libdata/hylafax/etc/hyla.conf
.include
Index: patches/patch-faxd_ModemConfig_c++
===
RCS file: patches/patch-faxd_ModemConfig_c++
diff -N patches/patch-faxd_ModemConfig_c++
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-faxd_ModemConfig_c++ 20 Apr 2019 17:37:32 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+Allow building with C++14
+
+Index: faxd/ModemConfig.c++
+--- faxd/ModemConfig.c++.orig
faxd/ModemConfig.c++
+@@ -817,4 +817,4 @@ ModemConfig::setConfigItem(const char* tag, const char
+ }
+ #undef N
+
+-fxIMPLEMENT_ObjArray(IDConfArray, id_config);
++fxIMPLEMENT_ObjArray(IDConfArray, id_config)
Index: patches/patch-faxd_ModemConfig_c++.orig
===
RCS file: patches/patch-faxd_ModemConfig_c++.orig
diff -N patches/patch-faxd_ModemConfig_c++.orig
Index: patches/patch-faxd_UUCPLock_c++
===
RCS file: /cvs/ports/comms/hylafax/patches/patch-faxd_UUCPLock_c++,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-faxd_UUCPLock_c++
--- patches/patch-faxd_UUCPLock_c++ 27 Jan 2003 13:42:48 - 1.2
+++ patches/patch-faxd_UUCPLock_c++ 20 Apr 2019 17:37:32 -
@@ -1,3 +1,5 @@
+$OpenBSD$
+
--- faxd/UUCPLock.c++.orig Thu Sep 21 05:24:54 2000
+++ faxd/UUCPLock.c++ Wed Jul 31 12:40:10 2002
@@ -37,6 +37,7 @@ extern "C" {
Index: patches/patch-libhylafax_FaxRecvInfo_c++
===
RCS file: patches/patch-libhylafax_FaxRecvInfo_c++
diff -N patches/patch-libhylafax_FaxRecvInfo_c++
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-libhylafax_FaxRecvInfo_c++20 Apr 2019 17:37:32 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Allow building with C++14
+
+Index: libhylafax/FaxRecvInfo.c++
+--- libhylafax/FaxRecvInfo.c++.orig
libhylafax/FaxRecvInfo.c++
+@@ -112,7 +112,7 @@ FaxRecvInfo::decode(const char* cp)
+ if (cp == NULL || cp[1] != ',' || cp[2] != '"')
+ return (false);
+ u_int i = 0;
+-while (cp+2 != '\0') {
++while (*(cp+2) != '\0') {
+ callid[i] = cp+3; // +1 for "/+1 for ,/+1 for "
+ if (*cp == '\"') break;
+ callid[i].resize(callid[i].next(0,'"'));
Index: pkg/README
===
RCS file: /cvs/ports/comms/hylafax/pkg/README,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 README
--- pkg/README 4 Sep 2018 12:46:09 - 1.7
+++ pkg/README 20 Apr 2019 17:37:32 -
Re: [NEW] www/honk
- Remove rc_pre On 4/20/19, Horia Racoviceanu wrote: > - Remove defaults > - Use syslog > - Fix templates > > On 4/19/19, Stuart Henderson wrote: >> This has various things (in Makefile and the rc script) explicitly set >> to the default (MAINTAINER, daemon_flags, daemon_rtable, etc), please >> just >> leave those lines out. >> >> The logging setup in this rc script will break with log rotation, >> it would be better to use the method done with prometheus/influxdb. >> >> The template files (html/css etc) installed directly to /var probably >> want installing to /usr/local/share/examples instead and copying with >> @sample instead, so if users modify them they can still update. >> >> > > Thank you > honk.tar.gz Description: GNU Zip compressed data
Re: [NEW] www/honk
- Remove defaults - Use syslog - Fix templates On 4/19/19, Stuart Henderson wrote: > This has various things (in Makefile and the rc script) explicitly set > to the default (MAINTAINER, daemon_flags, daemon_rtable, etc), please just > leave those lines out. > > The logging setup in this rc script will break with log rotation, > it would be better to use the method done with prometheus/influxdb. > > The template files (html/css etc) installed directly to /var probably > want installing to /usr/local/share/examples instead and copying with > @sample instead, so if users modify them they can still update. > > Thank you honk.tar.gz Description: GNU Zip compressed data
Re: update print/poppler
On Fri, Mar 29 2019, Matthias Kilian wrote: > Hi, > > On Fri, Mar 29, 2019 at 09:38:24PM +0100, Jeremie Courreges-Anglas wrote: >> > update to poppler-0.75.0, some bug fixes, and a new program (pdfattach) >> > in poppler-utils. > [...] >> Just to be clear: do you plan to commit this before 6.5 is tagged? > > If the timing isn't too tight... but see below. > >> (My sparc64 build machine is also running a test bulk and got past >> print/poppler already, so I can't really apply your diff now.) > > Well, the scariest entry in the release notes is: > > * pdfsig: fix use after free > > which doesn't apply to us (because we don't build / include that > one)[. > > So i'll just defer the update unless your sparc64 gains super powers > before the ports tree is locked ;-) I did another partial sparc64 bulk, the poppler-0.75 packages built fine. This was using gcc-8.3.0 though. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [NEW] net/thingsd 1.0
On Wed, Jan 23, 2019 at 08:26:23AM +0100, Rafael Sadowski wrote: > On Mon Jan 21, 2019 at 10:23:25AM -0700, Tracey Emery wrote: > > After some additional testing, I found a leak. So, here is a new port to > > include > > that fix. The flaw wasn't discovered until I decided to hammer the daemon > > with > > subscription packets. > > > > This will be the last email about this new port for awhile. > > Thanks. > > > > On Fri, Jan 18, 2019 at 04:00:42PM -0700, Tracey Emery wrote: > > > Sorry, screwed up release on github. Here is a patch for distinfo. I > > > redid the > > > release. > > > > > > Thanks. > > > > > > --- ports/net/thingsd/distinfoThu Jan 17 08:33:52 2019 > > > +++ net/thingsd/distinfo Fri Jan 18 15:53:15 2019 > > > @@ -1,2 +1,2 @@ > > > -SHA256 (thingsd-1.0.tar.gz) = > > > VBWxI2FzrFVD8rWdm8yjnM3FLs6RztAe1k5aj7TW0OE= > > > -SIZE (thingsd-1.0.tar.gz) = 20488 > > > +SHA256 (thingsd-1.0.tar.gz) = > > > R5Iqicf5cm62zlXU3uHNuzsKjMgLlToPLpElX1Qs0Ds= > > > +SIZE (thingsd-1.0.tar.gz) = 20539 > > > > > > > > > On Thu, Jan 17, 2019 at 09:39:10AM -0700, Tracey Emery wrote: > > > > Hello, > > > > > > > > This is a new port request and a replacement for a formerly requested > > > > port, > > > > which should be disregarded (net/busybeed). > > > > > > > > thingsd has been completely refactored and cleaned up from the original > > > > busybeed, and now uses libevent from base. > > > > > > > > Description: > > > > The thingsd OpenBSD proxy daemon provides a mechanism for clients and > > > > client > > > > processes to communicate with an array of serial and IoT things. At its > > > > core, > > > > thingsd is primarily a packet repeater in that it waits for packets to > > > > swap > > > > between subscriber clients and things. However, thingsd also provides > > > > password > > > > control over those connections, including client limits. > > > > > > > > I'd like to ask for _thingsd:_thingsd to be added to the user.list db. > > > > > > > > I've been succesfully running this in place of busybeed for a couple > > > > weeks, now. > > > > > > > > Is anyone willing to test and ok? Comments? > > > > > > > > Thanks, > > > > Tracey > > OK rsadowski@, if someone would like to import it. > > @Tracey Emery: thingsctl(1) need some love ;) > > RS Attached is a new port and major version bump. The control interface should be done now. Anyone willing to OK this again and import now? Thanks, Tracey thingsd-2.1.tar.gz Description: Binary data
Re: Update to sdl2-mixer 2.0.4
On Sat, Apr 20 2019, Thomas Frohwein wrote:
> ping - catch up with sdl2-mixer for 6.6?
One minor nit,
> On Sat, Jan 19, 2019 at 03:00:58PM -0800, Thomas Frohwein wrote:
>> Hi,
>>
>> This diff updates sdl2-mixer from 2.0.2 to 2.0.4. Main changes are
>> addition of Opus support via audio/opusfile and some bugfixes. Official
>> changelog [1]:
>>
>> 2.0.4:
>> * Removed smpeg support for mp3 music, now that it's replaced by libmpg123
>> * Fixed mp3 mad decoder to skip tags, which otherwise would lead to crashes
>> * Added support for Opus music playback using opusfile library
>>
>> 2.0.3:
>> * Fixed regression where Mix_Init() would return 0 for available music
>> formats
>>
>> Bump minor because of symbol additions. The output of check_sym:
>>
>> /usr/local/lib/libSDL2_mixer.so.0.0 -->
>> /usr/ports/pobj/sdl2-mixer-2.0.4/SDL2_mixer-2.0.4/build/.libs/libSDL2_mixer.so.0.1
>> No dynamic export changes
>> External reference changes:
>> added:
>> SDL_Log
>> SDL_strcmp
>> op_free
>> op_head
>> op_open_callbacks
>> op_pcm_seek
>> op_read
>> op_seekable
check_sym shows no "Dynamic export changes", this alone doesn't warrant
a minor bump. A diff of the installed headers shows new possible values
for two enums (related to opus support). I would bump the minor to
ensure that possible consumers of the new enum values use the library
they were built against.
While here I would sync the shlib version used upstream, see
${WRKSRC}/shared_libs.log:
SHARED_LIBS = SDL2_mixer 0.1 # 2.2
Diff looks good ports-wise, ok jca@ since you've tested multiple
consumers.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Update to sdl2-mixer 2.0.4
ping - catch up with sdl2-mixer for 6.6?
On Sat, Jan 19, 2019 at 03:00:58PM -0800, Thomas Frohwein wrote:
> Hi,
>
> This diff updates sdl2-mixer from 2.0.2 to 2.0.4. Main changes are
> addition of Opus support via audio/opusfile and some bugfixes. Official
> changelog [1]:
>
> 2.0.4:
> * Removed smpeg support for mp3 music, now that it's replaced by libmpg123
> * Fixed mp3 mad decoder to skip tags, which otherwise would lead to crashes
> * Added support for Opus music playback using opusfile library
>
> 2.0.3:
> * Fixed regression where Mix_Init() would return 0 for available music formats
>
> Bump minor because of symbol additions. The output of check_sym:
>
> /usr/local/lib/libSDL2_mixer.so.0.0 -->
> /usr/ports/pobj/sdl2-mixer-2.0.4/SDL2_mixer-2.0.4/build/.libs/libSDL2_mixer.so.0.1
> No dynamic export changes
> External reference changes:
> added:
> SDL_Log
> SDL_strcmp
> op_free
> op_head
> op_open_callbacks
> op_pcm_seek
> op_read
> op_seekable
>
> Tested most of the consumers (including hedgewars, sdlpop, blobwars,
> cataclysm-dda, corsixth, wesnoth, and more) briefly to make sure sound
> is there and found no issues.
>
> I'd like to take MAINTAINER to update SDL2 suite more consistently in
> the future.
>
> ok?
>
> [1] https://www.libsdl.org/projects/SDL_mixer/
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/sdl2-mixer/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- Makefile 27 Apr 2018 15:43:20 - 1.10
> +++ Makefile 19 Jan 2019 22:58:40 -
> @@ -1,19 +1,20 @@
> # $OpenBSD: Makefile,v 1.10 2018/04/27 15:43:20 jasper Exp $
>
> -V = 2.0.2
> +V = 2.0.4
> COMMENT =SDL2 multi-channel audio mixer library
> DISTNAME = SDL2_mixer-${V}
> PKGNAME =sdl2-mixer-${V}
> CATEGORIES = devel audio
>
> -SHARED_LIBS =SDL2_mixer 0.0 # 0.0
> +SHARED_LIBS =SDL2_mixer 0.1 # 0.4
>
> HOMEPAGE = https://www.libsdl.org/projects/SDL_mixer/
> +MAINTAINER = Thomas Frohwein
>
> # zlib
> PERMIT_PACKAGE_CDROM = Yes
>
> -WANTLIB += FLAC SDL2 c m mikmod modplug ogg pthread sndio usbhid
> +WANTLIB += FLAC SDL2 c m mikmod modplug ogg opus opusfile pthread sndio
> usbhid
> WANTLIB += vorbis vorbisfile samplerate mpg123
>
> MASTER_SITES = https://www.libsdl.org/projects/SDL_mixer/release/
> @@ -24,6 +25,7 @@ LIB_DEPENDS = audio/flac \
> audio/libogg \
> audio/libvorbis \
> audio/mpg123 \
> + audio/opusfile \
> devel/sdl2
>
> CONFIGURE_STYLE =gnu
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/sdl2-mixer/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 27 Apr 2018 15:43:20 - 1.3
> +++ distinfo 19 Jan 2019 22:58:40 -
> @@ -1,2 +1,2 @@
> -SHA256 (SDL2_mixer-2.0.2.tar.gz) =
> TmFeJ+/KT0Od+a9qosbehBUNF8v9EhdLVIaMEvGcg7s=
> -SIZE (SDL2_mixer-2.0.2.tar.gz) = 9620763
> +SHA256 (SDL2_mixer-2.0.4.tar.gz) =
> tM9aOCwGHNdQgc8kbCqi+d+NsEvdqNzca2zKVb7eJBk=
> +SIZE (SDL2_mixer-2.0.4.tar.gz) = 11125077
> Index: patches/patch-configure
> ===
> RCS file: /cvs/ports/devel/sdl2-mixer/patches/patch-configure,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-configure
> --- patches/patch-configure 27 Apr 2018 15:43:20 - 1.2
> +++ patches/patch-configure 19 Jan 2019 22:58:40 -
> @@ -2,16 +2,16 @@ $OpenBSD: patch-configure,v 1.2 2018/04/
> Index: configure
> --- configure.orig
> +++ configure
> -@@ -12357,7 +12357,7 @@ if eval \${$as_ac_Lib+:} false; then :
> +@@ -12353,7 +12353,7 @@ if ${ac_cv_lib_vorbisfile_ov_open_callbacks+:}
> false;
> $as_echo_n "(cached) " >&6
> else
> ac_check_lib_save_LIBS=$LIBS
> --LIBS="-lvorbisfile -lvorbis -logg -lm $LIBS"
> -+LIBS="-lvorbisfile -lvorbis -logg $LIBM $LIBS"
> +-LIBS="-lvorbisfile -lvorbis -logg -lm $LIBS"
> ++LIBS="-lvorbisfile -lvorbis -logg $LIBM $LIBS"
> cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h. */
>
> -@@ -12447,7 +12447,7 @@ fi
> +@@ -12443,7 +12443,7 @@ fi
>
> if test x$have_flac_export = xyes; then
> LIBS_SAVED="$LIBS"
> @@ -20,7 +20,7 @@ Index: configure
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libflac
> so-name version >= $libflac_ver" >&5
> $as_echo_n "checking for libflac so-name version >= $libflac_ver... " >&6; }
> cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> -@@ -12493,7 +12493,7 @@ if ${ac_cv_lib_FLAC_FLAC__stream_decoder_new+:}
> false;
> +@@ -12489,7 +12489,7 @@ if ${ac_cv_lib_FLAC_FLAC__stream_decoder_new+:}
> false;
> $as_echo_n "(cached) " >&6
> else
> ac_check_lib_save_LIBS=$LIBS
>
Re: NEW: graphics/bonzomatic
Thanks jsg, I've appended the following to DESCR so users will now up front whether it works on their machine: At least OpenGL 4.1 is required, which is supported by 3rd generation Intel Core i3/i5/i7 "Ivy Bridge" processors and ATI/AMD TeraScale 2 "Evergreen" chipsets or later. On Sat, Apr 20, 2019 at 11:52:50AM +0100, Stuart Henderson wrote: > For COMPILER I would just list base-clang, in the unlikely event of > somebody wanting to get it working on another arch they can add > whatever's needed. (And set ONLY_FOR_ARCHS). All but base-clang removed from COMPILER. > > Comment: > > Live shader editor > > lowercase ^^, but I would try to convey a bit more about what it does in > COMMENT. maybe something like this? > > tool for live-coding pixel shaders (demo-scene parties etc) Went for "tool for live-coding pixel shaders". More feedback? OK to import? bonzomatic.tgz Description: Binary data
Re: NEW: graphics/bonzomatic
On Sat, Apr 20, 2019 at 12:42:05PM +0200, Klemens Nanni wrote: > Here's bonzomatic, working fine so far on my X230 with OpenGL 4.2 so I > can play with shaders. Controls in the UI work, the visuals render > perfectly fluid in the background. > > Somehow midi input is not working yet and I cannot see the little > texture previews while coding, but I'd like to work on this in-tree. > Sound input can be used as entropy source for visual effects; no audio > playback involved. > > OpenGL >= 4.1 is required, as well a modern C++ compiler; appearently > only amd64 works but I'm a) lacking other platforms to test and b) > knowledge about Mesa/OpenGL/graphics stuff. Can someone point me to the > right direction here? It is hardware specific, the llvmpipe software rasteriser is at OpenGL 3.3. On ati/amd hardware >= evergreen is required https://www.x.org/wiki/RadeonFeature/#index1h2 On intel hardware >= ivy bridge (x230) https://cgit.freedesktop.org/mesa/mesa/plain/docs/features.txt?h=18.3
Re: NEW: graphics/bonzomatic
On 2019/04/20 12:42, Klemens Nanni wrote: > Here's bonzomatic, working fine so far on my X230 with OpenGL 4.2 so I > can play with shaders. Controls in the UI work, the visuals render > perfectly fluid in the background. > > Somehow midi input is not working yet and I cannot see the little > texture previews while coding, but I'd like to work on this in-tree. > Sound input can be used as entropy source for visual effects; no audio > playback involved. > > OpenGL >= 4.1 is required, as well a modern C++ compiler; appearently > only amd64 works but I'm a) lacking other platforms to test and b) > knowledge about Mesa/OpenGL/graphics stuff. Can someone point me to the > right direction here? > > The port bundles a few external programs, but all is baked into a single > program in the end and there seems to be no easy way of reusing existing > ports such as editors/scintilla for this. I've checked and mentioned > all licenses. > > Given these requirements, I'm not sure whether ONLY_ARCHS=amd64 *and* > COMPILER='base-clang ports-clang ports-gcc' are appropiate, as the > former implies COMPILER=base-clang, while the latter includes other > platforms as well. For COMPILER I would just list base-clang, in the unlikely event of somebody wanting to get it working on another arch they can add whatever's needed. (And set ONLY_FOR_ARCHS). > README.md is shipped since it includes a few helpful links, an optional > configuration example and brief instructions on how to run a competition. > > Package and program name are lowercased. > > DEBUG is properly propagated, but -DNDEBUG handling based on our flag > might need massaging (in external code); also something for in-tree. > > Feedback? OK? > > Information for inst:bonzomatic-20190326 > > Comment: > Live shader editor lowercase ^^, but I would try to convey a bit more about what it does in COMMENT. maybe something like this? tool for live-coding pixel shaders (demo-scene parties etc) > Description: > Bonzomatic is a live-coding tool, where you can write a 2D > fragment/pixel shader > while it is running in the background. > > The tool was originally conceived and implemented after the Revision > 2014 > demoscene party's live coding competition where two contestants > improv-code an > effect in 25 minutes head-to-head. > > Maintainer: Klemens Nanni > > WWW: https://github.com/Gargaj/Bonzomatic
Re: NEW: graphics/bonzomatic
shader.glsl was not meant to be in the tarball, but since you see it: That's the default code you start with, it was written to $PWD while I was running bonzomatic from the ports directory.
NEW: graphics/bonzomatic
Here's bonzomatic, working fine so far on my X230 with OpenGL 4.2 so I can play with shaders. Controls in the UI work, the visuals render perfectly fluid in the background. Somehow midi input is not working yet and I cannot see the little texture previews while coding, but I'd like to work on this in-tree. Sound input can be used as entropy source for visual effects; no audio playback involved. OpenGL >= 4.1 is required, as well a modern C++ compiler; appearently only amd64 works but I'm a) lacking other platforms to test and b) knowledge about Mesa/OpenGL/graphics stuff. Can someone point me to the right direction here? The port bundles a few external programs, but all is baked into a single program in the end and there seems to be no easy way of reusing existing ports such as editors/scintilla for this. I've checked and mentioned all licenses. Given these requirements, I'm not sure whether ONLY_ARCHS=amd64 *and* COMPILER='base-clang ports-clang ports-gcc' are appropiate, as the former implies COMPILER=base-clang, while the latter includes other platforms as well. README.md is shipped since it includes a few helpful links, an optional configuration example and brief instructions on how to run a competition. Package and program name are lowercased. DEBUG is properly propagated, but -DNDEBUG handling based on our flag might need massaging (in external code); also something for in-tree. Feedback? OK? Information for inst:bonzomatic-20190326 Comment: Live shader editor Description: Bonzomatic is a live-coding tool, where you can write a 2D fragment/pixel shader while it is running in the background. The tool was originally conceived and implemented after the Revision 2014 demoscene party's live coding competition where two contestants improv-code an effect in 25 minutes head-to-head. Maintainer: Klemens Nanni WWW: https://github.com/Gargaj/Bonzomatic bonzomatic.tgz Description: Binary data
Re: [NEW] graphics/xdot-1.0 [It was: [NEW] math/xdot-1.0]
On 2019/04/20 12:25, Alessandro DE LAURENZIS wrote:
> Hello Stuart,
>
> On 18/04/2019 18:07, Stuart Henderson wrote:
> [...]
> > > > - the pypi tarball doesn't include the tests, which I instead enabled
> > > > using the one from github; is this acceptable?
> >
> > I usually prefer pypi over github, because pypi uses uploaded files
> > rather than autogenerated ones which are subject to change. It depends
> > how useful the tests are really.
> >
>
> So I reverted the port's Makefile to use pypi (I think the test suite is
> useful mainly for development).
>
> > : RUN_DEPENDS = math/graphviz \
> > : devel/py-gobject3 \
> >
> > That should be devel/py-gobject3${MODPY_FLAVOR}
>
> Fixed.
>
> Updated tarball attached.
Thanks - this one is OK sthen@ if someone would like to import.
Re: [NEW] graphics/xdot-1.0 [It was: [NEW] math/xdot-1.0]
Hello Stuart,
On 18/04/2019 18:07, Stuart Henderson wrote:
[...]
- the pypi tarball doesn't include the tests, which I instead enabled
using the one from github; is this acceptable?
I usually prefer pypi over github, because pypi uses uploaded files
rather than autogenerated ones which are subject to change. It depends
how useful the tests are really.
So I reverted the port's Makefile to use pypi (I think the test suite is
useful mainly for development).
: RUN_DEPENDS = math/graphviz \
: devel/py-gobject3 \
That should be devel/py-gobject3${MODPY_FLAVOR}
Fixed.
Updated tarball attached.
--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: https://www.linkedin.com/in/delaurenzis/
xdot.tar.gz
Description: application/gzip
