Index | Thread | Search

From:
Martijn van Duren <openbsd+ports@list.imperialat.at>
Subject:
Re: telephony/coturn (turnserver) update
To:
ports <ports@openbsd.org>
Cc:
Stuart Henderson <stu@spacehopper.org>
Date:
Thu, 5 Mar 2026 13:51:46 +0100

Download raw body.

Thread
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.