port-modules(5): devel/cmake

Here is a suggestion to better document cmake.port.mk.

Rafael

Index: port-modules.5
===================================================================
RCS file: /cvs/src/share/man/man5/port-modules.5,v
diff -u -p -r1.278 port-modules.5
--- port-modules.5 2 Dec 2025 13:05:28 -0000 1.278
+++ port-modules.5 1 Jan 2026 09:35:45 -0000
@@ -566,6 +566,20 @@ Changes
to `test' as this is standard for CMake projects.
Also this module has the following knobs:
.Bl -tag -width Ds
+.It USE_NINJA
+If set to `Yes', use
+.Xr ninja 1
+as the build system instead of
+.Xr make 1 .
+Adds
+.Pa devel/ninja
+to
+.Ev BUILD_DEPENDS .
+If set to `No', uses Unix Makefiles generator and adds
+.Sq nojunk
+to
+.Ev DPB_PROPERTIES .
+Default value is `Yes'.
.It MODCMAKE_WANTCOLOR
If set to `Yes', CMake will colorize its output.
Should not be used in ports Makefiles.
@@ -581,11 +595,52 @@ build.
The exact effects on the build process depend on settings specified in
the CMake config files.
Default value is `No'.
+.It MODCMAKE_LDFLAGS
+If set, the value will be passed to CMake via the
+.Ev LDFLAGS
+environment variable during configuration.
+CMake uses this only on the first configuration to set
+.Ev CMAKE_EXE_LINKER_FLAGS_INIT ,
+.Ev CMAKE_SHARED_LINKER_FLAGS_INIT ,
+and
+.Ev CMAKE_MODULE_LINKER_FLAGS_INIT .
+Default value is empty.
.El
-Also,
-.Sq nojunk
-is added to DPB_PROPERTIES because CMake's include files parser cheats
-too much.
+.Pp
+When used together with other modules, appropriate variables are
+automatically passed to CMake:
+.Bl -tag -width "lang/python" -compact
+.It java
+.Ev JAVA_HOME
+is set in
+.Ev CONFIGURE_ENV
+and
+.Ev MAKE_ENV .
+.It lang/python
+Python executable, library, and include paths are set for FindPython,
+FindPython3, and FindPythonN modules.
+.It lang/lua
+Lua include directory and library path are set for FindLua.
+.It lang/ruby
+Ruby executable is set for FindRuby.
+.It lang/tcl
+Tcl version, include, library directories and library name are set in
+.Ev CONFIGURE_ENV .
+.It x11/tk
+Tk version, include, library directories and library name are set in
+.Ev CONFIGURE_ENV .
+.El
+.Pp
+The environment variable
+.Ev MODCMAKE_PORT_BUILD
+is automatically set to `yes' in
+.Ev CONFIGURE_ENV
+and
+.Ev MAKE_ENV .
+This disables CMake's default optimization flags, putting them under
+ports control, and prevents network operations
+.Pq file DOWNLOAD/UPLOAD
+during the build.
.It devel/cabal
See
.Xr cabal-module 5

Re: best way to detect running iked vpn

hi Piotr
>> is checking for /var/run/iked.sock the best way to see if the
>> vpn is running ?

>I'd:
>doas ipsecctl -sa | grep 'esp tunnel'
>and possibly narrow this down to what's relevant for you.

sorry i took so long to say thanks,
just noticed that i hadn't replyed to you.
happy new year to all

Re: OpenNTPD behaviour with sensors

Thanks for your reply, also to Kevin. This makes sense and explains the
behaviour I'm seeing.
I now know that I have to make some other choices in my setup, but that's
OK.

Best regards and all the best for 2026 (for everyone),
Maurice


On Wed, Dec 31, 2025 at 09:27:51PM +0300, Kihaguru Gathura wrote:
>Hi Maurice
>
>
>This is expected behavior with OpenNTPd and not a problem with your
>hardware.
>
>With only a local sensor, ntpd can control the clock very tightly so that
>microsecond offsets are normal but once you add remote servers, their
>network delay and asymmetry start to influence the clock control as well.
>
>Even if the sensor remains selected in ntpctl, the other peers will still
>affect the filtering and frequency correction, which typically results in
>millisecond-level variation.
>
>Weights don't fully isolate the sensor, and seeing it selected does not
>mean the other sources have zero impact.
>
>If you want to keep microsecond accuracy, the usual approach is to run the
>machine as a pure stratum-1 server with only the sensor configured and get
>redundancy by running multiple such boxes.
>
>However, If you need fallback to network time in the same daemon, then
>OpenNTPd is simply not designed for that use case.
>
>Regards,
>
>Kihaguru Njenga Gathura
>
>
>On Wed, 31 Dec 2025, 17:28 Maurice Janssen, <maurice@z74.net> wrote:
>
>> Hi,
>>
>> I have a couple of small machines (Soekris 6501 and 5501) that I use as
>> NTP server in the NTP pool.
>> When I use a sensor as the only source of time (Garmin 18lvc on the serial
>> port or Meinberg PZF180PEX DCF77 receiver card), the offset is quite good:
>> nearly allways below 20 us, most of the time below 5 us and sometimes even
>> less than 1 us.
>> But when I add another server (mainly as backup in case the sensor doen't
>> work), the offset drifts away to 1 or 2 ms. I tried with 1 sensor and
>> 1 server, with 1 sensor and multiple servers, I tried adding weight 5 or 10
>> to the sensor, but this doesn't seem to have any effect. In all cases ntpd
>> stays synchronised to the sensor (with poll=15s), but after an hour or so
>> after starting ntpd the offset starts to increase. And from that moment,
>> the
>> offset wanders between roughly -2 and +2 ms.
>> It almost seems as if ntpd is synchronised with one of the servers (with
>> much higher polling interval), however ntpctl still shows that it is
>> synchronised to the sensor (albeit with the wandering offset as described
>> above).
>>
>> I would prefer to have the microsecond offset _and_ some servers as backup,
>> but can't get it working like that.
>>
>> Am I missing something? Or is this a bug in ntpd?
>>
>> Thanks for any help.
>>
>>
>>

Pretty please: AfterStep 1.0

Hi everyone,

Happy New Year! I have spent a lot of effort lately trying to tackle
that old classic, AfterStep 1.0, on OpenBSD 7.8.

As I was not able to find the original source code easily, I used the
FreeBSD port as a base. With a bit of help from Gemini 3.0, I have
finally managed to install it successfully. However, the process was
somewhat beyond my personal skill level as I am not a "computer geek"
by trade.

I was wondering if any of the talented developers here would consider
making a formal package (port) for AfterStep 1.0? There must be others
who are still crazy about this classic window manager!

I have even installed Xsnow; seeing Father Christmas and his reindeer
flying across my OpenBSD 7.8 screen brings back so many memories.
It looks brilliant with AfterStep.

Pretty please?

Best regards,
masayoshi