Re: [NEW] security/ghidra
On Mon, Jun 17, 2019 at 08:10:45PM -0600, Anthony J. Bentley wrote:
> Lawrence Teo writes:
> > Here is an updated diff now that Gradle has been imported.
>
> It doesn't build for me.
Hi Anthony,
Thanks for testing! I checked your build log and found that the Ghidra
build process tries to fetch dependent files on demand while building.
I was able to replicate your build failure when I tried building the
port as _pbuild.
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?
Thank you,
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 01:40:09 -
@@ -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 from:
+# https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md
+pre-build:
+ cp ${FILESDIR}/repos.gradle ${WRKDIR}
+ ${SUBST_CMD} ${WRKDIR}/repos.gradle \
+
${WRKSRC}/Ghidra/Framework/Help/src/main/java/help/GHelpBuilder.java
+ mkdir ${WRKDIR}/{flatRepo,gradle,home}
+.for dir in ${JAR_DIRS}
+ unzip -j ${DISTDIR}/ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}.zip \
+ -d ${WRKDIR}/flatRepo \
+
ghidra_${VERSION}/Ghidra/${dir:C/-.*$//}/${dir:
[wip] mail/courier-authlib update
Hi, I was going to update mail/courier-authlib but I found that, even the version we have in tree, gives an error make lib-depends-check: courier-authlib-0.68.0p5(mail/courier-authlib,-main): Missing: z.5 (/usr/local/lib/libauthsqlite.so.0.0) (system lib) Extra: iconv.6 idn.18 intl.6 WANTLIB += z courier-authlib-mysql-0.68.0p3(mail/courier-authlib,-mysql): Missing: iconv.6 from libiconv-1.14p3 (/usr/local/lib/libauthmysql.so.0.0) Missing: mariadb.28 from mariadb-client-10.3.15v1 (/usr/local/lib/libauthmysql.so.0.0) Extra: mysqlclient.28 WANTLIB += iconv mariadb The second one depends on databases/mariadb update and it's easily fixable but what about the first one ? Should I remove gettext,-runtime and libidn from dependencies ? I am not sure this is the way to go. Cheers Giovanni
Re: UPDATE games/lgeneral
On 6/19/19 12:00 AM, Kirill Bychkov wrote: On Sat, June 1, 2019 10:47, Kirill Bychkov wrote: Hi! This is an update to the latest version of lgeneral. I've added CC BY-SA 3.0 licensed data package, so there is no need to purchase original PD data. OK, comments? Anyone? Don't really know how to play but it launches and I was able to get in game, so ok. Btw, "ambushs" in pkg/DESCR is spelled "ambushes" :) ~Brian
Re: net/mldonkey still in use?
On Wed, Jun 19 2019, kwesterb...@gmail.com wrote: [...] > I don't see much difference between disabling and moving to the attic, > but this two step approach is ok with me. If the current camlp4 code is compatible with ocaml-4.08 then the fix would be a two-lines patch for its configure script and removing the BROKEN line. Compare that to useless churn due to the unhooking/removal of two ports, and quirks glue to mark the packages as obsolete. And then the people actually willing to fix camlp4/mldonkey would have to undo all of this. > Dunno what quirks magic (if any) needs to be done for disabling a port. No need for quirks magic when you mark a port BROKEN. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [NEW] slant-0.0.20
On Wed, Jun 19, 2019 at 10:15:54AM +0200, Kristaps Dzonsons wrote: > 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 > > Best, > > Kristaps Port reads good to me. There is a trailing space on the lastline of the PLIST. -- James Turner
Re: net/mldonkey still in use?
> On Jun 19, 2019, at 10:48 AM, Christopher Zimmermann > wrote: > > On Tue, 18 Jun 2019 14:17:49 -0400 > ygrek wrote: > >> On Mon, 17 Jun 2019 20:34:41 +0100 >> Anil Madhavapeddy wrote: >> >>> I think this approach is fine for this particular package, since >>> upstream lags in recent times. >>> >>> The opam package for mldonkey is on ocaml<4.06, but I'm CCing the >>> current maintainer Ygrek in case there is a 4.08 port in the >>> offing. >> >> 4.08 support depends on camlp4 which is not yet available. >> I am maintaining git repository at github.com/ygrek/mldonkey - it >> builds fine with 4.07 > Is this the way to go? OK to commit? Is this port still in use? >> >> I don't think this is a good way forward if that package is used on >> non-x86 archs, there were many bugs there in older ocaml versions. > > > Ok. So mldonkey is the only port still using deprecated camlp4. > I already adapted camlp5 to OCaml 4.08, because coq needs camlp5. > But I'm reluctant to do the same for deprecated camlp4. > > * sthen@, krw@ already consented with removal of mldonkey > * anil@ proposed to disable the port (and therefore camlp4, too) > until camlp4 catches up. > > For the time being I would like to choose the second option and disable > mldonkey and camlp4, but only enable them again on request. > Then when no one complains and they have rotten long enough we can > dispose of them. > > OK? > > > Christopher > > > > -- > http://gmerlin.de > OpenPGP: http://gmerlin.de/christopher.pub > CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1 I don't see much difference between disabling and moving to the attic, but this two step approach is ok with me. Dunno what quirks magic (if any) needs to be done for disabling a port. Ken
Re: net/mldonkey still in use?
On Wed, Jun 19 2019, Jeremie Courreges-Anglas wrote: > On Wed, Jun 19 2019, Christopher Zimmermann wrote: >> On Tue, 18 Jun 2019 14:17:49 -0400 >> ygrek wrote: >> >>> On Mon, 17 Jun 2019 20:34:41 +0100 >>> Anil Madhavapeddy wrote: >>> >>> > I think this approach is fine for this particular package, since >>> > upstream lags in recent times. >>> > >>> > The opam package for mldonkey is on ocaml<4.06, but I'm CCing the >>> > current maintainer Ygrek in case there is a 4.08 port in the >>> > offing. >>> >>> 4.08 support depends on camlp4 which is not yet available. >>> I am maintaining git repository at github.com/ygrek/mldonkey - it >>> builds fine with 4.07 >> >>> > > Is this the way to go? OK to commit? >>> > > Is this port still in use? >>> >>> I don't think this is a good way forward if that package is used on >>> non-x86 archs, there were many bugs there in older ocaml versions. >> >> >> Ok. So mldonkey is the only port still using deprecated camlp4. >> I already adapted camlp5 to OCaml 4.08, because coq needs camlp5. >> But I'm reluctant to do the same for deprecated camlp4. >> >> * sthen@, krw@ already consented with removal of mldonkey >> * anil@ proposed to disable the port (and therefore camlp4, too) >> until camlp4 catches up. >> >> For the time being I would like to choose the second option and disable >> mldonkey and camlp4, but only enable them again on request. >> Then when no one complains and they have rotten long enough we can >> dispose of them. >> >> OK? > > ok jca@ to mark lang/ocaml-camlp4 as BROKEN with ocaml-4.08, which > should be sufficient for now. And just to make things clear: please don't mark it BROKEN before the ocaml-4.08 update is committed. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: net/mldonkey still in use?
On Wed, Jun 19 2019, Christopher Zimmermann wrote: > On Tue, 18 Jun 2019 14:17:49 -0400 > ygrek wrote: > >> On Mon, 17 Jun 2019 20:34:41 +0100 >> Anil Madhavapeddy wrote: >> >> > I think this approach is fine for this particular package, since >> > upstream lags in recent times. >> > >> > The opam package for mldonkey is on ocaml<4.06, but I'm CCing the >> > current maintainer Ygrek in case there is a 4.08 port in the >> > offing. >> >> 4.08 support depends on camlp4 which is not yet available. >> I am maintaining git repository at github.com/ygrek/mldonkey - it >> builds fine with 4.07 > >> > > Is this the way to go? OK to commit? >> > > Is this port still in use? >> >> I don't think this is a good way forward if that package is used on >> non-x86 archs, there were many bugs there in older ocaml versions. > > > Ok. So mldonkey is the only port still using deprecated camlp4. > I already adapted camlp5 to OCaml 4.08, because coq needs camlp5. > But I'm reluctant to do the same for deprecated camlp4. > > * sthen@, krw@ already consented with removal of mldonkey > * anil@ proposed to disable the port (and therefore camlp4, too) > until camlp4 catches up. > > For the time being I would like to choose the second option and disable > mldonkey and camlp4, but only enable them again on request. > Then when no one complains and they have rotten long enough we can > dispose of them. > > OK? ok jca@ to mark lang/ocaml-camlp4 as BROKEN with ocaml-4.08, which should be sufficient for now. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE signature.asc Description: PGP signature
Re: net/mldonkey still in use?
> On Jun 19, 2019, at 10:48 AM, Christopher Zimmermann > wrote: > > On Tue, 18 Jun 2019 14:17:49 -0400 > ygrek wrote: > >> On Mon, 17 Jun 2019 20:34:41 +0100 >> Anil Madhavapeddy wrote: >> >>> I think this approach is fine for this particular package, since >>> upstream lags in recent times. >>> >>> The opam package for mldonkey is on ocaml<4.06, but I'm CCing the >>> current maintainer Ygrek in case there is a 4.08 port in the >>> offing. >> >> 4.08 support depends on camlp4 which is not yet available. >> I am maintaining git repository at github.com/ygrek/mldonkey - it >> builds fine with 4.07 > Is this the way to go? OK to commit? Is this port still in use? >> >> I don't think this is a good way forward if that package is used on >> non-x86 archs, there were many bugs there in older ocaml versions. > > > Ok. So mldonkey is the only port still using deprecated camlp4. > I already adapted camlp5 to OCaml 4.08, because coq needs camlp5. > But I'm reluctant to do the same for deprecated camlp4. > > * sthen@, krw@ already consented with removal of mldonkey > * anil@ proposed to disable the port (and therefore camlp4, too) > until camlp4 catches up. > > For the time being I would like to choose the second option and disable > mldonkey and camlp4, but only enable them again on request. > Then when no one complains and they have rotten long enough we can > dispose of them. > > OK? Perhaps just mark camlp4 as BROKEN (which will effectively disable mldonkey) and then move on with the update of ocaml... ok daniel@ if you want to do that. If the situation changes, it can be repaired in tree. I would like to see ocaml 4.08 in the tree and don’t think these should hold things back. Thanks for leading the charge! > > > Christopher > > > > -- > http://gmerlin.de > OpenPGP: http://gmerlin.de/christopher.pub > CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
Re: mldonkey: use custom build of OCaml 3.12
On Mon, Jun 17 2019, Christopher Zimmermann wrote: > On Mon, 17 Jun 2019 21:59:57 +0100 > Stuart Henderson wrote: > >> If people do want to keep this port in the tree, I'd suggest >> rearranging things so that the changes are grouped together as much >> as possible (separate CONFIGURE_ARGS+= / LIB_DEPENDS+= blocks) to >> make it more obvious which are the parts for the compiler change and >> make it easier to switch back to a system compiler when upstream >> updates it. >> >> Really not sure about the value of having early 2000's pirac^W file >> sharing software in OpenBSD ports though ... I see value in having (2 or more) ports to access the eDonkey network, AFAIK the other solution is net/amule. > I would be ok with removing it, too. Anyone else we should ask before > killing it? I'm not ok with removing it "just like that". -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
net/mldonkey still in use?
On Tue, 18 Jun 2019 14:17:49 -0400 ygrek wrote: > On Mon, 17 Jun 2019 20:34:41 +0100 > Anil Madhavapeddy wrote: > > > I think this approach is fine for this particular package, since > > upstream lags in recent times. > > > > The opam package for mldonkey is on ocaml<4.06, but I'm CCing the > > current maintainer Ygrek in case there is a 4.08 port in the > > offing. > > 4.08 support depends on camlp4 which is not yet available. > I am maintaining git repository at github.com/ygrek/mldonkey - it > builds fine with 4.07 > > > Is this the way to go? OK to commit? > > > Is this port still in use? > > I don't think this is a good way forward if that package is used on > non-x86 archs, there were many bugs there in older ocaml versions. Ok. So mldonkey is the only port still using deprecated camlp4. I already adapted camlp5 to OCaml 4.08, because coq needs camlp5. But I'm reluctant to do the same for deprecated camlp4. * sthen@, krw@ already consented with removal of mldonkey * anil@ proposed to disable the port (and therefore camlp4, too) until camlp4 catches up. For the time being I would like to choose the second option and disable mldonkey and camlp4, but only enable them again on request. Then when no one complains and they have rotten long enough we can dispose of them. OK? Christopher -- http://gmerlin.de OpenPGP: http://gmerlin.de/christopher.pub CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1 pgpz0erQqq2kT.pgp Description: OpenPGP digital signature
Re: mldonkey: use custom build of OCaml 3.12
On Tue, Jun 18 2019, ygrek wrote: > On Mon, 17 Jun 2019 20:34:41 +0100 > Anil Madhavapeddy wrote: > >> I think this approach is fine for this particular package, since upstream >> lags in recent times. >> >> The opam package for mldonkey is on ocaml<4.06, but I'm CCing the current >> maintainer Ygrek in case there is a 4.08 port in the offing. > > 4.08 support depends on camlp4 which is not yet available. > I am maintaining git repository at github.com/ygrek/mldonkey - it builds fine > with 4.07 ygrek: I guess you're waiting for diml (https://github.com/diml) to chime in. ygrek, chrisz: are there other known ocaml-4.08 problems in mldonkey, except for a compatible camlp4 release? >> > Mldonkey in difficult to adapt to the new 4.08.0 release of OCaml. >> > Its build system has the option to build against a private build of >> > OCaml 3.12 and a copy of lablgtk. >> > I adapted the port to use this option and therefore get rid of the >> > dependency on a system wide OCaml installation. >> > Tested to build and start up on amd64. >> > Not tested on bytecode-only archs. >> > >> > Is this the way to go? OK to commit? >> > Is this port still in use? > > I don't think this is a good way forward if that package is used on non-x86 > archs, there were many bugs there in older ocaml versions. Seconded. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
[NEW] slant-0.0.20
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 Best, Kristaps slant-0.0.20.tgz Description: Binary data
NEW: textproc/epubcheck
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 epubcheck.tar.gz Description: epubcheck.tar.gz
