Project direction and next steps – GitHub migration and branch model 🔗 link

On Fr, 16 Jan 2026, Bruno Manzoni wrote:

> - Migrate source control from SVN/SourceForge to GitHub as the
>   primary workflow.

This seems to be done in https://github.com/xymon-monitoring/xymon

> - Establish a clean, shared Git workflow with clear governance.

There is much to do, but a first build pipeline (does only a build of
client and server, without creating packages or testing) was suggested
in https://github.com/xymon-monitoring/xymon/pull/4 Maybe some of you
finds time to review this.

> - Incorporate pending patches and publish a new 4.3.x release.

I started with these by creating some merge requests (the most
important and generic patches from the Debian repository), see
https://github.com/xymon-monitoring/xymon/pulls Looking for reviewers
of these.

> - Address technical debt (PCRE2 migration, build warnings,
>   compatibility issues).

A merge request for PCRE2 is in
https://github.com/xymon-monitoring/xymon/pull/5

> FEEDBACK AND INITIATIVES REQUESTED
> - Does the current branch model (`main` = 4.3.x stable, `4.x-master`
>   = 4.4 development) make sense?

For me that's okay.  I'm open for alternative names of '4.x-master'
(maybe 'devel' or the like?), but I don't think that this is really
relevant.

> - What should be prioritized next: patch integration, CI/CD setup,
>   packaging, testing, or documentation?

>From my point of view, patch integration and fixing build warnings and
the like has highest priority.  It would be great to have a 4.3.31
without architectural changes but with the current painpoints fixed.

I noticed that the RPM distributions (Fedora/RedHat/CentOS/SuSE)
currently don't seem to package xymon themselves.  Users of these
distributions have to use packages from J.C.'s
https://terabithia.org/xymon/ 3rd party repository.

But this seems to have stopped beeing updated after fc38, maybe
because of the PCRE2 incompatibility of newer OS distributions?

Without knowing, whether J.C. will continue to update this repository
in the future (his last vital sign on the xymon list was nearly two
years ago), we should think about building/providing at least RPM
packages via pipeline.

One open question to me is, why J.C. (as the person, who released
upstream 4.3.30) applied that many patches in
https://terabithia.org/xymon/f38/SRPMS/xymon-4.3.30-1.fc38.src.rpm,
that do not seem to be applied upstream.  Seems that we should review
them for integration into main, to find out whether they are RPM
specific or whether they are useful for everybody.

Greetings
Roland

I agree building for (at least) ubuntu-latest is a good start, but I would also add some RPM variant before publishing

Nicola

Mastodon: @user-3ad00cf7a0c9@xymon.invalid

Il giorno dom 18 gen 2026 alle ore 12:35 Roland Rosenfeld <user-237a1e03bc39@xymon.invalid> ha scritto:

On Fr, 16 Jan 2026, Bruno Manzoni wrote:

> - Migrate source control from SVN/SourceForge to GitHub as the
>   primary workflow.

This seems to be done in https://github.com/xymon-monitoring/xymon

> - Establish a clean, shared Git workflow with clear governance.

There is much to do, but a first build pipeline (does only a build of
client and server, without creating packages or testing) was suggested
in https://github.com/xymon-monitoring/xymon/pull/4 Maybe some of you
finds time to review this.

> - Incorporate pending patches and publish a new 4.3.x release.

I started with these by creating some merge requests (the most
important and generic patches from the Debian repository), see
https://github.com/xymon-monitoring/xymon/pulls Looking for reviewers
of these.

> - Address technical debt (PCRE2 migration, build warnings,
>   compatibility issues).

A merge request for PCRE2 is in
https://github.com/xymon-monitoring/xymon/pull/5

> FEEDBACK AND INITIATIVES REQUESTED
> - Does the current branch model (`main` = 4.3.x stable, `4.x-master`
>   = 4.4 development) make sense?

For me that's okay.  I'm open for alternative names of '4.x-master'
(maybe 'devel' or the like?), but I don't think that this is really
relevant.

> - What should be prioritized next: patch integration, CI/CD setup,
>   packaging, testing, or documentation?

>From my point of view, patch integration and fixing build warnings and
the like has highest priority.  It would be great to have a 4.3.31
without architectural changes but with the current painpoints fixed.

I noticed that the RPM distributions (Fedora/RedHat/CentOS/SuSE)
currently don't seem to package xymon themselves.  Users of these
distributions have to use packages from J.C.'s
https://terabithia.org/xymon/ 3rd party repository.

But this seems to have stopped beeing updated after fc38, maybe
because of the PCRE2 incompatibility of newer OS distributions?

Without knowing, whether J.C. will continue to update this repository
in the future (his last vital sign on the xymon list was nearly two
years ago), we should think about building/providing at least RPM
packages via pipeline.

One open question to me is, why J.C. (as the person, who released
upstream 4.3.30) applied that many patches in
https://terabithia.org/xymon/f38/SRPMS/xymon-4.3.30-1.fc38.src.rpm,
that do not seem to be applied upstream.  Seems that we should review
them for integration into main, to find out whether they are RPM
specific or whether they are useful for everybody.

Greetings
Roland
xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com



I downloaded and installed the source RPM from Terebithia.  The pristine tarball included in that matches the 4.3-master tarball from Sourceforge, in both size and md5sum, and there are a ton of patch files as well.  Some of the patches relate to the backfeed queue, not sure about the remainder.  Possibly the patches are backported from 4.4-alpha?  

I don't know the first thing about making Ubuntu/Debian packages, but I can make RPMs.

Ralph Mitchell

On Sun, Jan 18, 2026 at 8:55 AM Nicola <user-2c63804b6921@xymon.invalid> wrote:

I agree building for (at least) ubuntu-latest is a good start, but I would also add some RPM variant before publishing

Nicola

Mastodon: @user-3ad00cf7a0c9@xymon.invalid

Il giorno dom 18 gen 2026 alle ore 12:35 Roland Rosenfeld <user-237a1e03bc39@xymon.invalid> ha scritto:

On Fr, 16 Jan 2026, Bruno Manzoni wrote:

> - Migrate source control from SVN/SourceForge to GitHub as the
>   primary workflow.

This seems to be done in https://github.com/xymon-monitoring/xymon

> - Establish a clean, shared Git workflow with clear governance.

There is much to do, but a first build pipeline (does only a build of
client and server, without creating packages or testing) was suggested
in https://github.com/xymon-monitoring/xymon/pull/4 Maybe some of you
finds time to review this.

> - Incorporate pending patches and publish a new 4.3.x release.

I started with these by creating some merge requests (the most
important and generic patches from the Debian repository), see
https://github.com/xymon-monitoring/xymon/pulls Looking for reviewers
of these.

> - Address technical debt (PCRE2 migration, build warnings,
>   compatibility issues).

A merge request for PCRE2 is in
https://github.com/xymon-monitoring/xymon/pull/5

> FEEDBACK AND INITIATIVES REQUESTED
> - Does the current branch model (`main` = 4.3.x stable, `4.x-master`
>   = 4.4 development) make sense?

For me that's okay.  I'm open for alternative names of '4.x-master'
(maybe 'devel' or the like?), but I don't think that this is really
relevant.

> - What should be prioritized next: patch integration, CI/CD setup,
>   packaging, testing, or documentation?

>From my point of view, patch integration and fixing build warnings and
the like has highest priority.  It would be great to have a 4.3.31
without architectural changes but with the current painpoints fixed.

I noticed that the RPM distributions (Fedora/RedHat/CentOS/SuSE)
currently don't seem to package xymon themselves.  Users of these
distributions have to use packages from J.C.'s
https://terabithia.org/xymon/ 3rd party repository.

But this seems to have stopped beeing updated after fc38, maybe
because of the PCRE2 incompatibility of newer OS distributions?

Without knowing, whether J.C. will continue to update this repository
in the future (his last vital sign on the xymon list was nearly two
years ago), we should think about building/providing at least RPM
packages via pipeline.

One open question to me is, why J.C. (as the person, who released
upstream 4.3.30) applied that many patches in
https://terabithia.org/xymon/f38/SRPMS/xymon-4.3.30-1.fc38.src.rpm,
that do not seem to be applied upstream.  Seems that we should review
them for integration into main, to find out whether they are RPM
specific or whether they are useful for everybody.

Greetings
Roland
xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

To unsubscribe send an email to xymon-leave@xymon.com

On 19/01/2026 01:22, Scot Kreienkamp wrote:

Would it be worthwhile to create a docker image of xymon?  The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution.

please don't. Why would you do this?

Scot Kreienkamp

*
*

*Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate *
(XXX) XXX-XXXX | X-XXX-XXX-XXXX | user-9678697f1438@xymon.invalid
One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com <http:// www.la-z-boy.com/>
facebook.com/lazboy <http://facebook.com/lazboy>  |instagram.com/lazboy <https://instagram.com/lazboy> |youtube.com/lazboy <http://youtube.com/ lazboy>

LaZboy Logo

> On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <user-237a1e03bc39@xymon.invalid> wrote:
 >
 > Hi Mark!
 >
 > On Sun, 18 Jan 2026, Mark Felder via Xymon wrote:
 >
 >>> It would be great to have a 4.3.31 without architectural changes
 >>> but with the current painpoints fixed.
 >
 >> I agree. I think 4.3.31 as our test run should be a roll up of
 >> patches collected by distros and other small patches that have been
 >> floating around which don't risk changing behavior or build
 >> dependencies. That would exclude the PCRE2 change for this release
 >> as we don't know how this will affect non-Linux/BSD platforms. It
 >> should be fine as PCRE2 has been around a long time, but nobody has
 >> ever tried to build it on e.g., Solaris yet
 >
 > But not upgrading to PCRE2 but staying with the old library, which was
 > last updated 2021-06-22 (8.45) and is now officially "no longer being
 > actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/>) means, that RHEL 10
 > and Debian 13 (trixie) are no longer supported, since these do no
 > longer ship the old pcre library.
 >
 > BTW: pcre2 was first released in 2015, so I expect that every OS
 > should be able to build/ship this in more than 10 years.
 >
 > I have to admit, that I didn't try this out on Solaris yet, but is
 > there really anybody running a xymon server on Solaris nowadays?  If
 > you only need the client (with conftype "server"), no pcre is needed
 > at all (only for the client with conftype "client"), so for most
 > users, who only need a client on a "special" OS, this shouldn't be an
 > issue.
 >
 > A short search showed me, that pcre2 seems to be available on Solaris
 > 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/> (but I didn't try
 > this out myself, since I'm very happy to have shut down all Solaris
 > boxes last year and so I no longer have to pray, if one of them hicks
 > up and nobody is there to fix it).
 >
 > Greetings
 > Roland
 >
 > PS: Do you also see my mails on the ML "From: Roland Rosenfeld
 >    <user-237a1e03bc39@xymon.invalid>"?
 >    While I see most postings in the ML as "From: Some Name as xymon
 >    <xymon@xymon.com>", I see myself (and some others) with their real
 >    addresses (and get DMARC warnings, because the list breaks DKIM
 >    (by adding a signature) and SPF (since the list server isn't
 >    permitted for spinnaker.de)...
 > xymon@xymon.com
 > To unsubscribe send an email to xymon-leave@xymon.com

This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.

xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

Thanks, Scot and Christoph, for the clear and candid feedback — I appreciate the direct tone.

The security and complexity concerns are understood, even if I don’t yet have a complete picture — thanks, Christoph, for the explanations.

Exploring whether there are use cases that make sense (testing, integration, small environments) and better understanding the trade-offs still seems like a good idea to me.
At this stage, it doesn’t feel like a priority topic, although I may be mistaken, as there is generally a lack of testing and this could help address that to some extent.

There don’t seem to be any immediate stakes around this, so it really feels like an exploratory subject.
Since Scot already seems to have a working version, it’s good to know that this has been explored, and it seems fine for him to continue in whatever direction he finds useful. Thanks, Scot, for the idea and the proposal.

Bruno

Bruno,

Normally the processes running in the container are isolated.  The only files it can see are within the image, the only procs are those running in the image, ports, etc.  I’ve never tried to break that isolation to let anything “out of the box” of the image.  Did a bit of googling though, it looks like even the client might be able to work in a docker image.  Maybe. 

Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate
One La-Z-Boy Drive | Monroe, Michigan 48162 | ( (XXX) XXX-XXXX | |  ) X-XXX-XXX-XXXX  |  Email: user-9678697f1438@xymon.invalid

From: Bruno Manzoni via Xymon <xymon@xymon.com>
Sent: Monday, January 19, 2026 3:05 AM
To: xymon@xymon.com
Cc: Bruno Manzoni <user-81df5df13c04@xymon.invalid>
Subject: [Xymon] Re: Project direction and next steps – GitHub migration and branch model

Why not? One doesn't exclude the other, right?

I'm curious to hear both sides. What would be the pros and cons of having a Dockerized server receiving data from native clients?

@Scot, why do you think the client wouldn't be viable?
@Christoph, why the 'please don't'?

It seems like a good hybrid idea to me, but I’d love to understand your technical concerns!

Bruno

Le 19.01.2026 à 07:20, Christoph Zechner a écrit :

On 19/01/2026 01:22, Scot Kreienkamp wrote:

Would it be worthwhile to create a docker image of xymon?  The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution.

please don't. Why would you do this?

Scot Kreienkamp

*
*

*Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate *
(XXX) XXX-XXXX | X-XXX-XXX-XXXX | user-9678697f1438@xymon.invalid
One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com <http:// www.la-z-boy.com/>
facebook.com/lazboy <http://facebook.com/lazboy>  |instagram.com/lazboy <https://instagram.com/lazboy> |youtube.com/lazboy <http://youtube.com/ lazboy>

LaZboy Logo

> On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <user-237a1e03bc39@xymon.invalid> wrote:
 >
 > Hi Mark!
 >
 > On Sun, 18 Jan 2026, Mark Felder via Xymon wrote:
 >
 >>> It would be great to have a 4.3.31 without architectural changes
 >>> but with the current painpoints fixed.
 >
 >> I agree. I think 4.3.31 as our test run should be a roll up of
 >> patches collected by distros and other small patches that have been
 >> floating around which don't risk changing behavior or build
 >> dependencies. That would exclude the PCRE2 change for this release
 >> as we don't know how this will affect non-Linux/BSD platforms. It
 >> should be fine as PCRE2 has been around a long time, but nobody has
 >> ever tried to build it on e.g., Solaris yet
 >
 > But not upgrading to PCRE2 but staying with the old library, which was
 > last updated 2021-06-22 (8.45) and is now officially "no longer being
 > actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/>) means, that RHEL 10
 > and Debian 13 (trixie) are no longer supported, since these do no
 > longer ship the old pcre library.
 >
 > BTW: pcre2 was first released in 2015, so I expect that every OS
 > should be able to build/ship this in more than 10 years.
 >
 > I have to admit, that I didn't try this out on Solaris yet, but is
 > there really anybody running a xymon server on Solaris nowadays?  If
 > you only need the client (with conftype "server"), no pcre is needed
 > at all (only for the client with conftype "client"), so for most
 > users, who only need a client on a "special" OS, this shouldn't be an
 > issue.
 >
 > A short search showed me, that pcre2 seems to be available on Solaris
 > 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/> (but I didn't try
 > this out myself, since I'm very happy to have shut down all Solaris
 > boxes last year and so I no longer have to pray, if one of them hicks
 > up and nobody is there to fix it).
 >
 > Greetings
 > Roland
 >
 > PS: Do you also see my mails on the ML "From: Roland Rosenfeld
 >    <user-237a1e03bc39@xymon.invalid>"?
 >    While I see most postings in the ML as "From: Some Name as xymon
 >    <xymon@xymon.com>", I see myself (and some others) with their real
 >    addresses (and get DMARC warnings, because the list breaks DKIM
 >    (by adding a signature) and SPF (since the list server isn't
 >    permitted for spinnaker.de)...
 > xymon@xymon.com
 > To unsubscribe send an email to xymon-leave@xymon.com

This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.

xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

On 1/18/26 13:58, Roland Rosenfeld wrote:
>
> But not upgrading to PCRE2 but staying with the old library, which was
> last updated 2021-06-22 (8.45) and is now officially "no longer being
> actively maintained" (see https://www.pcre.org/) means, that RHEL 10
> and Debian 13 (trixie) are no longer supported, since these do no
> longer ship the old pcre library.
>

That's fair. I wasn't worried about Debian because they already patched
it and didn't know the state of things on RHEL. We might as well
consider that Debian has tested this pretty well already and make a fair
assumption that PCRE2 is available on platforms that still want Xymon
updates.

>
> PS: Do you also see my mails on the ML "From: Roland Rosenfeld
>      <user-237a1e03bc39@xymon.invalid>"?
>      While I see most postings in the ML as "From: Some Name as xymon
>      <xymon@xymon.com>", I see myself (and some others) with their real
>      addresses (and get DMARC warnings, because the list breaks DKIM
>      (by adding a signature) and SPF (since the list server isn't
>      permitted for spinnaker.de)...

A quick search shows I'm not seeing any mails from you coming through
the list properly, or it would show they're "From: Roland Rosenfeld via
Xymon <xymon@xymon.com>". I think we need to remember to reply to all
for now or some messages might get lost...

Mark
xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

Recently I tried to install xymon-4.3.30. I had similar results trying to run .configure on CentOS Stream 10 and openSUSE Leap 16.0.  Xymon configure can't seem to find or work with rrdtool, openSSH or OpenLDAP. I have confirmed that I have the following versions installed:

RRDtool 1.9.0  Copyright by Tobias Oetiker <user-645e379b3ab6@xymon.invalid>

               Compiled Aug 08 2024 16:56:07

OpenSSH_10.0p2, OpenSSL 3.5.0 8 Apr 2025

OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)

I am thrilled to see the Xymon project moving forward. We have been using Xymon for over 15 years and it continues to be an essential tool for us.  Rather than try to upgrade the old distro it's running on, I look forward to standing up a new server if this project updates the installer. I am open to using whichever Linux distro will work.

Thank you so much everyone for your efforts to maintain Xymon!

Regards,

Chris R.

---

From: Becker Christian via Xymon <xymon@xymon.com>
Sent: Thursday, February 5, 2026 9:09 AM
To: Xymon mailinglist <xymon@xymon.com>
Cc: Becker Christian <user-e4a19bfb94c0@xymon.invalid>
Subject: [Xymon] Re: Project direction and next steps – GitHub migration and branch model

Hi to the list,

Just FYI, it might be interesting for the project…..

Today, just for testing, I've installed an Oracle Linux 10 x86_64 from scratch, followed by the repo's updates and the known prerequisites to install Xymon.

Then I've cloned the Xymon 4.3.30 github from https://github.com/xymon-monitoring/xymon (hope it's the right one....)

Running configure did throw me that error as first:

Checking for PCRE ...

test-pcre.c:1:10: fatal error: pcre.h: No such file or directory

    1 | #include <pcre.h>

      |          ^~~~~~~~

compilation terminated.

make: *** [Makefile.test-pcre:4: test-compile] Error 1

ERROR: Cannot compile using PCRE library.

/usr/bin/ld: cannot find test-pcre.o: No such file or directory

/usr/bin/ld: cannot find -lpcre: No such file or directory

collect2: error: ld returned 1 exit status

make: *** [Makefile.test-pcre:7: test-link] Error 1

ERROR: Cannot link with PCRE library.

Missing PCRE include- or library-files. These are REQUIRED for xymond

PCRE can be found at http://www.pcre.org/

If you have PCRE installed, use the "--pcreinclude DIR" and "--pcrelib DIR"

options to configure to specify where they are.

Google’ing around, I found this site: https://dl.marmotte.net/rpms/redhat/el10/x86_64/pcre-8.45-1.el10.8/

From there, I've downloaded:

pcre-8.45-1.el10.8.src.rpm                     

pcre-8.45-1.el10.8.x86_64.rpm                  

pcre-cpp-8.45-1.el10.8.x86_64.rpm              

pcre-cpp-debuginfo-8.45-1.el10.8.x86_64.rpm    

pcre-debuginfo-8.45-1.el10.8.x86_64.rpm        

pcre-debugsource-8.45-1.el10.8.x86_64.rpm      

pcre-devel-8.45-1.el10.8.x86_64.rpm            

pcre-doc-8.45-1.el10.8.noarch.rpm              

pcre-static-8.45-1.el10.8.x86_64.rpm           

pcre-tools-8.45-1.el10.8.x86_64.rpm            

pcre-tools-debuginfo-8.45-1.el10.8.x86_64.rpm  

pcre-utf16-8.45-1.el10.8.x86_64.rpm            

pcre-utf16-debuginfo-8.45-1.el10.8.x86_64.rpm  

pcre-utf32-8.45-1.el10.8.x86_64.rpm            

pcre-utf32-debuginfo-8.45-1.el10.8.x86_64.rpm

…and installed:

                rpm -i     pcre-8.45-1.el10.8.x86_64.rpm \

               pcre-devel-8.45-1.el10.8.x86_64.rpm \

pcre-utf16-8.45-1.el10.8.x86_64.rpm \

pcre-utf32-8.45-1.el10.8.x86_64.rpm \

pcre-cpp-8.45-1.el10.8.x86_64.rpm \

pcre-tools-8.45-1.el10.8.x86_64.rpm

After this, with the next configure, the next error came to me:

Checking for RRDtool ...

Found RRDtool < 1.9.0 via pkg-config

Not RRDtool 1.0.x, checking for 1.2.x

test-rrd.c: In function ‘main’:

test-rrd.c:32:36: error: passing argument 2 of ‘rrd_graph’ from incompatible pointer type [-Wincompatible-pointer-types]

   32 |         result = rrd_graph(pcount, rrdargs, &calcpr, &xsize, &ysize, NULL, &ymin, &ymax);

      |                                    ^~~~~~~

      |                                    |

      |                                    char **

In file included from test-rrd.c:3:

/usr/include/rrd.h:185:5: note: expected ‘const char **’ but argument is of type ‘char **’

  185 |     const char **,

      |     ^~~~~~~~~~~~~

make: *** [Makefile.test-rrd:4: test-compile] Error 1

ERROR: Cannot compile with RRDtool.

ERROR: Linking with RRDtool fails

RRDtool include- or library-files not found.

These are REQUIRED for trend-graph support in Xymon, but Xymon can

be built without them (e.g. for a network-probe only installation.

RRDtool can be found at http://oss.oetiker.ch/rrdtool/

If you have RRDtool installed, use the "--rrdinclude DIR" and "--rrdlib DIR"

options to configure to specify where they are.

Continuing with all trend-graph support DISABLED

Now I’m stuck at this stage.

But this is just to let you guys know what happened to me on Oracle Linux 10.

Regards