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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2023/10/05 03:55:48 Modified files: www/nginx : Makefile Added files: www/nginx/patches: patch-lua-nginx-module_config Log message: nginx itself now uses pcre2, but the lua module still uses pcre, so now it needs to be explicitly linked against libpcre. ok sthen@ naddy@
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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2023/03/12 22:05:06 Modified files: security/pivy : Makefile distinfo security/pivy/pkg: PLIST security/pivy/patches: patch-Makefile Log message: Update to pivy 0.11.1, add dependency on json-c and enable pivy-ca
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2023/03/02 02:51:28 Modified files: security/pivy : Makefile distinfo security/pivy/patches: patch-Makefile Added files: security/pivy/patches: patch-piv-certs_c Log message: Update to pivy 0.11. Bundled OpenSSH is now clang 15 compatible.
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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2022/11/03 16:29:01 Modified files: net/irssi : Makefile Log message: Unbreak on ld.bfd arches, disable -Wl,--as-needed ok kmos@ sthen@
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 \
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2022/07/19 19:09:58 Modified files: devel/rebar3 : Makefile distinfo devel/rebar3/patches: patch-_build_default_lib_relx_priv_templates_bin patch-_build_default_lib_relx_priv_templates_extended_bin patch-rebar_config Log message: Update to rebar3 3.19.0, from Volker Schlecht
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2022/05/17 22:16:41 Modified files: security/pivy : Makefile distinfo security/pivy/patches: patch-Makefile Removed files: security/pivy/patches: patch-piv_c patch-pivy-tool_c Log message: Update to pivy 0.9.0, which is based on current LibreSSL and OpenSSH so we can drop some patches and remove BROKEN.
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2021/08/12 22:46:21 Modified files: security/pivy : Makefile distinfo security/pivy/pkg: PLIST Log message: update to pivy 0.8.0, and while here, ship the README file. schwarze@ pointed out the lack of user documentation and this is an easy first step to improving the situation.
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 - 1.1.1.1
> +++ distinfo 24 May 2021 15:43:55 -
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
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/12/09 15:50:45 Modified files: devel/rebar3 : Makefile Log message: apply MAKE_ENV to avoid trying to reach into root's homedir when building inside dpb
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/11/25 20:41:39 Modified files: devel : Makefile Log message: +rebar3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/11/25 20:31:56 Log message: Import rebar3-3.13.2 - "the official build tool for Erlang" ok jasper@ Status: Vendor Tag: jmatthew Release Tags: jmatthew_20201126 N ports/devel/rebar3/Makefile N ports/devel/rebar3/distinfo N ports/devel/rebar3/patches/patch-bootstrap N ports/devel/rebar3/patches/patch-src_rebar_prv_escriptize_erl N ports/devel/rebar3/patches/patch-_build_default_lib_relx_priv_templates_bin N ports/devel/rebar3/patches/patch-rebar_config N ports/devel/rebar3/patches/patch-_build_default_lib_relx_priv_templates_extended_bin N ports/devel/rebar3/pkg/DESCR N ports/devel/rebar3/pkg/PLIST No conflicts created by this import
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/08/27 04:27:31 Modified files: security/pivy : Makefile distinfo security/pivy/patches: patch-Makefile Log message: update to 0.7.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/08/08 05:05:26 Modified files: security/pivy : Makefile distinfo security/pivy/patches: patch-Makefile Log message: update to 0.6.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/06/18 02:22:35 Modified files: sysutils/firmware/urtwn: Makefile distinfo sysutils/firmware/urtwn/pkg: PLIST Log message: stsp@ reminded me we were still using the old version for some devices. Update the 8192cu firmware to the current linux-firmware version (using the old filenames) and drop the unused 8723 firmware. ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/06/08 04:58:33 Modified files: security : Makefile Log message: +pivy
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/06/08 04:42:59 Log message: import pivy-0.6.0 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). ok (and much help from) sthen@ Status: Vendor Tag: jmatthew Release Tags: jmatthew_20200608 N ports/security/pivy/Makefile N ports/security/pivy/distinfo N ports/security/pivy/patches/patch-Makefile N ports/security/pivy/pkg/DESCR N ports/security/pivy/pkg/PLIST No conflicts created by this import
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], )) {
> + 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], )
> + || !enif_get_int(env, argv[2], )) {
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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2018/05/15 00:38:33 Modified files: databases/riak : Makefile distinfo databases/riak/patches: patch-deps_eleveldb_c_src_build_deps_sh patch-deps_eleveldb_c_src_leveldb_build_config_mk patch-deps_eleveldb_rebar_config patch-deps_riak_kv_src_riak_kv_vnode_erl patch-rebar_config patch-rel_reltool_config patch-vars_config databases/riak/pkg: PLIST Added files: databases/riak/patches: patch-deps_hyper_src_hyper_gb_erl patch-deps_riak_kv_rebar_config patch-deps_riak_kv_src_riak_kv_mrc_map_erl patch-deps_riak_kv_src_riak_kv_put_fsm_erl patch-deps_riak_kv_src_riak_kv_sup_erl patch-deps_riak_kv_src_riak_kv_w_reduce_erl Removed files: databases/riak/patches: patch-erlang-js-rebar_config patch-erlang-js-spidermonkey_c patch-erlang-js-spidermonkey_h Log message: Update to riak 2.2.5. To help kill lang/spidermonkey, backport some changes from upstream's develop-3.0 riak_kv branch removing support for javascript commit hook and map-reduce functions; landry@ approves
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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2017/03/01 15:54:13 Modified files: databases/riak : Makefile databases/riak/patches: patch-deps_eleveldb_c_src_leveldb_build_config_mk Log message: honor CC and CXX
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2016/05/15 00:44:21 Modified files: databases/riak/patches: patch-deps_eleveldb_rebar_config Log message: forgot to update this patch as part of the riak 2.1.4 update
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2016/05/12 22:29:58 Modified files: databases/riak : Makefile distinfo databases/riak/patches: patch-deps_eleveldb_c_src_build_deps_sh patch-deps_eleveldb_c_src_leveldb_build_config_mk patch-deps_riak_kv_src_riak_kv_vnode_erl patch-erlang-js-rebar_config patch-rebar_config patch-rel_reltool_config databases/riak/pkg: PLIST Added files: databases/riak/patches: patch-deps_eleveldb_c_src_leveldb_include_leveldb_ldb_config_h Removed files: databases/riak/patches: patch-deps_eleveldb_c_src_leveldb_Makefile Log message: update to riak 2.1.4 and switch to erlang 17. jasper@ kindly checked the erlang version bits.
Re: Fix databases/riak
On Tue, May 26, 2015 at 03:04:59PM +0200, Jérémie Courrèges-Anglas wrote:
Antoine Jacoutot ajacou...@bsdfrog.org 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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2015/01/15 21:42:13 Modified files: databases/riak : Makefile distinfo databases/riak/patches: patch-deps_eleveldb_c_src_build_deps_sh patch-deps_eleveldb_c_src_leveldb_build_config_mk patch-deps_eleveldb_rebar_config patch-erlang-js-rebar_config patch-vars_config databases/riak/pkg: PFRAG.shared PLIST README Added files: databases/riak/patches: patch-deps_canola_rebar_config patch-deps_riak_kv_src_riak_kv_vnode_erl patch-rebar_config patch-rel_reltool_config Log message: update to riak 2.0.4, no longer marked broken. yokozuna (solr-based search) is disabled for now.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2014/11/02 14:18:27 Modified files: multimedia/gstreamer1/plugins-base/files: sndiosrc.c sndiosink.c gstsndio.h gstsndio.c multimedia/gstreamer1/plugins-base: Makefile Log message: Add stream volume control using sio_setvol and sio_onvol. Most gstreamer applications will pick this up rather than doing volume control inside the pipeline, meaning much lower latency on volume changes. with help and encouragement from ajacoutot@ and ratchov@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2014/09/15 01:14:21 Modified files: databases/riak : Makefile Log message: disable gtest usage so it doesn't break bulk builds, as reported by naddy and espie.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2014/02/05 04:22:51 Modified files: databases/riak : Makefile distinfo databases/riak/pkg: PFRAG.shared PLIST Log message: update to riak 1.4.7
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2013/11/02 17:07:49 Modified files: databases/riak : Makefile databases/riak/pkg: PLIST Log message: meck doesn't need to be in the package (it's only used for tests) and on some systems reltool doesn't include it in the release which makes the package build fail. help from Alex Wilson, tested by naddy
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2013/11/01 04:17:15 Removed files: databases/riak/patches: patch-deps_eleveldb_c_src_detail_hpp Log message: remove empty patch file
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2013/11/01 06:37:46 Modified files: databases/riak : Makefile Added files: databases/riak/patches: patch-deps_eleveldb_c_src_build_deps_sh patch-deps_eleveldb_rebar_config Log message: Instead of running make install for snappy, get the headers and static library from its source tree. Should make it possible for dpb to build this.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2013/10/27 05:24:06 Modified files: databases/riak : Makefile distinfo databases/riak/patches: patch-deps_eleveldb_c_src_detail_hpp patch-vars_config databases/riak/pkg: PLIST README Added files: databases/riak/patches: patch-deps_eleveldb_c_src_leveldb_Makefile patch-deps_eleveldb_c_src_leveldb_build_config_mk Removed files: databases/riak/patches: patch-deps_riaknostic_src_riaknostic_check_sysctl_erl patch-deps_riaknostic_src_riaknostic_export_erl Log message: update to riak 1.4.2 help from naddy@ and ajacoutot@, ok ajacoutot@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2013/03/27 21:56:07 Modified files: databases/riak : Makefile databases/riak/pkg: PLIST Log message: add missing files to riak's PLIST
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2012/12/18 18:47:25 Modified files: databases/riak : Makefile databases/riak/pkg: PLIST Added files: databases/riak/patches: patch-deps_riak_kv_src_riak_kv_stat_erl Log message: update riak to work with erlang r15b02, prodded by dlg@ and looked at by aja@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2012/08/24 01:26:30 Log message: import 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. ok dlg@ Status: Vendor Tag: jmatthew Release Tags: jmatthew_20120824 N ports/databases/riak/Makefile N ports/databases/riak/distinfo N ports/databases/riak/patches/patch-erlang-js-spidermonkey_c N ports/databases/riak/patches/patch-deps_eleveldb_rebar_config N ports/databases/riak/patches/patch-erlang-js-rebar_config N ports/databases/riak/patches/patch-vars_config N ports/databases/riak/patches/patch-erlang-js-spidermonkey_h N ports/databases/riak/pkg/riak.rc N ports/databases/riak/pkg/PLIST N ports/databases/riak/pkg/PFRAG.shared N ports/databases/riak/pkg/DESCR N ports/databases/riak/pkg/README No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2012/08/23 22:18:02 Modified files: infrastructure/db: user.list Log message: reserve uid for databases/riak
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2012/08/20 18:28:34 Modified files: databases/leveldb: Makefile distinfo databases/leveldb/patches: patch-Makefile patch-build_detect_platform patch-port_port_posix_h databases/leveldb/pkg: PLIST Added files: databases/leveldb/patches: patch-util_coding_cc Log message: update to leveldb 1.5.0 ok sthen@ -lpthread patch for jasper@
Re: update: databases/leveldb
On Thu, Aug 16, 2012 at 7:56 PM, Stuart Henderson s...@spacehopper.org 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 cstdatomic, 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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2012/03/18 06:56:56 Modified files: databases/leveldb: Makefile databases/leveldb/pkg: PLIST Log message: include the headers in the package ok aja sthen
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 bsd.port.mk
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/
