Package Details: sdrpp-git 1.0.4.r561.eab4264-1

Git Clone URL: https://aur.archlinux.org/sdrpp-git.git (read-only, click to copy)
Package Base: sdrpp-git
Description: The bloat-free SDR receiver
Upstream URL: https://www.sdrpp.org/
Keywords: sdr++ sdr-plus-plus
Licenses: GPL3
Conflicts: sdrpp
Provides: sdrpp
Submitter: ryzerth
Maintainer: thotypous (ryzerth, 2WheelDev, eclairevoyant, dnaeon)
Last Packager: eclairevoyant
Votes: 21
Popularity: 0.77
First Submitted: 2021-02-14 23:36 (UTC)
Last Updated: 2024-01-24 00:49 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

eclairevoyant commented on 2023-06-01 18:01 (UTC)

Thanks for suggesting the changes, updated. I moved some of the dependencies around as some of them are needed for specific plugins.

dnaeon commented on 2023-06-01 14:35 (UTC)

@eclairevoyant, thanks for the feedback!

I've just built the package in a clean chroot and updated the PKGBUILD.

Here's the final patch, that I have. Should be fine now.

Thanks!

eclairevoyant commented on 2023-06-01 12:58 (UTC)

@dnaeon The "build" section in the README is for macos specifically, but yeah if upstream is using those flags in CI then sure it makes sense to add those. Just from skimming there are some differences in flags between CI and docker build, I can take a look later today regarding those.

As far as dependencies, I would recommend that you always build in a clean chroot, otherwise it is easy to miss dependencies. With the two flags you added, at minimum we must add portaudio and codec2 for it to build, I'll check later today if there are any other changes needed.

dnaeon commented on 2023-06-01 12:43 (UTC)

Hey @eclairevoyant,

I've used these build flags as they are the ones provided by the upstream repo.

Also, same flags are being used by the sdrpp pipelines.

I didn't update the dependencies, because there was no need, but I might have overlooked something.

@eclairevoyant, can you please tell me what build errors you are getting?

@thotypous, thanks for adding me as co-maintainer! I'll need some time though to go over the AUR submission guidelines :)

P.S: On a second thought, the m17_decoder and new_portaudio_sink are flagged as beta, so it might be a good idea to remove them altogether. Thoughts?

eclairevoyant commented on 2023-06-01 11:40 (UTC)

@dnaeon why those flags specifically? And if you use those flags surely you need to update the dependencies accordingly, it doesn't even build as is.

eclairevoyant commented on 2023-06-01 11:35 (UTC)

Re: the audio issues, it's an rtaudio issue as the linked issues explained.

Re: maintainership, I would 100% be against ryzerth being the sole maintainer if he's not interested in actually, as the name says, maintaining the PKGBUILD. PKGBUILDs must follow certain guidelines and also build properly, if they don't do that then someone who will correct those issues must maintain the PKGBUILD instead.

thotypous commented on 2023-06-01 11:33 (UTC)

@dnaeon Your PKGBUILD looks fine. I added you as co-maintainer. Can you please commit?

thotypous commented on 2023-06-01 11:30 (UTC)

About jack:

PipeWire jack emulation is currently a little unreliable with RtAudio. I'm not sure whether that's a RtAudio issue or a PipeWire issue.

Anyway, it does not seem like disabling Jack support would be an acceptable solution for that issue, since some users may be using Jack instead of PipeWire!

There is actually a much simpler solution which does not involve messing with Jack users. PipeWire users just need to disable Jack emulation by setting:

export PIPEWIRE_NOJACK=1

About the maintainer situation

I'd be pissed off too if the PKGBUILD for the software I maintained upstream was disowned.

I'd like to once again make it clear it was not me who asked the package to be disowned. I just received a notification via e-mail because I follow the package and decided to take it so that it didn't remain orphaned. Then I added Alexandre Rouma and some people who contributed to the PKGBUILD in the past as co-maintainers.

For people who don't understand how co-maintainership works, it effectively gives complete access for changing the PKGBUILD. It works as if the package had multiple maintainers. One does not need to ask permission to the other.

Of course it is still unfair that the original maintainer (also the upstream developer) is listed inside parenthesis, so if he wants to come back as the main maintainer we can arrange for that.

dnaeon commented on 2023-06-01 07:38 (UTC)

FYI: here's an updated PKGBUILD, which I use based on the latest build flags for SDRPlusPlus.

https://gist.github.com/dnaeon/38562a5c8f814f319ef4298d4e34acb9

eclairevoyant commented on 2023-05-15 22:31 (UTC)

Might need some patches, I haven't looked into it myself since I build the -git version instead. It is quite an old release...

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »