devel August 2020

devel@lists.fedoraproject.org

217 participants
358 discussions

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

Orphaning openbabel
by Dominik 'Rathann' Mierzejewski 06 Oct '20

06 Oct '20

Hi everyone, I've finally admitted to myself that I have no time to take good care of openbabel: https://src.fedoraproject.org/rpms/openbabel It has one FTBFS bug in rawhide (related to cmake macro changes) and two requests to update. One in Fedora to move to the recent 3.x series and one for EPEL to update from 2.3 to 2.4. It has 9 consumers in Fedora: avogadro avogadro2 chemtool ghemical gnome-chemistry-utils IQmol kalzium molsketch xdrawchem Hopefully, one of their maintainers (Bcc'd) or someone from SciTech SIG (Cc'd) can pick this up. I'll orphan it in a few days if nobody responds here with their FAS ID. Regards, -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

4 8

LTO and F33
by Jeff Law 02 Oct '20

02 Oct '20

So we're at a point where the F33 FTBFS issues related to LTO that I'm aware of have been resolved (by opting the package out of LTO). I still expect some LTO issues will pop up as packages fix things like missing dependencies, cmake macros, etc. I continue to be available to investigate potential LTO issues, but package maintainers will need to contact me as I'm not actively looking for new LTO issues. My focus is now turning to the packages with LTO opt-outs. I'll be extracting bug reports for upstream (primarily GCC), trying simple workarounds for old style symbol versioning, identifying backports from upstream GCC that allow us to remove LTO opt-outs and the like. So there should be a trickle of opt-outs removed, but otherwise should largely be invisible to the F33 release process. I'd like to thank everyone involved for being patient while we worked through various issues and I look forward to continuing to make incremental improvements now that the bulk of the LTO work has landed. jeff

5 17

F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)
by Ben Cotton 02 Oct '20

02 Oct '20

https://fedoraproject.org/wiki/Changes/OptimizeSquashFS == Summary == Improve compression ratio of SquashFS filesystem on the installation media. == Owner == * Name: [[User:bkhomuts|Bohdan Khomutskyi]] * Email: bkhomuts(a)redhat.com == Detailed Description == As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is compressed with default block size of mksquashfs. The default block size is 128k. Additionaly, lorax sets BCJ filter depending on the architecture. 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 for adjusting the compression options for mksquashfs via the configuration file. The file should be altered as following: <pre> [compression] bcj = no args = -b 1M -Xdict-size 1M -no-recovery </pre> Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively; bcj -- branch-call-jump filter. Based on the results above, I'd suggest selecting the following ''optimal configuration'': XZ algorithm, with block size of 1MiB and without BCJ filter (plain xz -b 1M, without -Xbcj x86). On the right, you can see the impact of the compression algorithms on installation time. As can be seen from the picture on the right hand side, selecting 'plain xz -b 1M configuration' has minimal impact on the installation time and CPU usage during the installation. The compression will result in +6.51% or, in real terms, +24.94s additional installation time, compared to the savings of 142 MiB on the installation media, refer to the documentation section to download the ISO images. This increase in installation time will be compensated by the change in the installer: https://github.com/rhinstaller/anaconda/pull/2292 I noticed, that even with maximum compression, CPU is not fully utilized during installation. == 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. == Scope == * Proposal owners: The build environment should have support for adjusting the Lorax configuration file and -squashfs-only parameter. Lorax is a program that produces the LiveOS/squashfs.img file on the installation media. One of the ways to enable such customization is to introduce support in Pungi to pass -c option to Lorax. * Other developers: The pungi utility should support passing the custom configuration file location to the Lorax utility. This option should apply during buildInstall phase of pungi. * Release engineering: [https://pagure.io/releng/issue/9127]  * Policies and guidelines: Not required. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == <pre> mkdir -p /mnt/new /mnt/old sudo mount -o loop,ro FedoraInstallationOld.iso sudo mount -o loop,ro FedoraInstallationNew.iso ls -l /mnt/{new,old}/LiveOS/squashfs.img </pre> And then calculate the size difference. == User Experience == * Decreasing the installation image size will reduce cost of mirroring and storing Fedora installation images. * Decreasing the installation image size will reduce the download time. * 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 == Pungi, a utility that builds the compose, should include new functionality mentioned above. Alternatively, the /etc/lorax/lorax.conf should be altered in the environment where Lorax is running. == Contingency Plan == N/A == Documentation == https://pagure.io/releng/issue/9127. mksquashfs(1) lorax(1) https://docs.pagure.org/pungi Select ISOs can be downloaded at https://khomutsky.com/fedora-dvd/ Spreadsheet pictured above [[File:Comparison Table SquashFS.ods]] [https://github.com/rhinstaller/anaconda/pull/2292 Multi-core decompression of SquashFS merge request] -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

13 22

Orphaning qjackctl
by Fernando Lopez-Lezcano 28 Sep '20

28 Sep '20

Hi all, This wants to go to a new owner: https://src.fedoraproject.org/rpms/qjackctl I am the "official" maintainer, something I had completely forgotten about (this was a VERY long time ago). Orcan (Ogetbil) took care of it for a long time but now Christoph Karl (copied) would like to take over (and alerted me to the fact that it is my package!) Looks like this is the way to get this rolling... (let me know if there is anything else I need to do) Thanks, -- Fernando

4 6

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

fedbot spamming in #fedora
by Germano Massullo 27 Sep '20

27 Sep '20

Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times per day about Fedora respins update? [16:51] <fedbot> *** F32-20200715 updated lives available: https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more info #fedora-respins ***

2 5

s390x builder issues
by kevin 23 Sep '20

23 Sep '20

Greetings. As many of you know, the s390x builders have been very slow or failing builds with intermittent i/o issues for a while now. I've done what I can to mitigate this on the builder level, but the problem is at a deeper level. I've been asked to try and collect issues that package maintainers are hitting on these builders and provide them to mainframe admins so they can understand the impact on us and prioritize more resources or other corrective measures. To that end, if you are a maintainer and: * A build on s390x being slow affects you (needed for another build, important bug fix, etc) in a serious way or * a build on a s390x builder fails in some odd way that is NOT related to your package (unable to download src.rpm, checksum mismatches, etc). I'd love for you to note: * the link to the failed/slow task * The time (UTC preferred) * which exact builder it was * what the issue was * how it impacted your fedora work into: https://pagure.io/fedora-infrastructure/issue/9232 Please don't post to the list, mail me privately, etc. Just add the info to the above issue. Thanks for your help kevin _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

3 2

PostgreSQL 13 - Fedora 33 Self-Contained Change proposal
by Ben Cotton 22 Sep '20

22 Sep '20

https://fedoraproject.org/wiki/Changes/PostgreSQL_13 == Summary == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 12 to version 13 in the non-modular (main) builds. == Owner == * Name: [[User:panovotn| Patrik Novotny]] * Email: panovotn(a)redhat.com == Detailed Description == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 12 to version 13 in the non-modular (main) builds. This also involves updating and rebuilding the PostgreSQL plugins that depend on postgresql server. == Benefit to Fedora == Latest stable software is used by Fedora users. == Scope == * Proposal owners:  **Prepare PostgreSQL 13 as a module for Rawhide and at least one stable Fedora release (done) **Prepare PostgreSQL 12 as a module for Rawhide, so there would be a failover in case of problems **Build PostgreSQL 13 to Rawhide **Check software that requires or depends on `postgresql-server` or `libpq` packages for incompatibilities **Gather user input on the changes between PostgreSQL 12 and PostgreSQL 13 * Other developers: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The PostgreSQL client library (libpq component) is compatible, so there shouldn't be any issues, but rebuild of the depended components is better to be sure. There is a [https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/ COPR build] available for testing. Server plugins might require a newer version update, because they sometimes have explicit server requirements. PostgreSQL maintainer will help fixing/rebuilding any issues in the plugins. == How To Test == Usual testing as when upgrading between major PostgreSQL versions, running `postgresql-setup --upgrade` is necessary between major versions. Test that all other software runs well with PostgreSQL 13. == User Experience == The users will have to upgrade their databases the same way as between major PostgreSQL versions, aka `postgresql-setup --upgrade`. If users want to stick with PostgreSQL 12 for a little longer, there should be PostgreSQL 12 module. If users want to test it before it reaches Fedora 33, there is a [https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/ COPR build] available. == Dependencies == There are some packages (mostly server plugins), that build on top of PostgreSQL. Since the separation of PostgreSQL client library (libpq component), only packages that build server plugins should use postgresql package in BuildRequires, others should use libpq. In both the cases, rebuild should be done to make sure all potential binary incompatibilities are handled. == Contingency Plan == Modules will provide the functional version of PostgreSQL 12, available to all users. == Documentation == Upgrade startegy: https://www.postgresql.org/docs/13/upgrading.html == Release Notes == Release notes for PostgreSQL 13 release: https://www.postgresql.org/docs/13/index.html Overall overview of the changes and improvements: https://www.postgresql.org/docs/13/release-13.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

6 8

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2020