Hi Michael, We just did a major release to GSequencer v4.0.0 we migrated to Gtk4 and libsoup-3.0, thereby.
https://savannah.nongnu.org/forum/forum.php?forum_id=10187 For webkit2gtk-4.0 we had a replacement to show the manual as PDF using libpoppler-glib. During transition, I had to disable webkit2gtk-4.0 in order to avoid symbols from libsoup-3.0 provided by webkit2gtk-4.1 Thank you for providing additional background. Thought, libsoup code is only reachable from the API. If you enable OSC Server in GSequencer you get SLIP encoded TCP/UDP stream. This is local only. http://krähemann.com/howtos/ags-osc-docs/index.html http://krähemann.com/api/libags/4.0.8/xml-rpc.html http://krähemann.com/api/libags-audio/4.0.8/audio-osc-over-xmlrpc-server.html The AGS-OSC-OVER-XMLRPC is rather esoteric and didn't manually test for a while. And I am missing a login controller. We do some sort of cookie based authentication and sessions. https://packages.fedoraproject.org/pkgs/gsequencer/gsequencer/ Fedora 35 didn't get the 4.0.x series release, I just ignored it. libsoup-2.4 really served its purpose. Had a lot of fun. regards, Joël On Thu, May 26, 2022 at 9:37 PM Michael Catanzaro <mcatanz...@gnome.org> wrote: > > Hi developers, > > If you maintain a package that depends (directly or indirectly) on > libsoup, this mail is important. ***Lots of applications depend > indirectly on libsoup, even if you don't realize it!*** > > libsoup 3 (Fedora package: libsoup3) is incompatible with libsoup 2 > (Fedora package: libsoup). For better or for worse, the two cannot be > linked into the same process, similar to GTK major versions. If libsoup > 2 and 3 get linked into the same process, they will crash at runtime. > This means the transition from 2 -> 3 is going to be difficult and > awkward, because libsoup is often used by libraries, and all libraries > used by an application have to transition at the exact same time or > else the application will crash at runtime. Whereas with GTK we have a > few libraries that depend on GTK and need ported, with libsoup there > are many more affected libraries. Accordingly, *this will not go as > smoothly as we'd like.* > > Still, hopefully we can manage this transition without applications > winding up broken in stable Fedoras. The smoothest transition path is > for upstream libraries to provide a different API version for libsoup2 > and libsoup3 versions, and ensure they can be parallel-installed. Some > upstreams will do this while maintaining both versions at once, while > others will depend on libsoup 3 for newer releases and use libsoup 2 > for older/stable releases. Either way is fine. Parallel-installability > provides Fedora and other downstreams with maximum flexibility to > manage the process. Libraries that use libsoup but do not provide > parallel-installable API versions will be much harder to deal with, > because apps that use libsoup 3 will be broken until the library > switches to libsoup 3, and apps that use libsoup 2 will be broken after > the library switches to libsoup 3. If the library has many > dependencies, then it's hard to win in this situation. > > Now because libsoup is a sensitive network-facing HTTP library written > in an unsafe language and where CVEs may have disastrous impact, it is > not safe to leave libsoup 2 hanging around indefinitely like GLib 1 and > GTK 1. My proposal is to retire libsoup 2 in *Fedora 39* and for > packagers to not attempt to bring it back after that happens. Proposed > timeline: > > * September 2021 (done): libsoup 3.0 released > * January 2022 (done): libsoup3 packaged for Fedora, included in F36 > * Today: the perfect time to port your packages away from libsoup2! > * October 2022: Fedora 37 released with both libsoup 2 and libsoup 3 > * February 2023, right after F38 is branched: retire libsoup2 from > rawhide, packages that depend on it break in rawhide > * April 2023: Fedora 38 released with both libsoup 2 and libsoup 3 > * August 2023, ahead of F39 beta freeze: package carnage, retire all > packages that still depend on libsoup 2 > * November 2023: Fedora 39 released without libsoup 2 > > Hopefully the 1.5 year timeline should leave adequate time for > developers and maintainers to upgrade, while also acknowledging that we > cannot wait forever and will not successfully port everything. Some > packages will likely be retired at the end of this process, but > hopefully we can keep that to a minimum. (GNOME upstream is trying to > take care of GNOME core stuff, but we cannot possibly attempt to port > all the extra apps or everything else that is in Fedora.) > > Lastly, a special note on WebKitGTK. WebKitGTK especially benefits from > libsoup 3 because libsoup 3 can do HTTP/2 and libsoup 2 cannot. There > are three relevant APIs: > > * webkit2gtk-4.0: this is WebKitGTK for GTK 3 and libsoup 2 > * webkit2gtk-4.1: this is WebKitGTK for GTK 3 and libsoup 3 > * webkit2gtk-5.0 (subject to change): this is WebKitGTK for GTK 4 and > libsoup 3 > > I intend to package -4.1 and -.5.0 soon and maintain them both > indefinitely in the same source package. Neither are packaged yet, so > you can't actually use them yet, but they'll be available soon. I > intend to retire -4.0 at the same time libsoup2 is retired, if we stick > to the proposed schedule above. (Only if libsoup 2 remains longer than > I propose above would I be interested in removing -4.0 sooner.) The > -5.0 package does not yet have stable API/ABI, but probably will in > time for Fedora 37. > > Michael > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
