Upcoming F37 deadlines
by Ben Cotton
As a reminder, several Fedora Linux 37 deadlines are approaching:
* 2022-06-22 — Change proposals requiring infrastructure changes due
* 2022-06-28 — System-Wide Change proposals and proposals requiring a
mass rebuild due
* 2022-07-19 — Self-Contained Change proposals due
For the full schedule, see
https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 9 months
[HEADS UP] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July
11th
by Karolina Surma
Hello packagers,
The new major version of the popular documentation framework Sphinx has
been recently released[0]. It brings many changes, among which there is
support of docutils 0.18.1. We aim to update both packages together in
Fedora Rawhide on **July 11th**.
As usual, an ongoing attempt to smoothly integrate the updates takes
place using Copr[1]. There are some packages impacted with the new
changes. Please take time to review an fix the package, or coordinate
with the upstream.
If your package hasn't succeeded to build with Python 3.11 yet, we can't
test whether it will work with this update.
Common issues and mitigation
- `None` is no longer accepted as value of `language` in conf.py
Solution: Use `language = 'en'` instead.
- Build/ tests fail with: `AttributeError: 'path' object has no
attribute 'text'`
Solution: use `path.read_text()` instead
Test your package locally in mock using the provided test Copr
$ mock -r fedora-rawhide-x86_64
--addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/
--no-clean <your.src.rpm>
$ mock -r fedora-rawhide-x86_64
--addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/
shell
Packages that pin Sphinx and docutils to lower versions than are about
to be introduced, and will effectively stop working after the update has
reached Rawhide:
Sphinx < 5:
python-h2-0:4.1.0-7.fc37.src
python-priority-0:2.0.0-7.fc37.src
python-sphinx-panels-0:0.6.0-3.fc37.src
python-sphinx-tabs-0:3.1.0-7.fc37.src
python3-sphinxcontrib-zopeext-0:0.3.2-3.fc37.noarch
docutils < 0.18:
python-sphinx-tabs-0:3.1.0-7.fc37.src
python3-sphinx_rtd_theme-0:1.0.0-6.fc37.noarch
Full list of known affected packages
Maintainers by package:
copr-keygen clime dturecek frostyx msuchy praiskup
coq amdunn jjames
diceware kushal
kea fjanus mosvald zdohnal
libcamera javierm
liblognorm alakatos rsroka zfridric
python-django bkabrda churchyard jdornak mrunge rdopiera salimma
sgallagh
python-graphviz eclipseo
python-h2 eclipseo
python-pikepdf qulogic zdohnal
python-priority eclipseo
python-sphinx-panels qulogic
python-sphinx-tabs hobbes1069
python-sphinx_rtd_theme jjames ksurma piotrp
python-sphinxcontrib-bibtex jjames
python-sphinxcontrib-htmlhelp churchyard cstratak
python-sphinxcontrib-jsmath churchyard cstratak
python-sphinxcontrib-qthelp churchyard cstratak
python-sphinxcontrib-zopeext jjames
Packages by maintainer:
alakatos liblognorm
amdunn coq
bkabrda python-django
churchyard python-django python-sphinxcontrib-htmlhelp
python-sphinxcontrib-jsmath python-sphinxcontrib-qthelp
clime copr-keygen
cstratak python-sphinxcontrib-htmlhelp python-sphinxcontrib-jsmath
python-sphinxcontrib-qthelp
dturecek copr-keygen
eclipseo python-graphviz python-h2 python-priority
fjanus kea
frostyx copr-keygen
hobbes1069 python-sphinx-tabs
javierm libcamera
jdornak python-django
jjames coq python-sphinx_rtd_theme python-sphinxcontrib-bibtex
python-sphinxcontrib-zopeext
ksurma python-sphinx_rtd_theme
kushal diceware
mosvald kea
mrunge python-django
msuchy copr-keygen
piotrp python-sphinx_rtd_theme
praiskup copr-keygen
qulogic python-pikepdf python-sphinx-panels
rdopiera python-django
rsroka liblognorm
salimma python-django
sgallagh python-django
zdohnal kea python-pikepdf
zfridric liblognorm
Cheers,
Karolina Surma
[0] https://www.sphinx-doc.org/en/master/changes.html
[1] https://copr.fedorainfracloud.org/coprs/ksurma/sphinx-5/
1 year, 10 months
F37 Change Proposal: libsoup 3: Part One (System-Wide Change)
by Vipul Siddharth
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: <mcatanzaro(a)redhat.com>
== 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,
everything should be fine and users should not notice this transition.
But applications that link to both libsoup 2 and libsoup 3 will crash
on startup.
== How To Test ==
Although it's possible that bugs will be introduced when porting an
application from libsoup 2 to libsoup 3, we should focus on testing to
see whether applications crash on startup. An application that does
not crash immediately is probably good.
== User Experience ==
Applications that use libsoup 3 will support HTTP/2, which multiplexes
multiple HTTP requests over a single connection. Users may notice
performance improvements.
== Dependencies ==
$ dnf repoquery --whatdepends libsoup --latest-limit 1 --arch 'noarch,x86_64'
Last metadata expiration check: 0:37:45 ago on Mon 27 Jun 2022 10:43:26 AM CDT.
abrt-retrace-client-0:2.15.1-1.fc36.x86_64
badwolf-0:1.2.2-2.fc36.x86_64
bookworm-0:1.1.3-0.7.20200414git.c7c3643.fc36.x86_64
cawbird-0:1.4.2-3.fc36.x86_64
chatty-0:0.6.0-1.fc36.x86_64
chezdav-0:2.5-6.fc36.x86_64
claws-mail-plugins-fancy-0:4.1.0-1.fc36.x86_64
claws-mail-plugins-gdata-0:4.1.0-1.fc36.x86_64
coin-0:1.3.0-6.fc36.x86_64
cutter-0:1.2.7-6.fc36.x86_64
darktable-0:3.8.1-1.fc36.x86_64
dino-0:0.3.0-2.fc36.x86_64
dleyna-renderer-0:0.6.0-14.fc36.x86_64
dleyna-server-0:0.6.0-13.fc36.x86_64
dmapd-0:0.0.91-1.fc36.x86_64
elementary-calendar-0:6.1.1-1.fc36.x86_64
elementary-code-0:6.2.0-1.fc36.x86_64
elementary-mail-0:6.4.0-1.fc36.x86_64
elementary-photos-0:2.7.5-1.fc36.x86_64
elementary-planner-1:3.0.7-1.fc36.x86_64
elementary-tasks-0:6.2.0-1.fc36.x86_64
emacs-1:27.2-11.fc36.x86_64
ephemeral-0:7.1.0-3.fc36.x86_64
epiphany-1:42.2-1.fc36.x86_64
evolution-0:3.44.2-1.fc36.x86_64
evolution-chime-0:1.4.1-5.fc36.x86_64
evolution-data-server-0:3.44.2-1.fc36.x86_64
evolution-ews-0:3.44.2-1.fc36.x86_64
evolution-rspam-0:0.6.0-35.fc36.x86_64
evolution-rss-1:0.3.96-9.fc36.x86_64
exfalso-0:4.5.0-1.fc36.noarch
flatpak-0:1.12.7-2.fc36.x86_64
flatpak-builder-0:1.2.2-2.fc36.x86_64
flatpak-libs-0:1.12.7-2.fc36.x86_64
flatpak-tests-0:1.12.7-2.fc36.x86_64
fondo-0:1.6.1-2.fc36.x86_64
frogr-0:1.6-5.fc35.x86_64
gajim-0:1.4.4-1.fc36.noarch
gambas3-gb-gtk3-webview-0:3.17.2-1.fc36.x86_64
gamehub-0:0.16.3.2-4.fc36.x86_64
geany-plugins-geniuspaste-0:1.38-3.fc36.x86_64
geany-plugins-markdown-0:1.38-3.fc36.x86_64
geany-plugins-updatechecker-0:1.38-3.fc36.x86_64
geary-0:40.0-5.fc36.x86_64
geoclue2-0:2.6.0-2.fc36.x86_64
geocode-glib-0:3.26.2-5.fc36.x86_64
gfbgraph-0:0.2.4-2.fc36.x86_64
gnome-boxes-0:42.1-1.fc36.x86_64
gnome-builder-0:42.1-1.fc36.x86_64
gnome-calculator-0:42.1-1.fc36.x86_64
gnome-calendar-0:42.2-1.fc36.x86_64
gnome-games-0:40.0-3.fc36.x86_64
gnome-music-0:42.1-1.fc36.noarch
gnome-online-accounts-0:3.44.0-1.fc36.x86_64
gnome-panel-0:3.44.0-1.fc36.x86_64
gnome-software-0:42.2-4.fc36.x86_64
gnome-tweaks-0:42~beta-1.fc36.noarch
gnome-video-arcade-0:0.8.8-12.fc36.x86_64
goodvibes-0:0.7.2-2.fc36.x86_64
grilo-0:0.3.14-2.fc36.x86_64
grilo-plugins-0:0.3.14-3.fc36.x86_64
gsequencer-0:3.17.6-0.fc36.x86_64
gssdp-0:1.4.0.1-2.fc36.x86_64
gssdp-utils-0:1.4.0.1-2.fc36.x86_64
gthumb-1:3.12.1-1.fc36.x86_64
gtranslator-0:40.0-3.fc36.x86_64
gupnp-0:1.4.3-2.fc36.x86_64
gupnp-tools-0:0.10.3-1.fc36.x86_64
homebank-0:5.5.5-1.fc36.x86_64
libabiword-1:3.0.5-2.fc36.x86_64
libappstream-glib-0:0.7.18-4.fc36.x86_64
libchamplain-0:0.12.20-6.fc36.x86_64
libdmapsharing-0:2.9.41-6.fc36.x86_64
libdmapsharing4-0:3.9.10-5.fc36.x86_64
libepc-0:0.4.0-22.fc36.x86_64
libepc-ui-0:0.4.0-22.fc36.x86_64
libgda-tools-1:5.2.10-5.fc36.x86_64
libgda-web-1:5.2.10-5.fc36.x86_64
libgdata-0:0.18.1-4.fc36.x86_64
libgepub-0:0.6.0-9.fc36.x86_64
libgovirt-0:0.3.8-3.fc36.x86_64
libgrss-0:0.7.0-14.fc36.x86_64
libgweather-0:40.0-3.fc36.x86_64
libgweather4-0:4.0.0-1.fc36.x86_64
libmateweather-0:1.26.0-2.fc36.x86_64
libosinfo-0:1.10.0-1.fc36.x86_64
libphodav-0:2.5-6.fc36.x86_64
libsoup-devel-0:2.74.2-2.fc36.x86_64
libtimezonemap-0:0.4.5.1-11.fc36.x86_64
libtracker-sparql-0:3.3.1-1.fc36.x86_64
libtranslate-0:0.99-112.fc36.x86_64
liferea-1:1.13.7-2.fc36.x86_64
linphone-0:3.6.1-48.fc36.x86_64
logjam-1:4.6.2-27.fc36.x86_64
meteo-0:0.9.9.1-2.fc36.x86_64
midori-0:9.0-9.fc36.x86_64
mmsd-tng-0:1.8-1.fc36.x86_64
mpdscribble-0:0.22-24.fc36.x86_64
osinfo-db-tools-0:1.10.0-1.fc36.x86_64
osm-gps-map-0:1.1.0-10.fc36.x86_64
ostree-tests-0:2022.4-2.fc36.x86_64
perl-HTTP-Soup-0:0.01-26.fc36.x86_64
polari-0:42.0-1.fc36.x86_64
pragha-0:1.3.3-22.fc36.x86_64
purple-chime-0:1.4.1-5.fc36.x86_64
python3-nbxmpp-0:3.1.0-2.fc36.noarch
remmina-0:1.4.27-2.fc36.x86_64
rest-0:0.8.1-12.fc36.x86_64
rhythmbox-0:3.4.6-1.fc36.x86_64
rygel-0:0.40.3-1.fc36.x86_64
seahorse-0:42.0-1.fc36.x86_64
shotwell-0:0.31.3-8.fc36.x86_64
snapd-glib-0:1.58-4.fc36.x86_64
snapd-glib-tests-0:1.58-4.fc36.x86_64
snapd-qt-tests-0:1.58-4.fc36.x86_64
soup-sharp-0:2.42.2-6.20190810git0f36d10.fc36.x86_64
spice-glib-0:0.40-1.fc36.x86_64
srain-0:1.4.0-2.fc36.x86_64
surf-0:2.0-13.fc36.x86_64
switchboard-plug-onlineaccounts-0:6.5.0-1.fc36.x86_64
syncevolution-libs-1:2.0.0-3.fc36.x86_64
syncevolution-libs-akonadi-1:2.0.0-3.fc36.x86_64
taxi-0:2.0.1-2.fc36.x86_64
telepathy-gabble-0:0.18.4-18.fc36.x86_64
telepathy-salut-0:0.8.1-27.fc36.x86_64
uhttpmock-0:0.5.0-15.fc36.x86_64
vfrnav-0:20201231-22.fc36.x86_64
webkit2gtk3-0:2.36.3-1.fc36.x86_64
webkit2gtk3-devel-0:2.36.3-1.fc36.x86_64
xfce4-screenshooter-0:1.9.8-4.fc36.x86_64
xfce4-screenshooter-plugin-0:1.9.8-4.fc36.x86_64
xfce4-weather-plugin-0:0.11.0-3.fc36.x86_64
yelp-libs-2:42.1-1.fc36.x86_64
== Contingency Plan ==
* Contingency mechanism: We may be required to switch particular
packages back to libsoup 2. Due to interdependencies between packages,
this could be quite disruptive.
* Contingency deadline: Beta freeze
* Blocks release? Possibly. Applications that crash on startup will
fail the "basic functionality test" release criterion.
== Documentation ==
[https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html
Migrating from libsoup 2]
== Release Notes ==
Many applications and libraries now use libsoup 3, a new version of
libsoup that adds support for HTTP/2.
--
Vipul Siddharth
He/His/Him
FPgM team member
1 year, 10 months
F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
by Vipul Siddharth
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: mclasen(a)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-remo...
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
1 year, 10 months
F37 Change Proposal: IBus 1.5.27 (System-Wide change)
by Vipul Siddharth
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
1 year, 10 months
F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)
by Vipul Siddharth
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: <petersen(a)redhat.com>
* Name: [[User:Stransky| Martin Stransky]]
* Email: <mstransky(a)redhat.com>
== 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
1 year, 10 months
F37 Change Proposal: MAC Address Policy none (System-Wide Change)
by Vipul Siddharth
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 `systemd-udev` package installs
`"/usr/lib/systemd/network/99-default.link"`,
which sets `Link.MACAddressPolicy=persistent`. This proposal is to
change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address.
This is particularly important for bridge and bond devices.
This change can either only apply to bridge/bond devices, or to
various software devices. That is to be discussed.
== Owner ==
* Name: [[User:thaller|Thomas Haller]] (NetworkManager)
* Email: <thaller(a)redhat.com>
* Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
* Email: <dmabe(a)redhat.com>
== Detailed Description ==
On Fedora, udev by default changes the MAC address of a wide range of
software devices.
This was introduced by systemd 242 in early 2019 (Fedora 31), when
`MACAddressPolicy=` was
extended to affect more types of devices.
With `MACAddressPolicy=persistent` udev's aim is to provide a stable
MAC address, otherwise
the kernel will assign a random one. However, that can cause problems:
Firstly, software devices are always created by some tool that has
plans for the device. The tool may not
expect that udev is going to change the MAC address and races against
that. The best solution
for the tool is to set the MAC address when creating an interface.
This will prevent
udev from changing the MAC address according to the MACAddressPolicy.
Otherwise, the tool should wait for udev to initialize the device to
avoid the race. In theory, a
tool is always advised to wait for udev to initialize the device.
However, if it were not for MACAddressPolicy,
in common scenarios udev doesn't do anything relevant for software
devices to make that necessary.
Secondly, for interface types bridge and bond, an unset MAC address
has a special meaning
to the kernel and the MAC address of the first port is used. If udev
changes the MAC
address, that no longer works.
Now the generated MAC address is not directly discoverable as it is
based on `/etc/machine-id`
([https://www.man7.org/linux/man-pages/man5/machine-id.5.html
machine-id(5)]), among
other data. Even if there were a tool to easily calculate the MAC
address, it could be cumbersome
to use it without logging into the machine first. The MAC address can
directly affect the
assigned IP address, for example when using DHCP. When booting a new
virtual machine, the user might
know the MAC address of the (virtual) "physical" interfaces. When
bonding/bridging those
interfaces, the bond/bridge would get one of the well known MAC
addresses. `MACAddressPolicy=persistent`
interferes with that.
The goal of persistent policy is to provide a stable MAC address. Note
that if the
tool or user who created the interface would want a certain MAC address, they
have all the means to set it already. That applies regardless whether
the tool is
iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor
systemd-networkd
rely on udev's MACAddressPolicy for setting the MAC address. This
behavior is mostly
useful for plain `ip link add`, but it's unclear which real world user
wants this behavior.
Of course, the user is welcome to configure the MAC address in any way
they want. Including,
dropping a link file that sets `MACAddressPolicy=persistent`. The
problem is once udev sets a MAC address,
it cannot be unset. Which makes this problematic to do by default.
While Fedora inherited this behavior from upstream systemd, RHEL-9
does not follow this behavior
([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf...
centos9],
[https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For
RHEL-8, this doesn't
apply because the systemd there is too old to change the MAC address
of most software devices.
This could be either implemented by patching
`/usr/lib/systemd/network/99-default.link`
to have a different policy, or by dropping a link file with higher
priority. In the latter
case, that override could be shipped either by udev or even by NetworkManager.
Another option is to change the scope of this proposal to only change to
`MACAddressPolicy=none` for the device types where this causes the most issues
(bridge/bond/team).
== Feedback ==
This was also discussed on upstream systemd mailing list
[https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html
here].
The upstream systemd maintainers' opinion is that the current udev
behavior is desirable, but accepts that distributions (or network
stacks such as NetworkManager) may choose to change the default
depending on their needs
([https://lists.freedesktop.org/archives/systemd-devel/2022-May/047943.html
reference]).
The goal here is to find out what the Fedora community thinks is the
most appropriate default.
The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094
[rh#1921094]].
== Benefit to Fedora ==
Pros:
- Consistent behavior with RHEL8 and RHEL9.
- Avoid race of udev and the tool that creates the interface.
- Bridge and bond interfaces can get the MAC addresses from their first port.
In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will
get a MAC related to one of its physical NIC devices. In the case of
provisioning
new systems (especially in a large datacenter) information about the server
can be used to configure the network environment (DHCP, Firewall, etc) before
the server is ever even powered on. This does mean that you may have to update
your network environment configuration if you replace a NIC (con), but that you
won't have to update your network environment configuration if you re-install
your server (pro), which is what you'd have to do now with
`MACAddressPolicy=persistent`.
Cons:
- Deviate from upstream systemd.
It is desirable that RHEL and Fedora behaves similar. A possible outcome
could be the current behavior stays and RHEL 10 would change behavior. On the
other hand, different distributions (or even Fedora spins) have different
uses and needs. Deviating might be fine. In the same vein, there is also
a desire to stay close to upstream systemd behavior. But the uses of systemd
project go beyond Fedora/RHEL, so deviating here may also be fine.
== Scope ==
* Proposal owners:
The main goal of this request is to generate productive discussion and
find the desired behavior.
The implementation/changes are either way very simple.
* Other developers:
Other projects that wish a certain MAC address are welcome to
set it for their devices. Including using udev's MACAddressPolicy.
* Release engineering:
Not needed for this change.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
After the change, the MAC address for the affected device types changes.
== How To Test ==
1) Create a software device two times, for example `ip link add type
bridge`. Note
that the MAC address is either stable or random, depending on the
`MACAddressPolicy=`.
2) Note that if the software device has the MAC address set initially,
udev does not
change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on
`/sys/class/net/$dev/addr_assign_type`.
3) Create a bridge/bond interface without setting the MAC address.
Note that if `MACAddressPolicy=none`,
the MAC address is random at first. Note that attaching the first port
will update the controller's MAC address.
On the other hand, with `MACAddressPolicy=persistent`, the MAC address
of the controller is fixed
and not inherited from the port.
4) Run
ip monitor link &
while : ; do
ip link del xxx
ip link add name xxx type dummy \
&& ip link set xxx addr aa:00:00:00:00:00 \
&& ip link show xxx | grep -q aa:00:00:00:00:00 \
|| break
done
to reproduce the race between a simple tool and udev changing the MAC address.
== User Experience ==
Bond/bridge devices would again get assigned the MAC address of the
first NIC added to the device.
If we chose to not limit the scope of this change to just
bonds/bridges then all software devices would get randomly assigned
MAC addresses.
== Dependencies ==
None.
== Contingency Plan ==
If the change is rejected, nothing needs to be done. The change
itself will be simple to implement.
Contingency deadline: beta freeze
Blocks release? No
== Documentation ==
TODO.
== Release Notes ==
--
Vipul Siddharth
He/His/Him
FPgM team member
1 year, 10 months
F37 change proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)
by Vipul Siddharth
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 ==
This change is to promote Fedora CoreOS to Edition status alongside
Workstation, Server and IoT.
== Owners ==
* Name: [[User:cverna|Clement Verna]]
* Email: cverna(a)fedoraproject.org
* Products: Fedora CoreOS
* Responsible WGs: Fedora CoreOS Group
== Detailed Description ==
This change is to promote Fedora CoreOS to Edition status alongside
Workstation, Server and IoT.
[https://fedoraproject.org/wiki/Editions/Promotion_Process#Prerequisites
Prerequisites] are tracked bellow :
* Edition has a team with regular public meeting :
[https://apps.fedoraproject.org/calendar/meeting/9437/ weekly meeting
happening on #fedora-meeting-1]
* Trademark approval from the Fedora Council :
[https://pagure.io/Fedora-Council/tickets/issue/340 council ticket]
* Product requirements document (PRD) :
https://fedoraproject.org/wiki/CoreOS/PRD
* Technical specification :
https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md
== Feedback ==
This change was previously submitted for Fedora 34 and feedback were
collected in the following [https://pagure.io/fesco/issue/2516 FESCo
ticket].
The 2 main feedback received are either addressed or in the process of
being addressed.
* FCOS should not trail behind the latest Major Fedora version: see
[[https://fedoraproject.org/wiki/Changes/FedoraCoreOS#Major_Fedora_Version_release_Go/NoGo|Major
Fedora Version release Go/NoGo criteria]]
* FCOS should demonstrate the test case mapping to the Basic Release
Criteria: see [[https://fedoraproject.org/wiki/Changes/FedoraCoreOS#Basic_Release_Criteria|Basic
Release Criteria]]
== Benefit to Fedora ==
Make Fedora CoreOS an official edition, will help spread adoption and
position Fedora as credible solution for running container workflow.
We have started to publish monthly update of what is happening in
Fedora CoreOS based on the feedback received from
[https://discussion.fedoraproject.org/t/fedora-coreos-survey/34408/2 a
community survey]. Part of these monthly update are
[https://discussion.fedoraproject.org/t/this-month-in-fedora-coreos-may-20...
the count me stats] which gives us a good understanding of FCOS
adoption.
== Scope ==
* Proposal owners: see change owners
* Other developers: N/A
* Release engineering: Fedora CoreOS is already being composed and released.
* Policies and guidelines: N/A
* Trademark approval: https://pagure.io/Fedora-Council/tickets/issue/340
== How To Test ==
See QA test cases :
https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases and Fedora
CoreOS own test suite Kola
https://github.com/coreos/coreos-assembler/blob/main/docs/kola.md#testing...
We also have regular tests days, for example
https://fedoramagazine.org/fedora-coreos-test-day/
=== Basic Release Criteria ===
We are currently evaluating our compliance to the Fedora Basic Release
Criteria https://github.com/coreos/fedora-coreos-tracker/issues/1239.
This is an effort that will be done during the Fedora 37 development cycle.
==== Supported Architecture and Platforms ====
Fedora CoreOS is currently built for the x86_64, aarch64 and s390x
architecture, These
[https://docs.fedoraproject.org/en-US/fedora-coreos/platforms/#_well_known...
platforms] are supported and can be configured directly using
Ignition.
The [https://github.com/coreos/mantle/tree/cl/kola kola] test suite is
run for each stream release on AWS, Azure, GCP and OpenStack.
==== Stream release Go/NoGo ====
Stream releases are scheduled fortnightly, a GitHub issue
([https://github.com/coreos/fedora-coreos-streams/issues/242 example])
is created for each stream release with the release process.
The release status can be tracked in each ticket. If each steps and
validation were successful the release is considered GO.
Issues are reported in the
[https://github.com/coreos/fedora-coreos-tracker issue tracker] and
discussed during the weekly
[https://github.com/coreos/fedora-coreos-tracker#meetings IRC
meeting]. A stream release can become a NOGO during these meeting, the
blocker issue is then linked to the release GitHub issue.
==== Major Fedora Version release Go/NoGo ====
The policies around the Major version rebases are described in Fedora
CoreOS document
https://github.com/coreos/fedora-coreos-tracker/blob/main/Design.md#major...
(see copy below)
The release process integrates with Fedora's release milestones in the
following ways:
Fedora Beta Release
The next stream is switched over to the new release.
Fedora Final Freeze
The next stream switches to weekly releases to closely track the GA
content set.
Fedora General Availability
Fedora CoreOS re-orients its release schedule in the following way:
Week -1 (Fedora "Go" Decision): next release:
next release with final Fedora GA content
Week 0 (GA release): triple release:
testing release promoted from previous next
next release contains latest Fedora N content, including Bodhi updates
Week 2: triple release:
stable release promoted from previous testing, now fully rebased
to Fedora N
testing and next are now in sync
== Contingency Plan ==
Contingency mechanism: (What to do? Who will do it?) Delay promotion until F38
Contingency deadline: F37 Final release date
Blocks release? No
== Documentation ==
https://docs.fedoraproject.org/en-US/fedora-coreos/
--
Vipul Siddharth
He/His/Him
FPgM team member
1 year, 10 months
F37 proposal: Stratis 3.1.0 (Self-Contained change)
by Vipul Siddharth
https://fedoraproject.org/wiki/Changes/Stratis_3.1.0
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 ==
Stratis 3.1.0 includes significant improvements to the management of
the thin-provisioning layers, as well as a number of other
user-visible enhancements and bug fixes.
== Owner ==
* Name:
** [[User:dkeefe|Dennis Keefe]]
** [[User:mulhern|Anne Mulhern]]
** [[User:jbaublitz|John Baublitz]]
* Email:
** dkeefe(a)redhat.com
** amulhern(a)redhat.com
** jbaublitz(a)redhat.com
== Detailed Description ==
Stratis 3.1.0 includes significant improvements to the management of
the thin-provisioning layers, as well as a number of other
user-visible enhancements and bug fixes.
Please see this
[https://stratis-storage.github.io/thin-provisioning-redesign/ post]
for a detailed discussion of the thin-provisioning changes. To support
these changes the Stratis CLI has been enhanced to:
* allow specifying whether or not a pool may be overprovisioned on creation
* allow changing whether or not a pool may be overprovisioned while it
is running
* allow increasing the filesystem limit for a given pool
* display whether or not a pool is overprovisioned in the pool list view
Users of the Stratis CLI may also observe the following changes:
* A `debug` subcommand has been added to the `pool`, `filesystem`, and
`blockdev` subcommands. Debug commands are not fully supported and may
change or be removed at any time.
* The `--redundancy` option is no longer available when creating a
pool. This option had only one permitted value so specifying it never
had any effect.
stratisd 3.1.0 includes one additional user-visible change:
* The minimum size of a Stratis filesystem is increased to 512 MiB.
stratisd 3.1.0 also includes a number of internal improvements:
* The size of any newly created MDV is increased to 512 MiB.
* A pool's MDV is mounted in a private mount namespace and remains
mounted while the pool is in operation.
* Improved handling of udev events on device removal.
* The usual and customary improvements to log messages.
Please consult the
[https://github.com/stratis-storage/stratisd/blob/master/CHANGES.txt/
stratisd] and [https://github.com/stratis-storage/stratis-cli/blob/master/CHANGES.txt/
stratis-cli] changelogs for additional information about the 3.1.0
release.
== Benefit to Fedora ==
Users of Fedora will now benefit from Stratis 3.1.0 by:
* Change the overprovisioning mode at create time or while running
* User can increase the limit of filesystems per pool. The default is 100.
* Stratis pool list will display whether or not a pool is overprovisioned
* The MDV size is now 512MB, which allows for more filesystems to be
created per pool
* MDV is now in a private mount namespace, which decreases logging
events and user may see faster completion times for commands that
required the MDV to be mounted.
== Scope ==
* Proposal owners:
** Update existing stratis-cli package to specify new release
** Update existing stratisd package to specify new release
* Other developers: N/A
* Release engineering: Self Contained
* Policies guidelines: N/A
* Trademark approval: N/A
== How To Test ==
* To see the `overprovisioning` field, list the pools
`stratis pool list`
overprovisioned will equal `OP`, no overprovisioning will equal `~OP`
* To set the filesystem limit of a pool:
`stratis pool set-fs-limit p1 200`
* To see what the filesystem limit is
`stratis report engine_state_report`
Look for field `fs_limit` in output
== User Experience ==
Other than the changes mentioned above the user experience will be the same.
== Dependencies ==
No new dependencies
== Contingency Plan ==
* Contingency mechanism:
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
* This content can be viewed on Developer’s
[https://stratis-storage.github.io/thin-provisioning-redesign/ blog]
for Stratis 3.1
* Thin-provisioning
[https://stratis-storage.github.io/thin-provisioning-redesign/ blog]
* [https://github.com/stratis-storage/stratisd/blob/master/CHANGES.txt/
stratisd] changelog
* [https://github.com/stratis-storage/stratis-cli/blob/master/CHANGES.txt/
stratis-cli] changelog
== Release Notes ==
[https://stratis-storage.github.io/stratis-release-notes-3-1-0/
Stratis Release Notes]
--
Vipul Siddharth
He/His/Him
Fedora | CentOS CI Infrastructure Team
1 year, 10 months
