workflow updates 🔗 link

I think you can start from an existing .spec file ) it's the "definition" of how RPMs are built: with a bit of luck they wil work untouched.

Nicola

Nicola

Il giorno 27 gennaio 2026, alle ore 21:15, Scot Kreienkamp <xymon@xymon.com> ha scritto:

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 
(XXX) XXX-XXXX | X-XXX-XXX-XXXX | user-9678697f1438@xymon.invalid
One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com
facebook.com/lazboy  | instagram.com/lazboy | youtube.com/lazboy

Hi Scot,

I think this is a very important topic and it is great that you are working on it. On my side, I am exploring the step just before packaging with a CMake-based build. The current build system is powerful and optimized, but also quite intricate, which makes it harder to evolve. The goal with CMake is to clearly expose which dependencies are present, which features are enabled or disabled, and to provide a simpler base that should make RPM specs and other builds easier to write and more consistent across distributions.

https://github.com/bonomani/xymon/tree/cmake-migration-clean
- This is a first step. It will likely require several iterations to get something really clean, but the priority is to have something that works, in parallel with the current build.
. Compilation seems to work already (visible in my GitHub Actions). 
- The next steps are to cover the remaining parts: The configure.cmake.sh script also works, although probably not fully yet.

I already struggled with RPMs in the past, so I know it can take time to get right. The number of build variables in Xymon is not small, and my aim is to make this as simple as possible upstream, so the packaging step on your side can also stay simple. 

-> Roland and Corentin did some interesting things with Docker and GitHub Actions; maybe this can also help you.

Bruno

Not perfectly sure or all th next info...

The dependencies that I have identified so far are for the runtime:
- Server
  - Required at runtime: web server, fping, mailer (e.g. sendmail)
  - Optional / feature-dependent: OpenSSL libs (SSL checks), OpenLDAP libs (LDAP checks), net-snmp tools (net-snmp-config), c-ares libs (async DNS)

- Client
  - Required at runtime: no extra libraries beyond standard OS tools
  - Optional / feature-dependent: none (PCRE not used in client code: the doc is wrong, i think)

./configure.cmake.sh [options]
Options:
  --non-interactive     Use defaults and skip prompts (NEW)
  --gnuinstall          Enable GNUInstallDirs layout (NEW)
  --prefix DIR          Set install prefix (implies --gnuinstall) (NEW)
  --xymontopdir DIR     Set XYMONTOPDIR
  --xymonhome DIR       Set XYMONHOME
  --xymonclienthome DIR Set XYMONCLIENTHOME
  --xymonvar DIR        Set XYMONVAR
  --xymonlogdir DIR     Set XYMONLOGDIR
  --cgidir DIR          Set CGIDIR
  --securecgidir DIR    Set SECURECGIDIR
  --xymonuser USER      Set XYMONUSER
  --xymonhostname NAME  Set XYMONHOSTNAME
  --xymonhostip IP      Set XYMONHOSTIP
  --xymonhostos OS      Set XYMONHOSTOS
  --xymonhosturl URL    Set XYMONHOSTURL
  --xymoncgiurl URL     Set XYMONCGIURL
  --securexymoncgiurl URL  Set SECUREXYMONCGIURL
  --manroot DIR         Set MANROOT
  --httpdgid GROUP      Set HTTPDGID (webserver group)
  --enable-rrd yes/no   Set ENABLE_RRD
  --enable-snmp yes/no  Set ENABLE_SNMP
  --enable-ssl yes/no   Set ENABLE_SSL
  --enable-ldap yes/no  Set ENABLE_LDAP
  --fping PATH          Set FPING
  --mailprogram CMD     Set MAILPROGRAM
  --rrdinclude DIR      Set RRD include dir
  --rrdlib DIR          Set RRD library dir
  --pcreinclude DIR     Set PCRE include dir
  --pcrelib DIR         Set PCRE library dir
  --sslinclude DIR      Set OpenSSL include dir
  --ssllib DIR          Set OpenSSL library dir
  --ldapinclude DIR     Set LDAP include dir
  --ldaplib DIR         Set LDAP library dir
  --caresinclude DIR    Set C-ARES include dir
  --careslib DIR        Set C-ARES library dir
  --build-dir DIR       Override build directory (default: build-cmake) (NEW))
  --no-clean            Do not remove build directory before configuring (NEW)
  --no-build-install    Configure only (skip build/install) (NEW)

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 
(XXX) XXX-XXXX | X-XXX-XXX-XXXX | user-9678697f1438@xymon.invalid
One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com
facebook.com/lazboy  | instagram.com/lazboy | youtube.com/lazboy

Yep, I’ve progressed to the point I can compile it using the spec file but it still errors out after the compile finishes.  I had to figure out what kind of environment I can use to compile them in on Github actions, what software dependencies are required, and how to compile it.  I’ve been using the existing spec file as a reference but not everything works untouched.  It’s coming along nicely so far.  Just takes time.

 

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

From: Jeremy Laidman <user-0608abae5e7c@xymon.invalid>
Sent: Wednesday, January 28, 2026 9:39 AM
To: Xymon mailinglist <xymon@xymon.com>
Subject: [Xymon] Re: workflow updates

 

Many years ago I built a xymon package from the spec file. It was relatively straightforward, and it even applied a list of patches automatically. I would start with an SRPM file from Terabithia, which should have everything you need to build an RPM, including spec file and patches that JC deemed useful (either bug fixes that hadn't made it into the source code, or adjustments to work with the OS such as locations of directories, startup scripts).

 

J

 

On Wed, 28 Jan 2026, 21:03 Nicola, <user-2c63804b6921@xymon.invalid> wrote:

I think you can start from an existing .spec file ) it's the "definition" of how RPMs are built: with a bit of luck they wil work untouched.

 

Nicola

 

Nicola

Il giorno 27 gennaio 2026, alle ore 21:15, Scot Kreienkamp <xymon@xymon.com> ha scritto:

 

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 
(XXX) XXX-XXXX | X-XXX-XXX-XXXX | user-9678697f1438@xymon.invalid
One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com
facebook.com/lazboy  | instagram.com/lazboy | youtube.com/lazboy

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.