devel-announce June 2022

devel-announce@lists.fedoraproject.org

10 participants
29 discussions

Upcoming F37 deadlines
by Ben Cotton 12 Jul '22

12 Jul '22

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 2

[Reminder] CfP open for Nest with Fedora
by Marie Nordin 08 Jul '22

08 Jul '22

Hi there Fedorans, It's time to submit your proposals for Nest with Fedora! The event will be held virtually on August 4th, 5th, and 6th. This is a great opportunity to share what you have been doing in the project and connect with your fellow Fedorans :) *The final deadline for the CfP is July 8th. * *Submit your proposals on the Flock pagure repo:* https://pagure.io/flock/issues *More info about the CfP:* https://communityblog.fedoraproject.org/nest-2022-cfp/ *More info about Nest: * https://communityblog.fedoraproject.org/nest-with-fedora-fedora-hatch-annou… Can't wait to see your proposals! Best, -- Marie Nordin Fedora Community Action and Impact Coordinator Red Hat <https://www.redhat.com/> • Fedora Project <https://getfedora.org/> She/Her/Hers IRC/Element: riecatnor <https://red.ht/sig>

1 1

[HEADS UP] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July 11th
by Karolina Surma 30 Jun '22

30 Jun '22

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 0

F37 Change Proposal: libsoup 3: Part One (System-Wide Change)
by Vipul Siddharth 29 Jun '22

29 Jun '22

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 0

F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
by Vipul Siddharth 29 Jun '22

29 Jun '22

1 0

F37 Change Proposal: IBus 1.5.27 (System-Wide change)
by Vipul Siddharth 29 Jun '22

29 Jun '22

1 0

F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)
by Vipul Siddharth 29 Jun '22

29 Jun '22

1 0

F37 Change Proposal: MAC Address Policy none (System-Wide Change)
by Vipul Siddharth 25 Jun '22

25 Jun '22

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/c8953519504bf2e… 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 0

F37 change proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)
by Vipul Siddharth 25 Jun '22

25 Jun '22

1 0

F37 proposal: Stratis 3.1.0 (Self-Contained change)
by Vipul Siddharth 23 Jun '22

23 Jun '22

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 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce June 2022