Description of problem:
Version 3.9.11 of libdmapsharing will build using libsoup3, but Rhythmbox uses libsoup2. One binary cannot draw in both libsoup2 and libsoup3. See https://gitlab.gnome.org/GNOME/libsoup/-/issues/218.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install the libdmapsharing package from https://koji.fedoraproject.org/koji/taskinfo?taskID=97397074.
2. Try to run Rhythmbox with the DAAP plugin enabled.
Rhythmbox cannot run with both libsoup2 and libsoup3.
There are a few options:
1. Apply Geoff Hill's work to port Rhythmbox to libsoup3: https://gitlab.gnome.org/GNOME/rhythmbox/-/issues/1996.
2. Temporarily build Rhythmbox against the 3.0 series of libdmapsharing, i.e., use the libdmapsharing package rather than the libdmapsharing4 package. Fortunately Rhythmbox presently supports both versions of the libdmapsharing API.
3. Temporarily deactivate the DAAP plugin in Rhythmbox.
This also applies to the Rhythmbox packages in Fedora 38 and Rawhide.
The libdmapsharing 3.9.11 package is in Bodhi at https://bodhi.fedoraproject.org/updates/FEDORA-2023-b4c98e1e92.
FEDORA-2023-81d818c740 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-81d818c740
Although I would have preferred to use libsoup3 in rhythmbox with Geoff Hill's port (which I adjusted as per your recommendation and can be found at https://src.fedoraproject.org/rpms/rhythmbox/pull-request/5 in a WIP form), grilo would have to be ported too, so this is shelved for the moment. I opted to use the old libdmapsharing instead.
Thank you, David. The primary reason for my haste in updating the libdmapsharing4 package (and thus disrupting Rhythmbox) is in support of the Grilo work. Grilo just merged support for libdmapsharing4 3.9.11 + libsoup3, and the lack of a libdmapsharing4 3.9.11 package in Fedora broke their CI/CD. My release of the libdmapsharing 3.9.11 package should fix their CI/CD pipeline. I think we will see a compatible Grilo release soon, so the use of the old libdmapsharing here should be short-lived.
Thank you kindly for your patience. I am doing my best to minimize the disruption as we all move to libsoup3, but this has turned out to be difficult! The good thing is that we are making progress. The larger migration to libsoup3 seems to be in reach.
Was about to file a new bug report about rhythmbox crashing on start after dnf updating my machine and found this. ... Why would you push an update to stable that is known to regress the user experience? If you want to support Grilo CI/CD, have them pull in libdmapsharing 3.9.11 from a COPR repo and keep it out of stable while issues with rhythmbox are being sorted out?
FEDORA-2023-81d818c740 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-81d818c740`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-81d818c740
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Rob, kindly review the update referenced above so that we can amass the karma required to mark the new Rhythmbox package as stable.
*** Bug 2170065 has been marked as a duplicate of this bug. ***
*** Bug 2170545 has been marked as a duplicate of this bug. ***
*** Bug 2170548 has been marked as a duplicate of this bug. ***
Almost missed this. I've just rebuilt grilo to use libsoup 3 in David's side tag. This is mandatory for GNOME 44 as gnome-music 44.beta depends on libsoup 3. But I've only done this in rawhide and F38. grilo in F37 needs to stay on libsoup 2 forever as to do otherwise would be a big compatibility break (e.g. this very bug report). I don't think switching libdmapsharing to libsoup 3 in F37 was a good idea. But I do very much appreciate that it was already using libsoup 3 in F38, since that made my work today easier.
Anyway, the update above should fix F37 (thanks David!) but we need to decide how to keep rhythmbox working going forward. We have two options:
(1) Rebuild with grilo dependency disabled and lose whatever functionality it provides, or
(2) Rebuild with libsoup 3 patch applied, switched to libsoup 3
Opinions welcome. I'm going to start with option (1) today to avoid adding a big patch to the package that I have not tested myself, but option (2) seems better in the long term and that's required to avoid losing the functionality provided by grilo.
FEDORA-2023-81d818c740 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.
Thank you, Michael. The things that were holding up the Rhythmbox/libsoup3 work, namely migrating grilo and libdmapsharing to libsoup3, are complete. Thus I hope to see the Rhythmbox libsoup3 work used. Preparing a Fedora 38 package would allow us to more easily test the patch, even if we do not immediately merge that work into the mainline Fedora 38 package. It would be nice to have some Fedora users help test Geoff Hill's work.
Out of curiosity, I went looking for an upstream merge request but couldn't find one. Any idea why?
I think (In reply to Michael Catanzaro from comment #14)
> Out of curiosity, I went looking for an upstream merge request but couldn't
> find one. Any idea why?
I think Geoff wanted to test his work more before creating a merge request. His work in progress is at https://gitlab.gnome.org/geoffhill/rhythmbox/-/tree/libsoup3. Now that grilo-plugins and libdmapsharing are ported, we can more easily help him test.
Jonathan has asked us to disable grilo temporarily rather than ship with the libsoup 3 patch, so seems I made the right call. Sounds like he's working on this now.
The libsoup3 code is now in Rhythmbox's master branch: https://gitlab.gnome.org/GNOME/rhythmbox/-/commit/50bd147a8b55581fe95b459a0a68dcf9b0a24893.