January 2026 - Xymon - Xymon mailman web

Project direction and next steps – GitHub migration and branch model
by Bruno Manzoni 09 Feb '26

09 Feb '26

Hi All, Below is a structured summary of the current status following recent discussions and actions around the Xymon project, together with proposed next steps. Feedback from everyone is explicitly requested. PEOPLE – ROLES AND SKILLS (inferred from the latest email exchanges only; non-exhaustive and not limiting) - Bruno Manzoni – coordination; project management, workflow organization - Nicola – contributor; development support, automation - Stef Coene – contributor; development support, testing - Scot Kreienkamp – contributor; build and release automation - Ralph Mitchell – contributor; build and platform support - Mark Felder – contributor; technical guidance, system-level development - Matthew Goebel – contributor; platform support - Jeremy Laidman – contributor; deployment and lifecycle support - Kris Springer – contributor; interface customization - All listed participants have been invited and currently have owner access to the repository. GLOBAL SUMMARY – WHAT IS PROPOSED - Migrate source control from SVN/SourceForge to GitHub as the primary workflow. - Establish a clean, shared Git workflow with clear governance. - Treat 4.3 as the stable production line; keep 4.4 experimental. - Incorporate pending patches and publish a new 4.3.x release. - Enable GitHub Actions for tagging, releases, and CI/CD. - Improve packaging pipelines (RPM, tarballs, possibly DEB) while preserving existing ecosystems. - Address technical debt (PCRE2 migration, build warnings, compatibility issues). - Modernize networking and encryption incrementally (libcurl, HTTPS reporting). - Improve testing, documentation, and UI without breaking Xymon identity. PROJECT CONTEXT – RELEVANT CONSTRAINTS AND DEPENDENCIES - Existing packaging and repositories (e.g. Terabithia) are part of current production deployments and must be preserved or transitioned carefully. - Development momentum depends on early establishment of: - a source repository - a CI/build pipeline - a lightweight review and decision process - Multiple pending patches and enhancements are already available and can be integrated early to deliver visible progress. STEPS COMPLETED - Archived the historical repository `xymon-svn-mirror` to preserve the full SVN lineage as a read-only reference. - Created a new active Git repository `xymon` under xymon-monitoring, cloned from `xymon-svn-mirror` with full history intact. - Set `main` to track the stable 4.3.x line (anchored at Release 4.3.30). - Kept `4.x-master` as the ongoing development branch for 4.4. - Changed the default branch to `main` to align with production usage. FEEDBACK AND INITIATIVES REQUESTED - Does the current branch model (`main` = 4.3.x stable, `4.x-master` = 4.4 development) make sense? - Are there objections or improvements to the proposed Git workflow and governance? - What should be prioritized next: patch integration, CI/CD setup, packaging, testing, or documentation? - If you would like to take initiative, feel free to: - pick any area that interests you, - propose or start any concrete action (issue, patch, CI setup, documentation, release work, experimentation, etc.), - work independently or coordinate with others, as you prefer. - Opening issues, suggesting plans, or submitting early or draft PRs is explicitly encouraged. - Short replies and concrete input are perfectly fine. Thanks, Bruno

12 27

workflow updates
by Scot Kreienkamp 02 Feb '26

02 Feb '26

I've been working through the process of creating RPMs of Xymon, what we can and cannot do on GitHub actions. First, the GitHub actions to create the RPMs must run under Ubuntu, as it's the only Linux version directly available in actions, and it has to be a current version of Ubuntu at that. They phase out older versions fairly quickly. The RPM building commands are available under Ubuntu, but the file locations and such may differ, which could present a problem. The other option is I use podman or docker in Ubuntu based GitHub action to run a RedHat or Rocky Linux image to build the packages in. I might have to go that route to get packaging for older OS versions. If so, I might as well just use that to generate each OS version's packages so the only thing I would have to change between major OS versions is the image being used to compile it. Hopefully. Second, I'm still working through learning how to build the RPMs themselves. I'm still beginner level on how to do this so it's not fast progress. Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp(a)la-z-boy.com 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> [cid:lazboy_2024_inc_navy_4a4d68ec-613a-4141-a2aa-d73a2ae749f6.png] 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.

5 7

XymonPSClient repository
by Stef Coene 30 Jan '26

30 Jan '26

Hi, I create a private github repository and tried to merge all the changes I made to the Windows Powershell client. But I realised it is better to create a repo in https://github.com/xymon-monitoring/ with v2.42 from https://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/. Then I can fork that repo and add my changes. So is it ok if I create a XymonPSClient repository and add client v2.42 to it? Stef

8 17

Project status and current observations
by Bruno Manzoni 25 Jan '26

25 Jan '26

I am very pleased to welcome Henrik Juul Størner back into the organization. We are all very grateful for what you have done so far, and it is a real pleasure to have you with us. A substantial amount of work has already been done by the community in many areas, but it has not been consolidated for some time. Improving this consolidation appears to be an important topic. The GitHub platform is now operational and usable as a central collaboration point, although its governance and workflows are still at an early stage and will naturally evolve over time. One of the challenges currently observed is that Xymon no longer works correctly on several platforms, notably Debian. Platform compatibility is therefore a key concern and already involves a certain level of complexity. Experienced C developers note that delivering a release addressing these issues would represent a significant and concrete improvement. Roland and Mark have been directly involved in this effort, and greater collaboration around their work could be particularly helpful. Mark has already created many issues, which provide useful entry points for anyone interested. Release handling also appears to be an area where further refinement could be beneficial. Taking initiative can be intimidating; it should not be, even if I share that feeling as well. The Xymon community is welcoming, and initiatives taken with good intentions are appreciated. For example, ideas can be shared using the mailing list or by configuring and using GitHub tools and repositories, even if the setup is still evolving. Bruno

4 7

Mr Big - Windows client for Xymon
by Mark Felder 23 Jan '26

23 Jan '26

Has anyone seen this before? It's a C-based client for Windows. https://mrbig.365-24.se/ https://github.com/xymon-mrbig/MrBig Mark

6 5

Github repo for sharing client scripts?
by Mark Felder 23 Jan '26

23 Jan '26

Hi all, Would it be appropriate to create a repo for sharing client scripts / extensions for Xymon? There used to be places like deadcat.net where people uploaded their custom tooling but it's long gone. If we proceed, my only suggestion structurally is to keep each in its own directory so it can be easily accompanied by documentation or config examples if necessary. Mark

4 3

Re: Github repo for sharing client scripts?
by Mark Felder 22 Jan '26

22 Jan '26

On 1/21/26 12:28, Jesper Jensen wrote: > > Later maybe a button for donations for a coffee/beer/money? So we can show/give a bit back to the working people & the one who started it.. > You know, it's funny -- I just found Henrik already has an Amazon Wishlist mention in the README which I've never noticed before. It's so old that you can't even look up people's Amazon wishlists by their email address anymore... Mark

2 1

GIthub link added on xymon.com
by Henrik Juul Størner 21 Jan '26

21 Jan '26

1 0

Git: the 4.4.0-alpha1 tag was updated
by Mark Felder 21 Jan '26

21 Jan '26

I noticed that the 4.4.0-alpha1 tag was not quite correct as it was missing the last two commits JC did in 2023, so I manually imported those commits and force-pushed the tag. One commit was just Changes file updates, and the other was a big GCC warnings fix patch that we need to backport: https://github.com/xymon-monitoring/xymon/commit/54870eda23a8b12a25cf3fdfd9… I don't believe anything else was missing because my own Xymon git conversion has nothing newer than these two commits. Mark

1 0

Renaming 4.x-master branch
by Bruno Manzoni 20 Jan '26

20 Jan '26

3 3