Re: databases/victoriametrics: update to v1.99.0

[Stuart Henderson]

On 2024/03/06 00:10, Lucas Gabriel Vuotto wrote:
> 
> 1. Make VictoriaLogs a different package. A bit wasteful, but the reality
>is that the tags differ.

Agreed. (If not doing this and instead using subpackages,
PLIST-main needs "@pkgpath databases/victoriametrics").

> 2. Stick with LTS.

No opinion on this, I don't know victoriametrics well enough.
For some programs LTS makes sense, for others it doesn't.

Re: databases/victoriametrics: update to v1.99.0

[Denis Fondras]

Le Wed, Mar 06, 2024 at 12:10:37AM +, Lucas Gabriel Vuotto a écrit :
> On Mon, Mar 04, 2024 at 01:13:46PM +0100, Denis Fondras wrote:
> > Here is a diff to update VictoriaMetrics to v1.99.0.
> > 
> > I also added VictoriaLogs in a separate package.
> > 
> > Denis
> 
> Haven't tested the patch yet, but I have a couple of questions /
> discussions about the approach.
> 
> 1. What VictoriaMetrics did with Git tags is ugly in my opinion:
>there are v0.5.0-victorialogs and v1.99.0. In this particular case,
>the diff is only documentation [0]. But there was a
>v0.4.0-victorialogs and v0.4.1-victorialogs with an important bugfix
>(make it run non-readonly), and in such cases I don't how a sensible
>strategy for picking a newer tag, with the added complexity that it
>doesn't match the order of ports' versions. This also raises the
>question: do we want to keep the both versions tied together?
> 
> 2. For VictoriaMetrics, I wanted to stick to LTS releases, as they are
>supported for 1y which gives enough coverage for OpenBSD release
>cycle of roughly 6 months. I'm chceking now, latest LTS release is
>1.97.3, but 1.97.1 is the last one to include non-enterprise tarballs
>(doesn't really matter as we build from the GitHub-generated tarball
>for the tag--their release are the built artifacts) which makes me
>doubt seriously about how much I understand of their releases.
>, I believe that it would be nice sticking with LTS, what do
>you think?
> 
> My positions here would be:
> 
> 1. Make VictoriaLogs a different package. A bit wasteful, but the reality
>is that the tags differ.
> 
> 2. Stick with LTS.
> 

Thank you for your input. I'll go back to the workbench :)

Denis

Re: databases/victoriametrics: update to v1.99.0

[Lucas Gabriel Vuotto]

On Mon, Mar 04, 2024 at 01:13:46PM +0100, Denis Fondras wrote:
> Here is a diff to update VictoriaMetrics to v1.99.0.
> 
> I also added VictoriaLogs in a separate package.
> 
> Denis

Haven't tested the patch yet, but I have a couple of questions /
discussions about the approach.

1. What VictoriaMetrics did with Git tags is ugly in my opinion:
   there are v0.5.0-victorialogs and v1.99.0. In this particular case,
   the diff is only documentation [0]. But there was a
   v0.4.0-victorialogs and v0.4.1-victorialogs with an important bugfix
   (make it run non-readonly), and in such cases I don't how a sensible
   strategy for picking a newer tag, with the added complexity that it
   doesn't match the order of ports' versions. This also raises the
   question: do we want to keep the both versions tied together?

2. For VictoriaMetrics, I wanted to stick to LTS releases, as they are
   supported for 1y which gives enough coverage for OpenBSD release
   cycle of roughly 6 months. I'm chceking now, latest LTS release is
   1.97.3, but 1.97.1 is the last one to include non-enterprise tarballs
   (doesn't really matter as we build from the GitHub-generated tarball
   for the tag--their release are the built artifacts) which makes me
   doubt seriously about how much I understand of their releases.
   , I believe that it would be nice sticking with LTS, what do
   you think?

My positions here would be:

1. Make VictoriaLogs a different package. A bit wasteful, but the reality
   is that the tags differ.

2. Stick with LTS.

Lucas

[0]: 
https://github.com/VictoriaMetrics/VictoriaMetrics/compare/v0.5.0-victorialogs...v1.99.0

databases/victoriametrics: update to v1.99.0

[Denis Fondras]

Here is a diff to update VictoriaMetrics to v1.99.0.

I also added VictoriaLogs in a separate package.

Denis

Index: Makefile
===
RCS file: /cvs/ports/databases/victoriametrics/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile21 Jan 2024 11:58:03 -  1.20
+++ Makefile4 Mar 2024 12:10:35 -
@@ -1,6 +1,7 @@
-COMMENT =  fast, cost-effective and scalable time series database
+COMMENT-main = fast, cost-effective and scalable time series database
+COMMENT-victorialogs = fast, easy-to-use and efficient logs storage
 
-V =1.93.10
+V =1.99.0
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
@@ -10,6 +11,8 @@ CATEGORIES =  databases
 
 HOMEPAGE = https://victoriametrics.com/
 
+MULTI_PACKAGES =   -main -victorialogs
+
 MAINTAINER =   Lucas Gabriel Vuotto 
 
 # Apache License 2.0
@@ -21,6 +24,7 @@ USE_GMAKE =   Yes
 
 MODULES =  lang/go
 MODGO_GOPATH = ${MODGO_WORKSPACE}
+MODGO_GO111MODULE =auto
 SUBST_VARS =   LOCALSTATEDIR
 NO_TEST =  Yes
 
@@ -36,6 +40,7 @@ do-build:
cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmauth-pure
cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmalert-pure
cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmctl-pure
+   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} 
victoria-logs-pure
 
 do-install:
${INSTALL_PROGRAM} ${WRKSRC}/bin/victoria-metrics-pure 
${PREFIX}/bin/vmetrics
@@ -45,6 +50,7 @@ do-install:
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmauth-pure ${PREFIX}/bin/vmetricsauth
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmalert-pure 
${PREFIX}/bin/vmetricsalert
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmctl-pure ${PREFIX}/bin/vmetricsctl
+   ${INSTALL_PROGRAM} ${WRKSRC}/bin/victoria-logs-pure 
${PREFIX}/bin/victoria-logs
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/vmetrics/
${INSTALL_DATA} ${WRKSRC}/README.md ${PREFIX}/share/doc/vmetrics/
${INSTALL_DATA} ${WRKSRC}/LICENSE ${PREFIX}/share/doc/vmetrics/
Index: distinfo
===
RCS file: /cvs/ports/databases/victoriametrics/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- distinfo21 Jan 2024 11:58:03 -  1.18
+++ distinfo4 Mar 2024 12:10:35 -
@@ -1,2 +1,2 @@
-SHA256 (VictoriaMetrics-VictoriaMetrics-v1.93.10.tar.gz) = 
cEdMu0IOYVelz0y/8NCS8fT7qIkGTXamWUuZksAM448=
-SIZE (VictoriaMetrics-VictoriaMetrics-v1.93.10.tar.gz) = 59976987
+SHA256 (VictoriaMetrics-VictoriaMetrics-v1.99.0.tar.gz) = 
BpFWcwOcn+SVGtLjL3BPzHxK+ST/Vmv5XYdr77rEPX0=
+SIZE (VictoriaMetrics-VictoriaMetrics-v1.99.0.tar.gz) = 36952832
Index: patches/patch-Makefile
===
RCS file: patches/patch-Makefile
diff -N patches/patch-Makefile
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-Makefile  4 Mar 2024 12:10:35 -
@@ -0,0 +1,11 @@
+Index: Makefile
+--- Makefile.orig
 Makefile
+@@ -1,6 +1,6 @@
+ PKG_PREFIX := github.com/VictoriaMetrics/VictoriaMetrics
+ 
+-MAKE_CONCURRENCY ?= $(shell getconf _NPROCESSORS_ONLN)
++MAKE_CONCURRENCY ?= $(shell getconf NPROCESSORS_ONLN)
+ MAKE_PARALLEL := $(MAKE) -j $(MAKE_CONCURRENCY)
+ DATEINFO_TAG ?= $(shell date -u +'%Y%m%d-%H%M%S')
+ BUILDINFO_TAG ?= $(shell echo $$(git describe --long --all | tr '/' '-')$$( \
Index: pkg/DESCR
===
RCS file: pkg/DESCR
diff -N pkg/DESCR
--- pkg/DESCR   27 Jan 2022 09:23:01 -  1.1.1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,2 +0,0 @@
-VictoriaMetrics is a fast, cost-effective and scalable time-series
-database.
Index: pkg/DESCR-main
===
RCS file: pkg/DESCR-main
diff -N pkg/DESCR-main
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pkg/DESCR-main  4 Mar 2024 12:10:35 -
@@ -0,0 +1,2 @@
+VictoriaMetrics is a fast, cost-effective and scalable time-series
+database.
Index: pkg/DESCR-victorialogs
===
RCS file: pkg/DESCR-victorialogs
diff -N pkg/DESCR-victorialogs
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pkg/DESCR-victorialogs  4 Mar 2024 12:10:35 -
@@ -0,0 +1,16 @@
+VictoriaLogs is a fast and easy-to-use, open source logs solution.
+
+VictoriaLogs provides the following key features:
+- accept logs from popular log collectors
+- much easier to set up and operate compared to Elasticsearch and
+  Grafana Loki
+- easy yet powerful query language with full-text search capabilities
+  across all the log fields
+- seamlessly combine with good old Unix tools for log analysis such
+  as grep, less, sort, jq, etc.
+- capacity and