[sr-dev] Build failed in Jenkins: kamailiodev-nightly-binaries » amd64,bullseye #2889

2024-12-18 Thread kamailio--- via sr-dev
See Changes: -- [...truncated 66.92 KiB...] I: new cache content 'autotools-dev_20180224.1+nmu1_all.deb' added I: new cache cont

[sr-dev] Re: [kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)

2024-12-18 Thread space88man via sr-dev
For cmake this should be much less of a (security) concern as it is a build-system generator only: it does not change the distro build tools, viz., make / gcc / binutils - which are used during the actual build. Users buster/16.04/18.04 can use 3.31 from kitware - the generated Makefiles can

[sr-dev] Re: [kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)

2024-12-18 Thread Ovidiu Sas via sr-dev
> @ovidiusas: in the past, you used to do cross-compiling. Are you still doing > it? If yes, is the new cmake build system supporting/impacting it? I used to cross-compile for optware. I no longer have a toolchain to test it. -- Reply to this email directly or view it on GitHub: https://github.

[sr-dev] Re: [kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)

2024-12-18 Thread Daniel-Constantin Mierla via sr-dev
> Sure. But if such a legal requirements exists, I am wondering how they will > use Kamailio then on their platform. We are not providing this officially > certified packages either. And if they build Kamailio by themself, why they > also not could also add some build dependencies as well. Comp

[sr-dev] Re: [kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)

2024-12-18 Thread Daniel-Constantin Mierla via sr-dev
@ovidiusas: in the past, you used to do cross-compiling. Are you still doing it? If yes, is the new cmake build system supporting/impacting it? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2552030175 You are receiving this be

[sr-dev] Re: [kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)

2024-12-18 Thread Daniel-Constantin Mierla via sr-dev
@linuxmaniac: would it be ok (ie., not add too much complexity) if we also keep old-makefiles, so for older distros they are used for building (the deb specs for them should be there, right, no extra work) and for newer distros cmake is used? In this way, we can bump cmake to a more recent versi

[sr-dev] Re: [kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)

2024-12-18 Thread Ovidiu Sas via sr-dev
I just tested installing cmake 3.31.2 as a binary and compiling it from source on a system that has only cmake 2.18.12. https://cmake.org/download/ With both methods kamailio compiled successfully. Note: it takes quite a while to compile cmake from source. On Wed, Dec 18, 2024 at 10:30 AM Daniel

[sr-dev] Re: [kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)

2024-12-18 Thread Henning Westerholt via sr-dev
Good point, cmake 3.13 would mean drop support for 18.04, cmake 3.10 would mean drop support for 16.04. Both are currently packaged on deb.kamailio.org. We should probably formalize some support timeline (e.g. on a web page) also for distributions. Xenofon will list again the issues we would hav

[sr-dev] Re: [kamailio/kamailio] htable: Fix de-/increment w/ auto expire (PR #4079)

2024-12-18 Thread Bastian Triller via sr-dev
@btriller pushed 1 commit. 0c280e7319bce4fd83b3dd8eadc6ca1b2abfebd4 htable: Fix de-/increment w/ auto expire -- View it on GitHub: https://github.com/kamailio/kamailio/pull/4079/files/b1d6532b7877161371c0e8680226e55c9f4e2c1b..0c280e7319bce4fd83b3dd8eadc6ca1b2abfebd4 You are receiving this beca

[sr-dev] [kamailio/kamailio] htable: `$shtcn` also counts expired items (Issue #4080)

2024-12-18 Thread Bastian Triller via sr-dev
### Description `$shtcn` (and probably also `$shtcv`, but not tested) includes expired entries in count until `timer` process removes expired items. ### Troubleshooting Reproduction ``` #!KAMAILIO listen=udp:127.0.0.1: log_stderror=yes loadmodule "xlog.so" loadmodule "pv.so" lo

[sr-dev] [kamailio/kamailio] htable: Fix de-/increment w/ auto expire (PR #4079)

2024-12-18 Thread Bastian Triller via sr-dev
Update item expiration value during de-/incrementation for htables that are configured with autoexpire and updateexpire disabled. Otherwise an item cannot be used until timer cleaned it up.