F37 Change Proposal: libsoup 3: Part One (System-Wide Change)
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == libsoup 3 is a new API version of libsoup that provides support for HTTP/2. Unfortunately, it is incompatible with libsoup 2. To avoid misbehavior, applications will crash on startup if linked to both libsoup 2 and libsoup 3 at the same time. Because many libraries depend on libsoup, and applications have limited control over which libsoup they link to transitively, this transition will be tricky and requires attention from all Fedora packages that depend on libsoup, even if only indirectly. == Owner == * Name: [[User:catanzaro| Michael Catanzaro]] * Email: == Detailed Description == libsoup 3 was introduced in Fedora 36, but nothing actually uses it yet. For Fedora 37 and GNOME 43, many GNOME applications and libraries will switch from libsoup 2 to libsoup 3. libsoup 2 will remain in Fedora 37 as a compatibility library. 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, but we are not yet ready to remove it altogether. We will propose removing libsoup 2 (and all applications and libraries that still depend on it) for Fedora 39 in a separate change proposal. For Fedora 37 and Fedora 38, we propose a transition period where both libsoup 2 and libsoup 3 will coexist. Applications can switch to libsoup 3 without significant impact on the rest of the distribution, but libraries switching to libsoup 3 are very disruptive. Libraries have a few options: * Recommended: provide a new API version for libsoup 3. This gives applications that depend on your library a transition period to switch from libsoup 2 to libsoup 3. Applications will bump to your new API version at the same time they transition to libsoup 3. If the application does not directly depend on libsoup and does not depend on libsoup via any other libraries, then this can be done at any time. Example: webkit2gtk-4.0 is the libsoup 2 version of WebKitGTK's GTK 3 API, while webkit2gtk-4.1 is the libsoup 3 version. Currently only webkit2gtk-4.0 is available in Fedora (via the webkit2gtk3 package), but webkit2gtk-4.1 will be made available as part of this change (package name TBD). * Not recommended: provide a build option to toggle between libsoup 2 and libsoup 3, while retaining the same API version. All applications that depend on your library must port to libsoup 3 at exactly the same time. Unfortunately, many GNOME libraries have selected this approach, and building these libraries with libsoup 3 enabled will be required for GNOME 43. Known affected libraries will include geocode-glib, libgweather, librest-1.0, and libosinfo. * Require libsoup 3 unconditionally. This option is suitable only for libraries used by very few applications. Because many GNOME libraries have adopted the second approach, applications that depend on these libraries, whether directly or indirectly, must take action immediately or they will crash on startup. This is far from ideal. This transition is unlikely to go smoothly, but if we work together and coordinate with our fellow package maintainers, we should be OK. == Benefit to Fedora == Transitioning to libsoup 3 adds support for HTTP/2 and allows Fedora to continue packaging the latest versions of GNOME. If we do not transition to libsoup 3, then we will be unable to update certain GNOME packages to the latest version. == Scope == * Proposal owners: The proposal owner is working upstream to ensure GNOME 43 is buildable without conflicts between packages that require libsoup 2 dependencies vs. libsoup 3 dependencies. The proposal owner will also package webkit2gtk-4.1 for Fedora 37. Because this is a large transition that will require the efforts of dozens of developers, the proposal owner can offer only limited help with individual Fedora packages. * Other developers: Check your applications and libraries for direct or indirect dependencies on libsoup using ldd. You must assess each situation individually to decide the best course of action. If you're not sure where a dependency on libsoup comes from, use the lddtree tool from the pax-utils package. If you wind up stuck in an impossible situation where your software depends on both libsoup 2 and libsoup 3 simultaneously, ask other packagers for help to resolve the situation. We will need to work together to solve these issues. * Release engineering: [https://pagure.io/releng/issue/10859 #10859] * Policies and guidelines: No policy changes required * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: No alignment with current objectives == Upgrade/compatibility impact == If applications do not link to both libsoup 2 and libsoup 3,
F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The flatpak remote for Flathub will have no filtering, making all the Flathub content available in GNOME Software and via the flatpak commandline. == Owner == * Name: Workstation WG * Email: mcla...@redhat.com == Detailed Description == Fedora includes a flatpak repo definition for Flathub in the fedora-flathub-remote package. So far, this remote was filtered by an allowlist that only made a limited subset of software from Flathub available. We've been told that it is ok for us to remove the filtering and make all of Flathub available. The filtering mechanism itself will still be there, and it will be possible for us to reinstate a filter via a package update, should the need arise in the future. The Flathub remote is available to users who opt-in to enabling third-party software repositories in either GNOME Initial Setup or GNOME Software. Users who do not opt in will not see anything from Flathub. In case of overlaps, GNOME Software will prefer Fedora flatpaks over Flathub flatpaks. It is always possible for the user to manually select a different source for individual applications. == Feedback == This change proposal has previously been discussed here: https://pagure.io/fedora-workstation/issue/300 == Benefit to Fedora == More software will be easily available to Fedora users. Additionally, the filtered Flathub has not been popular with users. Users have been confused and displeased that our Flathub remote contains only a small subset of Flathub, rather than the full Flathub. Dropping the filter will resolve this criticism. == Scope == * Proposal owners: Remove the allowlist in /usr/share/flatpak/fedora-flathub.filter, or replace it with one that allows everything * Other developers: GNOME Software developers: Verify that the priorities between repos and packaging formats work out as desired * Release engineering: No work needed * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == Existing Fedora installations with a configured Fedora Flathub remote will pick up the new, permissive filter. == How To Test == When third-party software is not enabled in GNOME Initial Setup or GNOME Software, search results from Flathub should not appear in GNOME Software. When third-party software is enabled in GNOME Initial Setup or GNOME Software, search results from Flathub should appear. == User Experience == When opening GNOME Software, all the applications that are available on Flathub will show up in search results. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: Reinstate the filtering we had in Fedora 36 * Contingency deadline: Beta * Blocks release? No == Documentation == * [https://pagure.io/fedora-third-party/blob/main/f/doc/fedora-third-party.1.md fedora-third-party] * [https://github.com/flathub/flathub/wiki Flathub wiki] * [https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remotes/ Comparison of Fedora Flatpaks and Flathub remotes] == Release Notes == The Fedora Flathub remote now exposes all content from Flathub, instead of only a small subset. Flathub is not enabled by default. To enable software from Flathub, turn on third-party software in GNOME Initial Setup or GNOME Software. -- Vipul Siddharth He/His/Him FPgM team member ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change Proposal: IBus 1.5.27 (System-Wide change)
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In IBus 1.5.27, `ibus restart` subcommand will be enhanced to be able to restart ibus-daemon in GNOME desktop, `ibus im-module` subcommand will be added to get internal gtk-im-module value in an GTK instance, ibus-setup will provides custom themes for the IBus candidate window. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * `ibus restart` subcommand will be enhanced to be able to restart ibus-daemon via systemd for GNOME desktop. ibus-daemon is launched via systemd in GNOME desktop. `ibus restart` will restart ibus-daemon with systemd at first and with an IBus API directly at second and it also provides `--help` option to get other option arguments for the subcommand and `--type=direct` and `--type=systemd` subcommands are available. * `ibus im-module` subcommand will be added to get an internal gtk-im-module value from an instance of an GTK instance. Some users would fail to setup IBus and this subcommand will help them to check whether "ibus" is set to the gtk-im-module in the actual process. * ibus-setup will provides custom themes in the "Advanced" tab for IBus candidate window. IBus candidate window is composed by GTK and If the current desktop is composed by GTK likes GNOME, the desktop provides a utility to customize the themes. But if not, this feature is useful for the users. == Benefit to Fedora == Users can restart ibus-daemon with `ibus restart`. When users install new IBus engines, ibus-daemon has to be restarted to load the new engine lists, If users might encounter a bug, users would like to restart ibus-daemon. IM developers also sometimes restart ibus-daemon to debug IBus or the engines. `ibus im-module` subcommand is also useful when a users failed to setup IBus. Providing IBus custom themes is useful for Plasma desktop which theme utility does not change GTK themes. == Scope == * Proposal owners: ibus * Other developers: NONE * Release engineering: * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == `ibus restart` should not have any regressions in any desktops. == How To Test == * IBus restart ** Log into GNOME desktop session ** Run `ibus restart` and then ibus-daemon PID is changed. * IBus im-module ** Run `ibus im-module` and get "ibus" * IBus custom theme ** Log into Plasma desktop session ** Run ibus-setup and configure IM engines in "Input Method" tab, who can show the candidate window likes ibus-libpinyin, ibus-anthy. ** Run ibus-setup and configure custom themes in "Advanced" tab and confirme the theme of the candidate window is changed. == User Experience == `ibus restart` command line interface is available to restart the input method features and ibus-setup provides custom themes for ithe appearance of the input method candidate window. == Dependencies == `ibus restart --type=systemd` requires systemd. `ibus im-module` subcommand requires gtk4 or gtk3 or gtk2. == Contingency Plan == * Contingency mechanism: Revert the change to IBus. * Contingency deadline: Beta release * Blocks release? No == Documentation == TBD == Release Notes == TBD -- Vipul Siddharth He/His/Him FPgM team member ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Firefox langpacks, which have been bundled in the Fedora firefox base package until now, will be moved to a firefox-langpacks subpackage. == Owner == * Name: [[User:Petersen| Jens Petersen]] * Email: * Name: [[User:Stransky| Martin Stransky]] * Email: == Detailed Description == The firefox packages carries many langpacks containing translations and other localization data for different countries and languages. This Change will move them to a separate subpackage pulled in as a weak dependency by the base package. == Feedback == Initial discussion: https://bugzilla.redhat.com/show_bug.cgi?id=2035178 == Benefit to Fedora == This makes Fedora a little more modular: going forward it will be possible to install firefox without having to have all the langpacks installed too. == Scope == * Proposal owners: ** Update Rawhide firefox to add the langpacks subpackage ([https://src.fedoraproject.org/rpms/firefox/pull-request/43 PR]) * Other developers: none * Release engineering: [https://pagure.io/releng/issue/10858 #10858] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == When upgrading to Fedora 37, firefox's new weak dependency will pull in the firefox-langpacks subpackage, so users should not experience any change by default. == How To Test == * install firefox and check that firefox-langpacks gets pulled in * test that firefox's langpacks are functioning normally * test upgrade from F36 to F37 and ensure that the firefox-langpacks subpackage gets installed. == User Experience == Users will have a new firefox-langpacks subpackage installed by default. If they don't require localization they can remove it and benefit from lighter firefox updates and save about 50MB of diskspace. == Dependencies == None == Contingency Plan == * Contingency mechanism: proposal owners will revert firefox.spec to not subpackage langpacks * Contingency deadline: before final freeze * Blocks release? No == Documentation == None == Release Notes == Firefox's langpacks have been moved to a subpackage for greater install flexibility. -- Vipul Siddharth He/His/Him FPgM team member ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
