Fedora 34 Change: Deprecate xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Deprecate_xemacs == Summary == Deprecate the xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw packages, all of which have dead upstreams. == Owner == * Name: [[User:jjames|Jerry James]] * Email: loganje...@gmail.com == Detailed Description == I have been part of XEmacs upstream for over 20 years, and have maintained the Fedora package for over 11 years. Upstream development had already slowed significantly when I became Fedora maintainer. The last release was over 7 years ago. Since that time, development has essentially come to a halt. Somebody will push a commit every now and then, but significant bugs are not being fixed. I see no future for the project. We should start moving towards dropping it from the distribution. The upstream sources have been spread across 3 packages in Fedora: xemacs, xemacs-packages-base, and xemacs-packages-extra. In addition, the xemacs package uses an ancient, unmaintained 3D X library: neXtaw. It's last release was in 2003. Since xemacs is the only package in Fedora that uses neXtaw, I propose that it also be deprecated so we can eventually drop it. Deprecation is warranted because there are about a dozen XEmacs add-on packages in Fedora. This will prevent us from adding any more as we work to retire the existing add-ons. == Feedback == On December 7, 2020, I [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VDETPULZDBMXBXJKEFZX7DQ5R6W6FBXT/ communicated my intent to file this Change] on fedora-devel-list. There has been no community feedback. == Benefit to Fedora == This Change will open a path for us to eventually remove unmaintained software from the distribution. == Scope == * Proposal owners: The only required work is the addition of `Provides: deprecated()` to the 4 affected packages. * Other developers: No immediate work is required. Eventually, maintainers of XEmacs add-on packages will need to retire those packages so that XEmacs itself can be retired. * Release engineering: This change does not require coordination with or impact release engineering and does not require a mass rebuild. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: While this proposal does not match any of the [https://docs.fedoraproject.org/en-US/project/objectives current objectives], it is not opposed to any. == Upgrade/compatibility impact == Since the Change only deprecates packages, it has no immediate effect on upgrades or compatibility. Eventually, when the affected packages are retired, fedora-obsolete-packages will be updated to properly manage upgrades. == How To Test == N/A (not a System Wide Change) == User Experience == This change will not lead to any immediate changes in user experience. Eventually, we will retire the affected packages, which will impact users of those packages. We will seek to communicate the upcoming retirement as we work towards it. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? None == Documentation == N/A (not a System Wide Change) == Release Notes == The xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw packages have been deprecated. XEmacs users should prepare for the eventual removal of these packages from the Fedora distribution. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org
Fedora 34 Change: Xfce-4.16 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/xfce-4.16 == Summary == Xfce 4.16 is a stable release with proven components, provide features to both new and power users alike. This change proposal is submitted to sync fedora packages with the latest upstream release. == Owners == * Name: [[User:nonamedotc| Mukundan Ragavan]] * Email: nonamed...@fedoraproject.org * Name: [[User:kevin| Kevin Fenzi]] * Email: ke...@scrye.com == Detailed Description == This change migrates Xfce desktop environment (DE) to the latest version provided by upstream developers. This release brings, amongst others, the following features * client-side decorations * fractional scaling * new status tray plugins * Streamlined application chooser (i.e. merged "mime type editor" and "default applications") Full feature list can be viewed at [https://xfce.org/about/news Xfce news] == Benefit to Fedora == Updating Xfce to 4.16 will provide Fedora Xfce users stable but latest versions of upstream software. We will also be able to provide timely bug fixes. == Scope == * Proposal owners: ** Update core xfce packages to 4.16 ** Rebuild plugins once core packages are build * Other developers: N/A (not a System Wide Change) * Release engineering:
Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig == Summary == This change makes the GRUB configuration files layout to be consistent across all the supported architectures. Currently EFI is a special case since the GRUB configuration file and environment variables block are stored in the EFI System Partition (ESP) instead of the boot partition (or `/boot` directory if no boot partition is used). == Owner == * Name: [[User:Javierm|Javier Martinez Canillas]] * Email: javi...@redhat.com * Name: [[User:Gicmo|Christian Kellner]] * Email: ckell...@redhat.com == Detailed Description == The GRUB configuration files layout on EFI platforms is not consistent with the other non-EFI platforms (e.g: x86 with legacy BIOS, ppc64le with Open Firmware). On platforms using EFI the GRUB configuration file (`grub.cfg`) and environment variables block (`grubenv`) are stored in the EFI System Partition (ESP) while for non-EFI platforms these are stored in the boot partition (or `/boot` directory if not boot partition is used). The reason for this is that the path where the GRUB bootloader searches for its configuration file varies depending on the firmware interface used. In most cases, GRUB searches for it in the path set in the `$prefix` variable. The device is not specified in that case, GRUB just searches for a configuration in this path for every detected device. But on EFI, a special `$fw_path` variable is used instead. This variable specifies both the device and path from where the GRUB bootloader was loaded and these are used to search for the configuration file. This is done for security reasons, to make sure that the correct GRUB configuration file is used and not just the first one found in one of the detected devices. Since the GRUB binary is located in the ESP, it expects to find the configuration file in that location as well. But this creates the mentioned inconsistency, because the GRUB configuration file has to be stored in `/boot/efi/EFI/fedora/grub.cfg` while for non-EFI platforms it has to be stored in `/boot/grub2/grub.cfg`. This leads to a GRUB configuration layout that is confusing for users and error prone, since either the tools that are used to manage these files have to be aware of the differences or symbolic links used to hide the fact that the pats differ depending on the platform. Also, it creates artificial constraints on the OS installation due the differences in the configuration layout used. A system installed when using EFI won't be bootable if the firmware configuration is changed to boot using legacy BIOS instead, for example enabling the EFI Compatibility Support Module or moving the disk to a BIOS machine. The proposal is to always store the `grub.cfg` and `grubenv` files in the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg` to only be a small configuration file that sets a different `$prefix` variable and loads the configuration file stored in `/boot/grub2/grub.cfg`. The `$prefix` variable will be set to the device partition where `/boot/grub2/grub.cfg` is stored, using the partition filesystem's Universally Unique IDentifier (UUID). That way the correct GRUB configuration file will be loaded, making it as secure as the current approach where the configuration file in the ESP is used. A drawback of the new approach is that the GRUB configuration will now depend on the boot partition (or `/boot` directory if no boot partition is used). But since the kernel and initramfs images are stored there too, the bootloader configuration already has this dependency anyways. Note that the proposed configuration files layout is already used by the Fedora CoreOS Assembler (COSA) and OSBuild image builders. So this will make the systems installed with Anaconda to be consistent with the images generated by these. == Benefit to Fedora == This change will not only simplify and make less confusing the GRUB configuration but also allow the following improvements: * To have a consistent configuration across all the architectures using GRUB. * Allow the same installation to be booted with either EFI or legacy BIOS. * Use the same documentation and commands for all architectures instead of having EFI as a special case. * Make GRUB configuration tools more robust by not relying on symbolic links to be created and not having to handle platform specific cases. * Align with images generated by COSA and OSBuild on how the GRUB configuration files are used. * Align with other Linux distributions on how the GRUB configuration files are used. == Scope == * Proposal owners: ** Modify Anaconda to generate the `grub.cfg` and `grubenv` files in `/boot/grub2/` instead of `/boot/efi/EFI/fedora/` for EFI platforms. ** Make Anaconda to generate the minimal GRUB config file in the ESP that sets the `$prefix` variable and loads the configuration file located in `/boot/grub2/grub.cfg`. ** Modify the grub2 package scriptlets to not generate the `/boot/grub2/grubenv` and
Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements == Summary == Currently all packages that are not opted out of LTO include -ffat-lto-objects in their build flags. This proposal would remove -ffat-lto-objects from the default LTO flags and only use it for packages that actually need it. == Owner == * Name: [[User:law | Jeff Law]] * Email: l...@redhat.com == Detailed Description == -ffat-lto-objects was added to the default LTO flags to ensure that any installed .o/.a files included actual compiled code rather than just LTO bytecodes (which are stripped after the install phase). However, that is wasteful from a compile-time standpoint as few packages actually install any .o/.a files. This proposal would remove -ffat-lto-objects from the default LTO flags and packages that actually need the option would have to opt-in via an RPM macro in their .spec file. This should significantly improve build times for most packages in Fedora. To ensure that we can identify packages that need the opt-in now and in the future, the plan is to pass to brp-strip-lto a flag indicating whether or not the package has opted into -ffat-lto-objects. If brp-strip-lto finds .o/.a files, but the package has not opted into -ffat-lto-objects, then brp-strip-lto would signal an error. == Benefit to Fedora == The key benefit to Fedora is improved package build times and lower load on the builders. == Scope == * Proposal owners: The feature owner (Jeff Law) will need to settle on a suitable RPM macro to indicate an opt-in to -ffat-lto-objects, implement the necessary tests in brp-strip-lto and opt-in the initial set of packages. This will be accomplished by doing the prototype implementation locally, building all the Fedora packages to generate the opt-in set. Committing the necessary opt-ins, then committing the necessary changes to the RPM macros. * Other developers: There should be minimal work for other developers. The most likely scenarios where other developers will need to get involved would include: # Packages which are excluded from x86_64 builds and which need the opt-in will need the appropriate package owners to add the opt-in. # Packages which are FTBFS when the builds are run to find the set of packages that need to opt-in and which need to opt-in will need packager attention. # It is possible that the faster builds may trigger build failures in packages that have missing dependencies in their Makefiles. We saw a few of these during the initial LTO work and those packages were either fixed or -j parallelism removed. This work may expose more of these problems. I expect these all to be relatively rare occurences, but with 9000+ packages in Fedora I wouldn't be surprised if we see a few of each of these issues. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) This should have no release engineering impacts. * Policies and guidelines: The packaging guidelines will need to be updated to document the new macro. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: This proposal does not align with any current Fedora Objectives. == Upgrade/compatibility impact == This change should have zero impact on upgrade/compatibility. In fact, the change should have no user visible impacts. == How To Test == No special testing is needed. Any issues with this proposal will show up as FTBFS issues. == User Experience == Users should see no changes to the user experience. == Dependencies == Packages which need to opt-in to -ffat-lto-objects will need their .spec files updated to include the new macro. == Contingency Plan == If this can not be completed by final development freeze, then the RPM macro changes would not be installed and the change could defer to Fedora 35. * Contingency mechanism: Proposal owner will only commit the RPM macro changes once the opt-in package set has been identified and opt-ins added to those package's spec files. So no special contingency mechanism should be needed * Contingency deadline: It is most beneficial to have this completed before the mass rebuild; however, the drop dead date should be beta freeze. * Blocks release? No * Blocks product? No == Documentation == No upstream documentation. Packaging guidelines will need a minor update. == Release Notes == I do not expect this change to require any release notes. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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:
Fedora 34 Change: IBus 1.5.24 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IBus_1.5.24 == Summary == IBus will use the mmap(2) feature to show emoji and Unicode tables in order to reduce the physical memory usage. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == Currently IBus disables the emoji and Unicode features in some system users likes gdm, liveuser, gnome-initial-setup not to exhaust the limited memory usage with LiveDVD. The emoji data requires about 10MB and the Unicode data requires about 15MB and the total 25MB is required roughly to show the tables. The Fedora testers ask to test the emoji feature and Unicode feature in LiveDVD and the next IBus will use mmap to be available the emoji and Unicode data with liveuser. == Feedback == Fedora I18N testers asks to test the emoji and Unicode data without installing Fedora to disc. == Scope == * Proposal owners: * Other developers: N/A * Release engineering: (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Objectives: == Upgrade/compatibility impact == About 25MB free disc space will be needed. == How To Test == # Run Fedora LiveDVD and log into the Fedora desktop # Run `gnome-control-center region` and add both XKB and input method sources. E.g. "English (US)" and "Hangul" # Enable an XKB source with mouse or Super-space shortcut key. E.g. "English (US)" # Type Ctrl-Shift-e, "smile", space, and Enter key. U+1F603 is output. == User Experience == The physical memory usage will be reduced. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert the change to IBus. * Contingency deadline: Beta release * Blocks release? No * Blocks product? None == Documentation == TBD -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org
Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
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: mic...@michel-slm.name, dcava...@fb.com, jo...@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 mount -o compress=zstd:1 ** 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 btrfs filesystem defrag -czstd -r, updating `/etc/fstab` and remounting. == How to test == Existing systems can be converted to use compression manually with btrfs filesystem defrag -czstd -r, 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 mount -o compress=zstd:1 == 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 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org
Planned Outage - taiga - 2021-01-05 07:00 UTC
There will be an outage starting at 2021-01-05 07:00 UTC which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-01-05 07:00UTC' Reason for outage: Upgrade to a more recent/patched taiga Affected Services: Only taiga (ie: teams.fedoraproject.org) Ticket Link: https://pagure.io/fedora-infrastructure/issue/9552 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org
