From: Martijn van Duren Subject: Re: telephony/coturn (turnserver) update To: ports Cc: Stuart Henderson Date: Thu, 5 Mar 2026 13:51:46 +0100 On 3/5/26 1:35 PM, Stuart Henderson wrote: > On 2026/03/05 13:25, Martijn van Duren wrote: >> Funny, I'm running with 4.9.0r0 since yesterday. Diff below. >> My diff includes an additional diff, since coturn moves to >> openssl/{decoder,param_build}.h, which isn't supported by LibreSSL. I >> discussed this with tb@, and we came to the conclusion that just >> reintroducing the old DH-based code is the easiest way forward. > > I thought I'd go to 4.8.0 first before tackling that, so the commit > with whatever is needed for the DH code doesn't change as much. It's basically a simple revert to the old code. So I'm not too upset with adding this diff. > >>> COMMENT = coturn STUN/TURN server >>> >>> -V = 4.6.3-r0 >>> GH_ACCOUNT = coturn >>> GH_PROJECT = coturn >>> -GH_TAGNAME = docker/${V} >>> -DISTNAME = turnserver-${V:S/-r/pl/} >>> - >>> -COMPILER = base-clang ports-gcc >>> -COMPILER_LANGS = c >>> +GH_TAGNAME = 4.8.0 >>> +PKGNAME = turnserver-${GH_TAGNAME} >> >> Last time we chose to go with the r* versions, since they also add code >> changes in there. I don't have a hard preference for one of the other, >> but considering our previous choice is it worth swapping again? > > I checked for this version and there were no code changes in the docker > version compared to the normal one in this release. From what I gathered there normally isn't a code-change in between r0 and the base release number, but they do diverge on subsequent r* releases. The idea was that if we ever wanted to follow the r* releases more active it would be easier, especially considering the long delays in between the "normal" releases. > >>> +MODULES = devel/cmake >> >> Any particular reason to change build environment? > > I noticed that it was picking up ginstall from coreutils, noticed that > the cmake build looked reasonably sane, so thought I'd go with that. > But maybe it's better to just use the custom build script and fix it > to not pick up ginstall. > I don't care one way or the other. As long as it produces a working daemon I'm happy. It just makes reviewing it this one time harder. Your call.