devel-announce September 2026

devel-announce@lists.fedoraproject.org

1 participants
4 discussions

F45 Beta is GO
by Aoife Moloney 10 Sep '26

10 Sep '26

The Fedora Linux 45 Beta RC 1.3 compose is GO and will be shipped live on Tuesday,15 September, 2026. As a reminder, we will enter Final Freeze on 6 October, 2026. For more information please check the Go/No-Go meeting minutes[1] or log[2]. [1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-09-… [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-09-… -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F46 Change Proposal: Thin LTO Build Flag (self-contained)
by Aoife Moloney 02 Sep '26

02 Sep '26

Wiki - https://fedoraproject.org/wiki/Changes/Thin-LTO-Build-Flag This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == At present, many packages are built with fat link time optimization (LTO) objects. This can increase RAM requirements and build times. There is a build flag to disable LTO completely. But by using slim objects, one can still have the performance and size improvements offered by LTO with less of a build time cost. == Owner == * Name: [[User:fed500| Benson Muite]] * Email: <benson_muite at emailplus dot org> == Detailed Description == As indicated at https://stackoverflow.com/questions/13799452/what-is-the-difference-in-gcc-… a thin object allows for faster compilation times than a fat object and requires less memory. Adding this as a possible option would give an intermediate option between using fat objects and no link time optimization. This would enable more codes to benefit from easy incorporation of LTO without a substantial increase in compilation times. == Feedback == == Benefit to Fedora == Fedora would benefit from more efficient use of build resources while still getting optimized executables and libraries. There has been a related discussion on https://fedoraproject.org/wiki/Changes/LTOBuildImprovements == Scope == * Proposal owners: The proposal owner (Benson Muite) will create a macro that enables LTO with thin objects. In the gcc compiler suite, this will replace the build flag `-ffat-lto-objects` by `-fno-fat-lto-objects` At present `%global _lto_cflags %nil` is used to disable LTO (see https://fedoraproject.org/wiki/LTOByDefault) A possible modification is `%global _lto_cflags %slim`. * Other developers: Using this flag will be an option. Would suggest other developers try using LTO with slim objects first before disabling LTO completely. If it seems like it would be helpful to be adopted as default, this can be done in a further system wide change. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] No expected changes. * Policies and guidelines: N/A (not needed for this Change) If the change is adopted and after it has been tested, we should consider updating the packaging guidelines that when importing a new C/C++ or Fortran package, packagers should test if using a slim LTO is sufficient instead of disabling LTO altogether. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: General alignment with having an efficient operating system that uses sustainable development practices, but no specific community goal. == Upgrade/compatibility impact == No changes needed. == How To Test == The main thing to test will be modifying spec files for C, C++ or Fortran that use the GCC compiler suite to try using thin objects by setting a macro and then rebuilding When previously a fat object has been used, one should check if there are faster build times and reasonable performance of the resulting outputs. If LTO had been disable due to excessive build times or RAM use, one should test if builds are now possible and if the resulting outputs are more efficient. == User Experience == * Packages will spend less time waiting for builds to complete * Users should get a larger number of optimized packages provided == Dependencies == Only rpm macros package needs to be changed. == Contingency Plan == * Contingency mechanism: Implement by the next freeze * Contingency deadline: Ideally would implement by Fedora 45 release, but before fedora 46 is also fine. * Blocks release? No == Documentation == Packaging guidelines will be updated to document the new option. See: * https://stackoverflow.com/questions/13799452/what-is-the-difference-in-gcc-… * https://github.com/google/highway/pull/3024 * https://fedoraproject.org/wiki/Changes/LTOBuildImprovements N/A (not a System Wide Change) == Release Notes == Release notes should not require any changes. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 1

F46 Change Proposal: Libical4 (system-wide)
by Aoife Moloney 02 Sep '26

02 Sep '26

Wiki - https://fedoraproject.org/wiki/Changes/Libical4 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the `libical` library to its 4.x series. It's the next generation of the `libical` library, on which the upstream focuses the most right now. == Owner == * Name: [[User:mcrha| Milan Crha]] * Email: <mcrha at redhat dot com> == Detailed Description == The `libical` upstream begun to focus the main development on the new 4.x series, which is not API compatible with the 3.x series. These cannot be used by a single executable together, similar to `libsoup2` and `libsoup3`. Unlike `libsoup`, it does not verify in runtime whether the other library is also loaded, thus it it harder to spot the leftovers. Luckily, there are not that many direct dependencies which use either `libical` or `libical-glib`, thus I'd go even without a compact package and just flip the switch. == Feedback == I asked for an opinion [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… on the devel list] with almost no feedback. I built the dependencies [https://copr.fedorainfracloud.org/coprs/mcrha/libical-4.x/builds/ in COPR] checking which dependencies need a custom patch and which can be build with either `libical` 3.x or 4.x. I also proposed patches to some of the projects which needed them. == Benefit to Fedora == Stay on the latest `libical` upstream stable series. == Scope == * Proposal owners: Just adapting the `libical'` spec file, already prepared in the COPR * Other developers: Simply rebuild the package against the new `libical` for those whom are ready, or carry a custom patch to port to the new API changes. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13504 #13504] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == C API/ABI: Applications not rebuilt will fail to run due to the soname change. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N Propose pull request with the needed packaging changes is here: https://src.fedoraproject.org/rpms/libical/pull-request/2 COPR build with the main users rebuilt is here: https://copr.fedorainfracloud.org/coprs/mcrha/libical-4.x/ == How To Test == There should be no user visible changes, depending whether any of the library users provide different features for different versions on the `libical`. == User Experience == It depends on the applications using the library. == Dependencies == The users of the `libical` development packages: $ dnf repoquery --whatrequires "pkgconfig(libical)" \ --whatrequires "pkgconfig(libical-glib)" \ --whatrequires "libical-glib-devel" \ --whatrequires "libical-devel" \ --recursive --disablerepo=* --enablerepo=rawhide --srpm akonadi-calendar akonadi-search calendarsupport eventviews evolution evolution-data-server folks incidenceeditor kcalutils kf6-kcalendarcore kitinerary ktnef libkgapi (excluding `libical` itself and `kf5` packages, which are orphaned at the moment). Packages requiring `libical`: $ dnf repoquery --whatrequires "libical" --recursive --srpm --disablerepo=* --enablerepo=rawhide GoldenCheetah akonadi-calendar akonadi-calendar-tools akonadi-import-wizard akonadi-search akonadiconsole akregator almanah asterisk baresip bijiben blivet-gui blogilo bluedevil blueman bluez bubblemail cairo-dock cairo-dock-plug-ins calendarsupport calindori calligraplan calls chatty cinnamon claws-mail cyrus-imapd digikam digikam-gmic-qt eventviews evolution evolution-data-server evolution-ews evolution-rspam folks g3kb-switch gdm geary glabels gnokii gnome-applets gnome-bluetooth gnome-browser-connector gnome-calendar gnome-contacts gnome-flashback gnome-initial-setup gnome-panel gnome-phone-manager gnome-pomodoro gnome-session gnome-shell gnome-shell-extension-appindicator gnome-shell-extension-background-logo gnome-shell-extension-blur-my-shell gnome-shell-extension-bubblemail gnome-shell-extension-dash-to-dock gnome-shell-extension-dash-to-panel gnome-shell-extension-disconnect-wifi gnome-shell-extension-forge gnome-shell-extension-freon gnome-shell-extension-gamemode gnome-shell-extension-gamerzilla gnome-shell-extension-gsconnect gnome-shell-extension-ibus-font gnome-shell-extension-just-perfection gnome-shell-extension-kimpanel gnome-shell-extension-logo-menu gnome-shell-extension-netspeed gnome-shell-extension-pidgin gnome-shell-extension-pipewire-settings gnome-shell-extension-pop-shell gnome-shell-extension-refresh-wifi gnome-shell-extension-suspend-button gnome-shell-extension-system-monitor-applet gnome-shell-extension-unite gnome-shell-extension-vertical-workspaces gnome-shell-extensions gnome-shell-frippery gnome-todo gparted gpaste grantlee-editor incidenceeditor itinerary kaddressbook kalarm kcalutils kdepim kdepim-addons kdepim-runtime kdepimlibs kf6-kcalendarcore kio-gdrive kitinerary kleopatra kmail kmail-account-wizard kmailtransport kmymoney kongress kontact korganizer ktnef kuser libkgapi libksieve mailcommon mailimporter maui-agenda maui-mauikit-calendar mbox-importer merkuro messagelib mimetreeparser noctalia orage osmo phosh phosh-mobile-settings phrog pidgin-chime pim-data-exporter pim-sieve-editor pimcommon recoll redwax-tool syncevolution vakzination workrave xpra yaru-theme zanshin == Contingency Plan == * Contingency mechanism: ** ABI Breakage: If the mass rebuild is unsuccessful or reveals widespread, unresolvable issues, revert to the 3.x series. * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == Upstream has a migration guide at https://github.com/libical/libical/blob/4.0/docs/MigrationGuide_to_4.md == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F46 Change Proposal Crystal Language (system-wide)
by Aoife Moloney 02 Sep '26

02 Sep '26

Wiki - https://fedoraproject.org/wiki/Changes/CrystalLanguage his is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This proposal introduces official native support for the [[crystal|Crystal programming language]] compiler ({{package|crystal}}), its dependency manager ({{package|shards}}), an automated spec generator ({{package|cr2rpm}}), and standard RPM packaging macros ({{package|crystal-rpm-macros}}) into Fedora Linux. Shard libraries will be packaged following the '''Shard-as-RPM''' model, enabling offline, secure, and reproducible compilation across the distribution. == Owner == * Name: [[User:Renich|Rénich Bon Ćirić]] * Email: renich(a)woralelandia.com == Detailed Description == Crystal ([https://crystal-lang.org] is a statically typed compiled language designed for developer productivity and systems-level execution performance. The Fedora implementation uses the '''Shard-as-RPM''' model: * Each shard library is packaged as an independent RPM package installing source trees to <code>%{_datadir}/crystal/shards/<name>-<version></code> (with compatibility links for default releases). * Parallel coexistence of multiple shard versions is supported without filesystem collisions, enabling applications to build against specific SemVer versions. * Network access during package builds is prohibited; dependencies are provided locally by installed RPMs. * The compiler discovers installed shard libraries offline via <code>CRYSTAL_PATH="lib:%{crystal_shards_dir}:%{_datadir}/crystal/src"</code>. * Spec generation, license mapping (SPDX), and topological mock build ordering are automated via {{package|cr2rpm}}. * Compiler bootstrapping complies with Fedora's [[Packaging:Guidelines#No_pre-compiled_binaries|No Pre-compiled Binaries Policy]] via a standard transient Koji side-tag bootstrap. == Feedback == Community feedback and architectural planning have been discussed on Fedora Discussion at [https://discussion.fedoraproject.org/t/bringing-crystal-to-fedora-linux/182… Bringing Crystal to Fedora Linux]. == Benefit to Fedora == * '''Air-Gapped & High-Security Deployments''': Enables building and deploying Crystal software in isolated or air-gapped environments without external internet access or dynamic Git downloads. * '''Supply Chain Integrity''': Protects against upstream Git repository tampering, branch deletion, and dependency confusion by anchoring all dependencies to cryptographic RPM package checksums. * '''Centralized Security Auditing & Patching''': System administrators and security scanners (OpenSCAP, DNF, RPM) can track, audit, and patch Crystal libraries system-wide without inspecting ad-hoc vendor directories. * '''Hermetic & Reproducible Builds''': Conforms strictly with Fedora release engineering standards, ensuring deterministic builds in Koji and Mock. * '''Modern Systems Language''': Provides a high-performance compiled language with native LLVM optimization, green threads concurrency, and seamless C ABI interoperability. == Scope == * Proposal owners: ** Package and maintain {{package|crystal}}, {{package|shards}}, {{package|crystal-rpm-macros}}, and {{package|cr2rpm}}. ** Execute the initial bootstrap build in Koji using a staging side-tag. ** Publish official Crystal packaging guidelines. ** Maintain core ecosystem packages ({{package|ameba}}, {{package|flaw}}, {{package|kemal}}). * Other developers: No direct impact on existing packages. Developers can begin packaging Crystal applications and shard libraries. * Release engineering: Coordinate initial bootstrap build and provide a staging side-tag if required ([https://forge.fedoraproject.org/releng/tickets/issues/13511 RelEng Ticket #13511]). * Policies and guidelines: Fedora Packaging Guidelines updated with dedicated Crystal section ([https://discussion.fedoraproject.org/t/draft-guidelines-crystal-packaging-g… FPC Draft Discussion #200733]). * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Expands Fedora's ecosystem of modern, memory-efficient compiled systems languages. == Upgrade/compatibility impact == No impact on existing packages or system upgrades. This change introduces new packages and does not modify existing system defaults or libraries. == How To Test == === Hardware / Environment Requirements === Standard x86_64 or aarch64 Fedora Linux system (or Mock chroot). === System Preparation === sudo dnf install crystal shards cr2rpm crystal-rpm-macros === Verification Steps === Generate a spec file from a shard repository: cr2rpm generate --path ./my-shard Analyze dependency tree and build order: cr2rpm deps --path ./my-shard --format mock Build and verify an application binary: crystal build --release -o hello src/hello.cr ./hello Run package tests in an isolated mock chroot: mock -r fedora-rawhide-x86_64 rebuild my-package.src.rpm == User Experience == Fedora users and developers can install the Crystal compiler and shards package manager directly via standard package management: sudo dnf install crystal shards Crystal binaries compile with full Fedora hardening flags (PIE, Full RELRO, Stack Protection) and integrate with GDB and LLDB out of the box. == Dependencies == * Compiler runtime: {{package|llvm-devel}}, {{package|gc-devel}}, {{package|pcre2-devel}}, {{package|libffi-devel}}. * Standard library: {{package|openssl-devel}}, {{package|zlib-devel}}, {{package|gmp-devel}}, {{package|libyaml-devel}}, {{package|libxml2-devel}}. * Opt-in/legacy event loop: {{package|libevent-devel}}. == Contingency Plan == * Contingency mechanism: Retarget for Fedora N+1. Crystal packages remain available via Copr and staging repos. * Contingency deadline: Beta freeze. * Blocks release? No. == Documentation == * Implementation Plan: [https://codeberg.org/renich/crystal-in-fedora/src/branch/master/plan.rst plan.rst] * Packaging Guidelines: [https://codeberg.org/renich/crystal-in-fedora/src/branch/master/guidelines/… packaging-crystal.rst] * Crystal Official Site: [https://crystal-lang.org/ crystal-lang.org] * Upstream Language Repository: [https://github.com/crystal-lang/crystal github.com/crystal-lang/crystal] * Fedora Tooling & Planning Repository: [https://codeberg.org/renich/crystal-in-fedora codeberg.org/renich/crystal-in-fedora] == Release Notes == Fedora now includes official support for the Crystal programming language, including the compiler ({{package|crystal}}), dependency manager ({{package|shards}}), and full RPM packaging macros ({{package|crystal-rpm-macros}}). Developers can build native, high-performance Crystal applications and package shards offline using standard Fedora tooling. Proposal owners: Package and -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce September 2026