Re: sysutils/u-boot/rk3308
On Wed, Mar 27, 2024 at 10:13:40AM +0100, Mark Kettenis wrote: > > Date: Wed, 27 Mar 2024 18:57:11 +1000 > > From: Jonathan Matthew > > > > We've had kernel support for RK3308 based systems for a while, but it's been > > difficult to install on them. Recent U-Boot versions include support for > > them, so we can fix that now. > > > > I've replaced the old hand built Rock Pi S firmware I was previously using > > with one built from this port, and it works much better. > > > > ok? > > I think you need to patch the device trees to set the serial console > speed to 115200. Which probably means you've tested this with a > patches device tree from somewhere else. Dothings work with the > device tree built into U-Boot? Right, there's a bit of a mess there, in that the U-Boot device tree doesn't have USB and the Linux device tree uses a different compatible string for the ethernet device for no good reason. The U-Boot device tree (with the serial console set to 115200) does work for the hardware it includes. Updated tarball including device tree patches attached. > > Otherwise this looks ok. > u-boot-rk3308.tar.gz Description: application/tar-gz
sysutils/u-boot/rk3308
We've had kernel support for RK3308 based systems for a while, but it's been difficult to install on them. Recent U-Boot versions include support for them, so we can fix that now. I've replaced the old hand built Rock Pi S firmware I was previously using with one built from this port, and it works much better. ok? u-boot-rk3308.tar.gz Description: application/tar-gz
link nginx-lua with libpcre
While preparing for upgrading some systems to 7.4 today, I found that the
nginx-lua module currently doesn't load. It uses libpcre but doesn't link
against it, and this used to work when nginx itself used libpcre, but now
it's using libpcre2. I figure the simplest thing to do is to just link
the module against libpcre, which the diff below seems to manage.
lua-nginx-module upstream added pcre2 support recently, so it may be possible
to backport that to the version we're stuck at, but that seems like a
post-release type of solution.
Index: Makefile
===
RCS file: /cvs/ports/www/nginx/Makefile,v
retrieving revision 1.173
diff -u -p -u -p -r1.173 Makefile
--- Makefile26 Sep 2023 17:58:09 - 1.173
+++ Makefile3 Oct 2023 12:45:56 -
@@ -97,7 +97,7 @@ WANTLIB-njs= exslt m xml2 xslt
WANTLIB-xslt= exslt xml2 xslt
WANTLIB-naxsi=
WANTLIB-ldap_auth= ldap
-WANTLIB-lua= ${MODLUA_WANTLIB} m
+WANTLIB-lua= ${MODLUA_WANTLIB} m pcre
WANTLIB-headers_more=
WANTLIB-perl= c m perl
WANTLIB-passenger= m pthread ${COMPILER_LIBCXX}
@@ -109,7 +109,8 @@ LIB_DEPENDS-xslt= textproc/libxml \
LIB_DEPENDS-image_filter=graphics/gd
LIB_DEPENDS-geoip2=net/libmaxminddb
LIB_DEPENDS-ldap_auth= databases/openldap
-LIB_DEPENDS-lua= ${MODLUA_LIB_DEPENDS}
+LIB_DEPENDS-lua= ${MODLUA_LIB_DEPENDS} \
+ devel/pcre
LIB_DEPENDS-rtmp=
LIB_DEPENDS-securelink=
LIB_DEPENDS-njs= devel/pcre2 \
@@ -120,7 +121,8 @@ MODLUA_RUNDEP= No
RUN_DEPENDS= www/nginx,-main=${VERSION}
RUN_DEPENDS-main= # blank (override default)
RUN_DEPENDS-lua= ${RUN_DEPENDS} \
- ${_MODLUA_RUN_DEPENDS}
+ ${_MODLUA_RUN_DEPENDS} \
+ devel/pcre
RUN_DEPENDS-passenger= ${RUN_DEPENDS} \
ruby*-passenger-*:www/ruby-passenger
Index: patches/patch-lua-nginx-module_config
===
RCS file: patches/patch-lua-nginx-module_config
diff -N patches/patch-lua-nginx-module_config
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lua-nginx-module_config 3 Oct 2023 12:45:56 -
@@ -0,0 +1,11 @@
+--- lua-nginx-module/config.orig Tue Oct 3 22:18:35 2023
lua-nginx-module/configTue Oct 3 22:21:42 2023
+@@ -181,7 +181,7 @@
+ if [ $NGX_RPATH = YES ]; then
+ ngx_feature_libs="-R/usr/local/lib -L/usr/local/lib -llua -lm"
+ else
+-ngx_feature_libs="-L/usr/local/lib -llua5.1 -lm"
++ngx_feature_libs="-L/usr/local/lib -llua5.1 -lpcre -lm"
+ fi
+ . auto/feature
+ fi
Re: [Update] devel/rebar3 3.21.0
You should take maintainer. I don't use this port any more.
On Tue, Jun 27, 2023 at 09:14:08PM +0200, Volker Schlecht wrote:
> Ping ... still needs a maintainer ok :-)
>
> On 6/12/23 17:42, Volker Schlecht wrote:
> > Ping with an update to rebar3 3.22.0.
> > Difference to 3.21.0 affects Windows only, but since I'm proposing
> > an update anyway, why not take the latest version.
> >
> > Both flavors still build, test and run fine on amd64.
> >
> > On 5/19/23 09:07, Volker Schlecht wrote:
> >> Cc: Maintainer
> >>
> >> Updates rebar3 to 3.21.0, which is the fist version to be fully
> compatible with erlang26.
> >>
> >> Adds an erlang26 FLAVOR
> >>
> >> Tests pass without failure for both flavors.
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/rebar3/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- Makefile 15 Mar 2023 13:15:13 - 1.10
> +++ Makefile 12 Jun 2023 13:06:11 -
> @@ -2,7 +2,7 @@ COMMENT = Erlang build tool
>
> GH_ACCOUNT = erlang
> GH_PROJECT = rebar3
> -GH_TAGNAME = 3.20.0
> +GH_TAGNAME = 3.22.0
> CATEGORIES = devel
> HOMEPAGE = https://www.rebar3.org
> MAINTAINER = Jonathan Matthew
> @@ -10,13 +10,12 @@ MAINTAINER = Jonathan Matthew # APLv2
> PERMIT_PACKAGE = Yes
>
> -# rebar 3.19 only supports OTP 23..25
> -FLAVORS =erlang25
> +FLAVORS =erlang25 erlang26
> FLAVOR ?=erlang25
>
> MASTER_SITES1 = https://repo.hex.pm/tarballs/
>
> -.if ${FLAVOR:Merlang25}
> +.if ${FLAVOR:Merlang2[5,6]}
> _EV = ${FLAVOR:C/.*([0-9][0-9]+\$)/\1/}
> RUN_DEPENDS = lang/erlang/${_EV}
> ERL_VERSION = ${_EV}
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/rebar3/distinfo,v
> retrieving revision 1.4
> diff -u -p -r1.4 distinfo
> --- distinfo 15 Mar 2023 13:15:13 - 1.4
> +++ distinfo 12 Jun 2023 13:06:11 -
> @@ -1,4 +1,4 @@
> SHA256 (meck-0.8.13.tar) = 008BPBVttRrVfMVWiRuXIOahwd9f4uFa+ZnITWzr6xo=
> -SHA256 (rebar3-3.20.0.tar.gz) = U+1/KUqLj7TX11mIxpGUlDgxwQTTmDKh+jAwexqFk94=
> +SHA256 (rebar3-3.22.0.tar.gz) = KLJWA4tEXsgY0swzAAsyF/QqlGIZ7eVatZcFA7/PZkc=
> SIZE (meck-0.8.13.tar) = 34304
> -SIZE (rebar3-3.20.0.tar.gz) = 785992
> +SIZE (rebar3-3.22.0.tar.gz) = 797341
> Index: patches/patch-rebar_config
> ===
> RCS file: /cvs/ports/devel/rebar3/patches/patch-rebar_config,v
> retrieving revision 1.5
> diff -u -p -r1.5 patch-rebar_config
> --- patches/patch-rebar_config15 Mar 2023 13:15:13 - 1.5
> +++ patches/patch-rebar_config12 Jun 2023 13:06:11 -
> @@ -6,7 +6,7 @@ Index: rebar.config
> @@ -12,7 +12,7 @@
> {escript_name, rebar3}.
> {escript_wrappers_windows, ["cmd", "powershell"]}.
> - {escript_comment, "%%Rebar3 3.20.0\n"}.
> + {escript_comment, "%%Rebar3 3.22.0\n"}.
> -{escript_emu_args, "%%! +sbtu +A1\n"}.
> +{escript_emu_args, "%%! +sbtu +A1 -escript main rebar3\n"}.
> %% escript_incl_priv is for internal rebar-private use only.
Re: Proposal/Question: drop databases/riak?
On Fri, Dec 30, 2022 at 09:59:07AM +0100, Volker Schlecht wrote: > Cc: Maintainer > > Hi, > > the version of riak in ports has been broken for almost two years now, so I > would consider it a safe assumption that there's not a whole lot of interest > in that port. > While I could (and would be willing to) try to update it to a more recent > version, that builds and works with erlang 25.x, I'm really not sure if it's > effort well spent: > > * Nobody seemed to miss it for two years on OpenBSD > * None of the other BSDs provide ports/packages for it > * Barely a Linux distribution provides packages for it > https://repology.org/projects/?search=riak > > At the same time, if/when my proposed update to benchmarks/tsung gets in, > broken databases/riak will be the only port holding back a removal of > lang/erlang/21 and devel/rebar, both of which are not enjoying significant > upstream support anymore. > > Any thoughts? It doesn't seem to be possible to keep riak buildable without holding back erlang and rebar/rebar3 enough to cause problems elsewhere, and like you say no one minds that it's been marked broken for years now. dlg@ and I still use it, but it runs on machines that don't get upgraded very often, so we can just deal with it ourselves. ok jmatthew@ if someone is itching to get rid of it.
fix net/irssi on ld.bfd arches
On Thu, Nov 03, 2022 at 06:00:00AM -0600, k...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-10-31/net/irssi.log
Now that this uses meson, it needs -Wl,--as-needed disabled to build on ld.bfd
arches. I copied this bit from another port.
ok?
Index: Makefile
===
RCS file: /cvs/ports/net/irssi/Makefile,v
retrieving revision 1.99
diff -u -p -r1.99 Makefile
--- Makefile2 Nov 2022 01:18:42 - 1.99
+++ Makefile3 Nov 2022 11:35:01 -
@@ -34,6 +34,13 @@ MODMESON_CONFIGURE_ARGS += -Ddisable-utf
-Dwith-perl=yes \
-Dwith-proxy=yes
+# disable meson's default of using "-Wl,--as-needed" on ld.bfd arches;
+# build failures due to undefined references are often seen.
+.include
+.if !${PROPERTIES:Mlld}
+MODMESON_CONFIGURE_ARGS += -Db_asneeded=false
+.endif
+
RUN_DEPENDS-otr = net/irssi,-main
LIB_DEPENDS-otr = devel/glib2>=2.28.0 \
security/libgcrypt>=1.2.0 \
Re: llvm 13 memcpy optimiser breaks lang/node
On Tue, Jan 25, 2022 at 07:51:46AM +1000, Jonathan Matthew wrote: > On Mon, Jan 24, 2022 at 10:03:19AM -0700, Theo de Raadt wrote: > > Stuart Henderson wrote: > > > > > On 2022/01/24 22:17, Jonathan Matthew wrote: > > > > The proposed update to lang/node makes this irrelevant, but I thought > > > > I'd send > > > > it anyway since it may come up elsewhere too. > > > > > > > > I noticed that on one system, 'npm install less' would abort, logging > > > > 'node: backwards memcpy', but on another it worked fine. Eventually I > > > > figured out this was because the working one had packages built with > > > > llvm 11, > > > > the other with llvm 13 packages, and llvm 13's memcpy optimiser was > > > > turning > > > > a series of small memcpys in node's bundled zlib into one larger one, > > > > without > > > > identifying that the src and dest of the larger memcpy could overlap. > > > > > > > > Compiling the bundled zlib with -fno-builtin-memcpy prevents it from > > > > doing > > > > that, which fixes npm. > > > > > > If we can't trust the compiler's builtin memcpy to do the right thing then > > > it probably needs disabling completely... > > > > Right. We cannot conclude this is only in one specific piece of software. > > > > Has anyone reached opened a bug report with clang? > > I'll extract the memcpy loop out and try to turn it into something I can > include in a bug report. While doing that I noticed the zlib code was applying the 'restrict' qualifier to one of the pointers in one case where both the source and destination of the copy were in the output buffer. The compiler can assume there's no pointer aliasing in that case, so it used memcpy rather than memmove. So the fault here is really with node, it just happens that llvm's optimiser got more aggressive between 11 and 13. chromium fixed this a while ago here: https://chromium.googlesource.com/chromium/src.git/+/e0f88a903fdcb6c772de1929834a73d1662d509a%5E%21/ but node hasn't applied that change to their copy yet. I've opened an issue against node suggesting that they should do so.
Re: llvm 13 memcpy optimiser breaks lang/node
On Mon, Jan 24, 2022 at 10:03:19AM -0700, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2022/01/24 22:17, Jonathan Matthew wrote: > > > The proposed update to lang/node makes this irrelevant, but I thought I'd > > > send > > > it anyway since it may come up elsewhere too. > > > > > > I noticed that on one system, 'npm install less' would abort, logging > > > 'node: backwards memcpy', but on another it worked fine. Eventually I > > > figured out this was because the working one had packages built with llvm > > > 11, > > > the other with llvm 13 packages, and llvm 13's memcpy optimiser was > > > turning > > > a series of small memcpys in node's bundled zlib into one larger one, > > > without > > > identifying that the src and dest of the larger memcpy could overlap. > > > > > > Compiling the bundled zlib with -fno-builtin-memcpy prevents it from doing > > > that, which fixes npm. > > > > If we can't trust the compiler's builtin memcpy to do the right thing then > > it probably needs disabling completely... > > Right. We cannot conclude this is only in one specific piece of software. > > Has anyone reached opened a bug report with clang? I'll extract the memcpy loop out and try to turn it into something I can include in a bug report.
llvm 13 memcpy optimiser breaks lang/node
The proposed update to lang/node makes this irrelevant, but I thought I'd send
it anyway since it may come up elsewhere too.
I noticed that on one system, 'npm install less' would abort, logging
'node: backwards memcpy', but on another it worked fine. Eventually I
figured out this was because the working one had packages built with llvm 11,
the other with llvm 13 packages, and llvm 13's memcpy optimiser was turning
a series of small memcpys in node's bundled zlib into one larger one, without
identifying that the src and dest of the larger memcpy could overlap.
Compiling the bundled zlib with -fno-builtin-memcpy prevents it from doing
that, which fixes npm.
This should only affect the zlib bundled in node and chromium (and possibly
elsewhere?). The version in node and chromium has a supposedly optimised
inner loop using memcpy, while other versions use simpler byte copy loops,
which get turned into inline unrolled loops rather than memcpy calls.
The proposed update to node 16.13.2 also switches to using the system zlib,
so we probably don't need the diff below.
Index: Makefile
===
RCS file: /cvs/ports/lang/node/Makefile,v
retrieving revision 1.93
diff -u -p -u -p -r1.93 Makefile
--- Makefile2 Nov 2021 00:01:17 - 1.93
+++ Makefile24 Jan 2022 10:17:02 -
@@ -19,7 +19,7 @@ DISTFILES = node-pledge-{}${PLEDGE_VER}
DISTNAME = node-${NODE_VERSION}
PKGNAME = ${DISTNAME:S/v//g}
-REVISION = 0
+REVISION = 1
MASTER_SITES0 =https://github.com/qbit/node-pledge/archive/
Index: patches/patch-deps_zlib_zlib_gyp
===
RCS file: /cvs/ports/lang/node/patches/patch-deps_zlib_zlib_gyp,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-deps_zlib_zlib_gyp
--- patches/patch-deps_zlib_zlib_gyp6 Sep 2021 13:49:44 - 1.2
+++ patches/patch-deps_zlib_zlib_gyp24 Jan 2022 10:17:02 -
@@ -4,19 +4,24 @@ node has a patch to add SIMD etc optimiz
disable on i386, it breaks build. it uses cpuid to detect features so
_should_ work on amd64.
+clang 13 does not safely optimise the memcpy calls in the optimized
+zlib code, resulting in backwards memcpys and node processes aborting,
+so disable memcpy optimization for now.
+
Index: deps/zlib/zlib.gyp
--- deps/zlib/zlib.gyp.orig
+++ deps/zlib/zlib.gyp
-@@ -64,7 +64,7 @@
+@@ -64,7 +64,8 @@
'USE_FILE32API'
],
}],
-['(target_arch in "ia32 x64 x32" and OS!="ios") or
arm_fpu=="neon"', {
+['(target_arch in "x64" and OS!="ios") or arm_fpu=="neon"', {
++ 'cflags': [ '-fno-builtin-memcpy' ],
'sources': [
'adler32_simd.c',
'adler32_simd.h',
-@@ -77,7 +77,7 @@
+@@ -77,7 +78,7 @@
'sources': [ 'inflate.c', ],
}],
# Incorporate optimizations where possible
Re: rebar3 update
On Wed, May 26, 2021 at 10:13:44PM +1000, Jonathan Matthew wrote:
> On Mon, May 24, 2021 at 05:07:12PM +0100, Stuart Henderson wrote:
> > danj pointed out https://ferd.ca/you-ve-got-to-upgrade-rebar3.html;
> > here's an update for the port to a version which both has a fix for this,
> > and still supports erlang 21 (3.15.x support OTP 19 to 23; 3.16.x
> > supports 22 to 24).
>
> Thanks for looking at this.
>
> >
> > while there I fixed the distfile name from the current bare version
> > number, and got tests to work.
> >
> > i think the existing patches to change these ...
> >
> > -"$BINDIR/erl" -boot start_clean \
> > +"$BINDIR/erl${ERL_VERSION}" -boot start_clean \
> >
> > in relx_get_nodename() etc are incorrect, BINDIR refers to
> > /usr/local/lib/erlang21/erts-10.2/bin where the files have no version
> > suffix, so i've dropped those. (of course I've kept the patches for
> > filenames searched in the default PATH).
>
> I'm a bit confused about this. BINDIR can also be the erts/bin
> directory of a release generated by rebar3/relx, and in those, the erl
> binary does have the version suffix. I'm not sure how it gets there.
> I'll look into this more.
Turns out I did this myself, which of course indicates the patches are
wrong and should be dropped.
>
> >
> > the test suite passes, but i'm not really a user of this, so a
> > real-world test is probably a good idea.
>
> My main use for rebar3 is building current versions of databases/riak
> (not yet in the ports tree), and last time I tried, it didn't work with
> newer versions of rebar3. I may be able to find something else.
I've compiled some other stuff with this update and it all works ok.
ok jmatthew@
Re: rebar3 update
On Mon, May 24, 2021 at 05:07:12PM +0100, Stuart Henderson wrote:
> danj pointed out https://ferd.ca/you-ve-got-to-upgrade-rebar3.html;
> here's an update for the port to a version which both has a fix for this,
> and still supports erlang 21 (3.15.x support OTP 19 to 23; 3.16.x
> supports 22 to 24).
Thanks for looking at this.
>
> while there I fixed the distfile name from the current bare version
> number, and got tests to work.
>
> i think the existing patches to change these ...
>
> -"$BINDIR/erl" -boot start_clean \
> +"$BINDIR/erl${ERL_VERSION}" -boot start_clean \
>
> in relx_get_nodename() etc are incorrect, BINDIR refers to
> /usr/local/lib/erlang21/erts-10.2/bin where the files have no version
> suffix, so i've dropped those. (of course I've kept the patches for
> filenames searched in the default PATH).
I'm a bit confused about this. BINDIR can also be the erts/bin
directory of a release generated by rebar3/relx, and in those, the erl
binary does have the version suffix. I'm not sure how it gets there.
I'll look into this more.
>
> the test suite passes, but i'm not really a user of this, so a
> real-world test is probably a good idea.
My main use for rebar3 is building current versions of databases/riak
(not yet in the ports tree), and last time I tried, it didn't work with
newer versions of rebar3. I may be able to find something else.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/rebar3/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- Makefile 19 Feb 2021 03:58:34 - 1.4
> +++ Makefile 24 May 2021 15:43:55 -
> @@ -2,24 +2,21 @@
>
> COMMENT =Erlang build tool
>
> -V= 3.13.2
> -PKGNAME= rebar3-${V}
> -DISTNAME=${V}
> -CATEGORIES= devel
> -HOMEPAGE=https://www.rebar3.org
> +GH_ACCOUNT = erlang
> +GH_PROJECT = rebar3
> +GH_TAGNAME = 3.15.2
> +CATEGORIES = devel
> +HOMEPAGE = https://www.rebar3.org
> MAINTAINER = Jonathan Matthew
>
> # APLv2
> -PERMIT_PACKAGE= Yes
> +PERMIT_PACKAGE = Yes
>
> FLAVORS =erlang21
> FLAVOR ?=erlang21
>
> -MASTER_SITES = https://github.com/erlang/rebar3/archive/
> MASTER_SITES1 = https://repo.hex.pm/tarballs/
>
> -WRKDIST =${WRKDIR}/rebar3-${V}
> -
> .if ${FLAVOR:Merlang21}
> _EV = ${FLAVOR:C/.*([0-9][0-9]+\$)/\1/}
> RUN_DEPENDS = lang/erlang/${_EV}
> @@ -28,22 +25,26 @@ ERL_VERSION = ${_EV}
> ERRORS += "Invalid FLAVOR set: ${FLAVOR}"
> .endif
>
> -EXTRACT_ONLY = ${V}.tar.gz
> +EXTRACT_ONLY = rebar3-${GH_TAGNAME}.tar.gz
>
> +# certifi held back; >=2.6.0 -> "undefined parse transform 'certifi_pt'"
> HEX_MODULES = \
> - bbmustache 1.8.0 \
> - certifi 2.5.1 \
> - cf 0.2.2 \
> - cth_readable1.4.6 \
> - erlware_commons 1.3.1 \
> + bbmustache 1.12.1 \
> + certifi 2.5.3 \
> + cf 0.3.1 \
> + cth_readable1.5.1 \
> + erlware_commons 1.5.0 \
> eunit_formatters0.5.0 \
> - getopt 1.0.1 \
> - parse_trans 3.3.0 \
> + getopt 1.0.2 \
> + parse_trans 3.4.0 \
> providers 1.8.1 \
> - relx3.33.0 \
> - ssl_verify_fun 1.1.5
> + relx4.4.0 \
> + ssl_verify_fun 1.1.6
> +# for tests
> +HEX_MODULES += \
> + meck0.8.13
>
> -DISTFILES = ${V}.tar.gz
> +DISTFILES = rebar3-{}${GH_TAGNAME}.tar.gz
> .for _m _v in ${HEX_MODULES}
> DISTFILES += ${_m}-${_v}.tar:1
> .endfor
> @@ -75,5 +76,11 @@ do-build:
>
> do-install:
> ${INSTALL_SCRIPT} ${WRKSRC}/rebar3 ${PREFIX}/bin/rebar3-${ERL_VERSION}
> +
> +PORTHOME=${WRKDIR}
> +do-test:
> + cd ${WRKSRC} && \
> + ${SETENV} ${ALL_TEST_ENV} ./rebar3 escriptize && \
> + ${SETENV} ${ALL_TEST_ENV} ./rebar3 ct
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/rebar3/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo 26 Nov 2020 03:31:56 -
Re: [PATCH] Remove erlang19 flavor from devel/rebar{,3}
On Wed, Feb 17, 2021 at 09:10:23PM -0800, Greg Steuck wrote:
> I built both packages with no options to test they still are OK.
>
> Subject: [PATCH] Remove erlang19 flavor from devel/rebar{,3}
There's no reason for rebar to hold up the removal of erlang 19,
and this is trivial to revert if someone revives it.
ok jmatthew@
>
> The goal is to erlang19 broken by -fno-common.
> ---
> devel/rebar/Makefile | 4 ++--
> devel/rebar3/Makefile | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git devel/rebar/Makefile devel/rebar/Makefile
> index e1c5a109dff..98294bc0422 100644
> --- devel/rebar/Makefile
> +++ devel/rebar/Makefile
> @@ -17,10 +17,10 @@ PERMIT_PACKAGE= Yes
>
> # This port cannot use the erlang module for the module depends on this port.
> # Keep in sync with erlang.port.mk
> -FLAVORS =erlang19 erlang21
> +FLAVORS =erlang21
> FLAVOR ?=erlang21
>
> -.if ${FLAVOR:Merlang19 || ${FLAVOR:Merlang21}}
> +.if ${FLAVOR:Merlang21}}
> _EV =${FLAVOR:C/.*([0-9][0-9]+\$)/\1/}
> RUN_DEPENDS =lang/erlang/${_EV}
> ERL_VERSION =${_EV}
> diff --git devel/rebar3/Makefile devel/rebar3/Makefile
> index 617fa161316..0f8638b6e12 100644
> --- devel/rebar3/Makefile
> +++ devel/rebar3/Makefile
> @@ -12,7 +12,7 @@ MAINTAINER =Jonathan Matthew
>
> # APLv2
> PERMIT_PACKAGE= Yes
>
> -FLAVORS =erlang19 erlang21
> +FLAVORS =erlang21
> FLAVOR ?=erlang21
>
> MASTER_SITES = https://github.com/erlang/rebar3/archive/
> @@ -20,7 +20,7 @@ MASTER_SITES1 = https://repo.hex.pm/tarballs/
>
> WRKDIST =${WRKDIR}/rebar3-${V}
>
> -.if ${FLAVOR:Merlang19} || ${FLAVOR:Merlang21}
> +.if ${FLAVOR:Merlang21}
> _EV = ${FLAVOR:C/.*([0-9][0-9]+\$)/\1/}
> RUN_DEPENDS = lang/erlang/${_EV}
> ERL_VERSION = ${_EV}
> --
> 2.30.1
>
NEW: devel/rebar3 (again)
I picked up an earlier attempt at a port for rebar3, the successor to devel/rebar. My main interest in this is that I need it to revive databases/riak, so for now it's at the version that riak requires. rebar3 loves downloading things and updating git checkouts when you ask it to build something. To convince it to not do that, I've added all its dependencies as distfiles that are downloaded from http://hex.pm/ and extracted into two locations, one to stop the rebar3 bootstrap from downloading them, the second to stop the bootstrapped rebar3 from doing it. The patches are all in support of using versioned erl and escript binaries. Since the rebar3 binary is called rebar3, what should its erlang-versioned binaries be called? They currently end up called 'rebar3-21' for erlang21, which isn't great, but I can't think of anything better. ok to import? rebar3.tar.gz Description: application/tar-gz
Re: NEW: security/pivy
ping? On Mon, May 25, 2020 at 08:01:58PM +1000, Jonathan Matthew wrote: > Hi, > > Here's a new port, security/pivy, a set of tools for using PIV tokens (like > Yubikeys) as an SSH agent, for encrypting data at rest, and more. > > pkg/DESCR: > Pivy is an implementation of a simple PIV client with minimal dependencies. > It contains a pivy-tool binary which can conduct basic operations using > PIV cards, and the pivy-agent, which implements the SSH agent protocol as > a drop-in replacement for the OpenSSH ssh-agent command (except that the > keys it contains are always on a PIV card). > > "PIV cards" notably includes Yubico Yubikey devices such as the NEO and > Yubikey4, which can store up to 24 keys by using the "retired key" slots > (which this agent supports). > > > I've built and used this on amd64 and armv7, and built it on sparc64. > > ok to import?
NEW: security/pivy
Hi, Here's a new port, security/pivy, a set of tools for using PIV tokens (like Yubikeys) as an SSH agent, for encrypting data at rest, and more. pkg/DESCR: Pivy is an implementation of a simple PIV client with minimal dependencies. It contains a pivy-tool binary which can conduct basic operations using PIV cards, and the pivy-agent, which implements the SSH agent protocol as a drop-in replacement for the OpenSSH ssh-agent command (except that the keys it contains are always on a PIV card). "PIV cards" notably includes Yubico Yubikey devices such as the NEO and Yubikey4, which can store up to 24 keys by using the "retired key" slots (which this agent supports). I've built and used this on amd64 and armv7, and built it on sparc64. ok to import? pivy.tar.gz Description: application/gzip
Re: [sparc64/mips64] patch erlang21 to fix devel/rebar,erlang21
On Tue, Feb 18, 2020 at 11:49:43PM -0500, Kurt Mosiejczuk wrote:
> On Wed, Feb 19, 2020 at 11:48:28AM +1000, Jonathan Matthew wrote:
>
> > > I thought I'd have a look at this, since I'm actually using erlang
> > > on sparc64 now. The erlang21 flavor built, but the escriptized file
> > > ends up looking like this:
>
> > > -r-x--S--- 1 4087335480 1892169536 209098 Feb 19 07:36 rebar
>
> > > which looks like erlang21 is screwing up its chown and chmod syscalls.
>
> > This is fixed in otp 21.2.1, by this change:
> > https://github.com/erlang/otp/commit/df0638e021eb18a4271a02fdae08aa1779867209
>
> Based upon this information, here is a patch for lang/erlang/21 to add
> this patch to the current version.
>
> ok?
Looks good to me, and I built a package with this and it managed to build rebar
with correct ownership and permissions.
>
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/erlang/21/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- Makefile 25 Jun 2019 20:25:21 - 1.4
> +++ Makefile 19 Feb 2020 04:47:02 -
> @@ -13,8 +13,8 @@ PKGNAME=erlang-$V
> PKGNAME-main=erlang-$V
> PKGNAME-wx= erlang-wx-$V
>
> -REVISION-main= 2
> -REVISION-wx= 2
> +REVISION-main= 3
> +REVISION-wx= 3
>
> VERSION_SPEC=>=21v0,<22v0
> PKGSPEC-main=erlang-${VERSION_SPEC}
> Index: patches/patch-erts_emulator_nifs_common_prim_file_nif_c
> ===
> RCS file: patches/patch-erts_emulator_nifs_common_prim_file_nif_c
> diff -N patches/patch-erts_emulator_nifs_common_prim_file_nif_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-erts_emulator_nifs_common_prim_file_nif_c 19 Feb 2020
> 04:47:02 -
> @@ -0,0 +1,26 @@
> +$OpenBSD$
> +
> +erts: Fix warning and potential big-endian-bug in prim_file
> +https://github.com/erlang/otp/commit/df0638e021eb18a4271a02fdae08aa1779867209
> +
> +Index: erts/emulator/nifs/common/prim_file_nif.c
> +--- erts/emulator/nifs/common/prim_file_nif.c.orig
> erts/emulator/nifs/common/prim_file_nif.c
> +@@ -933,7 +933,7 @@ static ERL_NIF_TERM set_permissions_nif(ErlNifEnv *env
> + posix_errno_t posix_errno;
> +
> + efile_path_t path;
> +-Uint permissions;
> ++unsigned int permissions;
> +
> + if(argc != 2 || !enif_get_uint(env, argv[1], &permissions)) {
> + return enif_make_badarg(env);
> +@@ -952,7 +952,7 @@ static ERL_NIF_TERM set_owner_nif(ErlNifEnv *env, int
> + posix_errno_t posix_errno;
> +
> + efile_path_t path;
> +-Sint uid, gid;
> ++int uid, gid;
> +
> + if(argc != 3 || !enif_get_int(env, argv[1], &uid)
> + || !enif_get_int(env, argv[2], &gid)) {
Re: [sparc64/mips64] devel/rebar workaround erlang21 FLAVOR not building
On Wed, Feb 19, 2020 at 07:55:41AM +1000, Jonathan Matthew wrote: > On Tue, Feb 18, 2020 at 12:25:29PM -0500, Kurt Mosiejczuk wrote: > > On Sun, Feb 16, 2020 at 12:06:03AM -0500, Kurt Mosiejczuk wrote: > > > The erlang21 FLAVOR of devel/rebar does not build. It will fail to build > > > and thus DPB will never try the other FLAVORS because of the lock hanging > > > around. (I've checked, the other two FLAVORs do build on sparc64). > > > > > Rather than mark the whole port BROKEN for these architectures, this > > > just drops the erlang21 FLAVOR for sparc64/mips64 so the other flavors > > > can build. > > > > > Yes, the better solution would be to fix the erlang21 FLAVOR, but I > > > don't know how to do that. > > > > For the record, this is a bad idea. DPB gets unhappy. > > I thought I'd have a look at this, since I'm actually using erlang on sparc64 > now. > The erlang21 flavor built, but the escriptized file ends up looking like this: > > -r-x--S--- 1 4087335480 1892169536 209098 Feb 19 07:36 rebar > > which looks like erlang21 is screwing up its chown and chmod syscalls. > This is fixed in otp 21.2.1, by this change: https://github.com/erlang/otp/commit/df0638e021eb18a4271a02fdae08aa1779867209
Re: [sparc64/mips64] devel/rebar workaround erlang21 FLAVOR not building
On Tue, Feb 18, 2020 at 12:25:29PM -0500, Kurt Mosiejczuk wrote: > On Sun, Feb 16, 2020 at 12:06:03AM -0500, Kurt Mosiejczuk wrote: > > The erlang21 FLAVOR of devel/rebar does not build. It will fail to build > > and thus DPB will never try the other FLAVORS because of the lock hanging > > around. (I've checked, the other two FLAVORs do build on sparc64). > > > Rather than mark the whole port BROKEN for these architectures, this > > just drops the erlang21 FLAVOR for sparc64/mips64 so the other flavors > > can build. > > > Yes, the better solution would be to fix the erlang21 FLAVOR, but I > > don't know how to do that. > > For the record, this is a bad idea. DPB gets unhappy. I thought I'd have a look at this, since I'm actually using erlang on sparc64 now. The erlang21 flavor built, but the escriptized file ends up looking like this: -r-x--S--- 1 4087335480 1892169536 209098 Feb 19 07:36 rebar which looks like erlang21 is screwing up its chown and chmod syscalls.
Re: net ads testjoin coredumped with "bogus pointer". OpenBSD 6.6. samba 4.8.12
On Tue, Oct 08, 2019 at 09:44:52AM +0200, Jeremie Courreges-Anglas wrote: > On Mon, Oct 07 2019, "dmitry.sensei" wrote: > > No problem 👍 > > > > пн, 7 окт. 2019 г., 16:17 Klemens Nanni : > > > >> jca@ sent an update to samba 4.9.x along its request for testing to > >> ports@ on 04.10.2019, can you check whether the new version still has > >> this problem? > > I did not try to reproduce, mostly because I don't have any DC setup to > test with. The AD DC code has always been brittle on OpenBSD (we have > no ACLs or extended attrs support); I don't recommend it for > "production" use, and I might disable it in the next updates if it's in > the way. > > I haven't tried to look at the code to see if there's an obvious reason > for this segfault. Maybe in the next days, as time permits. > A backtrace with the samba-4.9.13 package would be welcome. Bonus > points if you rebuild databases/openldap with DEBUG=-g. :) I ran into this today and found an annoyingly obvious cause. 'net' picks up ber_free() from libutil, which is definitely not the same as ber_free() from liblber. LD_PRELOAD=/usr/local/lib/liblber.so.x.y makes it work better. The last time I joined samba on an OpenBSD host to an AD domain, it was on 6.5, where the ber code wasn't in libutil.
Re: multimedia/mediatomb removal (and apache-couchdb ?)
On Sat, Apr 07, 2018 at 04:38:06PM +0100, Stuart Henderson wrote: > On 2018/04/07 13:48, Landry Breuil wrote: > > > There are still 3 ports depending on lang/spidermonkey, which is from > > the mozilla 3 days and hasnt been updated since 2010. This is probably > > crippled with security issues, so i'd like to work towards removing it. > > > > databases/riak might be updatable, i havent checked to see if it still > > relied on this ancient version of spidermonkey. > > I don't see anything that looks like a change in js engine in newer versions. > > It's not super-new but there's some discussion about use of spidermonkey > at https://github.com/basho/riak/issues/427. It doesn't seem like something > that will be changed in a hurry. Judging by this: https://github.com/basho/riak_kv/commit/e895dc730488f699a1ddfb3a988accd289b0a378 the js stuff will be removed entirely in riak 3. I think we can get away with doing it earlier than that though. If no one objects (does anyone else even use riak?) I'll do that in the next update, which should be in the next few weeks.
Re: Fix databases/riak
On Tue, May 26, 2015 at 03:04:59PM +0200, Jérémie Courrèges-Anglas wrote:
> Antoine Jacoutot writes:
> >
> > Why not just AUTOCONF_VERSION and AUTOMAKE_VERSION...
>
> I thought that this scheme made it is easier to define other
> foo_AUTO*_VERSION for other bundled packages, should the need present
> itself. Also it documents what those autotools versions are used for.
> This sounded more attractive than...
>
> >> +BUILD_DEPENDS+= devel/autoconf/${snappy_AUTOCONF_VERSION} \
> >> + devel/automake/${snappy_AUTOMAKE_VERSION} \
> >
> > ... this way you can just use ${MODGNU_AUTO*_DEPENDS}
>
> ... being able to use this.
>
> I can use ${MODGNU_AUTO*_DEPENDS} if people don't like the initial
> proposal.
I'm ok with how you're fixing the problem here, but I'll defer to actual
ports people on the autotools details.
Re: update: databases/leveldb
On Thu, Aug 16, 2012 at 7:56 PM, Stuart Henderson wrote: > On 2012/08/16 13:52, Jonathan Matthew wrote: >> Hi, >> >> This updates leveldb from an svn snapshot to release 1.5.0. >> >> One thing I'm not sure about is that I'm using upstream's shared library >> major/minor numbers rather than setting it to 0.1 or something. > > We use our own versioning for this, it looks like they are just using > shared-library numbering based on the release version number. Please either > confirm whether there are ABI changes, or just bump the major i.e. > SHARED_LIBS=leveldb 1.0 > > More info at http://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs There were some API changes since the previous snapshot, things like changing return types of C++ class methods, enough that I think it's safest to just bump it. >> +Skip checks for , snappy and tcmalloc. We don't >> +have any of these, and with our current binutils, c++ -o /dev/null >> +deletes /dev/null, which is kind of bad. > > fun! > > Unfortunately gmail mangled your diff (at least tabs->spaces) so it > doesn't apply, as this is ports@ rather than the other lists, you could > send it as an attachment if necessary.. Sorry about that. Updated diff is attached this time. Thanks for taking a look. leveldb-update.diff Description: Binary data
update: databases/leveldb
Hi,
This updates leveldb from an svn snapshot to release 1.5.0.
One thing I'm not sure about is that I'm using upstream's shared library
major/minor numbers rather than setting it to 0.1 or something.
ok?
Index: Makefile
===
RCS file: /cvs/ports/databases/leveldb/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile18 Mar 2012 12:56:56 - 1.5
+++ Makefile16 Aug 2012 03:40:53 -
@@ -5,12 +5,9 @@ ONLY_FOR_ARCHS=i386 amd64 arm
COMMENT= fast and lightweight key/value database library
-# svn rev 48, use a small version to allow seemless updating when the
-# project releases a tarball.
-DISTNAME= leveldb-0.0.48
-SHARED_LIBS= leveldb 0.0
+DISTNAME= leveldb-1.5.0
+SHARED_LIBS= leveldb 1.5
CATEGORIES=databases
-REVISION= 1
HOMEPAGE= http://leveldb.googlecode.com/
@@ -20,7 +17,7 @@ PERMIT_PACKAGE_FTP= Yes
PERMIT_DISTFILES_CDROM=Yes
PERMIT_DISTFILES_FTP= Yes
-MASTER_SITES= http://distfiles.nl/
+MASTER_SITES= http://leveldb.googlecode.com/files/
WANTLIB += m stdc++
Index: distinfo
===
RCS file: /cvs/ports/databases/leveldb/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo19 Aug 2011 06:44:00 - 1.1.1.1
+++ distinfo16 Aug 2012 03:40:53 -
@@ -1,5 +1,5 @@
-MD5 (leveldb-0.0.48.tar.gz) = EpwqrYc2JOX3ml3Td4gmnQ==
-RMD160 (leveldb-0.0.48.tar.gz) = u1efJYCf33kWh7Bc4HnqHjhKCaA=
-SHA1 (leveldb-0.0.48.tar.gz) = CzmBnOP/olwh4pZec8wAjq4363U=
-SHA256 (leveldb-0.0.48.tar.gz) = a9D1oDdS0PjXWoEh22r23vRDkaPdzHQjE6xnwMhYQLg=
-SIZE (leveldb-0.0.48.tar.gz) = 174794
+MD5 (leveldb-1.5.0.tar.gz) = Z5fhmgqfm7HBujVr+JIn8A==
+RMD160 (leveldb-1.5.0.tar.gz) = Gi4LhiLZpd6Nf5Sbw4DYd7eFrcE=
+SHA1 (leveldb-1.5.0.tar.gz) = tbRf90Bl8kLDf0ZbE9r7kllyykM=
+SHA256 (leveldb-1.5.0.tar.gz) = y3NImvhNnZfT59I0ovXjoMif+ttlfn3Z6QRyJ3eOV7o=
+SIZE (leveldb-1.5.0.tar.gz) = 199231
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/databases/leveldb/patches/patch-Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-Makefile
--- patches/patch-Makefile 19 Aug 2011 06:44:00 - 1.1.1.1
+++ patches/patch-Makefile 16 Aug 2012 03:40:53 -
@@ -1,67 +0,0 @@
-$OpenBSD: patch-Makefile,v 1.1.1.1 2011/08/19 06:44:00 jasper Exp $
-
-- Allow ${CC} and ${OPT} to be overriden, to help packagers.
- http://code.google.com/p/leveldb/issues/detail?id=32
-
-- Provide a shared library
- http://code.google.com/p/leveldb/issues/detail?id=27
-
Makefile.orig Fri Aug 5 22:40:49 2011
-+++ Makefile Thu Aug 18 17:18:19 2011
-@@ -2,13 +2,15 @@
- # Use of this source code is governed by a BSD-style license that can be
- # found in the LICENSE file. See the AUTHORS file for names of contributors.
-
--CC = g++
-+CC ?= g++
-
-+SONAME_MAJOR?=0
-+SONAME_MINOR?=0
- #---
- # Uncomment exactly one of the lines labelled (A), (B), and (C) below
- # to switch between compilation modes.
-
--OPT = -O2 -DNDEBUG # (A) Production use (optimized mode)
-+OPT ?= -O2 -DNDEBUG # (A) Production use (optimized mode)
- # OPT = -g2 # (B) Debug mode, w/ full line-level debugging
symbols
- # OPT = -O2 -g2 -DNDEBUG # (C) Profiling mode: opt, but w/debugging symbols
- #---
-@@ -36,7 +38,7 @@ else
- GOOGLE_PERFTOOLS_LDFLAGS=
- endif
-
--CFLAGS = -c -I. -I./include $(PORT_CFLAGS) $(PLATFORM_CFLAGS) $(OPT)
$(SNAPPY_CFLAGS)
-+CFLAGS += -c -I. -I./include $(PORT_CFLAGS) $(PLATFORM_CFLAGS) $(OPT)
$(SNAPPY_CFLAGS) -fPIC
-
- LDFLAGS=$(PLATFORM_LDFLAGS) $(SNAPPY_LDFLAGS) $(GOOGLE_PERFTOOLS_LDFLAGS)
-
-@@ -102,20 +104,28 @@ PROGRAMS = db_bench $(TESTS)
- BENCHMARKS = db_bench_sqlite3 db_bench_tree_db
-
- LIBRARY = libleveldb.a
-+SHARED_LIBRARY = libleveldb.so
-
--all: $(LIBRARY)
-+all: $(LIBRARY) $(SHARED_LIBRARY)
-
- check: $(PROGRAMS) $(TESTS)
- for t in $(TESTS); do echo "* Running $$t"; ./$$t || exit 1; done
-
- clean:
- -rm -f $(PROGRAMS) $(BENCHMARKS) $(LIBRARY) */*.o */*/*.o ios-x86/*/*.o
ios-arm/*/*.o
-+ -rm -f $(SHARED_LIBRARY).* $(SHARED_LIBRARY)
- -rm -rf ios-x86/* ios-arm/*
- -rm build_config.mk
-
- $(LIBRARY): $(LIBOBJECTS)
- rm -f $@
- $(AR) -rs $@ $(LIBOBJECTS)
-+
-+$(SHARED_LIBRARY): $(LIBOBJECTS)
-+ rm -f $@
-+ $(CC) -shared -Wl,-soname -Wl,$@.$(SONAME_MAJOR) $(LIBOBJECTS)
$(LDFLAGS) -o $@.$(SONAME_MAJOR).$(SONAME_MINOR)
-+ ln -s $@.$(SONAME_MAJOR).$(SONAME_MINOR) $@.$(SONAME_MAJOR)
-+ ln -s $@.$(SONAME_MAJOR).$(SONAME_MINOR) $@
-
- db_bench: db/db_bench.o $(LIBOBJECTS) $(TESTUTIL)
- $(CC) $(LDFLAGS) db/db_bench.o $(LIBOBJECTS) $(TESTUTIL) -o $@
Index: patches/patch-build_detect_platform
==
new: databases/riak
"Riak combines a decentralized key-value store, a flexible map/reduce engine, and a friendly HTTP/JSON query interface to provide a database ideally suited for Web applications." I got some feedback from Jasper on this a while ago and just recently I've caught up to the current release and fixed the last few problems I'm aware of. Tested on amd64 with rthreads, vmmap, etc. Topically, it really doesn't like not having enough fds (hence the rc_pre function) but with that out of the way it works nicely. One of its dependencies, leveldb, only builds on amd64, i386 and arm, so trying to test it elsewhere isn't going to be productive. riak.tgz Description: GNU Zip compressed data
include headers in leveldb package
It's a bit hard to compile anything using leveldb when the headers
aren't included in the package.
Index: databases/leveldb/Makefile
===
RCS file: /cvs/ports/databases/leveldb/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- databases/leveldb/Makefile 16 Feb 2012 21:27:37 - 1.4
+++ databases/leveldb/Makefile 18 Mar 2012 06:30:55 -
@@ -10,6 +10,7 @@ COMMENT= fast and lightweight key/value
DISTNAME= leveldb-0.0.48
SHARED_LIBS= leveldb 0.0
CATEGORIES=databases
+REVISION= 0
HOMEPAGE= http://leveldb.googlecode.com/
@@ -37,5 +38,7 @@ do-install:
${PREFIX}/lib/
${INSTALL_DATA_DIR} ${DOC}
cd ${WRKSRC}/doc/ && tar cf - . | tar xf - -C ${DOC}
+ ${INSTALL_DATA_DIR} ${PREFIX}/include/leveldb/
+ cd ${WRKSRC}/include/ && tar cf - . | tar xf - -C ${PREFIX}/include/
.include
Index: databases/leveldb/pkg/PLIST
===
RCS file: /cvs/ports/databases/leveldb/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- databases/leveldb/pkg/PLIST 19 Aug 2011 06:44:00 - 1.1.1.1
+++ databases/leveldb/pkg/PLIST 18 Mar 2012 06:30:55 -
@@ -1,5 +1,18 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2011/08/19 06:44:00 jasper Exp $
%%SHARED%%
+include/leveldb/
+include/leveldb/c.h
+include/leveldb/cache.h
+include/leveldb/comparator.h
+include/leveldb/db.h
+include/leveldb/env.h
+include/leveldb/iterator.h
+include/leveldb/options.h
+include/leveldb/slice.h
+include/leveldb/status.h
+include/leveldb/table.h
+include/leveldb/table_builder.h
+include/leveldb/write_batch.h
lib/libleveldb.a
share/doc/leveldb/
share/doc/leveldb/bench/
