devel June 2020

devel@lists.fedoraproject.org

303 participants
316 discussions

Reproducible builds/bootstrap
by Pablo Greco 09 Oct '20

09 Oct '20

I'm starting to work on a project to make Fedora fully reproducible and bootstrappable from scratch. I know it is a long term plan and still working on the steps, but it would be good to know the current status, if there is an internal interest in this, if someone is already working (or planning to). Thanks for the info. Pablo

8 11

Fedora 33 System-Wide Change proposal: systemd-resolved
by Ben Cotton 07 Oct '20

07 Oct '20

https://fedoraproject.org/wiki/Changes/systemd-resolved == Summary == Enable systemd-resolved by default. glibc will perform name resolution using nss-resolve rather than nss-dns. == Owner == * Name: [[User:catanzaro| Michael Catanzaro]] * Email: <mcatanzaro(a)redhat.com> == Detailed Description == We will enable systemd-resolved by default. # We will change the [https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233e5… fedora-release presets] to enable systemd-resolved instead of disable it. # systemd-libs currently has [https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede… a %post scriplet] to enable nss-myhostname and nss-systemd by either (a) modifying authselect's user-nsswitch.conf template, if authselect is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We will work with the systemd maintainers to enable nss-resolve here as well. # We will work with the authselect maintainers to update authselect's minimal and nis profiles to enforce nss-resolve. These profiles modify the hosts line of /etc/resolv.conf. (By default, Fedora uses authselect's sssd profile, which does not modify the hosts line and therefore does not have this problem.) # We will remove our downstream patch to systemd that prevents systemd from symlinking /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf on new installs. For system upgrades, a systemd-libs %post scriptlet will be used to reassign the symlink during upgrade. Upon detecting this symlink, NetworkManager will automatically enable its systemd-resolved support and configure split DNS as appropriate. systemd-resolved has been enabled by default in Ubuntu since Ubuntu 16.10, but please note we are doing this differently than Ubuntu has. Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional nss-dns provided by glibc upstream, so glibc on Ubuntu continues to read /etc/resolv.conf, as is traditional. This extra step is not useful and not recommended by upstream. We want to follow upstream recommendations in using nss-resolve instead. If you do not wish to use systemd-resolved, then manual intervention will be required to disable it: * Modify /etc/authselect/user-nsswitch.conf and remove `resolve [!UNAVAIL=return]` from the hosts line. Run `authselect apply-changes`. (If you have disabled authselect, then edit /etc/nsswitch.conf directly.) * Disable and stop systemd-resolved.service. * Restart the NetworkManager service. NetworkManager will then create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you may create your own /etc/resolv.conf.) == Benefit to Fedora == === Standardization === Fedora will continue its history of enabling new systemd-provided services whenever it makes sense to do so. Standardizing on upstream systemd services is beneficial to the broader Linux ecosystem in addition to Fedora, since standardizing reduces behavior differences between different Linux distributions. Sadly, Fedora is no longer leading in this area. Ubuntu has enabled systemd-resolved by default since Ubuntu 16.10, so by the time Fedora 33 is released, we will be three years behind Ubuntu here. === resolvectl === `resolvectl` has several useful functions (e.g. `resolvectl status` or `resolvectl query`) that will be enabled out-of-the-box. === Caching === systemd-resolved caches DNS queries for a short while. This can [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846 dramatically] improve performance for applications that do not already manually cache their own DNS results. (Generally, only web browsers bother with manually caching DNS results.) === Split DNS === When systemd-resolved is enabled, users who use multiple VPNs at the same time will notice that DNS requests are now sent to the correct DNS server by default. Previously, this scenario would result in embarrassing "DNS leaks" and, depending on the order that the VPN connections were established, possible failure to resolve private resources. These scenarios will now work properly. For example, consider the scenario of Distrustful Denise, who (quite reasonably) does not trust her ISP. Denise uses a public VPN service, public-vpn.example.com, to hide her internet activity from her ISP, but she also needs to use her employer's corporate VPN, corporation.example.com, in order to access internal company resources while working from home. Using the Network panel in System Settings, Denise has configured her employer's VPN to "use this connection only for resources on its network." Distrustful Denise expects that her employer's VPN will receive all traffic for corporation.example.com, and no other traffic. And while this mostly works in Fedora 32, she discovers that it does not work properly for DNS: * If Denise connects to public-vpn.example.com first and corporation.example.com second, she is unable to access internal company resources. All DNS requests are sent to public-vpn.example.com's DNS server, so she is unable to resolve names for internal company websites. * If Denise connects to corporation.example.com first and public-vpn.example.com second, then she is able to access internal company resources. However, it only works because ''all'' her DNS requests are sent to corporation.example.com's DNS server. Sadly for Distrustful Denise, her employer discovers that she has been making some embarrassing DNS requests that she had expected to go through public-vpn.example.com instead. Whichever VPN Denise connects to first receives all DNS requests because glibc's nss-dns module is not smart enough to split the requests. /etc/resolv.conf is just a list of DNS servers to try in order, and NetworkManager has no plausible way to decide which to list first, because both ways are broken, so it just prefers whichever was connected first. And if one server fails to respond, then the next server in the list will be tried, likely resulting in a DNS leak. In contrast, when systemd-resolved is enabled, it will send each DNS request only to the correct DNS server. The DNS server that will be used for each tun interface can be inspected using the resolvectl tool. Migrating away from /etc/resolv.conf will also avoid an annoying footgun with this legacy file: only the first three listed nameservers are respected. All further nameservers are silently ignored. NetworkManager adds a warning comment when writing more than three nameservers to this file, but it cannot do any better than that. === DNS over TLS === systemd-resolved supports DNS over TLS (different from DNS over HTTPS). Although this feature will not initially be enabled by default, using systemd-resolved will enable us to turn on DNS over TLS in a future Fedora release, providing improved security if the user's DNS server supports DNS over TLS. == Scope == * Proposal owners: We will update Fedora presets to enable systemd-resolved by default. * Other developers: This change requires coordination with the systemd and authselect maintainers. * Release engineering: [https://pagure.io/releng/issue/9367 #9367] * Policies and guidelines: none required * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == systemd-resolved will be enabled automatically when upgrading to Fedora 33. After upgrade, /etc/resolv.conf will be managed by systemd and symlinked to /run/systemd/resolve/stub-resolv.conf. '''glibc will no longer look at /etc/resolv.conf when performing name resolution.''' Instead, glibc will communicate directly with systemd-resolved via nss-resolve. systemd adds a large warning comment to the top of /etc/resolv.conf to warn system administrators that changes to this file will be ignored; however, scripts that edit this file manually will break. Because this file is usually managed by NetworkManager, impact to Fedora users will be limited to users who have manually disabled NetworkManager; such users are expected to be experienced system administrators who should be comfortable adapting to the change (or disabling systemd-resolved). Any applications that bypass glibc and read /etc/resolv.conf directly will still work because /etc/resolv.conf will point to systemd-resolved's stub resolver running on 127.0.0.53. Nevertheless, /etc/resolv.conf is provided only for compatibility purposes, and applications should prefer to use either glibc or the systemd-resolved D-Bus API instead; see systemd-resolved(8) for details. In short, '''applications that read /etc/resolv.conf will continue to work as before.''' Applications that write to it will no longer work as expected, but this only previously worked if NetworkManager is disabled, a non-default configuration. It remains possible to disable systemd-resolved if desired. Otherwise, any custom system administration scripts that manage /etc/resolv.conf will need to be updated. === DNSSEC === systemd-resolved's DNSSEC support is known to cause compatibility problems with certain network access points. Per recommendation from the systemd developers, we will change the default value of this setting in Fedora from the upstream default `DNSSEC=allow-downgrade` to `DNSSEC=no` by building systemd with the build option `-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if it is working, but automatically disable it otherwise, allowing man-in-the-middle attackers to disable DNSSEC. Sadly, even the allow-downgrade setting suffers known compatibility problems. Because Fedora is not prepared to handle an influx of DNSSEC-related bug reports, we will disable this feature altogether. We anticipate that enabling DNSSEC by default will not be possible in the foreseeable future, or perhaps ever. Instead, enabling DNS over TLS (when supported by the DNS server) seems likely in the near future. === Multicast DNS === systemd-resolved's multicast DNS support conflicts with Avahi. Per recommendation from the systemd developers, we will change the default value of this setting in Fedora from the upstream default `MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving will be enabled, but responding will be disabled. This will require adding a new systemd build option to control the default value of the MulticastDNS setting, similar to the existing `default-dnssec` and `default-dns-over-tls` build options. == How To Test == Load any website in a web browser. If you succeed, then name resolution probably works. Try using `resolvectl status` and, for example, `resolvectl query fedoraproject.org`, to see how they work and sanity-check their output. Users who use multiple VPNs at the same time are encouraged to test DNS in a multiple VPN scenario, to ensure that DNS requests are sent to the expected DNS server. == User Experience == See the Benefit to Fedora section, above, for direct benefits to users who use multiple VPNs at the same time. Users will be able to use the resolvectl tool and the functionality it provides. /etc/resolv.conf will now be managed by systemd rather than by NetworkManager. As before, this file must not be modified directly when it is managed. == Dependencies == In Fedora, /etc/nsswitch.conf is managed by authselect. By default, authselect uses the sssd profile to generate configuration compatible with sssd. In this mode of operation, it does not modify the hosts line in /etc/nsswitch.conf. This is also true if using the winbind profile instead of the sssd profile. However, authselect's minimal and nis profiles do modify the hosts line. These authselect profiles must be updated to enable nss-resolved. If you are using authselect in one of these modes, it will not be possible to cleanly disable systemd-resolved because the hosts line in /etc/nsswitch.conf will be clobbered whenever 'authselect apply-changes' is run. If you wish to disable systemd-resolved and you are using authselect in one of these modes, then you should stop using authselect. This is not expected to cause many problems because virtually all Fedora users will be using the default sssd profile. We do not need to directly make any changes to the /etc/nsswitch.conf shipped by glibc. Changes will be applied in the systemd-libs %post scriptlet. == Contingency Plan == The contingency plan, in the unlikely event of unexpected problems, is simply to revert any changes and not enable systemd-resolved. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == * systemd-resolved is documented in several manpages: resolvectl(1), resolved.conf(5), nss-resolve(8), systemd-resolved(8). * [https://wiki.archlinux.org/index.php/Systemd-resolved Arch Wiki documentation] * [https://wiki.gnome.org/Projects/NetworkManager/DNS NetworkManager DNS documentation] == Release Notes == systemd-resolved is now enabled by default. systemd-resolved provides a system-level DNS cache that can substantially improve performance for applications that do not cache their own DNS results, allows correct handling of split DNS scenarios such as when multiple VPNs are in use, and will allow Fedora to enable DNS over TLS in the future. /etc/resolv.conf will now be managed by systemd-resolved rather than by NetworkManager. /etc/resolv.conf will no longer be read when performing name resolution using glibc; however, it is still provided for compatibility with applications that manually read this file to perform name resolution. Writing to /etc/resolv.conf will no longer work as expected. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

58 388

Fedora 33 System-Wide Change proposal: Make nano the default editor
by Ben Cotton 28 Sep '20

28 Sep '20

https://fedoraproject.org/wiki/Changes/UseNanoByDefault == Summary == Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use. == Owner == * Name: [[User:chrismurphy| Chris Murphy]] * Email: chrismurphy(a)fedoraproject.org == Detailed Description == Users are exposed to the default editor when they use commands that call it. The main example here is something like <code>git commit</code>. Fedora does not currently have a default terminal text editor, because the $EDITOR environment variable is unset by default. But a common scenario where users wind up in a terminal text editor is when using 'git commit'. By default, git picks vi. You need to spend time learning how to use it, for even basic editing tasks. This increases the barrier to entry for those who are switching to Fedora and don't know how to use vi. It also makes things hard for those who don't particularly want to learn how to use vi. (These arguments would apply just as well if git picked Vim. vi is like hard mode for Vim, with fewer features, missing syntax highlighting, and no indication of what mode you are in. Even Vim users may feel lost and bewildered when using vi.) In contrast, Nano offers the kind of graphical text editing experience that people are used to, and therefore doesn't require specialist knowledge to use. It is already installed across most Fedora Editions and Spins. This proposal will make Nano the default editor, while continuing to install <code>vim-minimal</code> (which provides vi, but not Vim). People will still be able to call <code>vi</code> if they want to edit a file. It will also obviously be possible to change the default editor to vi or Vim, for those who want it. Why make Nano default and vi optional, rather than the other way round? Because Nano is the option that everyone can use. == Feedback == Pending ... == Benefit to Fedora == * Makes the default editor across all of Fedora more approachable. * Nano is also mostly self-documenting, by displaying common keyboard shortcuts on-screen. * More in line with the default editor of other distributions. == Scope == * Proposal owners: ** Modify comps to include nano Fedora wide. ** Create a new subpackage of <code>nano</code>, called <code>nano-editor</code>. ** <code>nano-editor</code> to include <code>/usr/lib/environment.d/10-nano.conf</code>, which sets <code>$EDITOR</code> to <code>nano</code>. With this approach, if <code>nano</code> is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf. * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/9522 #9522] * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == Will not apply to upgrades. == How To Test == Run <code>export EDITOR="/usr/bin/nano"</code>. == User Experience == Users running <code>git commit</code> will be able to just type their commit message, rather than having to learn about insert mode, and they'll be able to cut and paste without having to learn special shortcuts. == Dependencies == No additional dependencies are required. == Contingency Plan == The contingency plan is to revert the change by removing the <code>nano-editor</code> package. * Contingency deadline: probably the beta? It's an easy change to revert. * Blocks release? If the change breaks the redirection to an editor, it should block the release. However, this is unlikely. * Blocks product? Potentially all. == Documentation == As part of this change, it would be good to add instructions for changing the default editor to the [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs]. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

70 264

Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
by Ben Cotton 14 Sep '20

14 Sep '20

https://fedoraproject.org/wiki/Changes/KDEEarlyOOM == Summary == As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install earlyoom package, and enable it by default. If both RAM and swap go below 10% free, earlyoom issues SIGTERM to the process with the largest oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL to the process with the largest oom_score. The idea is to recover from out of memory situations sooner, rather than the typical complete system hang in which the user has no other choice but to force power off. == Owner == * Name: [[User:bcotton|Ben Cotton]] * Email: bcotton(a)redhat.com == Detailed Description == Shamelessly copied from Workstation, which did it in the last release: Certain workloads have heavy memory demands, quickly consume all of RAM, and start to heavily page out to swap. (Heavy paging, is often called "swap thrashing" for added descriptive effect, probably because it's noticeable and annoying). Incidental swap usage is a good thing, it frees up memory for active pages used by a process. Heavy swap usage quickly leads to a very negative UX, because it's slow, even on modern SSDs. Due to installer defaults, the swap partition is made the same size as available memory (at install time), which can be huge. This just extends swap thrashing time. On the one hand, we want this resource hungry job to complete. On the other hand, we want our system to be responsive while that other work is going on. But once the GUI stutters or even comes to an apparent stand still (hang), we're really wishing the kernel oom-killer would kick in and free up memory, so we can start over (maybe using memory or thread limiting options - which arguably should be more intelligently figured out, and that too is a work in progress but beyond the scope of this feature). However, once in a heavy swap scenario, it's relatively common the system gets stuck in it, where GUI interactivity is terrible to non-existent, and also the kernel oom-killer doesn't trigger. From a certain point of view, this is working as intended. The kernel oom-killer is concerned about keeping the kernel running. It's not at all concerned about user space responsiveness. Instead of the system becoming completely unresponsive for tens of minutes, hours or days, this feature expects that an offending process (determined by oom_score, same as the kernel oom-killer) will be killed off within seconds or a few minutes. == Benefit to Fedora == KDE users will be able to take advantage of the benefits Workstation users got from enabling earlyOOM in Fedora 32: * improved user experience by more quickly regaining control over one's system, rather than having to force power off in low-memory situations where there's aggressive swapping. Once a system becomes unresponsive, it's completely reasonable for the user to assume the system is lost, but that includes high potential for data loss. * reducing forced poweroff as the main work around will increase data collection, improving understanding of low memory situations and how to handle them better * earlyoom first sends SIGTERM to the chosen process, so it has a chance of a proper shutdown, unlike the kernel's oom-killer == Scope == * Proposal owners: ** Modify {{code| https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in}} to include earlyoom package for in {{code|kde-desktop}} section. ** Add {{code| https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-kde.pres… to include: <pre> # enable earlyoom by default on KDE enable earlyoom.service </pre> * Other developers: None, unless KDE-based Spins/Labs want to opt out * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == earlyoom.service will be enabled on upgrade. An upgraded system should exhibit the same behaviors as a newly-installed system. == How To Test == * Fedora 31/32 KDE users can test today: ** {{code|sudo dnf install earlyoom}} ** {{code|sudo systemctl enable --now earlyoom}} And then attempt to cause an out of memory situation. Examples: ** {{code|tail /dev/zero}} ** https://lkml.org/lkml/2019/8/4/15 == User Experience == earlyoom sends SIGTERM to processes based on oom_score when both memory and swap have less than 10% free and SIGKILL when below 5%. == Dependencies == None == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Owner reverts changes * Contingency deadline: Final freeze * Blocks release? No == Documentation == * {{code|man earlyoom}} * https://github.com/rfjakob/earlyoom * https://www.kernel.org/doc/gorman/html/understand/understand016.html == Release Notes == The earlyoom service is now enabled by default in Fedora KDE. The earlyoom service monitors system memory usage. If free memory falls below a set limit, earlyoom terminates an appropriate process to free up memory. As a result, the system does not become unresponsive for long periods of time in low-memory situations. The following is the default earlyoom configuration: * If both RAM and swap go below 10% free, earlyoom sends the SIGTERM signal to the process with the largest oom_score. * If both RAM and swap go below 5% free, earlyoom sends the SIGKILL signal to the process with the largest oom_score. For more information, see the earlyoom man page. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

18 90

Searching a new home for my packages
by Thomas Spura 03 Sep '20

03 Sep '20

Hi all, unfortunately, I don't find much time anymore to look for my packages .. Due to that, I would like to step down as the primary maintainer and am searching for a new home for my packages! On most of them, I am co-maintainer and the following are the ones, where I am maintainer (and hope I didn't forget one, if so, please let me know): - python-jupyter-client - python-jupyter-core - python-matplotlib - python-tornado - ipython - mpi4py - php-zmq - pynac Feel free to let me know, if you are interested in taking any of those packages. Best, Thomas -- Fedora: https://fedoraproject.org/wiki/User:Tomspur

8 15

NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide Change proposal
by Ben Cotton 31 Aug '20

31 Aug '20

https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_if… == Summary == Change the default settings plugin of NetworkManager so that new profiles will be created in keyfile format instead of ifcfg-rh format. == Owner == * Name: [[User:Thaller| Thomas Haller]] * Email: <thaller(a)redhat.com> == Detailed Description == NetworkManager supports settings plugins to persist connection profiles to disk. There is the native ''keyfile'' format and the Fedora/RHEL specific ''ifcfg-rh'' format originally from initscripts. The keyfile plugin is always enabled in NetworkManager and can handle any supported type of profile. It stores profiles under `/{etc,usr/lib,run}/NetworkManager/system-connections` and is documented in [https://developer.gnome.org/NetworkManager/stable/nm-settings-keyfile.html nm-settings-keyfile manual]. The ifcfg-rh format is in part compatible with the network-scripts package from initscripts, however both network-scripts and NetworkManager define their own extensions ([https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html [1]]). Since network-scripts and NetworkManager are fundamentally different, the same ifcfg file is not treated exactly the same by both systems. In the past, having the ifcfg-rh format made it easier for users familiar with initscripts to migrate to/from NetworkManager. The settings plugins are configurable in [https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html NetworkManager.conf] via the `"main.plugins"` option. Multiple plugins can be configured and on Fedora 32 and older, the compile time default for the option is `"ifcfg-rh,keyfile"`. This means, that when NetworkManager stores a new profile to disk, it will first try to persist it in ifcfg-rh format before falling back to keyfile format, if the ifcfg-rh plugin doesn't support the profile type. When reading profiles from disk, NetworkManager will read and expose profiles from both settings plugins and when modifying an existing profile, it will update the existing file and preserve the settings plugin. This Change is about to change the default for `"main.plugins"` from `"ifcfg-rh,keyfile"` to `"keyfile,ifcfg-rh"`. == Feedback == This was brought up on the NetworkManager mailing list ([https://mail.gnome.org/archives/networkmanager-list/2020-May/msg00002.html [1]]]). Fedora CoreOS doesn't use ifcfg-rh files at all, only keyfile. Also, RHEL CoreOS uses the `"main.plugins=ifcfg-rh,keyfile"` configuration too. For CoreOS this of course is simpler, because they don't deal with existing user configurations and tools that would break during upgrade. == Benefit to Fedora == The long term goal of NetworkManager is to move away from ifcfg-rh files. That will be difficult as it affects existing installations and will require migration of existing configurations. This change is only a first step and affects how NetworkManager by default persists new profiles to disk. The ifcfg-rh format arguably has an uglier syntax and, contrary to keyfile, does not support all profile types. Also, keyfile plugin is available on every NetworkManager installation because that is the only plugin that supports all profiles. Having multiple plugins and file formats is confusing. By now, initscripts' `network-script` package is deprecated in Fedora and upstream wants to move away from that format in the long term. Also maintaining multiple settings plugins is a maintainance burden, and in the past there were subtle bugs where ifcfg-rh did not implement all settings (e.g. [https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10754 CVE-2020-10754]). On other Linux distributions NetworkManager uses the keyfile format by default. It is a general goal that NetworkManager works similar on all distributions. == Scope == * Proposal owners: The default settings for `"main.plugins"` can already be selected at compile time. This only requires building the package with a different default ([https://src.fedoraproject.org/rpms/NetworkManager/blob/a06b38bcbe8f9a38bada… [3]]). * Other developers: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This affects most users, unless they explicitly set the option in NetworkManager.conf configuration. The biggest effect of this change is that new profiles will now preferably be persisted in keyfile format. This changes behavior for users who expect NetworkManager to write ifcfg-rh files, or who have scripts or tools that expect that. What will still work is that existing ifcfg files are loaded after upgrade. Users who only use the D-Bus API (via one of the client applications like nmcli or the GUI), shouldn't notice the difference. As before, users still can explicitly configure the settings plugins in NetworkManager.conf. This only affects the default, but it affects existing installations if the user didn't explicitly configure NetworkManager's `"main.plugins"` option. The Change will be implemented by changing the compile time default, instead of dropping a configuration snippet. The reason is that it is preferably that the installation of NetworkManager avoids extra configuration. The default behavior should be achived without any configuration. During package update there would be the possibility to drop a file `/etc/NetworkManager/02-update-plugins-ifcfg-rh.conf` that preserves the previous behavior. However, I don't think that is necessary. After upgrading NetworkManager, it will still read ifcfg-rh file so for the user it is less necessary to preserve the previous behavior. Also, dropping configuration snippets during package upgrade has its own downsides because new installations behave different than upgraded systems. == How To Test == You can already test the effect by explicitly configuring the setting which will become the default. For example, add a file `/etc/NetworkManager/conf.d/99-main-plugins.conf` with content [main] plugins=keyfile,ifcfg-rh == User Experience == NetworkManager now preferably uses the keyfile format (INI files). This format is probably easier to understand to users and also has a closer resemblance to how the profile is presented in nmcli. If the user is using NetworkManager tools that use the D-Bus API (like nmcli or the GUI), then the used storage plugin and format is usually of no concern for the user. == Dependencies == None == Contingency Plan == The `"main.plugins"` option exists for a long time in NetworkManager. All that changes here is the default of this option. * Contingency mechanism: revert the change * Contingency deadline: beta freeze * Blocks release? No == Documentation == I am not aware of documentation that gets affected by this. == Release Notes == NetworkManager now prefers the keyfile settings plugin over ifcfg-rh plugin when writing new connection profiles to disk. Existing ifcfg-rh files are still handled as before. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

7 8

Fedora Packager Dashboard available for testing
by Josef Skladanka 18 Aug '20

18 Aug '20

Hi, We'd like to announce public testing of the Packager Dashboard - a new service for Fedora package maintainers aiming to provide all relevant data: FTBFS/FTI status (from both Bugzilla, Koschei and health check), orphan warnings, bugzillas, pull requests, active overrides and updates - at a single place in an easy to read and filter way. The Dashboard is now available: https://packager.fedorainfracloud.org/ Packager Dashboard leverages caching in the Oraculum backend to significantly speed-up loading times with comparison to querying all the relevant resources separately. We, of course, can't cache the entire Bugzilla, Pagure, Bodhi... so we only cache data for users who visit Packager Dashboard at least once per 14 days. Please keep in mind that the first load for a “new” user might take a while. Most of the data sources are refreshed every hour. You can use the Dashboard for individual accounts as well as for FAS groups. We'd love to hear your feedback. Please keep in mind that this is testing deployment - it's currently running on a server with very limited resources and we're aiming for production deployment on CommuniShift during this summer. Feel free to provide ideas or bug reports at https://pagure.io/fedora-qa/packager_dashboard or simply send an email reply to this thread with all kinds of feedback. I'd like to mention the other people who made this possible: - Miro Hrončok (churchyard) - Original idea <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…> and ideas for data to display - František Zatloukal - Backend <https://pagure.io/fedora-qa/oraculum> - Lukáš Brabec - Frontend <https://pagure.io/fedora-qa/packager_dashboard> Josef

17 28

Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
by Bohdan Khomutskyi 13 Aug '20

13 Aug '20

Summary Improve compression ratio of SquashFS filesystem on the installation media. Owner Name: Bohdan Khomutskyi Email: bkhomuts(a)redhat.com Current status Targeted release: I propose this change for Fedora 32 Last updated: Jan 5 2020 Pagure.io issue: https://pagure.io/releng/issue/9127 I was unable to create an article in Fedora wiki system. Detailed Description As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is compressed with default settings of mksquashfs. The standard configuration is set to XZ algorithm with block size of 128k and BCJ filter enabled. Those parameters can be adjusted which will lead to a better compression ratio and/or reduction of the CPU usage at build time. This is simple to achieve. Recently, Lorax has gotten support[1] for adjusting the compression options for mksquashfs via the configuration file. The file should be altered as following: [compression] bcj = yes args = -b 1M -Xdict-size 1M -no-recovery Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively. Could be adjusted. Benefit to Fedora - Reduction of the installation media size and the cost of storing and distributing Fedora. - Reduction of the CPU usage at build time. Depending on which compression parameters chosen. - See a graphical detail at https://pagure.io/releng/issue/9127. Scope - Proposal owners: The build environment should have support for adjusting the Lorax configuration file.. Lorax is a program that produces the LiveOS/squashfs.img file on the installation media. One of the way to allow for such customization, is to add a feature in Pungi, to allow for passing -c option to Lorax. - Release engineering: #9127 <https://pagure.io/releng/issue/9127> - Policies and guidelines: N/A - Trademark approval: N/A Upgrade/compatibility impact - This change comes at a cost of higher memory usage during the installation. Based on my personal estimations, this should not be the issue. Since the decompression should require up to 1MiB per thread. User Experience - Increasing the block size on the current configuration with EXT4 file system, should increase latency while accessing the EXT4 filesystem. The exact impact is to be evaluated. - The impact of latency will be reduced, if the plain SquashFS option is be choosen. Dependencies - N/A Contingency Plan - N/A Documentation https://pagure.io/releng/issue/9127. mksquashfs(1) Release notes See also https://pagure.io/releng/issue/8646 -- Bohdan Khomutskyi Release Configuration Management engineer Red Hat

18 50

Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages
by Ben Cotton 10 Aug '20

10 Aug '20

https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages == Summary == All retired packages are obsoleted by `fedora-retired-packages`. == Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Email: msuchy(a)redhat.com == Detailed Description == Right now `fedora-obsoletes-package` retires packages which cause an issue during an upgrade. We do nothing about all other retired packages. Now imagine the following story (it already happened many times): We have package "foo". It is a leaf package. No one requires it. It uses just basic libraries. A user installs it during F32 lifetime. Around F35 the upstream dies. Around F37 Fedora maintainer retires the package (or orphan and it later become retired). Because the package is a leaf package, it causes no pain during upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And then during upgrade to F43 it suddenly causes a problem. But because it is .fc37 everyone will hesitate to add it fedora-obsolete-packages.fc43. Additionally, during F38-F43, users may expect that their system is fully updated and they have no security issues. But it is not true about package "foo", which no one maintains. And users are not aware of that because he does not follow fedora-devel mailing list. Obviously. What I propose is: As part of the retirement process we add the to fedora-retired-packages: Obsoletes: foo < %{latestversion+1} And during upgrade from F37->F38 the package will be removed. If the user wants to preserve the package (e.g., because it moved to Copr), he simply uninstalls and protects the installation of fedora-retired-packages. But that will be an informed decision. The benefits are: * we do not leave unmaintained packages on a user's machine. * We make sure that archaic packages do not break upgrade between two versions of Fedora. == Feedback == After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5 discussion with fedora-obsolete-package maintainer] I filed this Change proposal to include a wider audience. See relevant [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… thread on devel mailing list]. == Benefit to Fedora == * We do not leave unmaintained packages on a user's machine. * We make sure that archaic packages do not break upgrade between two versions of Fedora. == Scope == * Proposal owners: Create package `fedora-retired-packages` as sub-package of `fedora-obsolete-packages` [https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532] Edit https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsol… guidelines with: The retired package should be obsoleted by one of: * fedora-obsoleted-packages - if the package can cause problem during upgrade to next version of Fedora * fedora-retired-packages - in all other cases It is enough to open an issue on https://src.fedoraproject.org/rpms/fedora-obsolete-packages * Other developers: No other work should be necessary. * Release engineering: This is optional. I may work with rel-eng to change https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_pack… to automatically create PR for `fedora-obsolete-packages` * Policies and guidelines: As stated above https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsol… will need an update. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == During an upgrade, all retired packages will be automatically removed. User may opt-out by: <pre> $ cat /etc/dnf/dnf.conf [main] ... exclude=fedora-retired-packages </pre> == How To Test == 1. Upgrade to next version of Fedora. 2. Check all retired packages are removed. == User Experience == - Packages that are no longer maintained are removed during a distribution upgrade. == Dependencies == This update has no dependencies on any other package. == Contingency Plan == * Contingency mechanism: Drop `fedora-retired-package`. Or remove `Obsoletes` from this sub-package. * Contingency deadline: Beta freeze * Blocks release? No == Documentation == TBD == Release Notes == TBD -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

25 48

[ELN] Opt out python2.7 from ELN
by Miro Hrončok 10 Aug '20

10 Aug '20

Hello, as a maintainer of the python2.7 package I was surprised to see it being built for ELN and I like to start a discussion on whether and how can I opt out this deprecated package from ELN. Since there is no tracker or dedicated mailing list, I am following the advice given somewhere else on devel, to use this list, possibly with the [ELN] marker in subject. Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel June 2020