# satdump_fedora

satdump packaged for Fedora

# Building SatDump 1.2.2 as an RPM on Fedora 44

This spec has been through several real `rpmbuild` runs on an actual
Fedora 44 system and now produces a working, installable RPM (`satdump`
+ `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

```bash
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:

```bash
# 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/`:

```bash
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 `.so`s 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

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