Hi — I'm the upstream author of Arctis Sound Manager. Thank you for packaging it for Terra; I only discovered it existed this week, through users.

The package currently declares no Requires: at all, so it installs without the audio stack and Python bindings it needs at runtime. On a system where those are already present everything works, which is presumably why it went unnoticed — but elsewhere users get failures that look like application bugs and aren't.

Two of these are behind reported upstream issues:
dependency what breaks without it
pulseaudio-utils provides pactl, used at GUI startup and for EQ/Sonar routing. A clean install crashes on launch with FileNotFoundError: 'pactl' — #117
ladspa-swh-plugins provides the reverb plugin the HeSuVi 7.1 virtual surround graph loads. Spatial Audio stays silent — #23

The Python bindings (pyside6, pyusb, pyudev, pulsectl, dbus-next, ruamel-yaml, pillow, babel) are imported at runtime rather than declared as build metadata, so they aren't picked up automatically either.

This list matches the spec I maintain alongside the source, where each entry carries the reason it's there.

Nothing else is touched — no version bump, no changes to %install, %files or the packager field.

Two things beyond this PR, if you're open to them:

I'd be glad to help keep this in sync. The project releases often (several times a week at the moment) and I'd rather Terra users get a package that works than have them file bugs against code that isn't the problem. Happy to send PRs when packaging-relevant things change, or to be pinged.

A heads-up on update.rhai: it tracks PyPI, and PyPI publication happens in the same workflow as the GitHub release, so the two can be briefly out of step. Source0 already points at the GitHub tag, so tracking GitHub releases directly would be marginally more reliable — entirely your call.

Thanks again for the packaging work.

Hello, I'm the one who packaged this. Thank you for the PR! I must have forgotten to PR your README with Terra install instructions (as I typically do this with my packages), I can do that soon here.

To address all your comments:

RPM auto generates runtime dependencies using the pyproject.toml, and it looks like all of the python3-* runtime deps you added here are already marked as runtime dependencies. below are the current auto generated runtime requirements of this package, which is pulling from here.

rpm -qpR python3-arctis-sound-manager-0_1.2.14-1.fc44.noarch.rpm                      

/usr/bin/python3
python(abi) = 3.14
python3.14dist(babel) >= 2.13
python3.14dist(dbus-next) >= 0.2.3
python3.14dist(pillow) >= 10
python3.14dist(pulsectl) >= 24.12
python3.14dist(pyside6) >= 6.10.1
python3.14dist(pyudev) >= 0.24.4
python3.14dist(pyusb) >= 1.3.1
python3.14dist(ruamel-yaml) >= 0.19.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1

So you should be able to safely remove these from the Requires: fields. All the other new Requires: looks good, my bad for not testing this as well as I should have!

>I'd be glad to help keep this in sync

Sure! I would very much appreciate PRs when there are new runtime deps/files to manually install/etc. The way Terra is set up, we have packages auto-update, I see Arctis-Sound-Manager update a lot and successfully build each time. Typically we have python packages use the python install macros so we catch all new/dropped files but Arctis-Sound-Manager has a lot of manually installed files as well, so if there are ever changes that are needed with new releases, PRs would be great!

>A heads-up on update.rhai

Noted, we generally prefer pypi over gh when possible due to GitHub API rate limits, and since Arctis-Sound-Manager updates so often I still do want it to track pypi, but if this ever becomes an issue let me know and I can change it over to the GitHub update function.

Also, could you bump the Release: 1%{?dist} to Release: 2%{?dist} to indicate a new package version? And if you'd like, a %changelog entry would be nice too.

Thanks again!

Thanks for the quick and thorough review — you were right on the Python bindings, and I've addressed all three points.

Dropped the python3-* requires. I'd assumed they weren't derivable because they're imported at runtime rather than linked, but of course the generator reads pyproject.toml, and your rpm -qpR output settles it — all eight are already there with their version constraints. What's left is only what RPM genuinely cannot infer: things reached through the filesystem or dlopen, where there's no metadata to read. I've said as much in a comment above the block so the next person doesn't re-add them.

Bumped to Release: 2%{?dist} and added a %changelog entry.

Rebased onto current frawhide. Your auto-update had moved the spec to 1.2.19 in the meantime, so the branch is now a single commit on top of that rather than a stale 1.2.14 base — the Release: 2 applies to 1.2.19.

On keeping this in sync: noted, and thank you. I'll send a PR whenever a release adds a runtime dependency or changes what gets installed manually. Two things worth flagging since you mentioned the manual installs — the udev rules file is generated at build time from the device profiles (scripts/generate_udev_rules.py), so it changes silently whenever a headset is added, and the dinit service templates are installed by hand for distros without systemd. Neither shows up as a new file, so neither would break your build; I mention them only so you know which parts of %install aren't inert.

And understood on update.rhai — PyPI is fine, the two are usually minutes apart. I'll only raise it if a real gap shows up.

This all looks good now, thank you!

💚 All backports created successfully

Status	Branch	Result
✅	el10
✅	f43
✅	f44
✅	f45

Questions ?

Please refer to the Backport tool documentation and see the Github Action logs for details