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
_______________________________________________