devel December 2020

devel@lists.stg.fedoraproject.org

220 participants
342 discussions

Assimp soname bump
by Rich Mattes 31 Jul '21

31 Jul '21

Hi, I plan to update assimp from 3.3.1 to the latest release (5.0.1) in rawhide this week. The following packages will be affected: fawkes-0:1.3.0-11.fc33.src mrpt-0:1.4.0-17.fc33.src pioneer-0:20200203-1.fc33.src vkmark-0:2017.08-0.8.20180123git68b6f23.fc32.src I will take care of the rebuilds and any fallout/updates that need to happen. Rich

2 2

How to easily automate test builds in a COPR project
by Richard Shaw 29 Jul '21

29 Jul '21

I maintain a suite of ham radio related packages. The developer is very active and often creates test versions adding and incrementing the "tweak" part of the version which is removed for the full releases and the patch level incremented. Currently I'm just trying to keep up with them by hand using pagure forks of the official repos so I don't accidentally pollute SCM with the changes and build them in COPR. Things I need to manage automagically: 1. Monitor the test URLs to look for new versions. I could write a bash script for this and add a cron or systemd timer but I was hoping for something that took less time as I don't have a lot of that :) Would it be permissible to create a <package>-testing entry in release-monitoring.org? 2. Trigger a "fedpkg clone" and add a tweak version. This could probably be managed with macros easy enough, %{?tweak}, or something like that. And then use a script to substitute into "%global tweak ..." 3. I need to download the files from a different location. %if %{?tweak} ... use difference Source0? 4. Build the packages in COPR. Easy enough using a bash script but is there a better way? Thanks, Richard

6 7

The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson 07 Jul '21

07 Jul '21

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. Now in 2017 Intel's technical marketing engineer Brian Richardson revealed in a presentation that the company will require UEFI Class 3 and above as in it would remove legacy BIOS support from its client and datacenter platforms by 2020 and one might expect AMD to follow Intel in this regard. So Intel platforms produced this year presumably will be unable to run 32-bit operating systems, unable to use related software (at least natively), and unable to use older hardware, such as RAID HBAs (and therefore older hard drives that are connected to those HBAs), network cards, and even graphics cards that lack UEFI-compatible vBIOS (launched before 2012 – 2013) etc. This post is just to gather feed back why Fedora should still continue to support legacy BIOS boot as opposed to stop supporting it and potentially drop grub2 and use sd-boot instead. Share your thoughts and comments on how such move might affect you so feedback can be collected for the future on why such a change might be bad, how it might affect the distribution and scope of such change can be determined for potential system wide proposal. Regards Jóhann B. 1. https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration

78 316

Remove old GPG keys?
by Miroslav Suchý 04 May '21

04 May '21

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

15 29

Thoughts about packaging a standalone python-PyQt5-sip?
by Michel Alexandre Salim 27 Apr '21

27 Apr '21

Hi all, Neal and I are looking at getting ButterManager packaged, and it depends on sip and PyQt5-sip: https://github.com/egara/buttermanager/blob/master/requirements.txt Now, this is where things get a bit odd: - the current sip (4.19.24) does not have autogenerated Python provides, but sip5 does: $ sudo dnf repoquery --provides sip Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53 PM PST. sip = 4.19.24-1.fc33 sip(x86-64) = 4.19.24-1.fc33 sip-macros = 4.19.24-1.fc33 $ sudo dnf repoquery --provides sip5 Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53 PM PST. python-sip5 = 5.5.0-1.fc33 python3-sip5 = 5.5.0-1.fc33 python3.9-sip5 = 5.5.0-1.fc33 python3.9dist(sip) = 5.5 python3dist(sip) = 5.5 sip5 = 5.5.0-1.fc33 sip5(x86-64) = 5.5.0-1.fc33 - sip ships PyQt5 bindings with matching version, but sip 5 seems to no longer do so $ sudo dnf info python3-pyqt5-sip Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53 PM PST. Installed Packages Name : python3-pyqt5-sip Version : 4.19.24 Release : 1.fc33 Architecture : x86_64 Size : 244 k Source : sip-4.19.24-1.fc33.src.rpm Repository : @System From repo : fedora Summary : SIP - Python 3/C++ Bindings Generator for pyqt5 URL : https://riverbankcomputing.com/software/sip/intro License : GPLv2 or GPLv3 and (GPLv3+ with exceptions) Description : This is the Python 3 build of pyqt5-SIP. - https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in Fedora (available since last month) - there's a lot of packages that depend on python3-pyqt5-sip (though none use the canonical python3dist(pyqt5-sip) unfortunately) $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires 'python3dist(pyqt5-sip)' Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020 04:28:29 PM PST. $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires python3-pyqt5-sip Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020 04:28:29 PM PST. calibre-0:4.23.0-3.fc34.x86_64 krita-0:4.4.1-1.fc34.i686 krita-0:4.4.1-1.fc34.x86_64 libarcus-0:4.8.0-1.fc34.src mingw-python-qt5-0:5.15.0-4.fc34.src pyqtwebengine-0:5.15.0-2.fc33.src python-pyface-0:7.1.0-1.fc34.src python-pynest2d-0:4.8.0-1.fc34.src python-qt5-0:5.15.0-5.fc34.src python3-arcus-0:4.8.0-1.fc34.x86_64 python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64 python3-poppler-qt5-0:0.75.0-6.fc33.x86_64 python3-pyqtchart-0:5.15.2-1.fc34.i686 python3-pyqtchart-0:5.15.2-1.fc34.x86_64 python3-qgis-0:3.16.1-2.fc34.i686 python3-qgis-0:3.16.1-2.fc34.x86_64 python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64 python3-qt5-base-0:5.15.0-5.fc34.i686 python3-qt5-base-0:5.15.0-5.fc34.x86_64 qhexedit2-0:0.8.9-2.fc33.src scidavis-0:2.3.0-2.fc33.src veusz-0:3.3.1-1.fc34.src veusz-0:3.3.1-1.fc34.x86_64 Any idea what's the best way to handle this? and/or why PyQt5-sip's versioning get so far ahead of sip? Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

4 16

Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok 28 Mar '21

28 Mar '21

Recently I've reported some Big Endian related test failures to an upstream project [0]. I was asked by an upstream project maintainer, whether I know some free Continuous Integration services where they can easily run their testsuite on Big Endian. Any tips? * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu) * Upstream uses AppVeyor to test on Microsoft Windows * It's a pure Python project, noarch, but some changes need to be done when loading/saving binary data (LE) with NumPy on BE system. What I've considered: * COPR (but there is no big endian arch) * (Ab)using Koji (I guess that would be considered a bad practice?) * using QUEMU on Travis CI [1] Any better tips? Thanks [0] https://github.com/mikedh/trimesh/issues/249 [1] https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

8 10

Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Ben Cotton 09 Mar '21

09 Mar '21

https://fedoraproject.org/wiki/Changes/DefaultPipeWire == Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default. == Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email: wim.taymans(a)gmail.com == Detailed Description == Currently, all desktop audio is handled by the PulseAudio daemon. Applications make use of the PulseAudio client library to communicate with the PulseAudio daemon that mixes and manages the audio streams from the clients. The desktop shell (gnome-shell) and the control panel (gnome-control-panel) both use the Pulseaudio client libraries to manage the volume and configuration of the PulseAudio daemon. This proposal is to replace the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak. All PRO audio is handled with the JACK client library, which talks to the JACK server. This proposal will install a JACK client library replacement that talks directly to PipeWire. All existing PRO audio jack applications will then work on top of PipeWire. For legacy ALSA clients, we will install an ALSA plugin that routes the audio directly to PipeWire. With these 3 changes, all audio will be routed to PipeWire. There will then be no more need to install the PulseAudio and JACK daemons. == Feedback == The owner of this proposal has been in context with both the PulseAudio and JACK maintainers and community. PipeWire is considered to be the successor of both projects. == Benefit to Fedora == The end goal is to end up with one audio infrastructure for both Desktop and Pro audio use cases. This will end the fragmentation of the audio landscape. Some of the benefits that PipeWire will bring: * PRO Audio features PipeWire can support both Desktop and PRO Audio use cases. PRO Audio application tend to use the JACK API and JACK daemon, which is hard to setup and integrates poorly with the rest of the system (and PulseAudio in particular). With a replacement libjack library, PRO Audio application can run directly on PipeWire and integrate seamlessly with other ALSA and PulseAudio applications. This would bring Fedora closer to the experience of other operating systems. * Flexibility/Integration PipeWire is designed to be multiprocess. It separates the processing of the multimedia graph and the management into separate processes. This makes it possible to better integrate with the other system components or swap out the default policy for a highly customized one (such as for automotive or embedded). This is in contrast to PulseAudio, which has all logic embedded into the daemon with limited configuration options. In the next phase we expect to greatly expand the user experience and configuration of the audio infrastructure with better integration throughout the system. * Performance PipeWire was designed for high performance and low-latency, using much of the same design as JACK. JACK application should run with comparable performance even in low-latency situations. * Security PipeWire enforces per client security. Object visibility and the actions on them can be configured independently per client. This makes it possible to enforce a security policy for sandboxed applications (Flatpak) such as denying access to certain audio capture devices or block them from interfering with other applications. * Maintainability Both PulseAudio and JACK have very slow development cycles with few new features. The more flexible and distributed nature of the design of PipeWire should encourage more new features and use-cases. == Scope == * Proposal owners: We would make a pipewire-pulse package that provides the same features as the pulseaudio (daemon) package. We would only provide a drop-in replacement daemon, the pulseaudio client libraries will remain unchanged. The idea is that when installing pipewire-pulse, only the pulseaudio package is removed and replaced by the pipewire-pulse implementation. In the same way, installing the pulseaudio package would remove the pipewire-pulse package, making it possible to switch between implementations. This will also allow for an easy rollback. We also need to check and correct the dependencies of other packages. As of this writing, some packages do not state their dependencies correctly and get removed when pulseaudio is removed. We also need to check the JACK to make sure they still install with the replacement JACK client library. The JACK client libraries will be installed in the same way, removing the old JACK client libraries. * Other developers: The distribution needs to default to the pipewire-pulse package instead of pulseaudio. JACK applications need to install the pipewire-libjack client library. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) * Policies and guidelines: * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The pulseaudio package will be uninstalled and pipewire-pulse will be installed. pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34 * avahi network discovery and audio routing. This is not enabled by default but can be activated with paprefs. this includes TCP and RTP transport of audio. * make devices available as UPNP media servers. Not enabled by default, paprefs can be used. * easy configuration of combining all sinks. Questionable feature but possible via paprefs. User scripts will still work but custom configurations of the pulseaudio daemon will not be used anymore. Most of the JACK workflow of managing the JACK daemon is not going to be needed anymore as things will work out-of-the-box. As of this writing, these things are missing from the JACK implementation, we hope to implement them before fedora 34: * latency reporting: useful to align streams * freewheeling: used when rendering a project * jackdbus: used by some tools to manage the graph == How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio. To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package). To test the JACK support, one needs to install pipewire-libjack, which removes the original JACK client and server. After these changes, a restart is needed to make sure the new pipewire-pulse daemon is running. Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify: - patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x) - gnome-control-center: check the audio tab, check the volume sliders and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch. - pavucontrol: check volumes in the input devices tabs and check the microphone volumes - firefox: check out a website with audio/video such as youtube and verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111) - rhythmbox: check if playback works as expected - bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc. - Regular system usage and performance should not change. - JACK tools such as catia, carla should run and can be used to inspect the graph. == User Experience == In general, users should not be able to see any change when using PulseAudio applications. The big change is when using JACK application: - They will start without having to configure and start the daemon. this includes the period size and sample rates. - All devices will be visible in the graph with meaningful names. Devices will be automatically slaved when needed without needing any configuration. - bluetooth devices will be usable as well. == Dependencies == Other packages might need to have their requirements fixed to work with the replacement packages but this is under our control. == Contingency Plan == * Contingency mechanism: Keep existing pulseaudio and JACK client libraries as defaults * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == [https://pipewire.org](PipeWire website) [https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status) [https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md](… guide) [https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md](h… to use/test) -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

52 139

Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
by Ben Cotton 04 Mar '21

04 Mar '21

https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main == Summary == This Change will move Fedora git repositories to use "main" as the default git branch instead of "master". Specific repositories will be manually moved and default git branch for new projects will be set to use "main". The Fedora Community strives to be open and welcoming. Some language around our git repositories is dated and could be more inclusive. Many git repositories currently use "master" as the default branch. This Change will move many repositories (see below) to use a "main" branch as default. This small bit of naming adjustment is in-line with Fedora's vision for free and open source software built by inclusive, welcoming, and open-minded communities. == Owner == * Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben Cotton]], [[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]], [[User:till| Till Maas]] * Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr, mboddu(a)bhujji.com, opensource(a)till.name == Detailed Description == The Fedora Project controls a number of git repositories. This change will move the default branch (that is, the git branch used when nothing is specified) from 'master' to 'main'. Existing git clones will need to pull to get the changed default branch. Existing Pull Requests against the 'master' branch will need to be rebased against the 'main' branch. Documentation will be updated. == Benefit to Fedora == The Fedora Project will be a more welcoming place for new contributors. == Scope == This change will take place in a number of phases: === Phase0 - 2020-12-14 === A guide will be published to explain how maintainers/project managers can change the default branch on pagure.io, which they can then do based in their projects desires. === Phase1 - 2020-12-15 === The following repos will be switched: src.fedoraproject.org/flatpacks/* pagure.io: releng releng/* fedora-comps fedora-kickstarts fedora-infrastructure fedora-lorax-templates fedora-mediawikitheme fedora-packager fedora-infra/* infra-docs koji-fedmsg-plugin workstation-ostree-config pungi-fedora github.com fedora-infra/* === Phase2 - 2021-01-13 === src.fedoraproject.org/* pagure.io default for new projects will be changed to 'main' * Proposal owners: Switching all above listed projects git repos to use 'main' Deleting the 'master' branch Announcing when changes have been made on devel-announce / other lists. * Other developers: Other developers are encouraged to change their upstream projects on pagure.io, github or gitlab. * Release engineering: Releng will adjust any scripts that assume 'master' branch to use 'main' instead. The list includes and maybe few more [https://pagure.io/releng/blob/master/f/scripts/update-critpath.py update-critpath.py] [https://pagure.io/releng/blob/master/f/scripts/block_retired.py block_retired.py] [https://pagure.io/releng/blob/master/f/scripts/update-docs.sh update-docs.sh] [https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py find_unblocked_orphans.py] [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py mass-rebuild-second-run.py] [https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py adjust-eol-modules.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py adjust-eol-modules.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py adjust-eol-modules.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py adjust-eol.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-branc… create-new-release-branches.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py create-branch.py] [https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py adjust-eol-all.py] [https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py check-unretirement.py] [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py mass-rebuild-special.py] [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py need-rebuild.py] [https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py distgit-branch-unused.py] [https://pagure.io/releng/blob/master/f/scripts/create-new-release-branches.… create-new-release-branches.py] * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == Users with old checkouts will need to update their git configuration or re-clone repositories that have changed before they can see any new changes. Repos used to build content for docs.fedoraproject.org can change the default git branch, but the Antora module version (in `antora.yml`) should remain `master` pending support for alternate "unversioned" versions upstream. == How To Test == # git clone <one of the listed repositories> # cd <repositoryname> # git branch should return: `* main` == User Experience == Users and developers will see more welcoming language and that the fedora project expended effort to be more welcoming to them. == Dependencies == none == Contingency Plan == * Contingency mechanism: Revert repositories, scripts, and docs back to the unwelcoming 'master' * Contingency date: 2020-01-13 == Documentation == A short guide on how to change this for pagure.io will be produced. == Release Notes == Many git repositories used to create Fedora releases were moved to use a 'main' branch instead of a 'master' branch. The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

37 97

Change in glibc about _STAT_VER in Fedora rawhide?
by Jan Pazdziora 18 Feb '21

18 Feb '21

Hello, it seems that both fakeroot and fakechroot fail to build in Fedora rawhide (at least partially) because _STAT_VER is no longer declared in the current glibc (or rather, its headers): https://bugzilla.redhat.com/show_bug.cgi?id=1889862 https://bugzilla.redhat.com/show_bug.cgi?id=1901049 The bugzillas are filed against their respective components but I wonder if we have any guidance from the glibc point of view about how these components should proceed. Or is the loss of _STAT_VER an omission and will it come back? -- Jan Pazdziora Product Owner, Platform Security Readiness, Red Hat

3 5

Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
by Ben Cotton 16 Feb '21

16 Feb '21

https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression == Summary == On variants using btrfs as the default filesystem, enable transparent compression using zstd. Compression saves space and can significantly increase the lifespan of flash-based media by reducing write amplification. It can also increase read and write performance. == Owners == * Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide Cavalca]], [[User:josef|Josef Bacik]] * Email: michel(a)michel-slm.name, dcavalca(a)fb.com, josef(a)toxicpanda.com == Detailed description == Transparent compression is a btrfs feature that allows a btrfs filesystem to apply compression on a per-file basis. Of the three supported algorithms, zstd is the one with the best compression speed and ratio. Enabling compression saves space, but it also reduces write amplification, which is important for SSDs. Depending on the workload and the hardware, compression can also result in an increase in read and write performance. See https://pagure.io/fedora-btrfs/project/issue/5 for details. This was originally scoped as an optimization for https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora 33. == Benefit to Fedora == Better disk space usage, reduction of write amplification, which in turn helps increase lifespan and performance on SSDs and other flash-based media. It can also increase read and write performance. == Scope == * Proposal owners: ** Update anaconda to perform the installation using <code>mount -o compress=zstd:1</code> ** Set the proper option in fstab (alternatively: set the XATTR) ** Update disk image build tools to enable compression: *** lorax *** appliance-tools *** osbuild *** imagefactory ** [optional] Add support for [https://github.com/kdave/btrfs-progs/issues/328 setting compression level when defragmenting] ** [optional] Add support for [https://github.com/kdave/btrfs-progs/issues/329 setting compression level using `btrfs property`] * Other developers: ** anaconda: review PRs as needed * Release engineering: https://pagure.io/releng/issue/9920 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == This Change only applies to newly installed systems. Existing systems on upgrade will be unaffected, but can be converted manually with <code>btrfs filesystem defrag -czstd -r</code>, updating `/etc/fstab` and remounting. == How to test == Existing systems can be converted to use compression manually with <code>btrfs filesystem defrag -czstd -r</code>, updating `/etc/fstab` and remounting. == User experience == Compression will result in file sizes (e.g. as reported by du) not matching the actual space occupied on disk. The [https://src.fedoraproject.org/rpms/compsize compsize] utility can be used to examine the compression type, effective compression ration and actual size. == Dependencies == Anaconda will need to be updated to perform the installation using <code>mount -o compress=zstd:1</code> == Contingency plan == * Contingency mechanism: will not include PR patches if not merged upstream and will not enable * Contingency deadline: Final freeze * Blocks release? No * Blocks product? No == Documentation == https://btrfs.wiki.kernel.org/index.php/Compression == Release Notes == Transparent compression of the filesystem using zstd is now enabled by default. Use the compsize utility to find out the actual size on disk of a given file. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

9 17

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 December 2020