Thank you for the detailed analysis Stuart.
It's true that Gradio has largely disappeared from the packaging in Linux distributions after the author deprecated it and stopped development. The replacement, Shortwave, is a heavier-weight program written in Rust, and from memory downloads hundreds of crates when building. It is also more tightly integrated with Gnome.
There is a similar program, Tuner [1], which is written in Vala and uses libsoup 3.x. I have used it on Linux installs and it does effectively the same job despite some quirks. I will have a go at building it on 7.6 and see if I can create a port, a process new to me.
Or are there other lightweight alternatives?
--
Chris Billington
[1] https://github.com/louis77/tuner
It's true that Gradio has largely disappeared from the packaging in Linux distributions after the author deprecated it and stopped development. The replacement, Shortwave, is a heavier-weight program written in Rust, and from memory downloads hundreds of crates when building. It is also more tightly integrated with Gnome.
There is a similar program, Tuner [1], which is written in Vala and uses libsoup 3.x. I have used it on Linux installs and it does effectively the same job despite some quirks. I will have a go at building it on 7.6 and see if I can create a port, a process new to me.
Or are there other lightweight alternatives?
--
Chris Billington
[1] https://github.com/louis77/tuner
On 6 December 2024 12:19:06 UTC, Stuart Henderson <stu@spacehopper.org> wrote:
On 2024/12/06 17:16, Chris Billington wrote:Unfortunately, since upgrading to 7.6, audio/gradio crashes for me when selecting any station for playback, with a libsoup error as follows:
(gradio:65131): libsoup-ERROR **: 17:03:20.678: libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.
Trace/BPT trap
I am pretty sure that the same version, 7.3 worked fine on 7.5.
$ pkg_info -Q libsoup
debug-libsoup-2.74.3p1
debug-libsoup3-3.6.0
libsoup-2.74.3p1 (installed) # gradio installs this
libsoup3-3.6.0 (installed) # used by many other packages
libsoup3 seems to be being loaded in preference to libsoup2. Does anyone have any ideas on how to debug this error?
gstreamer1-plugins-good includes libgstsoup which explicitly links to
libsoup3. libgstsoup does also have a mechanism to detect the correct
version of libsoup and load it dynamically at runtime, but this is
neutered because it records libsoup3 as a dependency:
$ objdump -p /usr/local/lib/gstreamer-1.0/libgstsoup.so|grep NEEDED
NEEDED libgstreamer-1.0.so.7.2
NEEDED libgobject-2.0.so.4200.20
NEEDED libglib-2.0.so.4201.13
NEEDED libintl.so.8.0
NEEDED libgstbase-1.0.so.7.2
NEEDED libgsttag-1.0.so.7.2
NEEDED libgio-2.0.so.4200.20
NEEDED libsoup-3.0.so.0.4
Two possible ways around this,
1. find out what's going on with gstreamer1-plugins-good/libgstsoup
and change that so it only loads libsoup dynamically again.
2. rewrite parts of gradio to work with the newer version of libsoup.
However, there's a question of whether it's worthwhile.
gradio was discontinued upstream some time ago in favour of another
radio player "shortwave" and other OS don't seem to be packaging
gradio any more (FreeBSD used to have it but it had been broken
there for a while due to other updates and then they removed it).
This means both that it doesn't look like there are existing patches
to borrow from for 2), and that there's a good chance other changes
in the ecosystem would result in gradio getting broken again for
other reasons, so there's a question of how worthwhile it is.
1) may be worth looking at, but there's a good chance that at this
point it only actually affects gradio (in which case the same
question applies).
The only packages using both gstreamer and libsoup 2 besides gradio
are qtwebkit and webkitgtk40, and I think it's unlikely that things
using those will also be using gstreamer's libgstsoup (it adds direct
http/https support to gstreamer) as they'd probably be downloading
things themselves anyway.
No comments:
Post a Comment