Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)
On Thu, 2022-05-26 at 14:37 -0500, Michael Catanzaro wrote: > Still, hopefully we can manage this transition without applications > winding up broken in stable Fedoras. Hi, for what it's worth, I have a COPR repo for Fedora 36, which includes several packages to use/build with/... libsoup3: https://copr.fedorainfracloud.org/coprs/mcrha/evo-soup3/ It replaces core packages (which might get obsolete by regular f36 updates eventually) as much that it includes also gnome-shell and others. The libsoup3 version there uses branch: https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/283 which is important for the evolution-data-server and the other evolution packages (to be tested in action soon). Other packages have included (or enabled) their changes from a porting tracker bug on the libsoup side: https://gitlab.gnome.org/GNOME/libsoup/-/issues/218 I did not cover all the packages from the default Workstation install, I skipped gnome-boxes (Vala, huh), gnome-photos and gnome-maps. With these removed one can replace the GNOME to the libsoup3 version. The grilo-plugins package is just hacked to remove the libsoup parts, because it doesn't have any proposed porting patch. There might be more hacks in the packages, I do not recall what I tweaked where precisely. That being said, if anyone wants to do any early testing of their project(s), then this can be a good starting point. I can add more packages, if anyone throws a source rpm at me (not by mail, just a link to it). Bye, Milan ___ 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
Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)
On 26. 05. 22 21:42, Ben Cotton wrote: Thanks for the long lead time. If you submit this as an F39 Change proposal now, you'll be the very first for that release (and perhaps even break churchyard's unofficial "most in-advance Change proposal submission). You can, of course, wait a while to do this, too. Let me correct that shortly. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)
On Fri, May 27 2022 at 12:15:33 AM +0200, Joël Krähemann wrote: For webkit2gtk-4.0 we had a replacement to show the manual as PDF using libpoppler-glib. This is fine IMO since it's your own PDF that you control and know will not be malicious. (For untrusted PDFs, WebKit is way more secure than poppler-glib.) 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
Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)
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 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 > lib
Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)
On Thu, May 26 2022 at 03:42:55 PM -0400, Ben Cotton wrote: Thanks for the long lead time. If you submit this as an F39 Change proposal now, you'll be the very first for that release (and perhaps even break churchyard's unofficial "most in-advance Change proposal submission). You can, of course, wait a while to do this, too. I agree it needs an F39 change proposal. I'll add it to my TODO list. ___ 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
Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)
Thanks for the long lead time. If you submit this as an F39 Change proposal now, you'll be the very first for that release (and perhaps even break churchyard's unofficial "most in-advance Change proposal submission). You can, of course, wait a while to do this, too. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
