Re: NEW: textproc/epubcheck
Rafael Sadowski writes:
> On Wed Jun 19, 2019 at 02:01:33AM -0600, Anthony J. Bentley wrote:
> > Hi,
> >
> > EPUBCheck is a tool to validate the conformance of EPUB publications agains
> t
> > the EPUB specifications. EPUBCheck can be run as a standalone command-line
> > tool or used as a Java library.
> >
> > EPUBCheck is open source software, maintained by the DAISY Consortium on
> > behalf of the W3C.
> >
> >
> > You can download some epubs to try validating from https://standardebooks.o
> rg/.
> >
> > ok?
> >
> > --
> > Anthony J. Bentley
>
> Why are you installed all jar file under ${PREFIX}/share/epubcheck
It's arbitrary. I considered ${PREFIX}/lib also, but ${PREFIX}/share is
where I usually put large port-specific data like this. (See also: lots
of game ports that put executables and data under ${PREFIX}/share and
only put a wrapper script in ${PREFIX}/bin.)
> and not ${PREFIX}/epubcheck?
Seems a bit weird to put something like this directly under /usr/local,
doesn't it? I tend to reserve it for paths that users will type a lot.
Since no user will ever refer to epubcheck's directories directly, a
deeper hierarchy is no problem...
--
Anthony J. Bentley
Re: NEW: devel/cpputest
On Mon Jun 10, 2019 at 03:00:14PM +0200, Rafael Sadowski wrote: > Please find attach a simple port for cpputest-3.8. This port is needed > by the upcoming weechat update from 2.4 to 2.5. I've been trying to > activate the weechat tests so I need this c++ test framework. > > To stop a lot of clang noise I added the following compiler option: > > CXXFLAGS += -Wno-zero-as-null-pointer-constant \ > -Wno-c++98-compat \ > -Wno-inconsistent-missing-destructor-override \ > -Wno-c++98-compat-pedantic \ > -Wno-cast-qual > > Or do we want all the noise? Tested with upcoming weechat tests on amd64. > Compiles fine with base clang and gcc. > > Information for inst:cpputest-3.8 > > Comment: > unit testing and mocking framework for C/C++ > > Description: > CppUTest is a C /C++ based unit xUnit test framework for unit testing and for > test-driving your code. It is written in C++ but is used in C and C++ projects > and frequently used in embedded systems but it works for any C/C++ project. > > Maintainer: The OpenBSD ports mailing-list > > WWW: https://cpputest.github.io Anybody got a moment to review it?
Re: NEW: textproc/epubcheck
On Wed Jun 19, 2019 at 02:01:33AM -0600, Anthony J. Bentley wrote:
> Hi,
>
> EPUBCheck is a tool to validate the conformance of EPUB publications against
> the EPUB specifications. EPUBCheck can be run as a standalone command-line
> tool or used as a Java library.
>
> EPUBCheck is open source software, maintained by the DAISY Consortium on
> behalf of the W3C.
>
>
> You can download some epubs to try validating from
> https://standardebooks.org/.
>
> ok?
>
> --
> Anthony J. Bentley
Why are you installed all jar file under ${PREFIX}/share/epubcheck and
not ${PREFIX}/epubcheck? That's a JAVA ports pattern? I don't see that
in other JAVA ports.
Re: kibana doesn't work with current node version??
Hi Sebastian, I'll try to update it this weekend. On 06/20, Sebastian Reitenbach wrote: > Hi, > > just updated, or better say freshly installed, > my elkstack host to a snapshot as of today, and starting kibana fails with: > > Kibana does not support the current Node.js version v10.15.3. Please use > Node.js v>=10.15.0 <10.16. -- With best regards, Pavel Korovin
Re: [NEW] security/ghidra
On Thu, Jun 20, 2019 at 04:22:28AM -0600, Anthony J. Bentley wrote:
> Lawrence Teo writes:
> > Here's an updated diff that makes the port fetch all the dependent
> > .jar files prior to building.
> >
> > I also used gradle's --offline flag which explicitly tells gradle to
> > "Execute the build without accessing network resources".
> >
> > Could you please try this diff to see if it resolves your issue?
>
> Thanks. That issue seems to be resolved, but I'm seeing another build
> failure:
>
> > Task :Base:buildHelp FAILED
> Exception in thread "main" ghidra.util.exception.AssertException: Failed to
> create user settings directory:
> /usr/ports/pobj/ghidra-9.0.4/home/.ghidra/.ghidra-9.0.4
> at ghidra.framework.Application.initialize(Application.java:78)
> at
> ghidra.framework.Application.initializeApplication(Application.java:114)
> at help.GHelpBuilder.main(GHelpBuilder.java:73)
>
> FAILURE: Build failed with an exception.
Oops! Sorry, that was a mistake on my part.
I used SUBST_CMD to substitute WRKDIR in GHelpBuilder.java, and
accidentally included the substituted value in my diff when I
regenerated patches.
I have fixed it in this latest diff. Could you please test if it works
for you?
Thanks,
Lawrence
Index: Makefile
===
RCS file: /cvs/ports/security/ghidra/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile11 Jun 2019 00:38:36 - 1.3
+++ Makefile20 Jun 2019 23:15:33 -
@@ -6,9 +6,13 @@ ONLY_FOR_ARCHS = amd64
COMMENT = software reverse engineering (SRE) framework
VERSION = 9.0.4
-REVISION = 0
-DISTNAME = ghidra_9.0.4_PUBLIC_20190516
-PKGNAME = ghidra-${VERSION}
+GHIDRA_DATE = 20190516
+REVISION = 1
+
+GH_ACCOUNT = NationalSecurityAgency
+GH_PROJECT = ghidra
+GH_TAGNAME = Ghidra_${VERSION}_build
+DISTNAME = ghidra-${VERSION}
CATEGORIES = security
@@ -17,32 +21,115 @@ HOMEPAGE = https://www.ghidra-sre.org/
MAINTAINER = Remi Pointel
# Apache v2
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE = Yes
+
+WANTLIB += c m stdc++
-MASTER_SITES = ${HOMEPAGE}
+MASTER_SITES0 =${HOMEPAGE}
+MASTER_SITES1 =
https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-${YAJSW_VER}/
+MASTER_SITES2 =https://repo.maven.apache.org/maven2/
EXTRACT_SUFX = .zip
+ST4_VER = 4.1
+HAMCREST_VER = 1.3
+JAVACC_VER = 5.0
+JMOCKIT_VER = 1.44
+JSON_SIMPLE_VER = 1.1.1
+JUNIT_VER =4.12
+YAJSW_VER =12.12
+
+JAR_DISTFILES += ST4{org/antlr/ST4/${ST4_VER}/ST4}-${ST4_VER}.jar
+JAR_DISTFILES +=
hamcrest{org/hamcrest/hamcrest-all/${HAMCREST_VER}/hamcrest}-all-${HAMCREST_VER}.jar
+JAR_DISTFILES +=
javacc{net/java/dev/javacc/javacc/${JAVACC_VER}/javacc}-${JAVACC_VER}.jar
+JAR_DISTFILES +=
jmockit{org/jmockit/jmockit/${JMOCKIT_VER}/jmockit}-${JMOCKIT_VER}.jar
+JAR_DISTFILES +=
json-simple{com/googlecode/json-simple/json-simple/${JSON_SIMPLE_VER}/json-simple}-${JSON_SIMPLE_VER}.jar
+JAR_DISTFILES += junit{junit/junit/${JUNIT_VER}/junit}-${JUNIT_VER}.jar
+
+DISTFILES =${DISTNAME}.tar.gz
+DISTFILES += ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}${EXTRACT_SUFX}:0
+DISTFILES += yajsw-stable-${YAJSW_VER}${EXTRACT_SUFX}:1
+DISTFILES += ${JAR_DISTFILES:C/$/:2/}
+
+EXTRACT_ONLY = ${DISTNAME}.tar.gz
+
MODULES = java
MODJAVA_VER = 11+
+BUILD_DEPENDS =archivers/unzip \
+ devel/bison \
+ java/gradle \
+ shells/bash
+
RUN_DEPENDS = shells/bash \
java/javaPathHelper
-NO_BUILD = Yes
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/${PKGNAME:S/-/_/}
+SUBST_VARS += GHIDRA_DATE VERSION WRKDIR
+
+JAR_DIRS +=Features-FileFormats
+JAR_DIRS +=Features-Python
+JAR_DIRS +=Framework-Docking
+JAR_DIRS +=Framework-FileSystem
+JAR_DIRS +=Framework-Generic
+JAR_DIRS +=Framework-Graph
+JAR_DIRS +=Framework-Project
+JAR_DIRS +=Framework-SoftwareModeling
post-extract:
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/ghidraRun
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/ghidraRun
+ @perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/support/launch.sh
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
+ @perl -pi -e 's,(application.version)=.*,\1=${VERSION},' \
+ ${WRKSRC}/Ghidra/application.properties
+
+# Steps derived
Re: vulkan ports
On Thu, Jun 20, 2019 at 05:22:53PM +1000, Jonathan Gray wrote: [...] > > I hit an abort trap with coredump on both Skylake and Vega 64 (the > > latter w/ amdgpu). I don't recall an issue with vulkaninfo with sdk > > version 1.1.104. vkcube still runs fine on both. Will take a deeper dive > > to see what's going on with vulkaninfo that I missed... > > I see the same problem described here on broadwell, vkcube also runs. > Linux seems to be more forgiving of getting pthreads wrong. > > Perhaps we revert > https://github.com/KhronosGroup/Vulkan-Loader/commit/ecb0b1e69fb2f4d3cae262e6da24c170ce62ae13 > ? [...] Thanks for the hint; that fixed vulkaninfo on both my Skylake and Vega! Now getting full vulkaninfo on both without any segfault or abort trap. Also tested vkcupe and vkcubepp, as well as vkquake on the Vega + amdgpu... and emulators/dolphin with vulkan backend on the Skylake :] Updated tarball attached that reverts the above commit and has the missing MAINTAINER line for vulkan-headers. ok? vulkan-ports-thfr-1.108.tgz Description: Binary data
kibana doesn't work with current node version??
Hi, just updated, or better say freshly installed, my elkstack host to a snapshot as of today, and starting kibana fails with: Kibana does not support the current Node.js version v10.15.3. Please use Node.js v>=10.15.0 <10.16. OpenBSD 6.5-current (GENERIC) #42: Wed Jun 19 21:41:26 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC /etc/rc.d/kibana -d start doing _rc_parse_conf doing _rc_quirks kibana_flags >--config /etc/kibana/kibana.yml< doing _rc_parse_conf /var/run/rc.d/kibana doing _rc_quirks doing rc_check kibana doing rc_start doing _rc_wait start No home directory /nonexistent! Logging in with home = "/". doing rc_check Kibana does not support the current Node.js version v10.15.3. Please use Node.js v>=10.15.0 <10.16. doing _rc_rm_runfile (failed) root@memory-alpha:~# pkg_info | grep -e kibana -e node kibana-6.6.1p0 browser based analytics/search interface to ElasticSearch node-10.15.3V8 JavaScript for clients and servers is it just me, or someone else sees the same? when I manually change /usr/local/kibana/package.json the node engine version to "10.15.3" it just starts, but using this range, which from my googling foo should be correct, I get this startup error. cheers, Sebastian
audio/taglib: Fix possible Ogg packet losses.
The attached diff fixes this nasty issue:
https://github.com/taglib/taglib/issues/864
It is easy to reproduce, for example with audio/clementine,
see https://github.com/clementine-player/Clementine/issues/5524
ok?
Index: Makefile
===
RCS file: /cvs/ports/audio/taglib/Makefile,v
retrieving revision 1.43
diff -u -p -u -p -r1.43 Makefile
--- Makefile24 Oct 2018 14:27:58 - 1.43
+++ Makefile20 Jun 2019 20:22:03 -
@@ -2,7 +2,7 @@
COMMENT= managing meta-data of audio formats
DISTNAME= taglib-1.11.1
-REVISION= 1
+REVISION= 2
CATEGORIES=audio devel
Index: patches/patch-taglib_ogg_oggfile_cpp
===
RCS file: patches/patch-taglib_ogg_oggfile_cpp
diff -N patches/patch-taglib_ogg_oggfile_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-taglib_ogg_oggfile_cpp20 Jun 2019 20:22:03 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Fix possible Ogg packet losses.
+https://github.com/taglib/taglib/issues/864
+https://github.com/taglib/taglib/commit/9336c82
+
+Index: taglib/ogg/oggfile.cpp
+--- taglib/ogg/oggfile.cpp.orig
taglib/ogg/oggfile.cpp
+@@ -253,7 +253,7 @@ void Ogg::File::writePacket(unsigned int i, const Byte
+ ByteVectorList packets = firstPage->packets();
+ packets[i - firstPage->firstPacketIndex()] = packet;
+
+- if(firstPage != lastPage && lastPage->packetCount() > 2) {
++ if(firstPage != lastPage && lastPage->packetCount() > 1) {
+ ByteVectorList lastPagePackets = lastPage->packets();
+ lastPagePackets.erase(lastPagePackets.begin());
+ packets.append(lastPagePackets);
Re: Qt5's libtool link scripts are unusable
On Thu Jun 20, 2019 at 04:46:59PM +0100, Stuart Henderson wrote:
> Thanks for the report,
>
> On 2019/06/20 17:30, Vadim Penzin wrote:
> > I admit that I am not familiar with the release process of pre-built binary
> > packages; I might be writing to a wrong mailing list and I apologize in
> > advance.
>
> ports@ is the better list for this, I've CC'd and set reply-to.
>
> > All libtool scripts from qt5 (/usr/local/lib/qt5/*.la) contain the following
> > on their third line:
> >
> > LIBQt5XXX_VERSION=5.9# The name that we can dlopen(3).
> >
> > (XXX above stands for the name of a particular library, such as Core,
> > Network, etc.)
> >
> > Since shell scripts (that libtool generates) source .la files, sh(1) fails
> > on unexpected '(' because someone, somewhere omitted a space before the
> > comment.
> >
> > Patching /usr/local/lib/qt5/*.la files programmatically by tucking a space
> > before the hash character brings linking with Qt5 assisted (encumbered?) by
> > libtool back to life.
> >
> > --Vadim
> >
>
> This patch to the qtbase port should fix the problem at source (I'll leave
> it building and test later). However it will also require REVISION bumps
> on all ports including .la files produced by this.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/qt5/qtbase/Makefile,v
> retrieving revision 1.29
> diff -u -p -w -u -r1.29 Makefile
> --- Makefile 20 May 2019 22:15:29 - 1.29
> +++ Makefile 20 Jun 2019 15:43:00 -
> @@ -15,13 +15,13 @@ PKGNAME-global = qt5-global-${VERSION}
> PKGNAME-psql = qt5-postgresql-${VERSION}
> PKGNAME-sqlite2 =qt5-sqlite2-${VERSION}
> PKGNAME-tds =qt5-tds-${VERSION}
> +
> REVISION-global = 0
> +REVISION-main = 5
> REVISION-mysql = 0
> REVISION-psql = 0
> REVISION-sqlite2 = 0
> REVISION-tds = 0
> -
> -REVISION-main = 4
>
> PKG_ARCH-global =*
> PKG_ARCH-examples = *
> Index: patches/patch-qmake_generators_unix_unixmake2_cpp
> ===
> RCS file:
> /cvs/ports/x11/qt5/qtbase/patches/patch-qmake_generators_unix_unixmake2_cpp,v
> retrieving revision 1.3
> diff -u -p -w -u -r1.3 patch-qmake_generators_unix_unixmake2_cpp
> --- patches/patch-qmake_generators_unix_unixmake2_cpp 5 Jul 2018 09:49:13
> - 1.3
> +++ patches/patch-qmake_generators_unix_unixmake2_cpp 20 Jun 2019 15:43:00
> -
> @@ -136,13 +136,14 @@ Index: qmake/generators/unix/unixmake2.c
> } else if (!project->isEmpty("QMAKE_AIX_SHLIB")) {
>
> project->values("TARGET_").append(project->first("QMAKE_PREFIX_STATICLIB") +
> project->first("TARGET")
> + "." + project->first("QMAKE_EXTENSION_STATICLIB"));
> -@@ -1465,18 +1498,32 @@ UnixMakefileGenerator::writeLibtoolFile()
> +@@ -1465,18 +1498,33 @@ UnixMakefileGenerator::writeLibtoolFile()
> << QT_VERSION_STR << ")";
> t << "\n";
>
> +if (!project->isEmpty("QMAKE_OPENBSD_SHLIB"))
> + t << "LIB" << fileVar("QMAKE_ORIG_TARGET") << "_VERSION="
> -+<< project->first("VER_MAJ") << "." << project->first("VER_MIN");
> ++<< project->first("VER_MAJ") << "." << project->first("VER_MIN")
> ++<< "\n";
This's what Qt 5.13 doas. They use "<< endl;" instead of "<< "\n";", I
would like to prefer that. std::endl calls std::flush which synchronizes
with the underlying storage device.
RS
> +
> t << "# The name that we can dlopen(3).\n"
> - << "dlname='" << fileVar(project->isActiveConfig("plugin") ? "TARGET"
> : "TARGET_x")
>
devel/monotone i386 breakage, maybe following libc++ update?
devel/monotone now fails to build on i386. During the build it runs its own-built "mtn" binary to produce manpages, which fails (segfaults), fails to produce the manpage file, so packaging fails, making the problem noticable. It uses C++ and the failure started after the libc++ update. Seems repeatable.
Re: Qt5's libtool link scripts are unusable
Thanks for the report,
On 2019/06/20 17:30, Vadim Penzin wrote:
> I admit that I am not familiar with the release process of pre-built binary
> packages; I might be writing to a wrong mailing list and I apologize in
> advance.
ports@ is the better list for this, I've CC'd and set reply-to.
> All libtool scripts from qt5 (/usr/local/lib/qt5/*.la) contain the following
> on their third line:
>
> LIBQt5XXX_VERSION=5.9# The name that we can dlopen(3).
>
> (XXX above stands for the name of a particular library, such as Core,
> Network, etc.)
>
> Since shell scripts (that libtool generates) source .la files, sh(1) fails
> on unexpected '(' because someone, somewhere omitted a space before the
> comment.
>
> Patching /usr/local/lib/qt5/*.la files programmatically by tucking a space
> before the hash character brings linking with Qt5 assisted (encumbered?) by
> libtool back to life.
>
> --Vadim
>
This patch to the qtbase port should fix the problem at source (I'll leave
it building and test later). However it will also require REVISION bumps
on all ports including .la files produced by this.
Index: Makefile
===
RCS file: /cvs/ports/x11/qt5/qtbase/Makefile,v
retrieving revision 1.29
diff -u -p -w -u -r1.29 Makefile
--- Makefile20 May 2019 22:15:29 - 1.29
+++ Makefile20 Jun 2019 15:43:00 -
@@ -15,13 +15,13 @@ PKGNAME-global =qt5-global-${VERSION}
PKGNAME-psql = qt5-postgresql-${VERSION}
PKGNAME-sqlite2 = qt5-sqlite2-${VERSION}
PKGNAME-tds = qt5-tds-${VERSION}
+
REVISION-global = 0
+REVISION-main =5
REVISION-mysql = 0
REVISION-psql =0
REVISION-sqlite2 = 0
REVISION-tds = 0
-
-REVISION-main =4
PKG_ARCH-global = *
PKG_ARCH-examples =*
Index: patches/patch-qmake_generators_unix_unixmake2_cpp
===
RCS file:
/cvs/ports/x11/qt5/qtbase/patches/patch-qmake_generators_unix_unixmake2_cpp,v
retrieving revision 1.3
diff -u -p -w -u -r1.3 patch-qmake_generators_unix_unixmake2_cpp
--- patches/patch-qmake_generators_unix_unixmake2_cpp 5 Jul 2018 09:49:13
- 1.3
+++ patches/patch-qmake_generators_unix_unixmake2_cpp 20 Jun 2019 15:43:00
-
@@ -136,13 +136,14 @@ Index: qmake/generators/unix/unixmake2.c
} else if (!project->isEmpty("QMAKE_AIX_SHLIB")) {
project->values("TARGET_").append(project->first("QMAKE_PREFIX_STATICLIB") +
project->first("TARGET")
+ "." + project->first("QMAKE_EXTENSION_STATICLIB"));
-@@ -1465,18 +1498,32 @@ UnixMakefileGenerator::writeLibtoolFile()
+@@ -1465,18 +1498,33 @@ UnixMakefileGenerator::writeLibtoolFile()
<< QT_VERSION_STR << ")";
t << "\n";
+if (!project->isEmpty("QMAKE_OPENBSD_SHLIB"))
+ t << "LIB" << fileVar("QMAKE_ORIG_TARGET") << "_VERSION="
-+<< project->first("VER_MAJ") << "." << project->first("VER_MIN");
++<< project->first("VER_MAJ") << "." << project->first("VER_MIN")
++<< "\n";
+
t << "# The name that we can dlopen(3).\n"
- << "dlname='" << fileVar(project->isActiveConfig("plugin") ? "TARGET" :
"TARGET_x")
Re: Fix textproc/py-commonmark tests by adding TEST_DEPENDS on itself
On 2019/06/20 15:56, Jeremie Courreges-Anglas wrote:
> On Thu, Jun 20 2019, Kurt Mosiejczuk wrote:
> > Paco Esteban just had trouble running the tests for py-commonmark because
> > the module needs itself installed to run the tests. This simple diff
> > adds itself to the TEST_DEPENDS to fix that.
>
> Not objecting, but there's another approach which I tend to prefer: use
> PYTHONPATH so that the tested code is the code actually being built and
> packaged. Skipping the update/reinstall step also makes testing updates
> easier.
>
> Suggested approach, "624 tests passed, 0 failed" both with py2
> and py3.
>
> > Tweak the PERMIT line to the new style while here.
> >
> > cc sebastia@ (maintainer)
>
>
> --- Makefile.~1.5.~ Thu Jun 20 15:42:58 2019
> +++ Makefile Thu Jun 20 15:49:36 2019
> @@ -24,6 +24,8 @@ RUN_DEPENDS=devel/py-future${MODPY_FLAVOR}
> TEST_DEPENDS=devel/flake8 \
> devel/py-hypothesis${MODPY_FLAVOR}
>
> +TEST_ENV=PYTHONPATH="."
> +
> post-install:
> mv ${PREFIX}/bin/cmark ${PREFIX}/bin/commonmark${MODPY_BIN_SUFFIX}
>
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
I think that is preferable and I would like to see it in more ports in the
tree so when I search for a random example I'm more likely to find it than
the common "TEST_DEPENDS=(self)" type.. :-)
python.port.mk, update-plist, MODPY_ABI3SO
MODPY_ABI3SO is used for python .so files which have a name like
foo.abi3.so - it is set to either ".abi3" or "" (blank), so plist
entries for these look like
lib/python${MODPY_VERSION}/site-packages/bcrypt/_bcrypt${MODPY_ABI3SO}.so
The current UPDATE_PLIST_ARGS uses -S ("match only at end of path")
which can't work with this (running update-plist strips the substitution).
I think it should just be changed to -I, does that makes sense?
Index: python.port.mk
===
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.113
diff -u -p -r1.113 python.port.mk
--- python.port.mk 18 May 2019 18:56:45 - 1.113
+++ python.port.mk 20 Jun 2019 13:59:54 -
@@ -190,7 +190,7 @@ SUBST_VARS := MODPY_PYCACHE MODPY_COMMEN
MODPY_PY_PREFIX MODPY_PYOEXTENSION ${SUBST_VARS}
UPDATE_PLIST_ARGS += -S MODPY_BIN_SUFFIX -S MODPY_PYOEXTENSION \
--S MODPY_ABI3SO -c MODPY_COMMENT -I MODPY_PYCACHE
+-I MODPY_ABI3SO -c MODPY_COMMENT -I MODPY_PYCACHE
# set MODPY_BIN for executable scripts
MODPY_BIN_ADJ =perl -pi \
I considered changing MODPY_ABI3SO to set to ".abi3.so" or ".so",
which would work with the existing UPDATE_PLIST_ARGS, but will cause
a horrible mess as all "foo.so" files in ports that use the python
module but don't use FLAVOR=python3 will then get updated to
"foo${MODPY_ABI3SO}" which is going to be wrong in many cases.
Re: Fix textproc/py-commonmark tests by adding TEST_DEPENDS on itself
On Thu, Jun 20 2019, Kurt Mosiejczuk wrote:
> Paco Esteban just had trouble running the tests for py-commonmark because
> the module needs itself installed to run the tests. This simple diff
> adds itself to the TEST_DEPENDS to fix that.
Not objecting, but there's another approach which I tend to prefer: use
PYTHONPATH so that the tested code is the code actually being built and
packaged. Skipping the update/reinstall step also makes testing updates
easier.
Suggested approach, "624 tests passed, 0 failed" both with py2
and py3.
> Tweak the PERMIT line to the new style while here.
>
> cc sebastia@ (maintainer)
--- Makefile.~1.5.~ Thu Jun 20 15:42:58 2019
+++ MakefileThu Jun 20 15:49:36 2019
@@ -24,6 +24,8 @@ RUN_DEPENDS= devel/py-future${MODPY_FLAVOR}
TEST_DEPENDS= devel/flake8 \
devel/py-hypothesis${MODPY_FLAVOR}
+TEST_ENV= PYTHONPATH="."
+
post-install:
mv ${PREFIX}/bin/cmark ${PREFIX}/bin/commonmark${MODPY_BIN_SUFFIX}
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Fix textproc/py-commonmark tests by adding TEST_DEPENDS on itself
sure
Re: [NEW] security/ghidra
Hi Lawrence, Lawrence Teo writes: > Here's an updated diff that makes the port fetch all the dependent > .jar files prior to building. > > I also used gradle's --offline flag which explicitly tells gradle to > "Execute the build without accessing network resources". > > Could you please try this diff to see if it resolves your issue? Thanks. That issue seems to be resolved, but I'm seeing another build failure: > Task :Base:buildHelp FAILED Exception in thread "main" ghidra.util.exception.AssertException: Failed to create user settings directory: /usr/ports/pobj/ghidra-9.0.4/home/.ghidra/.ghidra-9.0.4 at ghidra.framework.Application.initialize(Application.java:78) at ghidra.framework.Application.initializeApplication(Application.java:114) at help.GHelpBuilder.main(GHelpBuilder.java:73) FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':Base:buildHelp'. > Process 'command '/usr/local/jdk-11/bin/java'' finished with non-zero exit > value 1 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 42s 13 actionable tasks: 13 executed *** Error 1 in . (Makefile:118 'do-build')
[update] devel/flake8 (and dependencies)
Hi ports@,
Here's an update for devel/flake8 from 3.5.0 to 3.7.7.
The version now in ports always throws an error (it's py-codestyle's
fault, but that upgrade makes flake8 not to work ...) and pollutes the
results (like vim quickfix list for instance). You can see it here:
https://github.com/PyCQA/pycodestyle/issues/728
There are quite a few changes between those 2 versions, you can see them
here:
http://flake8.pycqa.org/en/latest/release-notes/index.html#x-release-series
I had to update some dependencies too:
devel/pyflakes 1.5.0 --> 2.1.1
https://github.com/PyCQA/pyflakes/blob/master/NEWS.rst
devel/py-entrypoints 0.2.3 --> 0.3
devel/py-codestyle 2.3.1 --> 2.5.0
https://github.com/PyCQA/pycodestyle/blob/master/CHANGES.txt
All pass tests and install correctly (py3 on amd64).
I also checked what depends on those. There the tests are not so good,
but I'm not sure what was the status before, so I'll put it here. I cced
the maintainers of flake8 and pyflakes.
Some of them have an insane amount of dependencies just to run tests, so
I would appreciate guidance on how to do this properly. Should I test +
install all of them ?
dependent on devel/flake8 (all of them TEST_DEPENDS):
www/youtube-dl
it took hours ...
Ran 2386 tests in 18354.702s
FAILED (errors=826, failures=322)
sysutils/ranger
Test crashes with: https://onna.be/paste/ranger_crash.txt
net/py-libcloud
2 failed, 9165 passed, 19 skipped, 534 warnings
seems related to paramikossh ??
textproc/py-commonmark
test fails with
ModuleNotFoundError: No module named 'CommonMark'
dependent on devel/pyflakes:
security/py-yaswfp
all tests pass
devel/spyder/spyder
did not check
dependent on devel/py-entrypoints:
devel/py-nbconvert
did not check
dependent on devel/py-codestyle:
games/freeorion
did not check
sysutil/d-feet
did not check
www/urlmatch
all tests pass
And finally the diffs:
cvs server: Diffing .
Index: Makefile
===
RCS file: /cvs/ports/devel/flake8/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile15 May 2019 12:04:35 - 1.15
+++ Makefile19 Jun 2019 18:53:14 -
@@ -2,9 +2,8 @@
COMMENT = modular python code checker wrapping pep8 and pyflakes
-MODPY_EGG_VERSION =3.5.0
+MODPY_EGG_VERSION =3.7.7
DISTNAME = flake8-${MODPY_EGG_VERSION}
-REVISION = 0
CATEGORIES = devel
@@ -26,6 +25,7 @@ MODPY_PYTEST_ARGS = tests
TEST_DEPENDS = devel/py-mock${MODPY_FLAVOR}
RUN_DEPENDS = devel/py-codestyle${MODPY_FLAVOR} \
+ devel/py-entrypoints${MODPY_FLAVOR} \
devel/py-mccabe${MODPY_FLAVOR} \
devel/pyflakes${MODPY_FLAVOR}
Index: distinfo
===
RCS file: /cvs/ports/devel/flake8/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo21 Jan 2018 23:49:25 - 1.7
+++ distinfo19 Jun 2019 18:53:14 -
@@ -1,2 +1,2 @@
-SHA256 (flake8-3.5.0.tar.gz) = clMmX3q9izE+OJKUQESjZeP0rD/Nz7Qpj1Xund8Yi6A=
-SIZE (flake8-3.5.0.tar.gz) = 140608
+SHA256 (flake8-3.7.7.tar.gz) = hZmWBz80HyZwdBtR7B5noB2hQoMaof3GJC2/iN/75mE=
+SIZE (flake8-3.7.7.tar.gz) = 148457
cvs server: Diffing patches
Index: patches/patch-setup_py
===
RCS file: patches/patch-setup_py
diff -N patches/patch-setup_py
--- patches/patch-setup_py 21 Jan 2018 23:49:25 - 1.7
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-setup_py,v 1.7 2018/01/21 23:49:25 danj Exp $
-
-Index: setup.py
setup.py.orig
-+++ setup.py
-@@ -24,7 +24,6 @@ requires = [
- "pyflakes >= 1.5.0, < 1.7.0",
- "pycodestyle >= 2.0.0, < 2.4.0",
- "mccabe >= 0.6.0, < 0.7.0",
--"setuptools >= 30",
- ]
-
- extras_require = {
cvs server: Diffing pkg
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/flake8/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST 21 Jan 2018 23:49:25 - 1.5
+++ pkg/PLIST 19 Jun 2019 18:53:14 -
@@ -10,7 +10,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/flake8-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/flake8/__init__.py
lib/python${MODPY_VERSION}/site-packages/flake8/__main__.py
-lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}/
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/flake8/${MODPY_PYCACHE}checker.${MODPY_PYC_MAGIC_TAG}pyc
@@ -
Re: [NEW] slant-0.0.20
Kristaps Dzonsons writes:
> Enclosed is a port attempt for slant, https://kristaps.bsd.lv/slant.
> Depends on openradtool, which was recently submitted by jturner.
>
> Previous attempts tried to be too smart about stopping the collector and
> CGI script. This just YOLOs and jams in an upgraded database schema.
> The schema upgrade is programmatic, dictated by openradtool.
>
> http://openbsd-archive.7691.n7.nabble.com/NEW-slant-0-0-10-td352814.html
> http://openbsd-archive.7691.n7.nabble.com/NEW-ping-slant-0-0-17-td357219.html
Missing LIB_DEPENDS/WANTLIB for sqlite.
I think /var should be ${VARBASE} in plist also.
Other than that it looks fine to me.
--
Anthony J. Bentley
Re: vulkan ports
On Wed, Jun 19, 2019 at 12:26:05AM -0600, Thomas Frohwein wrote: > On Wed, Jun 19, 2019 at 03:15:15PM +1000, Jonathan Gray wrote: > [...] > > This collection of ports no longer seems to work on inteldrm with ivy > > bridge. > > > > spirv-headers-1.4.1 SPIRV-Headers > > spirv-tools-2019.3 API and commands for processing SPIR-V > > vulkan-headers-1.1.108.0 Vulkan header files > > vulkan-loader-1.1.108.0 Vulkan ICD loader > > vulkan-tools-1.1.108.0 Vulkan Utilities and Tools > > vulkan-validation-layers-1.1.108.0 Vulkan Validation Layers > > I hit an abort trap with coredump on both Skylake and Vega 64 (the > latter w/ amdgpu). I don't recall an issue with vulkaninfo with sdk > version 1.1.104. vkcube still runs fine on both. Will take a deeper dive > to see what's going on with vulkaninfo that I missed... I see the same problem described here on broadwell, vkcube also runs. Linux seems to be more forgiving of getting pthreads wrong. Perhaps we revert https://github.com/KhronosGroup/Vulkan-Loader/commit/ecb0b1e69fb2f4d3cae262e6da24c170ce62ae13 ? commit ecb0b1e69fb2f4d3cae262e6da24c170ce62ae13 (tag: sdk-1.1.108.0, origin/sdk-1.1.108, origin/master, origin/HEAD) Author: baldurk Date: Mon Jun 10 13:07:40 2019 +0100 loader: Call through layers for device extensions If we reach the terminator function then we look up json properties per-layer there. This allows layers to participate in the enumeration and filter the list of extensions before they reach the application. Layers: count = 7 === VK_LAYER_GOOGLE_threading (Google Validation Layer) Vulkan version 1.1.108, layer version 1 Layer Extensionscount = 1 VK_EXT_debug_report : extension revision 6 Devices count = 1 GPU id : 0 (Intel(R) HD Graphics 5500 (Broadwell GT2)) Program received signal SIGABRT, Aborted. thrkill () at -:3 3 -: No such file or directory. in - Current language: auto; currently asm (gdb) bt #0 thrkill () at -:3 #1 0x014f753231fe in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #2 0x014f75309812 in _libc_pthread_mutex_unlock (mutexp=0x150132a1a80) at /usr/src/lib/libc/thread/rthread_mutex.c:265 #3 0x01501a9d25f0 in vkEnumerateDeviceExtensionProperties () from /usr/local/lib/libvulkan.so.0.0 #4 0x014d51e7a4ca in AppGetPhysicalDeviceLayerExtensions () from /usr/local/bin/vulkaninfo #5 0x014d51e7692d in main () from /usr/local/bin/vulkaninfo > > == > VULKANINFO > == > > Vulkan Instance Version: 1.1.108 > > > > Instance Extensions: > > Instance Extensions count = 16 > VK_EXT_acquire_xlib_display : extension revision 1 > VK_EXT_debug_report : extension revision 8 > VK_EXT_debug_utils : extension revision 1 > VK_EXT_direct_mode_display : extension revision 1 > VK_EXT_display_surface_counter : extension revision 1 > VK_KHR_device_group_creation: extension revision 1 > VK_KHR_display : extension revision 23 > VK_KHR_external_fence_capabilities : extension revision 1 > VK_KHR_external_memory_capabilities : extension revision 1 > VK_KHR_external_semaphore_capabilities: extension revision 1 > VK_KHR_get_display_properties2 : extension revision 1 > VK_KHR_get_physical_device_properties2: extension revision 1 > VK_KHR_get_surface_capabilities2: extension revision 1 > VK_KHR_surface : extension revision 25 > VK_KHR_xcb_surface : extension revision 6 > VK_KHR_xlib_surface : extension revision 6 > Layers: count = 7 > === > VK_LAYER_GOOGLE_threading (Google Validation Layer) Vulkan version 1.1.108, > layer version 1 > Layer Extensionscount = 1 > VK_EXT_debug_report : extension revision 6 > Abort trap (core dumped) > > Core was generated by `vulkaninfo'. > Program terminated with signal SIGABRT, Aborted. > #0 thrkill () at -:3 > 3 -: No such file or directory. > (gdb) bt full > #0 thrkill () at -:3 > No locals. > #1 0x07756ecdc73e in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > mask = 4294967263 > sa = > #2 0x07756ed4edb2 in _libc_pthread_mutex_unlock (mutexp=) > at /usr/src/lib/libc/thread/rthread_mutex.c:265 > mutex = 0x7758fdf8c60 > self = 0x7756ed58450 <_initial_thread> > #3 0x07753992d5f0 in vkEnumerateDeviceExtensionProperties () > from /usr/local/lib/libvulkan.so.0.0 > No symbol table info available. > #4 0x07732ab774ca in AppGetPhysicalDeviceLayerExtensions () > No symbol table info available. > #5 0x07732ab7392d in main () > No symbol table info available. > (gdb) > > > > > $ vulkaninfo > > == > > VULKANINFO > > == > > > >
Prepare for gpsd-3.x
Hi!
Long time ago I've started update of gpsd from 2.x to 3.x.
Upstream moved from auto crap to scons so it gave me some
headache.
Before switching to new gpsd we need to prepare some ports
which are linking against libgps because API has changed.
Here are the diffs for foxtrotgps, geoclue and qlandkaretegt.
(diff for geo/viking is still WIP):
Index: patches/patch-src_gps_functions_c
===
RCS file: patches/patch-src_gps_functions_c
diff -N patches/patch-src_gps_functions_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_gps_functions_c 14 Jun 2019 07:04:02 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+Fix build with newer gpsd API.
+https://bazaar.launchpad.net/~foxtrotgps-team/foxtrotgps/trunk/revision/316
+
+Index: src/gps_functions.c
+--- src/gps_functions.c.orig
src/gps_functions.c
+@@ -738,7 +738,11 @@ cb_gpsd_data(GIOChannel *src, GIOCondition condition,
+ if (!libgps_initialized)
+ return FALSE;
+
++#if GPSD_API_MAJOR_VERSION >= 7 /* API change. gpsd version 3.18 and
subsequent. */
++ ret = gps_read(&libgps_gpsdata, NULL, 0);
++#else
+ ret = gps_read(&libgps_gpsdata);
++#endif
+ /* Note that gps_read() will never actually return 0
+ (zero-length reads are converted internally to a -1 return,
+ since they mean that the connection to the daemon has closed),
Index: patches/patch-providers_gpsd_geoclue-gpsd_c
===
RCS file: patches/patch-providers_gpsd_geoclue-gpsd_c
diff -N patches/patch-providers_gpsd_geoclue-gpsd_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-providers_gpsd_geoclue-gpsd_c 14 Jun 2019 07:11:23 -
@@ -0,0 +1,72 @@
+$OpenBSD$
+
+Fix build with newer gpsd API.
+
+--- providers/gpsd/geoclue-gpsd.c.orig Tue Jul 31 20:47:05 2012
providers/gpsd/geoclue-gpsd.c Sun Mar 27 12:35:47 2016
+@@ -40,7 +40,12 @@
+ #include
+ #include
+
++#if GPSD_API_MAJOR_VERSION >= 5
++/* gps_data conflicts with gps_data function */
++typedef struct gps_data_t gps_data_l;
++#else
+ typedef struct gps_data_t gps_data;
++#endif
+ typedef struct gps_fix_t gps_fix;
+
+ /* only listing used tags */
+@@ -59,7 +64,11 @@ typedef struct {
+ char *host;
+ char *port;
+
++#if GPSD_API_MAJOR_VERSION >= 5
++ gps_data_l *gpsdata;
++#else
+ gps_data *gpsdata;
++#endif
+
+ gps_fix *last_fix;
+
+@@ -397,10 +406,16 @@ geoclue_gpsd_stop_gpsd (GeoclueGpsd *self)
+ static gboolean
+ geoclue_gpsd_start_gpsd (GeoclueGpsd *self)
+ {
++#if GPSD_API_MAJOR_VERSION >= 5
++ int status = gps_open (self->host, self->port, self->gpsdata);
++ if (status == 0) {
++ gps_stream(self->gpsdata, WATCH_ENABLE | WATCH_NMEA, NULL);
++#else
+ self->gpsdata = gps_open (self->host, self->port);
+ if (self->gpsdata) {
+ gps_stream(self->gpsdata, WATCH_ENABLE | WATCH_NMEA |
POLL_NONBLOCK, NULL);
+ gps_set_raw_hook (self->gpsdata, gpsd_raw_hook);
++#endif
+ return TRUE;
+ } else {
+ g_warning ("gps_open() failed, is gpsd running
(host=%s,port=%s)?",
self->host, self->port);
+@@ -413,10 +428,23 @@ gpsd_poll(gpointer data)
+ {
+ GeoclueGpsd *self = (GeoclueGpsd*)data;
+ if (self->gpsdata) {
++#if GPSD_API_MAJOR_VERSION >= 5
++ /* gps_poll and gps_set_raw_hook no longer present in this API
version */
++ if (gps_waiting(self->gpsdata, 500)) {
++ if (gps_read(self->gpsdata) == -1) {
++ geoclue_gpsd_set_status (self,
GEOCLUE_STATUS_ERROR);
++ geoclue_gpsd_stop_gpsd(self);
++ return FALSE;
++ } else {
++ /* Call existing raw_hook to process the data */
++ gpsd_raw_hook(self->gpsdata, NULL, 0);
++ }
++#else
+ if (gps_poll(self->gpsdata) < 0) {
+ geoclue_gpsd_set_status (self, GEOCLUE_STATUS_ERROR);
+ geoclue_gpsd_stop_gpsd(self);
+ return FALSE;
++#endif
+ }
+ }
+ return TRUE;
__
Index: patches/patch-src_CDeviceGPSD_cpp
===
RCS file: patches/patch-src_CDeviceGPSD_cpp
diff -N patches/patch-src_CDeviceGPSD_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_CDeviceGPSD_cpp 16 Jun 2019 07:14:21 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Fix build with newer gpsd API
+
+Index: src/CDeviceGPSD.cpp
+--- src/CDeviceGPSD.cpp.orig
src/CDeviceGPSD.cpp
+@@ -212,7 +212,9 @@ void CGPSDThread::run()
+ }// if
+ else if( FD_ISSET( gpsdata->gps_fd, &fds ) )
+
