phodav and spice-gtk were recently rebuilt against libsoup3: https://koji.fedoraproject.org/koji/buildinfo?buildID=1996488 (phodav) https://koji.fedoraproject.org/koji/buildinfo?buildID=1996544 (spice-gtk) Unfortunately this broke Boxes, because it's now linked against both libsoup2 and libsoup3. Boxes itself, and some of its other deps like libosinfo, are built against libsoup2; spice-gtk and phodav - which it also depends on and builds against - are linked against libsoup2. To fix this we either need to build spice-gtk and phodav against libsoup2 again (if the new versions still can be built against 2), or update all the other deps, including libosinfo and I think webkitgtk, to build against libsoup3. CCing mcatanzaro who seems to have irons in this fire, and Marc-André who bumped spice-gtk and phodav. Proposing as a Final blocker as a violation of the 'default application functionality' rules (Boxes is completely broken).
sigh, description should read "Boxes itself, and some of its other deps like libosinfo, are built against libsoup2; spice-gtk and phodav - which it also depends on and builds against - are linked against libsoup3." , sorry.
Fortunately libosinfo and Boxes are both ready for libsoup 3, but should wait for FESCo approval of the change proposal before actually switching them over. It's not the end of the world for Boxes to be broken temporarily in rawhide until the change proposal is either approved or rejected. Once FESCo has decided one way or the other, then we'll know which way to go to fix it. (Boxes is lucky. We have some apps that will not be possible to fix so easily....)
Adding David to CC just as an fyi, both for Boxes and because this will affect a large number of other packages from the forthcoming GNOME 43.alpha.
This needs libosinfo build update: https://src.fedoraproject.org/rpms/libosinfo/pull-request/3 And webkit2gtk3, what's the status there?
Pff the can of worms.. @mcatanza, wouldn't it be possible to run soup2 & soup3 in the same process if the library was using a version scripts (on systems that support it) ? We would then mass-rebuild all packages that BR on libsoup2/3 and be good for an easier transition time I guess.
(In reply to Marc-Andre Lureau from comment #4) > And webkit2gtk3, what's the status there? It's ready upstream and other distros have deployed it successfully, but it's stalled in Fedora because I haven't decided what to name the package yet. I will endeavor to select a name before FESCo approves the libsoup 3 change proposal so that we don't lose time. (In reply to Marc-Andre Lureau from comment #5) > @mcatanza, wouldn't it be possible to run soup2 & soup3 in the same process > if the library was using a version scripts (on systems that support it) ? Nope, it will still crash and burn due to GObject name conflicts. We'd need to rename all the objects from SoupFoo to Soup3Foo to avoid this. (And if we do that, might as well rename the functions too, and then we no longer need symbol versioning anymore.) FWIW upstream has admitted that not changing the namespace was a mistake, but releasing a libsoup 4 to correct this does not seem very desirable either.
*** Bug 2107099 has been marked as a duplicate of this bug. ***
This also affects virt-manager, so there's no great way to graphically use VMs in Rawhide right now. I downgraded libphodav and spice-gtk3 / spice-glib to get around it.
This also affects remmina in rawhide.
*** Bug 2105650 has been marked as a duplicate of this bug. ***
*** Bug 2106670 has been marked as a duplicate of this bug. ***
We got approval from FESCo to implement the libsoup 3 change on Friday last week. Today I started working on packaging WebKitGTK. Kalev is aiming to fix this tomorrow, before the mass rebuild, but the exact timing remains uncertain.
Should be fixed in gnome-boxes-43~alpha-1.fc37 that's part of GNOME 43.alpha megaupdate, https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b0af1bd87
FEDORA-2022-1b0af1bd87 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.