devel-announce January 2026

devel-announce@lists.fedoraproject.org

6 participants
36 discussions

Fedora Linux 44 Mass Rebuild Completed
by Samyak Jain 20 Jan '26

20 Jan '26

Hi all, Per the Fedora Linux 44 schedule [1], we started a mass rebuild for Fedora Linux 44 on 2026-01-16, after addressing initial blockers related to toolchain and dependency changes (including gcc, boost, and related updates). The Fedora Linux 44 mass rebuild has now concluded today. The mass rebuild was run for the changes listed at: https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild#Driving_Features The rebuild was carried out in a side tag (f44-rebuild) and has been merged into f44. Failures from the mass rebuild can be seen at: https://kojipkgs.fedoraproject.org/mass-rebuild/f44-failures.html Packages still needing rebuilding: https://kojipkgs.fedoraproject.org/mass-rebuild/f44-need-rebuild.html A total of 1,566 packages were identified as needing rebuilds as part of this effort. At the end of the mass rebuild, 1,242 builds have failed and will need to be addressed by package maintainers. In total, 22,016 builds have been successfully tagged into f44. We also untagged the following builds from f44, as they would otherwise break Rawhide Compose: - authselect-1.7.0-3.fc44 - shadow-utils-4.19.0-4.fc44 - firefox-147.0-2.fc44 - net-snmp-5.9.5.2-3.fc44 FTBFS bugs will be filed shortly for the remaining failures. Discussions related to the Fedora Linux 44 mass rebuild took place in the releng issue tracker: https://forge.fedoraproject.org/releng/tickets/issues/13150 Please be sure to let Release Engineering know if you notice any issues with the reporting. You can reach us in #releng:fedoraproject.org on Matrix, by emailing our list [2], or by filing an issue in Forge [3]. Regards, Samyak Jain Fedora Release Engineering [1] https://fedorapeople.org/groups/schedule/f-44/f-44-releng-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://forge.fedoraproject.org/releng/tickets/issues/

1 0

Migration of infrastructure tickets to forge.fedoraproject.org
by Kevin Fenzi 16 Jan '26

16 Jan '26

Greetings. I plan to migrate https://pagure.io/fedora-infrastructure/ over to https://forge.fedoraproject.org/infra/tickets/ next tuesday ( 2026-01-20 ) starting at 21UTC. All existing open tickets on the pagure.io side will get a comment noting that the ticket was moved over, the README will be updated to note the new tracker and how to handle private issues (email admin(a)fedoraproject.org) Folks that often interact with infrastructure may want to login to https://forge.fedoraproject.org and set their preferences, including enabling email if you wish to get email notifications. ( The default is off currently, but being discussed to change in: https://forge.fedoraproject.org/forge/forge/issues/324 ) Thanks for your patience. kevin

1 0

F45 Change Proposal: BuildAtomicDesktopsWithImageBuilder [SystemWide]
by Allison King 16 Jan '26

16 Jan '26

Wiki: https://fedoraproject.org/wiki/Changes/BuildAtomicDesktopsWithImageBuilder Discussion Thread: https://discussion.fedoraproject.org/t/179631 **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 == We will switch the builds of the Fedora Atomic Desktop ISOs over from `lorax` to `image-builder`. Additionally, we will introduce extra artifacts (`qcow2`, raw image) for those variants where an out-of-the-box setup is available. == Owner == * Name: [[User:supakeen| Simon de Vlieger]], [[User:Siosm|Timothée Ravier]] * Email: cmdr(a)supakeen.com, siosm(a)fedoraproject.org == Detailed Description == Currently the Fedora Atomic Desktops (Silverblue, Kinoite, Sway Atomic, Cosmic Atomic, Budgie Atomic) are built using `lorax`. We've slowly been reducing our usage of `lorax` over time; migrating mostly to `kiwi` for live media and disk images, and `image-builder` for artifacts that require `ostree` or `bootc`-based content. The Fedora Atomic Installers are `boot.iso`'s with an embedded `ostree`-commit. These are nearly identical to Fedora IoT installer ISOs which are already produced with `image-builder`. For this change proposal we will switch over the pungi configuration for the above listed variants to build their ISOs with `image-builder`, reducing `lorax` usage more. Additionally, since `image-builder` can produce multiple other types of artifacts out of `ostree`-commits we will introduce a `qcow2` image for Fedora Silverblue and Fedora Kinoite and a `raw` image for those variants (but only for `aarch64`) to be used with `arm-image-installer` for users of single board computers (such as the Raspberry Pi). We would love to also enable `qcow2` and `raw` images for the other Fedora Atomic Desktop variants but we are blocked on Anaconda's `initial-setup` not working ([https://github.com/rhinstaller/initial-setup/pull/156 upstream issue]). If this gets resolved before Beta Freeze we could potentially also enable the additional artifacts for those. == Feedback == None yet. == Benefit to Fedora == With this change and thhttps://www.youtube.com/shorts/l4E_5Fp1v14e additional (unrelated, but in the same area) change to [ https://fedoraproject.org/wiki/Changes/ModernizeBootISO Modernize the boot.iso] we will reduce our usage of `lorax` and simplify our deliverable process to be done by two tools, instead of the current three. It will also enable (in the future) to migrate the Fedora Atomic Desktops to be `bootc`-based either in Koji, or potentially in Konflux depending on the timing. The availability of `qcow2` images will make 'testdriving' Fedora Atomic Desktops easier as users can immediately spin up a virtual machine with them. In the same fashion, the availability of `raw` images will make it more feasible for users to run Fedora Atomic Desktops on their `aarch64` single board computers. == Scope == * Proposal owners: ** Implement the embedding of flatpaks in `image-builder`. ** Implement the Fedora Atomic Desktop installers and disk images. * Other developers: ** Review fedora-pungi pull-requests. * Release engineering: [ https://forge.fedoraproject.org/releng/tickets/issues/13170 #13170] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: ** Easier local builds and more artifacts for Fedora Atomic Variants make them more easily available. ** Alignment with the RHEL and CentOS build processes (which use `image-builder`). ** Alignment with `bootc`-deliverable conversion (which uses `image-builder`) easies future migrations. == Upgrade/compatibility impact == None. == Early Testing (Optional) == No. == How To Test == Once the relevant pungi changes have been made Fedora Rawhide composes will contain new ISOs. These can be used in the same fashion as current ones; so testing would consist of ensuring that they behave functionally the same after that point. The new artifacts will also be part of composes after the same point; users could download and try them out :) == User Experience == User experience for Fedora Atomic Desktops will not change. A new user experience will be available (`qcow2`, `raw`). == Dependencies == There are no dependencies. The work for this change proposal *does* touch the same areas as the [ https://fedoraproject.org/wiki/Changes/ModernizeBootISO modernization work for the boot.iso] and might simplify the implementation of that change proposal but is not a prerequisite. == Contingency Plan == * Contingency mechanism: Revert pungi configuration changes. * Contingency deadline: Beta freeze. * Blocks release? No. == Documentation == We will be documenting local builds of Fedora Atomic Desktops in the Fedora Atomic Desktops documentation as part of this change; though likely *after* the contingency point. == Release Notes == N/A

1 0

Fedora Mass Rebuild 44 has started
by Samyak Jain 16 Jan '26

16 Jan '26

Hi all, Per the Fedora Linux 44 schedule [1], we have started a mass rebuild on 2026-01-16 (two days later, due to blockers from failed changes in the boost update, etc.) for Fedora 44. We are running this mass rebuild for the changes listed in: https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild#Driving_Features The discussions for the mass rebuild are happening at the releng issue tracker: https://forge.fedoraproject.org/releng/tickets/issues/13150 This mass rebuild will be done in a side tag (f44-rebuild) and merged When completed, while looking at not merging all changes at once. Failures can be seen <https://kojipkgs.fedoraproject.org/mass-rebuild/f44-failures.html> Things still need rebuilding <https://kojipkgs.fedoraproject.org/mass-rebuild/f44-need-rebuild.html> FTBFS (Fails To Build From Source) bugs will be filed shortly after the mass rebuild is complete. Please let releng know if you see any bugs in the reporting. You can contact releng in the #releng:fedoraproject.org room on Matrix, or by dropping an email to our list [2] or filing an issue in pagure [3]. Regards, Samyak Jain Fedora Release Engineering [1]https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://forge.fedoraproject.org/releng/tickets/issues/13150

1 0

F44 Change Proposal: Build_FCOS_on_Fedora_Konflux [SelfContained]
by Allison King 14 Jan '26

14 Jan '26

Wiki: https://fedoraproject.org/wiki/Changes/Build_FCOS_on_Fedora_Konflux Discussion Thread: https://discussion.fedoraproject.org/t/179534 **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 == We want to build Fedora CoreOS updates payloads and boot disk images in Konflux, instead of Jenkins. == Owner == * Name: [[User:jcapitao | Joel Capitao]] * Email: jcapitao(a)redhat.com * Name: [[User:jbtrystram | JB Trystram ]] * Email: jbtrystram(a)redhat.com == Detailed Description == In F43 we switched Fedora CoreOS to be built with [ https://fedoraproject.org/wiki/Changes/BuildFCOSUsingContainerfile podman via a Containerfile]. We can now leverage this to move our builds into the Fedora Konflux cluster. We also want to leverage bootc-image-builder to build our disk images in Konflux. == Feedback == None right now. == Benefit to Fedora == The main benefit is the distribution of the SBOMs and attestations of the built artifacts to the end user. One will have the ability to verify how the OS was generated from the source code to the distribution. Another nice side effect is that Konflux keeps the intermediate builds artifacts in a public namespace, which makes reproducing tests failures and debugging easier for the Fedora CoreOS maintainers. Furthermore, this reduce the load on the Fedora CoreOS Jenkins pipeline, which is currently maintained by the CoreOS team. This will also increase the amount of shared code between CoreOS and bootc, helping with maintenance and exercising the code more. == Scope == * Proposal owners: ** Will switch Fedora CoreOS production streams (stable, testing, next) to be built in Konflux. This change was already done for our rawhide builds as an experiment. Proposal owner will also replace their current custom osbuild pipeline with bootc-image-builder. Theses changes are purely contained in the pipeline, they do not change the content of the produced artefacts compared to now. Notably, the Konflux release pipeline must integrate with the fedora message bus to get the artifact signed before release. * Release engineering: ** Enable selected projects to sign artifacts from Konflux pipelines using Fedora signing keys. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: ** Migration to Konflux is part of the Fedora Stategy. == Upgrade/compatibility impact == There should be no impact for users as the product of the new pipeline (container images, disk images) should be identical. == Early Testing (Optional) == N/A == How To Test == The testing artifacts builds with Konflux are currently published in https://quay.io/organization/coreos-devel. One can rebase a Fedora CoreOS system to it with: <pre> rpm-ostree rebase ostree-image-signed:docker:// quay.io/coreos-devel/fedora-coreos:stable --reboot </pre> And observe no functional difference. Note that the automatic updates won't work because the image is not from the official release repo. == User Experience == No visible change for users. == Dependencies == == Contingency Plan == * Contingency mechanism: The Jenkins pipeline will stay in place as we will rollout this progressively across Fedora CoreOS streams. We can revert to use the historical Jenkins pipeline at any time. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == See: https://github.com/coreos/fedora-coreos-tracker/issues/2031 == Release Notes == \nFedora CoreOS images are now built into the Fedora Konflux Cluster.

1 0

F44 Spins / Labs and Keepalive Deadline has now passed
by Allison King 14 Jan '26

14 Jan '26

Hi Folks, FESco previously approved a requirement[1] that Spin/Labs owners send a keepalive request in order to keep building the spin or lab. I opened Pagure issues[2] for all Spins and Labs for this release[3]. Thanks to your help, all spins and labs have been acknowledged! Thanks!! For a full list of key dates in this release cycle, please refer to our schedule[5]. Kind regards, Allison [1] https://pagure.io/fesco/issue/1972 [2] https://pagure.io/fedora-pgm/schedule/issues?status=Open&tags=spins+keepali… [3] https://docs.fedoraproject.org/en-US/releases/f40/spins/ [4] https://fedorapeople.org/groups/schedule/f-44/f-44-pm-tasks.html

1 0

Fedora 44 Mass Rebuild Notification - Scheduled for 2026-01-14
by Patrik Polakovic 14 Jan '26

14 Jan '26

Hello all, Per the Fedora Linux 44 release schedule [1]*, we will start a mass rebuild for Fedora 44 on 2026-01-14. We have a tracker ticket [2] open on the Release Engineering issue tracker. In case of any questions and/or requests feel free to leave a comment on the ticket. This mass rebuild will be done in a side tag (`f44-rebuild`) and merged when completed. FTBFS (Fails To Build From Source) bugs will be filed shortly after the mass rebuild. If you need to exclude any packages from the rebuild, you can use `PKG_SKIP_LIST` or add a `noautobuild` file to the root of your dist-git repository. This will instruct the mass rebuild script to skip these packages. If you encounter any bugs or issues in the reports, please let Release Engineering know. You can contact us through the Release Engineering Matrix room [3], by sending an email to our mailing list [4], or by opening a ticket on our issue tracker [5]. Regards, Patrik Polakovic Fedora Release Engineering [1] https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html * Please note that at the time of writing the schedule incorrectly says that the mass rebuild will happen on January 7th. Due to lack of admin access to the schedule we were not able to update this before sending out this notification email. The mass rebuild will happen on January 14th. [2] https://forge.fedoraproject.org/releng/tickets/issues/13150 [3] https://matrix.to/#/#releng:fedoraproject.org [4] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [5] https://forge.fedoraproject.org/releng/tickets/issues

2 1

F44 Change Proposal: konflux-atomic-change-proposal [SelfContained]
by Allison King 14 Jan '26

14 Jan '26

Wiki: https://fedoraproject.org/wiki/Changes/konflux-atomic-change-proposal Discussion Thread: https://discussion.fedoraproject.org/t/179522 **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 == Make Konflux the draft pipeline tool for building base images using the bootc toolchain. Note that this is to start a discussion with the goal of making sure no one is blindsided by our eventual goal of production for F45 :) == Owner == * Name: [[User:nimbinatus| Laura Santmaria (nimbinatus)]] || [[Initiatives/Fedora_bootc]] with members from CoreOS and Atomic SIGs and the Konflux (informal) SIG * Email: lasantam(a)redhat.com == Detailed Description == The Fedora Image Mode/Atomic initiative will formalize use of KonfluxCI for building base images with the bootc toolchain. This change proposal is to set up a parallel toolchain for delivering base images, as per the initiative's goal of being staging-ready for F44, with the intent that it can deliver beta base images to then improve for production readiness in F45. Currently, there is a test pipeline running for various components of CoreOS. This change proposal is to allow the member groups in the initiative to take that pipeline, standardize it, and document it, as well as to educate interested members on how to maintain that pipeline without affecting current production systems. Note that, for this release cycle, this tool will **not** affect the current build pipelines for other editions of Fedora. It only is and will be used for CoreOS, Atomic Desktops, and anyone else interested in bootc-based OCI artifacts. It is **not** affecting RPMs or the packaging build systems and is only for composed images. References: * [[Changes/BuildFCOSUsingContainerfile]] (accepted, F43) * [[Changes/KonfluxFedoraBootc]] (draft from F42) * [[Changes/Build_FCOS_on_Fedora_Konflux]] (proposed, F44) == Feedback == * **Not enough maintainers to have this toolchain:** Currently, the toolchain is in draft use with CoreOS. Many of the issues are being worked on actively by the CoreOS maintainer team. In addition, new contributors have expressed active interest in learning to use and maintain Konflux to start contributing to Fedora. * **Value prop for moving to this toolchain over Koji is missing:** We believe that this is an ideal way to explore what that value prop is without disturbing the rest of the Fedora ecosystem. By ensuring that we try Konflux in a small slice of the ecosystem, we can try this new software factory CI system to understand whether it is worth continuing to pursue. == Benefit to Fedora == This change will allow for trying Konflux across a larger part of the project and will bring in new contributors interested in building a repeatable process for building and maintaining Konflux pipelines. In addition, the change will help make builds for bootc-based OCI artifacts more sustainable through growing the teams building the artifacts and making the builds repeatable and testable. == Scope == * **Proposal owners:** Work with the CoreOS team to understand what they've already built and what are patches to make the system work. Identify what can be repeated versus what needs additional templating. Write up docs. Publish first base images as dev/staging to test out. * **Other developers:** N/A * **Release engineering:** N/A * **Policies and guidelines:** N/A (not needed for this Change) * **Trademark approval:** N/A (not needed for this Change) * **Alignment with the Fedora Strategy:** Yes, this change will drive to immutable variants being editions for Fedora and on driving innovation and leadership in technology (to try something different!). == Upgrade/compatibility impact == As this is a parallel build system that does not change the end user experience, it should not affect the end user. == Early Testing (Optional) == * **Do you require 'QA Blueprint' support?:** Not at this time == How To Test == As this is intended to be a test of moving to Konflux, there is not specific testing guidance. However, we hope that the base images produced are identical to the ones currently produced. == User Experience == Users should not notice a change. == Dependencies == N/A (not a System Wide Change) In addition, this is focused on a sandbox activity. == Contingency Plan == * **Contingency mechanism:** 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) == Documentation == The group will be writing up documentation on how to use Konflux for this purpose. The process of writing this has already started (one of the members of the initiative is also working in the docs initative). == Release Notes == \n

1 0

F44 Change Proposal: Bump_Minimum_Rust_Bindgen_To_v0.72 [SelfContained]
by Allison King 13 Jan '26

13 Jan '26

Wiki: https://fedoraproject.org/wiki/Changes/Bump_Minimum_Rust_Bindgen_To_v0.72 Discussion Thread: https://discussion.fedoraproject.org/t/179475 **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 == Fedora currently includes packages for v0.68, v0.69, v0.71, and v0.72 of the Rust "bindgen" crate. All dependent packages will be updated to use bindgen v0.72 (or newer) to address breaking changes in LLVM 22 that are only fixed in bindgen v0.72.1 and newer. == Owner == * Name: [[User:Decathorpe| Fabio Valentini]] * Email: decathorpe AT gmail DOT com * Name: Rust SIG * Email: rust AT lists DOT fedoraproject DOT org == Detailed Description == LLVM 22 brings (potentially breaking) [ https://github.com/llvm/llvm-project/pull/147835 changes] to how clang represents parsed AST. This required [ https://github.com/rust-lang/rust-bindgen/pull/3278 changes] in the bindgen crate, which have only been released in [ https://github.com/rust-lang/rust-bindgen/releases/tag/v0.72.1 v0.72.1] and newer. Older versions of the bindgen crate will potentially generate broken code with libclang 22, so all dependent packages in Fedora will be updated to use bindgen v0.72.1 or newer, and packages for old versions of bindgen will be retired from Fedora when they are no longer needed. This process has been ongoing for the past few months, but there are a few remaining packages that need to be handled: * rust-tss-esapi-sys (bindgen v0.68 -> v0.72) * clamav (bindgen v0.69 -> v0.72) * retis (bindgen v0.69 -> v0.72) * rust-krun-sys (bindgen v0.69 -> v0.72) * rust-libbpf-sys (bindgen v0.69 -> v0.72) * rust-libmonado (bindgen v0.69 -> v0.72) * rust-libspa-sys0.8 (bindgen v0.69 -> v0.72) * rust-pipewire-sys0.8 (bindgen v0.69 -> v0.72) * rust-scx_utils (bindgen v0.69 -> v0.72) * rust-tree-sitter0.23 (bindgen v0.69 -> v0.72) * rust-tree-sitter0.24 (bindgen v0.69 -> v0.72) * kryoptic (bindgen v0.71 -> v0.72) * rust-tree-sitter (bindgen v0.71 -> v0.72) Updating and / or patching packages that include "bindgen" in vendored Rust dependencies is explicitly out of scope of this Change. == Feedback == N/Y == Benefit to Fedora == Fedora packages are only built with versions of the "bindgen" crate that officially support LLVM 22 (not accounting for packages that build with vendored Rust dependencies). == Scope == * Proposal owners: ** Submit packaging changes (and upstream pull requests) for updating the "bindgen" dependency, where necessary. ** Submit pull requests for packages not under the Rust SIG umbrella (clamav, retis, kryoptic). * Other developers: ** Merge + build pull requests and / or rely on provenpackagers to merge + build pull requests for packages not under the Rust SIG umbrella. * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == There should be no upgrade / compatibility impact, other than improved support for building Rust packages when using LLVM 22 - the default version of LLVM in Fedora 44. == Early Testing (Optional) == N/A Do you require 'QA Blueprint' support? N == How To Test == * Check that all packages that depend on "crate(bindgen)" are built with bindgen v0.72.1 or newer. * Verify that packages for older versions of the "bindgen" crate were retired from Fedora 44+. == User Experience == No change in user experience (not a user-facing change). == Dependencies == Three dependent packages are not co-maintained by the Rust SIG (clamav, retis, kryoptic). Maintainers of these packages (or provenpackagers) will need to merge pull requests and / or implement necessary changes themselves. == Contingency Plan == If packages cannot be ported to bindgen v0.72 in time for the final freeze, retirement of older bindgen versions can be postponed to later versions of Fedora, as necessary. Not all packages will be affected by the changes in LLVM 22. * Contingency mechanism: Postpone retirement of old bindgen versions to a later Fedora release. * Contingency deadline: Final freeze. * Blocks release? No / N/A (not a System Wide Change) == Documentation == * https://github.com/rust-lang/rust-bindgen/releases/tag/v0.72.1 * https://github.com/rust-lang/rust-bindgen/issues/3264 * https://github.com/rust-lang/rust-bindgen/pull/3278 * https://github.com/llvm/llvm-project/pull/147835 == Release Notes == \nThe minimum version of the "bindgen" crate in Fedora has been raised to v0.72.1 to address compatibility issues with LLVM 22.

1 0

F44 Change Proposal: FilterFedoraFlatpaksAtomicDesktopsv2 [SelfContained]
by Allison King 13 Jan '26

13 Jan '26

Wiki: https://fedoraproject.org/wiki/Changes/FilterFedoraFlatpaksAtomicDesktopsv2 Discussion Thread: https://discussion.fedoraproject.org/t/179470 **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 == Allow image based Fedora Desktop outputs (and only those), to self-determine if they want to make use of filters on the Fedora flatpak repository for pre-installed Fedora Flatpaks and enable FlatHub by default. If output maintainers choose to enable Flathub by default, they must use flatpak filters to ensure the the Fedora Flatpak remote is used for all pre-installed user applications (the ones pre-installed from the ISO and the runtimes). == Owner == * Name: Jef Spaleta * Email: jspaleta(a)redhat.com == Detailed Description == With this change, we want to make use of Flathub flatpaks an explicit decision for each image based desktop output (ie. each Atomic desktop). Fedora contributors may package any application as Fedora Flatpak, but those Flatpaks will not be made available immediately to user of the desktops that have Flathub enabled by default, unless they are preinstalled applications. Users that want to have access to all Flatpaks from Fedora can remove the filter or add an additional remote definition that the filter doesn't apply to. === Why not use just use Flathub Flatpaks instead? === Moving the image based Fedora Desktops to using Flathub Flatpaks would potentially require legal work and infrastructure changes. Completely removing the Fedora Flatpak remote from the Atomic Desktops would mean that the default installation would appear very bare bone in terms of available applications. This change is thus trying to reach a middle ground between those two options, keeping Fedora Flatpaks where they are necessary and using Flathub flatpaks to meet growing median user expectation and desire for upstream binary packages for the graphical desktop applications. === Which Flatpaks will be added to the filter? === The list of Fedora Flatpak enabled for the Fedora Atomic Desktops will be maintained by the Fedora Atomic Desktop SIG, with input from the desktops working groups (Workstation Working Group, KDE SIG, etc.) and the Flatpak SIG. We will populate the filter with the list of pre-installed Flatpaks (and the runtimes) in SilverBlue as a starting point. == Feedback == This is a second attempt at this Change proposal after being rejected in the F43 cycle. After some discussion, I felt there was some confusion with regard to intent and benefits of the first attempt and I wanted to take a second pass at this and try to get clarity on some things. The text in this updated version draws heavily from the first in terms of technical specifics. The most material change in this second attempt is to reframe strategic benefit and to clear up confusion and to clarify that FlatHub does _not_ have to be adopted by all image-based desktop outputs. The maintainers of each image-based desktop output are empowered to make a choice to enable Flathub by default or not. We already have a legal decision that its allowed from a compliance standpoint. This is a change proposal meant to make it technically possible to do so with the least amount of friction and confusion to users. There are tradeoffs inherent in the decision on what the default flatpak remote should be. This is why this updated version of this proposal is explicit that its up to the maintainers of each image based output to make the choice as to whether to turn flathub on by default or not. Ultimately its the decision of users to decide which remote they want to use for which applications based on their own requirements. But the entire point of flatpak as a technology is to give application developers and maintainers the ability to decouple applications from the base operating system. We need to create a space for Fedora outputs that want to explore and innovate on the promise of flatpak as a technology the ability to do exactly that..decouple the base os from the application layer. Making flathub the default for a subset of image based outputs makes that exploration possible.. for the slice of users who have self determined that they want to explore the image layer based approach. But because of uncertainty with regard to compliance issues at present we can't cut over fully and we need to make use of Fedora generated flatpaks for preinstalled applications until there is clarity on the compliance issues for pre-installed software by working _with_ Flathub to figure out how compliance concerns can be satisfied in a reasonable manner. == Benefit to Fedora == * Less confusion for Fedora users who expect to use Flathub applications * Less confusion for upstream developers when responding to bug reports about "their" Flatpak'ed application * Stronger focus on what makes Fedora better: upstream contribution and collaboration with other communities * More focus and testing on the Fedora Flatpaks installed by default on the image based desktops == Scope == * Proposal owners: Add a filter to the Fedora Flatpak remote that imaged based desktops could choose to include as part of compose. * Other developers: image based desktop maintainers would need to choose to use the filter and enable Flathub by default in their image composes. This is a choice. Based on discussion I expect at a minimum SilverBlue would choose to make use of the filter. * Release engineering: Should not require any release engineering coordination. * Policies and guidelines: Should not impact any existing policy. Flathub has already been determined to be allowed to be enabled by default, this Change establishes a mechanism to actually do that. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This aligns with an upstream first approach for graphical application development and more specifically with the intent of flatpak as a federated technology available for use by open source graphical application developers. == Upgrade/compatibility impact == This change is intended to apply to participating image Desktops users on update. Users that are using Fedora Flatpaks may have to update the filter to keep receiving updates or move to Flathub packages instead. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == Remove Fedora Flatpak remote, enable filtered Fedora Flatpak remote, enable Flathub remote. Commands to be added here. The implementation will likely look similar to previous work: * https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications * https://pagure.io/fedora-flathub-filter Once the change is implemented, new installation ISOs for the Atomic Desktops making use of the filter will let users test this more easily. == User Experience == Users of the Fedora image-based desktops that opt-in to enabling FlatHub by default will install applications via flatpak cmdline or from the GNOME Software and Plasma Discover store, and will get FlatHub Flatpaks by default. The set of core applications pre-installed by default on the system will be installed using Fedora Flatpaks and will be defined by the filter implemented as part of this Change proposal. Users of other Fedora outputs will need to enable FlatHub and set up filtering accordingly as a post-install set of user-initiated actions. == Dependencies == == Contingency Plan == * Contingency mechanism: Keep things as is * Contingency deadline: Beta/Final freeze * Blocks release? N/A (not a System Wide Change) == Documentation == We will have to document how to remove the filter or add an additional named flatpak remote definition for users that want to use all Fedora Flatpaks. == Release Notes == -- *Allison King* Senior Technical Project Manager, In-Vehicle OS Red Hat <https://www.redhat.com/> alking(a)redhat.com <https://red.ht/sig>

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce January 2026