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/
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
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.
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
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
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.
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>