UPDATE databases/victoriametrics 1.104.0

[Lucas Gabriel Vuotto]

Hello,

New release of VictoriaMetrics is out. Been running it since Wednesday
without issues. There is a single release note stating they rolled back
the non-triming of password files that caught me by surprise during the
previous release, because it was hidden in the releasones notes of rc
versions.  Full changelog at [0].

OK?

Lucas

[0]: https://docs.victoriametrics.com/changelog/#v11040


diff /usr/ports
commit - 2548567bbb29861af9e107eff264e682a2a317a7
path + /usr/ports
blob - 0b582c36603e3cf1df72c413d12faed9e1e97169
file + databases/victoriametrics/Makefile
--- databases/victoriametrics/Makefile
+++ databases/victoriametrics/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  fast, cost-effective and scalable time series database
 
-V =1.103.0
+V =1.104.0
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
blob - 9ebe7762486f20fe9e5a26e688e1d5feccb03064
file + databases/victoriametrics/distinfo
--- databases/victoriametrics/distinfo
+++ databases/victoriametrics/distinfo
@@ -1,2 +1,2 @@
-SHA256 (VictoriaMetrics-VictoriaMetrics-v1.103.0.tar.gz) = 
jJ93u9r04thPnSlxxr+/RguMBeF+Fk/5txciRmkZIAU=
-SIZE (VictoriaMetrics-VictoriaMetrics-v1.103.0.tar.gz) = 35197803
+SHA256 (VictoriaMetrics-VictoriaMetrics-v1.104.0.tar.gz) = 
3fdV6keDk0EImtgj+q9fnorwGzyDUs4RFLUa7X0WVKc=
+SIZE (VictoriaMetrics-VictoriaMetrics-v1.104.0.tar.gz) = 38957776

Re: UPDATE net/haproxy 3.0.5

[Lucas Gabriel Vuotto]

On Wed, Sep 25, 2024 at 10:25:24PM GMT, Theo Buehler wrote:
> The patch was only needed while we had LibreSSL version number < 4.0.0.
> You can drop it now.

Completely missed the LibreSSL major bump.


diff refs/heads/master 0fb72d19a2cde4c8bb077b8ed252efb0fa2c1ff4
commit - f827ea88bac5095f5080effb6dd76d9793b28f1f
commit + 0fb72d19a2cde4c8bb077b8ed252efb0fa2c1ff4
blob - f8bba57c3e06bf6ddc6571815b7ec870cf358984
blob + 22c9f838ed5ac57344c3e0e78cc399311a97cfb3
--- net/haproxy/Makefile
+++ net/haproxy/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  reliable, high performance TCP/HTTP load balancer
 
-DISTNAME = haproxy-3.0.4
+DISTNAME = haproxy-3.0.5
 CATEGORIES =   net www
 HOMEPAGE = https://www.haproxy.org/
 MAINTAINER =   Lucas Gabriel Vuotto 
blob - af21fd7be05d0040d192e7eff202403963a826cf
blob + d0475928ad847d94980fab6a142dc907f25efcc0
--- net/haproxy/distinfo
+++ net/haproxy/distinfo
@@ -1,2 +1,2 @@
-SHA256 (haproxy-3.0.4.tar.gz) = qr/ZitpyG7+2j3gFWGztA3P7TI1z4Y+qlAVaFsIJaTY=
-SIZE (haproxy-3.0.4.tar.gz) = 4689835
+SHA256 (haproxy-3.0.5.tar.gz) = rjgiHoWuugOKcl7771v+XnZnG6eVnl63TDn9B55dAC4=
+SIZE (haproxy-3.0.5.tar.gz) = 4698022
blob - 3a3bb18aa12dd0433f376a4af1419356e5bf8a8c (mode 644)
blob + /dev/null
--- net/haproxy/patches/patch-include_haproxy_quic_tls_h
+++ /dev/null
@@ -1,15 +0,0 @@
-Enable ChaCha20-Poly1305. In-place decryption was fixed.
-https://github.com/haproxy/haproxy/issues/2569
-
-Index: include/haproxy/quic_tls.h
 include/haproxy/quic_tls.h.orig
-+++ include/haproxy/quic_tls.h
-@@ -140,7 +140,7 @@ static inline const EVP_CIPHER *tls_aead(const SSL_CIP
-   return EVP_aes_128_gcm();
-   case TLS1_3_CK_AES_256_GCM_SHA384:
-   return EVP_aes_256_gcm();
--#if !defined(OPENSSL_IS_AWSLC) && (!defined(LIBRESSL_VERSION_NUMBER) || 
LIBRESSL_VERSION_NUMBER >= 0x400fL)
-+#if !defined(OPENSSL_IS_AWSLC)
-   /* WT: LibreSSL has an issue with CHACHA20 running in-place till 3.9.2
-* included, but the fix is already identified and will be merged
-* into next major version. Given that on machines without AES-NI

UPDATE net/haproxy 3.0.5

[Lucas Gabriel Vuotto]

For post-unlock, as nothing seems critical. Announcement at [0],
changelog at [1]. Probably the most interesting part is that they now
use EVP_AEAD interfaces for QUIC.

The patch update is noiser than usual because of a small change in the
surrounding code.

It still runs fine. OK?

Lucas

[0]: https://www.mail-archive.com/haproxy@formilux.org/msg45314.html
[1]: 
https://git.haproxy.org/?p=haproxy-3.0.git;a=blob_plain;f=CHANGELOG;h=94b8b9580b8bf9fde54c28e73cc299b601ee828a;hb=HEAD


diff refs/heads/master 1028662be27369584f01c854702b6ab80bd64347
commit - f827ea88bac5095f5080effb6dd76d9793b28f1f
commit + 1028662be27369584f01c854702b6ab80bd64347
blob - f8bba57c3e06bf6ddc6571815b7ec870cf358984
blob + 22c9f838ed5ac57344c3e0e78cc399311a97cfb3
--- net/haproxy/Makefile
+++ net/haproxy/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  reliable, high performance TCP/HTTP load balancer
 
-DISTNAME = haproxy-3.0.4
+DISTNAME = haproxy-3.0.5
 CATEGORIES =   net www
 HOMEPAGE = https://www.haproxy.org/
 MAINTAINER =   Lucas Gabriel Vuotto 
blob - af21fd7be05d0040d192e7eff202403963a826cf
blob + d0475928ad847d94980fab6a142dc907f25efcc0
--- net/haproxy/distinfo
+++ net/haproxy/distinfo
@@ -1,2 +1,2 @@
-SHA256 (haproxy-3.0.4.tar.gz) = qr/ZitpyG7+2j3gFWGztA3P7TI1z4Y+qlAVaFsIJaTY=
-SIZE (haproxy-3.0.4.tar.gz) = 4689835
+SHA256 (haproxy-3.0.5.tar.gz) = rjgiHoWuugOKcl7771v+XnZnG6eVnl63TDn9B55dAC4=
+SIZE (haproxy-3.0.5.tar.gz) = 4698022
blob - 3a3bb18aa12dd0433f376a4af1419356e5bf8a8c
blob + 2808d3a5be66dedae04b6334e5e3a28b65f1d835
--- net/haproxy/patches/patch-include_haproxy_quic_tls_h
+++ net/haproxy/patches/patch-include_haproxy_quic_tls_h
@@ -4,10 +4,10 @@ https://github.com/haproxy/haproxy/issues/2569
 Index: include/haproxy/quic_tls.h
 --- include/haproxy/quic_tls.h.orig
 +++ include/haproxy/quic_tls.h
-@@ -140,7 +140,7 @@ static inline const EVP_CIPHER *tls_aead(const SSL_CIP
-   return EVP_aes_128_gcm();
-   case TLS1_3_CK_AES_256_GCM_SHA384:
+@@ -156,7 +156,7 @@ static inline const QUIC_AEAD *tls_aead(const SSL_CIPH
return EVP_aes_256_gcm();
+ #endif
+ 
 -#if !defined(OPENSSL_IS_AWSLC) && (!defined(LIBRESSL_VERSION_NUMBER) || 
LIBRESSL_VERSION_NUMBER >= 0x400fL)
 +#if !defined(OPENSSL_IS_AWSLC)
/* WT: LibreSSL has an issue with CHACHA20 running in-place till 3.9.2

UPDATE net/haproxy 3.0.4

[Lucas Gabriel Vuotto]

Hey,

Point release for haproxy. Running it since 2 days without issues.

- MINOR: proto: extend connection thread rebind API
- BUILD: listener: silence a build warning about unused value without threads
- BUG/MEDIUM: quic: prevent crash on accept queue full
- CLEANUP: proto: rename TID affinity callbacks
- CLEANUP: quic: rename TID affinity elements
- BUG/MINOR: session: Eval L4/L5 rules defined in the default section
- BUG/MEDIUM: debug/cli: fix "show threads" crashing with low thread counts
- DOC: install: don't reference removed CPU arg
- BUG/MEDIUM: ssl_sock: fix deadlock in ssl_sock_load_ocsp() on error path
- BUG/MAJOR: mux-h2: force a hard error upon short read with pending error
- DOC: configuration: issuers-chain-path not compatible with OCSP
- DOC: config: improve the http-keep-alive section
- BUG/MINOR: stick-table: fix crash for src_inc_gpc() without stkcounter
- BUG/MINOR: server: Don't warn fallback IP is used during init-addr resolution
- BUG/MINOR: cli: Atomically inc the global request counter between CLI commands
- BUG/MINOR: quic: Non optimal first datagram.
- MEDIUM: sink: don't set NOLINGER flag on the outgoing stream interface
- BUG/MINOR: quic: Lack of precision when computing K (cubic only cc)
- BUG/MEDIUM: jwt: Clear SSL error queue on error when checking the signature
- MINOR: quic: Dump TX in flight bytes vs window values ratio.
- MINOR: quic: Add information to "show quic" for CUBIC cc.
- MEDIUM: h1: allow to preserve keep-alive on T-E + C-L
- MINOR: queue: add a function to check for TOCTOU after queueing
- BUG/MEDIUM: queue: deal with a rare TOCTOU in assign_server_and_queue()
- MEDIUM: init: set default for fd_hard_limit via DEFAULT_MAXFD (take #2)
- BUG/MEDIUM: init: fix fd_hard_limit default in compute_ideal_maxconn
- Revert "MEDIUM: sink: don't set NOLINGER flag on the outgoing stream 
interface"
- MEDIUM: log: relax some checks and emit diag warnings instead in 
lf_expr_postcheck()
- DOC: quic: fix default minimal value for max window size
- MINOR: proxy: Add support of 429-Too-Many-Requests in retry-on status
- BUG/MEDIUM: mux-h2: Set ES flag when necessary on 0-copy data forwarding
- BUG/MEDIUM: stream: Prevent mux upgrades if client connection is no longer 
ready
- BUG/MINIR: proxy: Match on 429 status when trying to perform a L7 retry
- BUG/MEDIUM: mux-pt: Never fully close the connection on shutdown
- BUG/MEDIUM: cli: Always release back endpoint between two commands on the mcli
- BUG/MINOR: quic: unexploited retransmission cases for Initial pktns.
- BUG/MEDIUM: mux-h1: Properly handle empty message when an error is triggered
- MINOR: mux-h2: try to clear DEM_MROOM and MUX_MFULL at more places
- BUG/MAJOR: mux-h2: always clear MUX_MFULL and DEM_MROOM when clearing the mbuf
- BUG/MINOR: quic: Too shord datagram during O-RTT handshakes (aws-lc only)
- BUG/MINOR: Crash on O-RTT RX packet after dropping Initial pktns
- BUG/MEDIUM: mux-pt: Fix condition to perform a shutdown for writes in 
mux_pt_shut()

OK?

Lucas


diff refs/heads/master bc3bb7c8017b907cb14f860e90ee2c42e923dfe2
commit - d70b8e53802701577cd1b9be0d21e237a56d2105
commit + bc3bb7c8017b907cb14f860e90ee2c42e923dfe2
blob - 105b88de29031d6373daef5492241d9710f1bb57
blob + f8bba57c3e06bf6ddc6571815b7ec870cf358984
--- net/haproxy/Makefile
+++ net/haproxy/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  reliable, high performance TCP/HTTP load balancer
 
-DISTNAME = haproxy-3.0.3
+DISTNAME = haproxy-3.0.4
 CATEGORIES =   net www
 HOMEPAGE =     https://www.haproxy.org/
 MAINTAINER =   Lucas Gabriel Vuotto 
blob - 4f5e7e594a231b2e303ecf318d8723ae4021b40a
blob + af21fd7be05d0040d192e7eff202403963a826cf
--- net/haproxy/distinfo
+++ net/haproxy/distinfo
@@ -1,2 +1,2 @@
-SHA256 (haproxy-3.0.3.tar.gz) = Oac8GHoLANJgLLP/ylLRtZ2Q8JAyc0/owD6y4pp9Gd8=
-SIZE (haproxy-3.0.3.tar.gz) = 4684023
+SHA256 (haproxy-3.0.4.tar.gz) = qr/ZitpyG7+2j3gFWGztA3P7TI1z4Y+qlAVaFsIJaTY=
+SIZE (haproxy-3.0.4.tar.gz) = 4689835

Re: Correctly create a symbolic link in a port

[Lucas Gabriel Vuotto]

On Sun, Sep 01, 2024 at 07:30:57PM GMT, David Uhden Collado wrote:
> Hello everyone,
> 
> I am currently working on porting a BitTorrent client designed to run on the
> I2P network. While I originally intended to prioritize porting other tools,
> such as the Monero CLI [1] and SimpleX Chat CLI [2] [3], I unfortunately ran
> into challenges that were too complex for me to solve. Although I received
> some help with the Monero port, we were unable to achieve a fully functional
> result.
> 
> At this point, I am focusing on this BitTorrent client, as I find it very
> useful to be able to run it as a background service on torrent seeding
> servers. However, I have encountered a specific problem that I have yet to
> resolve: in order to enable the command line interface, a symbolic link must
> be created from the "XD" binary to "XD-CLI". Despite several attempts, I
> continue to encounter errors when building the package.

This doesn't help much, as you aren't sharing what issues are you
running into.

There 261 Makefiles that use 'ln -s' according to

find . -type f \( -path './pobj/*' -o -path './mystuff/*' \) -prune -o \
-name Makefile -exec grep -Fl 'ln -s' {} + | wc -l

Quite a bunch of them do it for linking binaries during the install
phase. Of those, all the ones I checked do it in the post-install
target, so maybe you should stick to that pattern. Also, in those cases,
what I saw is that the links are either cwd -> ${PREFIX}/... or
${TRUEPREFIX}/... -> ${PREFIX}/... . Read bsd.port.mk(5), in particular
the parts for TRUEPREFIX and the section "THE FAKE FRAMEWORK", which
explicitly addresses symlinks.

Lucas

Re: [MAINTAINER UPDATE] net/transmission net/miniupnp/libnatpmp

[Lucas Gabriel Vuotto]

On Wed, Aug 28, 2024 at 07:27:27AM GMT, Josh Grosse wrote:
> This net/transmission update has been posted multiple times, starting
> in June.  Tested by me and by Lucas Gabriel Vuotto. 
> 
> Included in this diff is an update to net/miniupnp/libnatpmp, which
> fixes an rtable issue with net/transmission that was reported last year,
> debugged and resolved upstream by Lucas at the end of July.
> 
> Lucas has been bumping this diff weekly.  It'd be wonderful if this
> could be reviewed, prior to the tree getting locked.
> 
> Thanks in advance!

Committed. Thanks Josh!

UPDATE databases/victoriametrics v1.103.0

[Lucas Gabriel Vuotto]

Hey,

Update for VictoriaMetrics. Full release notes at [0]. Only a single
update note this time:

- The external_labels field in vmalert-tool test file will be deprecated
  soon. Please use -external.label command-line flag instead, in the
  same way as vmalert uses it. This change is done for the sake of
  consistency between vmalert and vmalert-tool configuration. See this
  issue[1].

Been running it fine for the last 2 days. OK?

[0]: https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v1.103.0
[1]: https://github.com/VictoriaMetrics/VictoriaMetrics/issues/6735

Lucas


diff /usr/ports
commit - e07af32358f367f4d9f1d56f9f903f523c90cc22
path + /usr/ports
blob - e80724f98e175dc648521edc37975b11a536b26a
file + databases/victoriametrics/Makefile
--- databases/victoriametrics/Makefile
+++ databases/victoriametrics/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  fast, cost-effective and scalable time series database
 
-V =1.102.1
+V =1.103.0
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
blob - db4704b2d545c6172e5459f9b24521927fd6c77b
file + databases/victoriametrics/distinfo
--- databases/victoriametrics/distinfo
+++ databases/victoriametrics/distinfo
@@ -1,2 +1,2 @@
-SHA256 (VictoriaMetrics-VictoriaMetrics-v1.102.1.tar.gz) = 
V2d7t/hbOuEnghDuWkgMW7CDS/uxwSjmNAtvaAKRbss=
-SIZE (VictoriaMetrics-VictoriaMetrics-v1.102.1.tar.gz) = 39536390
+SHA256 (VictoriaMetrics-VictoriaMetrics-v1.103.0.tar.gz) = 
jJ93u9r04thPnSlxxr+/RguMBeF+Fk/5txciRmkZIAU=
+SIZE (VictoriaMetrics-VictoriaMetrics-v1.103.0.tar.gz) = 35197803

Re: [NEW WIP]: net/monero (help needed)

[Lucas Gabriel Vuotto]

On Thu, Aug 29, 2024 at 11:44:11PM GMT, David Uhden Collado wrote:
> > Nope. I ran monerod for a full-sync. The experience wasn't nice, as the
> > whole OS would freeze for quite long periods of times. Even so,
> > painstakingly I managed to sync ~51% of the chain, and now I run into a
> > SIGSEGV in RandomX, just like you (but in a different binary). I do have
> > some things to try out, but I haven't gotten around to it yet.
> > 
> 
> I think it might be because your port does not install the libwallet.a
> library, which is located in ${WRKBUILD}/lib/. For this reason, I like to
> define the software installation in the port itself, rather than trusting
> the build tools to do everything for me.

no, it's because [0] is memcpy(buf, &a_function_pointer, sz) which
doesn't work in xonly.

[0]: 
https://github.com/tevador/RandomX/blob/master/src/jit_compiler_x86.cpp#L230

Re: mail/mblaze: backport diff to relax body line length limit

[Lucas Gabriel Vuotto]

On Thu, Aug 29, 2024 at 12:05:48AM GMT, Omar Polo wrote:
> I keep recompiling mblaze to have this in.  It allows to set
> MBLAZE_RELAXED_MIME to not encode the body of the mail if it
> is longer than 72 chars, but still does if it exceedes 998.
> 
> This is committed upstream but not yet in a release.  Lucas,
> would you be fine with backporting this?
> 
> Thanks,
> 
> Omar Polo

OK me. I don't use mblaze anymore, but this patch was really helpful
when interacting with the lists.

Re: [NEW WIP]: net/monero (help needed)

[Lucas Gabriel Vuotto]

On Tue, Aug 27, 2024 at 02:21:14PM GMT, byteskeptical wrote:
> Took me longer than expected but I've tested monero-wallet-cli,
> monero-wallet-rpc, monero-blockchain-stats, monero-blockchain-export,
> monero-blockchain-import, monero-gen-ssl-cert, and monerod. Everything
> seems to be operating as expected though I'm running into issues
> creating a new copy of the blockchain.
> 
> Whether it's using monerod or monero-blockchain-import when it gets to
> v12 (randomx introduction) I'm seg-faulting on an opt-code failure.
> Attaching a tail of the ktrace as the full file is 161GB along with a
> backtrace from gdb for similar reasons the .core file is 86GB. Seems
> like a resource exhaustion that shouldn't be happening given it's only
> suppose to take a few GB of memory and the current system has more than
> enough memory and disk space available. This was the original intent
> behind the {snprintf,strncat} patches as I suspect something is not
> being freed.
> 
> Where you able to complete a full sync Lucas?

Nope. I ran monerod for a full-sync. The experience wasn't nice, as the
whole OS would freeze for quite long periods of times. Even so,
painstakingly I managed to sync ~51% of the chain, and now I run into a
SIGSEGV in RandomX, just like you (but in a different binary). I do have
some things to try out, but I haven't gotten around to it yet.


> Don't use -Ofast.

Please add a comment, no matter how obvious is the change.
In particular, I tried it locally with a helloword. `-Wl,-z,relro' is
recognized properly.

cc -O2 -pipe   -Wl,relro -o x x.c 
ld: error: cannot open relro: No such file or directory
cc: error: linker command failed with exit code 1 (use -v to see invocation)

So I get the feeling that your patch *is disabling* relro, now and
noexecstack. noexecheap is the only unsupported one for ld.lld. It seems
like the feature detection is a bit broken, as `-Wl,-z,noexecheap' ends
up in the flags anyway, so that's something else to take a look at.

> Index: CMakeLists.txt
> --- CMakeLists.txt.orig
> +++ CMakeLists.txt
> @@ -338,7 +338,7 @@ endif()
>  if(WIN32 OR ARM OR PPC64LE OR PPC64 OR PPC)
>set(OPT_FLAGS_RELEASE "-O2")
>  else()
> -  set(OPT_FLAGS_RELEASE "-Ofast")
> +  set(OPT_FLAGS_RELEASE "")
>  endif()
>  
>  # BUILD_TAG is used to select the build type to check for a new version
> @@ -867,15 +867,15 @@ else()
>add_linker_flag_if_supported("-pie" LD_SECURITY_FLAGS)
>  endif()
>endif()
> -  add_linker_flag_if_supported(-Wl,-z,relro LD_SECURITY_FLAGS)
> -  add_linker_flag_if_supported(-Wl,-z,now LD_SECURITY_FLAGS)
> -  add_linker_flag_if_supported(-Wl,-z,noexecstack noexecstack_SUPPORTED)
> +  add_linker_flag_if_supported(-Wl,relro LD_SECURITY_FLAGS)
> +  add_linker_flag_if_supported(-Wl,now LD_SECURITY_FLAGS)
> +  add_linker_flag_if_supported(-Wl,noexecstack noexecstack_SUPPORTED)
>if (noexecstack_SUPPORTED)
> -set(LD_SECURITY_FLAGS "${LD_SECURITY_FLAGS} -Wl,-z,noexecstack")
> +set(LD_SECURITY_FLAGS "${LD_SECURITY_FLAGS} -Wl,noexecstack")
>endif()
> -  add_linker_flag_if_supported(-Wl,-z,noexecheap noexecheap_SUPPORTED)
> +  add_linker_flag_if_supported(-Wl,noexecheap noexecheap_SUPPORTED)
>if (noexecheap_SUPPORTED)
> -set(LD_SECURITY_FLAGS "${LD_SECURITY_FLAGS} -Wl,-z,noexecheap")
> +set(LD_SECURITY_FLAGS "${LD_SECURITY_FLAGS} -Wl,noexecheap")
>endif()
>  
>if(BACKCOMPAT)

Re: transmission (+ natpmp?) vs rtable != 0 [was: Re: update: net/transmission 4.0.6]

[Lucas Gabriel Vuotto]

Bump for both.


diff refs/heads/master ca80566646f333620cc5ea11733e8ebaf680ae68
commit - 5a27026115546cbe11607b1197c547e14886732e
commit + ca80566646f333620cc5ea11733e8ebaf680ae68
blob - 43b62e7c1a177a807fa1566b1e12a546b2df3456
blob + 0a87b49cfb749682588085855666b840ea93326e
--- net/miniupnp/libnatpmp/Makefile
+++ net/miniupnp/libnatpmp/Makefile
@@ -1,7 +1,7 @@
 COMMENT =  NAT Port Mapping Protocol client library
 
-DIST_TUPLE =   github miniupnp libnatpmp 
f2433bec24ca3d3f22a8a7840728a3ac177f94ba .
-PKGNAME =  libnatpmp-20240116
+DIST_TUPLE =   github miniupnp libnatpmp 
8257134a5dcb077e40db1946554d676e06e4 .
+PKGNAME =  libnatpmp-20240803
 
 SHARED_LIBS =  natpmp 0.1
 
blob - 43e639c6632fb407227c622954c6c407f7174090
blob + 7ae4db0cd4548ab2814ed0dfeb8d6527e248e9af
--- net/miniupnp/libnatpmp/distinfo
+++ net/miniupnp/libnatpmp/distinfo
@@ -1,2 +1,2 @@
-SHA256 (miniupnp-libnatpmp-f2433bec24ca3d3f22a8a7840728a3ac177f94ba.tar.gz) = 
74SXmVDfs1VnBbY8nNbJVQG3Xoh/ukZiNLGH88kClmk=
-SIZE (miniupnp-libnatpmp-f2433bec24ca3d3f22a8a7840728a3ac177f94ba.tar.gz) = 
28356
+SHA256 (miniupnp-libnatpmp-8257134a5dcb077e40db1946554d676e06e4.tar.gz) = 
HsX5sdi/SOHaDiyCf3TkKMbN9VUnkbun0lUaiSEtDqo=
+SIZE (miniupnp-libnatpmp-8257134a5dcb077e40db1946554d676e06e4.tar.gz) = 
28327
blob - 03eef3d8f6e5b17a81a1760103ac84c74700a809
blob + 984b71f1e7b9e79f6369928f25c08b2c06033c19
--- net/miniupnp/libnatpmp/patches/patch-CMakeLists_txt
+++ net/miniupnp/libnatpmp/patches/patch-CMakeLists_txt
@@ -3,7 +3,7 @@ https://github.com/miniupnp/libnatpmp/pull/39/commits/
 Index: CMakeLists.txt
 --- CMakeLists.txt.orig
 +++ CMakeLists.txt
-@@ -61,7 +61,7 @@ install(TARGETS natpmp natpmpc
+@@ -57,7 +57,7 @@ install(TARGETS natpmp natpmpc
  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
  


diff --git a/net/transmission/Makefile b/net/transmission/Makefile
index 08397883eaf..76ce9054e43 100644
--- a/net/transmission/Makefile
+++ b/net/transmission/Makefile
@@ -2,16 +2,17 @@ COMMENT-main= BitTorrent command line and daemon client
 COMMENT-gtk=   BitTorrent client with GTK+ interface
 COMMENT-qt=BitTorrent client with Qt interface
 
-VER=   4.0.5
+VER=   4.0.6
 DISTNAME=  transmission-${VER}
 PKGNAME-main=  transmission-${VER}
 PKGNAME-gtk=   transmission-gtk-${VER}
 PKGNAME-qt=transmission-qt-${VER}
-REVISION=  0
 CATEGORIES=net
 HOMEPAGE=  https://transmissionbt.com/
 MAINTAINER=Josh Grosse 
 
+DEBUG_PACKAGES=${BUILD_PACKAGES}
+
 # GPLv2+
 PERMIT_PACKAGE=Yes
 
@@ -45,7 +46,7 @@ WANTLIB-qt += Qt6Widgets
 MODULES += devel/cmake \
textproc/intltool
 
-BUILD_DEPENDS-common +=devel/fmt
+BUILD_DEPENDS +=   devel/fmt
 
 LIB_DEPENDS-common +=  archivers/libdeflate \
net/curl \
diff --git a/net/transmission/distinfo b/net/transmission/distinfo
index 644e3f51975..2f5dac89a78 100644
--- a/net/transmission/distinfo
+++ b/net/transmission/distinfo
@@ -1,2 +1,2 @@
-SHA256 (transmission-4.0.5.tar.xz) = 
/Wj/EUpHkgAEPDDH5p26TBky9682ykxbXS7ctYZuY1c=
-SIZE (transmission-4.0.5.tar.xz) = 9745756
+SHA256 (transmission-4.0.6.tar.xz) = 
Kjj+bYojmRaAtpHCd6M1+Idb3sorl8aya1mLycewxF8=
+SIZE (transmission-4.0.6.tar.xz) = 11908296
diff --git a/net/transmission/patches/patch-gtk_Application_cc 
b/net/transmission/patches/patch-gtk_Application_cc
deleted file mode 100644
index 8a6d7516424..000
--- a/net/transmission/patches/patch-gtk_Application_cc
+++ /dev/null
@@ -1,15 +0,0 @@
-deps: bump libfmt to v10.0.0
-fd583ac878806546c3780eab939fdabd9e94c3de
-
-Index: gtk/Application.cc
 gtk/Application.cc.orig
-+++ gtk/Application.cc
-@@ -395,7 +395,7 @@ void register_magnet_link_handler()
- _("Couldn't register Transmission as a {content_type} handler: 
{error} ({error_code})"),
- fmt::arg("content_type", content_type),
- fmt::arg("error", e.what()),
--fmt::arg("error_code", e.code(;
-+fmt::arg("error_code", static_cast(e.code();
- }
- }
- 
diff --git a/net/transmission/patches/patch-gtk_DetailsDialog_cc 
b/net/transmission/patches/patch-gtk_DetailsDialog_cc
deleted file mode 100644
index c906d17f90d..000
--- a/net/transmission/patches/patch-gtk_DetailsDialog_cc
+++ /dev/null
@@ -1,14 +0,0 @@
-fix: missing #include in DetailsDialog.cc
-9b0be18cb5ae4c43c62ffaa6d7304f66332a5505
-
-Index: gtk/DetailsDialog.cc
 gtk/DetailsDialog.cc.orig
-+++ gtk/DetailsDialog.cc
-@@ -68,6 +68,7 @@
- #include 
- #else
- #include 
-+#include 
- #endif
- 
- using namespace std::literals;
diff --git a/net/transmission/patches/patch-libtransmission_file-posix_cc 
b/net/transmission/patches/patch-libtransmission_file-posix_cc
deleted file mode 100644
index 6f876bfcb8f..000
--- a/net/transmission/patches/patch-libtransmission_file-posix_cc
+++ /dev/null
@@ -1,15 +0,0 @@
-deps: bump libfmt to v10.0.0
-fd583ac87

Re: [NEW WIP]: net/monero (help needed)

[Lucas Gabriel Vuotto]

Hey,

I've been working on and off in a port for Monero for quite some time.
Thanks to your's and byteskeptical interest, I got back to it and now I
have a working port attached here.

On Thu, Aug 15, 2024 at 02:47:23PM GMT, David Uhden Collado wrote:
> Dear all,
> 
> I am currently working on creating a port of the Monero CLI wallet for
> OpenBSD, the work I have done so far is attached in this email. This project
> is of personal interest to me, as well as to others who view privacy as an
> essential component of cybersecurity.

First of all, it wasn't super clear to me if you only ported (or
intended to port) monero-wallet-cli. The attached port is for all the
binaries you build from upstream, and in particular monerod.

> I am in the process of learning how to create ports for OpenBSD, which is
> why I have chosen to start with software that seems relatively
> straightforward to port.

Hell no. ^^

> I think this port is complete. However, it is still a work in progress and I
> am hesitant to propose it for inclusion in the ports tree due to the
> following issue:
> 
> When building this software as a non-root user, the following error occurs:
> 
> LLVM ERROR: out of memory
> c++: error: unable to execute command: Abort trap (core dumped)
> 
> This issue is documented in the original project, and the solution is to
> increase the ulimit size to 2 GB:
> 
> ulimit -d 200
> 
> I would like to know if it is possible to resolve this issue within the port
> itself, or if it would be acceptable to add this port to the tree despite
> the problem, perhaps by including a note in the README file.

Didn't deal with this. I run with PORTS_PRIVSEP=Yes and _pbuild runs
with 8GB base in amd64.

> Additionally, while working on this port and reading the documentation, I
> encountered several questions that I had to deduce based on how other
> OpenBSD ports handle them:
> 
> a. The directories pointed to by certain macros in bsd.port.mk, such as
> PREFIX and LOCALSTATEDIR.

SUBST_VARS in bsd.port.mk(5) explains a bit, item 16 of [1] explains how
each directory is used, "make show=VAR" shows the value of VAR.

Having given that piece of information, I don't see a specific question
in your comment.

> b. How to configure a port to create a new user when needed, for instance,
> to run a daemon, as is the case with this port.

Take a look at pkg_create(1) @newuser. That needs to be added to
pkg/PLIST, like done in the attached port.

> These have been the most challenging parts for me, and I find the
> documentation unclear on these points.

It's quite spread over several manpages, so it's a bit confusing /
difficult at times.

> This port has been tested on an amd64 platform. Unfortunately, I do not have
> access to compatible machines with other architectures to conduct further
> testing. If anyone is able to test the port on different platforms, I would
> greatly appreciate it. I am currently using a virtual machine, as the only
> computer I own with sufficient resources to compile this software in a
> reasonable time frame is not compatible with OpenBSD.
> 
> Initially, I considered naming the port net/monero-cli since there is an
> official GUI wallet. However, I decided to leave it as net/monero, as I
> don't think the GUI wallet will be ported in the future due to the
> dependencies that would also need to be ported. If I ever attempt to port a
> GUI wallet, I would try with Feather Wallet, as it seems the most feasible
> option given that it uses QT.

So, properly about David port, it's mostly fine, but

- it's uncommon to have things listed both in RDEPs and BDEPs, and in
  this particular case all of the are actually LDEPs
- you don't need the do-install target, cmake manages it fine
- you don't need gmake
- I ran into a compilation error because hidapi was installed

About byteskeptical port:

- small detail, but REVISION isn't needed for an import
- ONLY_FOR_ARCHS is for things that actually don't build in the other
  arches, not for things not tested in different arches
- upstream tarballs are preferred over GitHub-generated tarballs
- also the RDEPs and BDEPs that should be LDEPs and the do-install
  target
- I run into some compilation error with this one too, but I don't want
  to recompile it yet again. I believe it was a different one than the
  David, but the issue is also present in here: if hidapi is detected
  at configure-time, then the port fails compilation
- the patches for replacing {sprintf,strcat} with {snprintf,strncat} are
  better suited for upstream, which benefits all the users

My tarball does the following:

- adds hidapi and miniupnp deps, as they are automatically picked up and
  there isn't a sensible way to disable them, which means issue for
  bulks (hidapi requires patching a source file)
  - I do have a hardware wallet to try it out, but I haven't managed to
do so yet and is low in my priority list. I don't see much point in
having neither this nor the individual binari

Re: CALL FOR TESTERS databases/luadbi 0.7.3

[Lucas Gabriel Vuotto]

On Sun, Aug 18, 2024 at 04:30:37PM GMT, Lucas Gabriel Vuotto wrote:
> Hello ports,
> 
> Update luadbi to its latest version. Release are short and might be
> useful for people running mariadb:
> 
> - oracle column name bugfix
> - [travis] fix mysql grant error
> - Don't break SQLite 3.6.20 as shipped in RHEL/CentOS 6
> - dbd/mysql/statement.c: fix compilation with mysql-8
> - Issue 56: Remove useless setting of is_null
> - Issue-66: dbd/mysql/statement.c: return nil for NULL
> - Attempt to provide partial fix for Issue #64 (MySQL 8: Error executing
>   statement parameters: Incorrect arguments to mysqld_stmt_execute)
> 
> I don't have a SQL-backed Prosody installation to test this out tho, so
> I only compile-tested the port. op@ does have a SQL-backed Prosody, so
> he's Cc'd :D

Forgot to include a small update to a comment: we already have luarocks,
but the tests also require busted. I think that somebody (gnezdo@?)
sent a port for it at some point; I'll dig the lists later.


diff refs/heads/master ce202dc41dde087b1eec6ef72c241b42490315b5
commit - 960304cb2e8847865e8c776bf9623c82b3698ff5
commit + ce202dc41dde087b1eec6ef72c241b42490315b5
blob - 6088581e2b7e7b781ce638896e02e7330b6967e2
blob + 68564c765062f2c19735706402339cf18c4af53b
--- databases/luadbi/Makefile
+++ databases/luadbi/Makefile
@@ -2,7 +2,7 @@ COMMENT-main=   database interface library for Lua (incl
 COMMENT-mysql= MySQL driver for luadbi
 COMMENT-pgsql= PostgreSQL driver for luadbi
 
-V= 0.7.2
+V= 0.7.3
 GH_ACCOUNT=mwild1
 GH_PROJECT=luadbi
 GH_TAGNAME=v${V}
@@ -42,13 +42,13 @@ RUN_DEPENDS-pgsql=  ${BASE_PKGPATH},-main
 USE_GMAKE= Yes
 ALL_TARGET=free # == sqlite3 mysql postgresql
 INSTALL_TARGET=install_free
-# requires luarocks
+# requires busted
 NO_TEST=   Yes
 
 MAKE_FLAGS=CC="${CC}" \
COMMON_LDFLAGS="-L${LOCALBASE}/lib" \
LUA_INC="-I${MODLUA_INCL_DIR}" \
-   MYSQL_INC="-I${LOCALBASE}/include/mysql" \
+   MYSQL_INC="-I${LOCALBASE}/include" \
SQLITE3_INC="-I${LOCALBASE}/include" \
PSQL_INC="-I${LOCALBASE}/include/postgresql"
 
blob - ac6a043858b03ccad038155bb067981ddd8ab35e
blob + 7bef3f7d3fc3cc453daefdffd389cd8b7097fa52
--- databases/luadbi/distinfo
+++ databases/luadbi/distinfo
@@ -1,2 +1,2 @@
-SHA256 (luadbi-0.7.2.tar.gz) = BafQLQyuOXCvJPcvOe3+cX45Qkkn0H+7wJ6+luoC9aY=
-SIZE (luadbi-0.7.2.tar.gz) = 36462
+SHA256 (luadbi-0.7.3.tar.gz) = g3DD52S2legFEkrVzZWyhfGcsiRuk8AjDc3NiAlrAEs=
+SIZE (luadbi-0.7.3.tar.gz) = 35753

CALL FOR TESTERS databases/luadbi 0.7.3

[Lucas Gabriel Vuotto]

Hello ports,

Update luadbi to its latest version. Release are short and might be
useful for people running mariadb:

- oracle column name bugfix
- [travis] fix mysql grant error
- Don't break SQLite 3.6.20 as shipped in RHEL/CentOS 6
- dbd/mysql/statement.c: fix compilation with mysql-8
- Issue 56: Remove useless setting of is_null
- Issue-66: dbd/mysql/statement.c: return nil for NULL
- Attempt to provide partial fix for Issue #64 (MySQL 8: Error executing
  statement parameters: Incorrect arguments to mysqld_stmt_execute)

I don't have a SQL-backed Prosody installation to test this out tho, so
I only compile-tested the port. op@ does have a SQL-backed Prosody, so
he's Cc'd :D

Lucas


diff refs/heads/master 8126515f9cbee4cb2b8c2e6348c1c0836b89d878
commit - 960304cb2e8847865e8c776bf9623c82b3698ff5
commit + 8126515f9cbee4cb2b8c2e6348c1c0836b89d878
blob - 6088581e2b7e7b781ce638896e02e7330b6967e2
blob + 74b48afa4cd83d3b80fe5645d08e0052078bc032
--- databases/luadbi/Makefile
+++ databases/luadbi/Makefile
@@ -2,7 +2,7 @@ COMMENT-main=   database interface library for Lua (incl
 COMMENT-mysql= MySQL driver for luadbi
 COMMENT-pgsql= PostgreSQL driver for luadbi
 
-V= 0.7.2
+V= 0.7.3
 GH_ACCOUNT=mwild1
 GH_PROJECT=luadbi
 GH_TAGNAME=v${V}
@@ -48,7 +48,7 @@ NO_TEST=  Yes
 MAKE_FLAGS=CC="${CC}" \
COMMON_LDFLAGS="-L${LOCALBASE}/lib" \
LUA_INC="-I${MODLUA_INCL_DIR}" \
-   MYSQL_INC="-I${LOCALBASE}/include/mysql" \
+   MYSQL_INC="-I${LOCALBASE}/include" \
SQLITE3_INC="-I${LOCALBASE}/include" \
PSQL_INC="-I${LOCALBASE}/include/postgresql"
 
blob - ac6a043858b03ccad038155bb067981ddd8ab35e
blob + 7bef3f7d3fc3cc453daefdffd389cd8b7097fa52
--- databases/luadbi/distinfo
+++ databases/luadbi/distinfo
@@ -1,2 +1,2 @@
-SHA256 (luadbi-0.7.2.tar.gz) = BafQLQyuOXCvJPcvOe3+cX45Qkkn0H+7wJ6+luoC9aY=
-SIZE (luadbi-0.7.2.tar.gz) = 36462
+SHA256 (luadbi-0.7.3.tar.gz) = g3DD52S2legFEkrVzZWyhfGcsiRuk8AjDc3NiAlrAEs=
+SIZE (luadbi-0.7.3.tar.gz) = 35753

emulators/snes9x: only build in base-clang arches

[Lucas Gabriel Vuotto]

On Fri, Aug 16, 2024 at 10:20:22PM GMT, k...@openbsd.org wrote:
> Build failures: 82

> http://build-failures.rhaalovely.net/sparc64/2024-08-14/emulators/snes9x.log

People agree that attempting to build and run snes9x in sparc64 is
pointless and wasteful. Only build in arches supported by base-clang.
Thanks sthen and tb for explanations and solution.

Lucas


diff refs/heads/master 4d2915709bdf2ba9fcca618cc7ddffd3e9470fdd
commit - bf83282067cc3c3a3f9968156b0b9b597ebd73c2
commit + 4d2915709bdf2ba9fcca618cc7ddffd3e9470fdd
blob - 2186e3b056142c97b59fa8d7419055e1d6eb1e4d
blob + a7c60474cd0054391ee59ea54375d222d29aca92
--- emulators/snes9x/Makefile
+++ emulators/snes9x/Makefile
@@ -5,7 +5,7 @@ BROKEN-hppa =   ICE/failure on filter/hq2x.cpp
 GH_ACCOUNT =   snes9xgit
 GH_PROJECT =   snes9x
 GH_TAGNAME =   1.63
-REVISION = 0
+REVISION = 1
 
 CATEGORIES =   emulators games
 
@@ -42,7 +42,7 @@ MODULES +=devel/cmake \
textproc/intltool
 
 # C++17
-COMPILER = base-clang ports-gcc
+COMPILER = base-clang
 
 CONFIGURE_ARGS +=  -DCMAKE_INSTALL_PREFIX="${PREFIX}" \
-DCMAKE_INSTALL_DATAROOTDIR="share" \

Re: transmission (+ natpmp?) vs rtable != 0 [was: Re: update: net/transmission 4.0.6]

[Lucas Gabriel Vuotto]

Bump for both.


diff refs/heads/master ca80566646f333620cc5ea11733e8ebaf680ae68
commit - 5a27026115546cbe11607b1197c547e14886732e
commit + ca80566646f333620cc5ea11733e8ebaf680ae68
blob - 43b62e7c1a177a807fa1566b1e12a546b2df3456
blob + 0a87b49cfb749682588085855666b840ea93326e
--- net/miniupnp/libnatpmp/Makefile
+++ net/miniupnp/libnatpmp/Makefile
@@ -1,7 +1,7 @@
 COMMENT =  NAT Port Mapping Protocol client library
 
-DIST_TUPLE =   github miniupnp libnatpmp 
f2433bec24ca3d3f22a8a7840728a3ac177f94ba .
-PKGNAME =  libnatpmp-20240116
+DIST_TUPLE =   github miniupnp libnatpmp 
8257134a5dcb077e40db1946554d676e06e4 .
+PKGNAME =  libnatpmp-20240803
 
 SHARED_LIBS =  natpmp 0.1
 
blob - 43e639c6632fb407227c622954c6c407f7174090
blob + 7ae4db0cd4548ab2814ed0dfeb8d6527e248e9af
--- net/miniupnp/libnatpmp/distinfo
+++ net/miniupnp/libnatpmp/distinfo
@@ -1,2 +1,2 @@
-SHA256 (miniupnp-libnatpmp-f2433bec24ca3d3f22a8a7840728a3ac177f94ba.tar.gz) = 
74SXmVDfs1VnBbY8nNbJVQG3Xoh/ukZiNLGH88kClmk=
-SIZE (miniupnp-libnatpmp-f2433bec24ca3d3f22a8a7840728a3ac177f94ba.tar.gz) = 
28356
+SHA256 (miniupnp-libnatpmp-8257134a5dcb077e40db1946554d676e06e4.tar.gz) = 
HsX5sdi/SOHaDiyCf3TkKMbN9VUnkbun0lUaiSEtDqo=
+SIZE (miniupnp-libnatpmp-8257134a5dcb077e40db1946554d676e06e4.tar.gz) = 
28327
blob - 03eef3d8f6e5b17a81a1760103ac84c74700a809
blob + 984b71f1e7b9e79f6369928f25c08b2c06033c19
--- net/miniupnp/libnatpmp/patches/patch-CMakeLists_txt
+++ net/miniupnp/libnatpmp/patches/patch-CMakeLists_txt
@@ -3,7 +3,7 @@ https://github.com/miniupnp/libnatpmp/pull/39/commits/
 Index: CMakeLists.txt
 --- CMakeLists.txt.orig
 +++ CMakeLists.txt
-@@ -61,7 +61,7 @@ install(TARGETS natpmp natpmpc
+@@ -57,7 +57,7 @@ install(TARGETS natpmp natpmpc
  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
  


diff --git a/net/transmission/Makefile b/net/transmission/Makefile
index 08397883eaf..76ce9054e43 100644
--- a/net/transmission/Makefile
+++ b/net/transmission/Makefile
@@ -2,16 +2,17 @@ COMMENT-main= BitTorrent command line and daemon client
 COMMENT-gtk=   BitTorrent client with GTK+ interface
 COMMENT-qt=BitTorrent client with Qt interface
 
-VER=   4.0.5
+VER=   4.0.6
 DISTNAME=  transmission-${VER}
 PKGNAME-main=  transmission-${VER}
 PKGNAME-gtk=   transmission-gtk-${VER}
 PKGNAME-qt=transmission-qt-${VER}
-REVISION=  0
 CATEGORIES=net
 HOMEPAGE=  https://transmissionbt.com/
 MAINTAINER=Josh Grosse 
 
+DEBUG_PACKAGES=${BUILD_PACKAGES}
+
 # GPLv2+
 PERMIT_PACKAGE=Yes
 
@@ -45,7 +46,7 @@ WANTLIB-qt += Qt6Widgets
 MODULES += devel/cmake \
textproc/intltool
 
-BUILD_DEPENDS-common +=devel/fmt
+BUILD_DEPENDS +=   devel/fmt
 
 LIB_DEPENDS-common +=  archivers/libdeflate \
net/curl \
diff --git a/net/transmission/distinfo b/net/transmission/distinfo
index 644e3f51975..2f5dac89a78 100644
--- a/net/transmission/distinfo
+++ b/net/transmission/distinfo
@@ -1,2 +1,2 @@
-SHA256 (transmission-4.0.5.tar.xz) = 
/Wj/EUpHkgAEPDDH5p26TBky9682ykxbXS7ctYZuY1c=
-SIZE (transmission-4.0.5.tar.xz) = 9745756
+SHA256 (transmission-4.0.6.tar.xz) = 
Kjj+bYojmRaAtpHCd6M1+Idb3sorl8aya1mLycewxF8=
+SIZE (transmission-4.0.6.tar.xz) = 11908296
diff --git a/net/transmission/patches/patch-gtk_Application_cc 
b/net/transmission/patches/patch-gtk_Application_cc
deleted file mode 100644
index 8a6d7516424..000
--- a/net/transmission/patches/patch-gtk_Application_cc
+++ /dev/null
@@ -1,15 +0,0 @@
-deps: bump libfmt to v10.0.0
-fd583ac878806546c3780eab939fdabd9e94c3de
-
-Index: gtk/Application.cc
 gtk/Application.cc.orig
-+++ gtk/Application.cc
-@@ -395,7 +395,7 @@ void register_magnet_link_handler()
- _("Couldn't register Transmission as a {content_type} handler: 
{error} ({error_code})"),
- fmt::arg("content_type", content_type),
- fmt::arg("error", e.what()),
--fmt::arg("error_code", e.code(;
-+fmt::arg("error_code", static_cast(e.code();
- }
- }
- 
diff --git a/net/transmission/patches/patch-gtk_DetailsDialog_cc 
b/net/transmission/patches/patch-gtk_DetailsDialog_cc
deleted file mode 100644
index c906d17f90d..000
--- a/net/transmission/patches/patch-gtk_DetailsDialog_cc
+++ /dev/null
@@ -1,14 +0,0 @@
-fix: missing #include in DetailsDialog.cc
-9b0be18cb5ae4c43c62ffaa6d7304f66332a5505
-
-Index: gtk/DetailsDialog.cc
 gtk/DetailsDialog.cc.orig
-+++ gtk/DetailsDialog.cc
-@@ -68,6 +68,7 @@
- #include 
- #else
- #include 
-+#include 
- #endif
- 
- using namespace std::literals;
diff --git a/net/transmission/patches/patch-libtransmission_file-posix_cc 
b/net/transmission/patches/patch-libtransmission_file-posix_cc
deleted file mode 100644
index 6f876bfcb8f..000
--- a/net/transmission/patches/patch-libtransmission_file-posix_cc
+++ /dev/null
@@ -1,15 +0,0 @@
-deps: bump libfmt to v10.0.0
-fd583ac87

Re: transmission (+ natpmp?) vs rtable != 0 [was: Re: update: net/transmission 4.0.6]

[Lucas Gabriel Vuotto]

Bump for both.

On Sun, Aug 04, 2024 at 10:17:06AM GMT, Josh Grosse wrote:
> On Sat, Aug 03, 2024 at 11:37:29PM +0000, Lucas Gabriel Vuotto wrote:
> > The PR to upstream got merged, so here is an update for libnatpmp to
> > the latest commit. There is a single non-merge commit [0] inbetween,
> > which is to remove some explicit setting in CMake that became the
> > default when they bumped the minimum version to 3.5.
> > 
> > Lucas
> 
> I've tested this with the updated transmission 4.0.6; the rtable issue
> has been resolved.  Below is Lucas's diff, but with an update-patches
> revision added, followed by the diff for net/transmission that was posted in 
> June and again in July. Please consider this another "ping."  

Thanks for the "make update-patches" btw.

Lucas


diff refs/heads/master ca80566646f333620cc5ea11733e8ebaf680ae68
commit - 5a27026115546cbe11607b1197c547e14886732e
commit + ca80566646f333620cc5ea11733e8ebaf680ae68
blob - 43b62e7c1a177a807fa1566b1e12a546b2df3456
blob + 0a87b49cfb749682588085855666b840ea93326e
--- net/miniupnp/libnatpmp/Makefile
+++ net/miniupnp/libnatpmp/Makefile
@@ -1,7 +1,7 @@
 COMMENT =  NAT Port Mapping Protocol client library
 
-DIST_TUPLE =   github miniupnp libnatpmp 
f2433bec24ca3d3f22a8a7840728a3ac177f94ba .
-PKGNAME =  libnatpmp-20240116
+DIST_TUPLE =   github miniupnp libnatpmp 
8257134a5dcb077e40db1946554d676e06e4 .
+PKGNAME =  libnatpmp-20240803
 
 SHARED_LIBS =  natpmp 0.1
 
blob - 43e639c6632fb407227c622954c6c407f7174090
blob + 7ae4db0cd4548ab2814ed0dfeb8d6527e248e9af
--- net/miniupnp/libnatpmp/distinfo
+++ net/miniupnp/libnatpmp/distinfo
@@ -1,2 +1,2 @@
-SHA256 (miniupnp-libnatpmp-f2433bec24ca3d3f22a8a7840728a3ac177f94ba.tar.gz) = 
74SXmVDfs1VnBbY8nNbJVQG3Xoh/ukZiNLGH88kClmk=
-SIZE (miniupnp-libnatpmp-f2433bec24ca3d3f22a8a7840728a3ac177f94ba.tar.gz) = 
28356
+SHA256 (miniupnp-libnatpmp-8257134a5dcb077e40db1946554d676e06e4.tar.gz) = 
HsX5sdi/SOHaDiyCf3TkKMbN9VUnkbun0lUaiSEtDqo=
+SIZE (miniupnp-libnatpmp-8257134a5dcb077e40db1946554d676e06e4.tar.gz) = 
28327
blob - 03eef3d8f6e5b17a81a1760103ac84c74700a809
blob + 984b71f1e7b9e79f6369928f25c08b2c06033c19
--- net/miniupnp/libnatpmp/patches/patch-CMakeLists_txt
+++ net/miniupnp/libnatpmp/patches/patch-CMakeLists_txt
@@ -3,7 +3,7 @@ https://github.com/miniupnp/libnatpmp/pull/39/commits/
 Index: CMakeLists.txt
 --- CMakeLists.txt.orig
 +++ CMakeLists.txt
-@@ -61,7 +61,7 @@ install(TARGETS natpmp natpmpc
+@@ -57,7 +57,7 @@ install(TARGETS natpmp natpmpc
  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
  

 8< 


diff --git a/net/transmission/Makefile b/net/transmission/Makefile
index 08397883eaf..76ce9054e43 100644
--- a/net/transmission/Makefile
+++ b/net/transmission/Makefile
@@ -2,16 +2,17 @@ COMMENT-main= BitTorrent command line and daemon client
 COMMENT-gtk=   BitTorrent client with GTK+ interface
 COMMENT-qt=BitTorrent client with Qt interface
 
-VER=   4.0.5
+VER=   4.0.6
 DISTNAME=  transmission-${VER}
 PKGNAME-main=  transmission-${VER}
 PKGNAME-gtk=   transmission-gtk-${VER}
 PKGNAME-qt=transmission-qt-${VER}
-REVISION=  0
 CATEGORIES=net
 HOMEPAGE=  https://transmissionbt.com/
 MAINTAINER=Josh Grosse 
 
+DEBUG_PACKAGES=${BUILD_PACKAGES}
+
 # GPLv2+
 PERMIT_PACKAGE=Yes
 
@@ -45,7 +46,7 @@ WANTLIB-qt += Qt6Widgets
 MODULES += devel/cmake \
textproc/intltool
 
-BUILD_DEPENDS-common +=devel/fmt
+BUILD_DEPENDS +=   devel/fmt
 
 LIB_DEPENDS-common +=  archivers/libdeflate \
net/curl \
diff --git a/net/transmission/distinfo b/net/transmission/distinfo
index 644e3f51975..2f5dac89a78 100644
--- a/net/transmission/distinfo
+++ b/net/transmission/distinfo
@@ -1,2 +1,2 @@
-SHA256 (transmission-4.0.5.tar.xz) = 
/Wj/EUpHkgAEPDDH5p26TBky9682ykxbXS7ctYZuY1c=
-SIZE (transmission-4.0.5.tar.xz) = 9745756
+SHA256 (transmission-4.0.6.tar.xz) = 
Kjj+bYojmRaAtpHCd6M1+Idb3sorl8aya1mLycewxF8=
+SIZE (transmission-4.0.6.tar.xz) = 11908296
diff --git a/net/transmission/patches/patch-gtk_Application_cc 
b/net/transmission/patches/patch-gtk_Application_cc
deleted file mode 100644
index 8a6d7516424..000
--- a/net/transmission/patches/patch-gtk_Application_cc
+++ /dev/null
@@ -1,15 +0,0 @@
-deps: bump libfmt to v10.0.0
-fd583ac878806546c3780eab939fdabd9e94c3de
-
-Index: gtk/Application.cc
 gtk/Application.cc.orig
-+++ gtk/Application.cc
-@@ -395,7 +395,7 @@ void register_magnet_link_handler()
- _("Couldn't register Transmission as a {content_type} handler: 
{error} ({error_code})"),
- fmt::arg("content_type", content_type),
- fmt::arg("error", e.what()),
--fmt::arg("error_code", e.code(;
-+fmt::arg("e

Re: transmission (+ natpmp?) vs rtable != 0 [was: Re: update: net/transmission 4.0.6]

[Lucas Gabriel Vuotto]

The PR to upstream got merged, so here is an update for libnatpmp to
the latest commit. There is a single non-merge commit [0] inbetween,
which is to remove some explicit setting in CMake that became the
default when they bumped the minimum version to 3.5.

Lucas

[0]: 
https://github.com/miniupnp/libnatpmp/commit/e8657b5bce063f5a4c2f617b825234dc751f1196


diff 5a27026115546cbe11607b1197c547e14886732e 
e728cbaf6f674ca90f20bd84543ed49f4651c6c1
commit - 5a27026115546cbe11607b1197c547e14886732e
commit + e728cbaf6f674ca90f20bd84543ed49f4651c6c1
blob - 43b62e7c1a177a807fa1566b1e12a546b2df3456
blob + 0a87b49cfb749682588085855666b840ea93326e
--- net/miniupnp/libnatpmp/Makefile
+++ net/miniupnp/libnatpmp/Makefile
@@ -1,7 +1,7 @@
 COMMENT =  NAT Port Mapping Protocol client library
 
-DIST_TUPLE =   github miniupnp libnatpmp 
f2433bec24ca3d3f22a8a7840728a3ac177f94ba .
-PKGNAME =  libnatpmp-20240116
+DIST_TUPLE =   github miniupnp libnatpmp 
8257134a5dcb077e40db1946554d676e06e4 .
+PKGNAME =  libnatpmp-20240803
 
 SHARED_LIBS =  natpmp 0.1
 
blob - 43e639c6632fb407227c622954c6c407f7174090
blob + 7ae4db0cd4548ab2814ed0dfeb8d6527e248e9af
--- net/miniupnp/libnatpmp/distinfo
+++ net/miniupnp/libnatpmp/distinfo
@@ -1,2 +1,2 @@
-SHA256 (miniupnp-libnatpmp-f2433bec24ca3d3f22a8a7840728a3ac177f94ba.tar.gz) = 
74SXmVDfs1VnBbY8nNbJVQG3Xoh/ukZiNLGH88kClmk=
-SIZE (miniupnp-libnatpmp-f2433bec24ca3d3f22a8a7840728a3ac177f94ba.tar.gz) = 
28356
+SHA256 (miniupnp-libnatpmp-8257134a5dcb077e40db1946554d676e06e4.tar.gz) = 
HsX5sdi/SOHaDiyCf3TkKMbN9VUnkbun0lUaiSEtDqo=
+SIZE (miniupnp-libnatpmp-8257134a5dcb077e40db1946554d676e06e4.tar.gz) = 
28327

Re: transmission (+ natpmp?) vs rtable != 0 [was: Re: update: net/transmission 4.0.6]

[Lucas Gabriel Vuotto]

On Fri, Aug 02, 2024 at 05:50:20PM GMT, Stuart Henderson wrote:
> Does that match with when I updated libnatpmp? Or is that a bit earlier.

No, that's too early. I've been running it in rtable 2 since 2023 and I
now know for certain that it happened for me after I read this thread
https://marc.info/?l=openbsd-ports&m=171474289512484&w=2 from May 3.

> LGTM, would you mind doing a PR upstream please?
> https://github.com/miniupnp/libnatpmp/pulls

Yes, that was my plan. I wanted a confirmation first, which I got now :)

Re: transmission (+ natpmp?) vs rtable != 0 [was: Re: update: net/transmission 4.0.6]

[Lucas Gabriel Vuotto]

On Fri, Aug 02, 2024 at 01:25:24PM GMT, Lucas Gabriel Vuotto wrote:
> On Mon, Jul 08, 2024 at 10:48:37AM GMT, Josh Grosse wrote:
> > Ping.  This is a bugfix release. Tested on amd64.  -daemon still
> > has a non-zero rtable issue reported with 4.0.5.
> 
> So, given I was a victim of the rtable issue, I took another attempt at
> it.
> 
> Josh, do you see the issue if you run transmission-daemon with
> "port-forwarding-enabled" set to false? Can be achieve running it -M,
> which will also write it to the config. In my setup, it gets stuck when
> port forwarding is enabled and it runs in an rtable other than 0. I've
> been running with it disable for 2 days without issues is rtable 2.
> 
> btw, decided to attempt that after rereading your debug attempts in
> Reddit. I believe that you keep looking at the loop in curlThreadFunc
> because that's the way that thread works, while taking a look at another
> thread showed it was attempting a read that came from natpmp.
> 
> iirc, I started experiencing it around mid-May, while the reddit post is
> from mid-April. transmission-daemon runs in a machine that runs -current
> and is updated on a weekly basis.
> 
>   Lucas

The following patch to net/miniupnp/libnatpmp makes transmission-daemon
work in a non-zero rtable with port-forwarding-enabled set to true.

I quickly tried natpmpc and indeed this looks like needed:

without patch:

$ natpmpc
initnatpmp() returned 0 (SUCCESS)
using gateway : 172.31.0.147
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
  errno=61 'Connection refused'
$ timeout 10 route -T1 exec natpmpc
$ timeout 10 route -T2 exec natpmpc 

with patch:

$ natpmpc   

  
initnatpmp() returned 0 (SUCCESS)
using gateway : 172.31.0.227
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
  errno=61 'Connection refused'
$ route -T1 exec natpmpc 
initnatpmp() returned 0 (SUCCESS)
using gateway : 192.168.100.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
  errno=61 'Connection refused'
$ route -T2 exec natpmpc  
initnatpmp() returned 0 (SUCCESS)
using gateway : 172.31.1.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
  errno=61 'Connection refused'

The only thing that doesn't make sense is why is this started being
noticeable somewhere around April / May. I'm pretty sure I started
experiencing roughly a month after I saw Josh comment about it.
net/rtsock.c, net/route.[ch] and net/rtable.[ch] changes seem inocuous
around those dates. netinet/if_mroute.c shows some change but I think
that code path isn't reachable thru libnatpmp.


diff 0d344cb42a7eca64820d544cfcf71f41eb47b835 
1434c3b0051be5d20df5fc2c707b8160665148ca
commit - 0d344cb42a7eca64820d544cfcf71f41eb47b835
commit + 1434c3b0051be5d20df5fc2c707b8160665148ca
blob - 43b62e7c1a177a807fa1566b1e12a546b2df3456
blob + 074bf4f845cb794f6c2e239d9c785ba10541f881
--- net/miniupnp/libnatpmp/Makefile
+++ net/miniupnp/libnatpmp/Makefile
@@ -2,6 +2,7 @@ COMMENT =   NAT Port Mapping Protocol client library
 
 DIST_TUPLE =   github miniupnp libnatpmp 
f2433bec24ca3d3f22a8a7840728a3ac177f94ba .
 PKGNAME =  libnatpmp-20240116
+REVISION = 0
 
 SHARED_LIBS =  natpmp 0.1
 
blob - /dev/null
blob + 44666d262d9e571b1009c4ed8ae8ebb4a72d761d (mode 644)
--- /dev/null
+++ net/miniupnp/libnatpmp/patches/patch-getgateway_c
@@ -0,0 +1,16 @@
+Handle non-zero rtables.
+
+Index: getgateway.c
+--- getgateway.c.orig
 getgateway.c
+@@ -269,6 +269,10 @@ int getdefaultgateway(in_addr_t *addr)
+   rtm.rtm_seq = ++seq;
+   rtm.rtm_addrs = rtm_addrs;
+ 
++#ifdef __OpenBSD__
++  rtm.rtm_tableid = getrtable();
++#endif
++
+   so_dst.sa_family = AF_INET;
+   so_dst.sa_len = sizeof(struct sockaddr);
+   so_mask.sa_family = AF_INET;

transmission (+ natpmp?) vs rtable != 0 [was: Re: update: net/transmission 4.0.6]

[Lucas Gabriel Vuotto]

On Mon, Jul 08, 2024 at 10:48:37AM GMT, Josh Grosse wrote:
> Ping.  This is a bugfix release. Tested on amd64.  -daemon still
> has a non-zero rtable issue reported with 4.0.5.

So, given I was a victim of the rtable issue, I took another attempt at
it.

Josh, do you see the issue if you run transmission-daemon with
"port-forwarding-enabled" set to false? Can be achieve running it -M,
which will also write it to the config. In my setup, it gets stuck when
port forwarding is enabled and it runs in an rtable other than 0. I've
been running with it disable for 2 days without issues is rtable 2.

btw, decided to attempt that after rereading your debug attempts in
Reddit. I believe that you keep looking at the loop in curlThreadFunc
because that's the way that thread works, while taking a look at another
thread showed it was attempting a read that came from natpmp.

iirc, I started experiencing it around mid-May, while the reddit post is
from mid-April. transmission-daemon runs in a machine that runs -current
and is updated on a weekly basis.

Lucas

Re: UPDATE: FFmpeg 4.4.5

[Lucas Gabriel Vuotto]

On Wed, Jul 31, 2024 at 12:05:36AM GMT, José Maldonado wrote:
> Hi Brad! Two questions you might be able to answer:
> 
> What downstream projects haven't switched to at least ffmpeg 6 yet?
> 
> What OpenBSD projects do we have that depend on ffmpeg?

# pkg_add sqlports
$ show-reverse-deps graphics/ffmpeg

Then you can check the downstream yourself. Take into consideration
that ffmpeg might not be the only thing blocking the update of a
downstream.

Re: UPDATE databases/victoriametrics 1.102.0 from MAINTAINER

[Lucas Gabriel Vuotto]

Bump

On Thu, Jul 25, 2024 at 12:16:00AM GMT, Lucas Gabriel Vuotto wrote:
> Hello ports@,
> 
> 
> Find an update for VictoriaMetrics. It includes a breaking change that
> caught me by surprise, because the releases notes for a non-rc version
> don't include the accumulated changes of the rc versions, so I'll write
> all the "update notes" here clearly, at the bottom of the message. Full
> release notes can be found at [1], [2] and [3].
> 
> Portswise, the update is straightforward and been running it fine in
> arm64 since Monday.
> 
>   Lucas
> 
> v1.102.0:
> 
> * Update note 1: support for snap packages was removed due to lack of
>   interest from community. See this pull request for details. Please
>   read about supported package types here.
> 
> * Update note 2: stream aggregation config now prevents setting multiple
>   identical outputs. For example, `outputs: [total, total]` will fail
>   the validation phase. In addition, `outputs: ["quantiles(0.5)",
>   "quantiles(0.9)"]` will fail the validation as well - use `outputs:
>   ["quantiles(0.5, 0.9)"]` instead.
> 
> v1.102.0-rc2:
> 
> * Update note 1: the --vm-disable-progress-bar command-line flag at
>   vmctl was deprecated. Use --disable-progress-bar instead.
> 
> * Update note 2: *.passwordFile and similar flags are no longer trimming
>   trailing whitespaces at the end of content. Make sure to update the
>   templating of password files or HTTP endpoints to not include trailing
>   whitespaces before the upgrade. See this[0] PR for the details.
> 
>   [NB: thanks for making me waste a couple of hours wondering why tf my
>   perfectly working, seemingly-not-affected config stopped working. btw
>   it's stupidly common to write a text file with a newline at the end,
>   and ime it's quite uncommon to have automation create things with a
>   newline at the end (especially in YAML), but hey, it doesn't seem to
>   be upstream's experience. Also I invested a good amount of time
>   tracking the change down. *sigh*.]
> 
> v1.102.0-rc1:
> 
> * Update note 1: the -remoteWrite.multitenantURL command-line flag at
>   vmagent was removed starting from this release. This flag was
>   deprecated since v1.96.0. Use -enableMultitenantHandlers instead, as
>   it is easier to use and combine with multitenant URL at vminsert. See
>   these docs for details.
> 
> * Update note 2: the -streamAggr.dropInputLabels command-line flag at
>   vmagent was renamed to -remoteWrite.streamAggr.dropInputLabels.
>   -streamAggr.dropInputLabels is now used for global streaming
>   aggregation.
> 
> * Update note 3: the -maxLabelValueLen command-line flag default value
>   was changed from 16KiB to 4KiB. It may lead to truncating of labels
>   with too long values.
> 
> [0]: https://github.com/VictoriaMetrics/VictoriaMetrics/pull/6503
> [1]: 
> https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v11020-rc1
> [2]: 
> https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v11020-rc2
> [3]: 
> https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v11020


diff 1ea8ce0bcaddb08502e6d1f80e5f2a8f018d7fe2 
481cf146e59ae595050b5edc633260a9a815baf5
commit - 1ea8ce0bcaddb08502e6d1f80e5f2a8f018d7fe2
commit + 481cf146e59ae595050b5edc633260a9a815baf5
blob - 7307b633f04d76955ed3475a5e7138dcd8723b9a
blob + 4c270c7b118d96a4e36cf799230e0ba4495e4328
--- databases/victoriametrics/Makefile
+++ databases/victoriametrics/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  fast, cost-effective and scalable time series database
 
-V =1.101.0
+V =1.102.0
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
blob - 7c823b8d298a419e58bcb796ee6d708b9a76f26b
blob + 1f12d9b527339efc16f3cfc7abb15f284ef4dc3a
--- databases/victoriametrics/distinfo
+++ databases/victoriametrics/distinfo
@@ -1,2 +1,2 @@
-SHA256 (VictoriaMetrics-VictoriaMetrics-v1.101.0.tar.gz) = 
KAe2UH1A1m6OM+RTXVLRtF5foIHrWOMm6LgpBdOqpMk=
-SIZE (VictoriaMetrics-VictoriaMetrics-v1.101.0.tar.gz) = 37191577
+SHA256 (VictoriaMetrics-VictoriaMetrics-v1.102.0.tar.gz) = 
jWg+4iwtTYBkMTGp2F2bFVWdMvvnHdBYjQK+mCWPUik=
+SIZE (VictoriaMetrics-VictoriaMetrics-v1.102.0.tar.gz) = 39679042

Re: UPDATE security/p5-Mojolicious-Plugin-Authentication

[Lucas Gabriel Vuotto]

Bump.

On Wed, Jul 17, 2024 at 08:04:14PM GMT, Lucas Gabriel Vuotto wrote:
> Hi ports@,
> 
> I keep forgetting to send this patch. Back in March 2023 I sent an
> update for www/p5-Mojo [0]. In May 2024, a newer version was commited
> after a bump from wen heping, but that diff missed a fix for the
> breakage of this port. 
> 
> This is the same diff that I sent back in May 2023. It still passes the
> tests, thing that currently doesn't happen (they hang). I'm not an user
> of the port btw, it's only something that came up when I was testing
> the Mojo update.
> 
>   Lucas
> 
> [0]: https://marc.info/?l=openbsd-ports&m=167871488231807&w=2
> 
> Relavant part of that email:
> 
> > - security/p5-Mojolicious-Plugin-Authentication: tests fail. Currently
> >   at 1.37; release 1.38 includes the following in the release notes:
> >   "Fixed an issue that made the test suite fail with Mojolicious 9.25."
> >   So, I made a small patch for 1.39 and tests passed. The diff is
> >   included, as no other ports depends on it.


diff /usr/ports
commit - 7304a451eb2ac7f3d404daa7f0c1afb24b419b9d
path + /usr/ports
blob - 7c87e4959795c74c3f143eb03f5276a2be527605
file + security/p5-Mojolicious-Plugin-Authentication/Makefile
--- security/p5-Mojolicious-Plugin-Authentication/Makefile
+++ security/p5-Mojolicious-Plugin-Authentication/Makefile
@@ -2,7 +2,7 @@ COMMENT =   authentication plugin for the Mojolicious Pe
 
 MODULES =  cpan
 PKG_ARCH = *
-DISTNAME = Mojolicious-Plugin-Authentication-1.37
+DISTNAME = Mojolicious-Plugin-Authentication-1.39
 CATEGORIES =   security
 
 # Perl
blob - 8632368ef3b2f3d80a0acdef8270fc1a5c623be7
file + security/p5-Mojolicious-Plugin-Authentication/distinfo
--- security/p5-Mojolicious-Plugin-Authentication/distinfo
+++ security/p5-Mojolicious-Plugin-Authentication/distinfo
@@ -1,2 +1,2 @@
-SHA256 (Mojolicious-Plugin-Authentication-1.37.tar.gz) = 
p+0gZyW3s5XU/KEuPx2SPaZE2RMzP/SOojHgZOyxq7Y=
-SIZE (Mojolicious-Plugin-Authentication-1.37.tar.gz) = 27712
+SHA256 (Mojolicious-Plugin-Authentication-1.39.tar.gz) = 
n5nL31ysqj+j+WG+6U3pcibRd6NqFee6MDrnnRModNE=
+SIZE (Mojolicious-Plugin-Authentication-1.39.tar.gz) = 27979

Re: UPDATE: FFmpeg 4.4.5

[Lucas Gabriel Vuotto]

On Mon, Jul 29, 2024 at 03:57:36AM GMT, Brad Smith wrote:
> Here is an update to FFmpeg 4.4.5.

Works for me via mpv. VA-API still works. I guess the default is to do
detection at configure-time and that's why it keeps working despite the
removal of the explicit `--enable-vaapi`?

Lucas

Re: Enable VA-API in graphics/ffmpeg

[Lucas Gabriel Vuotto]

On Mon, Jul 29, 2024 at 01:52:51PM GMT, Jan Stary wrote:
> On Jul 21 18:00:28, lu...@sexy.is wrote:
> > On Sun, Jul 21, 2024 at 01:09:24PM GMT, José Maldonado wrote:
> > > This is rare. In my case, using mpv+yt-dlp for YouTube videos work
> > > fine (using 4.4.4p3 and 4.4.4p5).
> > 
> > This isn't firefox tho, which is were I do experience issues. My
> > ffmpeg+mpv works fine, even mpv+yt-dlp with your YouTube video.
> 
> To be clear: what do you mean by ffmpeg+mpv, as opposed to mpv+ytdlp?
> mpv uses ffmpeg's libavcodec (right?) for software decoding;
> does mpv also use some parts of ffmpeg when hw decoding via vaapi?
> 
> If not, then ffmpeg does not enter into it, right?
> If yes, then it would be the same for mpv+ytdlp (right?),
> as yt-dlp is just a downloader.
> 
> Sorry if I'm missing something obvious.

I wanted to stress that the problem wasn't the video from YouTube, but
Firefox's playback, as José was talking about the YouTube video but with
mpv playing it.

> > >  mpv https://www.youtube.com/watch\?v\=PXFXEGLi3wg
> > >  (+) Video --vid=1 (*) (vp9 1920x1080 59.940fps)
> > >  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
> > >  Subs  --sid=1 --slang=live_chat 'json' (null) (external)
> > > File tags:
> > >  Uploader: Edu Camps
> > >  Channel_URL: https://www.youtube.com/channel/UCV6dTKLL29jPIggEvjIMPzw
> > > [ffmpeg/video] vp9: No support for codec vp9 profile 0.
> > > AO: [sndio] 44100Hz stereo 2ch s16
> > > VO: [gpu] 1920x1080 yuv420p
> > 
> > I don't believe you're doing hardware decoding here. This is how it
> > looks in my machine:
> > 
> >  (+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
> >  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
> >  Subs  --sid=1 --slang=live_chat 'json' (null) (external)
> > File tags:
> >  Uploader: Edu Camps
> >  Channel_URL: https://www.youtube.com/channel/UCV6dTKLL29jPIggEvjIMPzw
> > Using hardware decoding (vaapi).
> > AO: [sndio] 44100Hz stereo 2ch s16
> > VO: [gpu] 3840x2160 vaapi[nv12]
> > 
> > You need both --hwdec=auto in mpv and one of graphics/intel-media-driver
> > or graphics/intel-vaapi-driver for Intel cards, depending on your
> > graphics card. idk what the requirements are for AMD cards.
> 
> There is a difference I see between usimg mpv-0.38.0,
> which didn't use vaapi (right?) and mpv-0.38.0p0, which does.
> (My i965 doesn't do vp9, using h264.)

0.38.0 shouldn't use vaapi, as it used the configure flag
-Dvaapi=disabled. Check the commit history for more details.

> $ mpv /media/Brabec/kytice.mkv
>  (+) Video --vid=1 (*) (h264 1920x1080 23.999fps)
>  (+) Audio --aid=1 --alang=cze (*) (ac3 6ch 48000Hz)
> Using hardware decoding (vaapi-copy).
> AO: [sndio] 48000Hz 5.1(alsa) (5.1) 6ch s16
> VO: [gpu] 1920x1080 nv12
> AV:l00:00:00:/001:23:43:(0%)3A-V:)-0.0180ct:0-0.0650m?25h
> Exiting... (Quit)
> 
> $ mpv /media/Brabec/kytice.mkv
>  (+) Video --vid=1 (*) (h264 1920x1080 23.999fps)
>  (+) Audio --aid=1 --alang=cze (*) (ac3 6ch 48000Hz)
> Using hardware decoding (vaapi).
> AO: [sndio] 48000Hz 5.1(alsa) (5.1) 6ch s16
> VO: [gpu] 1920x1080 vaapi[nv12]
> AV:l00:00:02:/001:23:43:(0%)3A-V:)-0.0010ct:0-0.0820m?25h
> Exiting... (Quit)
> 
> What does the "vaapi-copy" stand for?

manpage.

> It seems the old mpv-0.38.0 (i.e. not -p0)
> was using some kinf of vaapi already;
> does mpv carry its own copy?

Own copy of ffmpeg? No:
https://github.com/mpv-player/mpv?tab=readme-ov-file#compilation .

Re: update: net/transmission 4.0.6

[Lucas Gabriel Vuotto]

On Mon, Jul 08, 2024 at 10:48:37AM GMT, Josh Grosse wrote:
> Ping.  This is a bugfix release. Tested on amd64.  -daemon still
> has a non-zero rtable issue reported with 4.0.5.

Been running it since yesterday. Works for me, but I only tried -daemon.
transmission-remote-gtk also works with it.

emulators/snes9x: fix build on ILP32 arches (was: Re: UPDATE emulators/snes9x 1.63 from MAINTAINER)

[Lucas Gabriel Vuotto]

On Mon, Jul 22, 2024 at 11:27:42AM GMT, Stuart Henderson wrote:
> On 2024/07/09 21:47, Lucas Gabriel Vuotto wrote:
> > Hey ports@,
> > 
> > Freshly out of the oven, here is an update for snes9x to its latest
> > version.
> 
> Build fails on i386, and probably all ILP32 arches.
> 
> /pobj/snes9x-1.63/snes9x-1.63/gtk/src/gtk_display_driver_vulkan.cpp:69:54: 
> error: assigning to
> 'VkDescriptorPool' (aka 'unsigned long long') from incompatible type 
> 'vk::DescriptorPool'
> init_info.DescriptorPool = imgui_descriptor_pool.get();
>~~^
> /pobj/snes9x-1.63/snes9x-1.63/gtk/src/gtk_display_driver_vulkan.cpp:74:5: 
> error: no matching function for call
> to 'ImGui_ImplVulkan_Init'
> ImGui_ImplVulkan_Init(&init_info, 
> context->swapchain->get_render_pass());
> ^ 
> 
> /pobj/snes9x-1.63/snes9x-1.63/gtk/../external/imgui/imgui_impl_vulkan.h:67:29:
>  note: candidate function not
> viable: no known conversion from 'vk::RenderPass' to 'VkRenderPass' (aka 
> 'unsigned long long') for 2ndargument
> IMGUI_IMPL_API bool ImGui_ImplVulkan_Init(ImGui_ImplVulkan_InitInfo* 
> info, VkRenderPass render_pass);
> ^
> 2 errors generated.
> ninja: build stopped: subcommand failed.

Hi Stuart,

This patch makes it build in a vmd-backed i386, meaning that I only
compile-tested it. I do have a macppc laying around and I'll try giving
it a shot in there, but that will take me some more time. amd64 still
builds and runs.

I'm attempting to upstream the patch at [0]. I don't know if I should
reference the PR in the patch message. If that's the case, feel free to
edit it before commiting.

[0]: https://github.com/snes9xgit/snes9x/pull/940

Lucas


diff 776d4c09005a00012fddb385579422d478fecedd 
4c7d93f92c47400c01860a76c61d8ec47c7ba890
commit - 776d4c09005a00012fddb385579422d478fecedd
commit + 4c7d93f92c47400c01860a76c61d8ec47c7ba890
blob - 8deaf932393ae14037dd58cd5102cc6717529fa6
blob + 2186e3b056142c97b59fa8d7419055e1d6eb1e4d
--- emulators/snes9x/Makefile
+++ emulators/snes9x/Makefile
@@ -5,6 +5,7 @@ BROKEN-hppa =   ICE/failure on filter/hq2x.cpp
 GH_ACCOUNT =   snes9xgit
 GH_PROJECT =   snes9x
 GH_TAGNAME =   1.63
+REVISION = 0
 
 CATEGORIES =   emulators games
 
blob - /dev/null
blob + dbc18180095569cba00697094054cf14926d2429 (mode 644)
--- /dev/null
+++ emulators/snes9x/patches/patch-gtk_src_gtk_display_driver_vulkan_cpp
@@ -0,0 +1,21 @@
+Fix build in ILP32. See
+https://github.com/KhronosGroup/Vulkan-Hpp#cc-interop-for-handles for details.
+
+Index: gtk/src/gtk_display_driver_vulkan.cpp
+--- gtk/src/gtk_display_driver_vulkan.cpp.orig
 gtk/src/gtk_display_driver_vulkan.cpp
+@@ -66,12 +66,12 @@ bool S9xVulkanDisplayDriver::init_imgui()
+ init_info.Device = context->device;;
+ init_info.QueueFamily = context->graphics_queue_family_index;
+ init_info.Queue = context->queue;
+-init_info.DescriptorPool = imgui_descriptor_pool.get();
++init_info.DescriptorPool = 
static_cast(imgui_descriptor_pool.get());
+ init_info.Subpass = 0;
+ init_info.MinImageCount = context->swapchain->get_num_frames();
+ init_info.ImageCount = context->swapchain->get_num_frames();
+ init_info.MSAASamples = VK_SAMPLE_COUNT_1_BIT;
+-ImGui_ImplVulkan_Init(&init_info, context->swapchain->get_render_pass());
++ImGui_ImplVulkan_Init(&init_info, 
static_cast(context->swapchain->get_render_pass()));
+ 
+ auto cmd = context->begin_cmd_buffer();
+ ImGui_ImplVulkan_CreateFontsTexture(cmd);

Re: security/pcsc-lite: update to 2.2.3

[Lucas Gabriel Vuotto]

On Sun, Jul 28, 2024 at 12:29:38PM GMT, Klemens Nanni wrote:
> 'make test' passes with my card (reader), qdigidoc4 is still happy.
> 
> Upstream now supports meson, I find that easier to use than autoconf,
> which fails to configure in this version (both 2.69 and 2.71).
> 
> polkit and systemd were always searched and picked up, I fixed that and
> intend to send that patch upstream.
> 
> Doxygen is used if found and has no option, so I neutered it.
> 
> To dlopen() the new pcsclite_real lib with our correct .so version,
> I pass it via CFLAGS instead of SUBST_CMD'ing LIB..._VERSION in our
> patch.
> 
> Tests? Feedack? OK?

I tried it with gpg and my Nitrokey, and it still works:

$ gpg --card-status   
Reader ...: Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00
Application ID ...: REDACTED
Application type .: OpenPGP
Version ..: 3.4
Manufacturer .: Nitrokey
[...]

Under certain circumstances it coredumps at exit, but I don't get a
core file, not even with kern.nosuidcoredump=2. Nevertheless, the
coredump and lack of core file also happen with current version, so I
don't believe it's a show stopper. Pointers on how to get the corefile
are welcome, I can reproduce it quite easily.

No opinion about switching to meson.

UPDATE databases/victoriametrics 1.102.0 from MAINTAINER

[Lucas Gabriel Vuotto]

Hello ports@,


Find an update for VictoriaMetrics. It includes a breaking change that
caught me by surprise, because the releases notes for a non-rc version
don't include the accumulated changes of the rc versions, so I'll write
all the "update notes" here clearly, at the bottom of the message. Full
release notes can be found at [1], [2] and [3].

Portswise, the update is straightforward and been running it fine in
arm64 since Monday.

Lucas

v1.102.0:

* Update note 1: support for snap packages was removed due to lack of
  interest from community. See this pull request for details. Please
  read about supported package types here.

* Update note 2: stream aggregation config now prevents setting multiple
  identical outputs. For example, `outputs: [total, total]` will fail
  the validation phase. In addition, `outputs: ["quantiles(0.5)",
  "quantiles(0.9)"]` will fail the validation as well - use `outputs:
  ["quantiles(0.5, 0.9)"]` instead.

v1.102.0-rc2:

* Update note 1: the --vm-disable-progress-bar command-line flag at
  vmctl was deprecated. Use --disable-progress-bar instead.

* Update note 2: *.passwordFile and similar flags are no longer trimming
  trailing whitespaces at the end of content. Make sure to update the
  templating of password files or HTTP endpoints to not include trailing
  whitespaces before the upgrade. See this[0] PR for the details.

  [NB: thanks for making me waste a couple of hours wondering why tf my
  perfectly working, seemingly-not-affected config stopped working. btw
  it's stupidly common to write a text file with a newline at the end,
  and ime it's quite uncommon to have automation create things with a
  newline at the end (especially in YAML), but hey, it doesn't seem to
  be upstream's experience. Also I invested a good amount of time
  tracking the change down. *sigh*.]

v1.102.0-rc1:

* Update note 1: the -remoteWrite.multitenantURL command-line flag at
  vmagent was removed starting from this release. This flag was
  deprecated since v1.96.0. Use -enableMultitenantHandlers instead, as
  it is easier to use and combine with multitenant URL at vminsert. See
  these docs for details.

* Update note 2: the -streamAggr.dropInputLabels command-line flag at
  vmagent was renamed to -remoteWrite.streamAggr.dropInputLabels.
  -streamAggr.dropInputLabels is now used for global streaming
  aggregation.

* Update note 3: the -maxLabelValueLen command-line flag default value
  was changed from 16KiB to 4KiB. It may lead to truncating of labels
  with too long values.

[0]: https://github.com/VictoriaMetrics/VictoriaMetrics/pull/6503
[1]: 
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v11020-rc1
[2]: 
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v11020-rc2
[3]: 
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v11020


diff 1ea8ce0bcaddb08502e6d1f80e5f2a8f018d7fe2 
481cf146e59ae595050b5edc633260a9a815baf5
commit - 1ea8ce0bcaddb08502e6d1f80e5f2a8f018d7fe2
commit + 481cf146e59ae595050b5edc633260a9a815baf5
blob - 7307b633f04d76955ed3475a5e7138dcd8723b9a
blob + 4c270c7b118d96a4e36cf799230e0ba4495e4328
--- databases/victoriametrics/Makefile
+++ databases/victoriametrics/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  fast, cost-effective and scalable time series database
 
-V =1.101.0
+V =1.102.0
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
blob - 7c823b8d298a419e58bcb796ee6d708b9a76f26b
blob + 1f12d9b527339efc16f3cfc7abb15f284ef4dc3a
--- databases/victoriametrics/distinfo
+++ databases/victoriametrics/distinfo
@@ -1,2 +1,2 @@
-SHA256 (VictoriaMetrics-VictoriaMetrics-v1.101.0.tar.gz) = 
KAe2UH1A1m6OM+RTXVLRtF5foIHrWOMm6LgpBdOqpMk=
-SIZE (VictoriaMetrics-VictoriaMetrics-v1.101.0.tar.gz) = 37191577
+SHA256 (VictoriaMetrics-VictoriaMetrics-v1.102.0.tar.gz) = 
jWg+4iwtTYBkMTGp2F2bFVWdMvvnHdBYjQK+mCWPUik=
+SIZE (VictoriaMetrics-VictoriaMetrics-v1.102.0.tar.gz) = 39679042

Re: Enable VA-API in graphics/ffmpeg

[Lucas Gabriel Vuotto]

On Sun, Jul 21, 2024 at 01:09:24PM GMT, José Maldonado wrote:
> This is rare. In my case, using mpv+yt-dlp for YouTube videos work
> fine (using 4.4.4p3 and 4.4.4p5).

This isn't firefox tho, which is were I do experience issues. My
ffmpeg+mpv works fine, even mpv+yt-dlp with your YouTube video.
ffmpeg+firefox doesn't.

> Log:
> 
>  mpv https://www.youtube.com/watch\?v\=PXFXEGLi3wg
>  (+) Video --vid=1 (*) (vp9 1920x1080 59.940fps)
>  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
>  Subs  --sid=1 --slang=live_chat 'json' (null) (external)
> File tags:
>  Uploader: Edu Camps
>  Channel_URL: https://www.youtube.com/channel/UCV6dTKLL29jPIggEvjIMPzw
> [ffmpeg/video] vp9: No support for codec vp9 profile 0.
> AO: [sndio] 44100Hz stereo 2ch s16
> VO: [gpu] 1920x1080 yuv420p

I don't believe you're doing hardware decoding here. This is how it
looks in my machine:

 (+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
 Subs  --sid=1 --slang=live_chat 'json' (null) (external)
File tags:
 Uploader: Edu Camps
 Channel_URL: https://www.youtube.com/channel/UCV6dTKLL29jPIggEvjIMPzw
Using hardware decoding (vaapi).
AO: [sndio] 44100Hz stereo 2ch s16
VO: [gpu] 3840x2160 vaapi[nv12]

You need both --hwdec=auto in mpv and one of graphics/intel-media-driver
or graphics/intel-vaapi-driver for Intel cards, depending on your
graphics card. idk what the requirements are for AMD cards.

Re: Enable VA-API in graphics/ffmpeg

[Lucas Gabriel Vuotto]

On Sat, Jul 20, 2024 at 11:32:29AM GMT, Rafael Sadowski wrote:
> OK to enable VA-API? It only depends on xenocara libva. Since libva
> builds on almost all arches, I see no reason to restrict it by CPU
> architectures any further.

This worked well with mpv but is giving me issues in Firefox:

- Invidious instances (YouTube alternative frontend) give me "No
  compatible source was found for this media"
- Twitch gives a similar message
- Couldn't test in YouTube because it thinks I'm a bot
- Some meme pages show webms just fine

In any case, disabling hardware media decoding didn't help. Rolling back
to 4.4.4p3 (that's what's in cdn.openbsd.org) makes the issues go away.
I can try with 4.4.4p4 too (adds --disable-vaapi), if it's needed.

Lucas

Re: Enable VA-API in multimedia/mpv

[Lucas Gabriel Vuotto]

On Sat, Jul 20, 2024 at 11:40:24AM GMT, Rafael Sadowski wrote:
> Tested by many, OK to enable VA-API support in mpv?

Works with both of

inteldrm0: msi, TIGERLAKE, gen 12
inteldrm0: msi, ALDERLAKE_P, gen 12

CPU usage stays consistently under 5% in `systat cpu`. With --hwdec=no
it fluctuates between 10%-15%.

Lucas

UPDATE security/p5-Mojolicious-Plugin-Authentication

[Lucas Gabriel Vuotto]

Hi ports@,

I keep forgetting to send this patch. Back in March 2023 I sent an
update for www/p5-Mojo [0]. In May 2024, a newer version was commited
after a bump from wen heping, but that diff missed a fix for the
breakage of this port. 

This is the same diff that I sent back in May 2023. It still passes the
tests, thing that currently doesn't happen (they hang). I'm not an user
of the port btw, it's only something that came up when I was testing
the Mojo update.

Lucas

[0]: https://marc.info/?l=openbsd-ports&m=167871488231807&w=2

Relavant part of that email:

> - security/p5-Mojolicious-Plugin-Authentication: tests fail. Currently
>   at 1.37; release 1.38 includes the following in the release notes:
>   "Fixed an issue that made the test suite fail with Mojolicious 9.25."
>   So, I made a small patch for 1.39 and tests passed. The diff is
>   included, as no other ports depends on it.


diff /usr/ports
commit - 7304a451eb2ac7f3d404daa7f0c1afb24b419b9d
path + /usr/ports
blob - 7c87e4959795c74c3f143eb03f5276a2be527605
file + security/p5-Mojolicious-Plugin-Authentication/Makefile
--- security/p5-Mojolicious-Plugin-Authentication/Makefile
+++ security/p5-Mojolicious-Plugin-Authentication/Makefile
@@ -2,7 +2,7 @@ COMMENT =   authentication plugin for the Mojolicious Pe
 
 MODULES =  cpan
 PKG_ARCH = *
-DISTNAME = Mojolicious-Plugin-Authentication-1.37
+DISTNAME = Mojolicious-Plugin-Authentication-1.39
 CATEGORIES =   security
 
 # Perl
blob - 8632368ef3b2f3d80a0acdef8270fc1a5c623be7
file + security/p5-Mojolicious-Plugin-Authentication/distinfo
--- security/p5-Mojolicious-Plugin-Authentication/distinfo
+++ security/p5-Mojolicious-Plugin-Authentication/distinfo
@@ -1,2 +1,2 @@
-SHA256 (Mojolicious-Plugin-Authentication-1.37.tar.gz) = 
p+0gZyW3s5XU/KEuPx2SPaZE2RMzP/SOojHgZOyxq7Y=
-SIZE (Mojolicious-Plugin-Authentication-1.37.tar.gz) = 27712
+SHA256 (Mojolicious-Plugin-Authentication-1.39.tar.gz) = 
n5nL31ysqj+j+WG+6U3pcibRd6NqFee6MDrnnRModNE=
+SIZE (Mojolicious-Plugin-Authentication-1.39.tar.gz) = 27979

UPDATE net/haproxy 3.0.3 from MAINTAINER

[Lucas Gabriel Vuotto]

Hi ports@,

Straightforward update for HAProxy 3.0.3. The accumulated releases
feature way too many fixes to list inline, see [0] for the details.

Been running it fine on arm64.

There is some extra whitespace churn which escaped my eyes in the
previous updates I sent.

Lucas

[0]: https://www.haproxy.org/download/3.0/src/CHANGELOG


diff 1ea8ce0bcaddb08502e6d1f80e5f2a8f018d7fe2 
7304a451eb2ac7f3d404daa7f0c1afb24b419b9d
commit - 1ea8ce0bcaddb08502e6d1f80e5f2a8f018d7fe2
commit + 7304a451eb2ac7f3d404daa7f0c1afb24b419b9d
blob - 8c7f65b3e4b8767692a5eeaa2fc2cf0294bb6c9d
blob + 105b88de29031d6373daef5492241d9710f1bb57
--- net/haproxy/Makefile
+++ net/haproxy/Makefile
@@ -1,13 +1,12 @@
 COMMENT =  reliable, high performance TCP/HTTP load balancer
 
-DISTNAME = haproxy-3.0.0
+DISTNAME = haproxy-3.0.3
 CATEGORIES =   net www
 HOMEPAGE = https://www.haproxy.org/
 MAINTAINER =   Lucas Gabriel Vuotto 
-REVISION = 0
 
 # GPLv2
-PERMIT_PACKAGE =   Yes
+PERMIT_PACKAGE =   Yes
 
 WANTLIB += c crypto pcre2-8 pcre2-posix pthread ssl z
 
@@ -30,8 +29,8 @@ LIB_DEPENDS = devel/pcre2
 
 # Fix undefined reference to __atomic_*
 .if ${MACHINE_ARCH} == "hppa"
-LDFLAGS += "-latomic"
-WANTLIB += atomic
+LDFLAGS += "-latomic"
+WANTLIB += atomic
 .endif
 
 NO_TEST =  Yes
blob - a1b3a2860f26f5acca317db26709004389ab6e51
blob + 4f5e7e594a231b2e303ecf318d8723ae4021b40a
--- net/haproxy/distinfo
+++ net/haproxy/distinfo
@@ -1,2 +1,2 @@
-SHA256 (haproxy-3.0.0.tar.gz) = Wq2XQWIW0s2d0hLrZ0g5xAzTh/YPvEsT1+o/HlZkqBQ=
-SIZE (haproxy-3.0.0.tar.gz) = 4677659
+SHA256 (haproxy-3.0.3.tar.gz) = Oac8GHoLANJgLLP/ylLRtZ2Q8JAyc0/owD6y4pp9Gd8=
+SIZE (haproxy-3.0.3.tar.gz) = 4684023

UPDATE emulators/snes9x 1.63 from MAINTAINER

[Lucas Gabriel Vuotto]

Hey ports@,

Freshly out of the oven, here is an update for snes9x to its latest
version.

Upstream removed libdl detection, so the patch was updated accordingly.
It now also includes a copy of imgui. I shamelessly stole^W^Wcopied a
patch over from games/fs2open to remove a version in dlopen (<3 thfr@).

A quick playtest shows that both the software and OpenGL backends work.
Vulkan works for a bit and then it dies, at least with Super Mario
World 2: Yoshi's Island (which is known for being a demanding game),
but I also get that with the current version so I don't consider it a
regression. Haven't got time yet to really investigate it, and the
backtrace I get is weird, so clues are welcome:

#0  thrkill () at /tmp/-:2
#1  0x5c8f6f9e08228512 in ?? ()
#2  0x082377978e7b in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#3  0x0823779deb3f in _libc___assert2 (file=, 
line=, func=, failedexpr=) at 
/usr/src/lib/libc/gen/assert.c:52
#4  0x082335b80d65 in poll_for_event () from /usr/X11R6/lib/libX11.so.18.0
#5  0x082335b7f750 in poll_for_response () from 
/usr/X11R6/lib/libX11.so.18.0
#6  0x082335b7f325 in _XEventsQueued () from /usr/X11R6/lib/libX11.so.18.0
#7  0x082335b6f117 in XPending () from /usr/X11R6/lib/libX11.so.18.0
#8  0x0822dc77706c in gdk_event_source_prepare () from 
/usr/local/lib/libgdk-3.so.2201.1
#9  0x08231aa92662 in g_main_context_prepare_unlocked () from 
/usr/local/lib/libglib-2.0.so.4201.12
#10 0x08231aa9331b in g_main_context_iterate_unlocked () from 
/usr/local/lib/libglib-2.0.so.4201.12
#11 0x08231aa9353b in g_main_context_iteration () from 
/usr/local/lib/libglib-2.0.so.4201.12
#12 0x0822f95661dd in g_application_run () from 
/usr/local/lib/libgio-2.0.so.4200.19
#13 0x082345a8cad0 in Gtk::Application::run(Gtk::Window&) () from 
/usr/local/lib/libgtkmm-3.0.so.4.5
#14 0x0820aeee3632 in main (argc=, argv=0x76544cac1968) at 
/usr/ports/pobj/snes9x-1.63/snes9x-1.63/gtk/src/gtk_s9x.cpp:157

The release notes we care for are:

General:
- Added a shortcut to change the backdrop color for sprite extraction.
- Fixed QuickSave 0-9 slot shortcuts not working.
- Allow "Address:byte" form for cheat inputs.
- Fixed ZIP files not being closed after patch search.
- Various memmap fixes to allow unofficial mappings.
- Added usage of ImGui to draw things on top of the screen instead of inside.

Gtk:
- Fixed config file location to never put files directly in $HOME and obey
  $XDG_CONFIG_HOME.
- Updated translations from JakeSmarter and StanleyKid-22.

Lucas


diff 657ca76e9757dc1f26a2bf3d79729c76b261a52e 
a4dfb8dfb45b72d3efd20f5360e7e203496d8a73
commit - 657ca76e9757dc1f26a2bf3d79729c76b261a52e
commit + a4dfb8dfb45b72d3efd20f5360e7e203496d8a73
blob - ea5c54265a75b9b76577e5b9187b619b2d541fa5
blob + 8deaf932393ae14037dd58cd5102cc6717529fa6
--- emulators/snes9x/Makefile
+++ emulators/snes9x/Makefile
@@ -4,8 +4,7 @@ BROKEN-hppa =   ICE/failure on filter/hq2x.cpp
 
 GH_ACCOUNT =   snes9xgit
 GH_PROJECT =   snes9x
-GH_TAGNAME =   1.62.3
-REVISION = 1
+GH_TAGNAME =   1.63
 
 CATEGORIES =   emulators games
 
blob - aa512deed30667594991d6675dcc00a8c9ced997
blob + d049b0c080968945d8adc540fc7e3e0111878b92
--- emulators/snes9x/distinfo
+++ emulators/snes9x/distinfo
@@ -1,2 +1,2 @@
-SHA256 (snes9x-1.62.3.tar.gz) = aRLGkpCuhU6iKxsskX2IWxxKGpWsvnPNQkPMsgcWAP4=
-SIZE (snes9x-1.62.3.tar.gz) = 3423799
+SHA256 (snes9x-1.63.tar.gz) = hFYM44pzSsgplkWIPY4MBCO32iQwveX4gna7ob5tUzA=
+SIZE (snes9x-1.63.tar.gz) = 5134657
blob - 5902804bcdddec9dfea03c618c04ca7172193679
blob + ae4e6b02122be9a1adf57085601f165eb89e61a4
--- emulators/snes9x/patches/patch-gtk_CMakeLists_txt
+++ emulators/snes9x/patches/patch-gtk_CMakeLists_txt
@@ -1,4 +1,3 @@
-No -ldl on OpenBSD.
 Use system glslang and SPIRV-Cross.
 Don't reach for Wayland headers.
 libHLSL is gone since glslang 14
@@ -6,16 +5,8 @@ libHLSL is gone since glslang 14
 Index: gtk/CMakeLists.txt
 --- gtk/CMakeLists.txt.orig
 +++ gtk/CMakeLists.txt
-@@ -63,7 +63,6 @@ pkg_check_modules(XRANDR REQUIRED xrandr)
+@@ -85,16 +85,10 @@ list(APPEND INCLUDES ../external/glad/include)
  
- find_library(X11 X11 REQUIRED)
- find_library(XEXT Xext REQUIRED)
--find_library(DL dl REQUIRED)
- list(APPEND ARGS ${SDL2_CFLAGS} ${GTK_CFLAGS} ${XRANDR_CFLAGS})
- list(APPEND LIBS ${X11} ${XEXT} ${DL} ${SDL2_LIBRARIES} ${GTK_LIBRARIES} 
${XRANDR_LIBRARIES})
- 
-@@ -78,16 +77,10 @@ list(APPEND SOURCES src/gtk_display_driver_opengl.cpp
- 
  if(USE_SLANG)
  list(APPEND SOURCES ../shaders/slang.cpp)
 -list(APPEND INCLUDES ../external/glslang)
@@ -31,7 +22,7 @@ Index: gtk/CMakeLists.txt
   SPIRV
   glslang-default-resource-limits)
  list(APPEND LIBS spirv-cross-core
-@@ -95,10 +88,8 @@ if(USE_SLANG)
+@@ -102,10 +96,8 @@ if(USE_SLANG)
   spirv-cross-reflect
   spirv-cross-cpp)
  list(APPEND DEFINES "USE_SLANG")
@@ -40,5 +31,5 @@ Index: gtk/CMakeLists.txt
   

Re: [update] sysutils/grafana to 11.1.0

[Lucas Gabriel Vuotto]

On Tue, Jul 02, 2024 at 09:56:23PM GMT, Lucas Raab wrote:
> Hello,
> 
> Here's an update for grafana that's been working fine. I also
> incorporated the proposed changes from jca@ if anyone else wants to
> chime in there. https://marc.info/?l=openbsd-ports&m=171803607026170&w=2
> Works fine on amd64, other tests?

Hey Lucas,

This one still works fine in my arm64 instance.

the other Lucas

Radxa ROCK 4B bwfm

[Lucas Gabriel Vuotto]

Hello ports@, Kurt, Patrick,

I have a Radxa ROCK 4B [0] lying around. It has a bwfm-compatible WiFi
but no firmware files. I went ahead and downloaded the files from [1,2]
(the actual files, not the symlinks, but kept the naming) and the
network is working in some light testing (tcpdump and ssh).  Could it
be possible to update the firmware to a newer version? I'm not sending
a patch right away because this ports seems a bit more special than the
rest. I believe that the relevant files should be added to Kurt's repo.
Should I send a PR there, get a new release and then update the
supplemental files version?

Lucas

[0]: https://wiki.radxa.com/Rockpi4
[1]: 
https://github.com/armbian/firmware/blob/master/brcm/brcmfmac43456-sdio.radxa%2Crockpi4b.bin
[2]: 
https://github.com/armbian/firmware/blob/master/brcm/brcmfmac43456-sdio.radxa%2Crockpi4b.txt
[3]: https://github.com/bsdkurt/brcm-supplemental


OpenBSD 7.5-current (GENERIC.MP) #94: Mon Jul  1 06:31:41 MDT 2024
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 4038746112 (3851MB)
avail mem = 3830820864 (3653MB)
random: good seed from bootblocks
mainbus0 at root: Radxa ROCK Pi 4B
psci0 at mainbus0: PSCI 1.1, SMCCC 1.4, SYSTEM_SUSPEND
efi0 at mainbus0: UEFI 2.8
efi0: Das U-Boot rev 0x20211000
smbios0 at efi0: SMBIOS 3.0
smbios0: vendor U-Boot version "2021.10" date 10/01/2021
smbios0: Unknown Unknown Product
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 512KB 64b/line 16-way L2 cache
cpu0: CRC32,SHA2,SHA1,AES+PMULL,ASID16
cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4
cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu1: 512KB 64b/line 16-way L2 cache
cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4
cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu2: 512KB 64b/line 16-way L2 cache
cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4
cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu3: 512KB 64b/line 16-way L2 cache
cpu4 at mainbus0 mpidr 100: ARM Cortex-A72 r0p2
cpu4: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu4: 1024KB 64b/line 16-way L2 cache
cpu4: CRC32,SHA2,SHA1,AES+PMULL,ASID16
cpu5 at mainbus0 mpidr 101: ARM Cortex-A72 r0p2
cpu5: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu5: 1024KB 64b/line 16-way L2 cache
apm0 at mainbus0
agintc0 at mainbus0 sec shift 3:3 nirq 288 nredist 6 ipi: 0, 1, 2: 
"interrupt-controller"
agintcmsi0 at agintc0
syscon0 at mainbus0: "qos"
syscon1 at mainbus0: "qos"
syscon2 at mainbus0: "qos"
syscon3 at mainbus0: "qos"
syscon4 at mainbus0: "qos"
syscon5 at mainbus0: "qos"
syscon6 at mainbus0: "qos"
syscon7 at mainbus0: "qos"
syscon8 at mainbus0: "qos"
syscon9 at mainbus0: "qos"
syscon10 at mainbus0: "qos"
syscon11 at mainbus0: "qos"
syscon12 at mainbus0: "qos"
syscon13 at mainbus0: "qos"
syscon14 at mainbus0: "qos"
syscon15 at mainbus0: "qos"
syscon16 at mainbus0: "qos"
syscon17 at mainbus0: "qos"
syscon18 at mainbus0: "qos"
syscon19 at mainbus0: "qos"
syscon20 at mainbus0: "qos"
syscon21 at mainbus0: "qos"
syscon22 at mainbus0: "qos"
syscon23 at mainbus0: "qos"
syscon24 at mainbus0: "qos"
syscon25 at mainbus0: "power-management"
"power-controller" at syscon25 not configured
syscon26 at mainbus0: "syscon"
"io-domains" at syscon26 not configured
rkclock0 at mainbus0
rkclock1 at mainbus0
syscon27 at mainbus0: "syscon"
"io-domains" at syscon27 not configured
"usb2phy" at syscon27 not configured
"usb2phy" at syscon27 not configured
rkemmcphy0 at syscon27
"pcie-phy" at syscon27 not configured
rktcphy0 at mainbus0
rktcphy1 at mainbus0
rkpinctrl0 at mainbus0: "pinctrl"
rkgpio0 at rkpinctrl0
rkgpio1 at rkpinctrl0
rkgpio2 at rkpinctrl0
rkgpio3 at rkpinctrl0
rkgpio4 at rkpinctrl0
pwmreg0 at mainbus0
syscon28 at mainbus0: "syscon"
syscon29 at mainbus0: "syscon"
"fit-images" at mainbus0 not configured
rkdrm0 at mainbus0
drm0 at rkdrm0
"pmu_a53" at mainbus0 not configured
"pmu_a72" at mainbus0 not configured
agtimer0 at mainbus0: 24000 kHz
"xin24m" at mainbus0 not configured
rkpcie0 at mainbus0
rkpcie0: link training timeout
dwge0 at mainbus0: rev 0x35, address f6:d2:37:a3:9f:1b
rgephy0 at dwge0 phy 0: RTL8169S/8110S/8211 PHY, rev. 6
dwmmc0 at mainbus0: 50 MHz base clock
sdmmc0 at dwmmc0: 4-bit, sd high-speed, dma
dwmmc1 at mainbus0: 50 MHz base clock
sdmmc1 at dwmmc1: 4-bit, sd high-speed, mmc high-speed, dma
sdhc0 at mainbus0
sdhc0: SDHC 3.00, 200 MHz base clock
sdmmc2 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma
ehci0 at mainbus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 
addr 1
ohci0 at mainbus0: version 1.0
ehci1 at mainbus0
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 
addr 1
ohci1 at mainbus0: version 1.0
rkdwusb0 at mainbus0: "usb"
xhci0 at rkdwusb0,

Re: WIP UPDATE net/haproxy 3.0.0

[Lucas Gabriel Vuotto]

On Thu, May 30, 2024 at 08:48:29PM GMT, Theo Buehler wrote:
> Does this still happen if you apply this on top (which will be a noop
> once we bump the libressl version to 4.0)?
> 
> Index: include/haproxy/quic_tls.h
> --- include/haproxy/quic_tls.h.orig
> +++ include/haproxy/quic_tls.h
> @@ -140,7 +140,7 @@ static inline const EVP_CIPHER *tls_aead(const SSL_CIP
>   return EVP_aes_128_gcm();
>   case TLS1_3_CK_AES_256_GCM_SHA384:
>   return EVP_aes_256_gcm();
> -#if !defined(OPENSSL_IS_AWSLC) && (!defined(LIBRESSL_VERSION_NUMBER) || 
> LIBRESSL_VERSION_NUMBER >= 0x400fL)
> +#if !defined(OPENSSL_IS_AWSLC)
>   /* WT: LibreSSL has an issue with CHACHA20 running in-place till 3.9.2
>* included, but the fix is already identified and will be merged
>* into next major version. Given that on machines without AES-NI
> 

Indeed, this gets HTTP/3 rolling. (Took quite some time testing because
I don't understand how desktop browsers do HTTP/3. I'm p sure I still
don't, but hey--my Grafana now loads over HTTP/3... *some times*).

Thanks for the prompt reply, Theo!

Diff updated with this patch. Better / correct patch comment suggestions
are more than welcome.


diff 74dcff6cd6dd2e62a28d3ab1da574df080129e8e 
0b0ecc870da4ee36832bc2fff07632a8d7861299
commit - 74dcff6cd6dd2e62a28d3ab1da574df080129e8e
commit + 0b0ecc870da4ee36832bc2fff07632a8d7861299
blob - b5cddc3eeab11bb6bf999bb5911687342fb8b1e4
blob + 4b2fc6d50a696cd7f95e51c2ced4bdc76533d65a
--- net/haproxy/Makefile
+++ net/haproxy/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  reliable, high performance TCP/HTTP load balancer
 
-DISTNAME = haproxy-2.8.9
+DISTNAME = haproxy-3.0.0
 CATEGORIES =   net www
 HOMEPAGE = https://www.haproxy.org/
 MAINTAINER =   Daniel Jakots 
@@ -12,19 +12,12 @@ WANTLIB +=  c crypto pcre2-8 pcre2-posix pthread ssl z
 
 DEBUG_PACKAGES = ${BUILD_PACKAGES}
 
-SITES =${HOMEPAGE}/download/2.8/src/
+SITES =${HOMEPAGE}/download/3.0/src/
 
-HAPROXYCONF =  ${SYSCONFDIR}/haproxy
-HAPROXYSTATE = /var/haproxy
-HAPROXYUID =   604
-HAPROXYGID =   604
-SUBST_VARS =   HAPROXYCONF HAPROXYSTATE \
-   HAPROXYUID HAPROXYGID
-
 USE_GMAKE =Yes
 MAKE_FLAGS +=  CPU_CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}"
 MAKE_FLAGS +=  CC="${CC}" LD="${CC}" TARGET="openbsd"
-MAKE_FLAGS +=  USE_OPENSSL=1 USE_PCRE2=1 USE_QUIC=1 USE_ZLIB=1 V=1
+MAKE_FLAGS +=  USE_OPENSSL=1 USE_PCRE2=1 USE_PROMEX=1 USE_QUIC=1 USE_ZLIB=1 V=1
 MAKE_FLAGS +=  USE_LIBATOMIC=
 
 FAKE_FLAGS +=  DOCDIR="${PREFIX}/share/doc/haproxy"
blob - f9c70c08d84f0653a75d3a3d505c893f4b840e9c
blob + a1b3a2860f26f5acca317db26709004389ab6e51
--- net/haproxy/distinfo
+++ net/haproxy/distinfo
@@ -1,2 +1,2 @@
-SHA256 (haproxy-2.8.9.tar.gz) = eoIUePNvhHYH9RpR6A9PiQw3r0gR1gQ45/Y3g/Z1kv8=
-SIZE (haproxy-2.8.9.tar.gz) = 4383096
+SHA256 (haproxy-3.0.0.tar.gz) = Wq2XQWIW0s2d0hLrZ0g5xAzTh/YPvEsT1+o/HlZkqBQ=
+SIZE (haproxy-3.0.0.tar.gz) = 4677659
blob - a43fe95d947d035d59d2a49a4d8fbc888a10bc4d
blob + 99030a2bb355b7a75851937ff393f07179241d9b
--- net/haproxy/files/haproxy.cfg
+++ net/haproxy/files/haproxy.cfg
@@ -2,8 +2,8 @@ global
log 127.0.0.1   local0 debug
maxconn 1024
chroot /var/haproxy
-   uid 604
-   gid 604
+   user _haproxy
+   group _haproxy
daemon
pidfile /var/run/haproxy.pid
 
blob - /dev/null
blob + 248415d196379cd4cd6dfb260f12422c8a2aa45b (mode 644)
--- /dev/null
+++ net/haproxy/patches/patch-include_haproxy_quic_tls_h
@@ -0,0 +1,17 @@
+-current works correctly with in-place ChaCha20-Poly1305. Without this,
+some clients may receive ChaCha20-Poly1305 in the handshake but won't
+be able to use it: at least curl returns "Weird server reply". To be
+dropped after LibreSSL 4.
+
+Index: include/haproxy/quic_tls.h
+--- include/haproxy/quic_tls.h.orig
 include/haproxy/quic_tls.h
+@@ -140,7 +140,7 @@ static inline const EVP_CIPHER *tls_aead(const SSL_CIP
+   return EVP_aes_128_gcm();
+   case TLS1_3_CK_AES_256_GCM_SHA384:
+   return EVP_aes_256_gcm();
+-#if !defined(OPENSSL_IS_AWSLC) && (!defined(LIBRESSL_VERSION_NUMBER) || 
LIBRESSL_VERSION_NUMBER >= 0x400fL)
++#if !defined(OPENSSL_IS_AWSLC)
+   /* WT: LibreSSL has an issue with CHACHA20 running in-place till 3.9.2
+* included, but the fix is already identified and will be merged
+* into next major version. Given that on machines without AES-NI
blob - 16e125964bb7859239dcd70c42d51055fa8d313e
blob + 80afa917bba6891b62364c489a3583bd15a841e4
--- net/haproxy/pkg/PLIST
+++ net/haproxy/pkg/PLIST
@@ -1,10 +1,10 @@
-@newgroup _haproxy:${HAPROXYGID}
-@newuser _haproxy:${HAPROXYUID}:_haproxy::HAProxy 
Daemon:/var/haproxy:/sbin/nologin
+@newgroup _haproxy:604
+@newuser _haproxy:604:_haproxy::HAProxy 
Daemon:${LOCALSTATEDIR}/haproxy:/sbin/nologin
 @rcscript ${RCDIR}/haproxy
 @man man/man1/haproxy.1
 @bin sbin/haproxy
-@sample ${HAPROXYCONF}/
-@sample ${HAPROXYSTAT

WIP UPDATE net/haproxy 3.0.0

[Lucas Gabriel Vuotto]

Hello ports@,

Here is an update to haproxy to latest version, released yesterday. I
have been running the -dev versions on-and-off for the last couple of
weeks without much issue; I don't expect anything to go wrong with
this last version. Changelog is big and can be found at [0].

Portwise, I didn't see much gain in HAPROXY* vars so I got rid of them.
That's where most of the churn comes from. I also added USE_PROMEX=1 to
have a Prometheus / OpenMetrics endpoint. It compiles an additional C
file without any new dependency.

tb@, the only difference (and the reason why update is WIP) I see here
with my arm64 server is that now I'll get "Weird server reply" from
curl if I try to connect with QUIC. The issue is only present when
using the default cipher suite; removing TLS_CHACHA20_POLY1305_SHA256
from the proposal makes it work correctly. Is this related to "alert
issue" you talk about in [1]? In that case, does it make sense to pause
this update until the issue is solved?

Cheers,
Lucas

[0]: https://github.com/haproxy/haproxy/blob/master/CHANGELOG
[1]: https://github.com/haproxy/haproxy/issues/2569#issuecomment-2124956170


diff 74dcff6cd6dd2e62a28d3ab1da574df080129e8e 
74db4daef7132ba3dc53fe6441d99be0c9c02184
commit - 74dcff6cd6dd2e62a28d3ab1da574df080129e8e
commit + 74db4daef7132ba3dc53fe6441d99be0c9c02184
blob - b5cddc3eeab11bb6bf999bb5911687342fb8b1e4
blob + 4b2fc6d50a696cd7f95e51c2ced4bdc76533d65a
--- net/haproxy/Makefile
+++ net/haproxy/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  reliable, high performance TCP/HTTP load balancer
 
-DISTNAME = haproxy-2.8.9
+DISTNAME = haproxy-3.0.0
 CATEGORIES =   net www
 HOMEPAGE = https://www.haproxy.org/
 MAINTAINER =   Daniel Jakots 
@@ -12,19 +12,12 @@ WANTLIB +=  c crypto pcre2-8 pcre2-posix pthread ssl z
 
 DEBUG_PACKAGES = ${BUILD_PACKAGES}
 
-SITES =${HOMEPAGE}/download/2.8/src/
+SITES =${HOMEPAGE}/download/3.0/src/
 
-HAPROXYCONF =  ${SYSCONFDIR}/haproxy
-HAPROXYSTATE = /var/haproxy
-HAPROXYUID =   604
-HAPROXYGID =   604
-SUBST_VARS =   HAPROXYCONF HAPROXYSTATE \
-   HAPROXYUID HAPROXYGID
-
 USE_GMAKE =Yes
 MAKE_FLAGS +=  CPU_CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}"
 MAKE_FLAGS +=  CC="${CC}" LD="${CC}" TARGET="openbsd"
-MAKE_FLAGS +=  USE_OPENSSL=1 USE_PCRE2=1 USE_QUIC=1 USE_ZLIB=1 V=1
+MAKE_FLAGS +=  USE_OPENSSL=1 USE_PCRE2=1 USE_PROMEX=1 USE_QUIC=1 USE_ZLIB=1 V=1
 MAKE_FLAGS +=  USE_LIBATOMIC=
 
 FAKE_FLAGS +=  DOCDIR="${PREFIX}/share/doc/haproxy"
blob - f9c70c08d84f0653a75d3a3d505c893f4b840e9c
blob + a1b3a2860f26f5acca317db26709004389ab6e51
--- net/haproxy/distinfo
+++ net/haproxy/distinfo
@@ -1,2 +1,2 @@
-SHA256 (haproxy-2.8.9.tar.gz) = eoIUePNvhHYH9RpR6A9PiQw3r0gR1gQ45/Y3g/Z1kv8=
-SIZE (haproxy-2.8.9.tar.gz) = 4383096
+SHA256 (haproxy-3.0.0.tar.gz) = Wq2XQWIW0s2d0hLrZ0g5xAzTh/YPvEsT1+o/HlZkqBQ=
+SIZE (haproxy-3.0.0.tar.gz) = 4677659
blob - a43fe95d947d035d59d2a49a4d8fbc888a10bc4d
blob + 99030a2bb355b7a75851937ff393f07179241d9b
--- net/haproxy/files/haproxy.cfg
+++ net/haproxy/files/haproxy.cfg
@@ -2,8 +2,8 @@ global
log 127.0.0.1   local0 debug
maxconn 1024
chroot /var/haproxy
-   uid 604
-   gid 604
+   user _haproxy
+   group _haproxy
daemon
pidfile /var/run/haproxy.pid
 
blob - 16e125964bb7859239dcd70c42d51055fa8d313e
blob + 80afa917bba6891b62364c489a3583bd15a841e4
--- net/haproxy/pkg/PLIST
+++ net/haproxy/pkg/PLIST
@@ -1,10 +1,10 @@
-@newgroup _haproxy:${HAPROXYGID}
-@newuser _haproxy:${HAPROXYUID}:_haproxy::HAProxy 
Daemon:/var/haproxy:/sbin/nologin
+@newgroup _haproxy:604
+@newuser _haproxy:604:_haproxy::HAProxy 
Daemon:${LOCALSTATEDIR}/haproxy:/sbin/nologin
 @rcscript ${RCDIR}/haproxy
 @man man/man1/haproxy.1
 @bin sbin/haproxy
-@sample ${HAPROXYCONF}/
-@sample ${HAPROXYSTATE}/
+@sample ${SYSCONFDIR}/haproxy/
+@sample ${LOCALSTATEDIR}/haproxy/
 share/doc/haproxy/
 share/doc/haproxy/51Degrees-device-detection.txt
 share/doc/haproxy/DeviceAtlas-device-detection.txt
@@ -29,7 +29,7 @@ share/examples/haproxy/
 share/examples/haproxy/basic-config-edge.cfg
 share/examples/haproxy/content-sw-sample.cfg
 share/examples/haproxy/haproxy.cfg
-@sample ${HAPROXYCONF}/haproxy.cfg
+@sample ${SYSCONFDIR}/haproxy/haproxy.cfg
 share/examples/haproxy/option-http_proxy.cfg
 share/examples/haproxy/quick-test.cfg
 share/examples/haproxy/socks4.cfg
blob - a12dbcca94f88c66db215d8691031ece620e5dfb
blob + 7552730c88bf774e6cf73e3503887d62b69f5fea
--- net/haproxy/pkg/haproxy.rc
+++ net/haproxy/pkg/haproxy.rc
@@ -1,7 +1,7 @@
 #!/bin/ksh
 
 daemon="${TRUEPREFIX}/sbin/haproxy"
-daemon_flags="-f ${HAPROXYCONF}/haproxy.cfg"
+daemon_flags="-f ${SYSCONFDIR}/haproxy/haproxy.cfg"
 
 . /etc/rc.d/rc.subr
 

Re: HELP WANTED: NEW net/abaddon

[Lucas Gabriel Vuotto]

On Sun, May 19, 2024 at 09:15:44AM GMT, izder456 wrote:
> Hello ports@,
> 
> I am working on a port for net/abaddon which is a lightweight GTK3
> discord client written in C++.
> 
> I got so far until a `make package` where I get this error:
> 
> ===>  Building package for abaddon-0.2.1
> Create /usr/packages/amd64/all/abaddon-0.2.1.tgz
> Error: Libraries in packing-lists in the ports tree
>and libraries from installed packages don't match
> --- /tmp/dep_cache.u16eUfuw6/portstree-abaddon-0.2.1Sun May 19
> 09:10:39 2024 +++ /tmp/dep_cache.u16eUfuw6/inst-abaddon-0.2.1 Sun May
> 19 09:10:39 2024 @@ -22,7 +22,7 @@
>  -W gtk-3.2201.0
>  -W gtkmm-3.0.4.5
>  -W handy-1.0.3
> --W harfbuzz.18.9
> +-W harfbuzz.18.8
>  -W intl.8.0
>  -W m.10.1
>  -W opus.1.5
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3567
> 'wantlib-args': @case X${_DEPENDS_CACHE} in  X) _DEPENDS_CACHE=$(
> mktemp -d ...) *** Error 2 in .
> (/usr/ports/infrastructure/mk/bsd.port.mk:2243
> '/usr/packages/amd64/all/abaddon-0.2.1.tgz': @trap "cd
> /usr/packages/amd64/t...) *** Error 2 in .
> (/usr/ports/infrastructure/mk/bsd.port.mk:2725 '_internal-package':
> @case X${_DEPENDS_CACHE} in  X) _DEPENDS_CACHE=$( mktem...) *** Error 2
> in /home/izder456/Projects/OpenBSD/ports/mystuff/net/abaddon
> (/usr/ports/infrastructure/mk/bsd.port.mk:2704 'package': @lock=aba...)
> 
> I have tried to update my plist with `make update-plist`, but to no
> avail.

So, playing a bit by ear here, but it seems you got an stale harfbuzz.
I believe this could happen if you were working in the port, then
upgraded your installed ports / your system and tried to work again with
it. Usually, a `make clean=plist` and `make plist` can solve it.

In my machine(tm), it `make package`s correctly.

I had to apply the following patch on top of your Makefile: sqlite3 is
checked at build time, and so is nlohmann-json (and the configure fails
without it).


--- Makefile.oldSun May 19 01:32:58 2024
+++ MakefileSun May 19 14:52:10 2024
@@ -31,9 +31,10 @@
 
 MODULES =  devel/cmake
 
-RUN_DEPENDS =  databases/sqlite3
+BUILD_DEPENDS =textproc/nlohmann-json
 LIB_DEPENDS =  audio/rnnoise \
audio/opus \
+   databases/sqlite3 \
devel/atk2mm \
devel/fmt \
devel/glib2mm \


Although I don't use discord, I tried to run-test it. I got 3 popups and
a coredump. Also, now I have an abaddon.ini in whatever directory I run
abaddon from.

1. The emoji file couldn't be loaded!
2. css failed parsing (Failed to import: Error opening file
   /home/lucas/css/main.css: No such file or directory)
3. css failed to load (:1:0Failed to import: Error opening
   file /home/lucas/css/main.css: No such file or directory)

$ abaddon  
[2024-05-19 15:00:23.270] [discord] [warning] unknown OS, trying to load config 
from cwd
[2024-05-19 15:00:23.301] [ui] [error] Keychain error reading token: The name 
org.freedesktop.secrets was not provided by any .service files (2)
[2024-05-19 15:00:23.324] [discord] [warning] unknown OS, trying to load 
resources from cwd
[2024-05-19 15:00:23.327] [audio] [info] Audio backend: sndio
[2024-05-19 15:00:23.328] [audio] [warning] No default playback device found
[2024-05-19 15:00:23.328] [audio] [warning] No default capture device found
[2024-05-19 15:01:30.942] [discord] [warning] unknown OS, trying to load 
resources from cwd

(abaddon:6193): Gtk-CRITICAL **: 15:02:53.986: gtk_tree_model_sort_get_value: 
assertion 'VALID_ITER (iter, tree_model_sort)' failed
Segmentation fault (core dumped) 

egdb backtrace:

Reading symbols from 
/usr/ports/pobj/abaddon-0.2.1/fake-amd64/usr/local/bin/abaddon...
(No debugging symbols found in 
/usr/ports/pobj/abaddon-0.2.1/fake-amd64/usr/local/bin/abaddon)
[New process 338261]
[New process 349941]
[New process 350520]
[New process 351364]
[New process 515827]
[New process 570852]
[New process 186393]
[New process 462478]
[New process 331380]
Core was generated by `abaddon'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00a5eac6baba in ?? ()
[Current thread is 1 (process 338261)]
(gdb) bt
#0  0x00a5eac6baba in ?? ()
#1  0x00a89f67 in SignalProxy_Select_gtk_callback(_GtkTreeSelection*, 
_GtkTreeModel*, _GtkTreePath*, int, void*) () from 
/usr/local/lib/libgtkmm-3.0.so.4.5
#2  0x00a8093f135e in _gtk_tree_selection_row_is_selectable () from 
/usr/local/lib/libgtk-3.so.2201.0
#3  0x00a8093f13ed in gtk_tree_selection_real_select_node () from 
/usr/local/lib/libgtk-3.so.2201.0
#4  0x00a8093ef563 in _gtk_tree_selection_internal_select_node () from 
/usr/local/lib/libgtk-3.so.2201.0
#5  0x00a8093fc33d in gtk_tree_view_real_set_cursor () from 
/usr/local/lib/libgtk-3.so.2201.0
#6  0x00a80940be31 in gtk_tree_view_grab_focus () from 
/usr/local/lib/libgtk-3.so.2201.0
#7  0x00a827699601 in _g_closure_invo

Re: [update] sysutils/grafana to 10.4.3

[Lucas Gabriel Vuotto]

On Sun, May 19, 2024 at 04:09:08AM GMT, Lucas Raab wrote:
> On Mon, Apr 22, 2024 at 04:07:36AM GMT, Lucas Raab wrote:
> > Hello,
> > 
> > Here's an update for grafana to the latest that's been working fine over
> > the past couple weeks.
> > 
> > changelogs:
> > https://github.com/grafana/grafana/releases/tag/v10.4.1
> > https://github.com/grafana/grafana/releases/tag/v10.4.2
> > 
> > Other tests?
> > 
> > Thanks,
> > Lucas
> 
> And an update to 10.4.3 as well which has been working fine since it was
> released.
> 
> changelog:
> https://github.com/grafana/grafana/releases/tag/v10.4.3
> 
> Thanks,
> Lucas

This one still works for me.

Perl ports in arm64 vs -current

[Lucas Gabriel Vuotto]

Hello ports@,

Since today's snapshot, it seems that something is off in arm64 and
Perl:

$ perl -MNet::SSLeay -e 'print "works\n"'
SSLeay.c: loadable library and perl binaries are mismatched (got first 
handshake key 0x1060, needed 0x10d0)

On the contrary, on amd64 updated today too,

$ perl -MNet::SSLeay -e 'print "works\n"'
works

The issue is present with other modules, Net::SSLeay was chosen as it
was the one giving me an error message. But I tried p5-EV with a similar
error except for the filename.

Rebuilding the package locally makes the error go away, so I guess it's
related to builders not being up-to-date with latest Perl, leading to
errors for packages with native extensions?

dmesgs for systems follow.

Lucas


==> arm64

OpenBSD 7.5-current (GENERIC.MP) #40: Fri May 17 14:59:13 MDT 2024
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 4185792512 (3991MB)
avail mem = 3971817472 (3787MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.0, SMCCC 1.1
efi0 at mainbus0: UEFI 2.7
efi0: EDK II rev 0x1
smbios0 at efi0: SMBIOS 3.0.0
smbios0: vendor Hetzner version "2017" date 11/11/2017
smbios0: Hetzner vServer
cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r3p1
cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache
cpu0: 1024KB 64b/line 8-way L2 cache
cpu0: 
DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SSBS+MSR
cpu1 at mainbus0 mpidr 1: ARM Neoverse N1 r3p1
cpu1: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache
cpu1: 1024KB 64b/line 8-way L2 cache
apm0 at mainbus0
agintc0 at mainbus0 shift 4:4 nirq 288 nredist 2 ipi: 0, 1, 2: 
"interrupt-controller"
agintcmsi0 at agintc0
agtimer0 at mainbus0: 25000 kHz
acpi0 at mainbus0: ACPI 5.1
acpi0: sleep states
acpi0: tables DSDT FACP APIC GTDT MCFG SPCR DBG2 IORT BGRT
acpi0: wakeup devices
acpimcfg0 at acpi0
acpimcfg0: addr 0x401000, bus 0-255
acpiiort0 at acpi0
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
pluart0 at acpi0 COM0 addr 0x900/0x1000 irq 33
pluart0: console
"LNRO0015" at acpi0 not configured
"LNRO0015" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
acpipci0 at acpi0 PCI0
pci0 at acpipci0
"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
virtio0 at pci0 dev 1 function 0 "Qumranet Virtio 1.x GPU" rev 0x01
viogpu0 at virtio0: 1024x768, 32bpp
wsdisplay0 at viogpu0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
virtio0: msix per-VQ
ppb0 at pci0 dev 2 function 0 "Red Hat PCIE" rev 0x00: irq 37
pci1 at ppb0 bus 1
virtio1 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01
vio0 at virtio1: address 96:00:02:40:c5:c9
virtio1: msix shared
ppb1 at pci0 dev 2 function 1 "Red Hat PCIE" rev 0x00: irq 37
pci2 at ppb1 bus 2
xhci0 at pci2 dev 0 function 0 "Red Hat xHCI" rev 0x01: msix, xHCI 0.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev 3.00/1.00 
addr 1
ppb2 at pci0 dev 2 function 2 "Red Hat PCIE" rev 0x00: irq 37
pci3 at ppb2 bus 3
virtio2 at pci3 dev 0 function 0 "Qumranet Virtio 1.x Console" rev 0x01
virtio2: no matching child driver; not configured
ppb3 at pci0 dev 2 function 3 "Red Hat PCIE" rev 0x00: irq 37
pci4 at ppb3 bus 4
virtio3 at pci4 dev 0 function 0 "Qumranet Virtio 1.x Memory Balloon" rev 0x01
viomb0 at virtio3
virtio3: irq 37
ppb4 at pci0 dev 2 function 4 "Red Hat PCIE" rev 0x00: irq 37
pci5 at ppb4 bus 5
virtio4 at pci5 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01
viornd0 at virtio4
virtio4: irq 37
ppb5 at pci0 dev 2 function 5 "Red Hat PCIE" rev 0x00: irq 37
pci6 at ppb5 bus 6
virtio5 at pci6 dev 0 function 0 "Qumranet Virtio 1.x SCSI" rev 0x01
vioscsi0 at virtio5: qsize 128
scsibus0 at vioscsi0: 2

Re: HAProxy, HTTP/3 and arm64

[Lucas Gabriel Vuotto]

Reviving this old thread, lately I found out that the issue is only
present in arm64 and not amd64. I also filled a bug in HAProxy repo,
which contains relevant information.

https://github.com/haproxy/haproxy/issues/2569

Lucas

On Mon, Jan 15, 2024 at 09:22:15PM GMT, Lucas Gabriel Vuotto wrote:
> Hi ports@,
> 
> did anybody succeed at serving HTTP/3 traffic with HAProxy? It should be
> supported since 2.8, but I can't make it work: `curl --http3-only` gets
> stuck and usually ends with
> 
> curl: (55) ngtcp2_conn_writev_stream returned error: ERR_DRAINING
> 
> It does work against https://http3.is, https://cloudflare.com and
> others.
> 
> I'm trying with the following config, which does work for HTTP/1.1 and
> HTTP/2:
> 
> 
> global
>   log 127.0.0.1 local0 debug
>   maxconn 1024
>   chroot /var/haproxy
>   user _haproxy
>   group _haproxy
>   daemon
>   pidfile /var/run/haproxy.pid
> 
>   ssl-default-bind-options ssl-min-ver TLSv1.2
>   ssl-load-extra-del-ext
> 
> defaults
>   log global
>   mode http
>   option httplog
>   option dontlognull
>   option redispatch
>   retries 3
>   maxconn 2000
>   timeout connect 5s
>   timeout client 65s
>   timeout server 5s
> 
> frontend haproxy
>   bind ipv4@:80,ipv6@:80
>   bind ipv4@:443,ipv6@:443 ssl crt /etc/haproxy/certs/
>   bind quic4@:443,quic6@:443 ssl crt /etc/haproxy/certs/
> 
>   option forwardfor
> 
>   acl acme-challenge path_beg /.well-known/acme-challenge/
>   acl ntfy req.hdr(host) -i ntfy.example.com
>   acl grafana req.hdr(host) -i grafana.example.com
> 
>   http-request redirect scheme https unless { ssl_fc } || acme-challenge
>   http-after-response add-header alt-svc 'h3=":443"; ma=900;'
> 
>   use_backend httpd if acme-challenge
>   use_backend ntfy_ws if ntfy { path_end /ws }
>   use_backend ntfy if ntfy
>   use_backend grafana if grafana
>   default_backend httpd
> 
> backend httpd
>   server s1 127.0.0.1:8080 check
> 
> backend ntfy_ws
>   option httpchk /v1/health
>   option http-server-close
>   timeout tunnel 10m
>   server s1 127.0.0.1:3010 check
> 
> backend ntfy
>   option httpchk /v1/health
>   server s1 127.0.0.1:3010 check
> 
> backend grafana
>   option httpchk /api/health
>   server s1 127.0.0.1:3000 check
> 
> 
> Adding an alpn directive to bind lines makes no difference, and
> according to the docs, the "normal" binds get an `alpn h2,http1.1` while
> the quic binds get an `alpn h3` by default.
> 
> tcpdump shows that there is some handshakes attempts between client and
> server, and so does the stats socket of HAProxy:
> 
> 
> > show quic full
> * 0xd10d64000[00]: scid=4f5f572ad85655a9 
> dcid=4559862ad37160765abf2b2082ad0e624fe59237
>   loc. TPs: odcid=5cf7472f2d706253c37792abe48c49eea466ffd1 
> iscid=4f5f572ad85655a9
> midle_timeout=3ms mudp_payload_sz=2048 ack_delay_exp=3 
> mack_delay=25ms act_cid_limit=8
> md=1687140 msd_bidi_l=16380 msd_bidi_r=16380 msd_uni=16380 ms_bidi=100 
> ms_uni=3
> (no_act_migr,stless_rst_tok)
>   rem. TPs: iscid=4559862ad37160765abf2b2082ad0e624fe59237
> midle_timeout=12ms mudp_payload_sz=65527 ack_delay_exp=3 
> mack_delay=25ms act_cid_limit=2
> md=1310720 msd_bidi_l=131072 msd_bidi_r=131072 msd_uni=131072 
> ms_bidi=262144 ms_uni=262144
> versions:chosen=0x0001,negotiated=0x0001
>   st=handshakemux=null  expire=24s
>   fd=-1   local_addr=128.140.63.137:443 
> foreign_addr=5.161.47.47:56773
>   [initl] rx.ackrng=1  tx.inflight=0[hndshk] 
> rx.ackrng=0  tx.inflight=9877
>   [01rtt] rx.ackrng=0  tx.inflight=0
>   srtt=274  rttvar=137  rttmin=274  ptoc=3cwnd=12707  mcwnd=12707  
> sentpkts=11 lostpkts=0
> 
> 
> > show quic full
> * 0xd10d64000[00]: scid=4f5f572ad85655a9 
> dcid=4559862ad37160765abf2b2082ad0e624fe59237
>   loc. TPs: odcid=5cf7472f2d706253c37792abe48c49eea466ffd1 
> iscid=4f5f572ad85655a9
> midle_timeout=3ms mudp_payload_sz=2048 ack_delay_exp=3 
> mack_delay=25ms act_cid_limit=8
> md=1687140 msd_bidi_l=16380 msd_bidi_r=16380 msd_uni=16380 ms_bidi=100 
> ms_uni=3
> (no_act_migr,stless_rst_tok)
>   rem. TPs: iscid=4559862ad37160765abf2b2082ad0e624fe59237
> midle_timeout=12ms mudp_payload_sz=65527 ack_delay_exp=3 
> mack_delay=25ms act_cid_limit=2
> md=1310720 ms

Re: databases/victoriametrics: update to v1.101.0

[Lucas Gabriel Vuotto]

On Sun, Apr 14, 2024 at 01:25:47PM GMT, Lucas Gabriel Vuotto wrote:
> Hey Denis, ports@,
> 
> Sorry it took me so long to get back at this.
> 
> I've revisited VictoriaMetrics versioning and they seem to no longer
> make LTS releases for non-enterprise clients, so lets jump straight to
> 1.100.1. The changes are extensive and split between [0] and [1].
> 
> Portwise, had to add MODGO_GO111MODULE (thanks for the issue in GitHub;
> otherwise I don't I'd have been able to fix it myself), removed the 
> built date from the version string, replaced the multiple utils Makefile
> targets with vmutils-pure (which now also builds and installs
> vmalert-tool), sorted the utils install step and removed some Excalidraw
> files that now would get installed while copying the docs over. There is
> some PLIST churn as upstream switched from PNG images to WebP. Of notice
> in PLIST, I did the following change to better align with most of the
> installs in other places:
> 
>   -@sample ${SYSCONFDIR}/vmetrics/
>   +@sample ${SYSCONFDIR}/victoriametrics/
> 
> I don't know how disruptive this can be to the port consumers. I guess
> it's little tho, as it doesn't read any config file by default.
> 
> Been running it for a couple of ours in arm64 without any issue so far.
> 
>   Lucas
> 
> [0]: 
> https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md
> [1]: 
> https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG_2023.md

Bump, now on 1.101.0.


diff refs/heads/master aa19ba1693990b685a56caf472379ad18b4f42b8
commit - da393a8bef60b5a2c658680daf3f9e750fc6fba8
commit + aa19ba1693990b685a56caf472379ad18b4f42b8
blob - a4c03f11455585ec042c26924f276d67114cc03c
blob + 7307b633f04d76955ed3475a5e7138dcd8723b9a
--- databases/victoriametrics/Makefile
+++ databases/victoriametrics/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  fast, cost-effective and scalable time series database
 
-V =1.93.10
+V =1.101.0
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
@@ -21,34 +21,37 @@ USE_GMAKE = Yes
 
 MODULES =  lang/go
 MODGO_GOPATH = ${MODGO_WORKSPACE}
+MODGO_GO111MODULE =auto
 SUBST_VARS =   LOCALSTATEDIR
 NO_TEST =  Yes
 
-MAKE_ENV = BUILDINFO_TAG=tags-v${V} PKG_TAG=tags-v${V}
+# Only used for "make release" target, not consumed by ports. Shuts up
+# getconf: _NPROCESSORS_ONLN: unknown variable
+MAKE_ENV +=MAKE_CONCURRENCY=1
+MAKE_ENV +=BUILDINFO_TAG=tags-v${V} \
+   DATEINFO_TAG= \
+   PKG_TAG=tags-v${V}
 
 ALL_TARGET =   github.com/VictoriaMetrics/VictoriaMetrics
 
 do-build:
-   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} 
victoria-metrics-pure
-   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmbackup-pure
-   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmrestore-pure
-   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmagent-pure
-   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-metrics-pure vmutils-pure
 
 do-install:
${INSTALL_PROGRAM} ${WRKSRC}/bin/victoria-metrics-pure 
${PREFIX}/bin/vmetrics
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmagent-pure ${PREFIX}/bin/vmagent
+   ${INSTALL_PROGRAM} ${WRKSRC}/bin/vmalert-pure 
${PREFIX}/bin/vmetricsalert
+   ${INSTALL_PROGRAM} ${WRKSRC}/bin/vmalert-tool-pure 
${PREFIX}/bin/vmetricsalert-tool
+   ${INSTALL_PROGRAM} ${WRKSRC}/bin/vmauth-pure ${PREFIX}/bin/vmetricsauth
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmbackup-pure 
${PREFIX}/bin/vmetricsbackup
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmrestore-pure 
${PREFIX}/bin/vmetricsrestore
-   ${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_DATA_DIR} ${PREFIX}/share/doc/vmetrics/
${INSTALL_DATA} ${WRKSRC}/README.md ${PREFIX}/share/doc/vmetrics/
${INSTALL_DATA} ${WRKSRC}/LICENSE ${PREFIX}/share/doc/vmetrics/
-   ${INSTALL_DATA} ${WRKSRC}/docs/vm* ${PREFIX}/share/doc/vmetrics/
+   (cd ${WRKSRC}/docs && pax -w vm*) | \
+   (cd ${PREFIX}/share/doc/vmetrics/ && pax -r -c '*.excalidraw')
${INSTALL_DATA} ${WRKSRC}/app/vmauth/example_config.yml \
${P

Re: [update] sysutils/grafana to 10.4.2

[Lucas Gabriel Vuotto]

On Mon, Apr 22, 2024 at 04:07:34AM GMT, Lucas Raab wrote:
> Hello,
> 
> Here's an update for grafana to the latest that's been working fine over
> the past couple weeks.
> 
> changelogs:
> https://github.com/grafana/grafana/releases/tag/v10.4.1
> https://github.com/grafana/grafana/releases/tag/v10.4.2
> 
> Other tests?
> 
> Thanks,
> Lucas

I'm running this on arm64 since yesterday without issues.

Lucas

Re: databases/victoriametrics: update to v1.93.13

[Lucas Gabriel Vuotto]

Hey Denis, ports@,

Sorry it took me so long to get back at this.

I've revisited VictoriaMetrics versioning and they seem to no longer
make LTS releases for non-enterprise clients, so lets jump straight to
1.100.1. The changes are extensive and split between [0] and [1].

Portwise, had to add MODGO_GO111MODULE (thanks for the issue in GitHub;
otherwise I don't I'd have been able to fix it myself), removed the 
built date from the version string, replaced the multiple utils Makefile
targets with vmutils-pure (which now also builds and installs
vmalert-tool), sorted the utils install step and removed some Excalidraw
files that now would get installed while copying the docs over. There is
some PLIST churn as upstream switched from PNG images to WebP. Of notice
in PLIST, I did the following change to better align with most of the
installs in other places:

-@sample ${SYSCONFDIR}/vmetrics/
+@sample ${SYSCONFDIR}/victoriametrics/

I don't know how disruptive this can be to the port consumers. I guess
it's little tho, as it doesn't read any config file by default.

Been running it for a couple of ours in arm64 without any issue so far.

Lucas

[0]: 
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md
[1]: 
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG_2023.md


diff 2cd9db2cf47edccc9b995543c2251ae75f97ca74 
a04dc5822ec6b9f87c5ba957dcd62c3f8e0ced2d
commit - 2cd9db2cf47edccc9b995543c2251ae75f97ca74
commit + a04dc5822ec6b9f87c5ba957dcd62c3f8e0ced2d
blob - a4c03f11455585ec042c26924f276d67114cc03c
blob + e1fd56d5ae3ffa4b5606a8fd97b4d03c174755e1
--- databases/victoriametrics/Makefile
+++ databases/victoriametrics/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  fast, cost-effective and scalable time series database
 
-V =1.93.10
+V =1.100.1
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
@@ -21,34 +21,37 @@ USE_GMAKE = Yes
 
 MODULES =  lang/go
 MODGO_GOPATH = ${MODGO_WORKSPACE}
+MODGO_GO111MODULE =auto
 SUBST_VARS =   LOCALSTATEDIR
 NO_TEST =  Yes
 
-MAKE_ENV = BUILDINFO_TAG=tags-v${V} PKG_TAG=tags-v${V}
+# Only used for "make release" target, not consumed by ports. Shuts up
+# getconf: _NPROCESSORS_ONLN: unknown variable
+MAKE_ENV +=MAKE_CONCURRENCY=1
+MAKE_ENV +=BUILDINFO_TAG=tags-v${V} \
+   DATEINFO_TAG= \
+   PKG_TAG=tags-v${V}
 
 ALL_TARGET =   github.com/VictoriaMetrics/VictoriaMetrics
 
 do-build:
-   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} 
victoria-metrics-pure
-   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmbackup-pure
-   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmrestore-pure
-   cd ${WRKSRC} && GOOS=openbsd ${MAKE_ENV} ${MAKE_PROGRAM} vmagent-pure
-   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-metrics-pure vmutils-pure
 
 do-install:
${INSTALL_PROGRAM} ${WRKSRC}/bin/victoria-metrics-pure 
${PREFIX}/bin/vmetrics
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmagent-pure ${PREFIX}/bin/vmagent
+   ${INSTALL_PROGRAM} ${WRKSRC}/bin/vmalert-pure 
${PREFIX}/bin/vmetricsalert
+   ${INSTALL_PROGRAM} ${WRKSRC}/bin/vmalert-tool-pure 
${PREFIX}/bin/vmetricsalert-tool
+   ${INSTALL_PROGRAM} ${WRKSRC}/bin/vmauth-pure ${PREFIX}/bin/vmetricsauth
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmbackup-pure 
${PREFIX}/bin/vmetricsbackup
${INSTALL_PROGRAM} ${WRKSRC}/bin/vmrestore-pure 
${PREFIX}/bin/vmetricsrestore
-   ${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_DATA_DIR} ${PREFIX}/share/doc/vmetrics/
${INSTALL_DATA} ${WRKSRC}/README.md ${PREFIX}/share/doc/vmetrics/
${INSTALL_DATA} ${WRKSRC}/LICENSE ${PREFIX}/share/doc/vmetrics/
-   ${INSTALL_DATA} ${WRKSRC}/docs/vm* ${PREFIX}/share/doc/vmetrics/
+   (cd ${WRKSRC}/docs && pax -w vm*) | \
+   (cd ${PREFIX}/share/doc/vmetrics/ && pax -r -c '*.excalidraw')
${INSTALL_DATA} ${WRKSRC}/app/vmauth/example_config.yml \
${PREFIX}/share/doc/vmetrics/vmauth_example_config.yml
${INSTALL_DATA} ${WRKSRC}/deployment/docker/alerts.yml \
blob - 80adccc8809934bcde660ee6d5652b7a6896a582
blob + 6b23c970b0819352adb8b912c60f835f1b64987e
--- databases/victoriametrics/distinfo
+++ databases/victoriametrics/distinfo
@@ -1,2 +1,2 @@
-SHA256 (VictoriaMetrics-VictoriaMetrics-v1.93.10.

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

Re: sysutils/docker-cli: update to 25.0.3

[Lucas Gabriel Vuotto]

Bump.

diff 66558c8aa9d546289d58e8d8fc876f4ab52fa9a4 
66ce938ebaa602aed50c9ed8f7db88b7b1755fe2
commit - 66558c8aa9d546289d58e8d8fc876f4ab52fa9a4
commit + 66ce938ebaa602aed50c9ed8f7db88b7b1755fe2
blob - c4725a9ecd19f3cc5192e1e9b814278f053891f5
blob + cc9fc7a65e6a88b303d359fb397c74379c176d13
--- sysutils/docker-cli/Makefile
+++ sysutils/docker-cli/Makefile
@@ -1,10 +1,8 @@
 COMMENT =  command-line tool for controlling Docker
 
-V =20.10.21
+V =25.0.3
 
-GH_ACCOUNT =   docker
-GH_PROJECT =   cli
-GH_TAGNAME =   v${V}
+DIST_TUPLE =   github docker cli v${V} .
 PKGNAME =  docker-${DISTNAME}
 
 CATEGORIES =   sysutils
@@ -17,10 +15,12 @@ PERMIT_PACKAGE =Yes
 WANTLIB += c pthread
 
 MODULES =  lang/go
-MODGO_LDFLAGS =-X 
github.com/docker/cli/cli/version.Version=${V}
-
 GO_PKGNAME =   github.com/docker/cli
+MODGO_LDFLAGS =-X ${GO_PKGNAME}/cli/version.Version=${V}
+
+RUN_DEPENDS =  sysutils/docker-buildx
+
 WRKSRC =   ${MODGO_WORKSPACE}/src/${GO_PKGNAME}
-ALL_TARGET =   github.com/docker/cli/cmd/docker
+ALL_TARGET =   ${GO_PKGNAME}/cmd/docker
 
 .include 
blob - 9c835ffc12989e7a07bfa7538b36290da8ad0ea2
blob + 9f519bbd3d439d882290ebd8ac8b708d5ff29a32
--- sysutils/docker-cli/distinfo
+++ sysutils/docker-cli/distinfo
@@ -1,2 +1,2 @@
-SHA256 (cli-20.10.21.tar.gz) = 8PYsocgOj9W54UDKZO8+ddx896KAQLPRCyYDBxKJRug=
-SIZE (cli-20.10.21.tar.gz) = 7633967
+SHA256 (docker-cli-v25.0.3.tar.gz) = 
BK0M6pkqZdsgyxsNv20c4yxwXOh53lGyIJX+jSgDCBU=
+SIZE (docker-cli-v25.0.3.tar.gz) = 6864551
blob - cbca5bf1121d9bb4edf7d9d22f05fa80131a3045 (mode 644)
blob + /dev/null
--- 
sysutils/docker-cli/patches/patch-vendor_github_com_containerd_containerd_content_local_store_unix_go
+++ /dev/null
@@ -1,9 +0,0 @@
-Index: vendor/github.com/containerd/containerd/content/local/store_unix.go
 vendor/github.com/containerd/containerd/content/local/store_unix.go.orig
-+++ vendor/github.com/containerd/containerd/content/local/store_unix.go
-@@ -1,4 +1,4 @@
--// +build linux solaris darwin freebsd netbsd
-+// +build linux solaris darwin freebsd netbsd openbsd
- 
- /*
-Copyright The containerd Authors.
blob - /dev/null
blob + 2adc78d29643bc58c8f93f0aa0872c9dad635e7b (mode 644)
--- /dev/null
+++ sysutils/docker-cli/patches/patch-cli-plugins_socket_socket_nodarwin_go
@@ -0,0 +1,20 @@
+Avoid keeping @docker_cli_[UUID] files
+https://github.com/docker/cli/pull/4862
+
+Index: cli-plugins/socket/socket_nodarwin.go
+--- cli-plugins/socket/socket_nodarwin.go.orig
 cli-plugins/socket/socket_nodarwin.go
+@@ -1,4 +1,4 @@
+-//go:build !darwin
++//go:build !darwin && !openbsd
+ 
+ package socket
+ 
+@@ -15,5 +15,6 @@ func listen(socketname string) (*net.UnixListener, err
+ 
+ func onAccept(conn *net.UnixConn, listener *net.UnixListener) {
+   // do nothing
+-  // while on darwin we would unlink here; on non-darwin the socket is 
abstract and not present on the filesystem
++  // while on darwin and OpenBSD we would unlink here;
++  // on non-darwin the socket is abstract and not present on the 
filesystem
+ }
blob - b66550e0750eefcb59425df2e32bfdd7f50d3030 (mode 644)
blob + /dev/null
--- 
sysutils/docker-cli/patches/patch-vendor_github_com_containerd_continuity_fs_stat_openbsd_go
+++ /dev/null
@@ -1,48 +0,0 @@
-Index: vendor/github.com/containerd/containerd/sys/stat_openbsd.go
 vendor/github.com/containerd/containerd/sys/stat_openbsd.go.orig
-+++ vendor/github.com/containerd/containerd/sys/stat_openbsd.go
-@@ -0,0 +1,44 @@
-+// +build openbsd
-+/*
-+   Copyright The containerd Authors.
-+
-+   Licensed under the Apache License, Version 2.0 (the "License");
-+   you may not use this file except in compliance with the License.
-+   You may obtain a copy of the License at
-+
-+   http://www.apache.org/licenses/LICENSE-2.0
-+
-+   Unless required by applicable law or agreed to in writing, software
-+   distributed under the License is distributed on an "AS IS" BASIS,
-+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-+   See the License for the specific language governing permissions and
-+   limitations under the License.
-+*/
-+
-+package sys
-+
-+import (
-+  "syscall"
-+  "time"
-+)
-+
-+// StatAtime returns the Atim
-+func StatAtime(st *syscall.Stat_t) syscall.Timespec {
-+  return st.Atim
-+}
-+
-+// StatCtime returns the Ctim
-+func StatCtime(st *syscall.Stat_t) syscall.Timespec {
-+  return st.Ctim
-+}
-+
-+// StatMtime returns the Mtim
-+func StatMtime(st *syscall.Stat_t) syscall.Timespec {
-+  return st.Mtim
-+}
-+
-+// StatATimeAsTime returns st.Atim as a time.Time
-+func StatATimeAsTime(st *syscall.Stat_t) time.Time {
-+  // The int64 conversions ensure the line compiles for 32-bit systems as 
well.
-+  return time.Unix(int64(st.Atim.Sec), int64(st.Atim.Nsec)) // nolint: 

Re: internal conflict between updatedb-0p0 and quirks-6.128

[Lucas Gabriel Vuotto]

On Wed, Feb 21, 2024 at 12:45:17PM +, Stuart Henderson wrote:
> Oh, you have old files in /usr/ports/packages, rm them.

Indeed, I had a quirks-6.128 in cache. Thanks Stu!

Re: internal conflict between updatedb-0p0 and quirks-6.128

[Lucas Gabriel Vuotto]

Forgot to tell my packages are up-to-date. I did run it again for good
meassure, still with no success. My ports tree is up-to-date (Git commit
f0a54ae35f82eebaf63789816ddb2a6acf4c09fd) and I'm using cdn.openbsd.org
for upstream.

Also worth noting, this only happens when trying to build the package.
If instead I install aarch64-none-elf-gcc directly, I don't get any
message:

darjeeling$ doas pkg_add aarch64-none-elf-gcc
quirks-7.5 signed on 2024-02-20T15:33:39Z
aarch64-none-elf-gcc-12.2.0p1:mpfr-4.2.1: ok
aarch64-none-elf-gcc-12.2.0p1:libmpc-1.1.0: ok
aarch64-none-elf-gcc-12.2.0p1:aarch64-none-elf-binutils-2.40: ok
aarch64-none-elf-gcc-12.2.0p1: ok

I tried also starting with an empty /usr/ports/pobj and
/usr/ports/distfiles, again with no success.

Lucas

On Wed, Feb 21, 2024 at 09:44:47AM +, Stuart Henderson wrote:
> Try pkg_add -u, that had usually cleared things up when I've seen this
> 
> -- 
>  Sent from a phone, apologies for poor formatting.
> 
> On 21 February 2024 04:17:30 Lucas Gabriel Vuotto  wrote:
> 
> > Hi ports@,
> > 
> > since last Saturday, I noticed a weird issue when I tried to prepare
> > u-boot-rk356x:
> > 
> > darjeeling$ make FETCH_PACKAGES=-Dsnap prepare
> > ===> u-boot-rk356x-2024.01 depends on: aarch64-none-elf-gcc-* - not found
> > ===>  Verifying install for aarch64-none-elf-gcc-* in 
> > devel/arm-none-eabi/gcc
> > ===>  Looking for aarch64-none-elf-gcc-12.2.0p1.tgz in $PKG_PATH -
> > updatedb-0p0 signed on 2024-02-20T15:35:22Z
> > quirks-7.5+updatedb-0p0->quirks-6.128+updatedb-0p0: internal conflict
> > between updatedb-0p0 and quirks-6.128
> > Couldn't find updates for quirks-7.5 updatedb-0p0
> > Couldn't install quirks-6.128 updatedb-0p0
> > not found
> > *** Error 1 in /usr/ports/devel/arm-none-eabi/gcc
> > (/usr/ports/infrastructure/mk/bsd.port.mk:2221
> > '/usr/ports/packages/amd64/cache/aarch64-none-elf-gcc-12.2.0p1.tgz')
> > ===> Building from scratch aarch64-none-elf-gcc-12.2.0p1
> > ^C
> > 
> > I don't know from where I'm getting that conflict between the old and
> > the new quirks. This problem still persist with a fresh snapshot:
> > 
> > kern.version=OpenBSD 7.5-beta (GENERIC.MP) #7: Tue Feb 20 11:09:18 MST 2024
> >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Problem persist after removing and reinstalling quirks and updatedb.
> > pkg_delete -a is run regularly, and running it didn't help. I have a
> > clean pkg_check too, and /var/db/pkg/ only shows the last versions of
> > both quirks and updatedb.
> > 
> > Any clues on where it comes from?
> > 
> > Lucas
> 

internal conflict between updatedb-0p0 and quirks-6.128

[Lucas Gabriel Vuotto]

Hi ports@,

since last Saturday, I noticed a weird issue when I tried to prepare
u-boot-rk356x:

darjeeling$ make FETCH_PACKAGES=-Dsnap prepare 
===> u-boot-rk356x-2024.01 depends on: aarch64-none-elf-gcc-* - not found
===>  Verifying install for aarch64-none-elf-gcc-* in devel/arm-none-eabi/gcc
===>  Looking for aarch64-none-elf-gcc-12.2.0p1.tgz in $PKG_PATH - updatedb-0p0 
signed on 2024-02-20T15:35:22Z
quirks-7.5+updatedb-0p0->quirks-6.128+updatedb-0p0: internal conflict between 
updatedb-0p0 and quirks-6.128
Couldn't find updates for quirks-7.5 updatedb-0p0
Couldn't install quirks-6.128 updatedb-0p0
not found
*** Error 1 in /usr/ports/devel/arm-none-eabi/gcc 
(/usr/ports/infrastructure/mk/bsd.port.mk:2221 
'/usr/ports/packages/amd64/cache/aarch64-none-elf-gcc-12.2.0p1.tgz')
===> Building from scratch aarch64-none-elf-gcc-12.2.0p1
^C

I don't know from where I'm getting that conflict between the old and
the new quirks. This problem still persist with a fresh snapshot:

kern.version=OpenBSD 7.5-beta (GENERIC.MP) #7: Tue Feb 20 11:09:18 MST 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Problem persist after removing and reinstalling quirks and updatedb.
pkg_delete -a is run regularly, and running it didn't help. I have a
clean pkg_check too, and /var/db/pkg/ only shows the last versions of
both quirks and updatedb.

Any clues on where it comes from?

Lucas

Re: sysutils/docker-cli: update to 25.0.3

[Lucas Gabriel Vuotto]

On Mon, Feb 12, 2024 at 11:10:37PM +0100, Kirill A. Korinsky wrote:
> Hi Lucas,
> 
> On Mon, 12 Feb 2024 18:53:26 +0100,
> Lucas Gabriel Vuotto wrote:
> > 
> > Based on the deprecation, I believe it makes a lot of sense to make
> > docker-buildx a RDEP of docker-cli.
> >
> 
> Agreed.
> 
> > Question: given that Docker names buildx and compose as plugins in their
> > docs, like `docker-{buildx,compose}-plugin`, would it make sense to also
> > name our packages like that?
> 
> I think that it is the right move for buildx, but not sure about compose.
> 
> Historically docker-compose was a standalone application, and current version
> can be run as docker plugin, and as standalone application.
> 
> Here I expect that user will try to install docker-compose as very common
> naming, and adding plugin may confuse.

I took a look at repology.org and `docker-buildx` and `docker-compose`
are the most common packages names, so I believe we won't gain much by
naming it `docker-buildx-plugin`. In fact, only a single package in
repology is called like that.

So, we agree for this latest version? buildx as an RDEP, no package name
changes.

Lucas


diff 66558c8aa9d546289d58e8d8fc876f4ab52fa9a4 
66ce938ebaa602aed50c9ed8f7db88b7b1755fe2
commit - 66558c8aa9d546289d58e8d8fc876f4ab52fa9a4
commit + 66ce938ebaa602aed50c9ed8f7db88b7b1755fe2
blob - c4725a9ecd19f3cc5192e1e9b814278f053891f5
blob + cc9fc7a65e6a88b303d359fb397c74379c176d13
--- sysutils/docker-cli/Makefile
+++ sysutils/docker-cli/Makefile
@@ -1,10 +1,8 @@
 COMMENT =  command-line tool for controlling Docker
 
-V =20.10.21
+V =25.0.3
 
-GH_ACCOUNT =   docker
-GH_PROJECT =   cli
-GH_TAGNAME =   v${V}
+DIST_TUPLE =   github docker cli v${V} .
 PKGNAME =  docker-${DISTNAME}
 
 CATEGORIES =   sysutils
@@ -17,10 +15,12 @@ PERMIT_PACKAGE =Yes
 WANTLIB += c pthread
 
 MODULES =  lang/go
-MODGO_LDFLAGS =-X 
github.com/docker/cli/cli/version.Version=${V}
-
 GO_PKGNAME =   github.com/docker/cli
+MODGO_LDFLAGS =-X ${GO_PKGNAME}/cli/version.Version=${V}
+
+RUN_DEPENDS =  sysutils/docker-buildx
+
 WRKSRC =   ${MODGO_WORKSPACE}/src/${GO_PKGNAME}
-ALL_TARGET =   github.com/docker/cli/cmd/docker
+ALL_TARGET =   ${GO_PKGNAME}/cmd/docker
 
 .include 
blob - 9c835ffc12989e7a07bfa7538b36290da8ad0ea2
blob + 9f519bbd3d439d882290ebd8ac8b708d5ff29a32
--- sysutils/docker-cli/distinfo
+++ sysutils/docker-cli/distinfo
@@ -1,2 +1,2 @@
-SHA256 (cli-20.10.21.tar.gz) = 8PYsocgOj9W54UDKZO8+ddx896KAQLPRCyYDBxKJRug=
-SIZE (cli-20.10.21.tar.gz) = 7633967
+SHA256 (docker-cli-v25.0.3.tar.gz) = 
BK0M6pkqZdsgyxsNv20c4yxwXOh53lGyIJX+jSgDCBU=
+SIZE (docker-cli-v25.0.3.tar.gz) = 6864551
blob - cbca5bf1121d9bb4edf7d9d22f05fa80131a3045 (mode 644)
blob + /dev/null
--- 
sysutils/docker-cli/patches/patch-vendor_github_com_containerd_containerd_content_local_store_unix_go
+++ /dev/null
@@ -1,9 +0,0 @@
-Index: vendor/github.com/containerd/containerd/content/local/store_unix.go
 vendor/github.com/containerd/containerd/content/local/store_unix.go.orig
-+++ vendor/github.com/containerd/containerd/content/local/store_unix.go
-@@ -1,4 +1,4 @@
--// +build linux solaris darwin freebsd netbsd
-+// +build linux solaris darwin freebsd netbsd openbsd
- 
- /*
-Copyright The containerd Authors.
blob - /dev/null
blob + 2adc78d29643bc58c8f93f0aa0872c9dad635e7b (mode 644)
--- /dev/null
+++ sysutils/docker-cli/patches/patch-cli-plugins_socket_socket_nodarwin_go
@@ -0,0 +1,20 @@
+Avoid keeping @docker_cli_[UUID] files
+https://github.com/docker/cli/pull/4862
+
+Index: cli-plugins/socket/socket_nodarwin.go
+--- cli-plugins/socket/socket_nodarwin.go.orig
 cli-plugins/socket/socket_nodarwin.go
+@@ -1,4 +1,4 @@
+-//go:build !darwin
++//go:build !darwin && !openbsd
+ 
+ package socket
+ 
+@@ -15,5 +15,6 @@ func listen(socketname string) (*net.UnixListener, err
+ 
+ func onAccept(conn *net.UnixConn, listener *net.UnixListener) {
+   // do nothing
+-  // while on darwin we would unlink here; on non-darwin the socket is 
abstract and not present on the filesystem
++  // while on darwin and OpenBSD we would unlink here;
++  // on non-darwin the socket is abstract and not present on the 
filesystem
+ }
blob - b66550e0750eefcb59425df2e32bfdd7f50d3030 (mode 644)
blob + /dev/null
--- 
sysutils/docker-cli/patches/patch-vendor_github_com_containerd_continuity_fs_stat_openbsd_go
+++ /dev/null
@@ -1,48 +0,0 @@
-Index: vendor/github.com/containerd/containerd/sys/stat_openbsd.go
 vendor/github.com/containerd/containerd/sys/stat_openbsd.go.orig
-+++ vendor/github.com/containerd/containerd/sys/stat_openbsd.go
-@@ -0,0 +1,44 @@
-+// +build openbsd
-+/*
-+   Copyright The containerd Authors.
-+
-+   Licensed under 

Re: sysutils/docker-cli: update to 25.0.3

[Lucas Gabriel Vuotto]

Hi Kyrill, Omar,

Got around to test all the ports and they work great. Thanks for taking
the time for porting docker-compose too. I wanted to do that for some
time already.

Based on the deprecation, I believe it makes a lot of sense to make
docker-buildx a RDEP of docker-cli.

The versions aren't being reported properly:

darjeeling$ docker buildx version
github.com/docker/buildx v0.0.0+unknown 
darjeeling$ docker compose version
Docker Compose version dev

After the patch:

darjeeling$ docker buildx version
github.com/docker/buildx v0.12.1 
darjeeling$ docker compose version
Docker Compose version v2.24.5

The following patch is on top of your latest docker-cli diff + your
docker-compose tarball + Omar's docker-buildx tarball. I'm also
attaching the full diff from master + the two tarballs, to ease testing.
I reused GO_PKGNAME in a bunch of places where it made sense. I had to
add a /v2 to compose's GO_PKGNAME to make it pick up the version var
in MODGO_LDFLAGS. Also I synced the new patches to the merge PR, and
added a comment referencing it, to make it easier to drop them after
release 26.

Kyrill, it seems that your email editor is mangling the diffs by
removing the dangling whitespaces from the diff sections, which are
significant. Had to your email for the patches to apply.

Question: given that Docker names buildx and compose as plugins in their
docs, like `docker-{buildx,compose}-plugin`, would it make sense to also
name our packages like that?

Again, thanks a lot Kyrill.

Lucas


diff a1fb6ae15ae11fe8e2a81efd5dcd8004a9d1790f 
66ce938ebaa602aed50c9ed8f7db88b7b1755fe2
commit - a1fb6ae15ae11fe8e2a81efd5dcd8004a9d1790f
commit + 66ce938ebaa602aed50c9ed8f7db88b7b1755fe2
blob - 32b8236b3f6f4f6f485096cd4187ed44d95666b3
blob + 5a6d65b620cb0b200c5bea36560f3f8235fd7f4b
--- sysutils/docker-buildx/Makefile
+++ sysutils/docker-buildx/Makefile
@@ -14,11 +14,12 @@ PERMIT_PACKAGE =Yes
 WANTLIB += c pthread
 
 MODULES =  lang/go
-MODGO_GOPATH = ${MODGO_WORKSPACE}
-
 GO_PKGNAME =   github.com/docker/buildx
+MODGO_GOPATH = ${MODGO_WORKSPACE}
+MODGO_LDFLAGS =-X ${GO_PKGNAME}/version.Version=v${V}
+
 WRKSRC =   ${MODGO_WORKSPACE}/src/${GO_PKGNAME}
-ALL_TARGET =   github.com/docker/buildx/cmd/buildx
+ALL_TARGET =   ${GO_PKGNAME}/cmd/buildx
 
 do-install:
${INSTALL_PROGRAM_DIR} ${PREFIX}/libexec/docker/cli-plugins
blob - 31a3c19b77c73cfe651363928e45e40074f3adaf
blob + cc9fc7a65e6a88b303d359fb397c74379c176d13
--- sysutils/docker-cli/Makefile
+++ sysutils/docker-cli/Makefile
@@ -15,10 +15,12 @@ PERMIT_PACKAGE =Yes
 WANTLIB += c pthread
 
 MODULES =  lang/go
-MODGO_LDFLAGS =-X 
github.com/docker/cli/cli/version.Version=${V}
-
 GO_PKGNAME =   github.com/docker/cli
+MODGO_LDFLAGS =-X ${GO_PKGNAME}/cli/version.Version=${V}
+
+RUN_DEPENDS =  sysutils/docker-buildx
+
 WRKSRC =   ${MODGO_WORKSPACE}/src/${GO_PKGNAME}
-ALL_TARGET =   github.com/docker/cli/cmd/docker
+ALL_TARGET =   ${GO_PKGNAME}/cmd/docker
 
 .include 
blob - fea591aa4c776bea61b82c027f98be16da7357e1
blob + 2adc78d29643bc58c8f93f0aa0872c9dad635e7b
--- sysutils/docker-cli/patches/patch-cli-plugins_socket_socket_nodarwin_go
+++ sysutils/docker-cli/patches/patch-cli-plugins_socket_socket_nodarwin_go
@@ -1,9 +1,20 @@
+Avoid keeping @docker_cli_[UUID] files
+https://github.com/docker/cli/pull/4862
+
 Index: cli-plugins/socket/socket_nodarwin.go
 --- cli-plugins/socket/socket_nodarwin.go.orig
 +++ cli-plugins/socket/socket_nodarwin.go
 @@ -1,4 +1,4 @@
 -//go:build !darwin
 +//go:build !darwin && !openbsd
-
+ 
  package socket
-
+ 
+@@ -15,5 +15,6 @@ func listen(socketname string) (*net.UnixListener, err
+ 
+ func onAccept(conn *net.UnixConn, listener *net.UnixListener) {
+   // do nothing
+-  // while on darwin we would unlink here; on non-darwin the socket is 
abstract and not present on the filesystem
++  // while on darwin and OpenBSD we would unlink here;
++  // on non-darwin the socket is abstract and not present on the 
filesystem
+ }
blob - 91132289909ced7ecd733e9162bfd452401eab72
blob + c6229f2c218cd497de722b11b11c786c23c5d983
--- sysutils/docker-cli/patches/patch-cli-plugins_socket_socket_openbsd_go
+++ sysutils/docker-cli/patches/patch-cli-plugins_socket_socket_openbsd_go
@@ -1,3 +1,6 @@
+Avoid keeping @docker_cli_[UUID] files
+https://github.com/docker/cli/pull/4862
+
 Index: cli-plugins/socket/socket_openbsd.go
 --- cli-plugins/socket/socket_openbsd.go.orig
 +++ cli-plugins/socket/socket_openbsd.go
blob - a131cbf3c7aafe96f6386f7d9e0364c254f2737f
blob + f9b66effe39f7ef59a267a9925a396b7df0f184d
--- sysutils/docker-compose/Makefile
+++ sysutils/docker-compose/Makefile
@@ -18,12 +18,12 @@ PERMIT_PACKAGE =Yes
 WANTLIB += c pthread
 
 MODULES = 

Re: node_exporter vs syscall(2) removal

[Lucas Gabriel Vuotto]

Bumping sthen@ version.


diff 0897d281ca8fb751c1244e4656dbb7b3c401cdfa 
5c3506b9909b5fe2a23c821ef12030b7c422
commit - 0897d281ca8fb751c1244e4656dbb7b3c401cdfa
commit + 5c3506b9909b5fe2a23c821ef12030b7c422
blob - f2926a220810d15825049f192edcb3cb44016426
blob + 98bbf7e2f275914df615c34fb1369def4e21820b
--- sysutils/node_exporter/Makefile
+++ sysutils/node_exporter/Makefile
@@ -2,6 +2,7 @@ COMMENT =   prometheus exporter for hardware and OS 
met
 
 MODGO_MODNAME =github.com/prometheus/node_exporter
 MODGO_VERSION =v1.7.0
+REVISION = 0
 
 DISTNAME = node_exporter-${MODGO_VERSION}
 
@@ -32,5 +33,7 @@ do-install:
${INSTALL_DATA} ${WRKSRC}/NOTICE ${PREFIX}/share/doc/node_exporter/
 
 .include "modules.inc"
+# updated from upstream's old version, also see patches
+MODGO_MODULES +=   golang.org/x/sysv0.15.0
 
 .include 
blob - 1d1fa1ecd4108e9f29cf31c867727c30d30d7ee1
blob + 15b01334bb995abb636809b205dea84ea5f032e3
--- sysutils/node_exporter/distinfo
+++ sysutils/node_exporter/distinfo
@@ -188,6 +188,8 @@ SHA256 (go_modules/golang.org/x/sys/@v/v0.11.0.mod) = 
 SHA256 (go_modules/golang.org/x/sys/@v/v0.12.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.13.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.13.0.zip) = 
PRSa/Jk5mANUN0wNR0Ydzb0dOYDrL3fmAwSyP+5vPTc=
+SHA256 (go_modules/golang.org/x/sys/@v/v0.15.0.mod) = 
0iezJfYh9OvijTm6dz6pm4cPOTt8CcNFksNlsW3VYN4=
+SHA256 (go_modules/golang.org/x/sys/@v/v0.15.0.zip) = 
hhLrQWxznDsEzkjcvmVjLG+8QnAx/Zgcrs7sZBDR4fw=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.2.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.5.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.6.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
@@ -430,6 +432,8 @@ SIZE (go_modules/golang.org/x/sys/@v/v0.11.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.12.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.13.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.13.0.zip) = 1901653
+SIZE (go_modules/golang.org/x/sys/@v/v0.15.0.mod) = 33
+SIZE (go_modules/golang.org/x/sys/@v/v0.15.0.zip) = 1901954
 SIZE (go_modules/golang.org/x/sys/@v/v0.2.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.5.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.6.0.mod) = 33
blob - /dev/null
blob + 10abf28436ff539cd5077891799a4e0f22edd162 (mode 644)
--- /dev/null
+++ sysutils/node_exporter/patches/patch-go_mod
@@ -0,0 +1,15 @@
+Update golang.org/x/sys to v0.15.0
+https://github.com/prometheus/node_exporter/pull/2863
+
+Index: go.mod
+--- go.mod.orig
 go.mod
+@@ -29,7 +29,7 @@ require (
+   github.com/prometheus/procfs v0.12.0
+   github.com/safchain/ethtool v0.3.0
+   golang.org/x/exp v0.0.0-20230522175609-2e198f4a06a1
+-  golang.org/x/sys v0.13.0
++  golang.org/x/sys v0.15.0
+   howett.net/plist v1.0.0
+ )
+ 
blob - /dev/null
blob + 1fa7ef309842bbdb261f4ee0b84218f5bfdae33a (mode 644)
--- /dev/null
+++ sysutils/node_exporter/patches/patch-go_sum
@@ -0,0 +1,17 @@
+Update golang.org/x/sys to v0.15.0
+https://github.com/prometheus/node_exporter/pull/2863
+
+Index: go.sum
+--- go.sum.orig
 go.sum
+@@ -142,8 +142,8 @@ golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5
+ golang.org/x/sys v0.8.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+ golang.org/x/sys v0.9.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+ golang.org/x/sys v0.10.0/go.mod 
h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+-golang.org/x/sys v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=
+-golang.org/x/sys v0.13.0/go.mod 
h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
++golang.org/x/sys v0.15.0 h1:h48lPFYpsTvQJZF4EKyI4aLHaev3CxivZmv7yZig9pc=
++golang.org/x/sys v0.15.0/go.mod 
h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
+ golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod 
h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
+ golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod 
h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8=
+ golang.org/x/term v0.5.0/go.mod 
h1:jMB1sMXY+tzblOD4FWmEbocvup2/aLOaQEp7JmGp78k=

Re: sysutils/docker-cli: update to 25.0.3

[Lucas Gabriel Vuotto]

On Wed, Feb 07, 2024 at 07:20:14PM +0100, Kirill A. Korinsky wrote:
> On Wed, 07 Feb 2024 03:42:08 +0100,
> Lucas Gabriel Vuotto wrote:
> > 
> > There are some differences between Dockerfile handling between the two,
> > which also breaks stuff that currently works (`COPY . .` works with
> > buildx, while it bails out with "When using COPY with more than one
> > source file, the destination must be a directory and end with a /"
> > without it).
> > 
> > I might take a further look during the week.
> > 
> 
> Well, it seems like a kind of progress from Docker Inc.
> 
> An another way is adding podman-remote into ports which should support old 
> way,
> or at least I feel so after reading 
> https://github.com/containers/podman/issues/20975

Release 23 [0] made buildx a separate project, [1]. It also made the
legacy (non-buildx) builder deprecated. I believe that buildx should
also be packaged in order to keep Docker CLI 23+.

I'm not super sure that the patches aren't required anymore; more like
thay aren't _needed_ anymore because the patched files are gone. Haven't
made a complete analysis of the repo, but I did find [2] which uses
syscall, which doesn't work in -current. Some deeper look is required.

I'll try to port buildx during the weekend.

Lucas

[0]: https://docs.docker.com/engine/release-notes/23.0/
[1]: https://github.com/docker/buildx
[2]: 
/usr/ports/pobj/docker-cli-25.0.3/go/src/github.com/docker/cli/vendor/github.com/docker/docker/pkg/system/stat_unix.go

Re: sysutils/docker-cli: update to 25.0.3

[Lucas Gabriel Vuotto]

Hi,

I gave this a very quick spin and I think there is something missing:
buildx isn't used anymore, and a `docker build` is greeted with

DEPRECATED: The legacy builder is deprecated and will be removed in a future 
release.
Install the buildx component to build images with BuildKit:
https://docs.docker.com/go/buildx/

There are some differences between Dockerfile handling between the two,
which also breaks stuff that currently works (`COPY . .` works with
buildx, while it bails out with "When using COPY with more than one
source file, the destination must be a directory and end with a /"
without it).

I might take a further look during the week.

Lucas

On Wed, Feb 07, 2024 at 03:21:42AM +0100, Kirill A. Korinsky wrote:
> Tested with remote podman.
> 
> All patches aren't required anymore.
> 
> -- 
> wbr, Kirill

node_exporter vs syscall(2) removal

[Lucas Gabriel Vuotto]

Hi ports, Claudio,

I noticed my for some time already that my -current node_exporters were
returning no data for node_filesystem_* metrics. There has been a PR [0]
that updates x/sys dep to a version that doesn't issue direct syscalls.
I backported it, given that node_exporter releases are quite sporadic.

I think it's one of my first times working with a Go port, and I'm not
super about sure what I did. Even with the patched go.mod, I couldn't
make modgo-gen-modules include x/sys v0.15.0 in the output. I don't know
if there is a better approach.

arm64 is happy, IBT amd64 is happy, non-IBT amd64 is happy.

Lucas

[0]: https://github.com/prometheus/node_exporter/pull/2863


diff /usr/ports
commit - a3b92e22af6789ff442dcf57773c1bb5b261ba96
path + /usr/ports
blob - f2926a220810d15825049f192edcb3cb44016426
file + sysutils/node_exporter/Makefile
--- sysutils/node_exporter/Makefile
+++ sysutils/node_exporter/Makefile
@@ -2,6 +2,7 @@ COMMENT =   prometheus exporter for hardware and OS 
met
 
 MODGO_MODNAME =github.com/prometheus/node_exporter
 MODGO_VERSION =v1.7.0
+REVISION = 0
 
 DISTNAME = node_exporter-${MODGO_VERSION}
 
@@ -32,5 +33,6 @@ do-install:
${INSTALL_DATA} ${WRKSRC}/NOTICE ${PREFIX}/share/doc/node_exporter/
 
 .include "modules.inc"
+MODGO_MODULES +=   golang.org/x/sysv0.15.0
 
 .include 
blob - 1d1fa1ecd4108e9f29cf31c867727c30d30d7ee1
file + sysutils/node_exporter/distinfo
--- sysutils/node_exporter/distinfo
+++ sysutils/node_exporter/distinfo
@@ -188,6 +188,8 @@ SHA256 (go_modules/golang.org/x/sys/@v/v0.11.0.mod) = 
 SHA256 (go_modules/golang.org/x/sys/@v/v0.12.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.13.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.13.0.zip) = 
PRSa/Jk5mANUN0wNR0Ydzb0dOYDrL3fmAwSyP+5vPTc=
+SHA256 (go_modules/golang.org/x/sys/@v/v0.15.0.mod) = 
0iezJfYh9OvijTm6dz6pm4cPOTt8CcNFksNlsW3VYN4=
+SHA256 (go_modules/golang.org/x/sys/@v/v0.15.0.zip) = 
hhLrQWxznDsEzkjcvmVjLG+8QnAx/Zgcrs7sZBDR4fw=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.2.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.5.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
 SHA256 (go_modules/golang.org/x/sys/@v/v0.6.0.mod) = 
8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
@@ -430,6 +432,8 @@ SIZE (go_modules/golang.org/x/sys/@v/v0.11.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.12.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.13.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.13.0.zip) = 1901653
+SIZE (go_modules/golang.org/x/sys/@v/v0.15.0.mod) = 33
+SIZE (go_modules/golang.org/x/sys/@v/v0.15.0.zip) = 1901954
 SIZE (go_modules/golang.org/x/sys/@v/v0.2.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.5.0.mod) = 33
 SIZE (go_modules/golang.org/x/sys/@v/v0.6.0.mod) = 33
blob - /dev/null
file + sysutils/node_exporter/patches/patch-go_mod (mode 644)
--- /dev/null
+++ sysutils/node_exporter/patches/patch-go_mod
@@ -0,0 +1,15 @@
+Update golang.org/x/sys to v0.15.0
+https://github.com/prometheus/node_exporter/pull/2863
+
+Index: go.mod
+--- go.mod.orig
 go.mod
+@@ -29,7 +29,7 @@ require (
+   github.com/prometheus/procfs v0.12.0
+   github.com/safchain/ethtool v0.3.0
+   golang.org/x/exp v0.0.0-20230522175609-2e198f4a06a1
+-  golang.org/x/sys v0.13.0
++  golang.org/x/sys v0.15.0
+   howett.net/plist v1.0.0
+ )
+ 
blob - /dev/null
file + sysutils/node_exporter/patches/patch-go_sum (mode 644)
--- /dev/null
+++ sysutils/node_exporter/patches/patch-go_sum
@@ -0,0 +1,17 @@
+Update golang.org/x/sys to v0.15.0
+https://github.com/prometheus/node_exporter/pull/2863
+
+Index: go.sum
+--- go.sum.orig
 go.sum
+@@ -142,8 +142,8 @@ golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5
+ golang.org/x/sys v0.8.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+ golang.org/x/sys v0.9.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+ golang.org/x/sys v0.10.0/go.mod 
h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+-golang.org/x/sys v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=
+-golang.org/x/sys v0.13.0/go.mod 
h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
++golang.org/x/sys v0.15.0 h1:h48lPFYpsTvQJZF4EKyI4aLHaev3CxivZmv7yZig9pc=
++golang.org/x/sys v0.15.0/go.mod 
h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
+ golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod 
h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
+ golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod 
h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8=
+ golang.org/x/term v0.5.0/go.mod 
h1:jMB1sMXY+tzblOD4FWmEbocvup2/aLOaQEp7JmGp78k=

Re: upcoming split of quirks

[Lucas Gabriel Vuotto]

Adding ports@.

On Sat, Jan 20, 2024 at 01:15:10AM +0100, Marc Espie wrote:
> > Can't install quirks-6.206->7.0: can't resolve updatedb-0p0
> > Can't find updatedb-0p0
> > quirks-7.0 signed on 2024-01-19T16:21:04Z
> > Couldn't find updates for blis-0.9.0 ghdl-3.0.0 quirks-6.206
> > Couldn't install quirks-7.0 updatedb-0p0
> 
> looks like a "feed  issue" like your upstream doesn't have
> updatedb-0.
> 
> > So, is this missing updatedb-0p0 actually a problem?  Or is there
> > an imminent change coming?
> 
> Yes, it is (but a minor one)
> I have zero idea how your mirror carries a recent quirks but no
> updatedb.
> 
> The "minor one" part is that having no updatedb around means you
> can't cache update information for pkg_add -U which makes the process
> roughly 10 times slower.

I see this same thing in my -currents. All of them point to
cdn.openbsd.org. I swapped one of them to ftp.openbsd.org and also got
the same error:


darjeeling$ sysctl -n kern.version
OpenBSD 7.4-current (GENERIC.MP) #1612: Fri Jan 19 17:50:01 MST 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
darjeeling$ doas pkg_add -u
quirks-7.0 signed on 2024-01-19T16:21:04Z
Couldn't find updates for updatedb-0

nuc$ sysctl -n kern.version
OpenBSD 7.4-current (GENERIC.MP) #1612: Fri Jan 19 17:50:01 MST 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
nuc$ doas pkg_add -u
quirks-7.0 signed on 2024-01-19T16:21:04Z
Couldn't find updates for updatedb-0

moon$ sysctl -n kern.version   
OpenBSD 7.4-current (GENERIC) #1512: Fri Jan 19 17:38:46 MST 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

moon$ doas pkg_add -u
Can't find updatedb-0p0
quirks-7.0 signed on 2024-01-19T16:21:04Z
Can't install quirks-6.206->7.0: can't resolve updatedb-0p0
Couldn't find updates for quirks-6.206
Couldn't install quirks-7.0 updatedb-0p0


Tried both {cdn,ftp}.openbsd.org in darjeeling, only cdn in nuc and
moon. (I have no clue why despite being the same mirror I have different
kernel for moon and the rest--they were all upgraded in the last 6
hours)

The other thing that darjeeling, nuc and moon have in common is that
they all are amd64. I happen to have a -current arm64 server:


kaguya$ sysctl -n kern.version 
OpenBSD 7.4-current (GENERIC.MP) #51: Fri Jan 19 21:58:53 MST 2024
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
kaguya$ doas pkg_add -u
quirks-7.0 signed on 2024-01-18T10:27:32Z
kaguya$ pkg_info | grep -e ^quirks -e ^update  
quirks-7.0  exceptions to pkg_add rules
updatedb-0p0pkg_add speed up cache


kaguya also points to cdn.openbsd.org.

Lucas

HAProxy and HTTP/3

[Lucas Gabriel Vuotto]

Hi ports@,

did anybody succeed at serving HTTP/3 traffic with HAProxy? It should be
supported since 2.8, but I can't make it work: `curl --http3-only` gets
stuck and usually ends with

curl: (55) ngtcp2_conn_writev_stream returned error: ERR_DRAINING

It does work against https://http3.is, https://cloudflare.com and
others.

I'm trying with the following config, which does work for HTTP/1.1 and
HTTP/2:


global
log 127.0.0.1 local0 debug
maxconn 1024
chroot /var/haproxy
user _haproxy
group _haproxy
daemon
pidfile /var/run/haproxy.pid

ssl-default-bind-options ssl-min-ver TLSv1.2
ssl-load-extra-del-ext

defaults
log global
mode http
option httplog
option dontlognull
option redispatch
retries 3
maxconn 2000
timeout connect 5s
timeout client 65s
timeout server 5s

frontend haproxy
bind ipv4@:80,ipv6@:80
bind ipv4@:443,ipv6@:443 ssl crt /etc/haproxy/certs/
bind quic4@:443,quic6@:443 ssl crt /etc/haproxy/certs/

option forwardfor

acl acme-challenge path_beg /.well-known/acme-challenge/
acl ntfy req.hdr(host) -i ntfy.example.com
acl grafana req.hdr(host) -i grafana.example.com

http-request redirect scheme https unless { ssl_fc } || acme-challenge
http-after-response add-header alt-svc 'h3=":443"; ma=900;'

use_backend httpd if acme-challenge
use_backend ntfy_ws if ntfy { path_end /ws }
use_backend ntfy if ntfy
use_backend grafana if grafana
default_backend httpd

backend httpd
server s1 127.0.0.1:8080 check

backend ntfy_ws
option httpchk /v1/health
option http-server-close
timeout tunnel 10m
server s1 127.0.0.1:3010 check

backend ntfy
option httpchk /v1/health
server s1 127.0.0.1:3010 check

backend grafana
option httpchk /api/health
server s1 127.0.0.1:3000 check


Adding an alpn directive to bind lines makes no difference, and
according to the docs, the "normal" binds get an `alpn h2,http1.1` while
the quic binds get an `alpn h3` by default.

tcpdump shows that there is some handshakes attempts between client and
server, and so does the stats socket of HAProxy:


> show quic full
* 0xd10d64000[00]: scid=4f5f572ad85655a9 
dcid=4559862ad37160765abf2b2082ad0e624fe59237
  loc. TPs: odcid=5cf7472f2d706253c37792abe48c49eea466ffd1 
iscid=4f5f572ad85655a9
midle_timeout=3ms mudp_payload_sz=2048 ack_delay_exp=3 mack_delay=25ms 
act_cid_limit=8
md=1687140 msd_bidi_l=16380 msd_bidi_r=16380 msd_uni=16380 ms_bidi=100 
ms_uni=3
(no_act_migr,stless_rst_tok)
  rem. TPs: iscid=4559862ad37160765abf2b2082ad0e624fe59237
midle_timeout=12ms mudp_payload_sz=65527 ack_delay_exp=3 
mack_delay=25ms act_cid_limit=2
md=1310720 msd_bidi_l=131072 msd_bidi_r=131072 msd_uni=131072 
ms_bidi=262144 ms_uni=262144
versions:chosen=0x0001,negotiated=0x0001
  st=handshakemux=null  expire=24s
  fd=-1   local_addr=128.140.63.137:443 
foreign_addr=5.161.47.47:56773
  [initl] rx.ackrng=1  tx.inflight=0[hndshk] 
rx.ackrng=0  tx.inflight=9877
  [01rtt] rx.ackrng=0  tx.inflight=0
  srtt=274  rttvar=137  rttmin=274  ptoc=3cwnd=12707  mcwnd=12707  
sentpkts=11 lostpkts=0


> show quic full
* 0xd10d64000[00]: scid=4f5f572ad85655a9 
dcid=4559862ad37160765abf2b2082ad0e624fe59237
  loc. TPs: odcid=5cf7472f2d706253c37792abe48c49eea466ffd1 
iscid=4f5f572ad85655a9
midle_timeout=3ms mudp_payload_sz=2048 ack_delay_exp=3 mack_delay=25ms 
act_cid_limit=8
md=1687140 msd_bidi_l=16380 msd_bidi_r=16380 msd_uni=16380 ms_bidi=100 
ms_uni=3
(no_act_migr,stless_rst_tok)
  rem. TPs: iscid=4559862ad37160765abf2b2082ad0e624fe59237
midle_timeout=12ms mudp_payload_sz=65527 ack_delay_exp=3 
mack_delay=25ms act_cid_limit=2
md=1310720 msd_bidi_l=131072 msd_bidi_r=131072 msd_uni=131072 
ms_bidi=262144 ms_uni=262144
versions:chosen=0x0001,negotiated=0x0001
  st=handshakemux=null  expire=10s
  fd=-1   local_addr=128.140.63.137:443 
foreign_addr=5.161.47.47:56773
  [initl] rx.ackrng=1  tx.inflight=0[hndshk] 
rx.ackrng=0  tx.inflight=14137
  [01rtt] rx.ackrng=0  tx.inflight=0
  srtt=274  rttvar=137  rttmin=274  ptoc=5cwnd=12707  mcwnd=12707  
sentpkts=15 lostpkts=0


> show quic full
* 0xd10d64000[00]: scid=4f5f572ad85655a9 
dcid=4559862ad37160765abf2b2082ad0e624fe59237
  loc. TPs: odcid=5cf7472f2d706253c37792abe48c49eea466ffd1 
iscid=4f5f572ad85655a9
midle_timeout=3ms mudp_payload_sz=2048 ack_delay_exp=3 mack_delay=25ms 
act_cid_limit=8
md=1687140 msd_bidi_l=16380 m

Re: boost futex diff

[Lucas Gabriel Vuotto]

On Sun, Dec 24, 2023 at 06:18:03AM +0100, Theo Buehler wrote:
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/boost/Makefile,v
> diff -u -p -r1.140 Makefile
> --- Makefile  24 Dec 2023 00:26:12 -  1.140
> +++ Makefile  24 Dec 2023 04:57:15 -
> @@ -11,8 +11,8 @@ COMMENT-md= machine-dependent libraries 
>  VERSION= 1.84.0
>  DISTNAME=boost_${VERSION:S/./_/g}
>  PKGNAME= boost-${VERSION}
> -REVISION=0
> -EPOCH =  0
> +REVISION=1
> +EPOCH=   0
>  CATEGORIES=  devel
>  SITES=   
> https://boostorg.jfrog.io/artifactory/main/release/${VERSION}/source/
>  EXTRACT_SUFX=.tar.bz2
> @@ -151,7 +151,7 @@ do-install:
>   ${INSTALL_DATA_DIR} ${PREFIX}/include/boost
>   ${INSTALL_DATA} ${WRKSRC}/stage/lib/lib!(*.so) ${PREFIX}/lib
>   cd ${WRKSRC}/boost && \
> - pax -rw -s ':^.*\.orig$$::' . ${PREFIX}/include/boost
> + pax -rw -s ':^.*${PATCHORIG}$$::' . ${PREFIX}/include/boost
>   find ${PREFIX}/include/boost -type d -exec chmod ${DIRMODE} {} +
>   find ${PREFIX}/include/boost -type f -exec chmod ${SHAREMODE} {} +
>   # boost-build:
> @@ -159,11 +159,11 @@ do-install:
>   ${PREFIX}/bin
>   ${INSTALL_DATA_DIR} ${PREFIX}/share/b2
>   @cd ${WRKSRC}/tools/build/src && \
> - pax -r -w -p pm -s ':^./engine.*$$::' -s ':^.*\.orig$$::' . \
> + pax -r -w -p pm -s ':^./engine.*$$::' -s ':^.*${PATCHORIG}$$::' 
> . \
>   ${PREFIX}/share/b2
>   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/b2
>   @cd ${WRKSRC}/tools/build/example && \
> - pax -r -w -p pm -s ':^.*\.orig$$::' . \
> + pax -r -w -p pm -s ':^.*${PATCHORIG}$$::' . \
>   ${PREFIX}/share/examples/b2
>  
>  .include 

Shouldn't those "${PATCHORIG}" be replaced by "\.orig\.port"? It isn't
an issue right now: "find $(make show=WRKSRC) -name '*?orig?port'"
only returns the files actually ending in ${PATCHORIG} and I guess that
if it actually becomes an issue in here, that also means that PATCHORIG
should have been changed before.

Re: UPDATE databases/victoriametrics from MAINTAINER

[Lucas Gabriel Vuotto]

On Tue, Nov 28, 2023 at 07:25:18PM +0100, Denis Fondras wrote:
> Le Tue, Nov 28, 2023 at 01:04:12PM +0000, Lucas Gabriel Vuotto a écrit :
> > Hi ports,
> > 
> > Update VictoriaMetrics to latest LTS, 1.93.8. A bunch of bugfixes in it,
> > enumerated at
> > 
> > - 
> > https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v1936
> > - 
> > https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v1937
> > - 
> > https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v1938
> > 
> > Runs fine in my single-node small deployment on arm64, with vmetrics and
> > vmetricsalert.
> > 
> 
> OK denis@

bump.


diff refs/heads/master refs/heads/victoriametrics-1.93.8
commit - 24e31a437db799ac2d1939e75cec232b8b1b546b
commit + c08f64b7fa5cdef1557d1870209868a13e66a53d
blob - eee970c488026ace06dbf30e50e07e644930e8a4
blob + c0e967a6992a9749baf6c45c8863e679ea88448d
--- databases/victoriametrics/Makefile
+++ databases/victoriametrics/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  fast, cost-effective and scalable time series database
 
-V =1.93.5
+V =1.93.8
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
blob - 2d76766dd1869ed46add6718c82de5ac43f25e04
blob + 0f9536f8f28e04c13add7c75d6e7558ad5faa788
--- databases/victoriametrics/distinfo
+++ databases/victoriametrics/distinfo
@@ -1,2 +1,2 @@
-SHA256 (VictoriaMetrics-VictoriaMetrics-v1.93.5.tar.gz) = 
DhpwbPR6u17OVR9maMJ4c60UFJqfmFGDLhMY9f1GzOQ=
-SIZE (VictoriaMetrics-VictoriaMetrics-v1.93.5.tar.gz) = 59986043
+SHA256 (VictoriaMetrics-VictoriaMetrics-v1.93.8.tar.gz) = 
2xhz27GANxjyx3WIoaUgprZyHj0KdknS+AkwNdIZyKQ=
+SIZE (VictoriaMetrics-VictoriaMetrics-v1.93.8.tar.gz) = 59823574

UPDATE databases/victoriametrics from MAINTAINER

[Lucas Gabriel Vuotto]

Hi ports,

Update VictoriaMetrics to latest LTS, 1.93.8. A bunch of bugfixes in it,
enumerated at

- 
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v1936
- 
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v1937
- 
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/CHANGELOG.md#v1938

Runs fine in my single-node small deployment on arm64, with vmetrics and
vmetricsalert.

Lucas


diff refs/heads/master refs/heads/victoriametrics-1.93.8
commit - 24e31a437db799ac2d1939e75cec232b8b1b546b
commit + c08f64b7fa5cdef1557d1870209868a13e66a53d
blob - eee970c488026ace06dbf30e50e07e644930e8a4
blob + c0e967a6992a9749baf6c45c8863e679ea88448d
--- databases/victoriametrics/Makefile
+++ databases/victoriametrics/Makefile
@@ -1,6 +1,6 @@
 COMMENT =  fast, cost-effective and scalable time series database
 
-V =1.93.5
+V =1.93.8
 
 DIST_TUPLE +=  github VictoriaMetrics VictoriaMetrics v${V} . # Apache 
License 2.0
 
blob - 2d76766dd1869ed46add6718c82de5ac43f25e04
blob + 0f9536f8f28e04c13add7c75d6e7558ad5faa788
--- databases/victoriametrics/distinfo
+++ databases/victoriametrics/distinfo
@@ -1,2 +1,2 @@
-SHA256 (VictoriaMetrics-VictoriaMetrics-v1.93.5.tar.gz) = 
DhpwbPR6u17OVR9maMJ4c60UFJqfmFGDLhMY9f1GzOQ=
-SIZE (VictoriaMetrics-VictoriaMetrics-v1.93.5.tar.gz) = 59986043
+SHA256 (VictoriaMetrics-VictoriaMetrics-v1.93.8.tar.gz) = 
2xhz27GANxjyx3WIoaUgprZyHj0KdknS+AkwNdIZyKQ=
+SIZE (VictoriaMetrics-VictoriaMetrics-v1.93.8.tar.gz) = 59823574

Re: Unable to access the Hiawatha package

[Lucas Gabriel Vuotto]

Hey Jason,

On Tue, Nov 07, 2023 at 09:43:38PM +1100, jasfi...@emailme.net.au wrote:
> I am using the latest OpenBSD 7.4 version along with Hiawatha 10.11
> installed. Unfortunately, I am unable to update the latest version Hiawatha
> 11.4 that found in OpenBSD Ports Readme: port www/hiawatha (openports.pl)
> and ports/www/hiawatha/ (openbsd.org) .
> 
> When I run a package command pkg_add -u hiawatha-10.11 or even pkg_add
> hiawatha-11.4 OpenBSD response in below are:
> Can't find Hiawatha-11.4
> Couldn't install Hiawatha-11.4

https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/hiawatha/Makefile

In revision 1.68, "PERMIT_PACKAGE = Yes" was removed due to licenses
incompatibilities, meaning that the port is able to build but OpenBSD
isn't able to distribute it. Your only option is building it yourself.

Not baby steps and no screenshots, but

0. Read https://www.openbsd.org/faq/ports/
1. Get the ports tree (https://www.openbsd.org/anoncvs.html for
   guidance)
2. cd /usr/ports//hiawatha && make install

Lucas

NEW mail/himalaya (after unlock)

[Lucas Gabriel Vuotto]

Hi ports,

I wanted to try out Himalaya [0], so I ported it. I didn't find it much
usable for myself, but might be useful for some of you, so here it is.
Given it isn't something I'll be using, I won't take MAINTAINER for it.

It's my first time dealing with a Rust port. The docs for the module are
a bit rough around the edges. I don't know why I had to define

MODCARGO_CRATES_KEEP += libsqlite3-sys

but it wouldn't make it compile without it. I copied it over from
another port after noticing that it's a somewhat common pattern in the
ports that use Rust and SQLite. There are also some undocumented
variables; one that particularly standed out is
MODCARGO_NO_DEFAULT_FEATURES, while the "counterpart" MODCARGO_FEATURES
is documented.

The workflow for getting crates.inc properly set up is a bit sketchy.
If anybody is looking for hints, I *believe* I went with

1. make makesum
2. make extract
3. make modcargo-gen-crates | sed 1d >crates.inc
   # the first line is a reminder to run modcargo-gen-crates-licenses
   # afterwards.
4. make makesum  # again, because now it needs to fetch the crates
5. make extract  # again, because new things downloaded
6. make modcargo-gen-crates-licenses >tmp && mv tmp crates.inc

Also, I'm not super sure if I'm missing a LDEP on sqlite3. Didn't hear
any complain from make port-lib-depends-check.

Lucas


himalaya.tgz
Description: application/tar-gz

Fix gitdaemon.rc pexp

[Lucas Gabriel Vuotto]

Hi ports@,

`git daemon` executes /usr/local/libexec/git/git-daemon, but pexp only checks 
for `gitdaemon ...`, resulting in `rcctl check gitdaemon` always returning an 
error. This patch changes that. Don't know if hardcoding the path and not using 
$TRUEPREFIX, so feel free to change that if needed.

Cheers.

-- lgv.

Index: devel/git/pkg/gitdaemon.rc
===
RCS file: /cvs/ports/devel/git/pkg/gitdaemon.rc,v
retrieving revision 1.1
diff -u -p -u -r1.1 gitdaemon.rc
--- devel/git/pkg/gitdaemon.rc  2 Jun 2016 18:33:27 -   1.1
+++ devel/git/pkg/gitdaemon.rc  28 Dec 2017 22:40:28 -
@@ -7,7 +7,7 @@ daemon_flags="--user=_gitdaemon"
 
 . /etc/rc.d/rc.subr
 
-pexp="git-daemon --detach${daemon_flags:+ ${daemon_flags}}"
+pexp="/usr/local/libexec/git/git-daemon --detach${daemon_flags:+ 
${daemon_flags}}"
 rc_reload=NO
 
 rc_cmd $1