Hi Jaime,
CentOS 7 is just one test among others. I added it to*exercise a specific scenario: the transition away from PCRE1 toward PCRE2*. It shows that even an older platform can still build successfully despite ongoing changes, which supports the conclusion that *dropping PCRE1 is a viable path and that we do not need extra complexity via a compatibility layer*. No specific effort is being made to maintain CentOS 7, and it may be removed in the future.
Also, this list is not an “officially supported OS” list. It is simply a list of environments where the build currently works (this does not mean it will not work on other systems). There is no formal support policy yet, and as discussed, we likely do not need to support very old OS versions. That said, I should make the purpose of this list clearer.
Bruno
Le 09.03.2026 à 01:42, Jaime Kikpole via Xymon a écrit :
Since CentOS 7 went EOL in mid-2024, are you sure you want to keep supporting it? I have no preference, since I migrated off after the EOL announcement, but I thought it might be worth asking. I certainly wouldn't want support for a functionally dead OS to hold back support for current OSs, like current releases of Rocky and Alma.
Kind of a random thought. Take it for what it is. Namely, the opinion of someone who isn't doing any of the work. :)
Jaime Kikpole
Director of Technology Ichabod Crane Central School District (518) 758-7575, x5425
On Sat, Mar 7, 2026, 3:31 AM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi all, As you may know (or not), I am currently**working on*delivering a functional CMake build*: - *It will run in parallel with the current build process for as long as needed; the existing build and packaging tools remain fully usable and untouched.* - *It should help us automate distribution packaging* and improve/optimize the packaging workflows over time, and also incorporate some of Terabithia's build improvements (futur). Unfortunately, parts of the *current build process are now impacted by changes in upstream package availability and major changes in linked libraries.* Since I do not want to build a migration path on top of an obsolete baseline, *I (we) first need to resolve the remaining package-related build issues.* This also aligns with the work already done by Roland (Debian) that is not yet fully merged into main, but is already published in the Debian distribution. To ensure a working CMake build, I need a clear and comprehensive overview of the current (legacy) build, so *we can later compare both build systems reliably.* For that, *I created a CI tool that builds using the existing flow (configure, make, make install) *- and it also works with the new CMake build - and *collects build and install status, along with additional detailed information to support build comparisons. *This is a high-level summary of some of the information the tool provides: *OS coverage and build variant lanes (see below for details) and package dependencies info * *- Scope: 177 lane jobs* *- Outcome: 165 passed, 12 failed * CI environment note: *this CI pipeline runs on GitHub infrastructure only *(GitHub-hosted runners), using the available execution backends there (Docker containers, host-based jobs, and VMs where applicable).*It does not assume any external or self-hosted build environment*. (This tool is not currently available on the upstream repo, but it is already available on my branch (see link below) and will be added upstream when ready? and more reliable.) This run also includes preliminary work to *capture per-lane package dependencies*, to establish a *baseline for the future CMake build*. Note: this is not produced by CMake (but it can); *it is generated using the standard legacy build flow* (configure, make, make install). Bugs may still exist in this baseline/dependency extraction work. *OS coverage summary:* *Fully passing (all lanes passed):* - Alpine (3.19-3.23, edge) amd64/arm64 - Arch Linux (base/latest) - CentOS 7 - Debian 11.11-slim amd64/arm64 - Debian 12.13-slim amd64/arm64 - Fedora 40/41/42 - FreeBSD 13.5 / 14.3 / 15.0 - macOS 14 / 15 / 26 / latest (work in progress; not fully available yet, despite what these tests might suggest) - NetBSD 9.2 / 9.3 / 9.4 / 10.0 / 10.1 - OpenBSD 7.6 / 7.7 / 7.8 - openSUSE Leap 15.5 / 15.6 / 16.0 - Oracle Linux 8 / 9 - Rocky Linux 8 / 9 - Ubuntu 20.04 / 22.04 / 24.04 (amd64/arm64) *Not fully passing (some lanes failed):* - AlmaLinux 10: PASS ct-server; FAIL ct-client and Server - Debian 13.3-slim (amd64/arm64): PASS ct-server; FAIL ct-client and Server (see note) - openSUSE Tumbleweed: PASS ct-server; FAIL ct-client and Server - Oracle Linux 10 (arm64 and 10-slim amd64): PASS ct-server; FAIL ct-client and Server Note:* - Debian 13.3 (Trixie)* has been patched by Roland, so installation works from the standard apt repositories for all lanes. -*Variant "ct-client"* is a client build that can perform some of the work normally done on the server on the client host; it does not appear to be widely used in practice. *All current failures are PCRE dependency-related* and*fail to build using standard distribution repositories* (no extra/third-party repos). The PCRE-related failures are a blocking prerequisite, and they likely conceal additional package dependency issues that will only become visible once PCRE is fixed. *Some next fixes (PRs) are already prepared but still need review:* - rrd: detect argv const-ABI (1.9+/1.8 backports) and drop RRDtool <1.2 gates (PR #80) - snmpcollect: switch MD5 to SHA1 when MD5 is unavailable (PR #75) *The PCRE work (PR #5) and these two fixes should resolve the package dependency issues* we are currently experiencing (and that also block my progress), and should bring the main branch much closer to Roland's work. For more info on this analysis: *https://github.com/bonomani/xymon/actions/runs/22792414183* Bruno _______________________________________________ Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-leave@xymon.com