CVS: cvs.openbsd.org: ports

2019-06-06 Thread Kirill Bychkov 
CVSROOT:/cvs
Module name:ports
Changes by: ki...@cvs.openbsd.org   2019/06/06 23:56:40

Modified files:
games/flare: Makefile distinfo 
games/flare/patches: patch-CMakeLists_txt 
games/flare/pkg: PLIST-data PLIST-main 

Log message:
update to flare-1.10

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Rafael Sadowski 
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2019/06/06 23:44:37

Modified files:
fonts/font-awesome: Makefile distinfo 

Log message:
Update font-awesome to 5.9.0

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Rafael Sadowski 
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2019/06/06 23:42:53

Modified files:
x11/libqaccessibilityclient: Makefile distinfo 

Log message:
Update libqaccessibilityclient to 0.4.1

Re: UPDATE: graphics/krita

2019-06-06 Thread Rafael Sadowski 
On Tue Jun 04, 2019 at 07:26:19PM +0100, Stuart Henderson wrote:
> On 2019/06/01 10:28, Rafael Sadowski wrote:
> > Update krita to 4.2.0.
> > 
> > Krita 4.2 Release Notes:
> > https://krita.org/en/krita-4-2-release-notes/
> > 
> > To build it you have to deinstall krita 4.18 otherwise tests will fetch
> > the old one.
> > 
> > Feedback is very welcome. All shared libs checked with
> > check_sym. Lightly tested on amd64.
> 
> I hit this when testing build, sorry I didn't think to log it and it's
> well beyond my tmux scrollback. CMakeCache.txt gzipped and attached.

Thanks for testing. It smells like our  "normal" Cmake/Ninja build (re-)order
issue.

I started from a clean setup with a fresh tree and no packages installed. Built
fine.

Is is a show stopper?

> 
> FAILED: 
> plugins/extensions/pykrita/kritarunner/CMakeFiles/kritarunner.dir/__/plugin/pyqtpluginsettings.cpp.o
>  
> /usr/obj/ports/krita-4.2.0/bin/c++  -DBOOST_ALL_NO_LIB -DHAVE_X11 
> -DKCOREADDONS_LIB -DKGUIADDONS_LIB -DQT_CONCURRENT_L
> IB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x50900 
> -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LI
> B -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS -DQT_NO_URL_CAST_FROM_STRING 
> -DQT_PRINTSUPPORT_LIB -DQT_STRICT_ITERATOR
> S -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_X11EXTRAS_LIB 
> -DQT_XML_LIB -DTRANSLATION_DOMAIN=\"krita\"
>  -D_LARGEFILE64_SOURCE -Iplugins/extensions/pykrita/kritarunner 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/plugins/exten
> sions/pykrita/kritarunner 
> -Iplugins/extensions/pykrita/kritarunner/kritarunner_autogen/include 
> -I/usr/obj/ports/krita-
> 4.2.0/krita-4.2.0/interfaces -I. -I/usr/obj/ports/krita-4.2.0/krita-4.2.0 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/plu
> gins/extensions/pykrita 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/plugins/extensions/pykrita/kritarunner/../plugin
>  -Ipl
> ugins/extensions/pykrita/kritarunner/../plugin 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/plugins/extensions/pykrita/kri
> tarunner/../libkis -Iplugins/extensions/pykrita/kritarunner/../libkis 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/ui
> /canvas -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/ui/flake 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/ui/ora -I
> /usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/ui/tool 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/ui/utils -I/usr/obj/
> ports/krita-4.2.0/krita-4.2.0/libs/ui/widgets 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/ui/input/wintab -Ilibs/ui 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/ui -Ilibs/impex 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/impex -I/u
> sr/obj/ports/krita-4.2.0/krita-4.2.0/libs/image/brushengine 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/image/filter
>  -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/image/generator 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/image/lay
> erstyles -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/image/processing 
> -Ilibs/image -I/usr/obj/ports/krita-4.2.0/krit
> a-4.2.0/libs/image -Ilibs/version 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/version -Ilibs/widgets 
> -I/usr/obj/port
> s/krita-4.2.0/krita-4.2.0/libs/widgets -Ilibs/odf 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/odf -Ilibs/koplugin -I
> /usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/koplugin -Ilibs/store 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/store 
> -Ilibs/global -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/global 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/flake
> /commands -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/flake/tools 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/flak
> e/svg -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/flake/text -Ilibs/flake 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/l
> ibs/flake -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/pigment/resources 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/lib
> s/pigment/compositeops -Ilibs/pigment 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/pigment 
> -I/usr/obj/ports/krita-4.2
> .0/krita-4.2.0/libs/widgetutils/config 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/widgetutils/xmlgui 
> -Ilibs/widgetu
> tils -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/widgetutils -Ilibs/command 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0
> /libs/command -Ilibs/psd -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/psd 
> -Ilibs/metadata -I/usr/obj/ports/krita-4.2.
> 0/krita-4.2.0/libs/metadata -Ilibs/color 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/color -Ilibs/color/colord -I/us
> r/obj/ports/krita-4.2.0/krita-4.2.0/libs/color/colord -Ilibs/brush 
> -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/brush
>  -Ilibs/libkis -I/usr/obj/ports/krita-4.2.0/krita-4.2.0/libs/libkis -isystem 
> /usr/local/include -isystem /usr/local/in
> clude/OpenEXR -isystem /usr/local/include/eigen3 
> -I/usr/local/include/python3.7m -isystem /usr/local/include/KF5/KCore
> Addons -isystem /usr/local/include/KF5 -isystem /usr/local/include/X11/qt5 
> -isystem /usr/local/include/X11/qt5/QtCore 
>

java.port.mk and java port build fixes

2019-06-06 Thread kurt 
Several ports that build using the jdk and ant have issues with getting
ant to use the correct build jdk. This diff addresses those issues.

javaPathHelper is designed to use JAVA_HOME when provided to pick the
jdk to use. If it is not provided it figures out what jdk satisfied the
run depend at install time and uses that (since it is guaranteed to
work). So if jdk-11 is installed before jdk-1.8.0 and then ant is
installed, ant will default to use jdk-11 when there's no JAVA_HOME
in the env. This can lead to ports building the with wrong jdk and can
result in a package that can't run with jdk 1.8.0 or fail to build
(e.g. graphics/opencv, games/jbrickshooter)

This diff does the following:
* Adds JAVA_HOME to MAKE_ENV and CONFIGURE_ENV for any port that uses
the java module and doesn't also contain NO_BUILD=yes. Previously
this was limited to just MODJAVA_BUILD=ant, but that is not sufficient
for ports that indirectly use ant via makefiles (e.g.
textproc/link-grammar, graphics/opencv).
* Fixes ports that rolled their own do-build for calling ant instead of
using MODJAVA_BUILD=ant (2 got it correct, 2 got it wrong).

I will coordinate this commit with the jdk/1.8 u212 update and REVISION
bumps for all the java ports due to u212 removing the jre and the change
to java.port.mk here. 

Index: devel/jdk/java.port.mk
===
RCS file: /cvs/ports/devel/jdk/java.port.mk,v
retrieving revision 1.36
diff -u -p -r1.36 java.port.mk
--- devel/jdk/java.port.mk  28 Mar 2019 19:00:47 -  1.36
+++ devel/jdk/java.port.mk  5 Jun 2019 18:36:30 -
@@ -44,6 +44,8 @@ RUN_DEPENDS+= ${MODJAVA_RUN_DEPENDS}
 
 .if ${NO_BUILD:L} != "yes"
 BUILD_DEPENDS+= ${MODJAVA_BUILD_DEPENDS}
+CONFIGURE_ENV += JAVA_HOME=${JAVA_HOME}
+MAKE_ENV += JAVA_HOME=${JAVA_HOME}
 .endif
 
 # Append 'java' to the list of categories.
@@ -55,7 +57,6 @@ CATEGORIES+=  java
 # respectively.
 .if defined(MODJAVA_BUILD) && ${MODJAVA_BUILD:L} == "ant"
 BUILD_DEPENDS += devel/apache-ant
-MAKE_ENV += JAVA_HOME=${JAVA_HOME}
 MODJAVA_BUILD_TARGET_NAME ?=
 MODJAVA_BUILD_FILE ?= build.xml
 MODJAVA_BUILD_DIR ?= ${WRKSRC}
Index: games/jbrickshooter/Makefile
===
RCS file: /cvs/ports/games/jbrickshooter/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- games/jbrickshooter/Makefile24 Mar 2019 22:24:13 -  1.15
+++ games/jbrickshooter/Makefile5 Jun 2019 18:36:30 -
@@ -7,21 +7,21 @@ GH_PROJECT=   jbrickshooter
 GH_COMMIT= 0445d9171cc46462970ae8eb08f0c7294c5707df
 DISTNAME=  ${GH_PROJECT}-1.6.0
 CATEGORIES=games
-REVISION=  1
+REVISION=  2
 
 # GPLv3
 PERMIT_PACKAGE_CDROM=  Yes
 
 MODULES=   java
 MODJAVA_VER=   1.8+
+MODJAVA_BUILD= ant
 
-BUILD_DEPENDS= devel/apache-ant
 RUN_DEPENDS=   java/javaPathHelper
 
 NO_TEST=   Yes
 
-do-build:
-   cd ${WRKSRC} && mkdir -p build && ant build
+pre-build:
+   cd ${WRKSRC} && mkdir -p build
 
 do-install:
${SUBST_CMD} -m 555 -c ${FILESDIR}/jbrickshooter \
Index: games/lwjgl/Makefile
===
RCS file: /cvs/ports/games/lwjgl/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- games/lwjgl/Makefile24 Mar 2019 22:24:13 -  1.7
+++ games/lwjgl/Makefile5 Jun 2019 18:36:30 -
@@ -8,7 +8,7 @@ GH_PROJECT= lwjgl
 GH_TAGNAME=${GH_PROJECT}${V}
 DISTNAME=  lwjgl${V}
 PKGNAME=   lwjgl-${V}
-REVISION=  1
+REVISION=  2
 
 .if ${MACHINE_ARCH} == "i386"
 M_ARCH=""
@@ -34,14 +34,10 @@ MODULES=java
 MODJAVA_VER=   1.8+
 MODJAVA_BUILD= ant
 
-BUILD_DEPENDS= audio/openal \
-   devel/apache-ant
+BUILD_DEPENDS= audio/openal
 
 NO_TEST=   Yes
 
-ANT_CMD=   ${SETENV} ${MAKE_ENV} PATH=${JAVA_HOME}/bin:${PATH} \
-   ${LOCALBASE}/bin/ant
-
 SUBST_VARS+=   M_ARCH
 
 pre-configure:
@@ -49,9 +45,6 @@ pre-configure:
${WRKSRC}/platform_build/bsd_ant/build.xml
perl -pi -e 's,/usr/local,${LOCALBASE},g' \
${WRKSRC}/platform_build/bsd_ant/build.xml
-
-do-build:
-   cd ${WRKSRC} && ${ANT_CMD}
 
 do-install:
${INSTALL_DATA_DIR} ${LWJGL_HOME}
Index: lang/jruby/Makefile
===
RCS file: /cvs/ports/lang/jruby/Makefile,v
retrieving revision 1.78
diff -u -p -r1.78 Makefile
--- lang/jruby/Makefile 18 May 2019 16:03:47 -  1.78
+++ lang/jruby/Makefile 5 Jun 2019 18:36:30 -
@@ -6,7 +6,7 @@ ONLY_FOR_ARCHS = amd64
 COMMENT =  pure-Java implementation of the Ruby language
 
 V =9.2.7.0
-REVISION = 0
+REVISION = 1
 DISTNAME = jruby-dist-${V}-bin
 PKGNAME =  jruby-${V}
 CATEGORIES =   lang lang/ruby
@@ -27,30 +27,28 @@ MASTER_SITES1 = ${MASTER_SITE_RUBYGEMS}
 
 MODULES =  java
 MODJAVA_VER =  1.8+

Re: py-decorator: update to 4.4.0

2019-06-06 Thread Daniel Jakots 
On Fri, 7 Jun 2019 00:24:58 +0100, Stuart Henderson
 wrote:

> > > Does anyone want to throw this into a bulk?  
> > 
> > Honestly I don't think a bulk is needed for such a port, I don't
> > know why s-r-d says that. Your call.  
> 
> generally I think s-r-d is more useful for "how much trouble might
> i be in if i break this" rather than "what do i need to test".

Totally agreed.

I did run at my good ol' showvictims.py before saying the above ;)

Re: py-decorator: update to 4.4.0

2019-06-06 Thread Stuart Henderson 
On 2019/06/06 15:38, Daniel Jakots wrote:
> On Thu, 6 Jun 2019 21:06:16 +0200, Klemens Nanni  wrote:
> 
> > Simple update required for another port I'm working on, which is happy
> > with this version.
> > 
> > Other than that, regress continues to pass on amd64 but it did not
> > test any other consumer:
> > 
> > $ show-reverse-deps devel/py-decorator | wc -l
> > 7482
> 
> haha
> 
> > Does anyone want to throw this into a bulk?
> 
> Honestly I don't think a bulk is needed for such a port, I don't know
> why s-r-d says that. Your call.

probably need to strip down the sql query and split it into pieces to
figure out all of "why" in this case, but note s-r-d includes test
dependencies, and it acts recursively. I *think* it will list a port
if some port in its dependency chain has the port you're searching
for as a TEST_DEPENDS.

generally I think s-r-d is more useful for "how much trouble might
i be in if i break this" rather than "what do i need to test".

sqlite> select distinct fullpkgpath from depends where dependspath like 
'devel/py-decorator%';
databases/py-sqlalchemy-migrate
databases/py-sqlalchemy-migrate,python3
devel/ipython
devel/ipython,python3
devel/py-addons
devel/py-bytecodeassembler
devel/py-peak-rules
devel/py-protocols
devel/py-traitlets
devel/py-traitlets,python3
www/py-httpbin
www/py-httpbin,python3
www/py-mastodon.py
www/py-mastodon.py,python3
www/py-pylons

or,

$ ls -l /usr/ports/INDEX
lrwxr-xr-x  1 sthen  _pbuild  28 Nov 20  2018 /usr/ports/INDEX -> 
/usr/local/share/ports-INDEX

$ grep -w devel/py-decorator /usr/ports/INDEX | cut -d'|' -f2
databases/py-sqlalchemy-migrate
databases/py-sqlalchemy-migrate,python3
devel/ipython
devel/ipython,python3
devel/py-decorator
devel/py-decorator,python3
devel/py-traitlets
devel/py-traitlets,python3
www/py-httpbin
www/py-httpbin,python3
www/py-mastodon.py
www/py-mastodon.py,python3
www/py-pylons

you can write that to a file and feed it to SUBDIRLIST:

$ grep -w devel/py-decorator /usr/ports/INDEX | cut -d'|' -f2 > 
/tmp/plist.decorator
$ cd /usr/ports; make SUBDIRLIST=/tmp/plist.decorator package

etc.

Re: OpenMP for both clang and GCC, part II

2019-06-06 Thread Stuart Henderson 
On 2019/06/06 11:13, j...@bitminer.ca wrote:
> 
> 
> On 2019-06-06 08:04, Stuart Henderson wrote:
> > On 2019/06/05 16:42, j...@bitminer.ca wrote:
> > > Users will adopt flavors such as -withopenmp, or -noopenmp, as they
> > > become
> > > available.
> > 
> > Flavours are often a bad idea, testing becomes more complicated,
> > especially for ports which are part of chains of dependencies. I think
> > they should probably be avoided for this.
> 
> That would be good advice for future changes to existing ports.
> 
> > 
> > > Some issues and questions:
> > > 
> > > - this will work for amd64, but will it work for arm64, sparc? Others?
> > > - should the flavors be -withopenmp or -noopenmp?
> > > - how to successfully detect 90% or more of ports with hidden OpenMP
> > > support?
> > >   I will do this and am looking for advice on how best to approach it.
> > >   Any pre-existing info would be very welcome.
> > 
> > It would be helpful to see examples of what sort of improvement can be
> > expected on OpenBSD before deciding if it's worth the trouble to
> > integrate
> > into ports (which is an ongoing thing, not just one-off work).
> 
> 
> My own motivation is not ports but specifically clang/flang and gcc with
> OpenMP enabled. And maybe Octave. Initially I started to suggest a general
> implementation, thinking this wasn't too hard to also update a few
> packagesoops.
> 
> Improvement would be measured how?  By number of supporting ports, or
> number of frequently used numerically intensive ports (such as audio, video,
> or math tools)?  I'd rather not judge and just try to give users options.

I'm thinking more at a very basic level for now: e.g. whether these
programs actually run any faster on OpenBSD when OpenMP is used.

> Forcing OpenMP disabled on most ports is obeying the principle of least
> surprise.  Ongoing work would be selectively enabling it.  And documenting
> how to control the number of threads.

Other ongoing work would be remembering that this is a thing and making
sure it's disabled where needed in new ports. (The worst case is if it
gets picked up and used at build time if the runtime is present and
produces a package that needs the runtime to work, but is otherwise
not very identifiable until someone tries to run the package on a
machine without the runtime.)

> The list of ports explicitly disabling openmp, and consumers of their shared
> libraries is a little surprising (emacs anyone?).  Here is the list,
> approximately, to one level deep:

It's disabled in a few things where it was noticed (usually by reviewing
lists of options in configure --help or in build log), but I don't think
there has been much concerted effort to disable it throughout the tree.
bcallah made a start at this but IIRC only did a few categories.

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Klemens Nanni 
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2019/06/06 16:37:09

Modified files:
math   : Makefile 

Log message:
py-networkx has no flavors

Noticed by naddy

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Edd Barrett 
CVSROOT:/cvs
Module name:ports
Changes by: e...@cvs.openbsd.org2019/06/06 15:53:38

Modified files:
editors/neovim : Tag: OPENBSD_6_5 Makefile 
Added files:
editors/neovim/patches: Tag: OPENBSD_6_5 
patch-src_nvim_getchar_c 

Log message:
editors/neovim: backport arbitrary code execution fix to 6.5-stable.

Source command doesn't check for the sandbox.
https://github.com/neovim/neovim/pull/10082

Detailed description:
https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md

OK sthen@

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Christian Weisgerber 
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2019/06/06 15:09:17

Modified files:
net/curl   : Makefile distinfo 

Log message:
Update to 7.65.1.  No known security fixes.

Re: UPDATE: audio/hydrogen

2019-06-06 Thread Raphael Graf 
On Tue, May 07, 2019 at 02:57:35PM -0400, Jeremie Courreges-Anglas wrote:
> On Mon, May 06 2019, Raphael Graf  wrote:
> > On Sun, May 05, 2019 at 01:46:48PM +0200, Jeremie Courreges-Anglas wrote:
> >> On Sun, May 05 2019, Raphael Graf  wrote:
> >> > Here is an update to hydrogen-0.9.7.
> >> >
> >> > Notable changes:
> >> > - Uses cmake instead of scons.
> >> > - There is a shared library and three additional command-line binaries.
> >> > - Enabled support for audio/ladspa plugins
> >> >
> >> > New features are listed here:
> >> > http://hydrogen-music.org/
> >> >
> >> > Comments/tests welcome.
> >> 
> >> Here's some nitpicking about the Makefile only.
> >> 
> >> > Index: Makefile
> >> > ===
> >> > RCS file: /cvs/ports/audio/hydrogen/Makefile,v
> >> > retrieving revision 1.25
> >> > diff -u -p -u -p -r1.25 Makefile
> >> > --- Makefile 8 Jan 2019 21:24:29 -   1.25
> >> > +++ Makefile 5 May 2019 10:55:31 -
> >> > @@ -1,58 +1,54 @@
> >> >  # $OpenBSD: Makefile,v 1.25 2019/01/08 21:24:29 sebastia Exp $
> >> >  
> >> > -COMMENT=software drum machine
> >> > +COMMENT =   software drum machine
> >> 
> >> Please avoid gratuitous whitespace changes like this, it makes cvs blame
> >> less useful for no real gain.  If you really care for consistency I'd
> >> suggest to tweak the COMPILER line instead.
> >
> > Ok, I've removed the whitespace changes from the diff.
> 
> Thanks.
> 
> >> 
> >> > -DISTNAME=   hydrogen-0.9.5
> >> > -CATEGORIES= audio
> >> > +DISTNAME =  hydrogen-0.9.7
> >> > +CATEGORIES =audio
> >> >  
> >> > -HOMEPAGE=   http://www.hydrogen-music.org/
> >> > +HOMEPAGE =  http://www.hydrogen-music.org/
> >> > +
> >> > +SHARED_LIBS =   hydrogen-core-0.9.7 0.0
> >> 
> >> I'm not saying it's a problem in practice, but this library name looks
> >> suspicious...
> >
> > Yes, it is a strange name, I don't think it is a real problem though.
> > Something like the following could be done to change the name:
> >
> > pre-configure:
> > sed -i 's,hydrogen-core-$${VERSION},hydrogen-core,g' \
> > ${WRKSRC}/src/*/CMakeLists.txt
> >
> > Do you think this is worthwhile?
> 
> No, I just found the naming weird.
> 
> >> 
> >> >  # GPLv2
> >> > -PERMIT_PACKAGE_CDROM=   Yes
> >> > +PERMIT_PACKAGE_CDROM =  Yes
> >> >  
> >> > -WANTLIB += ${COMPILER_LIBCXX} QtGui QtNetwork QtXml archive c
> >> > -WANTLIB += jack lrdf m ogg sndfile sndio
> >> > +WANTLIB += ${COMPILER_LIBCXX} QtGui QtNetwork QtXml QtXmlPatterns 
> >> > archive c
> >> > +WANTLIB += lrdf m sndfile sndio z
> >> >  
> >> > -MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=hydrogen/}
> >> > +MASTER_SITES =  ${MASTER_SITE_SOURCEFORGE:=hydrogen/}
> >> >  
> >> >  COMPILER =  base-clang ports-gcc base-gcc
> >> >  
> >> > -LIB_DEPENDS=audio/libsndfile \
> >> > -audio/flac \
> >> > -audio/jack \
> >> > +LIB_DEPENDS =   audio/libsndfile \
> >> >  archivers/libarchive \
> >> >  textproc/liblrdf
> >> >  
> >> > -RUN_DEPENDS=devel/desktop-file-utils
> >> > +BUILD_DEPENDS = audio/ladspa
> >> > +
> >> > +RUN_DEPENDS =   devel/desktop-file-utils
> >> >  
> >> > -MODULES=x11/qt4 devel/scons
> >> > +MODULES =   devel/cmake x11/qt4
> >> 
> >> I would suggest splitting MODULES over multiple lines.
> >
> > done
> >
> >> 
> >> Note: looks like hydrogen-1.0.0 will support Qt5.
> >
> > Yes, I already have a (working but incomplete) diff for 1.0.0-beta1.
> > It will need some more work on the midi part to support the new
> > midi feedback feature. 
> 
> ack.  Ports-wise this update looks good, except for a hidden dep on
> cppunit, used to build src/tests/tests.
> 
> --8<--
> russell /usr/ports/pobj/hydrogen-0.9.7/build-amd64$ src/tests/tests
> QCoreApplication::applicationDirPath: Please instantiate the QApplication 
> object first
> assertion "__instance" failed: file 
> "/usr/ports/pobj/hydrogen-0.9.7/hydrogen-0.9.7/src/core/include/hydrogen/Preferences.h",
>  line 238, function "get_instance"
> Abort trap
> -->8--
> 
> So ok jca@ ports-wise if you add devel/cppunit to BUILD_DEPENDS (not
> TEST_DEPENDS).  Good luck if you want to fix tests. :)

Instead of adding the dependency on cppunit, we can also disable building the
tests by adding -DWANT_CPPUNIT=OFF to CONFIGURE_ARGS (diff below).
(I plan to enable the tests in the next update, they do work in 1.0.0-beta)

ok?

> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 
Index: Makefile
===
RCS file: /cvs/ports/audio/hydrogen/Makefile,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 Makefile
--- Makefile8 Jan 2019 21:24:29 -

patch to support OpenMP in gcc

2019-06-06 Thread j 
Hi ports,

This patch to devel/gcc/8 adds OpenMP support mostly by including
files in the gcc-libs subpackage.  It does not conflict with the
clang libomp package I published earlier today.

Tested on amd64.


Index: 8/Makefile
===
RCS file: /cvs/ports/lang/gcc/8/Makefile,v
retrieving revision 1.14
diff -u -p -u -r1.14 Makefile
--- 8/Makefile  20 May 2019 14:59:05 -  1.14
+++ 8/Makefile  3 Jun 2019 00:08:34 -
@@ -1,4 +1,4 @@
-# $OpenBSD: Makefile,v 1.14 2019/05/20 14:59:05 pascal Exp $
+# $OpenBSD: Makefile,v 1.13 2019/05/01 12:12:24 sthen Exp $
 
 ONLY_FOR_ARCHS = \
aarch64 alpha amd64 arm hppa i386 mips64 mips64el powerpc sparc64
@@ -16,7 +16,7 @@ USE_LLD = No
 DPB_PROPERTIES = parallel
 
 V = 8.3.0
-REVISION = 1
+REVISION = 2
 FULL_VERSION = $V
 FULL_PKGVERSION = $V
 
@@ -56,6 +56,7 @@ SHARED_LIBS = estdc++ 19.0 \
lto_plugin  5.0 \
itm 4.0 \
atomic  3.0 \
+   gomp1.0 \
quadmath3.0 \
cc1 1.0 \
cc1plugin   1.0 \
@@ -137,7 +138,6 @@ CONFIGURE_ARGS += \
--disable-nls  \
--with-system-zlib \
--disable-libmudflap \
-   --disable-libgomp \
--disable-libssp \
--disable-tls \
--with-gnu-ld \
Index: 8/pkg/PLIST-f95
===
RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-f95,v
retrieving revision 1.2
diff -u -p -u -r1.2 PLIST-f95
--- 8/pkg/PLIST-f95 27 Apr 2019 21:26:35 -  1.2
+++ 8/pkg/PLIST-f95 3 Jun 2019 00:08:34 -
@@ -11,6 +11,9 @@ lib/gcc/${CONFIG}/${V}/finclude/
 lib/gcc/${CONFIG}/${V}/finclude/ieee_arithmetic.mod
 lib/gcc/${CONFIG}/${V}/finclude/ieee_exceptions.mod
 lib/gcc/${CONFIG}/${V}/finclude/ieee_features.mod
+lib/gcc/${CONFIG}/${V}/finclude/omp_lib_kinds.mod
+lib/gcc/${CONFIG}/${V}/finclude/omp_lib.mod
+lib/gcc/${CONFIG}/${V}/finclude/omp_lib.h
 lib/gcc/${CONFIG}/${V}/libcaf_single.a
 lib/gcc/${CONFIG}/${V}/libcaf_single.la
 lib/libgfortran.a
Index: 8/pkg/PLIST-libs
===
RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-libs,v
retrieving revision 1.2
diff -u -p -u -r1.2 PLIST-libs
--- 8/pkg/PLIST-libs27 Apr 2019 21:26:35 -  1.2
+++ 8/pkg/PLIST-libs3 Jun 2019 00:08:34 -
@@ -13,5 +13,9 @@ lib/libobjc.la
 @lib lib/libobjc.so.${LIBobjc_VERSION}
 lib/libcc1.la
 @lib lib/libcc1.so.${LIBcc1_VERSION}
+lib/libgomp.la
+@lib lib/libgomp.so.${LIBgomp_VERSION}
+lib/libgomp.a
+lib/libgomp.spec
 %%ITM%%
 %%QUADMATH%%
Index: 8/pkg/PLIST-main
===
RCS file: /cvs/ports/lang/gcc/8/pkg/PLIST-main,v
retrieving revision 1.2
diff -u -p -u -r1.2 PLIST-main
--- 8/pkg/PLIST-main27 Apr 2019 21:26:35 -  1.2
+++ 8/pkg/PLIST-main3 Jun 2019 00:08:34 -
@@ -29,6 +29,7 @@ lib/gcc/${CONFIG}/${V}/include-fixed/REA
 lib/gcc/${CONFIG}/${V}/include-fixed/limits.h
 lib/gcc/${CONFIG}/${V}/include-fixed/syslimits.h
 lib/gcc/${CONFIG}/${V}/include/gcov.h
+lib/gcc/${CONFIG}/${V}/include/omp.h
 lib/gcc/${CONFIG}/${V}/include/stdalign.h
 lib/gcc/${CONFIG}/${V}/include/stdatomic.h
 lib/gcc/${CONFIG}/${V}/include/stdfix.h

NEW: devel/libomp

2019-06-06 Thread j 

This is the LLVM support library for OpenMP.  Both clang and flang
support -fopenmp, and this is the library that makes it work.

This is a minor rework (including a rename) of a package first published
by Brian Callahan.

Note: with this present, some package builds will automatically
build for OpenMP because cmake (at least) can automatically discover
it.


$ cat pkg/DESCR
The OpenMP subproject of LLVM contains the components required to build
an executable OpenMP program that are outside the C or Fortran 
compilers.





openmp.tgz
Description: GNU Zip compressed data

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Klemens Nanni 
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2019/06/06 14:19:44

Modified files:
math   : Makefile 

Log message:
+ py-networkx

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Klemens Nanni 
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2019/06/06 14:18:59

Log message:
Import py-networkx 2.3

NetworkX is a Python package for the creation, manipulation,
and study of the structure, dynamics, and functions
of complex networks.

Feedback and OK jasper

Status:

Vendor Tag: kn
Release Tags:   kn_20190606

N ports/math/py-networkx/Makefile
N ports/math/py-networkx/distinfo
N ports/math/py-networkx/pkg/DESCR
N ports/math/py-networkx/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Klemens Nanni 
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2019/06/06 14:16:39

Modified files:
devel  : Makefile 

Log message:
+ py-cachetools

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Klemens Nanni 
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2019/06/06 14:02:50

Log message:
Import py-cachetools 3.1.1

This module provides various memoizing collections and decorators,
including variants of the Python 3 Standard Library `@lru_cache`_
function decorator.

Feedback and OK jasper

Status:

Vendor Tag: kn
Release Tags:   kn_20190606

N ports/devel/py-cachetools/Makefile
N ports/devel/py-cachetools/distinfo
N ports/devel/py-cachetools/pkg/DESCR
N ports/devel/py-cachetools/pkg/PLIST

No conflicts created by this import

[ports-gcc] Unbreak astro/celestia (was Re: powerpc bulk build report)

2019-06-06 Thread Charlene Wendling 
On Thu, 6 Jun 2019 09:27:07 -0600 (MDT)
lan...@openbsd.org wrote:

> http://build-failures.rhaalovely.net//powerpc/2019-05-19/astro/celestia.log

This one is easy - it's a (static) bool method, and ports-gcc doesn't
want NULL as a return value. It's the only problem there was, it builds
without issues [0] on macppc and amd64.

While here i've moved HOMEPAGE to https.

The runtime is good as well - notably colors aren't off :)

Charlène


[0] http://0x0.st/zuNH.txt


Index: Makefile
===
RCS file: /cvs/ports/astro/celestia/Makefile,v
retrieving revision 1.47
diff -u -p -u -p -r1.47 Makefile
--- Makefile20 May 2019 22:15:00 -  1.47
+++ Makefile6 Jun 2019 18:57:22 -
@@ -3,11 +3,11 @@
 COMMENT=   free space simulator and planetarium
 
 DISTNAME=  celestia-1.6.1
-REVISION=  17
+REVISION=  18
 
 CATEGORIES=astro x11
 
-HOMEPAGE=  http://www.shatters.net/celestia/
+HOMEPAGE=  https://celestia.space/
 
 MAINTAINER=Antoine Jacoutot 
 
Index: patches/patch-src_celengine_parseobject_cpp
===
RCS file: patches/patch-src_celengine_parseobject_cpp
diff -N patches/patch-src_celengine_parseobject_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_celengine_parseobject_cpp 6 Jun 2019 18:57:22 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+ports-gcc fix for:
+parseobject.cpp:280:10: error: converting to 'bool' from 'std::nullptr_t'
+requires direct-initialization 
+
+Index: src/celengine/parseobject.cpp
+--- src/celengine/parseobject.cpp.orig
 src/celengine/parseobject.cpp
+@@ -277,7 +277,7 @@ ParseStringList(Hash* table,
+ {
+   Value* v = table->getValue(propertyName);
+   if (v == NULL)
+-  return NULL;
++  return false;
+ 
+   // Check for a single string first.
+   if (v->getType() == Value::StringType)

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Klemens Nanni 
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2019/06/06 13:48:25

Modified files:
devel/py-decorator: Makefile distinfo 

Log message:
Update to py-decorator 4.4.0

See https://github.com/micheles/decorator/blob/master/CHANGES.md for
various fixes since 4.0.11.

Note on broken HOMEPAGE and OK danj

Re: py-decorator: update to 4.4.0

2019-06-06 Thread Klemens Nanni 
On Thu, Jun 06, 2019 at 03:38:21PM -0400, Daniel Jakots wrote:
> HOMEPAGE seems to be broken, can you remove it (or put something that
> works)?
Removed it to use the PyPi default, cheers.

Re: py-decorator: update to 4.4.0

2019-06-06 Thread Daniel Jakots 
On Thu, 6 Jun 2019 21:06:16 +0200, Klemens Nanni  wrote:

> Simple update required for another port I'm working on, which is happy
> with this version.
> 
> Other than that, regress continues to pass on amd64 but it did not
> test any other consumer:
> 
>   $ show-reverse-deps devel/py-decorator | wc -l
>   7482

haha

> Does anyone want to throw this into a bulk?

Honestly I don't think a bulk is needed for such a port, I don't know
why s-r-d says that. Your call.

> Feedback? OK?

HOMEPAGE seems to be broken, can you remove it (or put something that
works)?

with that, ok danj@

Cheers,
Daniel

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Charlene Wendling 
CVSROOT:/cvs
Module name:ports
Changes by: c...@cvs.openbsd.org2019/06/06 13:36:52

Modified files:
net/freeradius3: Makefile 

Log message:
freeradius3: unbreak the build on powerpc: it requires atomics.
While here, refresh WANTLIB for the -mysql subpackage.

OK sthen@ (maintainer)

py-decorator: update to 4.4.0

2019-06-06 Thread Klemens Nanni 
Simple update required for another port I'm working on, which is happy
with this version.

Other than that, regress continues to pass on amd64 but it did not test
any other consumer:

$ show-reverse-deps devel/py-decorator | wc -l
7482

Does anyone want to throw this into a bulk?

Feedback? OK?

Index: Makefile
===
RCS file: /cvs/ports/devel/py-decorator/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile13 May 2019 18:06:43 -  1.20
+++ Makefile6 Jun 2019 18:59:30 -
@@ -2,10 +2,9 @@
 
 COMMENT =  simplify usage of decorators
 
-MODPY_EGG_VERSION =4.0.11
+MODPY_EGG_VERSION =4.4.0
 DISTNAME = decorator-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
-REVISION = 1
 
 CATEGORIES =   devel
 
Index: distinfo
===
RCS file: /cvs/ports/devel/py-decorator/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo19 Jan 2017 20:22:49 -  1.11
+++ distinfo6 Jun 2019 18:59:48 -
@@ -1,2 +1,2 @@
-SHA256 (decorator-4.0.11.tar.gz) = lT1r8IKxAPQyKc9Uf0+X+X6XD1rWRe52AdVf+Hr9/nY=
-SIZE (decorator-4.0.11.tar.gz) = 70616
+SHA256 (decorator-4.4.0.tar.gz) = hhVjYcUEiLhKPxSAVupxbKWH3y8N4dNHUNNcITEnJd4=
+SIZE (decorator-4.4.0.tar.gz) = 34559

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Brian Callahan 
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2019/06/06 12:29:47

Modified files:
games/freedink/game: Makefile 

Log message:
FreeDink requires COMPILER=base-clang ports-gcc because the C++ invocation
include -std=c++11. Noticed from the latest macppc bulk logs.

[macppc] net/freeradius3 now requires atomics

2019-06-06 Thread Charlene Wendling 
Hi ports, Stuart,

Freeradius is broken with ports-gcc on macppc. It's a classic: 

> /usr/ports/pobj/freeradius-server-3.0.19/freeradius-server-3.0.19/build/lib/local/.libs/libfreeradius-radius.so:
>  undefined reference to `__atomic_store_8'
> /usr/ports/pobj/freeradius-server-3.0.19/freeradius-server-3.0.19/build/lib/local/.libs/libfreeradius-radius.so:
>  undefined reference to `__atomic_load_8'
> /usr/ports/pobj/freeradius-server-3.0.19/freeradius-server-3.0.19/build/lib/local/.libs/libfreeradius-radius.so:
>  undefined reference to `__atomic_compare_exchange_8'

As such i added the infamous block to the Makefile (all subpackages 
need it) and, while here, port-lib-depends-check asked for the 
mariadb^W mysql subpackage a WANTLIB update, so i did it. 

Once done, it builds fine on macppc [0], and on amd64 as well.

Comments/feedback are welcome! 

Charlène.


[0] http://0x0.st/zuZ8.txt


Index: Makefile
===
RCS file: /cvs/ports/net/freeradius3/Makefile,v
retrieving revision 1.39
diff -u -p -u -p -r1.39 Makefile
--- Makefile3 Jun 2019 16:06:53 -   1.39
+++ Makefile6 Jun 2019 17:11:59 -
@@ -14,6 +14,7 @@ COMMENT-python=   freeradius python rlm ad
 V= 3.0.19
 DISTNAME=  freeradius-server-$V
 EXTRACT_SUFX=  .tar.bz2
+REVISION=  0
 
 PKGNAME-main=  freeradius-$V
 PKGNAME-freetds= freeradius-freetds-$V
@@ -146,7 +147,7 @@ CONFIGURE_ARGS+=--with-mysql-include-di
 CONFIGURE_ARGS+=   --without-rlm_sql_mysql
 .endif
 LIB_DEPENDS-mysql= databases/mariadb
-WANTLIB-mysql= crypto ssl m pthread z mysqlclient_r
+WANTLIB-mysql= crypto iconv m mariadb ssl z
 RUN_DEPENDS-mysql= #empty
 
 # rlm_sql_postgresql
@@ -170,6 +171,13 @@ SUBST_VARS=FREERADIUS_ETC
 MAKE_FLAGS=PACKAGE=openbsd VERBOSE=1
 FAKE_FLAGS=VERBOSE=1 R=${WRKINST} \
raddbdir=${PREFIX}/share/examples/freeradius
+
+.if ${MACHINE_ARCH} == "powerpc"
+LDFLAGS += -latomic
+.for i in ${MULTI_PACKAGES}
+WANTLIB$i +=   atomic
+.endfor
+.endif
 
 post-configure:
sed -i -e 's,/etc/raddb,${SYSCONFDIR}/raddb,g' ${WRKSRC}/man/*/*

Re: OpenMP for both clang and GCC, part II

2019-06-06 Thread j 




On 2019-06-06 08:04, Stuart Henderson wrote:

On 2019/06/05 16:42, j...@bitminer.ca wrote:
Users will adopt flavors such as -withopenmp, or -noopenmp, as they 
become

available.


Flavours are often a bad idea, testing becomes more complicated,
especially for ports which are part of chains of dependencies. I think
they should probably be avoided for this.


That would be good advice for future changes to existing ports.




Some issues and questions:

- this will work for amd64, but will it work for arm64, sparc? Others?
- should the flavors be -withopenmp or -noopenmp?
- how to successfully detect 90% or more of ports with hidden OpenMP 
support?

  I will do this and am looking for advice on how best to approach it.
  Any pre-existing info would be very welcome.


It would be helpful to see examples of what sort of improvement can be
expected on OpenBSD before deciding if it's worth the trouble to 
integrate

into ports (which is an ongoing thing, not just one-off work).



My own motivation is not ports but specifically clang/flang and gcc with
OpenMP enabled. And maybe Octave. Initially I started to suggest a 
general
implementation, thinking this wasn't too hard to also update a few 
packagesoops.


Improvement would be measured how?  By number of supporting ports, or
number of frequently used numerically intensive ports (such as audio, 
video,
or math tools)?  I'd rather not judge and just try to give users 
options.


Forcing OpenMP disabled on most ports is obeying the principle of least
surprise.  Ongoing work would be selectively enabling it.  And 
documenting

how to control the number of threads.

The list of ports explicitly disabling openmp, and consumers of their 
shared

libraries is a little surprising (emacs anyone?).  Here is the list,
approximately, to one level deep:

sqlite> select w.fullpkgpath, w.value, s.fullpkgpath as src
   ...> from wantlib w, shared_libs s
   ...> where s.libname = w.value
   ...> and w.value in (
   ...>   select libname from shared_libs where fullpkgpath in (
   ...> select fullpkgpath from configureargs where value like 
'%openmp%'

   ...>   and not value like '%openmpt%' )
   ...> )
   ...> ;
FullPkgPath|Value|src
comms/xastir|GraphicsMagick|graphics/GraphicsMagick
databases/virtuoso|MagickCore-6.Q16|graphics/ImageMagick
databases/virtuoso|MagickWand-6.Q16|graphics/ImageMagick
editors/emacs|MagickCore-6.Q16|graphics/ImageMagick
editors/emacs,gtk3|MagickCore-6.Q16|graphics/ImageMagick
editors/emacs|MagickWand-6.Q16|graphics/ImageMagick
editors/emacs,gtk3|MagickWand-6.Q16|graphics/ImageMagick
editors/emacs,gtk2|MagickCore-6.Q16|graphics/ImageMagick
editors/emacs,gtk2|MagickWand-6.Q16|graphics/ImageMagick
emulators/mgba,-qt|MagickCore-6.Q16|graphics/ImageMagick
emulators/mgba,-qt|MagickWand-6.Q16|graphics/ImageMagick
emulators/mgba|MagickCore-6.Q16|graphics/ImageMagick
emulators/mgba,-main|MagickCore-6.Q16|graphics/ImageMagick
emulators/mgba|MagickWand-6.Q16|graphics/ImageMagick
emulators/mgba,-main|MagickWand-6.Q16|graphics/ImageMagick
graphics/darktable|GraphicsMagick|graphics/GraphicsMagick
graphics/digikam|Magick++-6.Q16|graphics/ImageMagick
graphics/digikam-kde4,-kipi|MagickCore-6.Q16|graphics/ImageMagick
graphics/dmtx-utils|MagickCore-6.Q16|graphics/ImageMagick
graphics/dmtx-utils|MagickWand-6.Q16|graphics/ImageMagick
graphics/inkscape|Magick++-6.Q16|graphics/ImageMagick
graphics/inkscape|MagickCore-6.Q16|graphics/ImageMagick
graphics/inkscape|MagickWand-6.Q16|graphics/ImageMagick
graphics/pdf2djvu|GraphicsMagick|graphics/GraphicsMagick
graphics/pdf2djvu|GraphicsMagick++|graphics/GraphicsMagick
graphics/pecl-imagick,php71|MagickCore-6.Q16|graphics/ImageMagick
graphics/pecl-imagick,php71|MagickWand-6.Q16|graphics/ImageMagick
graphics/pecl-imagick,php72|MagickCore-6.Q16|graphics/ImageMagick
graphics/pecl-imagick,php72|MagickWand-6.Q16|graphics/ImageMagick
graphics/pecl-imagick,php73|MagickCore-6.Q16|graphics/ImageMagick
graphics/pecl-imagick,php73|MagickWand-6.Q16|graphics/ImageMagick
graphics/ruby-rmagick,ruby25|MagickCore-6.Q16|graphics/ImageMagick
graphics/ruby-rmagick,ruby25|MagickWand-6.Q16|graphics/ImageMagick
graphics/ruby-rmagick,ruby26|MagickCore-6.Q16|graphics/ImageMagick
graphics/ruby-rmagick,ruby26|MagickWand-6.Q16|graphics/ImageMagick
graphics/sk1|MagickCore-6.Q16|graphics/ImageMagick
graphics/sk1|MagickWand-6.Q16|graphics/ImageMagick
graphics/zbar|MagickCore-6.Q16|graphics/ImageMagick
graphics/zbar|MagickWand-6.Q16|graphics/ImageMagick
math/octave|GraphicsMagick|graphics/GraphicsMagick
math/octave|GraphicsMagick++|graphics/GraphicsMagick
multimedia/dvdauthor|MagickCore-6.Q16|graphics/ImageMagick
multimedia/imagination|sox|audio/sox
multimedia/mlt|sox|audio/sox
multimedia/mlt,-main|sox|audio/sox
multimedia/mlt,,-main|sox|audio/sox
multimedia/synfig|Magick++-6.Q16|graphics/ImageMagick
multimedia/synfig|MagickCore-6.Q16|graphics/ImageMagick
multimedia/synfig|MagickWand-6.Q16|graphics/ImageMagick

Re: [UPDATE] devel/openmpi 4.0.1

2019-06-06 Thread Martin Reindl 
On Sat, Jun 01, 2019 at 08:03:17PM +0100, Stuart Henderson wrote:
> That needs fixing then..
> --
> Sent from a phone, apologies for poor formatting.
>
> On 1 June 2019 17:15:19 Jeremie Courreges-Anglas  wrote:
>
> > On Sat, Jun 01 2019, Stuart Henderson  wrote:
> > > Please don't do the huge bump for SHARED_LIBS, just a standard major
> > > bump for the existing libraries and start the new ones at 0.0
> >
> > IIRC the problem is that SHARED_LIBS isn't respected.
> >

Here is a polished version of the diff which should pass strict inspection
by the ports@ team:

- respects SHARED_LIBS by using base libtool, m4 from devel/libtool and -ltdl
- c++ interface is deprecated and not enabled in contrast to 1.0.4
- now uses SEPERATE-BUILD
- passes make test on macppc, arm64 and amd64 and schedules jobs on virtual
  amd64 mini-mpi-cluster
- now uses egfortran from ports-gcc instead of f77
- tidy up Makefile a bit so things look more in order for me


Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 Makefile
--- Makefile21 Jan 2019 14:24:30 -  1.26
+++ Makefile6 Jun 2019 12:54:33 -
@@ -1,52 +1,49 @@
 # $OpenBSD: Makefile,v 1.26 2019/01/21 14:24:30 jca Exp $
 
-BROKEN-hppa =  error: Could not determine global symbol label prefix
-BROKEN-powerpc =   checking if Fortran 77 compiler works... no
+COMMENT =  open source MPI-3.1 implementation
 
-COMMENT =  open source MPI-2 implementation
-
-V= 1.4.1
+V= 4.0.1
 DISTNAME = openmpi-$V
-REVISION = 8
-
-SHARED_LIBS =  mca_common_sm 1.0 \
-   mpi 0.1 \
-   mpi_cxx 0.0 \
-   mpi_f77 0.0 \
-   open-pal 0.0 \
-   open-rte 0.0
 
 CATEGORIES =   devel
 
+MASTER_SITES = 
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
+
 HOMEPAGE = http://www.open-mpi.org/
 
-MODULES =  fortran
-MODFORTRAN_COMPILER =  g77
-BUILD_DEPENDS +=   ${MODFORTRAN_BUILD_DEPENDS}
+MAINTAINER =   Martin Reindl 
 
 # BSD
 PERMIT_PACKAGE_CDROM = Yes
 
-WANTLIB+=  c m pthread ${COMPILER_LIBCXX} util z
+SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
+SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
+SHARED_LIBS +=  mca_common_ompio  0.0 # 60.1
+SHARED_LIBS +=  mca_common_sm 2.0 # 60.0
+SHARED_LIBS +=  mpi   1.0 # 60.1
+SHARED_LIBS +=  mpi_mpifh 0.0 # 60.1
+SHARED_LIBS +=  mpi_usempi_ignore_tkr 0.0 # 60.0
+SHARED_LIBS +=  mpi_usempif08 0.0 # 60.0
+SHARED_LIBS +=  ompitrace 0.0 # 60.0
+SHARED_LIBS +=  open-pal  1.0 # 60.1
+SHARED_LIBS +=  open-rte  1.0 # 60.1
 
-COMPILER = base-clang ports-gcc base-gcc
+MODULES =  fortran
+MODFORTRAN_COMPILER =  gfortran
 
-MASTER_SITES = 
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
+BUILD_DEPENDS +=   devel/libtool,-ltdl
 
-# XXX: uses a locally modified libtool.
-USE_LIBTOOL =  No
+LIB_DEPENDS += devel/libexecinfo 
+
+WANTLIB+=  c m pthread util z
+WANTLIB += pciaccess execinfo 
+
+COMPILER = base-clang ports-gcc base-gcc
 
-FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/
 CONFIGURE_STYLE =  gnu
-CONFIGURE_ENV =F77=${MODFORTRAN_COMPILER}
 
-.include 
-.if ${PROPERTIES:Mclang}
-CONFIGURE_ARGS =   --disable-visibility
-.endif
-
-# openmpi's otfinfo conflicts with the one from texlive
-post-install:
-   mv ${PREFIX}/bin/otfinfo ${PREFIX}/bin/otfinfompi
+SEPARATE_BUILD =   yes
+
+FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/devel/openmpi/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo18 Jan 2015 03:13:19 -  1.3
+++ distinfo6 Jun 2019 12:54:33 -
@@ -1,2 +1,2 @@
-SHA256 (openmpi-1.4.1.tar.gz) = quq9IhjNxPEejgPhVTkQEpzIQw6TN2xANsqW/BoVubU=
-SIZE (openmpi-1.4.1.tar.gz) = 9960381
+SHA256 (openmpi-4.0.1.tar.gz) = 5V4hP+CaIUq58scirP2L97ObvBgA5LekZNON8V5wf1k=
+SIZE (openmpi-4.0.1.tar.gz) = 17513706
Index: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
===
RCS file: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
diff -N patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
--- patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc 11 Apr 2018 
22:49:40 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,145 +0,0 @@
-$OpenBSD:

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Edd Barrett 
CVSROOT:/cvs
Module name:ports
Changes by: e...@cvs.openbsd.org2019/06/06 10:35:41

Modified files:
editors/neovim : Makefile 
Added files:
editors/neovim/patches: patch-src_nvim_getchar_c 

Log message:
editors/neovim: Plug a abritrary code execution bug.

Source command doesn't check for the sandbox.
https://github.com/neovim/neovim/pull/10082

Detailed description:
https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md

OK sthen@, thanks!

Re: SECURITY: editors/neovim

2019-06-06 Thread Edd Barrett 
On Thu, Jun 06, 2019 at 05:26:13PM +0100, Stuart Henderson wrote:
> OK.

Thanks!

> I was just about to send you an 0.3.7 update diff for this after
> doing editors/vim :)

It's certainly welcome, if you've already started :)

> Definitely.

I'll get on to that.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: SECURITY: editors/neovim

2019-06-06 Thread Stuart Henderson 
On 2019/06/06 17:16, Edd Barrett wrote:
> Hi,
> 
> Here's a patch to fix a recently found arbitrary code execution bug in
> neovim. It affects regular vim too, so CC sthen@.
> 
> https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md
> 
> I was alerted to this by solene@ on mastodon. Thanks!

OK. I was just about to send you an 0.3.7 update diff for this after
doing editors/vim :)

> Maybe worth pushing to -stable too?

Definitely.

> (I see that there is a new neovim -- will port soon).
> 
> OK?
>

Re: SECURITY: editors/neovim

2019-06-06 Thread Edd Barrett 
On Thu, Jun 06, 2019 at 05:16:02PM +0100, Edd Barrett wrote:
> It affects regular vim too, so CC sthen@.

Excellent! Stuart has already patched vim today. The first time I hit
cvsweb it didn't show up, but after a refresh a little while later, I
see it ;)

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

SECURITY: editors/neovim

2019-06-06 Thread Edd Barrett 
Hi,

Here's a patch to fix a recently found arbitrary code execution bug in
neovim. It affects regular vim too, so CC sthen@.

https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md

I was alerted to this by solene@ on mastodon. Thanks!

Maybe worth pushing to -stable too?

(I see that there is a new neovim -- will port soon).

OK?


Index: Makefile
===
RCS file: /cvs/ports/editors/neovim/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile20 May 2019 22:15:08 -  1.15
+++ Makefile6 Jun 2019 15:32:31 -
@@ -5,7 +5,7 @@ COMMENT =   continuation and extension of 
 GH_ACCOUNT =   neovim
 GH_PROJECT =   neovim
 GH_TAGNAME =   v0.3.4
-REVISION = 0
+REVISION = 1
 
 CATEGORIES =   editors devel
 HOMEPAGE = http://neovim.org
Index: patches/patch-src_nvim_getchar_c
===
RCS file: patches/patch-src_nvim_getchar_c
diff -N patches/patch-src_nvim_getchar_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_nvim_getchar_c6 Jun 2019 15:52:58 -
@@ -0,0 +1,25 @@
+$OpenBSD$
+
+Security patch: Source command doesn't check for the sandbox.
+https://github.com/neovim/neovim/pull/10082
+
+Detailed description:
+https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md
+
+Index: src/nvim/getchar.c
+--- src/nvim/getchar.c.orig
 src/nvim/getchar.c
+@@ -1244,6 +1244,13 @@ openscript (
+ EMSG(_(e_nesting));
+ return;
+   }
++
++  // Disallow sourcing a file in the sandbox, the commands would be executed
++  // later, possibly outside of the sandbox.
++  if (check_secure()) {
++return;
++  }
++
+   if (ignore_script)
+ /* Not reading from script, also don't open one.  Warning message? */
+ return;

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Stuart Henderson 
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2019/06/06 09:58:30

Modified files:
devel/quirks   : Makefile 
devel/quirks/files: Quirks.pm 

Log message:
quirks cve thingy for vim, pointed out by danj@

powerpc bulk build report

2019-06-06 Thread landry 
bulk build on macppc-1.ports.openbsd.org
started on  Sun May 19 11:15:27 MDT 2019
finished at Thu Jun 6 09:25:19 MDT 2019
lasted 18D15h09m
done with kern.version=OpenBSD 6.5-current (GENERIC.MP) #520: Fri May 17 
06:19:47 MDT 2019

built packages:8656
May 19:421
May 20:819
May 21:481
May 22:248
May 23:340
May 24:250
May 25:264
May 26:251
May 27:273
May 28:249
May 29:277
May 30:370
May 31:251
Jun 1:273
Jun 2:340
Jun 3:416
Jun 4:345
Jun 5:1008
Jun 6:1779



critical path missing pkgs: 
http://build-failures.rhaalovely.net//powerpc/2019-05-19/summary.log

build failures: 73
http://build-failures.rhaalovely.net//powerpc/2019-05-19/astro/celestia.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/audio/audacious-plugins.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/audio/audacity.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/audio/chromaprint.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/audio/gradio.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/benchmarks/wrk.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/cad/gnucap.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/cad/magic.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/cad/netgen.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/databases/mariadb.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/devel/geany.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/devel/include-what-you-use.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/devel/leatherman.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/devel/llvm.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/devel/py-unicorn.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/devel/pycdc.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/devel/pygame,python3.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/devel/xtensa-elf/gcc.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/emulators/desmume.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/emulators/fs-uae.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/emulators/nestopia,-libretro.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/emulators/ppsspp.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/emulators/vbam.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/emulators/xnp2.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/games/dxx-rebirth.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/games/freedink/game.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/games/gargoyle.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/games/godot.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/games/maelstrom.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/games/mvdsv.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/games/widelands.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/games/xevil.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/geo/spatialite/gis.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/graphics/DevIL.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/graphics/dibuja.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/graphics/makehuman.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/graphics/ufraw.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/inputmethods/scim-fcitx.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/inputmethods/scim-hangul.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/inputmethods/scim-pinyin.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/inputmethods/scim-tables.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/lang/gprolog.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/lang/parrot.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/lang/php/7.3.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/math/mlpack,-main.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/misc/openbabel.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/dleyna/renderer.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/dleyna/server.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/fastnetmon.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/libvncserver.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/megatools.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/mutella.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/seafile/libsearpc.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/toxcore.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/net/wireguard-tools.log
http://build-failures.rhaalovely.net//powerpc/2019-05-19/productivity/ledger.log

Re: OpenBSD maintainers Spring cleaning

2019-06-06 Thread Ingo Schwarze 
Hi Renaud,

Renaud Allard wrote on Thu, Jun 06, 2019 at 07:47:24AM +0200:

> I was also reluctant at answering because I didn't know the mail
> address from the sender.

In addition to what sthen@ said:  if you receive an email message
claiming to be *from an OpenBSD developer* and suspect a phishing
attempt for whatever reason, you can always reply to the @openbsd.org
address (in this case danj@) even when Reply-To: is not set.  If it
was not phishing - perfect, from the reply, you now know the other
address is genuine, too.  If it was phishing, the developer is likely
interested to learn that somebody is trying to impersonate them.

Either way, you should *really* reply to mail about your ports (as
opposed to obvious spam, of course), even when you suspect some
kind of phishing.  A maintainer address is publicly advertised on
the Internet anyway, so there is no point in trying to hide the
fact from spammers that you do indeed reed incoming mail.  Better
answer once to a spammer by mistake than ignore a user asking a
genuine question about your port.

Yours,
  Ingo

P.S.
You see, me too, i'm typically sending From: a non-OpenBSD address
without setting Reply-To: - because direct replies are faster.
But there is certainly nothing wrong with writing to schwarze@,
many people do that.

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Stuart Henderson 
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2019/06/06 09:04:55

Modified files:
editors/vim: Tag: OPENBSD_6_5 Makefile 
Added files:
editors/vim/patches: Tag: OPENBSD_6_5 
 patch-runtime_doc_options_txt 
 patch-src_getchar_c patch-src_option_c 
 patch-src_option_h 
 patch-src_testdir_test49_in 
 patch-src_testdir_test_modeline_vim 
 patch-src_testdir_test_source_vim 
 patch-src_version_c 

Log message:
SECURITY UPDATE to vim-8.1: add patches 1365-1368.

CVE-2019-12735 Arbitrary Code Execution via Modelines

https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md

"Beyond patching, it's recommended to disable modelines in the vimrc
(set nomodeline), to use the securemodelines plugin, or to disable
modelineexpr (since patch 8.1.1366, Vim-only) to disallow expressions in
modelines."

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Stuart Henderson 
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2019/06/06 09:04:22

Modified files:
editors/vim: Makefile distinfo 
editors/vim/pkg: PLIST-main 

Log message:
SECURITY UPDATE to vim-8.1.1483

CVE-2019-12735 Arbitrary Code Execution via Modelines

https://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md

"Beyond patching, it's recommended to disable modelines in the vimrc
(set nomodeline), to use the securemodelines plugin, or to disable
modelineexpr (since patch 8.1.1366, Vim-only) to disallow expressions in
modelines."

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Christian Weisgerber 
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2019/06/06 08:11:52

Modified files:
devel  : Makefile 

Log message:
typo

Re: OpenMP for both clang and GCC, part II

2019-06-06 Thread Stuart Henderson 
On 2019/06/05 16:42, j...@bitminer.ca wrote:
> Users will adopt flavors such as -withopenmp, or -noopenmp, as they become
> available.

Flavours are often a bad idea, testing becomes more complicated,
especially for ports which are part of chains of dependencies. I think
they should probably be avoided for this.

> Some issues and questions:
> 
> - this will work for amd64, but will it work for arm64, sparc? Others?
> - should the flavors be -withopenmp or -noopenmp?
> - how to successfully detect 90% or more of ports with hidden OpenMP support?
>   I will do this and am looking for advice on how best to approach it.
>   Any pre-existing info would be very welcome.

It would be helpful to see examples of what sort of improvement can be
expected on OpenBSD before deciding if it's worth the trouble to integrate
into ports (which is an ongoing thing, not just one-off work).

[NEW] fonts/luciole

2019-06-06 Thread Remi Pointel 

Hi,

attached is a new font called "luciole": a typeface developed explicitly 
for visually impaired people.


--
$ pkg_info luciole
Information for inst:luciole-1.0

Comment:
typeface developed explicitly for visually impaired people

Description:
Luciole (French fo "firefly") is a new typeface developed explicitly for
visually impaired people. The result of a two-year collaboration between 
the
Centre Technique Regional pour la Deficience Visuelle (the Regional 
Technical
Center for Visual Impairment) and the type-design studio 
typographies.fr, this
project received a grant from the Swiss Ceres Foundation and support 
from the

DIPHE laboratory at the Universite Lumiere Lyon 2.

Maintainer: The OpenBSD ports mailing-list 

WWW: https://www.luciole-vision.com/
--

Ok?

Cheers,

Remi.


luciole.tar.gz
Description: GNU Zip compressed data

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Raphael Graf 
CVSROOT:/cvs
Module name:ports
Changes by: ra...@cvs.openbsd.org   2019/06/06 06:13:17

Modified files:
audio  : Makefile 

Log message:
+rubberband

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Raphael Graf 
CVSROOT:/cvs
Module name:ports
Changes by: ra...@cvs.openbsd.org   2019/06/06 06:04:20

Log message:
Import audio/rubberband.  Help and ok sthen@

Rubber Band is a library and utility program that permits changing the
tempo and pitch of an audio recording independently of one another.

Status:

Vendor Tag: rapha
Release Tags:   rapha_20190606

N ports/audio/rubberband/Makefile
N ports/audio/rubberband/distinfo
N ports/audio/rubberband/patches/patch-Makefile_in
N ports/audio/rubberband/patches/patch-src_StretcherImpl_cpp
N ports/audio/rubberband/patches/patch-src_StretcherProcess_cpp
N ports/audio/rubberband/patches/patch-src_system_sysutils_h
N ports/audio/rubberband/pkg/DESCR
N ports/audio/rubberband/pkg/PLIST

No conflicts created by this import

[new] net/i2pd 2.25.0

2019-06-06 Thread Mikal Villa 
Hi,

This would be my first port, but I've actually read the documentation
and think I got it right. Not totally sure about the PLIST but hopefully
someone can point out my mistakes.

I plan to update the i2pd source for OpenBSD so this port can lose it's
current patch, but since the release was made before the port was
written it's needed for now. This can be considered as a official port
from the project.

I don't have CVS access so I would need someone here to actually submit it.


Best regards,
Mikal Villa / Meeh



net-i2pd.tar.bz2
Description: BZip2 compressed data

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Robert Nagy 
CVSROOT:/cvs
Module name:ports
Changes by: rob...@cvs.openbsd.org  2019/06/06 05:36:00

Modified files:
www/chromium   : Makefile 
www/chromium/patches: patch-chrome_browser_about_flags_cc 
  
patch-chrome_browser_chrome_content_browser_client_cc 
  patch-chrome_browser_flag_descriptions_cc 
  patch-chrome_browser_flag_descriptions_h 
  patch-tools_protoc_wrapper_protoc_wrapper_py 

Log message:
unbreak build by setting the PATH properly to ${WRKDIR}/bin so that
python can be found by the build and regen patches while here

Re: OpenBSD maintainers Spring cleaning

2019-06-06 Thread Renaud Allard 



On 6/6/19 11:24 AM, Stuart Henderson wrote:


How does a mail listing what ports ypu maintain, asking you to reply
saying if you want to continue, possibly look like phishing - would these
people also ignore emails with other questions about their ports (whether
from an openbsd.org address or not)? Part of the commitment for being
listed as a maintainer is responding to questions about the port.


Well, I sometimes receive mails from unknown people asking me questions 
(not about ports), which don't look obvious direct phishing, but which 
are attempts at testing the gullibility or the recipient. Of course, the 
one from Dan looked more genuine and this is why I checked and answered.





Next time, I think it might be interesting to send it from an @openbsd.org
mail address. Of course, from the official servers with SPF/DKIM, etc set up
correctly.


SPF is a non-starter for openbsd.org, it doesn't fit at all well with
how the email domain is used. And if we had to get DKIM setup on
openbsd.org first this much needed maintenance would just never get
done. (And without one or the other the mails would be very likely
to fail).



DKIM and SPF are somehow interlinked, because if you want to use DKIM, 
you need to send the mail from well known mail servers which know the 
key, and thus which would be easily added in the SPF.



I think doing this differently than danj@ did (within the constraints we
have to work with) would have either reduced deliverability or, if he'd
set reply-to openbsd.org, would have made it harder for replies to get
through.



I know, there is no magical recipe and Dan did his best.

Maybe there should be a "mandatory" mailing list with very few messages. 
But even that would not garantee a reply.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenBSD maintainers Spring cleaning

2019-06-06 Thread Stuart Henderson 
On 2019/06/06 07:47, Renaud Allard wrote:
> 
> 
> On 6/6/19 12:54 AM, Daniel Jakots wrote:
> > 
> > Some people mailed me after I posted the list here and no one said
> > it was in their spam.
> 
> If people receive a lot of mails and receive that one from an "unknown"
> email address (understand non @openbsd.org), and the mail looks like some
> kind of phishing attempt, they may have deleted it on sight. I was also
> reluctant at answering because I didn't know the mail address from the
> sender.

How does a mail listing what ports ypu maintain, asking you to reply
saying if you want to continue, possibly look like phishing - would these
people also ignore emails with other questions about their ports (whether
from an openbsd.org address or not)? Part of the commitment for being
listed as a maintainer is responding to questions about the port.

> Next time, I think it might be interesting to send it from an @openbsd.org
> mail address. Of course, from the official servers with SPF/DKIM, etc set up
> correctly.

SPF is a non-starter for openbsd.org, it doesn't fit at all well with
how the email domain is used. And if we had to get DKIM setup on
openbsd.org first this much needed maintenance would just never get
done. (And without one or the other the mails would be very likely
to fail).

I think doing this differently than danj@ did (within the constraints we
have to work with) would have either reduced deliverability or, if he'd
set reply-to openbsd.org, would have made it harder for replies to get
through.

Re: net/megatools: unbreak on gcc archs

2019-06-06 Thread Charlene Wendling 
Hi,

On Wed, 05 Jun 2019 15:02:59 +0200
Jeremie Courreges-Anglas wrote:

> 
> Hi,
> 
> there have been attempts to unbreak megatools on gcc archs by forcing
> C99 mode but this is not enough.  -std=c99 disables some extensions
> used by this port, namely anonymous unions.  -std=gnu99 helps getting
> past that, but linking then fails because the code uses
> _Static_assert from C11.
> 
> So here's a diff to force the use of base-clang or ports-gcc; both
> default to -std=gnu11.  Drop our only patch while here.
> 
> ok?

It builds fine on macppc. There are no tests but i've downloaded some
stuff successfully as well.

OK cwen@
 
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/megatools/Makefile,v
> retrieving revision 1.17
> diff -u -p -r1.17 Makefile
> --- Makefile  19 Dec 2018 08:21:44 -  1.17
> +++ Makefile  5 Jun 2019 12:52:05 -
> @@ -5,7 +5,7 @@ PORTROACH =   limit:[0-9]\.tar\.gz
>  COMMENT =command line client application for Mega
>  
>  DISTNAME =   megatools-1.10.2
> -REVISION =   1
> +REVISION =   2
>  
>  CATEGORIES = net
>  
> @@ -21,6 +21,7 @@ WANTLIB += ssl
>  
>  MASTER_SITES =   https://megatools.megous.com/builds/
>  
> +COMPILER =   base-clang ports-gcc
>  BUILD_DEPENDS =  devel/gobject-introspection \
>   textproc/asciidoc
>  LIB_DEPENDS =devel/glib2 \
> @@ -31,8 +32,6 @@ CONFIGURE_STYLE =   gnu
>  MAKE_FLAGS = VERBOSE=1
>  
>  CONFIGURE_ARGS = --disable-introspection
> -
> -CFLAGS +=-std=c99
>  
>  SEPARATE_BUILD = Yes
>  
> Index: patches/patch-Makefile_in
> ===
> RCS file: patches/patch-Makefile_in
> diff -N patches/patch-Makefile_in
> --- patches/patch-Makefile_in 27 Oct 2018 07:32:57
> - 1.1 +++ /dev/null   1 Jan 1970 00:00:00 -
> @@ -1,17 +0,0 @@
> -$OpenBSD: patch-Makefile_in,v 1.1 2018/10/27 07:32:57 bentley Exp $
> -
> -Build in C99 mode. From upstream
> 5acf268ba4e3df7fb7ebcab5bfef0a5a986fef8c. -
> -Index: Makefile.in
>  Makefile.in.orig
> -+++ Makefile.in
> -@@ -408,7 +408,8 @@ AM_CFLAGS = \
> - $(LIBCURL_CFLAGS) \
> - -DG_LOG_DOMAIN=\"Mega\" \
> - -I$(srcdir)/lib \
> ---I$(srcdir)
> -+-I$(srcdir) \
> -+-std=c99
> - 
> - 
> - # }}}
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE
> 1524 E7EE
>

net/zabbix 4.0.8

2019-06-06 Thread Mark Patruck 
Update net/zabbix to 4.0.8

Release notes: https://www.zabbix.com/rn/rn4.0.8

Running fine on amd64 (server + agent)


Index: Makefile
===
RCS file: /cvs/ports/net/zabbix/Makefile,v
retrieving revision 1.156
diff -u -p -r1.156 Makefile
--- Makefile12 Dec 2018 13:34:31 -  1.156
+++ Makefile3 Jun 2019 09:34:10 -
@@ -5,7 +5,7 @@ COMMENT-server =network and application
 COMMENT-proxy =network and application monitoring - proxy
 COMMENT-web =  network and application monitoring - web frontend
 
-VERSION =  4.0.0
+VERSION =  4.0.8
 DISTNAME = zabbix-${VERSION}
 FULLPKGNAME-main = zabbix-agent-${VERSION}
 FULLPKGPATH-main = net/zabbix,-main
@@ -15,8 +15,6 @@ FULLPKGPATH-proxy =   net/zabbix,-proxy
 FULLPKGNAME-web =  zabbix-web-${VERSION}
 FULLPKGPATH-web =  net/zabbix,-web
 CATEGORIES =   net
-REVISION-main =0
-REVISION-web = 0
 
 MAJV = ${VERSION:C/^([0-9]+\.[0-9]+).*/\1/}
 
Index: distinfo
===
RCS file: /cvs/ports/net/zabbix/distinfo,v
retrieving revision 1.45
diff -u -p -r1.45 distinfo
--- distinfo26 Oct 2018 06:57:21 -  1.45
+++ distinfo3 Jun 2019 09:34:10 -
@@ -1,2 +1,2 @@
-SHA256 (zabbix-4.0.0.tar.gz) = VnPhBhVhAq/4xngaiQ2mzt/Jdc8T2W2HSbTHEm9Ca8c=
-SIZE (zabbix-4.0.0.tar.gz) = 17984379
+SHA256 (zabbix-4.0.8.tar.gz) = ki5461YxGQjKZQ0UTL++UA/CJZxH/vgocn1t4GFt6gs=
+SIZE (zabbix-4.0.8.tar.gz) = 17125633
Index: patches/patch-conf_zabbix_server_conf
===
RCS file: /cvs/ports/net/zabbix/patches/patch-conf_zabbix_server_conf,v
retrieving revision 1.10
diff -u -p -r1.10 patch-conf_zabbix_server_conf
--- patches/patch-conf_zabbix_server_conf   26 Oct 2018 06:57:21 -  
1.10
+++ patches/patch-conf_zabbix_server_conf   3 Jun 2019 09:34:10 -
@@ -12,15 +12,15 @@ Index: conf/zabbix_server.conf
  
  ### Option: LogFileSize
  # Maximum size of log file in MB.
-@@ -124,6 +124,7 @@ DBUser=zabbix
+@@ -123,6 +123,7 @@ DBUser=zabbix
  # Mandatory: no
  # Default:
  # DBSocket=
 +DBSocket=/var/www/var/run/mysql/mysql.sock
  
  ### Option: DBPort
- # Database port when not using local socket. Ignored for SQLite.
-@@ -506,6 +507,7 @@ Timeout=4
+ # Database port when not using local socket.
+@@ -504,6 +505,7 @@ Timeout=4
  # Mandatory: no
  # Default:
  # AlertScriptsPath=${datadir}/zabbix/alertscripts
@@ -28,7 +28,7 @@ Index: conf/zabbix_server.conf
  
  ### Option: ExternalScripts
  # Full path to location of external scripts.
-@@ -523,6 +525,7 @@ Timeout=4
+@@ -521,6 +523,7 @@ Timeout=4
  # Mandatory: no
  # Default:
  # FpingLocation=/usr/sbin/fping
@@ -36,7 +36,7 @@ Index: conf/zabbix_server.conf
  
  ### Option: Fping6Location
  # Location of fping6.
-@@ -532,6 +535,7 @@ Timeout=4
+@@ -530,6 +533,7 @@ Timeout=4
  # Mandatory: no
  # Default:
  # Fping6Location=/usr/sbin/fping6
Index: patches/patch-configure
===
RCS file: /cvs/ports/net/zabbix/patches/patch-configure,v
retrieving revision 1.23
diff -u -p -r1.23 patch-configure
--- patches/patch-configure 26 Oct 2018 06:57:21 -  1.23
+++ patches/patch-configure 3 Jun 2019 09:34:10 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-configure,v 1.23 2018/10
 Index: configure
 --- configure.orig
 +++ configure
-@@ -6326,6 +6326,7 @@ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+@@ -6525,6 +6525,7 @@ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
  
  #include 
  #include 
@@ -10,7 +10,7 @@ Index: configure
  #include 
  int
  main ()
-@@ -9244,7 +9245,7 @@ $as_echo "yes" >&6; }
+@@ -9453,7 +9454,7 @@ $as_echo "yes" >&6; }
  
 JABBER_INCDIR="$IKSEMEL_CPPFLAGS"
 JABBER_LIBDIR="$IKSEMEL_LDFLAGS"
@@ -19,7 +19,7 @@ Index: configure
  
  fi
 else
-@@ -9254,7 +9255,7 @@ $as_echo_n "checking for iksemel support... " >&6; }
+@@ -9463,7 +9464,7 @@ $as_echo_n "checking for iksemel support... " >&6; }
 if test -f $_libiksemel_with/include/iksemel.h; then
 JABBER_INCDIR="-I$_libiksemel_with/include"
 JABBER_LIBDIR="-L$_libiksemel_with/lib"
@@ -28,7 +28,7 @@ Index: configure
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
  $as_echo "yes" >&6; }
 else
-@@ -12500,12 +12501,12 @@ LIBS="$LIBS $ICONV_LIBS"
+@@ -12771,12 +12772,12 @@ LIBS="$LIBS $ICONV_LIBS"
  RANLIB="ranlib"
  
  
Index: patches/patch-src_libs_zbxcrypto_tls_c
===
RCS file: /cvs/ports/net/zabbix/patches/patch-src_libs_zbxcrypto_tls_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_libs_zbxcrypto_tls_c
---

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Gonzalo L . Rodriguez 
CVSROOT:/cvs
Module name:ports
Changes by: gonz...@cvs.openbsd.org 2019/06/06 01:02:20

Modified files:
security/sqlmap: Makefile distinfo 
security/sqlmap/pkg: PLIST 

Log message:
Update for SQLMap to 1.3.6

https://github.com/sqlmapproject/sqlmap/releases/tag/1.3.6

"I've tested this lightly and it's working fine for me." lteo@

OK rpointel@

CVS: cvs.openbsd.org: ports

2019-06-06 Thread Rafael Sadowski 
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2019/06/06 00:08:56

Modified files:
x11/tellico: Makefile 

Log message:
fix searching for for QImageBlitz

Set CMAKE_DISABLE_FIND_PACKAGE_QImageBlitz=ON to stop finding QImageBlitz at
build time. Otherwise the Qt4 port is detected.

Spotted by naddy@ Thanks