satdump-devel). These notes cover how to build it, the non-obvious fixes baked into the spec and why they're there, and what's still worth double-checking.

Building

sudo dnf install rpm-build rpmdevtools
rpmdev-setuptree

# rpmbuild doesn't fetch Source URLs itself - spectool does that, pulling
# down the main tarball plus the two patched sol2 header files (see below)
cd ~/SOURCES
spectool -g ~/SPECS/satdump.spec

sudo dnf builddep ~/SPECS/satdump.spec
rpmbuild -ba ~/SPECS/satdump.spec

Resulting packages land in ~/RPMS/x86_64/. Optional features can be trimmed at build time:

# headless build, e.g. for a relay/server box
rpmbuild -ba ~/SPECS/satdump.spec --without gui --without live

# bladeRF support (off by default - see below)
rpmbuild -ba ~/SPECS/satdump.spec --with bladerf

If you only changed something in %files or later and don't need a full recompile, --short-circuit skips straight past %prep/%build using what's already in ~/BUILD/:

rpmbuild -bb --short-circuit ~/SPECS/satdump.spec

Why the spec patches two things before building

sol2 (Lua binding library), via Source1/Source2. 1.2.2 vendors sol2 3.2.3, which has a real bug: sol::optional<T&>::emplace() calls a construct() member that doesn't exist on that partial specialization. Older GCC never checked that unreached branch closely enough to catch it; GCC 13+ (Fedora 44 ships GCC 15) turns it into a hard build failure. This is upstream's own bug, not something Fedora-specific — traced their git history to the exact commit (2b0a874f3) where they fixed it by bumping the vendored header to a newer generated release (the same fix Debian's 1.2.2 package ships). Since SatDump 2.0 drops Lua entirely for AngelScript, there's no later tagged release with the fix to pull a clean tarball from, so Source1/Source2 point at the two files from that exact commit, and %prep copies them over the vendored ones. This is done via proper Source tags rather than a mid-build curl, since Fedora's real build systems (mock, koji, Copr) run %build with no network access.

Vendored libacars (inmarsat_support plugin), via sed in %prep. GCC 15 switched its default C dialect from -std=gnu17 to -std=gnu23. C23 changed what an unprototyped declaration like void (*node_free)() means — from "unspecified arguments" (compatible with anything) to "takes no arguments." The plugin's vendored libacars copy declares its callback-list functions (la_list_free_full, la_list_foreach, la_list_free_full_with_ctx in list.h/list.c) exactly the old way, so every real call site now mismatches. This isn't libacars-specific — it's a known, wide-reaching GCC 15 migration issue. Forcing -std=gnu17 globally via CMAKE_C_STANDARD does not reliably work here: this plugin's own CMakeLists.txt has a nested cmake_minimum_required(VERSION 3.12), which resets CMake's effective policy version for that subdirectory below 3.22 (CMP0128, which governs -std= flag selection), so CMake can silently skip emitting the flag at all. The actual fix is narrower and more reliable: give the three declarations/definitions real prototypes matching how every call site already uses them (verified against every call site in the plugin, not just one file, and compile-tested against GCC's C23 behavior with zero errors).

Other decisions baked into the spec

%global debug_package %{nil} — this build's LTO flags (-flto=auto -ffat-lto-objects, applied across ~15 plugin .sos plus the core library) confuse Fedora's automatic debuginfo extraction into leaving orphaned /usr/lib/debug/... files that never make it into an auto-generated -debuginfo/-debugsource package, which fails the build with "installed but unpackaged files." Skipping debuginfo packaging entirely is the simplest reliable fix. If you want real debuginfo later (e.g. distributing this more broadly), disabling LTO for the build is the more likely fix than fighting find-debuginfo.sh.
bladeRF is off by default (%bcond_with bladerf, note this is the one bcond that defaults off, unlike all the others). Fedora's repos don't carry Nuand's bladeRF/libbladeRF at all — confirmed directly against a live Fedora 44 system (dnf: "No match for argument: bladeRF-devel"). SatDump's own bladerf_sdr_support plugin already handles a missing bladeRF gracefully via find_library() and just skips building that one plugin with a log message, so this was never going to hard-fail the build either way — pass --with bladerf and install bladeRF-devel yourself only if you've already built libbladeRF from source.
OpenCL-ICD-Loader-devel, not ocl-icd-devel. Fedora replaced the ocl-icd OpenCL loader with the Khronos-official OpenCL-ICD-Loader; the two conflict by design (both provide the same functionality), and Fedora 44 installs the latter by default.
No hicolor icon-theme entry. SatDump doesn't use the standard /usr/share/icons/hicolor/<size>/apps/... layout most GUI apps do — it installs a single flat icon.png under /usr/share/satdump/, and satdump.desktop's Icon= line points at that exact absolute path (valid per the desktop-entry spec, just less common than icon-name lookup). That's already covered by the general %{_datadir}/satdump/ line in %files, so there's nothing extra to add here.
satdump-devel subpackage. SatDump installs a full public C++ SDK: libsatdump_core.so and libsatdump_interface.so as real shared libraries (which the CLI, SDR server, and every plugin .so link against at runtime, so both live in the main package, not devel-only), plus roughly 400 headers under /usr/include/satdump/, which get their own satdump-devel subpackage (Requires: satdump = ...).

Things that might still need attention

NNG version. SatDump's docs mention needing a minimum NNG version and, on distros where the packaged one is too old, building it from source (git clone https://github.com/nanomsg/nng.git -b v1.9.0). Fedora 44 ships nng-devel at 1.9.0, which has built cleanly so far — but if a future SatDump release bumps its minimum and find_package(nng) starts failing, the fallback is vendoring NNG as an additional SourceN tarball and building it in %build before SatDump's own %cmake step.

Lua 5.5. Not a problem on Fedora 44 (still on Lua 5.4 — the bump to 5.5 is a Fedora 45 change), but if this spec ever gets rebased for Fedora 45+: SatDump 1.2.2's Lua binding code doesn't compile against 5.5 (removed LUA_ERRGCMM etc., the same break other distro packagers have hit). The next major SatDump release drops Lua for AngelScript entirely, so this only matters for 1.2.x.

OpenCL at runtime. OpenCL-ICD-Loader-devel/opencl-headers get you the build-time loader; the runtime machine still needs an actual ICD installed (intel-opencl, rocm, a vendor driver, etc.) for -DBUILD_OPENCL=ON to do anything — otherwise projections silently run on CPU instead.

Desktop file validation. %check runs desktop-file-validate on satdump.desktop. If a future upstream change to that template fails strict validation (missing Icon=, categories, etc.), either patch it in %prep or drop the %check section rather than let a cosmetic issue block the whole build.

Sanity-check after install

sudo dnf install ~/RPMS/x86_64/satdump-1.2.2-1.fc44.x86_64.rpm
satdump --help
satdump-ui   # if built with GUI support