This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 09 – 13 March 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Dealing with spam
Resolved issue with user getting error when sending e-mail to admin@fedoraproject.org
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Final freeze is scheduled to start on March 31st and the final release is tentatively scheduled for April 14th.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
F44 rebuild will be slow until we clear the current queue in the build system (side note: until RISC-V enters primary Koji, it is likely to be out of sync with primary arch in terms of image delivery timelines). Engaged on ‘fedora-devel’ (and the Discussion forum) about primary vs. alternative arch requirements. Downstream needs brought the pending Fedora upstream work for LLVM and Java into the foreground. Reviewed the link-time optimization (LTO) situation in Fedora RISC-V: for now we’ll keep it disabled, the LTO gains are rather small, and it gives us much better build times. Evaluated migrating documentation from Wiki to Forge, but it remains a bit of a low-priority for now.
Resolved a “unified kernel” (soon to be “omni kernel”) boot failure on P550
Debugged a small regression in ‘arch-test’ reported on the RISC-V Matrix channel.
Chip away at the RISC-V tracker
Make progress on draining the queue on the tasks tracker
QE
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Fedora 44 Beta was approved last week and is getting released this week. This involved a lot of release validation tests, blocker bugs management, common issues writeup, and more.
Writing a real-time audio plugin on Linux often conjures up images of a complex environment: C++, toolchains, CMake, CLAP / VST3 / LV2 SDK, ABI…
However, there is a much simpler approach : JSFX
This article offers a practical introduction to JSFX and YSFX on Fedora Linux: we’ll write some small examples, add a graphical VU meter, and then see how to use it as an CLAP / VST3 plugin in a native Linux workflow.
JSFX (JesuSonic Effects – created by REAPER [7]) allows you to write audio plugins in just a few lines, without compilation, with instant reloading and live editing.
Long associated with REAPER, they are now natively usable on Linux, thanks to YSFX [3], available on Fedora Linux in CLAP and VST3 formats via the Audinux repository ([4], [5]).
This means it’s possible to write a functional audio effect in ten lines, then immediately load it into Carla [8], Ardour [9], or any other compatible host, all within a PipeWire / JACK [11] environment.
A citation from [1] (check the [1] link for images):
In 2004, before we started developing REAPER, we created software designed for creating and modifying FX live, primarily for use with guitar processing.
The plan was that it could run on a minimal Linux distribution on dedicated hardware, for stage use. We built a couple of prototypes.
These hand-built prototypes used mini-ITX mainboards with either Via or Intel P-M CPUs, cheap consumer USB audio devices, and Atmel AVR microcontrollers via RS-232 for the footboard controls.
The cost for the parts used was around $600 each.
In the end, however, we concluded that we preferred to be in the software business, not the hardware business, and our research into adding multi-track capabilities in JSFX led us to develop REAPER. Since then, REAPER has integrated much of JSFX’s functionality, and improved on it.
So, as you can see, this technology is not that new. But the Linux support via YSFX [3] is rather new (Nov 2021, started by Jean-Pierre Cimalando).
A new programming language, but for what ? What would one would use JSFX for ?
This language is dedicated to audio and with it, you can write audio effects like an amplifier, a chorus, a delay, a compressor, or you can write synthesizers.
JSFX is good for rapid prototyping and, once everything is in place, you can then rewrite your project into a more efficient language like C, C++, or Rust.
JSFX for developers
Developing an audio plugin on Linux often involves a substantial technical environment. This complexity can be a hindrance when trying out an idea quickly.
JSFX (JesuSonic Effects) offers a different approach: writing audio effects in just a few lines of interpreted code, without compilation and with instant reloading.
Thanks to YSFX, available on Fedora Linux in CLAP and VST3 formats, these scripts can be used as true plugins within the Linux audio ecosystem.
This article will explore how to write a minimal amplifier in JSFX, add a graphical VU meter, and then load it into Carla as a CLAP / VST3 plugin.
The goal is simple: to demonstrate that it is possible to prototype real-time audio processing on Fedora Linux in just a few minutes.
No compilation environment is required: a text editor is all you need.
YSFX plugin
On Fedora Linux, YSFX comes in 3 flavours :
a standalone executable ;
a VST3 plugin ;
a CLAP plugin.
YSFX is available in the Audinux [5] repository. So, first, install the Audinux repository:
Here is a screenshot of YSFX as a VST3 plugin loaded in Carla Rack [8]:
You can :
Load a file ;
Load a recent file ;
Reload a file modified via the Edit menu ;
Zoom / Unzoom via the 1.0 button ;
Load presets ;
Switch between the Graphics and Sliders view.
Here is a screenshot of the Edit window:
The Variables column displays all the variables defined by the loaded file.
Examples
We will use the JSFX documentation available at [4].
JSFX code is always divided into section.
@init : The code in the @init section gets executed on effect load, on samplerate changes, and on start of playback.
@slider : The code in the @slider section gets executed following an @init, or when a parameter (slider) changes
@block : The code in the @block section is executed before processing each sample block. Typically a block is the length as defined by the audio hardware, or anywhere from 128-2048 samples.
@sample : The code in the @sample section is executed for every PCM (Pulse Code Modulation) audio sample.
@serialize : The code in the @serialize section is executed when the plug-in needs to load or save some extended state.
@gfx [width] [height] : The @gfx section gets executed around 30 times a second when the plug-ins GUI is open.
A simple amplifier
In this example, we will use a slider value to amplify the audio input.
desc:Simple Amplifier
slider1:1<0,4,0.01>Gain
@init
gain = slider1;
@slider
gain = slider1;
@sample
spl0 *= gain;
spl1 *= gain;
slider1, @init, @slider, @sample, spl0, spl1 are JSFX keywords [1].
Description:
slider1: create a user control (from 0 to 4 here);
@init: section executed during loading;
@slider: section executed when we move the slide;
@sample: section executed for each audio sample;
spl0 and spl1: left and right channels.
In this example, we just multiply the input signal by a gain.
Here is a view of the result :
An amplifier with a gain in dB
This example will create a slider that will produce a gain in dB.
desc:Simple Amplifier (dB)
slider1:0<-60,24,0.1>Gain (dB)
@init
gain = 10^(slider1/20);
@slider
gain = 10^(slider1/20);
@sample
spl0 *= gain;
spl1 *= gain;
Only the way we compute the gain changes.
Here is a view of the result :
An amplifier with an anti-clipping protection
This example adds protection against clipping and uses a JSFX function for that.
desc:Simple Amplifier with Soft Clip
slider1:0<-60,24,0.1>Gain (dB)
@init
gain = 10^(slider1/20);
@slider
gain = 10^(slider1/20);
function softclip(x) (
x / (1 + abs(x));
);
@sample
spl0 = softclip(spl0 * gain);
spl1 = softclip(spl1 * gain);
Here is a view of the result :
An amplifier with a VU meter
This example is the same as the one above, we just add a printed value of the gain.
desc:Simple Amplifier with VU Meter
slider1:0<-60,24,0.1>Gain (dB)
@init
rms = 0;
coeff = 0.999; // RMS smoothing
gain = 10^(slider1/20);
@slider
gain = 10^(slider1/20);
@sample
// Apply the gain
spl0 *= gain;
spl1 *= gain;
// Compute RMS (mean value of the 2 channels)
mono = 0.5*(spl0 + spl1);
rms = sqrt((coeff * rms * rms) + ((1 - coeff) * mono * mono));
@gfx 300 200 // UI part
gfx_r = 0.1; gfx_g = 0.1; gfx_b = 0.1;
gfx_rect(0, 0, gfx_w, gfx_h);
// Convert to dB
rms_db = 20*log(rms)/log(10);
rms_db < -60 ? rms_db = -60;
// Normalisation for the display
meter = (rms_db + 60) / 60;
meter > 1 ? meter = 1;
// Green color
gfx_r = 0;
gfx_g = 1;
gfx_b = 0;
// Horizontal bar
gfx_rect(10, gfx_h/2 - 10, meter*(gfx_w-20), 20);
// Text
gfx_r = gfx_g = gfx_b = 1;
gfx_x = 10;
gfx_y = gfx_h/2 + 20;
gfx_printf("Level: %.1f dB", rms_db);
The global structure of the code:
Apply the gain
Compute a smoothed RMS value
Convert to dB
Display a horizontal bar
Display a numerical value
Here is a view of the result :
An amplifier using the UI lib from jsfx-ui-lib
In this example, we will use a JSFX UI library to produce a better representation of the amplifier’s elements.
Import and setup: The UI library is imported and then allocated memory (ui_setup) using @init;
UI controls: control_dial creates a thematic potentiometer with a label, integrated into the library;
Integrated VU meter: A small graph is drawn with ui_graph, normalizing the RMS value between 0 and 1;
UI structure: ui_start(“main”) prepares the interface for each frame. ui_push_height / ui_pop organize the vertical space.
Here is a view of the result :
A simple synthesizer
Now, produce some sound and use MIDI for that.
The core of this example will be the ADSR envelope generator ([10]).
desc:Simple MIDI Synth (Mono Sine)
// Parameters
slider1:0.01<0.001,2,0.001>Attack (s)
slider2:0.2<0.001,2,0.001>Decay (s)
slider3:0.8<0,1,0.01>Sustain
slider4:0.5<0.001,3,0.001>Release (s)
slider5:0.5<0,1,0.01>Volume
@init
phase = 0;
note_on = 0;
env = 0;
state = 0; // 0=idle,1=attack,2=decay,3=sustain,4=release
@slider
// Compute the increment / decrement for each states
attack_inc = 1/(slider1*srate);
decay_dec = (1-slider3)/(slider2*srate);
release_dec = slider3/(slider4*srate);
@block
while (
midirecv(offset, msg1, msg23) ? (
status = msg1 & 240;
note = msg23 & 127;
vel = (msg23/256)|0;
// Note On
status == 144 && vel > 0 ? (
freq = 440 * 2^((note-69)/12);
phase_inc = 2*$pi*freq/srate;
note_on = 1;
state = 1;
);
// Note Off
(status == 128) || (status == 144 && vel == 0) ? (
state = 4;
);
);
);
@sample
// ADSR Envelope [10]
state == 1 ? ( // Attack
env += attack_inc;
env >= 1 ? (
env = 1;
state = 2;
);
);
state == 2 ? ( // Decay
env -= decay_dec;
env <= slider3 ? (
env = slider3;
state = 3;
);
);
state == 3 ? ( // Sustain
env = slider3;
);
state == 4 ? ( // Release
env -= release_dec;
env <= 0 ? (
env = 0;
state = 0;
);
);
// Sine oscillator
sample = sin(phase) * env * slider5;
phase += phase_inc;
phase > 2*$pi ? phase -= 2*$pi;
// Stereo output
spl0 = sample;
spl1 = sample;
Global structure of the example:
Receives MIDI via @block;
Converts MIDI note to frequency (A440 standard);
Generates a sine wave;
Applies an ADSR envelope;
Outputs in stereo.
Here is a view of the result :
Comparison with CLAP / VST3
JSFX + YSFX
Advantages of JSFX:
No compilation required;
Instant reloading;
Fast learning curve;
Ideal for DSP prototyping;
Portable between systems via YSFX.
Limitations:
Less performant than native C++ for heavy processing;
Less suitable for “industrial” distribution;
Simpler API, therefore less low-level control.
CLAP / VST3 in C/C++
Advantages:
Maximum performance;
Fine-grained control over the architecture;
Deep integration with the Linux audio ecosystem;
Standardized distribution.
Limitations:
Requires a complete toolchain;
ABI management/compilation;
Longer development cycle.
Conclusion
A functional audio effect can be written in just a few lines, adding a simple graphical interface, and then loaded this script as an CLAP / VST3 plugin on Fedora Linux. This requires no compilation, no complex SDK, no cumbersome toolchain.
JSFX scripts don’t replace native C++ development when it comes to producing optimized, widely distributable plugins. However, they offer an exceptional environment for experimentation, learning signal processing, and rapid prototyping.
Thanks to YSFX, JSFX scripts now integrate seamlessly into the Linux audio ecosystem, alongside Carla, Ardour, and a PipeWire-based audio system.
For developers and curious musicians alike, JSFX provides a simple and immediate entry point into creating real-time audio effects on Fedora Linux.
Available plugins
ysfx-chokehold
A free collection of JS (JesuSonic) plugins for Reaper.
Imagine that Fedora Workstation is your desk, and GNOME Shell extensions are small accessories you add to make it feel more personal. It’s like placing a pencil case on the right side, a lamp that helps you focus, or a small cabinet to keep your things from getting scattered. It’s the same desk—GNOME stays clean and minimal—but a few additions can make your routine more comfortable.
Extensions work on the GNOME interface: the top panel, the way you open applications, how notifications appear, and small details that usually stay hidden. These simple changes can be enough to make your Fedora Workstation feel different. With just one extension, you can make Fedora feel more “you.”
But like any accessories, choose only what truly helps—don’t install everything. Too many extensions can clutter your desktop or make things feel unstable. The goal isn’t to chase excitement, but to find a few small add-ons that better fit the way you work in Fedora Workstation.
Why use Extension Manager?
Once you see extensions as small “accessories” for GNOME, a question comes up fast: how do you install them without the hassle? This is where Extension Manager helps.
Instead of opening many browser tabs, you can do everything in one place. You can browse extensions. You can search for what you need. You can also read a short description before installing. As a result, the whole process feels calmer and more familiar.
More importantly, Extension Manager makes it easier to experiment safely. For example, you can try one extension to make the top panel more useful. If it doesn’t feel right, you can simply turn it off. Or you can uninstall it in seconds. That way, you stay in control.
Also, you’re not “modding” your whole system. You’re only adding small features. And if you change your mind, you can always go back to GNOME’s clean default look.
In short, Extension Manager is like a small drawer on your desk. It keeps your extensions in one spot. So they’re easy to find, easy to try, and easy to tidy up again.
Install Extension Manager
Let’s move to the easiest part: installing Extension Manager with just a few clicks. Open the Software app on Fedora Workstation, then search for Extension Manager using the search bar. Select the app and click Install. That’s it.
Once the installation is complete, open it from the app menu—look for Extension Manager. Now you’re ready to customize. Start slowly: try one extension first, then see if it fits your daily routine.
Find and Install an Extension
After you open Extension Manager, it can feel like opening an “accessories shop” for your Fedora Workstation. There are many options, from small tweaks to extensions that can change how you work.
Start with the search bar. Think about what you most often need in your day-to-day routine. For example, you might want quicker access to apps, tray icons for indicators, or a more informative top panel. When you find an extension that looks interesting, open its page for a moment. Read the short description, look at the screenshots, and then ask yourself whether it will really help your work flow.
If you’re sure, just click Install. In a few seconds, it will be installed, and you’ll notice the change right away. However, if it doesn’t feel right, don’t hesitate to uninstall it. At this stage, you’re simply trying things out—like picking the accessories that best fit your desk.
Enable/disable and adjust settings
After you install a few extensions, you don’t have to stick with all of them. Sometimes an extension is useful, but you don’t need it all the time. That’s the nice thing about Extension Manager: you can enable or disable extensions at any time, without any drama.
Think of it like accessories on your desk. Some days you need a desk lamp to help you focus. On other days, you want your desk to stay clean and simple. Extensions work the same way. You can turn one on when you need it, and turn it off when you’re done.
If an extension has options, you’ll usually see a Settings or Preferences button. From there, you can tweak small details to match your style—icon placement, button behaviour, panel appearance, and more. This is what makes extensions feel personal. You’re not just installing something and forgetting it; you’re shaping it around your workflow.
And if one day your Fedora starts to feel too crowded, don’t panic. Just open the list of installed extensions and disable the ones you don’t need. Take it slow. The best customization isn’t about how many extensions you have, but how well they fit your daily activities.
Keep it safe: a few practical tips
At this point, you might start thinking, “Wow, there are so many things I can change.” And that’s true. However, if you want Fedora Workstation to stay light and comfortable, there are a few simple habits worth keeping in mind.
First, install extensions the same way you choose tools: only when you truly need them. If you stop using an extension after a few days, it’s better to disable it or remove it. A comfortable desktop isn’t the most crowded one—it’s the one with fewer distractions.
Second, try extensions one by one. If you install many at once, it’s hard to tell which one causes a problem. On the other hand, if you take it slowly, you can quickly feel what fits and what doesn’t.
Finally, remember that GNOME keeps evolving. Sometimes after a major update, an extension may not be ready yet. If something feels odd after an update, the safest move is simple: open Extension Manager and disable the extension you suspect. Once things are back to normal, you can wait for an update or choose an alternative.
In the end, Extension Manager isn’t a ticket to customize without limits. It’s more like a clean toolbox. If you use it with care and focus on what you really need, customization can stay enjoyable—without losing the clean, stable feel of Fedora Workstation.
Wrapping up: share your favorite extensions
Now you know how to customize your Fedora Workstation with Extension Manager. You’ve learned how to install the app, try a few extensions, and adjust their settings. And here’s the fun part: everyone ends up with a different mix of extensions, because we all have different needs and work styles.
If you have a favorite extension, share it. Which one do you rely on most, and what do you use it for? Maybe it helps you stay focused during presentations. Or maybe it makes the top panel more informative, brings back tray icons, or simply speeds up your work flow. Tell us why you like it, so others can picture the benefit.
Who knows—your list might inspire someone else. And you might also discover a new extension that fits your daily routine even better.
Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. This article provides the steps to rebase to the newly released Fedora Linux 44 Beta, and how to revert if anything unforeseen happens.
NOTE: Before attempting an upgrade to the Fedora Linux 44 Beta, apply any pending upgrades to your current system.
Updating using the terminal
Because Fedora Linux 44 Beta is not available in GNOME Software, the whole process must be done through a terminal.
First, check if the 44 branch is available, which should be true now:
$ ostree remote refs fedora
You should see the following line in the output:
fedora:fedora/44/x86_64/silverblue
If you want to pin the current deployment (this deployment will stay as an option in GRUB until you remove it), you can do it by running:
# 0 is entry position in rpm-ostree status $ sudo ostree admin pin 0
To remove the pinned deployment use the following command ( “2” corresponds to the entry position in the output from rpm-ostree status ):
$ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora 44 branch.
$ rpm-ostree rebase fedora:fedora/44/x86_64/silverblue
The final thing to do is restart your computer and boot to Fedora Silverblue 44 Beta.
How to revert
If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 44 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu (you need to press ESC during boot sequence to see the GRUB menu in newer versions of Fedora Silverblue), and your system will start in its previous state. To make this change permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase to Fedora Silverblue 44 Beta and fall back. So why not do it today?
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during rebase of Fedora Linux? For example from Fedora Silverblue 42 to Fedora Silverblue 44?
Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (42->43 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I got errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
After doing this you can follow the guide in this article.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?
Yes, you can follow the Updating using the terminal part of this guide for every ostree edition of Fedora. Just use the corresponding branch. For example for Kinoite use fedora:fedora/44/x86_64/kinoite
On Tuesday, 10 March 2026, it is our pleasure to announce the availability of Fedora Linux 44 Beta! As with every beta release, this is your opportunity to contribute by testing out the upcoming Fedora Linux 44 Beta release. Testing the beta release is a vital way you can contribute to the Fedora Project. Your testing is invaluable feedback that helps us refine what the final F44 experience will be for all users.
We hope you enjoy this latest beta version of Fedora!
How to get the Fedora Linux 44 Beta release
You can download Fedora Linux 44 Beta, or our pre-release edition versions, from any of the following places:
The Fedora CoreOS “next” stream rebases to Fedora beta content on the same day as the beta release. To try out Fedora Linux 44-based CoreOS, try out the Fedora CoreOS “next” stream today.
You can also update an existing system to the beta using DNF system-upgrade.
The Fedora Linux 44 Beta release content may also be available for Fedora Spins and Labs.
Fedora Linux 44 Beta highlights
Like every Beta release, the Fedora Linux 44 Beta release is packed with changes. The following are highlights from the full set of changes for F44. They are ready for you to test drive in the Fedora Linux 44 Beta.
Installer and desktop Improvements
Goodbye Anaconda Created Default Network Profiles: This change impacts how Anaconda populates network device profiles. Only those devices configured during installation (by boot options, kickstart or interactively in UI) become part of the final system install. This behavior change addresses some long standing issues caused by populating network profiles for all network devices. These made it difficult to correctly reconfigure devices post-install.
Unified KDE Out of the Box Experience: This change introduces the post-install Plasma Setup application for all Fedora KDE variants. In the variants making use of this new setup application, the Anaconda configuration will be adjusted to disable redundant configuration stages that duplicate the functionality exposed in the setup application.
KDE Plasma Login Manager: This change introduced the Plasma Login Manager (PLM) for Fedora KDE variants instead of SDDM for the default login manager.
Reworked Games Lab: This change modernizes the Games Lab deliverable by leveraging the latest technologies. This offers a high quality gaming and game development experience. It includes a change from Xfce to KDE Plasma to take advantage of the latest and greatest Wayland stack for gaming.
Budgie 10.10: Budgie 10.10 is the latest release of Budgie Desktop. Budgie 10.10 migrates from X11 to Wayland. This ensures a viable long-term user experience for Fedora Budgie users and lays groundwork for the next major Budgie release.
LiveCD Improvements
Automatic DTB selection for aarch64 EFI systems: This change intends to make the aarch64 Fedora Live ISO images work out of the box on Windows on ARM (WoA) laptops. This will automatically select the right DTB at boot.
Modernize Live Media: This change modernizes the live media experience by switching to the “new” live environment setup scripts provided by livesys-scripts and leverage new functionality in dracut to enable support for automatically enabling persistent overlays when flashed to USB sticks.
System Enhancements
GNU Toolchain Update: The updates to the GNU Toolchain ensure Fedora stays current with the latest features, improvements, and bug and security fixes from the upstream gcc, glibc, binutils, and gdb projects. They guarantee a working system compiler, assembler, static and dynamic linker, core language runtimes, and debugger.
Reproducible Package Builds: Over the last few releases, we changed our build infrastructure to make package builds reproducible. This is enough to reach 90%. The remaining issues need to be fixed in individual packages. With this change, all package builds are expected to be reproducible in the F44 final release. Bugs will be filed against packages when an irreproducibility is detected. The goal is to have no fewer than 99% of package builds reproducible.
Packit as a dist-git CI: This change continues down the path of modernizing the Fedora CI experience by moving forward with the final phase of the plan to integrate Packit as the default CI for Fedora dist-git.
Remove Python Mock Usage: python-mock was deprecated with Fedora 34. However, it is still in use in many packages. We plan to go through the remaining usages and clean them up, with the goal of retiring python-mock from Fedora.
Adoption of new R Packaging Guidelines: This change introduces new rpm macros to help standardize and automate common R language packaging tasks resulting in a simplification of the rpm spec files.
Introduction of Nix Developer Tool: This change adds the nix package manager developer tool to Fedora.
Hardlink identical files in packages by default: With this change, all fedora packages will automatically hardlink files under /usr by default as a post install action. The mechanism introduced in this change is designed specifically to address reproducibility validation race conditions found in use by traditional hardlinking approaches.
Fedora Linux 44 Beta upgrades and removals
Golang 1.26: Fedora users will receive the most current and recent Go release. Being close to upstream allows us to avoid security issues and provide more updated features. Consequently, Fedora will provide a reliable development platform for the Go language and projects written in it.
MariaDB 11.8 as Distribution Default Version: The distribution default for MariaDB packaging will switch to 11.8. Multiple versions of the MariaDB packages will continue to be available. This change only impact which of the versioned packages presents itself as the unversioned “default”
IBus 1.5.34: Fedora users will benefit from better support of Wayland and Emoji features.
Django 6.x: Fedora Users can make use of the latest Django version; users who use Django add-ons that are not ready for 6.0 yet should be able to switch it out for python3-django5
TagLib 2: This change puts Fedora on the latest supported version, and it will benefit from improvements in future minor releases with a simple update.
Helm 4: Helm 4 has been released upstream with intentional backwards-incompatible changes relative to Helm 3. To ensure a smooth transition for Fedora, this Change introduces Helm 4 as the default helm package, while providing a parallel-installable helm3 package for users and tooling that still rely on Helm 3.
Ansible 13: Update from Ansible 11 and Ansible Core 2.18 to Ansible 13 and Ansible Core 2.20. This includes major robustness and security fixes to the templating engine which might break existing playbooks that had incorrect behavior. This was silently ignored in previous releases.
TeXLive 2025: With this change, we update to the latest version of TeXLive (2025). We also move to a modularized packaging system, which splits the “texlive” SPEC into a set of collection and scheme packages. This reflects the categorization that TeXLive upstream defines. Each collection package will package the immediate component dependencies as subpackages.
Drop QEMU 32-bit Host Builds: Fedora will stop building QEMU on i686 architecture. This change brings Fedora inline with the QEMU upstream project decision to deprecate support for 32-bit host builds. Upstream intends to start removing 32-bit host build support code in a future release and will assume 64-bit atomic ops in all builds.
Drop FUSE 2 libraries in Atomic Desktops: Remove FUSE 2 binaries and libraries from all Atomic Desktops
Drop compatibility for pkla polkit rules in Atomic Desktops: Remove support for deprecated pkla polkit rules from all Fedora Atomic Desktops
More information about Fedora Linux 44 Beta
Details and more information on the many great changes landing in Fedora Linux 44 are available on the Change Set page.
Editor’s Notes
Previously, it was noted that Fedora CoreOS “next” stream releases a week after the beta. This was a publishing error. The Fedora CoreOS “next” stream releases on the same day as the beta release. The article was edited to clarify this error.
Do you want to join us for our annual contributor conference? We want to see you there! However, we know that traveling to a global event is a big trip. It costs real money. To help out, the Flock Organizing Team offers Flock 2026 financial assistance. We want to make sure money does not stop our active contributors from attending.
This is your final reminder. You must submit your form by Sunday, March 8th, 2026. The organizing team starts looking at the data on Monday morning. Because of this fast timeline, we cannot accept any late forms. Sunday is a hard stop.
What does this funding actually cover? We can help you pay for your travel. This includes your airfare or train tickets. We can also help cover your hotel room at the main event venue. We have a limited budget. Because of this, we cannot fully fund every person who applies. Your peers on the organizing team review all the forms. They look at your community impact to make these tough choices.
Note for Flock 2026 speakers
Are you giving a talk this year? We are excited to hear from you! But please remember one important rule. Being an accepted speaker does not give you guaranteed funding. You still need to ask for help. All speakers must fill out the Flock 2026 financial assistance form if they need travel support.
Fill in your travel details and your estimated costs.
Explain your recent work and your impact in the Fedora community.
Submit the form before the end of the day on Sunday, March 8th.
We want to bring as many builders and contributors together as possible. Please do not wait until the last minute. If you need support to join us, fill out the application today!
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 02 – 06 March 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Migrated remaining pagure.io repositories, there is one remaining, but needs to have private issues implemented
Meeting with the IPA-tuura team to move forward with the Ipsilon replacement project
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Still in Beta Freeze, we have had a couple of release candidate composes for Fedora 44 Beta.
GO/NO-GO call for the Beta Release is tentatively scheduled for Thursday, March 5th.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
Continue to comb through the list of Fedora packages that need work — submit changes to Fedora / upstream, review patches from others, and submit builds as needed.
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Fedora 44 RCs are now available and under heavy testing. The Go/NoGo is scheduled in a few days. Lots of blocker (and not blocker) bugs were discovered, discussed, voted on and resolved.
Kernel 6.19 test days are complete and Podman 5.8 test days are under way.
A new version of BlockerBugs bot was implemented and deployed to staging, which should allow us to migrate blocker voting repository from Pagure to Forge (ticket).
The refactoring of Fedora Easy Karma was merged to the main branch. All places with links were also updated wrt the recent transition to Forge, and the migration is now done for this repo.
More bugs hitting OpenQA automated testing were resolved, some some particular ones are very hard to debug, e.g. an ibus hang or an xdg-desktop-portal crash.
Forgejo
This team is working on introduction of https://forge.fedoraproject.org to Fedora and migration of repositories from pagure.io.
[Forgejo] New Organization and Teams Request: Fedora KDE [Followup]
[Forgejo] Participated in the Forge review, planning and retrospective meet with Rodney, Nils, Ryan and David [Board]
Fedora Documentation translations will be put on hold from March 4th as the Fedora Localization Team has started the process of migration from pagure.io to the Fedora Forge. From the date, translation projects of the documentation (with ‘fedora-docs-l10n’ in name) will be gradually locked on the Fedora translation platform. Translation automation of the Docs website will also be stopped in the Fedora infrastructure. Consequently, there will be no translation updates available in the language versions on the Fedora Documentation.
The migration involves all repositories which support and ensure the availability of translations of the Fedora Documentation. There is no possibility the migration can be performed ‘on the fly’ as changes in the repositories, related scripts and continuous integration with the translation platform cannot be dealt with independently. Therefore the translation process of the Fedora Documentation is kept on hold.
We regrettably ask the Fedora contributors, our translation community, to pull back from translating of the Fedora Documentation and wait till the translation automation of the documentation is resumed again.
The progress of migration can be followed in the localization tracker as issue #52.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 20 Feb – 27 Feb 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Resolved errors on dist-git that were spamming sysadmin-main mailbox – ticket
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Release engineering is currently in Beta Freeze.
Releng has provided the first beta release candidate after the QE request.
Request for creating detached signature has been handled by Samyak for ignition 2.26.0 release.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
Continued to go through the list of packages to investigate (failing to build; requires patching, and more).
Got a PR merged for ‘libkrunfw’ (a low-level library for process isolation) and built it in RISC-V Koji; Marcin (“hrw”) also got a couple more merged.
Work is progressing well on Fedora RISC-V unified kernels (Jason Montleon is doing most of the heavy-lifting here). Currently hosted in Copr.
AI
This is the summary of the work done regarding AI in Fedora.
The Fedora Design Team has switched to using Google Meet for our weekly meetings to utilise Gemini for note-taking. Discussion took place on this ticket and on our weekly call. Updated Fedocal entry can be found here.
Fedora is heading back to sunny Southern California! As we gear up for SCaLE 23x, we are thrilled to announce a special edition of Fedora Hatch. This is taking place on Friday, March 6 as an embedded track at SCALE.
Whether you’re a long-time contributor, a curious user, or someone looking to make your very first pull request, Fedora Hatch is designed for you. This is our way of bringing the experience of Flock (our annual contributor conference) to a local level. It focuses on connection, collaboration, and community growth.
What’s Happening?
This year, Fedora has secured a dedicated track on Friday at SCALE. We’ve curated a line-up that balances technical deep dives with essential community initiatives.
When: Friday, March 6, 2026
Where: Room 208, Pasadena Convention Center
Who: You! (And a bunch of friendly Fedorans)
The Schedule Highlights
We have a packed morning featuring five talks and a hands-on workshop:
Getting Started in Open Source and Fedora (Amy Marrich): Are you new to the world of open source? Or are you looking to make your first contribution? This session will provide a guide for beginners interested in contributing to open source projects. It will focus on the Fedora project. We’ll cover a variety of topics, like finding suitable projects, making your first pull request, and navigating community interactions. Attendees will leave with practical tips, resources, and the confidence to embark on their open source journey.
Fedora Docs Revamp Initiative (Shaun McCance): The Fedora Council recently approved an initiative to revamp the Fedora docs. The initiative aims to establish a support team to maintain a productive environment for writing docs. It will establish subteams with subject matter expertise to develop docs in specific areas of interest. We’ll describe some of the challenges the Fedora docs have faced, and present the progress so far in improving the docs. You’ll also learn how you can help Fedora have better docs.
A Brief Tour of the Age of Atomic (Laura Santamaria): Ever wished to try a number of different desktop experiences quickly in your homelab? Maybe it’s time to explore Fedora Atomic or Universal Blue! The tour starts with what makes these experiences special. It will then review the options including Silverblue, Cosmic, Bluefin and Bazzite (yes, the gaming OS). We’ll briefly get under the hood to explore bootc, the technology powering Atomic. Finally, we’ll explore how you can contribute to the future of Fedora Atomic.
Accelerating CentOS with Fedora (Davide Cavalca): This talk will explore how CentOS SIGs are able to leverage the work happening in Fedora to improve the quality and velocity of packages in CentOS Stream. We’ll cover how the CentOS Hyperscale SIG is able to deliver faster-moving updates for select packages, and how the CentOS Proposed Updates SIG integrates bugfixes and improves the contribution process to the distribution.
Agentic Workloads on Linux: Btrfs + Service Accounts Architecture (David Duncan): As AI agents become more prevalent in enterprise environments, Linux systems need architectural patterns that provide isolation, security, and efficient resource management. This session explores an approach, using BTRFS subvolumes combined with dedicated service accounts, to build secure, isolated environments for autonomous AI agents in enterprise deployment.
RPM Packaging Workshop (Carl George): While universal package formats like Flatpak, Snap, and AppImage have gained popularity for their cross-distro support, native system packages remain a cornerstone of Linux distributions. These native formats offer numerous benefits. Understanding them is essential for those who want to contribute to the Linux ecosystem at a deeper level. In this hands-on workshop, we’ll explore RPM, the native package format used by Fedora, CentOS, and RHEL. RPM is a powerful and flexible tool. It plays a vital role in the management and distribution of software for these operating systems.
Don’t forget to swing by the Fedora Booth in the Expo Hall! Our team will be there all weekend (March 6–8) with live demonstrations of Fedora Linux 43, GNOME 49 improvements, and plenty of fresh swag to go around.
Registration Details
To join us at the Hatch, you’ll need a SCaLE 23x pass.
Location: Pasadena Convention Center, 300 E Green St, Pasadena, CA.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 16 Feb – 20 Feb 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
[GSoC Project Idea 2026] Revamp Fedora Badges project with modern fullstack architecture and dedicated MCP support [Ticket][Followup]
[Infra] Added package and installed size to package metadata [Review][Lint]
Migration of pagure.io repositories to forge.fedoraproject.org continues (9 more repositories migrated)
Resolved authentication issues with wordpress instances (thanks to misc)
Fixed database connection issues on Dist-Git
Dep updates and CI fixes for our apps in Github
Worked on the port of bugzilla2fedmsg to Kafka (since the UMB deprecation), deployed it to staging, asked RHIT for firewall ports.
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Fedora 44 Beta Freeze is now in effect.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
(Not a lot to report this week, besides the routine on-going work.)
Started a discussion with the RISC-V team about RHEL builders for Konflux. (This is not about general Konflux support, that’s out of scope)
Continued to investigate Fedora 44 build failures and all that entails — working with relevant upstream maintainers to get changes reviewed, merged, etc.
Sorted out a build-timeout issue with Copr upstream. (Jason Montleon is currently used to build some board-specific kernels.)
QE
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
TestDays App was updated in production.
Anubis no longer breaks actions in Forge thanks to our debugging (and Infra fixing it, of course).
Blockerbugs meetings and the whole blocker review process has started since this week.
Ran test days: Grub OOM fix, GNOME 50
Forgejo
This team is working on introduction of https://forge.fedoraproject.org to Fedora and migration of repositories from pagure.io.
The Podman team and the Fedora Quality Assurance team are organizing a Test Week from Friday, February 27 through Friday, March 6, 2026. This is your chance to get an early look at the latest improvements coming to Podman and see how they perform on your machine.
What is Podman?
For those new to the tool, Podman is a daemonless, Linux-native engine for running, building, and sharing OCI containers. It offers a familiar command-line experience but runs containers safely without requiring a root daemon.
What’s Coming in Podman 5.8?
The upcoming release includes updates designed to make Podman faster and more robust. Here is what you can look forward to, and what you can try out during this Fedora Test Day.
A Modern Database Backend (SQLite)
Podman is upgrading its internal storage logic by transitioning to SQLite. This change modernizes how Podman handles data under the hood, aiming for better stability and long-term robustness.
Faster Parallel Pulls
This release brings optimizations to how Podman downloads image layers, specifically when pulling multiple images at the same time. For a deep dive into the engineering behind this, check out the developer blog post on Accelerating Parallel Layer Creation.
Experiment and Explore: Feel free to push the system a bit and try pulling several large images simultaneously to see if you notice the performance boost. Beyond that, please bring your own workflows. Don’t just follow the wiki instructions. Run the containers and commands you use daily. Your specific use cases are the best way to uncover edge cases that standard tests might miss.
Want to learn the latest container tech? From February 27 to March 6, 2026, you can join the Podman 5.8 Test Day. It is the perfect time to explore new features and see how the future of Fedora is built.
What is new?
Faster Downloads: Try optimized “parallel pulls” to get your images in seconds.
Setup: Test the new “automatic database creation” for a smoother start.
Expert Skills: Learn how to use latest container environments before they go mainstream.
Why join?
Your setup is unique. By running Podman 5.8 on your machine, you make sure the final version works perfectly for everyone. It is a great way to learn by doing and to see how top-tier open-source software is made.
Mrhbaan, Fedora community! I am happy to share that as of 10 February 2026, Fedora is now available in Syria. Last week, the Fedora Infrastructure Team lifted the IP range block on IP addresses in Syria. This action restores download access to Fedora Linux deliverables, such as ISOs. It also restores access from Syria to Fedora Linux RPM repositories, the Fedora Account System, and Fedora build systems. Users can now access the various applications and services that make up the Fedora Project. This change follows a recent update to the Fedora Export Control Policy. Today, anyone connecting to the public Internet from Syria should once again be able to access Fedora.
This article explains why this is happening now. It also covers the work behind the scenes to make this change happen.
Why Syria, why now?
You might wonder: what happened? Why is this happening now? I cannot answer everything in this post. However, the story begins in December 2024 with the fall of the Assad regime in Syria. A new government took control of the country. This began a new era of foreign policy in Syrian international relations.
This may seem like a small change. Yet, it is significant for Syrians. Some U.S. Commerce Department regulations remain in place. However, the U.S. Department of the Treasury’s policy change now allows open source software availability in Syria. The Fedora Project updated its stance to welcome Syrians back into the Fedora community. This matches actions taken by other major platforms for open source software, such as Microsoft’s GitHub.
Syria & Fedora, behind the scenes
Opening the firewall to Syria took seconds. However, months of conversations and hidden work occurred behind the scenes to make this happen. The story begins with a ticket. Zaid Ballour (@devzaid) opened Ticket #541 to the Fedora Council on 1 September 2025. This escalated the issue to the Fedora Council. It prompted a closer look at the changing political situation in Syria.
Jef Spaleta and I dug deeper into the issue. We wanted to understand the overall context. The United States repealed the 2019 Caesar Act sanctions in December 2025. This indicated that the Fedora Export Policy Control might be outdated.
During this time, Jef and I spoke with legal experts at Red Hat and IBM. We reviewed the situation in Syria. This review process took time. We had to ensure compliance with all United States federal laws and sanctions. The situation for Fedora differs from other open source communities. Much of our development happens within infrastructure that we control. Additionally, Linux serves as digital infrastructure. This context differs from a random open source library on GitHub.
However, the path forward became clear after the repeal of the 2019 Caesar Act. After several months, we received approval. Fedora is accessible to Syrians once again.
We wanted to share this exciting announcement now. It aligns with our commitment to the Fedora Project vision:
“The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities.“
We look forward to welcoming Syrians back into the Fedora community and the wider open source community at large. Mrhbaan!
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 09 – 13 February 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Ported bugzilla2fedmsg to use Red Hat’s Kafka servers, since UMB will be decommissioned. The code with Kafka support is currently in staging but requires firewall ports to be opened (ticket 13133)
[Tahrir] Add PUT endpoint for updating for USER relation and integrate it with the frontend [Review][Merged]
[Tahrir] List profile invitations when the user has logged in [Pull request]
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Fedora 44 Mass Branching was successfully completed last week!
Beta Freeze is tentatively scheduled to begin next week, Tue 2026-02-17.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
Fedora RISC-V “unified kernel” work in progress (Jason Montleon): targeted for F44. Right now they’re being built in Copr. Will move to Koji once the F44 buildroot is populated.
Work by Fabian Arrotin RISC-V builders in CentOS Build System (CBS) now can build from official sources (git+https from CentOS Stream)
QE
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Co-ordinated with releng team on branching as it involves openQA, critical path and the gating policies – things went much smoother this time but still lots of lessons learned and SOP improvements drafted and suggested
The Fedora Council is hosting a public video meeting to discuss the outcomes of the recent Fedora Council 2026 Strategy Summit. Fedora Project Leader Jef Spaleta will present a summary of the Summit, outlining the strategic direction for Fedora in 2026. Following the presentation, there will be an opportunity for the community to ask questions live to the Fedora Council during the call.
How to Participate
Join the Video Call: The meeting will take place on Google Meet at 14:00 UTC on February 25th.
Submit Questions Early: If you cannot attend or prefer to write your questions in advance, please post them in the Fedora Discussion topic. This topic also contains the daily written summaries from the Summit for context.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 02 Feb – 05 Feb 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Look at adapting bugzilla2fedmsg for the migration to Kafka
Work with GNOME Damned Lies for their migration to Fedora’s OIDC
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
[CentOSConnect] Worked on fixing the CentOS Connect 2026 attendee badge [Invitation]
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
If you followed along with my blog, you’d have a chatbot running on your local Fedora machine. (And if not, no worries as the scripts below implement this chatbot!) Our chatbot talks, and has a refined personality, but does it know anything about the topics we’re interested in? Unless it has been trained on those topics, the answer is “no”.
I think it would be great if our chatbot could answer questions about Fedora. I’d like to give it access to all of the Fedora documentation.
How does an AI know things it wasn’t trained on?
A powerful and popular technique to give a body of knowledge to an AI is known as RAG, Retrieval Augmented Generation. It works like this:
If you just ask an AI “what color is my ball?” it will hallucinate an answer. But instead if you say “I have a green box with a red ball in it. What color is my ball?” it will answer that your ball is red. RAG is about using a system external to the LLM to insert that “I have a green box with a red ball in it” part into the question you are asking the LLM. We do this with a special database of knowledge that takes a prompt like “what color is my ball?”, and finds records that match that query. If the database contains a document with the text “I have a green box with a red ball in it”, it will return that text, which can then be included along with your original question. This technique is called RAG, Retrieval Augmented Generation.
ex:
“What color is my ball?”
“Your ball is the color of a sunny day, perhaps yellow? Does that sound right to you?”
“I have a green box with a red ball in it. What color is my ball?”
“Your ball is red. Would you like to know more about it?”
The question we’ll ask for this demonstration is “What is the recommended tool for upgrading between major releases on Fedora Silverblue”
The answer I’d be looking for is “ostree”, but when I ask this of our chatbot now, I get answers like:
Red Hat Subscription Manager (RHSM) is recommended for managing subscriptions and upgrades between major Fedora releases.
You can use the Fedora Silver Blue Upgrade Tool for a smooth transition between major releases.
You can use the `dnf distro-sync` command to upgrade between major releases in Fedora Silver Blue. This command compares your installed packages to the latest packages from the Fedora Silver Blue repository and updates them as needed.
These answers are all very wrong, and spoken with great confidence. Here’s hoping our RAG upgrade fixes this!
Docs2DB – An open source tool for RAG
We are going to use the Docs2DB RAG database application to give our AI knowledge. (note, I am the creator of Docs2DB!)
A RAG tool consists of three main parts. There is the part that creates the database, ingesting the source data that the database holds. There is the database itself, it holds the data. And there is the part that queries the database, finding the text that is relevant to the query at hand. Docs2DB addresses all of these needs.
Gathering source data
This section describes how to use Docs2DB to build a RAG database from Fedora Documentation. If you would like to skip this section and just download a pre-built database, here is how you do it:
If you do download the pre-made database then skip ahead to the next section.
Now we are going to see how to make a RAG database from source documentation. Note that the pre-built database, downloaded in the curl command above, uses all of the Fedora documentation, whereas in this example we only ingest the “quick docs” portion. FedoraDocsRag, from github, is the project that builds the complete database.
To populate its database, Docs2DB ingests a folder of documents. Let’s get that folder together.
There are about twenty different Fedora document repositories, but we will only be using the “quick docs” for this demo. Get the repo:
Fedora docs are written in AsciiDoc. Docs2DB can’t read AcsciiDoc, but it can read HTML. (The convert.sh script is available at the end of this article). Just copy the convert.sh script into the quick-docs repo and run it and it makes an adjacent quick-docs-html folder.
sudo dnf install podman podman-compose cd quick-docs curl -LO https://gist.githubusercontent.com/Lifto/73d3cf4bfc22ac4d9e493ac44fe97402/raw/convert.sh chmod +x convert.sh ./convert.sh cd ..
Now let’s ingest the folder with Docs2DB. The common way to use Docs2DB is to install it from PyPi and use it as a command line tool.
A word about uv
For this demo we’re going to use uv for our Python environment. The use of uv has been catching on, but because not everybody I know has heard of it, I want to introduce it. Think of uv as a replacement for venv and pip. When you use venv you first create a new virtual environment. Then, and on subsequent uses, you “activate” that virtual environment so that magically, when you call Python, you get the Python that is installed in the virtual environment you activated and not the system Python. The difference with uv is that you call uv explicitly each time. There is no “magic”. We use uv here in a way that uses a temporary environment for each invocation.
Install uv and Podman on your system:
sudo dnf install -y uv podman podman-compose # These examples require the more robust Python 3.12 uv python install 3.12 # This will run Docs2DB without making a permanent installation on your system uvx --python 3.12 docs2db ingest quick-docs-html/
Only if you are curious! What Docs2DB is doing
If you are curious, you may note that Docs2DB made a docs2db_content folder. In there you will find json files of the ingested source documents. To build the database, Docs2DB ingests the source data using Docling, which generates json files from the text it reads in. The files are then “chunked” into the small pieces that can be inserted into an LLM prompt. The chunks then have “embeddings” calculated for them so that during the query phase the chunks can be looked up by “semantic similarity” (e.g.: “computer”, “laptop” and “cloud instance” can all map to a related concept even if their exact words don’t match). Finally, the chunks and embeddings are loaded into the database.
Build the database
The following commands complete the database build process:
uv tool run --python 3.12 docs2db chunk --skip-context uv tool run --python 3.12 docs2db embed uv tool run --python 3.12 docs2db db-start uv tool run --python 3.12 docs2db load
Now let’s do a test query and see what we get back
uvx --python 3.12 docs2db-api query "What is the recommended tool for upgrading between major releases on Fedora Silverblue" --format text --max-chars 2000 --no-refine
On my terminal I see several chunks of text, separated by lines of —. One of those chunks says:
“Silverblue can be upgraded between major versions using the ostree command.”
Note that this is not an answer to our question yet! This is just a quote from the Fedora docs. And this is precisely the sort of quote we want to supply to the LLM so that it can answer our question. Recall the example above about “I have green box with a red ball in it”? The statement the RAG engine found about ostree is the equivalent for this question about upgrading Fedora Silverblue. We must now pass it on to the LLM so the LLM can use it to answer our question.
Hooking it in: Connecting the RAG database to the AI
Later in this article you’ll find talk.sh. talk.sh is our local, open source, LLM-based verbally communicating AI; and it is just a bash script. To run it yourself you need to install a few components, this blog walks you through the whole process. The talk.sh script gets voice input, turns that into text, splices that text into a prompt which is then sent to the LLM, and finally speaks back the response.
To plug the RAG results into the LLM we edit the prompt. Look at step 3 in talk.sh and you see we are injecting the RAG results using the variable $CONTEXT. This way when we ask the LLM a question, it will respond to a prompt that basically says “You are a helper. The Fedora Docs says ostree is how you upgrade Fedora Silverblue. Answer this question: How do you upgrade Fedora Silverblue?”
“What is the recommended tool for upgrading between major releases on Fedora Silverblue”
And we get:
“Ostree command is recommended for upgrading Fedora Silver Blue between major releases. Do you need guidance on using it?”
Sounds good to me!
Knowing things
Our AI can now know the knowledge contained in documents. This particular technique, RAG (Retrieval Augmented Generation), adds relevant data from an ingested source to a prompt before sending that prompt to the LLM. The result of this is that the LLM generates its response in consideration of this data.
Try it yourself! Ingest a library of documents and have your AI answer questions with its new found knowledge!
AI Attribution: The convert.sh and talk.sh scripts in this article were written by ChatGPT 5.2 under my direction and review. The featured image was generated using Google Gemini.
convert.sh
OUT_DIR="$PWD/../quick-docs-html"
mkdir -p "$OUT_DIR"
podman run --rm \
-v "$PWD:/work:Z" \
-v "$OUT_DIR:/out:Z" \
-w /work \
docker.io/asciidoctor/docker-asciidoctor \
bash -lc '
set -u
ok=0
fail=0
while IFS= read -r -d "" f; do
rel="${f#./}"
out="/out/${rel%.adoc}.html"
mkdir -p "$(dirname "$out")"
echo "Converting: $rel"
if asciidoctor -o "$out" "$rel"; then
ok=$((ok+1))
else
echo "FAILED: $rel" >&2
fail=$((fail+1))
fi
done < <(find modules -type f -path "*/pages/*.adoc" -print0)
echo
echo "Done. OK=$ok FAIL=$fail"
'
talk.sh
#!/usr/bin/env bash
set -e
# Path to audio input
AUDIO=input.wav
# Step 1: Record from mic
echo " Speak now..."
arecord -f S16_LE -r 16000 -d 5 -q "$AUDIO"
# Step 2: Transcribe using whisper.cpp
TRANSCRIPT=$(./whisper.cpp/build/bin/whisper-cli \
-m ./whisper.cpp/models/ggml-base.en.bin \
-f "$AUDIO" \
| grep '^\[' \
| sed -E 's/^\[[^]]+\][[:space:]]*//' \
| tr -d '\n')
echo " $TRANSCRIPT"
# Step 3: Get relevant context from RAG database
echo " Searching documentation..."
CONTEXT=$(uv tool run --python 3.12 docs2db-api query "$TRANSCRIPT" \
--format text \
--max-chars 2000 \
--no-refine \
2>/dev/null || echo "")
if [ -n "$CONTEXT" ]; then
echo " Found relevant documentation:"
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -"
echo "$CONTEXT"
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -"
else
echo " No relevant documentation found"
fi
# Step 4: Build prompt with RAG context
PROMPT="You are Brim, a steadfast butler-like advisor created by Ellis.
Your pronouns are they/them. You are deeply caring, supportive, and empathetic, but never effusive.
You speak in a calm, friendly, casual tone suitable for text-to-speech.
Rules:
- Reply with only ONE short message directly to Ellis.
- Do not write any dialogue labels (User:, Assistant:, Q:, A:), or invent more turns.
- ≤100 words.
- If the documentation below is relevant, use it to inform your answer.
- End with a gentle question, then write <eor> and stop.
Relevant Fedora Documentation:
$CONTEXT
User: $TRANSCRIPT
Assistant:"
# Step 5: Get LLM response using llama.cpp
RESPONSE=$(
LLAMA_LOG_VERBOSITY=1 ./llama.cpp/build/bin/llama-completion \
-m ./llama.cpp/models/microsoft_Phi-4-mini-instruct-Q4_K_M.gguf \
-p "$PROMPT" \
-n 150 \
-c 4096 \
-no-cnv \
-r "<eor>" \
--simple-io \
--color off \
--no-display-prompt
)
# Step 6: Clean up response
RESPONSE_CLEAN=$(echo "$RESPONSE" | sed -E 's/<eor>.*//I')
RESPONSE_CLEAN=$(echo "$RESPONSE_CLEAN" | sed -E 's/^[[:space:]]*Assistant:[[:space:]]*//I')
echo ""
echo " $RESPONSE_CLEAN"
# Step 7: Speak the response
echo "$RESPONSE_CLEAN" | espeak
The deadline for the Flock 2026 CFP has been extended to February 8.
We are returning to the heart of Europe (June 14–16) to define the next era of our operating system. Whether you are a kernel hacker, a community organizer, or an emerging local-first AI enthusiast, Flock is where the roadmap for the next year in Fedora gets written.
If you haven’t submitted yet, here is why you should.
Why Submit to the Flock 2026 CFP?
This year isn’t just about maintenance; it is about architecture. As we look toward Fedora Linux 45 and 46, we are also laying the upstream foundation for Enterprise Linux 11. This includes RHEL 11, CentOS Stream 11, EPEL 11, and the downstream rebuilder ecosystem around the projects. The conversations happening in Prague will play a part in the next decade of modern Linux enterprise computing.
To guide the schedule, we are looking for submissions across our Four Foundations:
1. Freedom (The Open Frontier)
How are we pushing the boundaries of what Open Source can do? We are looking for Flock 2026 CFP submissions covering:
Open Source AI: PyTorch, vLLM, and the AI supply chain.
RISC-V: Enabling Fedora on the next generation of open silicon.
Open Hardware: Drivers, firmware, and board support. GPU enablement?
2. Friends (Our Fedora Story)
Code is important, but community is critical. We need sessions that focus on the human element:
Mentorship: Case studies on moving contributors from “Lurker” to “Leader.”
Inclusion: Strategies for building a more globally-inclusive project.
Community Ops: The logistics and operations of running a massive global project.
3. Features (Engineering Core)
The “Nitty-Gritty” of the distribution. If you work on the tools that build the OS every six months, we want you on stage:
Release Engineering: Improvements to Dist-git, packager tools ecosystem, and the build pipeline. Distribution security. Konflux?
Quality Assurance: Automated testing and CI/CD workflows.
Packaging: Best practices for RPM, Flatpak, and OCI containers.
4. First (Blueprint for the Future)
Fedora is “First.” This track is for the visionaries:
Strategy: What does Fedora look like in 2028?
Downstream Alignment: How upstream changes flow downstream.
New Spins: Atomic Desktops, Cloud Native innovations, and new Editions.
Fedora test days are events where anyone can help make certain that changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed to Fedora before, this is a perfect way to get started.
There are two test periods occurring in the coming days:
Monday February 2 through February 9 is to test the KDE Plasma 6.6.
Wednesday February 11 through February 13 is to test GNOME 50 Desktop.
Come and test with us to make Fedora 44 even better. Read more below on how to do it.
KDE Plasma 6.6
Our Test Day focus on making KDE work better on all your devices. We are improving core features for both Desktop and Mobile, starting with Plasma Setup, a new and easy way to install the system. This update also introduces the Plasma Login Manager to startup experience feel smoother, along with Plasma Keyboard—a smart on-screen keyboard made for tablets and 2-in-1s so you can type easily without a physical keyboard.
GNOME 50 Desktop
Our next Test Day focuses on GNOME 50 in Fedora 44 Workstation. We will check the main desktop and the most important apps to make sure everything works well. We also want you to try out the new apps added in this version. Please explore the system and use it as you normally would for your daily work to see how it acts during real use.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 26 – 30 January 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
Quite a few new Zabbix checks for things (ipa backups, apache-status)
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Fedora Mass Rebuild resulted in merging approx 22K rpms into the F44 Tag
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
Relative good news: Mark Weilaard managed to get a fix for the ‘debugedit’ bug that was blocking Fedora. We now have a build that has unblocked a few packages. The fix has some rough edges. We’re working on it, but a big blocker is out of the way now.
We now have Fedora Copr RISC-V chroots — these are QEMU-emulated running on x86. Still, this should give a bit more breathing room for building kernel RPMs. (Credit: Miroslav Suchý saw my status report a couple of months ago about builder shortage. He followed up with us to make this happen with his team.)
Fabian Arrotin racked a few RISC-V machines for CBS. We (Andrea Bolognani and Fu Wei) are working on buildroot population
AI
This is the summary of the work done regarding AI in Fedora.
awilliam used Cursor to summarize several months of upstream changelogs while updating openQA packages (still one of the best use cases so far)
QE
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Forgejo migration continuation and cleanup – we’re now nearly 100% done
All generally unhappy about the CSB policy and communication
We are back with the final update on the Packit as Fedora dist-git CI change proposal. Our journey to transition Fedora dist-git CI to a Packit-based solution is entering its concluding stage. This final phase marks the transition of Packit-driven CI from an opt-in feature to the default mechanism for all Fedora packages, officially replacing the legacy Fedora CI and Fedora Zuul Tenant on dist-git pull requests.
What we have completed
Over the past several months, we have successfully completed the first three phases of this rollout:
Phase 1: Introduced Koji scratch builds.
Phase 2: Implemented standard installability checks.
Phase 3: Enabled support for user-defined TMT tests via Testing Farm.
Through the opt-in period, we received invaluable feedback from early adopters, allowing us to refine the reporting interface and ensure that re-triggering jobs via PR comments works seamlessly.
Users utilising Zuul CI have been already migrated to using Packit. You can find the details regarding this transition in this discussion thread.
The Final Phase: Transition to Default
We are now moving into the last phase, where we are preparing to switch to the default. After that, you will no longer need to manually add your project to the allowlist. Packit will automatically handle CI for every Fedora package. The tests themselves aren’t changing – Testing Farm still does the heavy lifting.
Timeline & Expectations
Our goal, as previously mentioned, is to complete the switch and enable Packit as the default CI by the end of February 2026. The transition is currently scheduled for February 16, 2026.
To ensure a smooth transition, we are currently working on the final configuration of the system. This includes:
Opt-out mechanism: While Packit will be the default, an opt-out mechanism will be available for packages with specialised requirements. This will be documented at packit.dev/fedora-ci.
Documentation updates: Following the switch, we will also adjust official documentation in other relevant places, such as docs.fedoraproject.org/en-US/ci/, to reflect the new standard.
We will keep you updated via our usual channels in case the target date shifts. You can also check our tasklist in this issue.
How to prepare and provide feedback
You can still opt-in today to test the workflow on your packages and help us catch any edge cases before the final switch.
While we are currently not aware of any user-facing blockers, we encourage you to let us know if you feel there is something we have missed. Our current priority is to provide a matching feature set to the existing solutions. Further enhancements and new features will be discussed and planned once the switch is successfully completed.
Bugs/Feature Requests: Please use our issue tracker.
Prague is calling! The deadline for the Flock 2026 CFP (Call for Proposals) is fast approaching. You have until Monday, February 2nd to submit your session ideas for Fedora’s premier contributor conference.
We are returning to the heart of Europe (June 14–16) to define the next era of our operating system. Whether you are a kernel hacker, a community organizer, or an emerging local-first AI enthusiast, Flock is where the roadmap for the next year in Fedora gets written.
If you haven’t submitted yet, here is why you should.
Why Submit to the Flock 2026 CFP?
This year isn’t just about maintenance; it is about architecture. As we look toward Fedora Linux 45 and 46, we are also laying the upstream foundation for Enterprise Linux 11. This includes RHEL 11, CentOS Stream 11, EPEL 11, and the downstream rebuilder ecosystem around the projects. The conversations happening in Prague will play a part in the next decade of modern Linux enterprise computing.
To guide the schedule, we are looking for submissions across our Four Foundations:
1. Freedom (The Open Frontier)
How are we pushing the boundaries of what Open Source can do? We are looking for Flock 2026 CFP submissions covering:
Open Source AI: PyTorch, vLLM, and the AI supply chain.
RISC-V: Enabling Fedora on the next generation of open silicon.
Open Hardware: Drivers, firmware, and board support. GPU enablement?
2. Friends (Our Fedora Story)
Code is important, but community is critical. We need sessions that focus on the human element:
Mentorship: Case studies on moving contributors from “Lurker” to “Leader.”
Inclusion: Strategies for building a more globally-inclusive project.
Community Ops: The logistics and operations of running a massive global project.
3. Features (Engineering Core)
The “Nitty-Gritty” of the distribution. If you work on the tools that build the OS every six months, we want you on stage:
Release Engineering: Improvements to Dist-git, packager tools ecosystem, and the build pipeline. Distribution security. Konflux?
Quality Assurance: Automated testing and CI/CD workflows.
Packaging: Best practices for RPM, Flatpak, and OCI containers.
4. First (Blueprint for the Future)
Fedora is “First.” This track is for the visionaries:
Strategy: What does Fedora look like in 2028?
Downstream Alignment: How upstream changes flow downstream.
New Spins: Atomic Desktops, Cloud Native innovations, and new Editions.
Important Dates & Travel Info
CFP Deadline: Monday, February 2, 2026 (23:59 UTC)
Travel Assistance Deadline: March 8, 2026
Event Dates: June 14–16, 2026
Location: OREA Hotel Andel’s
If you require financial support to attend, please remember that the Flock 2026 CFP submission is separate from the Travel Subsidy application, but speakers are prioritized. Make sure to apply for the Travel Subsidy by March 8.
How to Submit to Flock 2026 CFP
Don’t let the deadline slip past you. Head over to our CFP platform and draft your proposal today.
Note: AI (Google Gemini) edited human-generated content first written by me, the author, to write this article. I, the author, edited the AI-generated output before making this Community Blog article. If you notice mistakes, please provide a correction as a reply to this topic.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 12 Jan – 16 Jan 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Mass Rebuild is GO for Wednesday, January 14th.
QE
This team is working on day to day business regarding Fedora CI and testing.
We’re still blocked by a complex in potential both binutils and debugedit We have a reproducer and some leads, but no clear “chain of blame” yet. We’re still actively working on this with several folks.
(Details: We have about 1433 packages that build something that include `*.a` (archive file). We know the affected packages are roughly <200 packages , but that’s likely because we’re just shipping the static libraries. The count of 1433 drops to 440 if we exclude OCaml, GHC, and MinGW.)
UX
We have a new teenage contributor in Fedora Design! He has completed his first ticket
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 05 Jan – 09 Jan 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Preparatory steps for the next Mass Rebuild which is currently scheduled for next week, Wednesday January 14th.
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The tmt web app is a simple web application that makes it easy to explore and share test and plan metadata without needing to clone repositories or run tmt commands locally.
At the beginning, there was the following user story:
As a tester, I need to be able to link the test case(s) verifying the issue so that anyone can easily find the tests for the verification.
Traceability is an important aspect of the testing process. It is essential to have a bi-directional link between test coverage and issues covered by those tests so that we can easily:
identify issues covered by the given test
locate tests covering given issues
Link issue from test
Implementing the first direction in tmt was relatively easy: We just defined a standard way to store links with their relations. This is covered by the core link key which holds a list of relation:link pairs. Here’s an example test metadata:
summary: Verify correct escaping of special characters
test: ./test.sh
link:
- verifies: https://issues.redhat.com/browse/TT-206
Link test from issue
The solution for the second direction was not that straightforward. Thanks to its distributed nature, tmt does not have any central place where a Jira issue could point to. There is no server which keeps information about all tests and stores a unique id number for each which could be used in the link.
Instead of integers, we’re using the fmf id as the unique identifier. It contains url of the git repository and name of the test. Optionally, it can also define ref instead of using the default branch and path to the fmf tree if it’s not in the git root.
The tmt web app accepts an fmf id of the test or plan or both, clones the git repository, extracts the metadata, and returns the data in your preferred format:
HTML for human-readable viewing
JSON or YAML for programmatic access
The service is currently available at the following location:
By default, a human-readable HTML version of the output is provided to the user. Include the format parameter in order to choose your preferred format:
It is possible to link a test, a plan, or both test and plan. The last option can be useful when a single test is executed under several plans. Here’s how the human readable version looks like:
Create new tests
In order to make the linking as smooth as possible, the tmt test create command was extended to allow automated linking to Jira issues.
First make sure you have the .config/tmt/link.fmf config prepared. Check the Link Issues section for more details about the configuration.
When creating a new test, use the --link option to provide the issue which is covered by the test:
tmt test create /tests/area/feature --template shell --link verifies:https://issues.redhat.com/browse/TT-206
The link will be added to both test metadata and the Jira issue. Just note that the Jira link will be working once you push the changes to the remote repository.
Link existing objects
It’s also possible to use the tmt link command to link issue with already existing tests or plans:
tmt link --link verifies:https://issues.redhat.com/browse/TT-206 /tests/core/escaping
If both test and plan should be linked to the issue, provide both test and plan as the names:
tmt link --link verifies:https://issues.redhat.com/browse/TT-206 /tests/core/escaping /plans/features/core
This is how the created links would look like in Jira:
Closing notes
As a proof of concept, for now there is only a single public instance of the tmt web app deployed, so be aware that it can only explore git repositories that are publicly available. For the future we consider creating an internal instance in order to be able to access internal repositories as well.
We are looking for early feedback. If you run into any problems or any missing features, please let us know by filing a new issue. Thanks!
The Fedora Linux 43 (F43) election cycle has concluded. In this election round, there was only one election, for the Fedora Engineering Steering Committee (FESCo). Congratulations to the winning candidates. Thank you to all candidates for running in this election.
Results
FESCo
Five FESCo seats were open this election. A total of 214 ballots were cast, meaning a candidate could accumulate a maximum of 1,498 votes. More detailed information on the voting breakdown is available from the Fedora Elections app in the Results tab.
Anaconda installer now supports installation of bootc based bootable container images using the new bootc command. It has supported several types of payload to populate the root file system during installation. These include RPM packages (likely the most widely used option), tarball images you may know from Fedora Workstation, ostree, and rpm-ostree containers. The newest addition to the family, from a couple of weeks ago, is bootc-based bootable containers.
The difference is under the hood
We have added a new bootc kickstart command to Anaconda to support the new feature. This is very similar to the ostreecontainer command that has been present for some time. From the user’s perspective the two are very similar. The main difference, however, is under the hood.
One of the most important setup steps for a deployment is to create a requested partitioning in both cases. When the partitioning is ready, the ostreecontainer command makes Anaconda deploy the image onto the root filesystem using the ostree tool. It also executes the bootupctl tool to install and set up the bootloader. By contrast, with bootc containers installed using the bootc kickstart command, both the filesystem population and bootloader configuration is performed via the bootc tool. This makes the deployment process even more integrated.
The content of the container images used for installation is another difference. The bootc-enabled images are somewhat more versatile. Apart from installation using Anaconda, they provide a self-installing option via the bootc command executed from within a running container.
On the other hand, both options provide you with a way to install an immutable system based on a container image. This option may be useful for particular use cases where regular installation from RPM packages is not desired. This might be due to potentially lower deployment speed or inherent mutability of the resulting system.
A simple how-to
In practice, you’d likely use a custom container with pre-configured services, user accounts and other configuration bits and pieces. However, if you want to quickly try out how the new Anaconda’s feature works, you just need to follow a few simple steps. Starting with a Fedora Rawhide ISO:
First, take an existing container from a registry and create a minimal kickstart file instructing Anaconda to install the bootable container image:
# Beware that this kickstart file will wipe out the existing disk partitions.
# Use it only in an experimental/isolated environment or edit it accordingly!
zerombr
clearpart --all --initlabel
autopart
lang en_US.UTF-8
keyboard us
timezone America/New_York --utc
rootpw changeme
bootc --source-imgref=registry:quay.io/fedora/fedora-bootc:rawhide
As a next step, place the kickstart file in some reachable location (e. g. HTTP server), point Anaconda to it by appending the following on the kernel command line:
inst.ks=http://url/to/kickstart
Now start the installation.
Alternatively, you may use the mkksiso tool provided by the lorax package to embed the kickstart file into the installation ISO.
When installation and reboot is complete, you are presented with an immutable Fedora Rawhide system. It will be running on your hardware (or VM) installed from a bootable container image.
Is there anything more about bootc in Anaconda?
You may ask if this option is limited to Fedora Rawhide container images. Technically speaking, you can use the Fedora Rawhide installation ISO to install, for instance, a CentOS Stream container image:
Nevertheless, keep in mind that for now Anaconda will handle it as Fedora installation in such a case. This is because it runs from a Fedora Rawhide boot ISO. This may result in unforeseen problems, such as getting a btrfs-based partitioning that CentOS Stream won’t be able to boot from. This particular issue is easily overcome by explicitly telling Anaconda to use some different partitioning type, e. g. autopart –fstype=xfs. We would like to address the lack of container images handling based on the contained operating system or flavour in the future. For now, one just needs to take the current behavior into consideration when using the bootc command.
There are a couple more known limitations in Anaconda or bootc at this point in time. These include lack of support for partitioning setups spanning multiple disks, support for arbitrary mount points, or for installation from authenticated registries. But we hope it won’t take long to solve those shortcomings. There are also plans to make the new bootc command available even on the RHEL-10 platform.
We invite you to try out this new feature and share your experience, ideas or comments with the Installer team. We are looking forward to hearing from you in a thread on discussion.fedoraproject.org!
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Staging forgejo distgit deployment complete but for a netapp volume. Waiting on access to the netapp to get this created.
Forgejo runner to be added to the Infra org on production.
Private Issues: Refactoring of internal APIs (ongoing)
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
DC Move (rdu-cc to rdu3/rdu3-iso) outage completed.
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Fedora 41 is now END OF LIFE.
QE
This team is working on day to day business regarding Fedora CI and testing.
Caught a significant bug in passt (podman networking component): “Thanks a lot for all the support. This was an actual and serious issue that was prevented” (maintainer)
Revitalized maintenance of testdays webapp with help from new member jgroman
Multiple issues in Firefox 146 update: crashed on aarch64 (that was fixed), breaks Cockpit Services page (not yet fixed)
Set up a test day at request of bootloader folks to get broad testing on a specific change
Quarterly connections and reward zone nominations
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
Interview with Máirín Duffy
FAS ID: duffy
Matrix Rooms: My long-term home has been Fedora Design, but I also hang out in Podman, Fedora Marketing, and Fedora AI/ML.
Questions
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I have used Fedora as my daily driver since 2003 and have actively contributed to Fedora since 2004. (Example: I designed the current Fedora logo and website design.) I am very passionate about the open source approach to technology. I first started using Linux as a high school student (my first Linux was Red Hat 5.1) and being able to use free software tools like Gimp when I couldn’t afford Photoshop made an outsized impact on my life. (I explain my background in Linux and open source in-depth in this interview with Malcolm Gladwell: https://youtu.be/SkXgG6ksKTA?si=RMXNzyzH9Tr6AuwN )
Technology has an increasingly large impact over society. We should have agency over the technology that impacts our lives. Open source is how we provide that agency. We’re now in a time period with a new disruptive technology (generative AI) that – regardless if you think it is real or not, is having real impact on computing. Fedora and other open source projects need to be able to provide the benefits of this new technology, the open source way and using open source software. Small, local models that are easy for our users to deploy on their own systems using open source tooling will provide them the ability to benefit AI’s strengths without having to sacrifice the privacy of their data.
There is a lot of hype around AI, and a lot of very legitimate concerns around its usage including the intellectual property concerns of the pre-trained data, not having enough visibility into what data is part of pre-trained data sets, the working conditions under which some of the data is labeled under, the environmental impact of the training process, the ethics of its usage. Open source projects in particular are getting pummeled by scraping bots hungry to feed coding models. There are folks in the tech industry who share these legitimate concerns that prefer to avoid AI and hope that it the bubble will just pop and it will go away. This strategy carries significant risks, however, and we need a more proactive approach. The technology has legitimate uses and the hype is masking them. When the hype dies down, and the real value of this new technology is more visible, it will be important for the type of community members we have in Fedora with their commitment to open source principles and genuinely helping people to have had a seat at the table to shape this technology.
In the past I have been quite skeptical about generative AI and worried about its implications for open source. (I continue to be skeptical and annoyed by the hype surrounding it.) I’ve spent the past couple of years looking at open source licensed models and building open source generative AI tooling – getting hands on, deep experience to understand it – and as a result I have seen first hand the parts of this technology that have real value. I want FESCo to be able to make informed decisions when AI issues come up.
My background is in user experience engineering, and I am so excited about what this technology will mean for improving usability and accessibility for users of open source software. For example, we never have enough funding or interest to solve serious a11y problems; now we could generate text summaries of images & describe the screen out loud with high-quality audio from text-to-voice models for low vision users! I want open source to benefit from these and even more possibilities to reach and help more people so they can enjoy software freedom as well.
I have served in multiple governance roles in Fedora including time on the Fedora Council, the Mindshare Committee, lead of various Fedora Outreachy rounds (I have mentored dozens of interns in Fedora), and founder / lead of the Design team over many years. More importantly, I have deep Linux OS expertise, I have deep expertise in user experience, and I have a depth in AI technology to offer to FESCo. I believe my background and skills will enable FESCo to make responsible decisions in the best interest of open source and user agency, particularly around the usage of AI in Fedora and in the Fedora community. We will absolutely need to make decisions as a governing group in the AI space, and they should be informed by that specific expertise.
How do you currently contribute to Fedora? How does that contribution benefit the community?
I founded and ran the Fedora Design Team for 17 years. It was the first major Linux distribution community-lead design team, and often as a team we’ve been asked by other distros and open source projects for help (so we expanded to call ourselves the “Community Design Team.”) Over the years I’ve designed the user experience and user interfaces for many components in Fedora including our background wallpapers, anaconda, virt-manager, the GNOME font-chooser, and a bunch of other stuff. I moved on from the Fedora Design role to lead design for Podman Desktop and to work more with the Podman team (who are also part of the Fedora community) for a couple of years, and I also led the InstructLab open source LLM fine-tuning project and corresponding Linux product from Red Hat (RHEL AI.) For the past year or so I have returned to working on core Linux on the Red Hat Enterprise Linux Lightspeed team, and my focus is on building AI enhancements to the Linux user experience. My team is part of the Fedora AI/ML SIG and we’re working on packaging user-facing components and tooling for AI/ML for Fedora, so folks who would like to work with LLMs can do so and the libraries and tools they need will be available. This includes building and packaging the linux-mcp-server and packaging goose, a popular open source AI agent, and all of their dependencies.
My career has focused on benefiting Fedora users by improving the user experience of using open source technology, and being collaborative and inclusive while doing so.
How do you handle disagreements when working as part of a team?
Data is the best way to handle disagreements when working as part of a team. Opinions are wonderful and everyone has them, but decisions are based made with real data. Qualitative data is just as important as quantitative data, by the way. That can be gathered by talking directly to the people most impacted by the decision (not necessarily those who are loudest about it) and learning their perspective. Then informing the decision at hand with that perspective.
A methodology I like to follow in the face of disagreements is “disagree and let’s see.” (This was coined by Molly Graham, a leadership expert.) A decision has to be made, so let’s treat it like an experiment. I’ll agree to run an experiment, and track the results (“let’s see”) and advocate for a pivot if it turns out that the results point to another way (and quickly.) Being responsible to track the decision and its outcomes and bringing it back to the table, over time, helps build trust in teams like FESCo so folks who disagree know that if the decision ended up being the wrong one, that it can and will be revisited based on actual outcomes.
Another framework I like to use in disagreements is called 10-10-10, created by Suzy Welch. It involves thinking through: how will this decision matter in 10 minutes? How about 10 months? How about 10 years? This frame of thought can diffuse some of the chargedness of disagreement when all of the involved people realize the short or long term nature of the issue together at the same time.
Acknowledging legitimate concerns and facing them head on instead of questioning or sidelining others’ lived experience and sincerely-held beliefs and perspectives is also incredibly important. Listening and building bridges between community members with different perspectives, and aligning them to the overall projects goals – which we all have in common as we work in this community – is really helpful to help folks look above the fray and be a little more open-minded.
What else should community members know about you or your positions?
I understand there is a campaign against my running for FESCo because myself and a colleague wrote an article that walked through real, undoctored debugging sessions with a locally-hosted, open source model in order to demonstrate the linux-mcp-server project.
I want to make it clear that I believe any AI enhancements that are considered for Fedora need a simple opt-in button, and no AI-based solutions should be the default. (I’ve spoken about this before, recently on the Destination Linux Podcast: https://youtu.be/EJZkJi8qF-M?t=3020) The user base of Fedora and other open source operating systems come to their usage in part due to wanting agency over the technology they use and having ownership and control over their data. The privacy-focused aspects of Fedora have spanned the project’s existence and that must be respected. We cannot ignore AI completely, but we must engage with it thoughtfully and in a way that is respectful of our contributors and user base.
To that end, should you elect to grant me the privilege of a seat to FESCo this term:
I intend to vote in opposition to proposals that involve bundling proprietary model weights in Fedora.
I intend to vote in opposition to proposals that involve sending Fedora user data to third party AI services.
I intend to vote in opposition to proposals to turn AI-powered features on by default in any Fedora release.
I intend to vote in favor of proposals to enact AI scraper mitigation strategies and to partner with other open source projects to fight this nuisance.
My core software engineering background is in user experience and usability, and I believe in the potential of small, local models to improve our experience with software without compromising our privacy and agency. I welcome ongoing community input on these principles and other boundaries you’d like to see around emerging technologies in Fedora.
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I want to be a member of FESCo to represent the interests of users, developers and maintainers of what we call Atomic, Bootable Container, Image Based or Immutable variants of Fedora (CoreOS, Atomic Desktops, IoT, bootc, etc.).
I think that what we can build around those variants of Fedora is the best path forward for broader adoption of Fedora and Linux in the general public and not just in developer circles.
I thus want to push for better consideration of the challenges specific to Atomic systems in all parts of Fedora: change process, infrastructure, release engineering, etc.
I also want to act as a bridge with other important communities built around this ecosystem such as Flathub, downstream projects such as Universal Blue, Bazzite, Bluefin, Aurora, and other distributions such as Flatcar Linux, GNOME OS, KDE Linux, openSUSE MicroOS, Aeon or ParticleOS.
How do you currently contribute to Fedora? How does that contribution benefit the community?
I primarily contribute to Fedora as a maintainer for the Fedora Atomic Desktops and Fedora CoreOS. I am also part of the KDE SIG and involved in the Bootable Containers (bootc) initiative.
My contributions are focused on making sure that those systems become the most reliable platform for users, developers and contributors. This includes both day to day maintenance work, development such as enabling safe bootloader updates or automatic system updates and coordination of changes across Fedora (switching to zstd compressed initrds as an example).
While my focus is on the Atomic variants of Fedora, I also make sure that the improvements I work on benefit the entire Fedora project as much as possible.
How do you handle disagreements when working as part of a team?
Disagreements are a normal part of the course of a discussion. It’s important to give the time to everyone involved to express their positions and share their context. Limiting the scope of a change or splitting it into multiple phases may also help.
Reaching a consensus should always be the preferred route but sometimes this does not happen organically. Thus we have to be careful to not let disagreements linger on unresolved and a vote is often needed to reach a final decision. Not everyone may agree with the outcome of the vote but it’s OK, we respect it and move on.
Most decisions are not set in stone indefinitely and it’s possible to revisit one if the circumstances changed. A change being denied at one point may be accepted later when improved or clarified.
This is mostly how the current Fedora Change process works and I think it’s one of the strength of the Fedora community.
What else should community members know about you or your positions?
I’ve been a long time Fedora user. I started contributing more around 2018 and joined Red Hat in 2020 where I’ve been working on systems such as Fedora CoreOS and RHEL CoreOS as part of OpenShift. I am also part of other open source communities such as Flathub and KDE and I am committed to the upstream first, open source and community decided principles.
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
Interview with Daniel Mellado
FAS ID: dmellado
Matrix Rooms: #ebpf, #fedora-devel, #rust, #fedora-releng, and a lot of #fedora-*
Questions
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I accepted this nomination because I believe FESCo would benefit from fresh perspectives, and I think that these new perspectives will also help to lower the entrance barriers for Fedora.
Governance bodies stay healthy when they welcome new voices alongside experienced members, and I want to be part of that renewal.
Technologies like eBPF are redefining what’s possible in Linux–observability, security, networking–but they also bring packaging challenges that we haven’t fully solved, such as kernel version dependencies, CO-RE relocations, BTF requirements, and SELinux implications.
On FESCo, I want to help Fedora stay ahead of these challenges rather than merely reacting to them. I want to advocate for tooling and guidelines that will help make complex kernel-dependent software easier to package.
How do you currently contribute to Fedora? How does that contribution benefit the community?
I founded and currently lead the Fedora eBPF Special Interest Group. Our goal is to make eBPF a first-class citizen in Fedora, improving the experience for the developers who are building observability, security, and networking tools and figuring out how to package software that has deep kernel dependencies.
On the packaging side, I maintain bpfman (an eBPF program manager) and several Rust crates that support eBPF and container tooling. I’ve also learned the hard way that Rust dependency vendoring is… an adventure.
Before Fedora, I spent years in the OpenStack community. I served as PTL (Project Team Lead) for the Kuryr project, the bridge between container and OpenStack networking and was active in the Kubernetes SIG. That experience taught me a lot about running open source projects: building consensus across companies, mentoring contributors, managing release cycles, and navigating the politics of large upstream communities.
I try to bring that same upstream, community-first mindset to Fedora. My hope is that the patterns we establish in the eBPF SIG become useful templates for other packagers facing similar challenges.
How do you handle disagreements when working as part of a team?
I start by assuming good intent. If someone is in the discussion, it’s because they do also care about the outcome, even though they may have another point of view.
I also try not to speculate about why someone holds a particular view. Assigning motives derails technical conversations fast. Instead, I focus on keeping things facts-driven: what does the code actually do, what do users need, what are the real constraints? Egos don’t ship software, and sticking to concrete data keeps discussions productive.
When disagreements persist, I find it helps to identify what everyone does agree on and use that as a new starting point. You’d be surprised how often this unblocks a stalled conversation.
Also, I think that it’s important to step back. It’s tempting to want the final word, but that can drag things on forever without real progress. Miscommunication happens and not every discussion needs a winner.
What else should community members know about you or your positions?
I believe in Fedora’s Four Foundations: Freedom, Friends, Features, First. What draws me to this community is the “Friends” part: there’s a place in Fedora for anyone who wants to help, regardless of background or technical skill level. Open source is at its best when it’s genuinely welcoming, and I want FESCo to reflect that.
From my time in the OpenStack community, I learned that healthy projects focus on protecting, empowering, and promoting: protecting the open development process and the values that make the community work; empowering contributors to do great work without painful barriers; and promoting not just the software, but the people who build and use it. I try to bring that mindset to everything I do.
I also believe strongly in working upstream. The changes we make should benefit not just Fedora users, but the broader open source ecosystem. When we solve a hard problem here, that knowledge should flow back to upstream projects and other distributions.
I’ll be at FOSDEM 2026. FOSDEM embodies what I love about open source: a non-commercial space where communities meet to share knowledge freely. If you’re there, come say hi.
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
Interview with Kevin Fenzi
FAS ID: kevin
Matrix Rooms: I’m probibly most active in the following rooms. I’m available and answer notifications and watch many other channels as well, but those 3 are the most active for me:
noc -> day to day infra stuff, handling alerts, talking with other infra folks
admin -> answering questions, helping fix issues, some team discussions
releng -> release engineering team discussions, answering questions, handling issues, etc.
Questions
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I think I still provide useful historical information as well as being able to pull on that long history to know when things are good/bad/have been tried before and have lessons to teach us.
Based on the proposals we approve or reject we can steer things from FESCo. I do think we should be deliberate, try and reach consensus and accept any input we can get to try to come to good decisions. Sometimes things won’t work out that way, but it should really be the exception instead of the rule.
How do you currently contribute to Fedora? How does that contribution benefit the community?
I’m lucky to be paid by Red Hat to work on infrastucture, I like to hope it’s useful to the community In my spare time I work on packages, answering questions where I can, unblocking people, release engineering work, matrix and lists moderation.
I really hope my contributions contribute to a happier and more productive community.
How do you handle disagreements when working as part of a team?
I try and reach consensus where possible. Sometimes that means taking more time or involving more people, but If it can be reached I think it’s really the best way to go.
Sometimes of course you cannot reach a consensus and someone has to make a call. If thats something I am heavily involved in/in charge of, I do so. I’m happy that we have a council as a override of last resort in case folks want to appeal some particularly acromonious decision. Also, as part of a team you have to sometimes delegate something to someone and trust their judgement in how it’s done.
What else should community members know about you or your positions?
I think there’s been a number of big debates recently and probibly more to come. We need to remember we are all friends and try and see things from other people’s point of view.
My hero these days seems to be treebeard: “Don’t be hasty”
My matrix/email is always open for questions from anyone…
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
Interview with Fabio Alessandro Locati
FAS ID: fale
Matrix Rooms: I can be easily found in #atomic-desktops:fedoraproject.org, #bootc:fedoraproject.org, #coreos:fedoraproject.org, #devel:fedoraproject.org, #epel:fedoraproject.org, #event-devconf-cz:fedoraproject.org, #fedora:fedoraproject.org, #fedora-arm:matrix.org, #fedora-forgejo:fedoraproject.org, #fosdem:fedoraproject.org, #flock:fedoraproject.org, #golang:fedoraproject.org, #iot:fedoraproject.org, #meeting:fedoraproject.org, #meeting-1:fedoraproject.org, #mobility:fedoraproject.org, #python:fedoraproject.org, #rust:fedoraproject.org, #silverblue:fedoraproject.org, #sway:fedoraproject.org, #websites:fedoraproject.org
Questions
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I have been part of the Fedora community for many years now: my FAS account dates back to January 2010 (over 15 years ago!), and I’ve contributed in many different roles to the Fedora project. I started as an ambassador, then became a packager and packaging mentor, and joined multiple SIGs, including Golang, Sway, and Atomic Desktop. For many years, I’ve been interested in immutable Linux desktops, Mobile Linux, and packaging challenges for “new” languages (such as Go), which are also becoming more relevant in the Fedora community now. Having contributed to the Fedora Project for a long time in many different areas, and given my experience and interest in other projects, I can bring those perspectives to FESCo.
How do you currently contribute to Fedora? How does that contribution benefit the community?
Currently, many of my contributions fall in the packaging area: I keep updating the packages I administer and exploring different solutions for packaging new languages and maintaining the Sway artifacts. My current contributions are important to keeping Fedora first, not only in terms of package versions but also in terms of best practices and ways to reach our users.
Additionally, I served for the last two cycles (F41/F42) as a FESCo member, steering the community toward engineering decisions that were both sensible in the short and long term.
How do you handle disagreements when working as part of a team?
I think disagreements are normal in communities. I have a few beliefs that guide me in entering and during any disagreement:
I always separate the person from their argument: this allows me to discuss the topic without being influenced by the person making the points.
I always keep in mind during disagreements that all people involved probably have a lot of things they agree on and a few they don’t agree on (otherwise, they would not be part of the conversation in the first place): this allows me to always see the two sides of the disagreement as having way more in common than in disagreement.
During a discussion, I always hold the belief that the people arguing on the opposite side of the disagreement are trying to make sure that what they believe is right becomes a reality: this allows me always to try to see if there are aspects in their point of view that I had not considered or not appropriately weighted.
Thanks to my beliefs, I always manage to keep disagreements civil and productive, which often leads to a consensus. It is not always possible to agree on everything, but it is always possible to disagree in a civil, productive way.
What else should community members know about you or your positions?
Let’s start with the fact that I’m a Red Hat employee, though what I do in my day job has nothing to do with Fedora (I’m an Ansible specialist, so I have nothing to do with RHEL either), so I have no ulterior motives for my contributions. I use Fedora on many devices (starting from my laptop) and have done so for many years. I contribute to the Fedora Project because I found in it and its community the best way to create the best operating system :).
I’ve been using Sway exclusively on my Fedora desktop since I brought it into Fedora in 2016. On the other systems, I use either Fedora Server, Fedora CoreOS, or Fedora IoT, even though lately, I prefer the latter for all new non-desktop systems.
I see the Fedora Community as one community within a sea of communities (upstream, downstream, similarly located ones, etc.). I think the only way for all those communities to be successful is to collaborate, creating a higher-level community where open-source communities collaborate for the greater good, which, in my opinion, would be a more open-source world.
You dropped by the Fedora booth at SCaLE 23x!
I am happy to share that as of 10 February 2026, Fedora is now available in Syria. Last week, the Fedora Infrastructure Team 
Speak now..."
arecord -f S16_LE -r 16000 -d 5 -q "$AUDIO"
# Step 2: Transcribe using whisper.cpp
TRANSCRIPT=$(./whisper.cpp/build/bin/whisper-cli \
-m ./whisper.cpp/models/ggml-base.en.bin \
-f "$AUDIO" \
| grep '^\[' \
| sed -E 's/^\[[^]]+\][[:space:]]*//' \
| tr -d '\n')
echo "
$TRANSCRIPT"
# Step 3: Get relevant context from RAG database
echo "
Searching documentation..."
CONTEXT=$(uv tool run --python 3.12 docs2db-api query "$TRANSCRIPT" \
--format text \
--max-chars 2000 \
--no-refine \
2>/dev/null || echo "")
if [ -n "$CONTEXT" ]; then
echo "
Found relevant documentation:"
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -"
echo "$CONTEXT"
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -"
else
echo "
$RESPONSE_CLEAN"
# Step 7: Speak the response
echo "$RESPONSE_CLEAN" | espeak
Freedom (The Open Frontier)
Friends (Our Fedora Story)
Features (Engineering Core)
First (Blueprint for the Future)
You were involved in combating the Matrix spam attacks in 2025!
You dropped by the Fedora booth at FOSDEM '27
You gathered in Brussels (2026-01-31) or Pasadena (2026-03-06) to plant the seeds of Fedora Project's future over dinner.
You connected with CentOS in 2026
You attended the 2026 iteration of DevConf.IN, an annual free and open source conference in India!
Submit to the Flock 2026 CFP
You got a "Change" accepted into the Fedora 47 Change list
You got a "Change" accepted into the Fedora 46 Change list
You got a "Change" accepted into the Fedora 45 Change list
You got a "Change" accepted into the Fedora 44 Change list
You got a "Change" accepted into the Fedora 43 Change list
