Source: satdump
Version: 1.2.2+git20260527.6e4757c31+dfsg-3+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

satdump is completely unusable as shipped: it aborts during startup on a
stock install, before reaching any subcommand.

$ satdump
[...] (C) TODOREWORK NO MORE CPP COMPOSITES!!!
terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr: __pos (which is 66) > this->size() (which is 26)
Aborted

CAUSE

Seven plugins in /usr/lib/x86_64-linux-gnu/satdump/plugins/ have a DT_NEEDED
entry on libxrit_support.so (and libfirstparty_support.so), but carry no
DT_RPATH or DT_RUNPATH, and the plugin directory is not in the dynamic
loader's search path (no /etc/ld.so.conf.d entry is shipped). The provider
libraries are present in that same directory, but dlopen() cannot resolve
them:

libelektro_arktika_support.so -> libxrit_support.so
libfengyun4_support.so -> libxrit_support.so
libfirstparty_loader_support.so -> libfirstparty_support.so
libfirstparty_support.so -> libxrit_support.so
libgk2a_support.so -> libxrit_support.so
libgoes_support.so -> libxrit_support.so
libhimawari_support.so -> libxrit_support.so

$ readelf -d /usr/lib/x86_64-linux-gnu/satdump/plugins/libhimawari_support.so \
| grep -E 'NEEDED|RPATH|RUNPATH'
0x0000000000000001 (NEEDED) Shared library: [libxrit_support.so]
(no RPATH/RUNPATH entry present)

$ ls -l /usr/lib/x86_64-linux-gnu/satdump/plugins/libxrit_support.so
-rw-r--r-- 1 root root 662224 /usr/lib/.../plugins/libxrit_support.so

The real error is masked by a second (upstream) bug -- see below. Recovered
by breaking on the exception constructor under gdb:

Error loading /usr/lib/x86_64-linux-gnu/satdump/plugins/libhimawari_support.so!
Error : libxrit_support.so: cannot open shared object file:
No such file or directory

Backtrace of the abort:

0000008 satdump::satdump_exception_t::satdump_exception_t(
std::string const&, char const*, int)
0000009 ?? () from /usr/lib/x86_64-linux-gnu/libsatdump_core.so
0000010 loadPlugins(std::map<...>&) from libsatdump_core.so
0000011 satdump::initSatDump(bool) from libsatdump_core.so

WORKAROUND

LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/satdump/plugins satdump

or, persistently:

echo /usr/lib/x86_64-linux-gnu/satdump/plugins \
| sudo tee /etc/ld.so.conf.d/satdump.conf
sudo ldconfig

With either applied, all plugins resolve, satdump --help, satdump probe
and satdump-ui start normally.

SUGGESTED FIX

Link the plugins with -Wl,-rpath,'$ORIGIN' so they find their siblings
without polluting the global loader path. Shipping an ld.so.conf.d snippet
works but exposes the plugin directory system-wide, which is less desirable.

SECONDARY BUG (upstream, reported separately)

satdump::satdump_exception_t's constructor unconditionally does substr(66)
on FILE to strip the build directory prefix. Under the Debian build the
path is "./src-core/core/plugin.cpp" (26 chars), so the constructor itself
throws std::out_of_range. Any plugin-load failure therefore aborts with an
unreadable error instead of the intended diagnostic. This is what turns the
packaging issue above into a bare "terminate called" abort. Filed upstream
at https://github.com/SatDump/SatDump.

-- System Information
Debian Release: trixie/sid (via Kali kali-rolling)
Architecture: amd64
Kernel: Linux 7.1.5+kali-amd64
Versions of packages satdump depends on:
ii satdump-data 1.2.2+git20260527.6e4757c31+dfsg-3