[macppc/arm] Unbreak misc/openbabel (was: Re: powerpc bulk build report)

2019-06-16 Thread Charlene Wendling
Hi,

> http://build-failures.rhaalovely.net//powerpc/2019-05-19/misc/openbabel.log
> http://build-failures.rhaalovely.net/arm/2019-04-30/misc/openbabel.log
> http://build-failures.rhaalovely.net/aarch64/2019-06-09/misc/openbabel.log

It's a typical narrowing error we've here.

Upstream has fixes [0] for it, and once applied, it builds fine on
macppc [1] and amd64. 'make test' passes as well.

Comments/feedback are welcome!

Charlène.


[0] https://github.com/openbabel/openbabel/pull/1744
[1] http://0x0.st/zeBS.txt


Index: Makefile
===
RCS file: /cvs/ports/misc/openbabel/Makefile,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 Makefile
--- Makefile24 Oct 2018 14:28:08 -  1.26
+++ Makefile16 Jun 2019 07:04:56 -
@@ -4,7 +4,7 @@ COMMENT=chemistry file translation prog
 
 V= 2.2.3
 DISTNAME=  openbabel-${V}
-REVISION=  7
+REVISION=  8
 CATEGORIES=misc
 
 SUBST_VARS=V
Index: patches/patch-src_formats_pngformat_cpp
===
RCS file: patches/patch-src_formats_pngformat_cpp
diff -N patches/patch-src_formats_pngformat_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_formats_pngformat_cpp 16 Jun 2019 07:04:56 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Fix the build on archs where char is unsigned by default (arm,ppc)
+see:
+https://github.com/openbabel/openbabel/commit/e26491017efefdc6aaf73d4d49f284f4e9436244
+
+Index: src/formats/pngformat.cpp
+--- src/formats/pngformat.cpp.orig
 src/formats/pngformat.cpp
+@@ -120,7 +120,7 @@ bool PNGFormat::ReadMolecule(OBBase* pOb, OBConversion
+   if(pConv->IsFirstInput())
+ count=0;
+ 
+-  const char pngheader[] = {-119,80,78,71,13,10,26,10,0};
++  const unsigned char pngheader[] = {137,80,78,71,13,10,26,10,0};
+   char readbytes[9];
+   ifs.read(readbytes, 8);
+   
Index: patches/patch-src_formats_yasaraformat_cpp
===
RCS file: patches/patch-src_formats_yasaraformat_cpp
diff -N patches/patch-src_formats_yasaraformat_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_formats_yasaraformat_cpp  16 Jun 2019 07:04:56 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+
+fix narrowing conversion errors on archs where char is unsigned by default
+(arm, ppc), see 
+https://github.com/openbabel/openbabel/pull/1744
+
+Index: src/formats/yasaraformat.cpp
+--- src/formats/yasaraformat.cpp.orig
 src/formats/yasaraformat.cpp
+@@ -478,7 +478,7 @@ bool YOBFormat::WriteMolecule(OBBase* pOb, OBConversio
+ 
+   //  bool hetatom;
+   char buffer[32],/*resname[4],*/atomname[5];
+-  char double1[8]={0,0,0,0,0,0,-16,0x3f};
++  unsigned char double1[8]={0,0,0,0,0,0,0xf0,0x3f};
+   //   char *str;
+   int i,j,/*m,q,*/pos;
+   int /*resno,chainNum,link,linktype,*/atoms,element,links/*,chain*/;
+@@ -506,7 +506,7 @@ bool YOBFormat::WriteMolecule(OBBase* pOb, OBConversio
+   mem_set(buffer,0,8);
+   for (i=0;i<4;i++)
+   { for (j=0;j<4;j++)
+-{ if (i==j) ofs.write(double1,8);
++{ if (i==j) ofs.write((char*)double1,8);
+   else ofs.write(buffer,8); } }
+   storeint32le(buffer,MOB_INFOEND);
+   storeint32le(&buffer[4],MOB_INFOENDSIZE);



Re: [NEW] security/ghidra

2019-06-16 Thread Stuart Henderson
Here's a small tweak for gradle, then it's ok with me to import.

diff --git a/Makefile b/Makefile
index 06e0699..e4e5daf 100644
--- a/Makefile
+++ b/Makefile
@@ -2,9 +2,8 @@
 
 COMMENT =  build automation tool
 
-V =5.4.1
-DISTNAME = gradle-${V}-bin
-PKGNAME =  gradle-${V}
+DISTNAME = gradle-5.4.1
+EXTRACT_SUFX = -bin.zip
 
 CATEGORIES =   devel
 
@@ -15,17 +14,12 @@ PERMIT_PACKAGE =Yes
 
 MASTER_SITES = https://services.gradle.org/distributions/
 
-EXTRACT_SUFX = .zip
-
 MODULES =  java
 MODJAVA_VER =  1.8+
 
 NO_BUILD = Yes
 NO_TEST =  Yes
 
-WRKDIST =  ${WRKDIR}/gradle-${V}
-WRKSRC =   ${WRKDIST}
-
 RUN_DEPENDS =  java/javaPathHelper
 
 do-install:



Re: [NEW] security/ghidra

2019-06-16 Thread Stuart Henderson

Oh, maybe worth considering putting it in java/ instead of devel/.

--
Sent from a phone, apologies for poor formatting.

On 16 June 2019 10:47:15 Stuart Henderson  wrote:


Here's a small tweak for gradle, then it's ok with me to import.

diff --git a/Makefile b/Makefile
index 06e0699..e4e5daf 100644
--- a/Makefile
+++ b/Makefile
@@ -2,9 +2,8 @@

COMMENT =   build automation tool

-V =5.4.1
-DISTNAME = gradle-${V}-bin
-PKGNAME =  gradle-${V}
+DISTNAME = gradle-5.4.1
+EXTRACT_SUFX = -bin.zip

CATEGORIES =devel

@@ -15,17 +14,12 @@ PERMIT_PACKAGE =Yes

MASTER_SITES =  https://services.gradle.org/distributions/

-EXTRACT_SUFX = .zip
-
MODULES =   java
MODJAVA_VER =   1.8+

NO_BUILD =  Yes
NO_TEST =   Yes

-WRKDIST =  ${WRKDIR}/gradle-${V}
-WRKSRC =   ${WRKDIST}
-
RUN_DEPENDS =   java/javaPathHelper

do-install:






print/poppler build failure

2019-06-16 Thread Christian Weisgerber
This is a randomly recurring print/poppler build failure:

--->
CMake Error at glib/cmake_install.cmake:47 (file):
  file INSTALL cannot find

"/usr/obj/ports/poppler-0.76.1/build-amd64/glib/libpoppler-glib.so.8.12".
Call Stack (most recent call first):
  cmake_install.cmake:238 (include)

FAILED: CMakeFiles/install.util 
cd /usr/obj/ports/poppler-0.76.1/build-amd64 && /usr/local/bin/cmake -P
cmake_install.cmake
ninja: build stopped: subcommand failed.
<---

There appears to be a mismatch in the shared library versioning.
>From the Makefile:

SHARED_LIBS +=  poppler-glib 19.1 # 8.12

In the work directory, glib/libpoppler-glib.so.19.1 has been built
correctly.  But for some reason our LIBpoppler-glib_VERSION override
is forgotten during the fake install.

This only happens in some bulk builds.  Most of the time, print/poppler
builds fine.

(Full build log attached.)
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de


poppler,,-qt5.log.xz
Description: application/xz


Re: UPDATE: graphics/krita

2019-06-16 Thread Rafael Sadowski
On Mon Jun 10, 2019 at 02:51:14PM +0200, Rafael Sadowski wrote:
> On Fri Jun 07, 2019 at 02:53:39PM +0100, Stuart Henderson wrote:
> > On 2019/06/07 07:14, Rafael Sadowski wrote:
> > > 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?
> > 
> > In a word, yes.
> 
> Stupid question, I was assuming wrong facts.
> 
> > 
> > If things fail in bulk they need looking into, so this is a lot of
> > manual extra checking needed by people who are already putting a fair
> > bit of time into running builds. Counting just the official bulk builds
> > for amd64 and i386 plus exopi, that's probably about 10 builds a week,
> > and I know there are other people who do larger or smaller bulks
> > slightly less frequently.
> > 
> > (In the case of ports which are depended on by other ports, a failure
> > there blocking a bunch of other ports significantly slows down the
> > build: check, fix broken port, restart, wait, come back and check again,
> > fix another broken port, )
> > 
> > If the breakage is too much, people doing non-essential builds are likely
> > to just stop caring because they're too much work ..
> > 
> 
> Of course, you're absolutely right.
> 
> Back to krita, I did a mistake in my last diff. CONFIGURE_ARGS should
> set to ON and not to OFF. That triggered the broken part(s). I also added
> all optional non-existing dependencies to be on the safe side.
> 
> RS
> 

New diff:

- Fix build with upcoming ninja 1.9.0
  (I don't see an alternative at the moment than disable this
  wired benchmark tests.)
- Adopt PERMIT_PACKAGE

OK?

Index: Makefile
===
RCS file: /cvs/ports/graphics/krita/Makefile,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 Makefile
--- Makefile20 May 2019 22:15:13 -  1.25
+++ Makefile16 Jun 2019 12:05:31 -
@@ -2,37 +2,35 @@
 
 COMMENT =  advanced drawing and image manipulation
 
-VERSION =  4.1.8
+VERSION =  4.2.1
 DISTNAME = krita-${VERSION}
-REVISION = 1
 
-SHARED_LIBS +=  kritabasicflakes  1.0 # 16.0
+SHARED_LIBS +=  kritabasicflakes  2.0 # 16.0
 SHARED_LIBS +=  kritacolord   1.0 # 16.0
-SHARED_LIBS +=  kritaflake2.0 # 16.0
-SHARED_LIBS +=  kritaodf  1.0 # 16.0
-SHARED_LIBS +=  kritapigment  2.0 # 16.0
+SHARED_LIBS +=  kritaflake3.0 # 16.0
+SHARED_LIBS +=  kritaodf  2.0 # 16.0
+SHARED_LIBS +=  kritapigment  3.0 # 16.0
 SHARED_LIBS +=  kritaplugin   1.0 # 16.0
-SHARED_LIBS +=  kritastore1.0 # 16.0
+SHARED_LIBS +=  kritastore2.0 # 16.0
 SHARED_LIBS +=  kritatext 1.0 # 16.0
 SHARED_LIBS +=  kritatextlayout   1.0 # 16.0
-SHARED_LIBS +=  kritaundo21.0 # 16.0
-SHARED_LIBS +=  kritavectorimage  2.0 # 16.0
 SHARED_LIBS +=  kritaversion  1.0 # 16.0
-SHARED_LIBS +=  kritawidgets  1.0 # 16.0
-SHARED_LIBS +=  kritawidgetutils  3.0 # 16.0
-SHARED_LIBS +=  kritacommand  1.0 # 16.0
+SHARED_LIBS +=  kritawidgets  2.0 # 16.0
+SHARED_LIBS +=  kritawidgetutils  4.0 # 16.0
+SHARED_LIBS +=  kritacommand  2.0 # 16.0
 SHARED_LIBS +=  kritaimpex1.0 # 16.0
-SHARED_LIBS +=  kritalibkis   1.0 # 16.0
-SHARED_LIBS +=  kritalibkra   1.0 # 16.0
-SHARED_LIBS +=  kritaqml  1.0 # 16.0
+SHARED_LIBS +=  kritalibkis   2.0 # 16.0
+SHARED_LIBS +=  kritalibkra   2.0 # 16.0
+SHARED_LIBS +=  kritaqml  2.0 # 16.0
+SHARED_LIBS +=  kritametadata 0.0 # 18.0
 # XXX Version numbers from editors/calligra 2.x port
 SHARED_LIBS +=  kritapsd  2.0 # 14.0
 SHARED_LIBS +=  kritacolor2.0 # 14.0
-SHARED_LIBS +=  kritaglobal   3.0 # 14.0
-SHARED_LIBS +=  kritaimage53.0 # 0.0
-SHARED_LIBS +=  kritalibbrush 52.0 # 0.0
-SHARED_LIBS +=  kritalibpaintop   52.0 # 0.0
-SHARED_LIBS +=  kritaui   56.0 # 0.0
+SHA

Re: New prometheus node_exporter port

2019-06-16 Thread Sacha
Hi,

A packaged node_exporter for OpenBSD could be really nice with no need to
install go or python to compile it.

Here are some missing metrics for OpenBSD:
- uname -a
- PF stats, like pfctl -s info, memory or actual against maximum limits
- Cpu temp
- ntpd
- CPU interrupts
- uptime
- some specifics OBSD daemons like OpenBGPD/OpenSMTPD metrics will be very
appreciated
- syspatch updates

And we need a rc script for the package ?

I'm ready to test the package ;)


Sacha.



--
Sent from: 
http://openbsd-archive.7691.n7.nabble.com/openbsd-user-ports-f108501.html



Re: UPDATE: net/gajim

2019-06-16 Thread Kurt Mosiejczuk
On Sun, Jun 16, 2019 at 08:15:26AM +0200, Ingo Feinerer wrote:

> > You need the py-nbxmpp update as well:
> > https://marc.info/?l=openbsd-ports&m=155704320901616&w=2

> Updated diff with explicit requirement on 0.6.10 (already in ports
> tree). Also adapt PERMIT_PACKAGE at the same time.

> OK?

Looks OK to me and runs here on amd64. 

OK kmos

--Kurt



Re: [NEW] security/ghidra

2019-06-16 Thread Klemens Nanni
On Sun, Jun 16, 2019 at 11:12:09AM +0100, Stuart Henderson wrote:
> Oh, maybe worth considering putting it in java/ instead of devel/.
I agree.  OK kn with that.



Re: print/poppler build failure

2019-06-16 Thread Matthias Kilian
Hi,

On Sun, Jun 16, 2019 at 01:24:29PM +0200, Christian Weisgerber wrote:
> This is a randomly recurring print/poppler build failure:
> 
> --->
> CMake Error at glib/cmake_install.cmake:47 (file):
>   file INSTALL cannot find
> 
> "/usr/obj/ports/poppler-0.76.1/build-amd64/glib/libpoppler-glib.so.8.12".
> Call Stack (most recent call first):
>   cmake_install.cmake:238 (include)
> 
> FAILED: CMakeFiles/install.util 
> cd /usr/obj/ports/poppler-0.76.1/build-amd64 && /usr/local/bin/cmake -P
> cmake_install.cmake
> ninja: build stopped: subcommand failed.
> <---
> 
> There appears to be a mismatch in the shared library versioning.
> >From the Makefile:
> 
> SHARED_LIBS +=  poppler-glib 19.1 # 8.12
> 
> In the work directory, glib/libpoppler-glib.so.19.1 has been built
> correctly.  But for some reason our LIBpoppler-glib_VERSION override
> is forgotten during the fake install.
> 
> This only happens in some bulk builds.  Most of the time, print/poppler
> builds fine.

I think I've seen this *once*, and IIRC in this case and in all
reported cases of the failure, it was for poppler,,-qt5.

I'd like to drop the default FLAVOR?=no_qt5 bootstrap and also the
pseudo flavor bootstrap in the next update of poppler (poppler-0.77.0),
unless full bulk builders protest.

BTW: is it really a problem if the default poppler build also needs
qt5 during bulk builds?

Ciao,
Kili



Re: [update] py-progress-1.5

2019-06-16 Thread Klemens Nanni
OK kn



UPDATE: security/keybase 4.1.0 + git-remote-keybase

2019-06-16 Thread Juan Francisco Cantero Hurtado
Works for me. I've added git-remote-keybase to the port, so you can now
work with git repos hosted on keybase. There are some remaining bugs
with the git repos, but I can reproduce the same problems on Linux.

If you know something about OpenBSD syscalls, please check my patches
and tell me if I'm doing the conversion from Linux syscalls correctly.

Comments? OK?


Index: Makefile
===
--- Makefile(revision 138830)
+++ Makefile(working copy)
@@ -8,7 +8,7 @@
 COMMENT =  client for keybase.io
 
 # XXX: https://github.com/keybase/client/issues/10800
-V =4.0.0
+V =4.1.0
 GH_ACCOUNT =   keybase
 GH_PROJECT =   client
 GH_TAGNAME =   v${V}
@@ -37,8 +37,11 @@
 do-build:
cd ${WRKSRC}/go/keybase && ${MODGO_CMD} build -tags \
production
+   cd ${WRKSRC}/go/kbfs/kbfsgit/git-remote-keybase && \
+   ${MODGO_CMD} build -tags production
 
 do-install:
${INSTALL_PROGRAM} ${WRKSRC}/go/keybase/keybase ${PREFIX}/bin/
+   ${INSTALL_PROGRAM} 
${WRKSRC}/go/kbfs/kbfsgit/git-remote-keybase/git-remote-keybase ${PREFIX}/bin/
 
 .include 
Index: distinfo
===
--- distinfo(revision 138830)
+++ distinfo(working copy)
@@ -1,2 +1,2 @@
-SHA256 (keybase-4.0.0.tar.gz) = UD4Gjn6JpXxJfkDO5bFhcEwjkZvFmEamUH38Xs1BgJE=
-SIZE (keybase-4.0.0.tar.gz) = 48707909
+SHA256 (keybase-4.1.0.tar.gz) = fmcPTGB702ft7F9Y0tJ9z/gmzVVfM7UZJhi0T++9QbA=
+SIZE (keybase-4.1.0.tar.gz) = 61605137
Index: patches/patch-go_kbfs_libkbfs_disk_limits_unix_go
===
--- patches/patch-go_kbfs_libkbfs_disk_limits_unix_go   (nonexistent)
+++ patches/patch-go_kbfs_libkbfs_disk_limits_unix_go   (working copy)
@@ -0,0 +1,25 @@
+$OpenBSD$  
+   
 
+Index: go/kbfs/libkbfs/disk_limits_unix.go
+--- go/kbfs/libkbfs/disk_limits_unix.go.orig   Sat Jun 15 22:30:45 2019
 go/kbfs/libkbfs/disk_limits_unix.goSat Jun 15 22:30:56 2019
+@@ -28,14 +28,14 @@
+   }
+ 
+   // Bavail is the free block count for an unprivileged user.
+-  availableBytes = uint64(stat.Bavail) * uint64(stat.Bsize)
+-  totalBytes = uint64(stat.Blocks) * uint64(stat.Bsize)
++  availableBytes = uint64(stat.F_bavail) * uint64(stat.F_bsize)
++  totalBytes = uint64(stat.F_blocks) * uint64(stat.F_bsize)
+   // Some filesystems, like btrfs, don't keep track of inodes.
+   // (See https://github.com/keybase/client/issues/6206 .) Use
+   // the total inode count to detect that case.
+-  if stat.Files > 0 {
+-  availableFiles = uint64(stat.Ffree)
+-  totalFiles = uint64(stat.Files)
++  if stat.F_files > 0 {
++  availableFiles = uint64(stat.F_ffree)
++  totalFiles = uint64(stat.F_files)
+   } else {
+   availableFiles = math.MaxInt64
+   totalFiles = math.MaxInt64
Index: patches/patch-go_vendor_gopkg_in_src_d_go_git_v4_worktree_bsd_go
===
--- patches/patch-go_vendor_gopkg_in_src_d_go_git_v4_worktree_bsd_go
(nonexistent)
+++ patches/patch-go_vendor_gopkg_in_src_d_go_git_v4_worktree_bsd_go
(working copy)
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: go/vendor/gopkg.in/src-d/go-git.v4/worktree_bsd.go
+--- go/vendor/gopkg.in/src-d/go-git.v4/worktree_bsd.go.origWed Jun 12 
17:53:05 2019
 go/vendor/gopkg.in/src-d/go-git.v4/worktree_bsd.go Sat Jun 15 19:41:25 2019
+@@ -12,7 +12,7 @@
+ func init() {
+   fillSystemInfo = func(e *index.Entry, sys interface{}) {
+   if os, ok := sys.(*syscall.Stat_t); ok {
+-  e.CreatedAt = time.Unix(int64(os.Atimespec.Sec), 
int64(os.Atimespec.Nsec))
++  e.CreatedAt = time.Unix(int64(os.Atim.Sec), 
int64(os.Atim.Nsec))
+   e.Dev = uint32(os.Dev)
+   e.Inode = uint32(os.Ino)
+   e.GID = os.Gid
Index: pkg/PLIST
===
--- pkg/PLIST   (revision 138830)
+++ pkg/PLIST   (working copy)
@@ -1,2 +1,3 @@
 @comment $OpenBSD: PLIST,v 1.1.1.1 2016/09/09 14:11:43 abieber Exp $
+@bin bin/git-remote-keybase
 @bin bin/keybase



UPDATE: syncthing-1.1.4

2019-06-16 Thread Edd Barrett
Hi,

Here's an update to Syncthing. I'll be testing this over the next few
days.


Index: Makefile
===
RCS file: /cvs/ports/net/syncthing/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile4 May 2019 21:46:17 -   1.26
+++ Makefile16 Jun 2019 19:59:45 -
@@ -2,7 +2,7 @@
 
 COMMENT =  open decentralized synchronization utility
 
-V =1.1.1
+V =1.1.4
 DISTNAME = syncthing-${V}
 DISTFILES =syncthing-source-v${V}${EXTRACT_SUFX}
 
@@ -29,9 +29,9 @@ do-build:
cd ${WRKSRC} && ${MODGO_CMD} run build.go \
-version v${V} -no-upgrade
 
-# Some tests fail, but they are bugs in the test suite itself, not Syncthing.
-# We are working with upstream to fix these:
-# https://forum.syncthing.net/t/openbsd-test-debugging/12799
+# A couple of test failures caused by a bug in the test suite (but not in
+# Syncthing itself):
+# https://github.com/syncthing/syncthing/issues/5796#issuecomment-502473144
 do-test:
cd ${WRKSRC} && ${MODGO_CMD} run build.go test
 
Index: distinfo
===
RCS file: /cvs/ports/net/syncthing/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- distinfo3 May 2019 12:58:59 -   1.16
+++ distinfo14 Jun 2019 20:40:22 -
@@ -1,2 +1,2 @@
-SHA256 (syncthing-source-v1.1.1.tar.gz) = 
p5ZYPBKJR2U5S+OOjehYcFSR3GdCibtpNuaK60viNHc=
-SIZE (syncthing-source-v1.1.1.tar.gz) = 6966579
+SHA256 (syncthing-source-v1.1.4.tar.gz) = 
1GSIS/2S6sLy28g1x0DqfVvZ5uvQvKfNpJaCsNpOa14=
+SIZE (syncthing-source-v1.1.4.tar.gz) = 9364374
Index: patches/patch-build_go
===
RCS file: /cvs/ports/net/syncthing/patches/patch-build_go,v
retrieving revision 1.8
diff -u -p -r1.8 patch-build_go
--- patches/patch-build_go  3 May 2019 12:58:59 -   1.8
+++ patches/patch-build_go  16 Jun 2019 17:59:54 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-build_go,v 1.8 2019/05/0
 Index: build.go
 --- build.go.orig
 +++ build.go
-@@ -188,6 +188,20 @@ var targets = map[string]target{
+@@ -189,6 +189,20 @@ var targets = map[string]target{
{src: "AUTHORS", dst: 
"deb/usr/share/doc/syncthing-relaypoolsrv/AUTHORS.txt", perm: 0644},
},
},
@@ -23,7 +23,7 @@ Index: build.go
  }
  
  // These are repos we need to clone to run "go generate"
-@@ -435,7 +449,7 @@ func appendParameters(args []string, tags []string, ta
+@@ -439,7 +453,7 @@ func appendParameters(args []string, tags []string, ta
  
if !debugBinary {
// Regular binaries get version tagged and skip some debug 
symbols


-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk



games/openra: add dlopen'd WANTLIBs

2019-06-16 Thread Thomas Frohwein
Hi,

OpenRA dlopen's libraries via the mono-config(5) dllmap mechanism. It
seems that if openal, freetype, and SDL2 are not listed as WANTLIB they
are not installed as RUN_DEPENDS (this is how I read bsd.port.mk(5)).
The diff below adds these libraries to WANTLIB and this way I can't
install the package if openal is not present. Same should go for SDL2
and freetype.

The missing installation of openal for runtime was reported by Matthias
(@_xhr_@mastodon.social).

ok?

Index: Makefile
===
RCS file: /cvs/ports/games/openra/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile28 Apr 2019 03:34:16 -  1.3
+++ Makefile16 Jun 2019 23:30:45 -
@@ -6,7 +6,7 @@ DISTNAME =  openra-${V}
 CATEGORIES =   games x11
 HOMEPAGE = https://www.openra.net
 MAINTAINER =   Thomas Frohwein 
-REVISION = 1
+REVISION = 2
 
 # GPLv3 (openra)
 # MIT (StyleCopPlus, StyleCop, SharpZipLib, NUnit, NUnit.Console, Open.Nat,
@@ -15,6 +15,9 @@ REVISION =1
 # GPLv2 (FuzzyLogicLibrary)
 # zlib (SDL2-CS, OpenAL-CS)
 PERMIT_PACKAGE_CDROM = Yes
+
+# dlopen'd via mono-config(5)
+WANTLIB += SDL2 freetype openal
 
 MASTER_SITES = https://mirrors.nycbug.org/pub/distfiles/
 EXTRACT_SUFX = .tar.xz



Re: games/openra: add dlopen'd WANTLIBs

2019-06-16 Thread Stuart Henderson
On 2019/06/16 17:39, Thomas Frohwein wrote:
> Hi,
> 
> OpenRA dlopen's libraries via the mono-config(5) dllmap mechanism. It
> seems that if openal, freetype, and SDL2 are not listed as WANTLIB they
> are not installed as RUN_DEPENDS (this is how I read bsd.port.mk(5)).
> The diff below adds these libraries to WANTLIB and this way I can't
> install the package if openal is not present. Same should go for SDL2
> and freetype.
> 
> The missing installation of openal for runtime was reported by Matthias
> (@_xhr_@mastodon.social).
> 
> ok?
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/openra/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile  28 Apr 2019 03:34:16 -  1.3
> +++ Makefile  16 Jun 2019 23:30:45 -
> @@ -6,7 +6,7 @@ DISTNAME =openra-${V}
>  CATEGORIES = games x11
>  HOMEPAGE =   https://www.openra.net
>  MAINTAINER = Thomas Frohwein 
> -REVISION =   1
> +REVISION =   2
>  
>  # GPLv3 (openra)
>  # MIT (StyleCopPlus, StyleCop, SharpZipLib, NUnit, NUnit.Console, Open.Nat,
> @@ -15,6 +15,9 @@ REVISION =  1
>  # GPLv2 (FuzzyLogicLibrary)
>  # zlib (SDL2-CS, OpenAL-CS)
>  PERMIT_PACKAGE_CDROM =   Yes
> +
> +# dlopen'd via mono-config(5)
> +WANTLIB +=   SDL2 freetype openal
>  
>  MASTER_SITES =   https://mirrors.nycbug.org/pub/distfiles/
>  EXTRACT_SUFX =   .tar.xz
> 

OK sthen@.

You have two options, either as you've done (i.e. LIB_DEPENDS + WANTLIB +
explanatory comment - which I prefer), or just list them in RUN_DEPENDS.

The "tell" for this is the "LIB_DEPENDS  not needed for "
message when building the package.



Re: [NEW] security/ghidra

2019-06-16 Thread Lawrence Teo
Thank you Stuart!  I have imported java/gradle with your tweak.

On Sun, Jun 16, 2019 at 11:12:09AM +0100, Stuart Henderson wrote:
> Oh, maybe worth considering putting it in java/ instead of devel/.
> 
> --
> Sent from a phone, apologies for poor formatting.
> 
> On 16 June 2019 10:47:15 Stuart Henderson  wrote:
> 
> > Here's a small tweak for gradle, then it's ok with me to import.
> > 
> > diff --git a/Makefile b/Makefile
> > index 06e0699..e4e5daf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2,9 +2,8 @@
> > 
> > COMMENT =   build automation tool
> > 
> > -V =5.4.1
> > -DISTNAME = gradle-${V}-bin
> > -PKGNAME =  gradle-${V}
> > +DISTNAME = gradle-5.4.1
> > +EXTRACT_SUFX = -bin.zip
> > 
> > CATEGORIES =devel
> > 
> > @@ -15,17 +14,12 @@ PERMIT_PACKAGE =Yes
> > 
> > MASTER_SITES =  https://services.gradle.org/distributions/
> > 
> > -EXTRACT_SUFX = .zip
> > -
> > MODULES =   java
> > MODJAVA_VER =   1.8+
> > 
> > NO_BUILD =  Yes
> > NO_TEST =   Yes
> > 
> > -WRKDIST =  ${WRKDIR}/gradle-${V}
> > -WRKSRC =   ${WRKDIST}
> > -
> > RUN_DEPENDS =   java/javaPathHelper
> > 
> > do-install:



Re: [NEW] security/ghidra

2019-06-16 Thread Lawrence Teo
On Sat, Jun 15, 2019 at 09:26:18PM +0200, Remi Pointel wrote:
> On 6/15/19 4:56 PM, Lawrence Teo wrote:
> > On Tue, May 14, 2019 at 07:59:57PM +0200, Remi Pointel wrote:
> > > On 5/14/19 7:48 PM, Jeremy O'Brien wrote:
> > > > On Tue, May 14, 2019, at 12:43, Anthony J. Bentley wrote:
> > > > > Jeremy O'Brien writes:
> > > > > > I noticed this port was committed today. I have to
> > > > > > ask, did you actually try to use it? In its current
> > > > > > state, (sans my above changes), there is no decompiler
> > > > > > nor symbol demangler. This might have been OK to omit,
> > > > > > except for the fact that you will get a "Could not
> > > > > > find decompiler executable decompile" popup every
> > > > > > single time you click anywhere in the disassembly pane,
> > > > > > which makes this port unusable.
> > > > > 
> > > > > Indeed they are very annoying. I agree the port is not
> > > > > "finished." But I've used Ghidra to do some minor work despite that, 
> > > > > so
> > > > > I'm happy to see it in. Revising the port to add the native tools 
> > > > > would
> > > > > be very welcome though.
> > > > > 
> > > > > 
> > > > 
> > > > If you're willing to compile it yourself, my MR here: 
> > > > https://github.com/NationalSecurityAgency/ghidra/pull/490 makes the 
> > > > native components build perfectly in OpenBSD. Just follow the ghidra 
> > > > DevGuide.md instructions after applying the patch. I also have my 
> > > > personal build here (but that of course requires that you trust a 
> > > > stranger on the internet): 
> > > > https://pintobyte.com/tmp/ghidra_9.1-DEV_PUBLIC_20190513_openbsd64.zip 
> > > > if you don't feel like compiling but want the "full" ghidra experience. 
> > > > I do like that the current ghidra port requires no compilation, as the 
> > > > compilation process is a bit heavy-handed and takes some time to 
> > > > complete, but I personally would prefer to see a fully-working port 
> > > > over a fast-installing one.
> > > > 
> > > 
> > > Thank you for feedback, I will try your patch to build ghidra and I will 
> > > let
> > > you know.
> > > If you are motivated, you can send a diff that applies on the ghidra port 
> > > to
> > > integrate your work.
> > > 
> > > Cheers,
> > > 
> > > Remi.
> > > 
> > 
> > Here's my attempt to update Ghidra to add a native decompiler for
> > OpenBSD.  I created the patches based on Jeremy's pull request and used
> > https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md
> > to figure out the build steps.
> > 
> > I also did the following to make it build and conform to OpenBSD port
> > conventions:
> > 
> > 1. Ghidra is built using Gradle so I have attached a new port for
> > devel/gradle 5.4.1.
> > 
> > 2. DevGuide.md says they built Ghidra with Gradle 5.0 but I was able to
> > build it successfully with Gradle 5.4.1.
> > 
> > 3. To prevent the build process from touching $HOME, I made gradle use
> > ${WRKDIR}/gradle as its home and also modified GHelpBuilder.java
> > (the program that builds help files during build) to log to ${WRKDIR}
> > instead of $HOME/.ghidra.
> > 
> > 4. One of the Gradle scripts (ip.gradle) scans the Ghidra source tree so
> > I had to explicitly tell it to exclude *.orig and *.beforesubst.
> > 
> > 5. The port has to be built with a high `ulimit -d` (I set it to
> > `ulimit -Hd` which on my system is 33554432).
> > 
> > Using the resulting package I was able to decompile programs without
> > encountering the "Could not find decompiler executable decompile" popup.
> > 
> > Tests/reviews/feedback welcome! :)
> 
> Hi,
> 
> quickly tested and sounds good to me, thanks a lot for your work.
> 
> Cheers,
> 
> Remi.

Remi, thank you for testing!

Here is an updated diff now that Gradle has been imported.

The only change is the BUILD_DEPENDS for Gradle which I've changed from
devel/gradle to java/gradle.

ok?
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
+++ Makefile17 Jun 2019 00:58:58 -
@@ -6,9 +6,14 @@ 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
+YAJSW_VER =12.12
+REVISION = 1
+
+GH_ACCOUNT =   NationalSecurityAgency
+GH_PROJECT =   ghidra
+GH_TAGNAME =   Ghidra_${VERSION}_build
+DISTNAME = ghidra-${VERSION}
 
 CATEGORIES =   security
 
@@ -17,32 +22,85 @@ HOMEPAGE =  https://www.ghidra-sre.org/
 MAINTAINER =   Remi Pointel 
 
 # Apache v2
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE =   Yes
 
-MASTER_SITES = ${HOMEPAGE}
+WANTLIB += c m stdc++
+
+MASTER_SITES0 =${HOMEPAGE}
+MASTER_SITES1 =
https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-