CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2019/03/18 23:34:32 Modified files: databases/py-influxdb: Makefile distinfo databases/py-influxdb/pkg: PLIST Log message: Update to py-influxdb-5.2.2. Bugfix release. Changelog can be found at https://github.com/influxdata/influxdb-python/blob/master/CHANGELOG.md
Re: [NEW] converters/bdf2psf
Frederic, On Mon, Mar 18, 2019 at 9:37 PM Frederic Cambus wrote: > > On Thu, Feb 07, 2019 at 05:46:55PM +0100, Frederic Cambus wrote: > > > Here is a new port: converters/bdf2psf. > > ... > > Ping. Anyone willing to look at this? Thanks. I am not the right person to comment on how good an OpenBSD package is, but am glad to see bdf2psf getting packaged. I am the GNU Unifont maintainer, and would like to package Unifont for OpenBSD. I have a version that builds on OpenBSD now, but it needs bdf2psf to build a 512-glyph font for programming in APL in console mode. Can OpenBSD use a PSF font with 512 glyphs? If not, I can build it on OpenBSD but not install it. Here is a copy of bdf2psf I put on my website in 2014 for those who don't have it on their system, if you want something for comparison: http://unifoundry.com/pub/bdf2psf/ It is arranged with files under /usr rather than /usr/local, so I also thought of making a new tarball with the "/usr" stripped from the path. Here are the main pages describing the current release of Unifont and the software that builds all of its fonts: http://unifoundry.com/unifont/index.html http://unifoundry.com/unifont/unifont-utilities.html I plan to add a couple more programs in the next version that will handle VGA console fonts that OpenBSD uses. I have not packaged anything for OpenBSD and think it will be a while before I have the package ready for review. I thought I'd go over this now though because of your packaging bdf2psf. Thank you, Paul Hardy
sparc64 bulk build report
bulk build on sparc64-1.ports.openbsd.org started on Mon Mar 4 12:47:02 MST 2019 finished at Mon Mar 18 21:37:10 MDT 2019 lasted 15D00h50m done with kern.version=OpenBSD 6.5-beta (GENERIC) #131: Sun Mar 3 22:45:10 MST 2019 built packages:8974 Mar 4:208 Mar 5:170 Mar 6:151 Mar 7:84 Mar 8:58 Mar 9:127 Mar 10:78 Mar 11:109 Mar 12:97 Mar 13:291 Mar 14:268 Mar 15:509 Mar 16:611 Mar 17:1438 Mar 18:4774 critical path missing pkgs: http://build-failures.rhaalovely.net//sparc64/2019-03-04/summary.log build failures: 76 http://build-failures.rhaalovely.net//sparc64/2019-03-04/audio/audacious-plugins.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/audio/ncmpc.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/cad/qucs.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/comms/hackrf.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/appstream-glib.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/coccinelle.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/frama-c.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/ocaml-dose.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/omake.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/openmpi.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/rebar,erlang21.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/vte3.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/devel/xtensa-elf/gcc.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/editors/qscintilla.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/editors/scintilla.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/emulators/BasiliskII.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/emulators/higan.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/emulators/nestopia,-libretro.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/emulators/ppsspp.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/emulators/vice.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/games/freeorion.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/games/godot.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/games/grhino.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/games/gzdoom.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/games/supertux.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/geo/qlandkartegt.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/geo/spatialite/gis.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/graphics/aqsis.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/graphics/dcmtk.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/graphics/gegl04.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/graphics/gthumb.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/graphics/makehuman.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/graphics/pstoedit.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/inputmethods/scim-fcitx.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/inputmethods/scim-hangul.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/inputmethods/scim-pinyin.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/inputmethods/scim-tables.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/lang/apl.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/lang/janet.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/lang/parrot.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/mail/kopano/core.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/math/coq.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/math/gbc.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/multimedia/gstreamer1/mm.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/dleyna/renderer.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/dleyna/server.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/filezilla.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/megatools.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/mosquitto.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/mutella.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/pmacct.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/py-slixmpp.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/telegram-purple.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/toxcore.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/net/valknut.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/productivity/gnucash.log http://build-failures.rhaalovely.net//sparc64/2019-03-04/security/aircrack-ng.log
Re: miniupnpd-2.1
Bjrn Ketelaars [2019-03-07, 07:09:48]:
> Diff below brings miniupnpd to the latest version (2.1). Changelog can
> be found at
> http://miniupnp.free.fr/files/changelog.php?file=miniupnpd-2.1.tar.gz
>
> (Lightly) tested at home by a PS4-fanatic.
these patches (from upstream) avoid crashes by null pointer dereference
on receiving a request without those parameters.
ok?
Index: Makefile
===
RCS file: /cvs/ports/net/miniupnp/miniupnpd/Makefile,v
retrieving revision 1.19
diff -u -p -u -r1.19 Makefile
--- Makefile11 Mar 2019 20:05:23 - 1.19
+++ Makefile18 Mar 2019 23:33:03 -
@@ -3,7 +3,7 @@
COMMENT= UPnP IGD daemon
DISTNAME= miniupnpd-2.1
-REVISION= 0
+REVISION= 1
WANTLIB += c crypto kvm ssl
Index: patches/patch-upnpsoap_c
===
RCS file: patches/patch-upnpsoap_c
diff -N patches/patch-upnpsoap_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-upnpsoap_c18 Mar 2019 23:33:03 -
@@ -0,0 +1,28 @@
+$OpenBSD$
+
+Index: upnpsoap.c
+--- upnpsoap.c.orig
upnpsoap.c
+@@ -590,7 +590,7 @@ AddAnyPortMapping(struct upnphttp * h, const char * ac
+ if(leaseduration == 0)
+ leaseduration = 604800;
+
+- if (!int_ip || !ext_port || !int_port)
++ if (!int_ip || !ext_port || !int_port || !protocol)
+ {
+ ClearNameValueList();
+ SoapError(h, 402, "Invalid Args");
+@@ -1841,6 +1841,13 @@ GetOutboundPinholeTimeout(struct upnphttp * h, const c
+ rem_host = GetValueFromNameValueList(, "RemoteHost");
+ rem_port = GetValueFromNameValueList(, "RemotePort");
+ protocol = GetValueFromNameValueList(, "Protocol");
++
++ if (!int_port || !rem_port || !protocol)
++ {
++ ClearNameValueList();
++ SoapError(h, 402, "Invalid Args");
++ return;
++ }
+
+ rport = (unsigned short)atoi(rem_port);
+ iport = (unsigned short)atoi(int_port);
Re: [ports-gcc] Unbreak graphics/pstoedit
Charlene Wendling [2019-03-18, 14:57:23]:
> Hi ports, Steven,
>
> > http://build-failures.rhaalovely.net/sparc64/2019-02-03/graphics/pstoedit.log
> > http://build-failures.rhaalovely.net/powerpc/last/graphics/pstoedit.log
>
> It requires -std=c++11 once again, it builds fine on macppc after it's
> provided [1]. While here i've fixed a spacing inconsistency in COMPILER.
>
> I didn't bump REVISION, since pstoedit-3.73 has never been built on
> ports-gcc archs.
>
> Any comment?
>
> Charlène.
>
> [1] http://0x0.st/z8SZ.txt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/pstoedit/Makefile,v
> retrieving revision 1.27
> diff -u -p -u -p -r1.27 Makefile
> --- Makefile 5 Jan 2019 10:08:33 - 1.27
> +++ Makefile 18 Mar 2019 13:36:47 -
> @@ -26,9 +26,15 @@ CONFIGURE_ARGS=--without-libplot \
> --without-magick
> WANTLIB= c ${COMPILER_LIBCXX} m
>
> -COMPILER = base-clang ports-gcc base-gcc
> +# c++11
> +COMPILER = base-clang ports-gcc base-gcc
>
> post-install:
> ${INSTALL_MAN} ${WRKSRC}/doc/pstoedit.1 ${PREFIX}/man/man1
>
> .include
> +
> +# XXX this should be retried once moving to ports-gcc>=8
> +.if ${CHOSEN_COMPILER} == "ports-gcc"
> +CONFIGURE_ENV += CXXFLAGS="${CXXFLAGS} -std=c++11"
> +.endif
sure, but -std=c++11 is also supported by clang, we could always apply it?
Re: [ports-gcc] Unbreak audio/qsynth
Hi,
On Mon, 18 Mar 2019 22:56:35 +0100
"Sebastian Reitenbach" wrote:
> Hi,
>
> Am Montag, März 18, 2019 17:36 CET, Sebastian Reitenbach
> schrieb:
>
> > Hi,
> >
> > I was just testin to updat to 0.5.5, and failed miserably. I
> > contacted upstream and was told to use configure, make, make
> > install instead of cmake.
> >
> > Let me try that, and I’ll send you the update, to test it on
> > sparc64, maybe that will fix the problem
> >
> > Sebastian
> >
> > Sent from my iPhone
> >
> > > On 17. Mar 2019, at 14:58, Charlene Wendling
> > > wrote:> Hi Sebastian, ports,
> > >
> > >> http://build-failures.rhaalovely.net/powerpc/last/audio/qsynth.log
> > > (Qt5 doesn't build on sparc64)
> > >
> > > What happens behind the scenes (may it be clang or gcc):
> > >
> > > - Cmake search for math libs [1], and can't find them, setting
> > > CONFIG_ROUND not defined
> > > - Later, lroundf() is declared as a bundled, static function [2]
> > >
> > > The problem (to me) is that it seems that Qt headers pull
> > > , so there is a clash when using gcc. That doesn't occur
> > > with clang.
> > >
> > > There are several way to fix it, but in any case, would
> > > cause an out of scope error with ports-gcc, similarily to what
> > > you can find in math/{veusz,kst} in powerpc build failures.
> > >
> > > So i'm explicitly including when not using clang on
> > > OpenBSD, to point the problem out (but alternatives are welcome).
> > >
> > > It then builds fine on macppc [3] and amd64 [4].
> > >
> > > Charlène.
> > >
> > >
>
> as promised, here's the update to 0.5.5, which as upstream
> recommended to me switched from cmake to gnu style
> configure/make/make install. As they told me, the cmake stuff is more
> an example, and not kept up to date with the gnu style of building,
> therefore it should not really be used. Guess it was pure luck it
> worked with the older releases ;) Additionally a bit of cleanup in
> the Makefile, let me know if it fixes the math thingie bingie on gcc
> archs.
>
> cheers,
> Sebastian
>
It builds fine on macppc [1], after some modifications to your diff:
- It wants atomic as WANTLIB (macppc specific, will be dropped once
macppc has base-clang)
- I had to bring the lroundf() fix again :(
- portcheck says it needs x11/gtk+3,-guic (not sure if it's a false
positive though)
It yells that it wants c+11, i feared that i had to use the infamous
block that enables it like in other ports, but it's not needed as
upstream adds -std=gnu++11 during the effective build. And anyway this
warning will disappear once we move to ports-gcc-8 "soonish" (to quote
espie@).
Ah, and well, it runs [2], i can't really test as i've not
the hardware needed ;)
Charlène.
[1] http://0x0.st/z829.txt
[2] http://0x0.st/z821.jpg
Index: Makefile
===
RCS file: /cvs/ports/audio/qsynth/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile8 Mar 2019 20:00:40 - 1.6
+++ Makefile18 Mar 2019 22:58:05 -
@@ -2,8 +2,7 @@
COMMENT = Qt GUI Interface for FluidSynth
-DISTNAME = qsynth-0.5.4
-REVISION = 0
+DISTNAME = qsynth-0.5.5
CATEGORIES = audio
@@ -16,22 +15,26 @@ PERMIT_PACKAGE_CDROM = Yes
MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=qsynth/}
-WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Widgets X11 c
-WANTLIB += m fluidsynth Qt5X11Extras
+WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Widgets c
+WANTLIB += m fluidsynth GL Qt5Network curses readline
-MODULES = devel/cmake \
- x11/qt5
+.if ${MACHINE_ARCH} == "powerpc"
+WANTLIB += atomic
+.endif
-LIB_DEPENDS += audio/fluidsynth \
- x11/qt5/qtx11extras
+MODULES = x11/qt5
+
+LIB_DEPENDS += audio/fluidsynth
RUN_DEPENDS += devel/desktop-file-utils \
+ x11/gtk+3,-guic
+USE_GMAKE =Yes
NO_TEST = Yes
-BUILD_DEPENDS =audio/fluidsynth
+CONFIGURE_STYLE = gnu
-post-build:
- cp ${WRKSRC}/src/qsynth.desktop ${WRKBUILD}/src/
+CONFIGURE_ENV += CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
+ LDDFLAGS="${LDDFLAGS} -L${LOCALBASE}/lib"
.include
Index: distinfo
===
RCS file: /cvs/ports/audio/qsynth/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo2 Jan 2019 21:56:15 - 1.4
+++ distinfo18 Mar 2019 22:58:05 -
@@ -1,2 +1,2 @@
-SHA256 (qsynth-0.5.4.tar.gz) = LWvvtAI/imTzXYApkdDUE+EdAwfodIVCjJablLsr+E4=
-SIZE (qsynth-0.5.4.tar.gz) = 268106
+SHA256 (qsynth-0.5.5.tar.gz) = hY9SuVZCol9XA0LVz3+v0qKt24nVZ8W2ijVFvrb9pyM=
+SIZE (qsynth-0.5.5.tar.gz) = 269061
Index: patches/patch-src_qsynthChannelsForm_cpp
===
RCS file:
Re: NEW: security/wpscan
On 03/18 11:11, Sebastian Reitenbach wrote: > Hi, > > Am Sonntag, M??rz 17, 2019 19:46 CET, "Sebastian Reitenbach" > schrieb: > > > Hi, > > > > attached a port of wpscan: > > > > WPScan is a black box WordPress vulnerability scanner. > > > > I deliberately didn't named the port ruby-wpscan, since it's just a tool, > > and it's known as just wpscan. If ruby-wpscan would be preferred, I can > > for sure rename it. > > needs all of those just sent new gems. > > > > comments, concerns, or even test or OKs welcome. > > due to the fact I deliberately wanted the port as security/wpscan, jeremy@ > recommended > to use: > MODRUBY_HANDLE_FLAVORS =No > GEM_FLAGS = --no-format-executable > > this changes the package name from ruby25-wpscan to wpscan, as well as the > binary > name from wpscan25 to wpscan. Which is way much nicer. Thanks for that. > > However, he was concerned about the number of pure ruby gem dependencies > added with tight constraints, which might lead to conflicts in the future if > similar > package arises. I'd say, if really something comes up in the future which may > conflict or cause trouble, > it can be reviewed again. > I see the number of dependencies, but for me portroach bugs me to keep them > up-to-date, which I find incredibly convenient. Also, the very tight > dependency from > wpscan to cms_scanner is because, both are from the wpscan team, like a few > other dependencies of the cms_scanner. Since they're from the same team, > they'll likely keep them in sync, so I don't see the problem as dark as > jeremy@ does. One of the dependencies is already out of date. ruby-tzinfo uses 1.2.5, when 2.0.0 has been out for a couple months. Updating that is going to be problematic, because this depends on activesupport, which limits tzinfo to <2, and which is not able to work with tzinfo 2 (see https://github.com/rails/rails/pull/35368). What I recommended to sebestia@ was to bundle the pure-ruby dependencies, and only add port dependencies for compiled dependencies. That makes the conflict issue much less likely, and reduces the number of ports that require maintenance. It is probably more work for the maintainer to do the bundling, which may be the reason sebastia@ is not too fond of the idea. I'm not objecting to this and all dependencies being imported. However, I'm not going to review/OK the new ports. Thanks, Jeremy
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/03/18 16:35:09 Modified files: devel/ruby-concurrent-ruby: Makefile distinfo Log message: Update to 1.1.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/03/18 16:16:06 Modified files: net/proxychains-ng: Makefile distinfo Log message: Update to 4.14
[ports-gcc] Unbreak math/kst
> http://build-failures.rhaalovely.net/powerpc/last/math/kst.log
(Qt5 hasn't been built on sparc64)
There are 2 issues here:
- math functions being out of scope, most of the new patches
are because of this.
- it uses "-lrt", breaking the build later, so i've removed it.
Once again i've been conservative here, it will help future
maintenance.
Testing:
- macppc: it builds fine [1], i have been able to follow the basic
tutorial [2] without issues as well
- amd64: nothing bad to report as well [3]
Any comment?
Charlène.
[1] http://0x0.st/z8el.txt
[2] https://bsd.network/@julianaito/101773875372524149
[3] http://0x0.st/z8e0.txt
Index: Makefile
===
RCS file: /cvs/ports/math/kst/Makefile,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 Makefile
--- Makefile8 Mar 2019 20:00:47 - 1.37
+++ Makefile18 Mar 2019 21:44:32 -
@@ -5,7 +5,7 @@ COMMENT=data viewing/plotting tool
GH_ACCOUNT = Kst-plot
GH_PROJECT = kst
GH_TAGNAME = v2.0.8
-REVISION = 2
+REVISION = 3
SHARED_LIBS += kst2core 0.0 # 2.0
SHARED_LIBS += kst2math 0.0 # 2.0
Index: patches/patch-src_libkst_CMakeLists_txt
===
RCS file: patches/patch-src_libkst_CMakeLists_txt
diff -N patches/patch-src_libkst_CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libkst_CMakeLists_txt 18 Mar 2019 21:44:32 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+ports-gcc: we don't need -lrt
+
+Index: src/libkst/CMakeLists.txt
+--- src/libkst/CMakeLists.txt.orig
src/libkst/CMakeLists.txt
+@@ -7,7 +7,7 @@ kst_files_ignore(stdinsource timezones)
+ if(WIN32 OR APPLE OR QNX OR ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
+ kst_files_ignore(sysinfo psversion)
+ else()
+-if(NOT kst_clang)
++if(NOT kst_clang AND NOT ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD")
+ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -lrt")
+ endif()
+ endif()
Index: patches/patch-src_libkst_matrix_cpp
===
RCS file: patches/patch-src_libkst_matrix_cpp
diff -N patches/patch-src_libkst_matrix_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libkst_matrix_cpp 18 Mar 2019 21:44:32 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+ports-gcc: fix out of scope errors
+
+Index: src/libkst/matrix.cpp
+--- src/libkst/matrix.cpp.orig
src/libkst/matrix.cpp
+@@ -20,7 +20,13 @@
+
+ #include "matrix.h"
+
++#if defined(__OpenBSD__) && !defined(__clang__)
++#include
++#define isnan std::isnan
++#define isfinite std::isfinite
++#else
+ #include
++#endif
+ #include
+ #include
+
Index: patches/patch-src_libkst_vector_cpp
===
RCS file: patches/patch-src_libkst_vector_cpp
diff -N patches/patch-src_libkst_vector_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libkst_vector_cpp 18 Mar 2019 21:44:32 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+ports-gcc: fix out of scope errors
+
+Index: src/libkst/vector.cpp
+--- src/libkst/vector.cpp.orig
src/libkst/vector.cpp
+@@ -19,7 +19,13 @@
+ #include "vector.h"
+
+ #include
++#if defined(__OpenBSD__) && !defined(__clang__)
++#include
++#define isnan std::isnan
++#define isfinite std::isfinite
++#else
+ #include
++#endif
+ #include
+
+ #include
Index: patches/patch-src_libkstapp_plotaxis_cpp
===
RCS file: patches/patch-src_libkstapp_plotaxis_cpp
diff -N patches/patch-src_libkstapp_plotaxis_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libkstapp_plotaxis_cpp18 Mar 2019 21:44:32 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+
+ports-gcc: fix out of scope errors
+
+Index: src/libkstapp/plotaxis.cpp
+--- src/libkstapp/plotaxis.cpp.orig
src/libkstapp/plotaxis.cpp
+@@ -15,6 +15,11 @@
+ #include "math_kst.h"
+ #include "dialogdefaults.h"
+
++#if defined(__OpenBSD__) && !defined(__clang__)
++#include
++#define isnan std::isnan
++#endif
++
+ #include
+
+ #define MAJOR_TICK_DEBUG 0
Index: patches/patch-src_libkstmath_curve_cpp
===
RCS file: patches/patch-src_libkstmath_curve_cpp
diff -N patches/patch-src_libkstmath_curve_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libkstmath_curve_cpp 18 Mar 2019 21:44:32 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+
+ports-gcc: fix out of scope errors
+
+Index: src/libkstmath/curve.cpp
+--- src/libkstmath/curve.cpp.orig
src/libkstmath/curve.cpp
+@@ -37,6 +37,11 @@
+ #include
+ #include
+
++#if defined(__OpenBSD__) && !defined(__clang__)
++#include
++#define isinf std::isinf
++#endif
++
+ // #define DEBUG_VECTOR_CURVE
+ // #define BENCHMARK
+
Index: patches/patch-src_libkstmath_image_cpp
===
RCS file:
Re: NEW: security/wpscan
Hi, Am Sonntag, März 17, 2019 19:46 CET, "Sebastian Reitenbach" schrieb: > Hi, > > attached a port of wpscan: > > WPScan is a black box WordPress vulnerability scanner. > > I deliberately didn't named the port ruby-wpscan, since it's just a tool, > and it's known as just wpscan. If ruby-wpscan would be preferred, I can > for sure rename it. > needs all of those just sent new gems. > > comments, concerns, or even test or OKs welcome. due to the fact I deliberately wanted the port as security/wpscan, jeremy@ recommended to use: MODRUBY_HANDLE_FLAVORS =No GEM_FLAGS = --no-format-executable this changes the package name from ruby25-wpscan to wpscan, as well as the binary name from wpscan25 to wpscan. Which is way much nicer. Thanks for that. However, he was concerned about the number of pure ruby gem dependencies added with tight constraints, which might lead to conflicts in the future if similar package arises. I'd say, if really something comes up in the future which may conflict or cause trouble, it can be reviewed again. I see the number of dependencies, but for me portroach bugs me to keep them up-to-date, which I find incredibly convenient. Also, the very tight dependency from wpscan to cms_scanner is because, both are from the wpscan team, like a few other dependencies of the cms_scanner. Since they're from the same team, they'll likely keep them in sync, so I don't see the problem as dark as jeremy@ does. The updated port attached. cheers, Sebastian wpscan.tar.gz Description: application/gzip
Re: [ports-gcc] Unbreak audio/qsynth
Hi,
Am Montag, März 18, 2019 17:36 CET, Sebastian Reitenbach
schrieb:
> Hi,
>
> I was just testin to updat to 0.5.5, and failed miserably. I contacted
> upstream and was told to use configure, make, make install instead of cmake.
>
> Let me try that, and I’ll send you the update, to test it on sparc64, maybe
> that will fix the problem
>
> Sebastian
>
> Sent from my iPhone
>
> > On 17. Mar 2019, at 14:58, Charlene Wendling wrote:>
> > Hi Sebastian, ports,
> >
> >> http://build-failures.rhaalovely.net/powerpc/last/audio/qsynth.log
> > (Qt5 doesn't build on sparc64)
> >
> > What happens behind the scenes (may it be clang or gcc):
> >
> > - Cmake search for math libs [1], and can't find them, setting
> > CONFIG_ROUND not defined
> > - Later, lroundf() is declared as a bundled, static function [2]
> >
> > The problem (to me) is that it seems that Qt headers pull , so
> > there is a clash when using gcc. That doesn't occur with clang.
> >
> > There are several way to fix it, but in any case, would cause
> > an out of scope error with ports-gcc, similarily to what you can find in
> > math/{veusz,kst} in powerpc build failures.
> >
> > So i'm explicitly including when not using clang on OpenBSD,
> > to point the problem out (but alternatives are welcome).
> >
> > It then builds fine on macppc [3] and amd64 [4].
> >
> > Charlène.
> >
> >
as promised, here's the update to 0.5.5, which as upstream recommended to
me switched from cmake to gnu style configure/make/make install.
As they told me, the cmake stuff is more an example, and not kept up
to date with the gnu style of building, therefore it should not really
be used. Guess it was pure luck it worked with the older releases ;)
Additionally a bit of cleanup in the Makefile, let me know if it fixes the
math thingie bingie on gcc archs.
cheers,
Sebastian
Index: Makefile
===
RCS file: /cvs/ports/audio/qsynth/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile8 Mar 2019 20:00:40 - 1.6
+++ Makefile18 Mar 2019 21:50:21 -
@@ -2,8 +2,7 @@
COMMENT = Qt GUI Interface for FluidSynth
-DISTNAME = qsynth-0.5.4
-REVISION = 0
+DISTNAME = qsynth-0.5.5
CATEGORIES = audio
@@ -16,22 +15,21 @@
MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=qsynth/}
-WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Widgets X11 c
-WANTLIB += m fluidsynth Qt5X11Extras
+WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Widgets c
+WANTLIB += m fluidsynth GL Qt5Network curses readline
-MODULES = devel/cmake \
- x11/qt5
+MODULES = x11/qt5
-LIB_DEPENDS += audio/fluidsynth \
- x11/qt5/qtx11extras
+LIB_DEPENDS += audio/fluidsynth
-RUN_DEPENDS += devel/desktop-file-utils \
+RUN_DEPENDS += devel/desktop-file-utils
+USE_GMAKE =Yes
NO_TEST = Yes
-BUILD_DEPENDS =audio/fluidsynth
+CONFIGURE_STYLE = gnu
-post-build:
- cp ${WRKSRC}/src/qsynth.desktop ${WRKBUILD}/src/
+CONFIGURE_ENV += CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
+ LDDFLAGS="${LDDFLAGS} -L${LOCALBASE}/lib"
.include
Index: distinfo
===
RCS file: /cvs/ports/audio/qsynth/distinfo,v
retrieving revision 1.4
diff -u -r1.4 distinfo
--- distinfo2 Jan 2019 21:56:15 - 1.4
+++ distinfo18 Mar 2019 21:50:21 -
@@ -1,2 +1,2 @@
-SHA256 (qsynth-0.5.4.tar.gz) = LWvvtAI/imTzXYApkdDUE+EdAwfodIVCjJablLsr+E4=
-SIZE (qsynth-0.5.4.tar.gz) = 268106
+SHA256 (qsynth-0.5.5.tar.gz) = hY9SuVZCol9XA0LVz3+v0qKt24nVZ8W2ijVFvrb9pyM=
+SIZE (qsynth-0.5.5.tar.gz) = 269061
Index: patches/patch-src_qsynthChannelsForm_cpp
===
RCS file: patches/patch-src_qsynthChannelsForm_cpp
diff -N patches/patch-src_qsynthChannelsForm_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_qsynthChannelsForm_cpp18 Mar 2019 21:50:21 -
@@ -0,0 +1,33 @@
+$OpenBSD$
+
+Index: src/qsynthChannelsForm.cpp
+--- src/qsynthChannelsForm.cpp.orig
src/qsynthChannelsForm.cpp
+@@ -256,11 +256,11 @@ void qsynthChannelsForm::updateChannel ( int iChan )
+ #ifdef CONFIG_FLUID_BANK_OFFSET
+ int iSFID = 0;
+ QString sSFName;
+- #ifdef CONFIG_FLUID_PRESET_GET_SFONT
++ #ifdef CONFIG_FLUID_PRESET_GET_SFONT
+ fluid_sfont_t *pSoundFont = ::fluid_preset_get_sfont(pPreset);
+- #else
++ #else
+ fluid_sfont_t *pSoundFont = pPreset->sfont;
+- #endif
++ #endif
+ if (pSoundFont) {
+ #ifdef CONFIG_FLUID_SFONT_GET_ID
+ iSFID = ::fluid_sfont_get_id(pSoundFont);
+@@ -290,10 +290,12 @@ void qsynthChannelsForm::updateChannel ( int iChan )
Re: Adding MODPY_TEST_LOCALE to python.port.mk
On Mon, Mar 18, 2019 at 12:03:58AM +, Stuart Henderson wrote:
> On 2019/03/17 19:37, Kurt Mosiejczuk wrote:
> > On Sun, Mar 17, 2019 at 11:12:29PM +, Stuart Henderson wrote:
> >
> > > I like the direction this is taking, but it's missing use of a standard
> > > MODULES mechanism, and a comment on style for commit -
> >
> > > There are several logically separate pieces here which would be
> > > better to commit independently to keep the history clear.
> >
> > > I think MODPY_TEST_LOCALE also stands alone.
> >
> > Here's the second part adding MODPY_TEST_LOCALE.
> >
> > --Kurt
> >
> > Index: python.port.mk
> > ===
> > RCS file: /cvs/ports/lang/python/python.port.mk,v
> > retrieving revision 1.100
> > diff -u -p -r1.100 python.port.mk
> > --- python.port.mk 4 Dec 2018 05:57:31 - 1.100
> > +++ python.port.mk 17 Mar 2019 23:26:29 -
> > @@ -159,6 +159,10 @@ MODPY_TEST_CMD = cd ${WRKSRC} && ${SETEN
> > ${MODPY_BIN} ./${MODPY_SETUP} \
> > ${MODPY_SETUP_ARGS}
> >
> > +MODPY_TEST_LOCALE ?= LC_CTYPE=en_US.UTF-8
> > +
> > +TEST_ENV +=${MODPY_TEST_LOCALE}
> > +
> > SUBST_VARS := MODPY_PYCACHE MODPY_COMMENT MODPY_ABI3SO
> > MODPY_PYC_MAGIC_TAG \
> > MODPY_BIN MODPY_EGG_VERSION MODPY_VERSION MODPY_BIN_SUFFIX \
> > MODPY_PY_PREFIX MODPY_PYOEXTENSION ${SUBST_VARS}
> >
>
> This one's OK with me.
>
I just committed this one. Thank you!
Remi
Re: MODPY_TESTDEP diff for python.port.mk
On Mon, Mar 18, 2019 at 12:58:28AM +, Stuart Henderson wrote:
> On 2019/03/17 20:52, Kurt Mosiejczuk wrote:
> > On Sun, Mar 17, 2019 at 07:35:52PM -0400, Kurt Mosiejczuk wrote:
> >
> > > So here is the first part adding MODPY_TESTDEP.
> >
> > Here's a version that has a comment as to why MODPY_TEST_DEPENDS is
> > empty
>
> Great, this is OK with me.
I committed this one. Thanks!
Remi
>
> > --Kurt
> >
> > Index: python.port.mk
> > ===
> > RCS file: /cvs/ports/lang/python/python.port.mk,v
> > retrieving revision 1.100
> > diff -u -p -r1.100 python.port.mk
> > --- python.port.mk 4 Dec 2018 05:57:31 - 1.100
> > +++ python.port.mk 17 Mar 2019 23:23:11 -
> > @@ -68,6 +68,7 @@ MODPY_WANTLIB = python${MODPY_VERSION}${
> > MODPY_RUN_DEPENDS =lang/python/${MODPY_VERSION}
> > MODPY_LIB_DEPENDS =lang/python/${MODPY_VERSION}
> > _MODPY_BUILD_DEPENDS = lang/python/${MODPY_VERSION}
> > +MODPY_TEST_DEPENDS = # empty, appended by MODPY_PYTEST
> >
> > .if ${NO_BUILD:L} == "no"
> > MODPY_BUILDDEP ?= Yes
> > @@ -75,6 +76,7 @@ MODPY_BUILDDEP ?= Yes
> > MODPY_BUILDDEP ?= No
> > .endif
> > MODPY_RUNDEP ?=Yes
> > +MODPY_TESTDEP ?= Yes
> >
> > .if ${MODPY_BUILDDEP:L} == "yes"
> > BUILD_DEPENDS += ${_MODPY_BUILD_DEPENDS}
> > @@ -82,6 +84,10 @@ BUILD_DEPENDS += ${_MODPY_BUILD_DEPENDS}
> >
> > .if ${MODPY_RUNDEP:L} == "yes"
> > RUN_DEPENDS += ${MODPY_RUN_DEPENDS}
> > +.endif
> > +
> > +.if ${MODPY_TESTDEP:L} == "yes"
> > +TEST_DEPENDS +=${MODPY_TEST_DEPENDS}
> > .endif
> >
> > _MODPY_PRE_BUILD_STEPS = :
> >
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: r...@cvs.openbsd.org2019/03/18 15:30:48 Modified files: lang/python: python.port.mk Log message: Add MODPY_TEST_LOCALE. In general python tests want an UTF-8 locale. If needed this allows to overwrite it. I looks like python preferes C.UTF-8. But Ingo pointed out that on OpenBSD en_US.UTF-8 is prefered and the former is just a link to the later. from Kurt Mosiejczuk ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/03/18 15:22:26 Modified files: databases/p5-DBD-XBase: Makefile databases/p5-DBD-XBase/pkg: PLIST Log message: Install dbfdump script as dbfdump.pl, a shapelib update i'm working on will ship a dbfdump binary.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: r...@cvs.openbsd.org2019/03/18 15:19:18 Modified files: lang/python: python.port.mk Log message: Add MODPY_TESTDEP and MODPY_TEST_DEPENDS. In a future step this will allow to automatically add deps for pytest to TEST_DEPENDS. from Kurt Mosiejczuk ok sthen@
Re: [UPDATE] devel/libyaml
On Thu, Mar 14 2019, Remi Pointel wrote: > Hi, > > attached is the diff to update libyaml to latest release. > > Ok? Diffs for ports that ship shared libraries should be checked for API and ABI changes. Please mention which checks you have done to avoid duplicate work. ;) For this libyaml diff, src/lib/check_sym old.so new.so tells me that no dynamic symbol were added/removed, and a diff of the public headers shows irrelevant changes. No SHARED_LIBS bump is needed and this update looks safe to me, API and ABI-wise. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/03/18 11:54:33 Modified files: security/suricata: Makefile distinfo security/suricata/pkg: PLIST Log message: update to suricata-4.1.3 ok gonzalo@
Re: UPDATE: graphics/opencv
On Mon Mar 11, 2019 at 09:31:56PM +0100, Rafael Sadowski wrote: > Update opencv to 3.4.2. > > Tested with upcoming nomacs update and digikam. > > Face detection and recognition works quite well with this version and > upcoming digikam5. > > RS > General note, to build opencv local. Please make sure you don't have opencv installed. First run "pkg_delete opencv" RS
Re: [ports-gcc] Unbreak audio/qsynth
Hi,
I was just testin to updat to 0.5.5, and failed miserably. I contacted upstream
and was told to use configure, make, make install instead of cmake.
Let me try that, and I’ll send you the update, to test it on sparc64, maybe
that will fix the problem
Sebastian
Sent from my iPhone
> On 17. Mar 2019, at 14:58, Charlene Wendling wrote:
>
> Hi Sebastian, ports,
>
>> http://build-failures.rhaalovely.net/powerpc/last/audio/qsynth.log
> (Qt5 doesn't build on sparc64)
>
> What happens behind the scenes (may it be clang or gcc):
>
> - Cmake search for math libs [1], and can't find them, setting
> CONFIG_ROUND not defined
> - Later, lroundf() is declared as a bundled, static function [2]
>
> The problem (to me) is that it seems that Qt headers pull , so
> there is a clash when using gcc. That doesn't occur with clang.
>
> There are several way to fix it, but in any case, would cause
> an out of scope error with ports-gcc, similarily to what you can find in
> math/{veusz,kst} in powerpc build failures.
>
> So i'm explicitly including when not using clang on OpenBSD,
> to point the problem out (but alternatives are welcome).
>
> It then builds fine on macppc [3] and amd64 [4].
>
> Charlène.
>
>
> [1] https://github.com/rncbc/qsynth/blob/master/CMakeLists.txt#L58
> [2]
> https://github.com/rncbc/qsynth/blob/master/src/qsynthMainForm.cpp#L103
> [3] http://0x0.st/z8qH.txt
> [4] http://0x0.st/z8qX.txt
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/audio/qsynth/Makefile,v
> retrieving revision 1.6
> diff -u -p -u -p -r1.6 Makefile
> --- Makefile8 Mar 2019 20:00:40 -1.6
> +++ Makefile17 Mar 2019 13:45:26 -
> @@ -3,7 +3,7 @@
> COMMENT =Qt GUI Interface for FluidSynth
>
> DISTNAME =qsynth-0.5.4
> -REVISION =0
> +REVISION =1
>
> CATEGORIES =audio
>
> Index: patches/patch-src_qsynthMainForm_cpp
> ===
> RCS file: patches/patch-src_qsynthMainForm_cpp
> diff -N patches/patch-src_qsynthMainForm_cpp
> --- /dev/null1 Jan 1970 00:00:00 -
> +++ patches/patch-src_qsynthMainForm_cpp17 Mar 2019 13:45:26 -
> @@ -0,0 +1,20 @@
> +$OpenBSD$
> +
> +ports-gcc fix. lroundf() is not detected during configuration, so
> CONFIG_ROUND
> +is undefined. But is pulled by Qt headers already, creating a
> conflict
> +between 's lroundf() and the bundled lroundf().
> +
> +Using would cause an out of scope error.
> +
> +Index: src/qsynthMainForm.cpp
> +--- src/qsynthMainForm.cpp.orig
> src/qsynthMainForm.cpp
> +@@ -103,6 +103,8 @@ static int g_fdStdout[2] = { QSYNTH_FDNIL, QSYNTH_FDNI
> + // Needed for lroundf()
> + #ifdef CONFIG_ROUND
> + #include
> ++#elif defined(__OpenBSD__) && !defined(__clang__)
> ++#include
> + #else
> + static inline long lroundf ( float x )
> + {
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: giova...@cvs.openbsd.org2019/03/18 10:29:49 Modified files: net/rbldnsd: Makefile distinfo net/rbldnsd/pkg: PLIST Log message: Update to latest GH commit (2018.05.16) and take maintainership
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/03/18 09:13:16 Modified files: editors: Makefile Log message: build vim--gtk2 again (previously it had just plain "vim" using the default flavour, previously gtk2 now gtk3 - change to explicitly listing both ,gtk2 and ,gtk3).
[ports-gcc] Unbreak graphics/pstoedit
Hi ports, Steven,
> http://build-failures.rhaalovely.net/sparc64/2019-02-03/graphics/pstoedit.log
> http://build-failures.rhaalovely.net/powerpc/last/graphics/pstoedit.log
It requires -std=c++11 once again, it builds fine on macppc after it's
provided [1]. While here i've fixed a spacing inconsistency in COMPILER.
I didn't bump REVISION, since pstoedit-3.73 has never been built on
ports-gcc archs.
Any comment?
Charlène.
[1] http://0x0.st/z8SZ.txt
Index: Makefile
===
RCS file: /cvs/ports/graphics/pstoedit/Makefile,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 Makefile
--- Makefile5 Jan 2019 10:08:33 - 1.27
+++ Makefile18 Mar 2019 13:36:47 -
@@ -26,9 +26,15 @@ CONFIGURE_ARGS= --without-libplot \
--without-magick
WANTLIB= c ${COMPILER_LIBCXX} m
-COMPILER = base-clang ports-gcc base-gcc
+# c++11
+COMPILER = base-clang ports-gcc base-gcc
post-install:
${INSTALL_MAN} ${WRKSRC}/doc/pstoedit.1 ${PREFIX}/man/man1
.include
+
+# XXX this should be retried once moving to ports-gcc>=8
+.if ${CHOSEN_COMPILER} == "ports-gcc"
+CONFIGURE_ENV += CXXFLAGS="${CXXFLAGS} -std=c++11"
+.endif
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2019/03/18 07:27:51 Modified files: www/py-django/lts: Makefile distinfo www/py-django/lts/pkg: PLIST www/py-django/stable: Makefile distinfo www/py-django/stable/pkg: PLIST Log message: update django to 1.11.20 and 2.1.7.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/03/18 07:09:28 Modified files: geo/qlandkartegt: Makefile Added files: geo/qlandkartegt/patches: patch-src_GeoMath_cpp Log message: qlandkartegt: requires -std=c++11 with ports-gcc-4.9. Also fix an out of scope isnan() occurring only with ports-gcc. Successfully tested on macppc. OK sthen@, "looks good" landry@
Re: [ports-gcc] Unbreak geo/qlandkartegt
Hi, On Mon, 18 Mar 2019 09:06:09 + Stuart Henderson wrote: > On 2019/03/18 08:23, Landry Breuil wrote: > > On Mon, Mar 18, 2019 at 12:09:01AM +0100, Charlene Wendling wrote: > > > > > > > http://build-failures.rhaalovely.net/powerpc/last/geo/qlandkartegt.log > > > > http://build-failures.rhaalovely.net/sparc64/2019-02-03/geo/qlandkartegt.log > > > > > > So this one needs -std=c++11. Once provided there is the usual > > > / fight later during the build. I tried to be > > > conservative here, but anyway upstream moved to a remake of its > > > own software called QMapShack. > > > > > > It builds fine on macppc [1] and amd64 [2]. I don't have the > > > hardware to fully test it, but geotiff maps are fine. > > > > > > Any comment? > > > > > > > +# fix error: #error Must have C++11 or newer. > > > +# XXX this should be retried once moving to ports-gcc>=8 > > > > removed :) retired isnt right either i think.. > > otherwise looks good. In fact it's careful wording, i haven't tested with ports-gcc-8 ;) > > Landry > > > > 'reviewed' is probably the best word, but 'retried' is understandable > and matches the wording in other ports. > > hopefully it won't stay there for long anyway :) > Sadly, the next fix i'm going to propose requires that as well.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/03/18 06:02:00 Modified files: security/hcxtools: Makefile distinfo Log message: Update to 5.1.4
Re: WIP: net/libsignal-protocol-c
On Thu, Mar 7, 2019 at 10:35 PM Anthony J. Bentley wrote: > Stuart Henderson writes: > > On 2019/03/07 13:55, Stefan Sperling wrote: > > > On Thu, Mar 07, 2019 at 12:34:35AM -0700, Anthony J. Bentley wrote: > > > > On Sun, Feb 17, 2019 at 2:57 PM Anthony J. Bentley > > > > w > > rote: > > > > > > > > > > Alex Holst writes: > > > > > > Hi, > > > > > > > > > > > > Thanks for your input. It should all be adopted into this port > > > > > > except > > > > > > for the 'test' target which I couldn't get working otherwise. > > > > > > > > > > No need for a do-test, just use: > > > > > > > > > > CONFIGURE_ARGS =-DBUILD_TESTING=ON > > > > > > > > Here's a port with that change, some minor whitespace changes, and a > > > > tweaked DESCR. > > > > > > > > Is this ready to go in? > > > > > > Some files have the executable bit set, please clear them. > > > > > > It seems something is wrong with build dependencies. > > > After 'make prepare' which installed cmake and ninja packages, > > > I tried to run 'make package' and it failed: > > > > Setting -DBUILD_TESTING adds check as a build requirement. > > > > Is there a reason not to build the shared lib? > > Makes sense to me. > > Attached tarball builds shared lib, sets BUILD_DEPENDS properly, > removes executable bit from files in the port directory. Is this version ready for import? Any oks? -- Anthony J. Bentley libsignal-protocol-c.tar.gz Description: application/gzip
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2019/03/18 04:49:05 Modified files: productivity/khal: Makefile distinfo productivity/khal/pkg: PLIST Log message: update to 0.9.10 and switch back to pypi from Kurt Mosiejczuk with tweaks from kn ok kn bentley
Re: Update: devel/py-icalendar 4.0.0 -> 4.0.3
On Sat, Mar 16, 2019 at 02:33:45PM -0400, Kurt Mosiejczuk wrote: > On Mon, Mar 04, 2019 at 10:53:49PM -0500, Kurt Mosiejczuk wrote: > > A fairly straightforward update. Slight changes to the PLIST including a > > bin/icalendar. First time when I've had that. On the advice of pamela@ > > I grabbed the post-install for loop construction from py-gunicorn. > > Overkill for one file, but it will just work if the package adds any > > more in the future. > > > For the previous version we failed one test, all tests pass for 4.0.3. > > > Only consumer seems to be khal and its tests pass and fail exactly the > > same number of tests as before. > > ping Committed, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2019/03/18 04:38:40 Modified files: devel/py-icalendar: Makefile distinfo devel/py-icalendar/pkg: PLIST Log message: update to 4.0.3 from Kurt Mosiejczuk
Re: UPDATE: games/freedink/game and games/freedink/data && NEW: games/freedink/dfarc
Brian Callahan writes: > Big update for FreeDink to update to the latest engine and data releases. > Also, a new subport for dfarc which is a game and D-Mod frontend for > FreeDink. dfarc fails during fake for me: /usr/local/bin/xdg-icon-resource install --context mimetypes --size 32 \ ./pixmaps/dfarc.png application-x-dmod mkdir: /dfarc-3.14_writes_to_HOME: Permission denied touch: /dfarc-3.14_writes_to_HOME/.local/share/icons/hicolor/.xdg-icon-resource-dummy: No such file or directory /usr/local/bin/xdg-mime install freedink-mime.xml mkdir: /dfarc-3.14_writes_to_HOME: Permission denied mkdir: /dfarc-3.14_writes_to_HOME: Permission denied /usr/local/bin/xdg-mime: cannot create /dfarc-3.14_writes_to_HOME/.kde/share/mimelnk//application/x-dmod.desktop: No such file or directory grep: /dfarc-3.14_writes_to_HOME/.kde/share/mimelnk//application/x-dmod.desktop: No such file or directory rm: /dfarc-3.14_writes_to_HOME/.kde/share/mimelnk//application/x-dmod.desktop: No such file or directory gmake[2]: *** [Makefile:583: install-data-local] Error 1 gmake[2]: Leaving directory '/ptmp/pobj/dfarc-3.14/dfarc-3.14/share' gmake[1]: *** [Makefile:461: install-am] Error 2 gmake[1]: Leaving directory '/ptmp/pobj/dfarc-3.14/dfarc-3.14/share' gmake: *** [Makefile:427: install-recursive] Error 1
Re: [ports-gcc] Unbreak geo/qlandkartegt
On 2019/03/18 08:23, Landry Breuil wrote: > On Mon, Mar 18, 2019 at 12:09:01AM +0100, Charlene Wendling wrote: > > > > > http://build-failures.rhaalovely.net/powerpc/last/geo/qlandkartegt.log > > > http://build-failures.rhaalovely.net/sparc64/2019-02-03/geo/qlandkartegt.log > > > > So this one needs -std=c++11. Once provided there is the usual > > / fight later during the build. I tried to be > > conservative here, but anyway upstream moved to a remake of its own > > software called QMapShack. > > > > It builds fine on macppc [1] and amd64 [2]. I don't have the > > hardware to fully test it, but geotiff maps are fine. > > > > Any comment? > > > > +# fix error: #error Must have C++11 or newer. > > +# XXX this should be retried once moving to ports-gcc>=8 > > removed :) retired isnt right either i think.. > otherwise looks good. > > Landry > 'reviewed' is probably the best word, but 'retried' is understandable and matches the wording in other ports. hopefully it won't stay there for long anyway :)
Re: Update: productivity/khal 0.9.9* -> 0.9.10
Klemens Nanni writes: > On Wed, Mar 13, 2019 at 09:56:23PM -0400, Kurt Mosiejczuk wrote: > > While looking into another port update, I came across productivity/khal > > that was temporarily not using PyPi until a new version had a fix for > > using py-dateutil >= 2.7. I checked, and such an update is out. ok bentley@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2019/03/18 02:36:20 Modified files: cad: Makefile Log message: +magic
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2019/03/18 02:35:35 Log message: Import magic-8.1.224. Magic is an interactive system for creating and modifying VLSI circuit layouts. It is used to design basic cells and to combine them hierarchically into large structures. Magic understands quite a bit about the nature of circuits. It has built-in knowledge of layout rules; during editing, it continuously checks for rule violations. Magic also knows about connectivity and transistors, and contains a built-in hierarchical circuit extractor. It has a plow operation that permits to stretch or compact cells. Lastly, Magic has routing tools to make the circuit interconnections. Magic is based on the Mead-Conway style of design: it uses simplified design rules and circuit structures that make it easier layout drawing and permit Magic to provide powerful assistance, at the cost of slightly less dense circuits. From Alessandro De Laurenzis; thanks! ok sthen@ Status: Vendor Tag: bentley Release Tags: bentley_20190318 N ports/cad/magic/Makefile N ports/cad/magic/distinfo N ports/cad/magic/pkg/DESCR N ports/cad/magic/pkg/PLIST N ports/cad/magic/patches/patch-Makefile N ports/cad/magic/patches/patch-scripts_configure N ports/cad/magic/patches/patch-textio_txInput_c N ports/cad/magic/patches/patch-textio_textioInt_h N ports/cad/magic/patches/patch-utils_magsgtty_h N ports/cad/magic/patches/patch-tcltk_magic_sh_in N ports/cad/magic/patches/patch-utils_paths_h No conflicts created by this import
update: editors/vile
Hi, The following diff update editors/vile to latest version (9.8t) from 2018-11-12. ChangeLog: https://invisible-island.net/vile/CHANGES.html#index-v9_8t Thanks. -- Sebastien Marie Index: Makefile === RCS file: /cvs/ports/editors/vile/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile12 Apr 2016 21:25:22 - 1.1.1.1 +++ Makefile18 Mar 2019 07:46:47 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.1.1.1 2016/04/12 21:25:22 sthen Exp $ COMMENT= VI Editor Like Emacs -DISTNAME= vile-9.8q +DISTNAME= vile-9.8t CATEGORIES=editors HOMEPAGE= http://invisible-island.net/vile/ Index: distinfo === RCS file: /cvs/ports/editors/vile/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo12 Apr 2016 21:25:22 - 1.1.1.1 +++ distinfo18 Mar 2019 07:46:59 - @@ -1,2 +1,2 @@ -SHA256 (vile-9.8q.tgz) = NmsrGOol5V57m2zB0rdS8KT9xFOgoYrt1Xc/RW54Iwc= -SIZE (vile-9.8q.tgz) = 2321373 +SHA256 (vile-9.8t.tgz) = YLKIQyz9MrcUnEzWYoROJpTFq5K8RpsoLzPe1REPbe0= +SIZE (vile-9.8t.tgz) = 2352119 Index: pkg/PLIST === RCS file: /cvs/ports/editors/vile/pkg/PLIST,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 PLIST --- pkg/PLIST 12 Apr 2016 21:25:22 - 1.1.1.1 +++ pkg/PLIST 18 Mar 2019 07:52:04 - @@ -63,6 +63,7 @@ lib/vile/ @bin lib/vile/vile-rpm-filt @bin lib/vile/vile-rtf-filt @bin lib/vile/vile-ruby-filt +@bin lib/vile/vile-rust-filt @bin lib/vile/vile-sccs-filt @bin lib/vile/vile-scheme-filt @bin lib/vile/vile-sed-filt @@ -85,6 +86,10 @@ lib/vile/ @bin lib/vile/vile-xres-filt @bin lib/vile/vile-xs-filt @bin lib/vile/vile-yacc-filt +@bin lib/vile/vile-yaml-filt +@man man/man1/vile-libdir-path.1 +@man man/man1/vile-pager.1 +@man man/man1/vile-to-html.1 @man man/man1/vile.1 share/vile/ share/vile/ada.keywords @@ -165,6 +170,7 @@ share/vile/rexx.keywords share/vile/rpm.keywords share/vile/rtf.keywords share/vile/ruby.keywords +share/vile/rust.keywords share/vile/sccs.keywords share/vile/scheme.keywords share/vile/search.rc @@ -185,6 +191,8 @@ share/vile/ti.keywords share/vile/vb.keywords share/vile/vb6.keywords share/vile/vbs.keywords +share/vile/vcproj.keywords +share/vile/vcxproj.keywords share/vile/vile.hlp share/vile/vile.keywords share/vile/vileinit.rc @@ -199,4 +207,5 @@ share/vile/xres.keywords share/vile/xs.keywords share/vile/xsl.keywords share/vile/yacc.keywords +share/vile/yaml.keywords share/vile/zsh.keywords
Re: [ports-gcc] Unbreak geo/qlandkartegt
On Mon, Mar 18, 2019 at 12:09:01AM +0100, Charlene Wendling wrote: > > > http://build-failures.rhaalovely.net/powerpc/last/geo/qlandkartegt.log > > http://build-failures.rhaalovely.net/sparc64/2019-02-03/geo/qlandkartegt.log > > So this one needs -std=c++11. Once provided there is the usual > / fight later during the build. I tried to be > conservative here, but anyway upstream moved to a remake of its own > software called QMapShack. > > It builds fine on macppc [1] and amd64 [2]. I don't have the > hardware to fully test it, but geotiff maps are fine. > > Any comment? > +# fix error: #error Must have C++11 or newer. > +# XXX this should be retried once moving to ports-gcc>=8 removed :) retired isnt right either i think.. otherwise looks good. Landry
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/03/18 01:15:52 Modified files: devel/glib2mm : Makefile distinfo devel/glib2mm/pkg: PLIST Log message: Update to glib2mm-2.58.1.
