Fedora People

Fedora Infrastructure Status: Updates and reboots on Fedora infrastructure

2026-08-20T20:00:00+00:00

Fedora Magazine: Test Days for Fedora 45: Help Us Test the Big Changes

2026-08-14T17:22:24+00:00

Fedora 45 has several system-level changes that need testing on real hardware. The first test day up is GNOME 51, starting on 17 August, with more events planned for RPM 6.1, installation media and others. You can participate with a VM for most tests; some hardware-specific testing is more useful on a real machine.

Details are contained in this article.

Fedora 45 is bringing several changes that deserve testing beyond CI and automated test suites. Here are some of the bigger ones:

RPM 6.1: update to 6.1, enforced signature checking, and DNF repo configs relocating to /usr.
OpenSSL 4.0 — a major version bump that could affect anything doing TLS.
Boot and live media are being rebuilt from scratch with image-builder. This changes how the images are produced, so we want to make sure they still boot and install correctly across a range of hardware and virtualization setups.
kmscon replaces the kernel VT console (fbcon) as the default.
Python 3.15, GRUB EFI for Confidential Computing, and more.

Why we need community testing

Automated tests catch regressions in known scenarios, but they won’t tell us if the new boot.iso works on your particular laptop, or if enforced RPM signature checking breaks a workflow nobody on the team thought of. We need people trying this on real machines and in real scenarios.

That’s what test days are for. A few days focused on a specific change, developers on Matrix to help debug, and anyone can show up and run through the test cases. You don’t need to be a Fedora QA expert. If you can install Fedora, reproduce a problem and report what happened, you can help.

What we’re planning for F45

At our July 20 Quality meeting (transcript), we went through the ChangeSet and picked out the changes that would benefit most from community testing. That turned into a planning ticket on Forge with individual tickets for each event.

GNOME 51 Desktop — August 17-21 is the first test day this cycle and it’s happening right now . Desktop, graphics, peripherals, core applications. If you’re reading this in time, jump in. (#GNOME_51_Desktop)

I18n test week —September 7-13 input methods, locales, keyboard layouts. . (#924)

RPM 6.1 — NSS support for user/group lookups is back, queries work again during transactions, new macro modifiers for packagers, and better rpmkeys verification output. Looks like a smooth update, but RPM touches everything — worth making sure nothing slipped through. (#917)

Installation media — boot.iso and live images, physical hardware, VMs. Try booting the new images on whatever hardware you have. Does the installer work? Does the live environment behave? (#9 18)

KDE — likely KDE 6.7. (#922)

Cockpit — it’s been years since the last Cockpit test day. (#920)

GRUB EFI / Confidential Computing — relevant mainly to specific hardware and VM environments. (#919)

The list isn’t final. We’re still looking at kmscon, OpenSSL 4.0, CoreOS, and Kernel 7.2. Keep an eye on testdays.fedoraproject .org for the current schedule.

What kind of testing helps most

Try upgrading your system to the latest packages. Boot the new boot.iso on physical hardware. Test suspend/resume, Wi-Fi, external displays, NVIDIA/AMD/Intel graphics, or whatever hardware you actually use. Each test day has a wiki page with specific test cases, but your own daily workflows are often where the interesting bugs hide.

You need a Fedora Account to report results. Pick a test day from the schedule, follow the wiki instructions, report through the test day app, and if you find something odd, come talk to us on Matrix in #test-day:fedorapr oject.org.

The test day app itself is open source at quality/testdays-web on Forge. If something about it bugs you or you have an idea, file a ticket.

Propose a test day

This doesn’t all have to come from us. If you maintain a package with a big change in F45, or you see something in the ChangeSet that you think needs broader testing — propose a test day. Create a ticket at forge.fedoraproject.org/quality/tickets, tag it “test days”, and tell us what you’d like to test. You don’t need test cases or wiki pages ready. The QA team will help with that.

Testing beyond test days

Test days are focused events around specific changes, but testing Fedora is something you can do any day. fedora-easy-karma is a CLI tool that picks up testing updates already installed on your system and lets you submit karma to Bodhi right from your terminal. See the installation instructions to get started. Like the test day app, it’s an open source project hosted on Forge — feel free to report issues or suggest features.

Links

Catch you in #test-day on Matrix.

Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own.

Fedora Infrastructure Status: Fedora Copr outage

2026-08-12T07:30:00+00:00

Fedora Infrastructure Status: Fedora 45 Mass Branching

2026-08-11T14:00:00+00:00

Fedora Magazine: Monitor Your Drive Health with Performance Co-Pilot on Fedora

2026-08-10T08:00:00+00:00

You wake up one morning to find your home server unresponsive, after some investigation you discover a failed NVMe drive taking your self-hosted services and data with it. Perhaps you’re a system administrator and a workstation’s SSD has been silently accumulating errors for months, and now a user is reporting corrupted files.

Drive failures are rarely instant, they give subtle warnings (through rising temperatures, increasing error counts, and wear indicators) but only if you’re watching. Most people will only check on disk health after problems start, by then it may be too late.

Performance Co-Pilot (PCP) is an open source framework for collecting, monitoring, and analyzing system performance metrics. Recent updates have expanded its drive monitoring capabilities with:

SMART metric collection for HDDs, SSDs, and NVMe drives
NVMe error log decoding with human-readable error messages
WWID-based drive tracking that survives device name changes across reboots
Seagate FARM telemetry for extended vendor-specific diagnostics

In this post, you’ll set up PCP drive monitoring on Fedora, learn which metrics matter most, and build a Grafana dashboard to visualize your drive health over time.

Prerequisites

To follow along, you’ll need:

Fedora Workstation or Server (Fedora 39 or later recommended)
Root or sudo access for installing packages and PMDAs
smartmontools installed (PCP’s SMART agent depends on smartctl)

You can verify smartmontools is available:

$ rpm -q smartmontools

If it’s not installed:

$ sudo dnf install smartmontools

What is SMART?

SMART (Self-Monitoring, Analysis and Reporting Technology) is a monitoring system built into modern hard drives, SSDs and NVMe devices. SMART continuously tracks indicators like wear leveling, error rates, temperature and power-on hours. These are reliability metrics that can help point towards impending failures.

Most people only check SMART data once, using tools like smartmontools (smartctl -a /dev/sda) and only when they already suspect a problem. That approach only gives you a single snapshot. PCP takes a different approach: its SMART agent collects these metrics continuously in the background, building historical trends that you can analyze.

Did your drive’s temperature spike yesterday during a large file transfer? Has your NVMe wear indicator increased from 5% to 15% over the past six months? Continuous monitoring catches these patterns. Drive failures rarely happen without warning, clues are given through SMART values that shift over time.

Installing and enabling PCP with the SMART PMDA

Getting started is straightforward. Install the required packages:

$ sudo dnf install pcp pcp-pmda-smart

The pcp-pmda-smart package provides the SMART monitoring agent. Next, install the PMDA (Performance Metrics Domain Agent):

$ cd /var/lib/pcp/pmdas/smart/
$ sudo ./Install

The installer will prompt for configuration options. The defaults work well for most setups, so press Enter to accept them.

Start and optionally enable the PCP collector daemon:

$ sudo systemctl start pmcd
$ sudo systemctl enable pmcd

Verify the SMART metrics are available:

If you see metrics listed, you’re ready to go.

Querying SMART metrics

Now that monitoring is running, let’s look at the metrics that matter most.

Temperature

Drive temperature is one of the easiest health indicators to track. Query it with:

$ pminfo -ft smart.attributes.temperature_celsius.value

For NVMe drives, use:

$ pminfo -ft smart.nvme_attributes.temperature_sensor_one

As a general guideline: sustained temperatures above 60 °C for HDDs or 70 °C for SSDs and NVMe drives indicate potential cooling problems. Consistent high temperatures accelerate wear and reduce drive lifespan.

To watch temperatures update in real time (every 5 seconds):

$ pmrep -t 5s smart.nvme_attributes.temperature_sensor_one smart.attributes.temperature_celsius.value

Press Ctrl+C to stop.

Wear and age indicators

Every drive has a finite lifespan. These metrics help you track where a drive is in its lifecycle.

Power-on hours tracks total runtime:

$ pminfo -ft smart.attributes.power_on_hours.value
$ pminfo -ft smart.nvme_attributes.power_on_hours          # NVMe

A drive with 50,000 hours (roughly 5.7 years of continuous operation) is significantly older than one with 5,000 hours.

Power cycle count shows how many times the drive has been powered on and off:

$ pminfo -ft smart.attributes.power_cycle_count.value
$ pminfo -ft smart.nvme_attributes.power_cycles             # NVMe

Excessive power cycling can accelerate mechanical wear in HDDs and contribute to flash cell wear in SSDs.

For NVMe drives, smart.nvme_attributes.percentage_used is the most important wear metric. It runs from 0 to 100%, reflecting the drive’s consumed endurance. Above 80% means significant wear. Above 90%, start planning a replacement.

$ pminfo -ft smart.nvme_attributes.percentage_used

Critical error metrics

These are the metrics you hope stay at zero. Any non-zero value or an increasing trend points to physical drive problems.

Reallocated sector count shows bad sectors that the drive has detected and remapped to spare areas. Modern drives reserve sectors for this purpose but once remapping starts it signals deteriorating media:

$ pminfo -ft smart.attributes.reallocated_sector_count.value

Current pending sector count tracks sectors waiting to be remapped. A non-zero value suggests the drive is actively struggling with bad areas:

$ pminfo -ft smart.attributes.current_pending_sector.value

For a quick overview of all drives at once:

$ pmrep -s 1 smart.health smart.attributes.temperature_celsius.value smart.nvme_attributes.temperature_sensor_one smart.nvme_attributes.percentage_used

WWID-based drive tracking

A common challenge with drive monitoring is that device names can change. Your NVMe drive might be /dev/nvme0n1 today but after a reboot or BIOS update it could become /dev/nvme1n1. Hot-plugging USB drives or adding new storage can also shuffle device assignments.

PCP solves this with the smart.wwid.* metric namespace. WWID (World Wide Identifier) is a unique identifier assigned to each drive during manufacturing. It never changes regardless of how the operating system names the device.

Here’s the difference in practice:

The WWID-based namespace is particularly useful for multi-drive setups (home lab servers, workstations with external drives, or laptops with docking stations). Your monitoring history stays consistent even when device names don’t.

NVMe error log collection

Beyond standard SMART attributes, NVMe drives maintain a detailed error log (log page 0x01) that records every error event the drive encounters. The SMART PMDA can collect and decode these logs giving you visibility into issues that basic SMART counters won’t reveal.

While smart.nvme_attributes.media_and_data_integrity_errors gives you a count, the error log tells you what happened, when it happened, and where on the drive it occurred. Each log entry includes:

Error type and status code
Command that triggered the error
Logical block address (LBA) of the failure
Namespace and submission queue information
Timestamp of the error event

This level of detail helps diagnose intermittent problems. Maybe your NVMe drive only throws errors under specific workloads or errors cluster in a particular address range.

Query the error log metrics:

$ pminfo -ft smart.nvme_error_log

The most important metric is smart.nvme_error_log.error_count which should be zero on a healthy drive. If you see non-zero values, check smart.nvme_error_log.status_code for human-readable error descriptions. Common error codes include:

Data Transfer Error: Problem reading or writing data
Internal Device Error: Controller or firmware issues
Aborted Command: Command was cancelled or timed out
Write Fault: Write operation failed

Recurring errors, especially with the same status code or affecting the same LBA range indicate a real problem that needs attention.

FARM log support for Seagate drives

If you have Seagate drives, PCP offers additional monitoring through the FARM (Field Accessible Reliability Metrics) PMDA. FARM is Seagate’s extended monitoring that goes beyond standard SMART, providing deeper insights into drive behavior.

What FARM provides

FARM logs capture operational data that SMART doesn’t track:

Power metrics: Per-head write power hours, total power-on hours with finer granularity
Error history: Read and write error rates broken down by head and zone
Performance data: Command latency statistics, queue depth tracking
Environmental history: Temperature trends over the drive’s lifetime, humidity exposure
Workload patterns: Sequential vs. random I/O ratios, read/write balance
Head-specific statistics: Individual read/write head performance (for HDDs)

Setting up the FARM PMDA

FARM support works for both SATA and SAS Seagate drives. Install and enable it:

$ sudo dnf install pcp-pmda-farm
$ cd /var/lib/pcp/pmdas/farm/
$ sudo ./Install

Query available FARM metrics:

$ pminfo farm | head -10
farm.smart_attribute.power_on_hours
farm.environment.current_temperature
farm.reliability.uncorrectable_read_errors
farm.reliability.uncorrectable_write_errors
...

FARM is especially useful for tracking long-term health trends, diagnosing subtle issues not visible in basic SMART data and verifying that drive specifications match actual usage.

Note: FARM metrics are Seagate-specific. They won’t work with Western Digital, Samsung, or other manufacturers. For universal monitoring use the SMART PMDA covered earlier.

Visualizing with Grafana

PCP integrates with Grafana through the grafana-pcp plugin, letting you build dashboards that visualize drive health over time. This is where continuous monitoring pays off. You can spot trends, set up alerts and keep an eye on your entire fleet of drives from a single dashboard.

Installing the Grafana PCP plugin

Install Grafana and the PCP plugin:

$ sudo dnf install grafana grafana-pcp

Start the required services:

$ sudo systemctl start grafana-server pmproxy
$ sudo systemctl enable grafana-server pmproxy

Open Grafana in your browser at http://localhost:3000 (default credentials: admin/admin).

Before adding a datasource, you may need to enable the Performance Co-Pilot plugin. Go to Administration > Plugins and data > Plugins, search for Performance Co-Pilot, and click Enable. If the plugin is already enabled, you can skip this step.

Configuring the PCP Vector datasource

Go to Connections > Data sources > Add data source and select PCP Vector. The only required field is the URL:

http://localhost:44322

Click Save & Test to verify the connection.

Building drive monitoring panels

Below are panel configurations you can use in your dashboards. To add a panel, click Add > Visualization on any dashboard, select the PCP Vector datasource and enter the metric name in the query field.

Drive temperature timeseries panel:

This panel shows drive temperature over time, with color thresholds for warning levels.

{
  "type": "timeseries",
  "title": "Drive Temperature",
  "datasource": {
    "type": "pcp-vector-datasource",
    "uid": "PCP_VECTOR"
  },
  "targets": [
    {
      "expr": "smart.nvme_attributes.temperature_sensor_one",
      "format": "time_series"
    },
    {
      "expr": "smart.attributes.temperature_celsius.value",
      "format": "time_series"
    }
  ],
  "fieldConfig": {
    "defaults": {
      "unit": "°C",
      "thresholds": {
        "mode": "absolute",
        "steps": [
          { "color": "green", "value": null },
          { "color": "yellow", "value": 50 },
          { "color": "orange", "value": 60 },
          { "color": "red", "value": 70 }
        ]
      },
      "custom": {
        "thresholdsStyle": { "mode": "area" }
      }
    },
    "overrides": [
      {
        "matcher": { "id": "byType", "options": "number" },
        "properties": [
          { "id": "unit", "value": "°C" }
        ]
      }
    ]
  },
  "gridPos": { "h": 8, "w": 24, "x": 0, "y": 0 }
}

NVMe wear percentage gauge panel:

A gauge showing how much of each NVMe drive’s endurance has been consumed.

{
  "type": "gauge",
  "title": "NVMe Wear Level",
  "datasource": {
    "type": "pcp-vector-datasource",
    "uid": "PCP_VECTOR"
  },
  "targets": [
    {
      "expr": "smart.nvme_attributes.percentage_used",
      "format": "time_series"
    }
  ],
  "fieldConfig": {
    "defaults": {
      "unit": "percent",
      "min": 0,
      "max": 100,
      "thresholds": {
        "mode": "absolute",
        "steps": [
          { "color": "green", "value": null },
          { "color": "yellow", "value": 50 },
          { "color": "orange", "value": 80 },
          { "color": "red", "value": 90 }
        ]
      }
    },
    "overrides": [
      {
        "matcher": { "id": "byType", "options": "number" },
        "properties": [
          { "id": "unit", "value": "percent" }
        ]
      }
    ]
  },
  "gridPos": { "h": 6, "w": 8, "x": 0, "y": 8 }
}

Drive health status panel:

A stat panel showing the overall health assessment for each drive.

{
  "type": "stat",
  "title": "Drive Health Status",
  "datasource": {
    "type": "pcp-vector-datasource",
    "uid": "PCP_VECTOR"
  },
  "targets": [
    {
      "expr": "smart.health",
      "format": "time_series"
    }
  ],
  "fieldConfig": {
    "defaults": {
      "unit": "string",
      "mappings": [
        {
          "type": "value",
          "options": {
            "PASSED": { "text": "PASSED", "color": "green" },
            "FAILED": { "text": "FAILED", "color": "red" }
          }
        }
      ]
    },
    "overrides": [
      {
        "matcher": { "id": "byType", "options": "string" },
        "properties": [
          { "id": "unit", "value": "string" }
        ]
      }
    ]
  },
  "gridPos": { "h": 6, "w": 8, "x": 8, "y": 8 }
}

A complete, importable Grafana dashboard JSON file is provided alongside this post as pcp-drive-monitoring-dashboard.json. Import it via Dashboards > Import in Grafana.

Automated alerting with pmie

PCP includes pmie (Performance Metrics Inference Engine), a rule-based tool that evaluates metric expressions and triggers actions when conditions are met. Where Grafana dashboards require someone to be watching pmie can alert you automatically.

To start and optionally enable pmie:

$ sudo systemctl start pmie
$sudo systemctl enable pmie

Exploring metrics with pmie

Before writing alerting rules you can use pmie in verbose mode to view metrics from the command line. This is a useful way to get familiar with the syntax:

$ echo 'temp_check = smart.nvme_attributes.temperature_sensor_one;' | pmie -e -v -t 5second
temp_check (Mon Jun 30 10:15:01 2026): 35

temp_check (Mon Jun 30 10:15:06 2026): 35

temp_check (Mon Jun 30 10:15:11 2026): 36

Press Ctrl+C to stop. The -e flag shows the evaluated expression, -v shows values even when no action fires, and -t sets the evaluation interval.

You can add conditions and actions to turn this into a rule. Here’s an example that prints a message whenever an NVMe drive’s temperature is above 0 (effectively showing all drives):

$ echo 'temp_check = some_inst(smart.nvme_attributes.temperature_sensor_one > 0) -> print "NVMe temp:" " %i:%v";' | pmie -e -v -t 5second
Mon Jun 30 10:15:01 2026: NVMe temp: nvme0n1:35
temp_check (Mon Jun 30 10:15:01 2026): true

Mon Jun 30 10:15:06 2026: NVMe temp: nvme0n1:36
temp_check (Mon Jun 30 10:15:06 2026): true

The %i token expands to the instance name (the drive) and %v to the metric value.

Writing alerting rules

Now let’s create practical rules that alert on real problems. Save the following to /etc/pcp/pmie/smart-health.pmie:

// Alert if any NVMe drive temperature exceeds 70 °C
some_inst(smart.nvme_attributes.temperature_sensor_one > 70)
    -> syslog 10 min "NVMe drive temperature critical:" " %i at %v °C";

// Alert if any NVMe drive wear level exceeds 80%
some_inst(smart.nvme_attributes.percentage_used > 80)
    -> syslog 24 hour "NVMe drive wear level high:" " %i at %v%";

// Alert if any drive has reallocated sectors
some_inst(smart.attributes.reallocated_sector_count.value > 0)
    -> syslog 24 hour "Drive has reallocated sectors:" " %i with %v sectors";

The syslog action writes to the system log with the tag pcp-pmie. The time after syslog (e.g., 10 min, 24 hour) is a throttle that prevents repeated alerts, so you won’t flood your logs if a condition stays true.

Testing and running pmie rules

Test your rules from the command line first:

$ sudo pmie -v -c /etc/pcp/pmie/smart-health.pmie -t 10second

This evaluates the rules every 10 seconds and prints verbose output so you can see them firing. Once you’re happy with the rules you can run pmie as a persistent service. The system-wide pmie instance is managed by pmie_check and configured in /etc/pcp/pmie/control. Add an entry pointing to your rules file to have them evaluated continuously alongside the default PCP rules.

A complete smart-health.pmie rules file covering temperature, wear and error alerts for both NVMe and SATA drives is provided alongside this post in the conclusions section. Copy it to /etc/pcp/pmie/ to get started.

Other actions are available beyond syslog. Use shell to run arbitrary commands (such as sending an email or desktop notification), print for stdout output or chain actions with & to run multiple actions when a rule fires.

Continuous monitoring with pmlogger

pmlogger is a core utility included with PCP, and automatically logs metrics when running. To start it and enable it on boot:

$ sudo systemctl start pmlogger
$ sudo systemctl enable pmlogger

By default, pmlogger captures a broad set of system metrics. To ensure SMART drive metrics are included, run:

$ sudo pmlogconf -r /var/lib/pcp/config/pmlogger/config.default

When prompted, enable the S.M.A.R.T drive statistics [Linux] group. This ensures drive health metrics are captured continuously, allowing you to review historical trends using tools like pmchart, pmrep, or Grafana with the PCP Valkey datasource.

With pmlogger running, you build a historical record of your drive health. If a drive starts failing in six months, you can look back and see exactly when the warning signs began.

Conclusion

Drive failures give warnings, through SMART metrics, error logs and performance degradation. With PCP’s drive monitoring capabilities you have the tools to catch these warnings before they become data loss.

In this post we covered setting up the SMART PMDA for universal drive health monitoring, interpreting key metrics like temperature, wear levels, error counts and tracking drives reliably with WWID-based identifiers. NVMe users can go deeper with error log collection and Seagate drive owners have access to extended FARM telemetry. Combined with Grafana dashboards and pmlogger you get continuous visibility into your drives’ health.

The key takeaway: continuous monitoring catches trends that one-time checks miss. A few minutes of setup today can save hours of recovery work (or worse, unrecoverable data loss) tomorrow.

For more information, visit the Performance Co-Pilot documentation and the grafana-pcp plugin documentation. The Grafana dashboard used in this post is available to download here and can be imported via Dashboards > Import in Grafana. The pmie alerting rules are also available to download here and can be copied to /etc/pcp/pmie/ for use with pmie.

Fedora Infrastructure Status: Migration of fedora-scm-requests from Pagure to Forgejo

2026-08-05T12:00:00+00:00

Fedora Magazine: Running Ollama Locally with Podman on Fedora Linux

2026-08-05T08:00:00+00:00

Running Large Language Models (LLMs) locally has become increasingly popular for development, privacy, and offline testing. Ollama makes this incredibly straightforward, allowing you to run models like Llama 3 or Mistral directly on your machine.

By leveraging Podman on Fedora Linux, you can isolate Ollama inside a container. This approach keeps your host system clean while making it effortless to spin up, manage, and tear down your AI development environment.

What is Ollama?

Ollama is an open-source framework designed for running, creating, and sharing large language models. It packages model weights, configuration, and data into a unified management system. Running it inside a container means you don’t have to deal with complex local dependencies, Python environments, or complex GPU driver configurations on your base OS.

Verify or Install Podman

Podman is available by default in Fedora Workstation. It can be easily install, if missing, using DNF:

$ sudo dnf install podman -y

For Fedora Linux Silverblue users, Podman is natively available in the immutable base system and no extra steps are necessary.

To verify your installation and ensure everything is running smoothly, execute a quick check:

$ podman --version

Step 1: Create a Persistent Volume for Your Models

LLM weights can be huge—often ranging from 4 GB to over 40 GB, depending on the model size. To avoid downloading these models every time you restart your container, create a persistent Podman volume to store them safely on your host disk:

$ podman volume create ollama_storage

Step 2: Run the Ollama Container

Next, spin up the Ollama container. The following command pulls the official image, attaches the volume we just created, and maps the communication port (

11434

) to your host machine.

$ podman run -d \
  -v ollama_storage:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Note on Hardware Acceleration

The command above runs Ollama using your CPU. If you are on Fedora Workstation or Silverblue and want to pass through an Nvidia GPU for fast hardware acceleration, make sure you have the Nvidia Container Toolkit installed and append the GPU flag:

--device nvidia.com/gpu=all

Step 3: Download and Run an AI Model

With the container running in the background, you can interact with it using Podman’s execution command. Let’s pull and run Llama 3, a highly capable, lightweight model perfect for local development:

$ podman exec -it ollama ollama run llama3

The first time you execute this, Podman will download the model weights into your

ollama_storage

volume. Once the download completes, you will be dropped directly into an interactive terminal prompt:

>>> Send a message (/? for help)
>>> Tell me a fun fact about Fedora Linux.
Fedora Linux is named after the iconic felt hat worn by the Red Hat shadowman logo! It started as a community project to provide extra packages for Red Hat Linux.

>>>
To exit the interactive prompt, simply type /exit.

Step 4: Interact with the Local API

Because we mapped port 11434 to our host system, you can also interact with your local Ollama instance via its built-in REST API. Open a standard terminal window and send a curl request:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Why use containers?",
  "stream": false
}'

This returns a structured JSON payload containing your answer, allowing you to easily hook your local model up to web apps, scripts, or IDE extensions.

Checking Container Status

To monitor your running local AI instance, use the classic Podman management commands, perhaps starting with:

$ podman ps

You can also inspect the logs to make sure the API server is listening properly:

$ podman logs ollama

When you are done with your development session and want to free up system memory, stop the container:

$ podman stop ollama

If you ever need to completely remove the container environment, use:

$ podman rm ollama

Note: Your downloaded models are completely safe inside the ollama_storage volume and will instantly reattach the next time you spin up the container.

Conclusion

Using Podman to manage Ollama on Fedora Linux or Fedora Silverblue offers a clean, containerized way to build and test applications with LLMs completely offline. It bypasses host environment pollution, isolates large model storage cleanly into a named volume, and treats your AI stack exactly like any other microservice.

Fedora Badges: New badge: FrOSCon 2026 Attendee !

2026-08-05T04:49:30+00:00

Fedora Magazine: Developing with Fedora, first flock, and not the last!

2026-08-03T08:00:00+00:00

Flock 2026 was my first Fedora conference, and it won’t be my last. I came home with new ideas, new friendships, and even a new project to work on for next year.

Appreciation

I want to start by appreciating the Flock organizers and volunteers. Putting together an event like this takes a lot of quiet, unglamorous work, and it showed in how smoothly everything ran. Thanks for that!

I’d also like to thank the event sponsors. Their support makes it possible for contributors from all over the world to come together, learn from one another, and strengthen the Fedora community.

I also want to appreciate my mentor, Jona, for pushing and supporting me until I finally made it. And a big thank you to Fedora for the sponsorship that got me there.

This year I also got to be part of the Mentor Summit organizing team myself and helped put together the very sessions I used to just attend as a newcomer. Full circle moment here

It has always felt rewarding to contribute to something I love, and Fedora has always been one of my favorite communities. Along the way, I’ve made great friends and met many wonderful people.

Finally, I’d like to thank the Nairobi GNU/Linux Users Group for supporting Fedora’s Recognition Program this year by sponsoring the trophies and keychains. It was great to see our local community play a part in recognizing Fedora contributors, and I hope it’s the beginning of a lasting tradition.

Our winners this time were; Fabio Valentini, Justin Forbes and Ankur Sinha in that order. Congratulations to you, and keep going You might want to hear from them in our podcast Fedora Contributor Recognition Program 056.

Diversity, Equity and Inclusion

Cornelius with Matt, Jona, and Akash, celebrating time together at Flock 2026.

I love how Fedora is so supportive of people from under-represented groups. Being at Flock felt like a reward for the work I’ve been doing with the community too – I had been organizing and mentoring from home. Being there in person and seeing that my work was appreciated meant a lot.

This is what I love about Fedora: it’s welcoming, and it lives by the Four Foundations every day.

I also believe the in-person inclusive checklist I worked on last year helped make this year’s event a success. I loved the venue – I guess that’s why we went back to the same place as last year.

Honestly, I’d say everything was perfect. So hey, Flock organizers – the venue was perfect.

View of the Flock 2026 venue, which hosted the conference sessions

The talks

There was so much to take in: design, the mentor summit, docs and the docs initiative, lessons from FOSDEM and SCaLE, and so much more.

There was also the fbrnch workshop, Fedora data and analytics, and honestly too many good sessions to list them all here.

If there’s one thing I keep learning about this community, it’s that nothing happens unless you ask. People, or I would say, I personally don’t wait to be picked here, I just find ways to engage, go deep, and just ask, ask, ask. I wanted to help with speaker logistics this year for Fedora Linux 44 release party, so while I was checking open tickets, I found it and asked if I could manage it. And I did it. I know some people might hesitate to just raise their hand like that, but Fedora is always welcoming, and honestly, we can always use the support. Get involved, it feels good to contribute to something you love.

Funny enough, a friend paid me a compliment (I think?) that I know how to navigate open-source communities and always find something to do. I’m still not sure if that’s just a “community person” thing, or if it’s because I genuinely like understanding people and learning new things. Maybe both.

Candy Swap

The candy swap – I totally loved this! Super awesome idea. Sorry to disappoint that I couldn’t find time to bring anything, but I promise I will next time.

Mentor Summit

This was the 5th edition of the Fedora Mentor Summit, and it packed a lot into a few days. Lunch & Learn sessions ran across all three days, the informal, team-themed gatherings where you could step out of your usual circle and sit with people from Docs, Infra, Marketing, Packaging, Design, wherever you wanted to learn something new. No pressure, just conversation over food.

There was also a sticker-matching icebreaker, and everyone got a Fedora mascot sticker at registration, and the game was to go find your match and have a chat with them about anything open source.

Being on the organizing side of this for the first time gave me a whole new appreciation for how much quiet coordination goes into making something feel effortless for the people attending. Read more about how Mentor Summit came together here.

The hallway track

This is where the real magic happens. Daniel gave a brief, informal talk about eBPF, and honestly, that conversation ended up being one of the best parts of the whole trip.

I got to connect and meet team members, make new friends, and it was exciting just to sit and learn from them in a way a formal talk doesn’t always allow.

And out of that hallway conversation, I actually found another thing to do within Fedora. I have a project I’m hoping to finish and present at the next Flock – mentored by Daniel on eBPF. (Putting this here for accountability, so you can hold me to it. )

I keep meeting super kind, good Fedora friends who are willing to mentor and give their time. It says a lot about how welcoming this community really is.

Everyone I met was kind, and always down to talk about their experiences and their love for open source – and how they hope more people get to know it, try free software, and enjoy it wherever they are, in their own languages. That last part is thanks to the i18n and translation teams across open source communities, doing work that often goes unnoticed.

Being early in my career, of course I had to ask people how they got in. I won’t turn this into a rant, but if I had to summarize the advice: be a problem solver, and contribute to what you believe in – something you enjoy or find genuinely interesting.

*Thanks for reading this far. What’s below isn’t a big deal – just the city.*

The city

I extended my stay by 3 days to explore Prague. I took so many pictures my phone storage nearly gave up on me – I found almost everything lovely and fantastic. I’ll link one of my best shots of the museum and the city below.

Thanks to my friend MatH for being my tour guide!

I totally loved it. It says something that the organizers knew just how magnificent this city is, and believed we’d love it again – and they were right.

A view framed through glass and reflection from the museum rooftop in Prague.

Gothic twin spires over the old town square in Prague.

Stone statues against a blue sky with clouds in Prague.

I wish I could include every beautiful photo I took, but for now, these few will have to tell the story.

Take away

Every day with Fedora, I get to know more about open source, and I get to give back to my community back home.

I am Fedora

If any of this made you curious, here’s where to start: come join us in Fedora Join SIG, or if you’re just getting started, the Beginner’s Guide is the friendliest place to land.

Your Friend in Open Source, and Open-Source Freedom Fighter.

Fedora Community Blog: Fedora Forge Usage Policy

2026-07-30T12:11:59+00:00

After extensive review and discussion on the ticket request and in recent council meetings (see meetbot for 29 July and 15 July 2026), the Fedora Council would like to initiate the policy change policy process for ratifying the Fedora Forge Usage policy. This document is open to public feedback (if any) for a minimum of two weeks. If there are no significant changes to be made to the policy based on community feedback after Thursday, 13 August 2026, this policy will go to a formal ticket vote for Council to approve or reject.
If there are significant changes to be made to the document, Council will review the policy and, if necessary, extend the feedback period before calling for an official vote. Please provide feedback on the discussion post.

The policy can be found on the Council wiki page in Fedora Forge, posted on discourse, and pasted below here for convenience.

Thank you everyone for your contributions to this policy so far, and on behalf of the Council, we look forward to working with you all to ratify this policy soon.

Fedora Forge Usage Policy

Welcome to the Fedora Forge. This Forgejo instance is provided by the Fedora Infrastructure team to support the daily operations, development, and collaboration of the Fedora Project.

To ensure this service remains reliable, secure, and useful for everyone in the Fedora community, all users must adhere to the following usage policy.

1. Scope, Criteria, and Exceptions

The Fedora Forge is a dedicated workspace for the Fedora Project. Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.

The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is not a public, general-use Git hosting provider. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.

Criteria for “Fedora Project Related”

To qualify for hosting on the Fedora Forge, a repository must meet at least one of the following criteria:

Infrastructure and Operations: Configuration management, deployment scripts, or tooling used by the Fedora Infrastructure team to run the project.
Release Engineering and Packaging: Tools, scripts, and templates used to build, compose, and distribute Fedora releases, editions, and spins.
Governance and Team Organization: Trackers, documentation, and collaborative spaces for official Fedora Teams, Special Interest Groups (SIGs), Working Groups, and Fedora Council initiatives.
Fedora-Specific Software: Software projects conceptualized and developed primarily to serve the Fedora community (e.g., Fedora Badges, Bodhi, fedmsg).

Exceptions and Special Cases (Ecosystem Upstreams)

While general upstream development should happen on public forges (like GitHub, GitLab, or Codeberg), the Fedora Project recognizes that certain large-scale upstream projects are so deeply intertwined with Fedora’s infrastructure and history that they qualify as exceptions.

Recognized Exceptions:

Foundational infrastructure tools heavily maintained by Fedora and Red Hat ecosystem contributors (e.g., Koji, FreeIPA).
Core system components where the primary development team is historically rooted in the Fedora community and relies on Fedora Infrastructure for their workflow.

Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.

Decision Process for Edge Cases

If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:

Request Submission: The requester must open a ticket on the Fedora Infrastructure tracker, detailing the project’s purpose, its connection to Fedora, and why it should be hosted on the Fedora Forge rather than a public alternative.
Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.
Steering Committee Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) or the Fedora Council for a policy ruling.
Final Resolution: The decision will be documented in the ticket. If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.

2. Access and Authentication

Access to the Fedora Forge is integrated with our central identity systems to ensure secure and accountable access.

Account Creation and Login: All authentication is handled via the Fedora Account System (FAS). You cannot create a local account directly on the Forgejo instance. To log in, use the Single Sign-On (SSO) integration with your active FAS credentials.
Personal Namespaces: Upon your first login, a personal namespace (e.g., forge.fedoraproject.org/your-fas-username) is automatically provisioned for you. You can only fork repositories into this space, creation of new repositories is allowed only under Organization.
Organizations and Teams: To prevent organizational sprawl, the creation of top-level Organizations (e.g., /infra or /quality) is restricted. If your Fedora team or SIG needs a dedicated Organization space, please open a ticket with the Forge team. Organization owners are responsible for managing team access within their assigned space.
Account Deactivation: If your FAS account is suspended, disabled, or marked as inactive, your access to the Fedora Forge will be automatically revoked. Repositories hosted in your personal namespace may be archived or removed if your account remains inactive for an extended period. If you are leaving the project, please transfer ownership of any critical tools to a Fedora Organization or an active co-maintainer before your departure.

3. Code of Conduct and Community Behavior

The Fedora Forge is a collaborative space. All activity on this platform is strictly governed by the Fedora Code of Conduct.

4. Prohibited Activities

To ensure the Fedora Forge remains performant, secure, and legally compliant, the following activities and content are strictly prohibited:

Non-Fedora Projects: As stated in the scope, this Forge is not a general-purpose Git host. Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.
Malicious Content: Hosting malware, exploits, botnet command-and-control infrastructure, or phishing materials. (Note: Security-related tools strictly used for Fedora infrastructure testing must be explicitly approved).
Proprietary and Copyrighted Material: Uploading copyrighted materials you do not have the right to distribute, or hosting proprietary, closed-source binary blobs. All code should be open source and compliant with Fedora’s licensing guidelines.
Exposing Secrets: Committing sensitive information such as passwords, API tokens, private SSH keys, or Personally Identifiable Information (PII).
System Abuse: Engaging in activities that degrade the performance of the Forgejo instance or its runners, such as aggressive network scraping, DDoS attacks, or intentionally triggering infinite CI loops.
Cryptocurrency Mining: Using the Forge or its CI/CD runners to mine cryptocurrency is strictly forbidden and will result in an immediate, permanent ban.

5. Resource Limits and CI/CD

We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.

Repository Size: Git is not a backup system. Please keep repositories focused on source code and text-based documentation.
- Repositories should ideally remain under 500MB.
- If your project requires large assets (e.g., design files, test datasets), you must use Git LFS (Large File Storage).
Forgejo Actions and CI Runners:
- Shared Infrastructure: The default CI runners provided by Fedora Infrastructure are a shared community resource. Jobs should be optimized to run efficiently and are subject to a maximum timeout of 10 minutes per job.
- Community-Owned Runners (Bring Your Own): We highly encourage larger teams, SIGs, and Working Groups with extensive testing or specific architectural requirements (e.g., heavily utilizing ARM, RISCV, or requiring long build times) to provision and register their own runners. Dedicated runners can be attached directly to your Organization or specific repositories.
- Compliance for Custom Runners: Even if your team provides the compute resources, any runner connected to the Fedora Forge is an extension of our infrastructure. All workflows and actions executed on community-owned runners must strictly comply with Section 4 (Prohibited Activities). You may not use custom runners to bypass policy (e.g., no cryptocurrency mining, no building unrelated non-Fedora upstream projects, and no malicious network scraping).
- Registration Process: To register a dedicated runner for your team, please review our Runner Registration Docs and ensure your runner is secured according to Fedora Infrastructure standards.
API Usage: Automated scripts and bots interacting with the Forgejo API must respect rate limits and include descriptive user-agent strings identifying the tool and its maintainer.

6. Repository Lifecycle and Organization

Naming Conventions: We have a general naming convention, there should be tickets repository in your Organisation to have a single point of opening tickets relevant to your group. The docs repo in you organization should point to your groups official sources for docs.fedoraproject.org namespace. In other cases please use clear, descriptive names for repositories so other community members can easily understand their purpose.
Archiving: Projects that are no longer actively maintained should be archived (marked as read-only) to signal their status to the community. Active Forge organization owners should archive repos as necessary. If needed (e.g., in the case of an inactive organization), the Infrastructure team reserves the right to archive repositories that have seen no activity after trying to contact the organization owners.**.
Deletion: If you need an Organization or repository completely deleted, please open a ticket with the Forge team. The Infrastructure team also reserves the right to delete abandoned, non-compliant, or empty repositories to maintain a clean workspace.

7. Support and Abuse Reporting

Getting Help: For technical issues with the Fedora Forge (e.g., CI runner failures, login issues, requesting an Organization), please open a ticket on the Forge team tracker or ask in the #fedora-admin Matrix channel.
Reporting Code of Conduct Violations: To report a CoC violation occurring on the Forge, please contact the Fedora Code of Conduct Committee.
Reporting Security/Legal Issues: To report a security vulnerability on the platform, exposed secrets, or a DMCA/copyright violation, please immediately send an email to Fedora Infrastructure team.

The post Fedora Forge Usage Policy appeared first on Fedora Community Blog.

Fedora Magazine: Announcing the next Fedora Community Architect

2026-07-30T08:00:00+00:00

Evolution, change, and innovation are important parts of Fedora. This applies both to our open source technology and in how we sustain the community that builds it. As Fedora changes with the world around us, so too must the roles that support it. This includes the Fedora Community Architect role. Today, we (Justin & Shaun) are excited to share a strategic transition in how Red Hat supports Fedora’s community operations.

Effective as of time of publication, we are beginning a transition period for the Fedora C ommunity Architect (FCA) role. To continue our commitments to Fedora and CentOS, the Red Hat Open Source & AI Program Office is splitting the current, wide-reaching FCA responsibilities into two distinct, focused roles.

The Transition

We (being Justin & Shaun) will work in a transitional phase together from now until the release month of Fedora Linux 45, currently planned for October 2026. During this time, we will shift our focuses to ensure a smooth handoff for key community operations, including event logistics, budget management, and both Fedora Council and CentOS board representation.

Shaun McCance will step into the role of Fedora Community Architect. Many may already know Shaun as a longtime person in our community, bringing experience and context from GNOME, a major Fedora upstream project. He also brings significant experience in community event execution, budget management, and existing expertise as the CentOS Community Architect. He will take over the permanent FCA seat on the Fedora Council and Fedora Mindshare Committee, chair the Code of Conduct Committee, lead the annual planning of the Flock to Fedora conference, and continue the financial stewardship of our project resources.

Simultaneously, Justin Wheeler will transition into a new position: AI Alignment Community Architect. This role allows for a dedicated focus to align Fedora’s existing and future AI adoption with Fedora community values and norms. This gives more time and attention for him to participate in Fedora community discussions that explore a future with AI builder downstreams, this role will focus on formalizing community AI services, mentoring contributors, and ensuring that major AI-related initiatives in the default Fedora Linux experience align with Fedora’s Four Foundations: Freedom, Friends, Features, First.

What stays the same

While our day-to-day focuses are shifting, the biggest constant remains our shared commitment to Fedora and CentOS. We are both remaining deeply involved in our current communities through our work at Red Hat, and we are committed to ensuring this transition maintains the health and momentum of our ongoing community work.

This transition marks a strategic expansion of Red Hat’s investment in Fedora, rather than a departure. We are excited about this next chapter and the ability to dedicate more specific focus to both our foundational community operations and our emerging technical horizons.

We look forward to continuing this work with all of you through the Fedora Linux 45 release cycle and beyond. Thank you for your patience as we work through the transition.

Fedora Magazine: Flock 2026 Afterburn: a retrospective

2026-07-28T08:00:00+00:00

When I heard that Flock was the most awaited event every year for the Fedora community, and that I was going to be a part of it, I was genuinely excited. Gradually, I found myself involved right in the middle of Flock 2026 planning. Months of planning. Dozens of meetings. Meeting notes referenced and re-referenced every single week. New ideas, new proposals, sponsor packages, food logistics, team gifts, a candy swap, a games night, a Foundations Wall made of sticky notes and community feelings all of it building toward one event. Three days in Prague. That’s what Flock to Fedora is. And this year, Flock 2026 delivered.

This article is a brief summary and recap of what happened at Flock 2026 this year in Prague, Czechia. It covers my perspective as an intern in the Fedora community, working in the middle of all the action. Read on to know more about what happened at this year’s annual contributor conference!

Why this one stood out

Flock to Fedora 2026 ran from June 14–16 in Prague, Czechia, in the same city for the second time in a row. Sponsorship hit record numbers this year, with more unique sponsors committing to Flock than any past edition. A huge thank you to AlmaLinux, Arm, AWS, CentOS, Fleet, Framework Computers, Meta, Microsoft Azure, openSUSE, Red Hat, Rocky Enterprise Software Foundation, and Zabbix for making it possible.

The schedule this year was planned starting with “Day 0” (Sunday, June 14) with workshops and team meetups. Day 1 and Day 2 were about keynotes and streamed sessions built around Flock’s four themes:

Freedom (open hardware, AI, and open standards)
Friends (mentorship, onboarding, and community stories)
Features (packaging, infrastructure, and engineering excellence)
First (the road to Fedora Linux 45 and 46, which lay the groundwork for CentOS Stream 11 and EPEL 11)

Behind the execution of Flock, there was an incredible organizing team which handled everything from CfP logistics and on-site execution to design, travel coordination, website improvements, and a Matrix virtual experience that brought the conference to people who couldn’t make it to Prague in person (one like me). Planning kicked off months before the event, with weekly meet-ups, shared meeting notes, and sprint-by-sprint coordination across time zones and contributors. Flock doesn’t happen without these people.

Two community-driven additions gave Flock 2026 its own identity. The #CommitHistory interview campaign brought eight Flock speakers to Fedora Magazine, before the event even started, to share their first commit stories, contributor journeys, the very human reasons people keep showing up for this project, and why it really matters in this community. Also the Foundations Wall, a new interactive installation at the registration desk, asked attendees to share what Fedora’s Four Foundations mean to them on a whiteboard.

What the community said

The post-event survey closed on 8th July with 117 responses and a 57.35% response rate. The results told a clear story. Nearly every single respondent said they felt more connected to the Fedora community after attending Flock in-person. In a community that does most of its work asynchronously across time zones, mailing lists, and Matrix channels, that response is everything.

The hallway track rated highest of all. Above the keynotes, above the workshops, above the sessions. The informal conversations, that’s what people came for. One respondent put it perfectly:

“Flock is starting to feel like a family gathering, but a good one.”

Sessions were rated valuable or extremely valuable by 92% of respondents. The venue and organization scored Excellent or Good from 97% of respondents. The reception night, the candy swap, the games night on Day 0, all of it landed warmly in the open responses.

The constructive feedback? Noise levels made hallway conversations harder than they needed to be. People wanted more unstructured hacking space. Virtual attendees wanted clearer navigation instructions for the online experience. As the organizing team begins to review the data and compare against our own feedback, we hope to take these ideas for improvements into the next edition of Flock.

What happened after Prague

The real measure of Flock is never the event alone. Another big part is what contributors do once they get home.

In the 30 days since Prague, the conversations that started in corridors have continued in Fedora Discussion threads. A fuller picture of survey responses and feedback will be part of a future Fedora Council town hall video meeting later this summer.

See you in 2027!

Survey respondents have spoken on what comes next. The organizing team is processing the feedback as we begin setting our sights on the next edition.

Flock 2027 is coming. And honestly? This time I’m hoping to be there in person. Fingers crossed.

Fedora Infrastructure Status: Authentication degraded

2026-07-27T22:00:00+00:00

Fedora Infrastructure Status: accounts.fedoraproject.org degraded

2026-07-24T22:00:00+00:00

Fedora Community Blog: End of Community update

2026-07-24T12:00:00+00:00

Last few years a small team of people in the CLE Team were working each week to prepare a Community update for you. First one published on October 21st 2021. We were starting with only Infrastructure and Release Engineering teams (+ initiatives we did in CPE Team at the time), but later added more teams to our weekly reports to bring people a better picture what is being worked on. We thank to everyone who read our updates and found some value in them.

But as life is going forward even this updates are evolving. Last few weeks @abompard worked together with us to improve his weekly report to include the sources we are using for this weekly reports. So I introduce to you This Week in Fedora as a replacement for Community weekly updates. I’m glad that this initiative I started few years ago was able to live for that long and hopefully helped a few people to find information they were looking for.

I would like to thank people who helped me working on Community weekly updates:

@lenkaseg
@jnsamyak
@c4rt0
@jskladan
@t0xic0der
@siddharthvipul1
@patrikp

The post End of Community update appeared first on Fedora Community Blog.

Justin Staging Fedorable: Reflections on Organizing Flock as Fedora Community Architect

2026-07-07T08:00:00+00:00

Fedora Community Blog: Community Update – Week 27

2026-07-03T11:00:00+00:00

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: 29 June – 3 July 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

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 Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

Release Engineering

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

Continued investigation into building a Fedora container base image using Konflux.
Continued work on remaining Pagure -> Forgejo migrations.
F45 release cycle is set to begin soon, starting with Mass Rebuild in the middle of July. This will require some prep work next week.

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

Discussion with Scaleway (a cloud vendor in France) for potential Fedora Koji builders in their Paris datacenter. To be coordinated via RISE.
Hardware
- Coordinated shipping another “K3” hardware to DavidA (one of the Fedora RISC-V maintainers). This will be used as another RISC-V Koji builder. Sponsored by CLE.
- Milk-V Titan hardware is now available to buy. A handful of machines are being shipped to a couple of RISC-V engineers, including for Fedora use.
Community work
- Fedora Omni kernels for Muse Pi Pro hardware discussion with Trevor from Baylibre and Jason (Fedora RISC-V kernel)
- Marcin (hrw) Juszkiewicz continues to chip away at the Fedora RISC-V tracker
- Fedora Omni kernel work continues, with support for Muse Pi Pro, K3, and more: Jason Montleon and Jennifer Berringer
Other:
- Discussions on ‘fedora-devel’: “How can we improve the Changes Process?” thread
- A lot of internal discussion about 2FA for packagers
- Several internal and upstreams meetings

AI

This is the summary of the work done regarding AI in Fedora.

Aurelien Bompard improved the This Week in Fedora script to include the CLE status reports

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.

Lots of PTO: psklenar on extended PTO, kparal and adamwill each took some post-travel PTO days. Also post-event travel, bureaucracy (trip and expense reports) and decompression cut into work time for most
Compose-critical package script now in MVP state – see pull request, it works and does useful stuff but needs more refinement
Dist-git PR test feature progress: status report now works, still needs polish and tests
Tool work: CI optimization in blockerbugs, reverse proxy handling improvement in testdays-web
Significant bug investigations: grub2 changes broke image builds, haveged update could cause boot failure

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

Forge 15.0.3 in staging
New runner for koji organization
Continued work on Private Issues: public/private comments
Zabbix template developed to monitor health of runnerhost VM, moving onto the forge instance next.

EPEL

This team is working on keeping Epel running and helping package things.

Updated caddy in f44, f43, epel10.3, and epel10.2 resolving 22 CVEs
EPEL 11 planning discussions

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

Open Call for Fedora Event Video Footage! [discussions post]
Feedback period for F45 wallpaper has just ended. Here is the current iteration.

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 27 appeared first on Fedora Community Blog.

Justin Staging Fedorable: How Flock to Fedora Gets Organized

2026-07-02T08:00:00+00:00

Justin Staging Fedorable: Flock to Fedora 2026: What Happened

2026-06-30T08:00:00+00:00

Fedora Community Blog: Community Update – Week 26 2026

2026-06-26T10:00:00+00:00

Week: 22 – 26 June 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

CentOS Infra including CentOS CI

Attended/interacted with some Folks contributors (remotely attending and chat in matrix rooms)
Rebuilt quite some dependencies for calligrabot/robosignatory for centos stream 10 infra change (https://redhat.atlassian.net/browse/CS-3402)
Continue to work on all needed package rebuild phase for stream signing infra change (https://redhat.atlassian.net/browse/CS-3402)
Rebuilt already 48 rpm pkgs for infra10s for centos stream signing upgrade (https://redhat.atlassian.net/browse/CS-3402) but unfortunately more to come
Sprint planning meeting
Claude helped me writing sms (standup-matrix-summarizer) which can be used to retrieve your “Done” section from each daily standup report, combine that into weekly view so that you can just then copy/paste into manager google doc. See https://gitlab.com/CentOS/infra/containers/standup-matrix-summarizer (and https://quay.io/repository/centos-infra/sms?tab=info)
Rebuilt more pkgs for centos stream infra but also had to find workaround for orphaned pkg (https://redhat.atlassian.net/browse/CS-3402)
Rotate some api keys for SIGs (https://gitlab.com/CentOS/infra/tracker/-/work_items/1940)
Started to work on ansible boot-server role to convert for el10 and isc dhcpd replaced by kea (https://gitlab.com/CentOS/infra/tracker/-/work_items/1936) – WIP
PoC for kea dhcp replacement for isc dhcpd gone from el10 (https://gitlab.com/CentOS/infra/tracker/-/work_items/1936)
Created other tickets for .stg. stream el10 staging signing service (network ports for fedora-messaging stg rabbitmq hosts and two new service principals) – https://redhat.atlassian.net/browse/CS-3414
Closed ticket (review) about all dependencies built and available for el10 robosignatory/calligrabot (https://redhat.atlassian.net/browse/CS-3413)
Prepared staging host for centos-stream signing (https://redhat.atlassian.net/browse/CS-3414) but now blocked with a fedora infra staging issue (rabbitmq) so tried the whole day to debug but need someone from Fedora infra side to solve the issue there
Riscv64 discussion about a new p550 hardware firmware upgrade
Tested and validated that RH network team opened needed port for rabbitmq.stg.fedoraproject.org

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

F45 rebuild started — we’re trying to first focus on language toolchains — need to refer to Miro’s lightning talk from Flock on how they handled Python bootstrap
F44 is being kept up2date (there were some big updates, including GCC)
Kevin did the legwork to move away from old dist-git on fedora.riscv.rocks to forge.fp.o
Another K3 builder in Fedora Koji — another member added. (This might sound like a tame update, but all compute power is helpful / important to keep the build momentum :-))
Discussed some details of riscv64 in primary Koji ticket
Slides for Flock RISC-V update

AI

This is the summary of the work done regarding AI in Fedora.

The AI Developer Desktop Remix repos have moved to an org on codeberg (https://codeberg.org/project-resistor)

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.

Flock & DevConf attendance, lruzicka gave a talk on openQA test investigation, adamwill gave a lightning talk with cle about Fedora CI improvements, several of us were involved in a workshop/roundtable about the viability/desirability of moving all testing to dist-git PRs, lots of productive side conversations etc., many about AI – trip reports / blog posts coming
On-demand openQA test of dist-git PRs in progress
Looks like we maybe found some new maintainers for packager-dashboard
Lots of work to enable testing of the huge OpenSSL 4 update for Rawhide, investigate a significant bug that showed up, and eventually bypass the test failures for that bug as it’s proving not to be possible to resolve in a reasonable time (the update needed to get merged)
Continued tech debt / enhancement work on blockerbugs, testdays-web and issuebot

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

PTOs & travel
On Zabbix staging, now have a working template to monitor the Forgejo runnerhost VM and the runners themselves
Continued work on Private Issues (private comments refactoring)

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

Beta Wallpaper ticket closed

List of new releases of apps maintained by I&R Team

Patch update of Fedora Messaging from 3.9.0 to 3.9.1 on 2026-06-23: https://github.com/fedora-infra/fedora-messaging/releases/tag/v3.9.1

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 26 2026 appeared first on Fedora Community Blog.

Fedora Community Blog: Fedora Documentation translations again available

2026-06-26T09:19:27+00:00

Updates to translations of Fedora Documentation are again available. As announced on March 3rd, the unavailability of translation updates was due to the migration of the translation repositories and necessary tools from Pagure to the Fedora Forge. It took longer than expected but we are pleased to report this undertaking came finally to the end.

The post Fedora Documentation translations again available appeared first on Fedora Community Blog.

Fedora Infrastructure Status: Planned Outage - download-ib01, torrent, people outage

2026-06-25T20:00:00+00:00

Fedora Community Blog: Fedora at XV P.I.W.O. Poznań Free Software Fest

2026-06-25T10:18:38+00:00

On Saturday May 30th 2026, the XV edition of P.I.W.O. Poznań Free Software Fest was held in Poznań, Poland.

P.I.W.O. is an event with a long history. Between 2004 and 2018, it was organized by various student associations at the Poznań University of Technology. After 2018’s XIII edition (superstition much?), it entered a long hiatus that lasted until 2025, when members of the newly-formed Knyfyrtel Poznań Hackerspace decided to bring it back. The reactivated event proved a huge success, with the XIV edition bringing in 197 attendees. As such, ambitions for 2026 were rather big.

Teamwork makes the dream work

This year’s edition was the result of combined efforts of three Poznań-based organizations:

Knyfyrtel Hackerspace Poznań
“Webrains” Students’ Scientific Association at the Adam Mickiewicz University
“Linux Academic Group” Students’ Scientific Association at the Poznań University of Technology

Thanks to Webrains, for the first time in its history, the event was held at the Adam Mickiewicz University in Poznań – namely, the uni’s Faculty of Mathematics and Computer Science. Also a historical first, the XV edition was granted honorary patronage by the President of Poznań City Council.

Busy, busy day

The event spanned almost the entire Saturday, opening at 9:30 am and closing at 7:35 pm. The agenda was tightly packed, featuring 3 lecture tracks with 24 talks, 2 workshop tracks with 8 activities, plus a LAN Party track with 3 tournaments, as well as “free play” sessions. There was also a quiet corner where, thanks to the “Honte” group, attendees could relax and learn to play Go.

Throughout the years, one of P.I.W.O.’s hallmarks was the lunch break, with the attendees being provided free pizza. This year couldn’t be any different, with some 66m² (or 710 ft²) of pizza being delivered to the venue. (It disappeared frighteningly quick.)

The Fedora Community was represented by:

Zbyszek Jędrzejewski-Szmek, who gave 2 (!) talks
Mat Holmes, who volunteered as a photographer
Kacper Skrzyński, who handled various urgent tasks
Artur Frenszek-Iwicki, who gave a talk and held a workshop session

Historical moment: creation of SPOIWO

This year’s P.I.W.O. served as an opportunity to announce the creation of SPOIWO – Sojusz Przyjaciół Otwartego i Wolnego Oprogramowania (Alliance of Friends of Open and Free Software). This diverse coalition of social and technology organisations, cooperatives and open source businesses signed a declaration in support of digital sovereignty. The alliance was formed in response to the ever-deepening of public institutions’ dependency on closed platforms and their loss of control over data and communication.

The signing ceremony also featured speeches by representatives of SUSE Poland, Polish Linux User Group, “Internet. Czas działać!” Foundation and PLZ Spółdzielnia.

Exceeding all expectations

The event wrapped with 452 attendee badges issued, which exceeded even the most daring of expectations. (The number also explains why the pizza disappeared so quick.) The bar for the next edition is set high, but so are the organizing team’s ambitions.

If you’d like to learn more about the event, watch the live stream recordings, or subscribe to news so you won’t miss the announcement for the XVI edition – you can do all of that on the event’s website, at piwo.sh.

The post Fedora at XV P.I.W.O. Poznań Free Software Fest appeared first on Fedora Community Blog.

Fedora Infrastructure Status: Partial Outage - 2 of 5 Openshift workers down

2026-06-25T09:30:00+00:00

Fedora Community Blog: Community Update – Week 25, 2026

2026-06-23T10:12:46+00:00

Week: 15 – 19 June 2026 (Flock Week!!)

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

Helped getting elnbuildsync moved into stg openshift (ongoing).
A couple more services had OS upgrades to Fedora 44.
Some more MirrorManager problems.
Scrappers found another ostree repo. on kojipkgs, limited dir. indexing to stop the attack and then searched for any other ostree repos. Hopefully the last time it happens.

CentOS Infra including CentOS CI

Finish rebuilding/bumping some pkgs for ppc64le libvirt/qemu-kvm stack on el10 (https://gitlab.com/CentOS/infra/tracker/-/work_items/1928)
Start to work on debuginfo origin servers refresh with el10 instances (https://gitlab.com/CentOS/infra/tracker/-/work_items/1892)
More coordination work with Stream team about secureboot issues (https://redhat.atlassian.net/browse/CS-3400)
Finishing last debuginfo pool members reinstall (https://gitlab.com/CentOS/infra/tracker/-/work_items/1892)
Decommission old openstack env for stream (https://redhat.atlassian.net/browse/CS-3404)
Cloud SIG doc url change (migration to gitlab, from pagure) – https://gitlab.com/CentOS/infra/tracker/-/work_items/1934
internal requests (FRCL and audit compliance)
Move another SIG doc url (away from pagure.io) – https://gitlab.com/CentOS/infra/tracker/-/work_items/1938
Modified the aws load-balancer settings for one ocp tenant (https://gitlab.com/CentOS/infra/tracker/-/work_items/1932)
Migrate haproxy load-balancers to el10 for stream dc-move prep (https://redhat.atlassian.net/browse/CS-3353)

Release Engineering

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

Migration at 95%, the only thing left to migrate is majorly fedora-scm-requests, bug fixes, and continued releng operations.
Migration: archive-repo-manager from pagure
Fix: Missing permissions on releng/fedora-comps
Bug Fix: Mass tagging script for verification bits
F45 Change Sets reviews are in check and f45-python side tags are merged.
Regular releng operations.

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.

We’ve started searching for new owners/maintainers of Packager Dashboard and Oraculum

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

Completed the Flock To Fedora 2026 presentation on Fedora → Forgejo migration efforts #588, packaged and deployed Forgejo 15.0.3 #620.
successfully ran the PR fix doctor across all migrated repositories #601 to address merge issues with Pagure imports.
Enhanced runner infrastructure with the addition of a Testing Farm runner option #619 and docker-slim type runner #568, and improved security by deploying oauth-proxy to secure the Forge metrics endpoint #571.

EPEL

This team is working on keeping Epel running and helping package things.

Updated caddy in rawhide, resolving 14 CVEs
Ongoing onboarding of Pedro

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

With Flock this week, got to see how all the final designs turned out it in person!
Emma delivered her talk on ‘Why You Should Use Open Source Design in Open Source’ at Flock
Great progress on the F45 wallpaper in the final stretch!

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 25, 2026 appeared first on Fedora Community Blog.

Fedora Community Blog: Community Update – Week 24, 2026

2026-06-23T10:07:47+00:00

Week: 08 – 12 June 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

Request for CentOS Alternative Images SIG URL Update
Wiki upgrade problems/patch with FedoraMessaging when editing a page
Staging wiki down due to PluggableAuth extension issue
Move all remaining Fedora 42 instances to 44
Deploy DRM Panic Frontend
Switch from session-based OIDC to Authentication Bearer
Move the Fedora Badges static assets from Pagure to Forgejo
badges: fix image trigger annote order on deploy metadata
List authorization in CORS headers for API routes

CentOS Infra including CentOS CI

Release Engineering

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

Change Set Review for F45
Script improvement and feature addition (in-progress):
- fix(orphans): handle alternative providers to eliminate false positives
- Fixes #9841 – adds a release_type field to .composeinfo so we can tell Beta and Final releases apart.
Regular Releng Operations
Fedora 42 EOL Preps

AI

This is the summary of the work done regarding AI in Fedora.

Testdays (the webapp we use for running…Test Days) has an MCP server now (not sure if it’s deployed in prod yet though) – work by Jaroslav Groma

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.

Executive summary: Python 3.15 and kmscon Changes landing caused some fallout, tool tech debt payoff / enhancement continues, most team members used Day of Learning for AI experimentation
Two major Changes landed: Python 3.15 and kmscon consoles, various fallout from that:
- CoreOS and IoT both broken by the kmscon change
- Got on-the-fly keyboard layout changes added (important for openQA)
- Kickstart installs broken by Python 3.15 change (sent a fix)
- Various openQA test updates required for kmscon fixes
openQA serial bug worked around, new packages now deployed to prod
Tech debt repayment and new feature work continue on testdays, issuebot and blockerbugs
Kparal continues to find bugs in Lenovo laptop support
Work on ELN kernel gating got blocked by an unfortunate pre-existing design problem
Worked with Cristian Le to get rpmdeplint pipeline updated so fixes from last ~year are in prod, it now runs in ~2 minutes instead of ~20
Team did some AI agent / skills experimentation during Day of Learning

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

`testing-farm` optimized runner option provided to `ci` and `atomic-desktops` organizations
Regular runners capacity increased from 1 to 4 concurrent jobs
Private Issues work is ongoing.

EPEL

This team is working on keeping Epel running and helping package things.

Executive summary:
Completed archiving of EPEL 10.1
Package maintenance across multiple Fedora and EPEL packages
Quality work via bug reports and bodhi karma

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

Final stretch prepping Flock materials – Fedora badge, livestream template, sponsor splash
Progress being made on the F45 Wallpaper
Emma gave a talk about the Fedora Design team at the Waterford office’s Fedora 44 Release Party last Wednesday

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 24, 2026 appeared first on Fedora Community Blog.

Fedora Badges: New badge: DevConf.cz 2026 Attendee !

2026-06-18T11:59:07+00:00

Fedora Magazine: Web-Based Remote Installation for Fedora Linux: Here’s What We’re Building

2026-06-17T08:00:00+00:00

If you’ve ever needed to install Fedora Linux on a headless server, a Raspberry Pi, or any machine without a monitor attached, you’ve probably reached for VNC or RDP. They work – but as the installer moves to a web-based interface, there’s a new opportunity to do something more native to that model. We’re building it, and we want your input before we go too far down a path that’s hard to reverse.

Why This Is Happening

The Anaconda installer’s Web UI first landed in Fedora Linux 42 Workstation and was extended to all Live spins in Fedora Linux 43. It’s a full graphical installer built on Cockpit tooling and using PatternFly widgets. The GUI is rendered in a fullscreen browser window – but until now, that browser had to be running on the same machine you’re installing onto.

Here’s the thing: VNC and RDP were built around the GTK interface. While RDP could technically work with the Web UI too (it operates at the display level), a remote browser is a much better fit – orders of magnitude less data and much lower UI latency. As the Web UI becomes the primary installer interface across Fedora Linux editions, it needs its own native remote access story.

On top of that, there are two more forces pushing in the same direction.

As browsers move toward Flatpak packaging – already the reality for atomic desktops and derivatives like Bazzite – remote installation opens an opportunity for shipping focused, smaller boot images that don’t need to bundle a local browser at all. A lightweight ISO aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine.

And once you have a browser-rendered installer, serving it to a remote browser is the natural next step anyway. A headless ARM SBC doesn’t need to run a GPU-accelerated browser locally just to show you a disk partitioning screen. Your laptop can do that for it.

What It Actually Is

The concept is pretty straightforward: Anaconda’s Web UI, already built on Cockpit, gets served over HTTPS. You point a browser at the machine you’re installing, authenticate with a PIN, and you’re controlling the installation remotely. No VNC client, no RDP client, no X forwarding. Just a browser.

If you’ve used Cockpit to manage a server, you already have a feel for the experience. The difference is that the machine you’re connecting to is mid-install, not running a full OS.

Use Cases

The ones we’ve talked through most:

Headless servers – You’re installing onto a server in a rack with no attached display. You expose the Web UI over the network and control everything from your workstation.

Lightweight ARM SBCs – Devices like Raspberry Pi have limited resources. With remote rendering, the Pi just runs the installer backend; all the UI rendering happens on whatever machine you’re connecting from.

Remote monitoring – Even if you’re not fully headless, being able to watch an installation from another machine is genuinely useful. Kick off a server install, go make coffee, check progress from your laptop.

The Design Decisions So Far

We’ve had some meaty discussions about how this should work, and a few things are now settled.

Authentication: You set a PIN through kickstart or boot options, and type it into the browser login page. Same pattern as VNC and RDP – the user provides the password, not the system.

TLS with self-signed certificates: The connection is encrypted, but the certificate is generated on the fly at boot. That means your browser will show the “this certificate isn’t trusted” warning. We’ve accepted this tradeoff – shipping a private key on installation media is a security risk, and the IP address isn’t known ahead of time, so standard PKI doesn’t really apply. For environments that need proper certificates (say, a university deploying at scale), Image Builder is likely the right path to embed custom certs. That’s a later problem.

Single connection only: Only one browser session can connect at a time. Two concurrent sessions could genuinely conflict – one session starting installation while another changes the storage configuration. So: one connection, full stop.

Reconnection behavior: If you disconnect and reconnect, what happens depends on where the installation was. Before the review screen – the point of no return – you start from step one. After the review screen (installation actually running), you land on the progress view. Simple two-state model, covers the critical cases.

Config isolation and port: All Cockpit configuration specific to remote installation lives in /etc/anaconda/cockpit/, not the default Cockpit paths – otherwise the config could leak into the installed system. We’re leaning toward port 443 by default so you can just point your browser at the machine’s IP without specifying a port, but the port will also be configurable.

How This Compares to VNC and RDP

VNC has been around in Anaconda for years; RDP support was added more recently. Both work by screen-sharing the GTK interface. Technically, RDP could work with the Web UI too – it operates at the display level, scraping pixels from the screen. But a remote browser is simply better: you send orders of magnitude less data and get much lower UI latency compared to streaming a full desktop.

Beyond performance, there are practical advantages. No client is required – any modern browser works. No VNC viewer to install, no RDP client to configure, no protocol quirks across platforms. And it’s the same Web UI we’re already actively developing, so features and fixes automatically benefit the remote experience. With VNC or RDP, you’re screen-sharing a separate GTK codebase – a separate maintenance burden.

VNC and RDP aren’t going away for now – they still work with the GTK legacy interface. But as the Web UI becomes the default across more Fedora Linux editions, browser-based remote access is where the investment goes.

Where We Are Right Now

This is a developer preview. Here’s what’s working:

Custom login page with PIN-based authentication
Separate socket-activated systemd unit for auth (clean separation from the main Cockpit process)
Session cookies that survive tab closes, require re-login on browser close
Cockpit config in an isolated, anaconda-owned path

Here’s what’s still open:

Single-connection enforcement (this will likely require close collaboration with the Cockpit team)
Backend detection of whether installation is already running (this is needed for proper reconnection behavior)

If you want to see the PoC in action, there’s a draft PR at rhinstaller/anaconda-webui#1274 with the authentication setup – custom login page, pin-based auth script, socket-activated systemd units, and the Cockpit config override. To try it yourself, clone the PR branch, build an updates image, and boot it with virt-install:

git clone -b poc-remote https://github.com/bruno-fs/anaconda-webui.git
cd anaconda-webui
make create-updates.img

virt-install \
  --name anaconda-remote-test \
  --ram 4096 \
  --vcpus 2 \
  --disk size=20 \
  --location /path/to/Fedora-Everything-netinst-x86_64-Rawhide.iso \
  --extra-arg "inst.updates=http://your-host:port/updates.img" \
  --extra-arg "inst.webui.remote"

This is a proof of concept, not production-ready code. The PIN is hardcoded to 1234, there’s no TLS, and single-connection enforcement isn’t in place yet. Don’t use this for real installations – it’s meant to show the direction and let you poke at the approach. Once the installer boots, point a browser at the VM’s IP and enter 1234 on the login page. It’s rough, but it runs.

What We Want to Hear From You

We’re sharing this now because some of these decisions are hard to unwind once the feature ships, and community input is more useful now than after the fact. A few things we’re genuinely thinking about:

Remote installation is opt-in – you enable it through boot options or kickstart. But here’s a question we’re genuinely considering: should we ship a lightweight boot ISO without a local browser, with remote installation enabled by default? A minimal image aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine. Would that be useful to you? And if you’re using VNC or RDP for remote installation today, would this replace them? What would it need to do that it doesn’t yet?

Come talk to us on Matrix (#anaconda:fedoraproject.org), or leave a comment on this article. You can also follow the work on the anaconda-webui GitHub repo. We’re looking forward to hearing from you.

Fedora Magazine: What’s Next for Pagure.io?!

2026-06-16T14:59:15+00:00

At the Flock 2026 Birds of a Feather session, poetically named FFFwF (or, for us lazy people, Forging Fedora’s Future with Forgejo), we discussed the current state of our migration effort to the new forge. I asked the obligatory question: Who still has things on pagure.io?!

A few brave contributors raised their hands, some with an uneasy look in their eyes. Miro swiftly pointed out that everybody is affected by one particular repository; looking at you, `fedora-scm-requests`. Luckily, the RelEng folks have it in their sights. Sure, there are a few other repos lying around the old faithful, but it is time for the Fedora Project to move on and embrace the Forge.

Our new home is currently running on the LTS branch in v15.0.2. We are going to stick with it in production, and our next LTS upgrade will be to v19.

What is going to happen next?

Pagure itself as a project is hosted on pagure.io, and that service is going to be decommissioned at the end of July 2026. What does that mean for you? Well, that depends on when you are reading this.

If you just came back from Flock 2026 and you still have active repositories on pagure.io, here is what you need to do:

Check out the existing organizations in the Forge. If your project fits into any of the existing ones, ask its owners for a migration.

If it doesn’t fit, open a ticket with the forge team, and we will help you decide the best path forward.

Some of us have commits in projects that point back to pagure.io. Don’t worry, we are not going to break your links, for foreseeable future. We will explore options for implementing redirects so your historical links successfully point to their current locations.

The best way to handle the transition after your move, right now, is to inform your users about your new home. Add a BIG BOLD ANNOUNCEMENT to your README, close all open issues, and create a single pinned issue with your migration announcement.

Note: Do not expect to be able to log in to pagure.io after July 2026.

Wait… and what about `dist-git`?

Well, that is the next target in the scopes of the Forge team. As I showed you in the room, we have 11 Features that define the transition. The biggest task at hand is a bit more sneaky. We are missing multiple enhancements to the upstream project that will require a lot of coordination and Go code. So, if you find yourself in possession of spare cycles and a particular need to help us make it better and faster, Forgejo is waiting for you!

A road-map with all the tasks for the move will land in the Forge soon. (See resource list below.)

Important Links & Resources

Check out the new home: Browse existing organizations on the new Fedora Forge
Want to write some Go? Contribute to the upstream Forgejo project.
Track our progress: Migration roadmap will be posted here soon

AI Disclaimer: Grammar and formatting were done with the help of robots; all the original brain-farts are my own.

Fedora Community Blog: From Contributor to Outreachy Intern: My Fedora Journey Begins

2026-06-16T12:00:00+00:00

Introduction

Hi, I’m Aman, a software developer and open-source enthusiast who enjoys backend development, APIs, and building tools that are useful to others.

I recently started my Outreachy internship with the Fedora community, and this is my first blog as an intern. In this post, I want to share what my first two weeks have been like, what I’ve learned so far, and what I’m looking forward to in the next phase of the internship.

I’m working on the Fedora Release Schedule Planner API, a project focused on improving Fedora’s release planning workflow by moving away from older XML-heavy processes and strengthening the current FastAPI-based API through better tests, authentication, and infrastructure integration.

About the Fedora Community

Fedora is a global open-source community behind Fedora Linux and many related projects. People contribute in many areas, including packaging, infrastructure, design, documentation, testing, and release engineering.

One thing I’ve enjoyed learning about Fedora is its Four Foundations: Freedom, Friends, Features, and First. These values reflect Fedora’s focus on free and open-source software, community, innovation, and adopting new technologies early.

What I like about Fedora is that it is not only about writing code. Communication, documentation, reviews, and helping new contributors are also important parts of the community.

Through this internship, I’m also getting a better understanding of Fedora’s release process and how different contributors work together to improve the tools used by the community.

About My Project

My Outreachy project is Enhancing the Fedora Release Schedule Planner API.

Fedora’s traditional release planning workflow relied heavily on manually edited XML files, which made the process difficult for newcomers, harder to scale, and less connected to modern tooling.

The Fedora Release Schedule Planner API is a modern FastAPI-based project hosted on Codeberg. It has already moved from Flask to a modular FastAPI architecture, uses Pydantic for data validation, provides auto-generated Swagger documentation, and relies on Forgejo Actions for CI/CD testing.

The goal of my internship is to help make this API more production-ready. My work will focus on improving the test suite, strengthening CI reliability, adding secure authentication with OpenID Connect, integrating the API with Fedora infrastructure data, and preparing it for deployment.

Learning More About the Community

I had already started contributing to the Fedora Release Schedule Planner API during the Outreachy contribution period. During that time, I joined the project’s Matrix chat, went through issues and pull requests, and became familiar with the basic project structure.

So, during the first two weeks of the internship, my focus was more on understanding the project in depth. I followed discussions in the Matrix chat, worked through issue and pull request conversations, and learned how mentors and maintainers review changes.

We also have a weekly Google Meet call with the mentors. These calls are helpful for discussing progress, asking questions, and understanding what to focus on next.

Alongside exploring the codebase, I spent time reading Fedora documentation and project-related resources to better understand the release planning workflow.

I also explored the FastAPI codebase, tests, CI setup, and previous pull requests more closely. This helped me understand how tools like Pydantic, Swagger documentation, and Forgejo Actions are being used in the project.

Challenges and Wins

One of my biggest challenges in the first two weeks was understanding the codebase beyond its basic structure. During the contribution period, I had already become familiar with the main parts of the project, but during the internship, I started understanding how different layers work together, including API routes, database models, Pydantic schemas, services, templates, and tests.

Another challenge was making sure my changes did not affect existing behavior. I had to run tests, check formatting, and verify things locally before updating a pull request.

My biggest win was becoming more confident with the project workflow. I was able to work on issues, raise pull requests, respond to review feedback, and understand the expectations around code quality and maintainability.

I also became more comfortable with the tools used in the project, including FastAPI, SQLAlchemy, Pydantic, Jinja2, HTMX, tests, and CI checks.

A small win for me was getting some of my pull requests merged. For example, PR #425 and PR #427 helped me understand the review process better and gave me more confidence while working on the project.

Plans for the Next Month

In the next month, I want to continue building on the work from the first few weeks. Currently, we are focusing on fixing UI-related issues, improving the code structure, and aligning the codebase with the project’s expected structure.

Along with that, I want to keep improving the test suite and make sure the API works correctly with the current FastAPI and Pydantic structure.

I also want to start preparing for the authentication part of the project. Since OpenID Connect is an important goal of this internship, I plan to spend time understanding how Fedora authentication works and how it can fit into the Release Schedule Planner API.

After that, I want to gradually learn more about how this API can connect with Fedora infrastructure data. This is important because the long-term goal of the project is to move away from the older XML-based workflow and make the release planning process more modern and maintainable.

Conclusion

These first two weeks have helped me understand the project better. I now have a clearer understanding of the Fedora community, the Release Schedule Planner API, and how people collaborate in open source.

I still have many things to learn, but I feel more comfortable with the project now than I did at the beginning of the internship.

I am thankful to Outreachy, Fedora, and my mentors for this opportunity, and I am looking forward to continuing the work in the coming weeks.

PS: Cover image generated with the help of an AI tool.

The post From Contributor to Outreachy Intern: My Fedora Journey Begins appeared first on Fedora Community Blog.

Fedora Magazine: Sandbox AI coding agents with microVMs on Fedora Linux

2026-06-15T08:00:00+00:00

AI coding agents such as Claude code or Codex get more capable every month. This is great for productivity, but approving all commands gets annoying really quickly. On the other hand, allowing agents to run any command on your work machine is not a great idea. They are really good at exploring your production cluster using kubectl or running remote commands at your production servers over SSH.

Fortunately, Linux distributions come with plenty of options for process isolation. You can run agents as a completely different user, in a container, or in a VM. This article shows how to use microVMs to run coding agents.

Security concerns

Running AI agents in unattended mode is like running untrusted code. Companies behind these agents, such as Anthropic or Google, are not trying to steal credentials, but people keep coming up with new attack vectors like Slopsquatting or prompt injections virtually anywhere.

The coding agents themselves ship with built-in mitigations that try to refuse prompt injections as described, for example, here.

Lightweight sandboxing technologies are another layer of defense in coding agents. On Linux, bwrap is one of the possible implementations. This raises the bar, yet sandbox escapes are still a problem. Take a look at CVE-2026-39861 as an example of multi-platform sandbox escape.

You could use containers to isolate the agent in their own namespace, but they still share the host kernel. Some of the the recent kernel vulnerabilities resulted in privilege escalation (switching from regular user to root) suggesting that containers are not enough as a security boundary.

In the rest of this article, I describe how to use microVMs to easily sandbox coding agents on your Fedora Linux.

Exploring microVMs

First of all, let’s take a look at what microVMs are. Just like any VM, they have their own kernel, one per each microVM. Compared to traditional VMs they start in very short time (hundreds of milliseconds) but don’t offer all the features of full VMs.

This article explains usage of krun runtime for podman. This approach offers the same well-known workflow as containers, but simply runs every container as a microVM.

Start by installing the runtime:

dnf install crun-krun

To run a microVM, simply run podman with –runtime=krun in your terminal:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Things to watch out for

A microVM is not a regular container, so a few things might behave differently. First, allocate enough CPU and RAM with krun annotations. The defaults are too small and might result in OOM (Out Of Memory) kills. Second, make sure you have libkrun version >= 1.8. Older versions have a bug which prevents you from pressing Enter in your coding agent. Third, the microVM ignores the USER set in the Dockerfile and always boots as root. Either switch to the correct user manually or put the switch into an entrypoint script.

Case study: sandboxing Claude Code for a Python project

This section outlines a simple setup for a Python project managed by uv. It uses podman-compose to mount the project into the microVM. Compared to containers, this podman compose needs additional annotations for UID/GID translation, SELinux labeling, and HW resources. The final setup is very similar to what you would need for containers.

To install podman compose from official Fedora repositories, run:

dnf install podman-compose

The setup has 3 parts:

Dockerfile
docker-compose.yaml
entrypoint.sh

Dockerfile

As mentioned above, podman with krun runtime still runs containers, but spawns each of them in a microVM. This example container includes uv package manager, claude code and a few additional RPM packages. Define your own container based on your project dependencies and programming language.

Make sure to create an unprivileged user and use it for running the agent.

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Create group and user matching host UID/GID
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Rarely-changing tooling. Kept above the dnf layer so editing the RPM list
# below does not invalidate (and re-run) these installs.
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# Frequently-changing RPMs. Kept last so adding a package only rebuilds from here down.
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

# This is needed because entrypoint does not have .local/bin in the PATH
ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

docker-compose.yaml

The compose file defines how to mount the project directory into the microVM. This is where most of the magic happens, because podman needs to translate UID/GID and manage SELinux labels, otherwise the files would not be accessible inside of the microVM or they would end up being owned by a different user.

services:
  claude:
    container_name: project-name-claude
    annotations:
      run.oci.handler: krun
      krun.ram_mib: "4096"
      krun.cpus: "4"
    user: "${HOST_UID}:${HOST_GID}"
    userns_mode: keep-id  # optional, for rootless host
    build:
      context: .
      args:
        HOST_UID: "${HOST_UID}"  # use UID and GID from the host so that files created in the container have correct permissions
        HOST_GID: "${HOST_GID}"
    volumes:
      - ../:/app:U,z  # bind mount your project
      - project-name-venv-cache:/venv:U,z
      - claude-config:/home/appuser/.claude:U,z  # persistent claude credentials/config
    working_dir: /app
    stdin_open: true
    tty: true
    environment:
      - CLAUDE_CONFIG_DIR=/home/appuser/.claude
      - UV_LINK_MODE=copy
      - UV_PROJECT_ENVIRONMENT=/venv/env  # This is inside the cached volume
      - UV_PYTHON_INSTALL_DIR=/venv/python  # So that uv-managed python installations are not in home but cached in /venv
      - TERM=xterm-256color
      - COLORTERM=truecolor

volumes:
  project-name-venv-cache:
  claude-config:
    external: true
    name: claude-config

There are 3 key parts:

annotations – these select krun as a runtime and specify HW requirements
user and userns_mode – this tells podman to translate UID/GID so that the files created in the microVM end up owned by your user on the host
volume labels – z tells podman to relabel the files with a shared SELinux label. Otherwise SELinux would prevent the process inside the microVM from touching the files in the volume. U tells podman to recursively chown all files.

entrypoint.sh

The entrypoint creates a virtual environment for the Python project, because we don’t want dynamic dependencies baked into the container image. It also runs the switch from root to regular user because podman with krun runtime ignores the USER directive from the container.

#!/bin/bash
set -e

echo "Sandbox started as user: $(id -un) in directory: $(pwd)"

if [ "$(id -un)" != "appuser" ]; then
  runuser -u appuser -- uv sync
  echo "Running ${@} as appuser"
  exec runuser -u appuser -- "$@"
fi

uv sync
exec "$@"

Run the setup

First, build the container:

$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build
STEP 1/18: FROM fedora:44
...
Successfully tagged localhost/agent-sandbox_claude:latest

Then create the external volume and run the claude container interactively:

$ podman volume create claude-config
$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude
Sandbox started as user: root in directory: /app
Resolved 3 packages in 6ms
Checked 3 packages in 1ms
Running /bin/bash as appuser
tty: ttyname error: Inappropriate ioctl for device
[appuser@3bd1234b9a77 app]$

You can now check that the kernel is different by running uname -a inside of the microVM.

Putting it together: single script to create the whole setup

Creating the same setup manually for every project is not the greatest user experience, but you can automate the setup using a simple script like this. It installs a new sbx command that wraps the setup described above into 3 simple command options: init, build, and run.

A word of caution — microVM is not a bulletproof boundary

A microVM raises the bar considerably, but it is not perfect isolation, and it would be irresponsible to present it as such. Take a look at the libkrun git repository to read more about the security model.

If you want to run software that might be dangerous, prefer using a full VM or even cloud VM.

Conclusion

MicroVMs seem like a sweet spot for running AI Agents. They provide a familiar workflow of containers, but the agents run on their own kernel behind a hypervisor. This article describes workflow based on podman and krun runtime because Fedora Linux ships both of them natively, but there are plenty of other options available for any platform (for example docker sandbox).

Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own and tested.

Fedora Community Blog: F44 Election Results

2026-06-13T16:16:29+00:00

The F44 election cycle has concluded. Below are the results. We are posting the results early this year as we are currently on the eve of Flock to Fedora 2026 and the results were ready. Thank you to all candidates and voters, and congratulations to the newly elected members!

Results

Council

Two Council seats were open this election. A total of 204 voters participated in this election.

# votes	Candidate
958	Miro Hrončok
788	Aleksandra Fedorova
744	Fabio Valentini
637	Tomáš Hrčka
509	Vít Smolík
451	Akashdeep Dhar
337	Hristo Marinov

FESCo

Five FESCo seats were open this election. A total of 199 voters participated in this election

# votes	Candidate
771	Neal Gompa
700	Fabio Valentini
662	Michel Lind
604	Maxwell G
549	Simon de Vlieger
537	Adam Miller

Mindshare

Four Mindshare seats were open this election. A total of 154 voters participated in this election.

# votes	Candidate
419	Samyak Jain
396	Akashdeep Dhar
395	Luis Bazan
351	Mat H (Mat Holmes)
214	Kenz S (Makenzie Stewart)

EPEL Steering Committee

Four EPEL Steering Committee seats were open this election. As the amount of interviews submitted equaled the number of open seats, candidates who interviewed were automatically elected.

# votes	Candidate
Automatically Elected	Carl George
Automatically Elected	Diego Herrera
Automatically Elected	Jonathan Wright
Automatically Elected	Troy Dawson

The post F44 Election Results appeared first on Fedora Community Blog.

Fedora Magazine: Justin Wheeler on Growing Up in the Fedora Community

2026-06-12T15:53:38+00:00

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

In 2015, an 18-year-old student walked into his first Flock not knowing a single person. He was shy, a little overwhelmed, and had no idea what he was walking into. By the time he walked out, something had shifted. The community had been so genuinely welcoming, so warm and easy to fall into that he left not just curious about Fedora, but hungry to be part of it.

That student was Justin Wheeler. And Flock never really let him go.

What started as one conference became a thread running through his entire open source journey. First he became a Fedora Magazine author. Then editor-in-chief. And now, as Fedora Community Architect, he’s the one standing on stage at the opening and closing looking out at the very kind of room that once changed his life helping shape the event that shaped him.

He’ll be the first to admit it’s a lot. “It’s way more intense and hard work than I ever could have realized,” he says, with genuine respect for everyone who built Flock before him. But that experience of once being the nervous newcomer gives him something no job description could have: an instinct for why people show up and what makes it matter.

For Justin, the answer has always been the hallway track. Not the sessions, the spaces in between them. The moment you bump into the exact person you need to talk to. The lunch conversation that turns into a collaboration. The game night and candy swap where the ice finally breaks and people stop being usernames and start being friends. “It’s the relationships we get to strengthen and build,” he says, “that make us so much more effective in everything we do the rest of the year.”

That’s also what data can’t capture and Justin thinks about this a lot as part of the Data Working Group, where he works alongside Michael Winters and Robert Wright to understand community health. Numbers can tell you a lot. But they can’t show you a first-timer lighting up when they realise they belong here. They can’t measure the moment the community becomes real.

His advice for anyone walking into Flock for the first time? “Don’t be shy. Leave your comfort zone a little. And definitely don’t skip the social events.” He says it like someone who knows exactly what it feels like to need that push and exactly what’s waiting on the other side of it.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Fedora Magazine: What you need to know about the Microsoft Secure Boot certificate expiration: Don’t Panic!

2026-06-11T08:00:00+00:00

UEFI Secure Boot keys, used to sign the first stage boot loader, are expiring in June 2026 (this month!) But that only means that Microsoft can no longer sign with them. Machines, both bare metal and virtual, will continue to boot long after June is over as long as the current public keys are not removed from the firmware database or revoked via the dbx database. In the meantime, Fedora Rawhide (f45) already contains a first stage boot loader that is signed by multiple keys for maximal compatibility. So there is no need to panic, but action is recommended.

Secure Boot basics

UEFI Secure Boot is a security feature which ensures only trusted (signed) applications run during a computer’s boot up process. This applies to the boot loaders, the operating system kernel, and the kernel modules. Trust is established using asymmetric cryptography. Tested algorithms, like R S A or ECDSA, are used to create asymmetric key pairs. The private key is used to sign the application. A totally different but complementary public key is used to verify the application. The private key is kept secret while the public key is available to anyone who wants to run the application. UEFI Secure Boot is only available for machines that run UEFI firmware, and for Fedora, the key expiration only applies to the x86_64 architecture (Intel, AMD), and to those who have Secure Boot enabled.

The root of trust for Secure Boot is in the firmware. Hardware manufacturers add trusted Secure Boot public keys to their devices’ Secure Boot firmware database (db). Firmware for virtualization, known as edk2-ovmf, is built with similar trusted public keys. In order to simplify the process, there is a central signing authority which signs the first stage boot loader. This is the “shim” whose public key is enrolled pretty much everywhere, and that is Microsoft. Microsoft first started signing shim with their 2011 UEFI Third Party CA, but by the end of June they will no longer be able to do so. Since October 2025, Microsoft began signing with a new 2023 key as well. Once the 2011 key expires, new shims will only be signed with the 2023 key.

The OS maintains the rest of the Secure Boot chain. Fedora’s shim embeds a Fedora Secure Boot public CA key. Private keys on Fedora’s signing server are used to sign the next stage boot loader (grub2), the kernel, and any other applications that need to run during the boot process (like fwupd for firmware updates or unified kernel images– UKIs)

When the kernel is built, kernel modules are signed using an ephemeral key. Only signed kernel modules can be loaded when Secure Boot is enabled.

Action Recommended

The fact is that you don’t really have to do anything about any of this right now. Your computer will continue to boot. New installations of both older and new OSes will continue to be possible.

BUT, we recommend updating your Secure Boot database if and when an update is available. The next deliverable shim update can only be signed by the 2023 key and it is best to be prepared. While there are no known exploitable security vulnerabilities in shim at this time, new ones may be found next month or next year. Below are some commands that will help you determine what state your computer is in, and how to make the correct updates.

How to tell if you have UEFI or legacy BIOS

The presence of the /sys/firmware/efi directory is the clearest way to check whether you are running UEFI firmware or legacy BIOS. The following command will print “BIOS” if the efi directory does not exist:

$ [[ -d /sys/firmware/efi ]] || echo BIOS

How to check if Secure Boot is enabled

$ mokutil --sb-state
SecureBoot enabled

The Secure Boot state may be “enabled”, “disabled”, or the machine may be in “Setup Mode”, which means there are no Secure Boot keys enrolled in firmware.

How to identify which keys are in the firmware db

$ mokutil --db --short
580a6f4cc4 Microsoft Windows Production PCA 2011
45a0fa3260 Windows UEFI CA 2023
46def63b5c Microsoft Corporation UEFI CA 2011
b5eeb4a670 Microsoft UEFI CA 2023

This output is from a VM, and as you can see, it already contains the 2011 and 2023 public keys. Your laptop or desktop will also show other database keys from the manufacturer.

How to update the firmware db

Enable and use fwupd to get your updates from the Linux Vendor Firmware Service (LVFS):

$ sudo fwupdmgr update

If you have an HP or Fujitsu machine, the update will be available soon, after you have updated your firmware. Use either the above command, or the vendor-recommended command at that time.

How to check which key(s) signed the shim

$ sudo dnf install pesign -y
$ sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi
----------------------------------------------
certificate address is 0x7f3fffc11410
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
----------------------------------------------
certificate address is 0x7f3fffc139e0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft UEFI CA 2023 signer
No signer email address.
No signing time included.
There were certs or crls included.
-----------------------------------------------

The output shown here is from the dual-signed Fedora Rawhide (F45) shim. If Rawhide is not installed, the shim will only be signed with the first key, which is the 2011 key.

You can use the same pesign command to examine grub2 (/boot/efi/EFI/fedora/grubx64.efi) and the kernel (/boot/vmlinuz-…).

What NOT to do

If a database update is not available for your system, contact your hardware manufacturer. Do not attempt to force an incompatible update. Do not update your database manually unless you know exactly what you are doing!

Do not remove or revoke the 2011 key. The 2011 key is not compromised, it is only expiring, so there is no need to remove it. Additionally, it was used to sign option ROMs, so removing it could render peripherals on your system inoperable. Likewise, adding the 2011 key to the firmware dbx database (the forbidden database) will affect option ROMs. This will stop the dual-signed shim from booting.

Fedora Badges: New badge: Czech Mate! !

2026-06-11T05:35:14+00:00

Fedora Infrastructure Status: Network issues

2026-06-10T13:00:00+00:00

Fedora Magazine: Jaroslav Reznik on Security, the EU Cyber Resilience Act, and Why You Can’t Do Things From Behind a Desk!

2026-06-10T08:00:00+00:00

Jaroslav Reznik has been part of Fedora longer than most people remember. This goes all the way back to Red Hat Linux 5, before Fedora was even known as Fedora. After a brief detour to another distro, he joined the KDE SIG days and went on to build a long career in Red Hat’s Program Management team. But it was the EU Cyber Resilience Act (CRA) that brought him back to the Fedora community.

The moment that changed everything? A scene at FUDCon North America in 2009 watching Fedora’s Program Manager command what looked like a sci-fi control room, scheduling Fedora 13. Jaroslav looked at that and thought: I want that job. Years later, he got it.

On the CRA, Jaroslav is clear and passionate. The regulation is the first to formally acknowledge the existence of open source software in legislation. Thanks to an enormous community effort, it’s actually open-source friendly. Non-commercialised community projects are fully exempt. For a project like Fedora, the concept of open-source stewards formally recognised in the regulation opens up a powerful new model for governance.

The program management team is working to build a stewardship governance model around Fedora. They are making it a welcoming place for anyone who wants to support the project. They are clear about what stewardship should and shouldn’t be: it’s not about monetizing open source or adding burdens, it’s about helping the community raise the bar for security together.

Flock holds a special place for Jaroslav; he co-organised the very first Flock held in Prague back in 2014. Now, more than ten years later, he is returning to Prague for Flock 2026 with Roman Zhukov to not only talk about the CRA but run a hands-on workshop on it. His message is simple: you can’t do things from behind a desk.

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora Community Blog: Onboarding a Forgejo-hosted project to Fedora Konflux

2026-06-09T09:08:39+00:00

We, the Forge team, recently onboarded a Codeberg-hosted repo to the new Fedora Konflux instance.
This is a guide based on the onboarding experience, the steps and UI are similar in Fedora’s Forge.

Useful links

Konflux UI: https://konflux-ci.fedoraproject.org
Documentation: https://konflux-ci.dev/docs/
Cluster Console: https://console-openshift-console.apps.kflux-fedora-01.84db.p1.openshiftapps.com
Cluster API (for oc login): https://api.kflux-fedora-01.84db.p1.openshiftapps.com:6443

Step 1: Get access to the tenants-config GitLab repo

Konflux configuration is managed through GitOps in the
tenants-config
repo on GitLab. The UI is intended to be read-only — you should do everything through merge requests.

Sign in via SAML SSO at https://gitlab.com/groups/fedora/-/saml/sso to get
group membership.
Make sure you have at least a Guest role. Guest lets you approve MRs
but not merge them. Ask a maintainer to bump your role if needed.
Get yourself added to CODEOWNERS for your tenant’s directory
Example MR.

Step 2: Create your tenant namespace

Follow the instructions in the
tenants-config repo:

Run the create-tenant-resources playbook. It generates the namespace, RBAC
and quota resources.

You end up with three files:

ns.yaml — the namespace with a konflux-ci.dev/type: tenant label
rbac.yaml — a RoleBinding granting konflux-admin-user-actions to your FAS
user
kustomization.yaml — ties together the quota, RBAC, namespace and your
applications directory. Quota can be increased later.

Then run the update-tenant-apps playbook to generate an ArgoCD application
manifest per tenant directory and update the ArgoCD kustomization.

Example MR.

Step 3: Define your Applications and Components

This is where you tell Konflux what to build. We went with a Kustomize
Configuration-as-Code setup with three layers:

A shared base — a generic Component template with the git URL, provider
annotations (git-provider: forgejo, git-provider-url: https://codeberg.org),
pipeline config and the build.appstudio.openshift.io/request: configure-pac
annotation.
Per-application bases — an Application CR plus per-variant overrides (e.g.
rawhide vs. stable).
Per-environment overlays (staging/production) — patches for application names,
component names, context paths and Dockerfile paths.

Open a merge request with everything
Example MR.

Step 4: Add ImageRepository resources

Each Component needs a matching ImageRepository CR. If you don’t have one, the image controller
never provisions a Quay repo, spec.containerImage stays empty on the
Component, and the build service just sits there waiting. No webhook, no PaC PR,
nothing happens.

Example ImageRepository:

apiVersion: appstudio.redhat.com/v1alpha1
kind: ImageRepository
metadata:
  name: forge-rawhide-production
  namespace: fedora-infra-tenant
  annotations:
    image-controller.appstudio.redhat.com/update-component-image: "true"
  labels:
    appstudio.redhat.com/application: forge-production
    appstudio.redhat.com/component: forge-rawhide-production
spec:
  image:
    name: fedora-infra-tenant/forge-rawhide-production
    visibility: public

The update-component-image: "true" annotation is what tells the image
controller to write the Quay URL back to spec.containerImage on the Component.

Example MR. Do not merge yet.

Step 5: Create the SCM secret

Konflux needs a secret to authenticate with your Forgejo/Codeberg instance:

oc create secret generic pipelines-as-code-codeberg 
  -n {namespace} 
  --type=kubernetes.io/basic-auth 
  --from-literal=password={FORGEJO_TOKEN}

oc label secret pipelines-as-code-codeberg -n {namespace} 
  appstudio.redhat.com/credentials=scm 
  appstudio.redhat.com/scm.host=codeberg.org

The Konflux docs
say you need these token scopes:

issue: Read and Write
organization: Read
repository: Read and Write
user: Read

Don’t restrict the token to a specific repo — scopes like write:user aren’t
available with repo-scoped tokens on Forgejo. If you set the right scopes and
it still complains about insufficient permissions, try a token with everything
enabled.

Step 6: Merge and verify

With the secret in place, merge your MR. ArgoCD picks it up and syncs the
resources. Wait a few minutes, then check:

# Did containerImage get set?
oc get components -n {namespace} 
  -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containerImage'

# Are the ImageRepositories ready?
oc get imagerepositories -n {namespace} 
  -o custom-columns='NAME:.metadata.name,STATE:.status.state'

# What does the PaC status say?
oc get components -n {namespace} 
  -o custom-columns='NAME:.metadata.name,STATUS:.metadata.annotations.build.appstudio.openshift.io/status'

If spec.containerImage is filled in and the status shows "state":"enabled",
you’re good.

Step 7: Handle the PaC pull requests

At this point Konflux opens PRs on your source repo with auto-generated Tekton
pipeline files in .tekton/. Two ways to go:

Merge them as-is if you’re happy with Konflux’s defaults.
Close them and use your own pipelines. If you already have .tekton/ files,
update them with:
application/component labels matching your Konflux component names
output-image pointing to quay.io/redhat-user-workloads/{namespace}/{component}
latest task bundle versions (grab the @sha256:... refs from the
Konflux-generated files)
serviceAccountName: build-pipeline-{component}

We went with the second option. We already had pipelines with custom version
tagging that we wanted to keep, so we pulled in the new task bundles and labels
from the generated files and left the rest alone.

Step 8: Re-triggering when things go wrong

The configure-pac annotation gets consumed on the first attempt. If it fails
(token issue, rate limit, whatever), you need to re-add it:

# One component
oc annotate component {component} -n {namespace} 
  build.appstudio.openshift.io/request=configure-pac --overwrite

# All of them
for comp in $(oc get components -n {namespace} -o name); do
  oc annotate $comp -n {namespace} 
    build.appstudio.openshift.io/request=configure-pac --overwrite
done

To sum it up, we created a tenant on Konflux-ci cluster, created applications and components and set a place where the images would be hosted. At the event of push to the codeberg repo main branch – the repo where we store the Forge Containerfiles, the pipeline gets triggered (scoped by the on-cel-expression to only those contexts where the change happened) and a fresh and tagged image appears on quay, ready for further testing and deployment.

Thanks to the Konflux Team for the Forgejo support!

The post Onboarding a Forgejo-hosted project to Fedora Konflux appeared first on Fedora Community Blog.

Fedora Magazine: Peter Boy on Why Fedora Needs More Than Just Technical Contributors

2026-06-09T08:00:00+00:00

Peter Boy came to Fedora documentation the way many contributors do, by seeing a gap and deciding to fill it. As a researcher, writing is his daily work. When he looked at how he could meaningfully contribute to Fedora, documentation was the obvious answer. He started with Fedora Core 1, stepped away, and returned in 2020 when both the Server Working Group and the Docs Team were being revitalised at the same time. Since then, his focus has been on the “bigger-picture” content structure, readability, consistency, and inspiring others to get involved.

His first Flock was in Cork, Ireland in 2023, and what struck him most was the collaborative approach combined with open, structured dialogue and the sheer range of personalities all genuinely trying to get to know each other.

For a team like Docs, where so much depends on shared standards and careful communication, Peter sees Flock as irreplaceable. New ideas emerge from spontaneous conversation, something the formal structure of video calls simply can’t replicate. His message to anyone thinking about contributing? Fedora needs far more than technical contributors. Documentation, communication, community building these are all vital, and Fedora needs to do a better job of making that visible. At Flock 2026, he is most looking forward to the working groups and the hallway conversations, the ones that are simply too nuanced to have any other way.

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora Magazine: Jona Azizaj – Why Mentorship at Flock Changes Everything!

2026-06-08T08:00:00+00:00

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Jona Azizaj’s first Flock was ten years ago in Kraków, Poland. What struck her most was how approachable everyone was. In a community full of experienced contributors, people made space for new voices, listened to her experiences building the local community in Albania, and made her feel like her perspective genuinely mattered. Those small moments, she says, are what made her feel like she truly belonged.

A decade on, Jona sees Flock as one of the most powerful tools for growing the next generation of Fedora contributors. Online mentorship happens asynchronously and at a distance. Flock, however, creates something different: the chance to sit down with someone, share experiences, and build real trust. Flock is where contributors grow more confident, find their place, and realise that open source is about far more than technical work.

For Flock 2026, Jona and the Fedora Mentor Summit team are bringing three initiatives, now in their 5th edition.

The Fedora Contributor Recognition Program celebrating the quiet, meaningful work that often goes unnoticed.
A Lunch and Learn session creating a relaxed space for people to connect beyond their usual circles.
A sticker matching icebreaker providing first-time attendees an easy, low-pressure way to start conversations.

A successful Flock, for Jona, is one where people leave feeling more confident than when they arrived. It is an event where the connections built there carry on long after the event ends.

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora Magazine: Akashdeep Dhar – Contributing to Fedora Infrastructure and the Power of Flock!

2026-06-05T15:07:06+00:00

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the Commit History campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Akashdeep’s history with Flock goes back around five years, and his perspective on it has evolved significantly. During his time on the Fedora Council, he participated in the grueling process of reviewing over 150 talk proposals in a single cycle. This task was made harder by the fact that acceptance is often tied to sponsored travel meaning funding rejection can mean a contributor simply can’t attend at all.

But beyond the sessions and schedules, Akashdeep is emphatic about what Flock is really for. Roughly 75% of the experience is about human connection; understanding the person behind the screen, building friendships, and embodying the “friends foundation” philosophy at the heart of Fedora. Technical work is the bonus, not the point.

Nowhere is this clearer than in the story of the Fedora Badges revamp. Interest in rebuilding the platform which, despite its 2003-era interface, plays a vital role in motivating new contributors, dates back to 2019. But it was Flock’s hallway conversations and dedicated workshops that finally built the consensus needed to move the project forward.

Akashdeep also wants people to know that contributing to Fedora infrastructure is more accessible than it looks. You don’t need to be on a specific team or work for a particular company. Just join a chat, introduce yourself, and find your corner. As one contributor discovered, starting with documentation led to a whole journey into diversity and inclusion work. Community bonding is what keeps people, and the technical work is the reward.

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora Community Blog: Community Update – Week 23 2026

2026-06-05T10:00:00+00:00

Week: 01 – 05 June 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

Devise the flagging of inactive badges as a boolean column [Triaged]
feat: add legacy boolean column to badges [Approved]
Add unit tests for _serve_frontend path traversal safety [Suggested]
Add (or modify) methods to filter/modify the legacy status [Triaged] [Followup]
Moved fedora-badges to badges-assets [Repository] [Followup]
Mark the Pagure’s Fedora Badges repository as OBSOLETE [Commit] [Followup]
Revamp Fedora Badges Project (into develop) [Merged]
Port the project management aspect from Poetry to UV [Triaged A] [Triaged B]
Refreshed the Fedora Badges staging deployment [Resource]
Update badge rarity calculation [Reviewed] [Followup]
Modularize the dbapi module while retaining the references [Followup]
feat: normalize tags into separate tables [Review A] [Review B]
Readme.md file update [Closed] [Followup]
Update badge rarity calculation [Review A] [Review B]
rhel10 migration: tang servers
rhel10 migration: memcached instances
nftables cleanup, and table rename
discover why proxy11 struggles with restarting apache

CentOS Infra including CentOS CI

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

F44: core rebuild is completed. Image generation and repo-creation needs some work. ‘omni’ kernels are being built and ‘kiwi descriptions’ (required for image generation) needs some RISC-V specific patching. We’re short on resources , so this delay is expected.
Conferences preparation:
- Prep for RISC-V Summit, meetings with hardware vendors, upstream meetings, and RISE
- Prepare updated material for Flock RISC-V update
[Hardware] We have one of the newest RVA23 boards (SpacemiT K3) in Fedora RISC-V Koji.
- Thanks to Jason Montleon. It’s his personal hardware. A CLE-sponsored Fedora K3 builder is on its way to him too, it’ll be wired into RISC-V Koji
[Hardware] Discussed with Jefro about potentially working with Scaleway to get some cloud builders via the RISE initiative. To be discussed at the RISC EU Summit.

AI

This is the summary of the work done regarding AI in Fedora.

t0xic0d3r helped draft the Fedora AI Developer Desktop Community Objective logic model [Draft]

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.

Reported bugs related to Thinkpad X1 Carbon Gen14, a laptop that could be in the next laptop models offering for RHatters. Both the microphone and camera are broken. Notified the CSB team and Mark Pearson from Lenovo.
We missed an installer crash in F44 KDE and other spins (but not Workstation), documented it and took follow-up steps to prevent it in the future. We have flagged before that having multiple installer UIs and storage paths raises the risk of this kind of situation
Ongoing tool tech debt and enhancement work: reviving and fixing issuebot, MCP server and devcontainer config for testdays-web, cloud automation now reporting to resultsdb
cloud automation found systemd bug at AWS
openQA: deployments upgraded to Fedora 44 and new os-autoinst packages, fedora-media-writer coverage extended, discovered multiple dependency bugs, dracut decryption bug, plymouth keyboard layout bug, KDE config panel layout bug

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

Discussed the coordination process for the private issues
Enabled the members team to create repositories [Access]

EPEL

This team is working on keeping Epel running and helping package things.

Prepared EPEL 10.1 for move to archives
Package maintenance across multiple Fedora and EPEL packages
Quality work via bug reports and bodhi karma
Starting to onboard Pedro

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

Finalizing Flock materials
- Everything for print sent to organisers
- Digital assets is now the focus

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 23 2026 appeared first on Fedora Community Blog.

Fedora Badges: New badge: Flock 2026 Attendee !

2026-06-05T00:22:08+00:00

Fedora Infrastructure Status: Updates and reboots on Fedora infrastructure

2026-06-04T21:00:00+00:00

Fedora Magazine: Aleksandra Fedorova on Community, Flock, and the Human Side of Fedora

2026-06-04T08:00:00+00:00

Flock to Fedora is more than a conference — it’s where the Fedora community comes alive. As part of the #In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Aleksandra Fedorova’s journey into Fedora started with a sticker. At LinuxTag in Berlin, her first properly organised Linux community event she approached the Fedora booth simply wanting a sticker. What happened next changed everything. The people behind the booth invited her to join them on their side of the table. That single gesture dismantled the wall between user and contributor, and she never looked back.

For Aleksandra, Flock isn’t the place for deep technical work. Instead, it’s where the Fedora Council reads the room, sensing priorities, spotting coordination gaps, and picking up on tensions before they become real problems. She’s also refreshingly honest about Flock’s limitations: the costs of attending mean it’s not always a fully representative cross-section of the community, and understanding the broader Fedora ecosystem requires deliberate effort beyond the event itself.

But what Flock offers that nothing else can? The human element. No mailing list or Matrix channel lets you simply walk up to someone and start a conversation without a formal introduction. At Flock, the hallway is as valuable as the schedule. For Flock 2026, Aleksandra hopes the event helps ease current tensions; the reminder that everyone is working toward the same goal, even when they disagree on how to get there, is something only being in the same room together can provide.

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora Magazine: Fedora 43 Upgrade revealed 20 years old Outlook Security Bug

2026-06-03T19:19:57+00:00

Yes, the Fedora 43 upgrade brought an interesting revelation for all Outlook users—one that Microsoft is unlikely to be thrilled about. Outlook was not encrypting email connections, even though SSL/TLS was clearly enabled in the account settings. It looks like, that bug dates back to at least Outlook 2007, which is the oldest Outlook version I was informed about.

Let us start with the beginning

Every six months, Fedora Servers require and upgrade to the next release version, as you all know This May we had to upgrade from 42 to 43 and in this upgrade, Dovecot POP/IMAP server switched to version 2.4.3. Dovecot did us all an unexpected favor, because it required a full rewrite of the used service config, because it’s not backwards compatible. This change introduced a new paradigm: PLAIN TEXT passwords are no longer allowed over unencrypted connections.

This is a major break with the oldest RFCs (i.e. RFC 1081) regarding POP3 behavior, but a good one IMHO. No one should still use unencrypted connections to any form of service on the internet when we have easy to use encryption protocols like STARTTLS (STLS) at hand in any major client.

The Day After

After the upgrade, “we” (admins & customers) did not even know about the now broken auth-mechanism. This came a day later when customers started to call the support line about rquesters popping up for them to enter their passwords again. This is a normal behavior if auth fails… and it failed hard

As all admins know, such upgrades will result in higher amounts of support calls. To my surprise it was all Outlook clients that called. The oldest version so far was Outlook 2007. We even had an old MACOS Outlook :-). They all had in common, that the mailbox prefs had “SSL/TLS” enabled, but used Port 110, which is the old cleartext port for POP3, where port 995 is the correct SSL port. A normal mailclient would change the port number to 995 as soon as you enable SSL/TLS encryption. This is because you can’t “speak” SSL on a non-ssl port, except if you choose STARTTLS. This starts as a cleartext connection, but upgrades itself to ssl-encrypted later.

“Look, there is something out there!”

Outlook did the worst move you can take as a security enhanced app. It silently ignored the choosen SSL option and used the unencrypted port 110 without any notice to the user. After our server upgrade, the following message popped up:

German version of the error message

“-ERR [AUTH] Cleartext authentication disallowed on non -secure ( SSL/TLS ) connections.“ popped up if you tried to open your inbox. The server logs revealed it clearly: the user used a non-secure connection and got this message correctly. This never got noticed since the EU GDRP only states, that corporations and organisations need to protect their data via a transport encryption like TLS. Normal persons don’t need to do so.

Even some of the notable folks of Fedora did not use encryption, which I personally advise to change immediately. Having this in mind, who are we to judge if you encrypt your connection or not?

Really folks: use TLS encryption for your mailboxes!

You can easily check if TLS encryption is working. Send yourself an mail and open the mail headers, you will find lines like this:

Received: from bastion01.fedoraproject.org ([38.145.32.11] helo=bastion.fedoraproject.org)
by s113.resellerdesktop.de with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384
(Exim 4.99.2)
(envelope-from <updates@fedoraproject.org>)
…
Any good MTA ( Exim, Postfix, etc. ) will note if the connection was encrypted or not.

If you don’t see an encryption notice, you can use this command:

tcpdump -A -n -n port 110 or port 143

in a root terminal and see if the unencrypted port is used for transport. If so, if it’s cleartext or if it’s using STLS.

So… THANKS Fedora 43 and Dovecot 2.4 … you revealed a 20 year old security bug in Outlook \o/

Disclaimer: It is possible that MS patched the Outlook UI in the past in a way that only old accounts are affected by this major fail. As Fedora users we had no Outlook available to test this

Source: https://marius.bloggt-in-braunschweig.de/2026/06/03/outlook-hat-emailverbindung-nicht-verschluesselt/

Fedora Magazine: Valentin Rothberg on Building the Future of Fedora Containers

2026-06-03T08:00:00+00:00

Valentin Rothberg’s journey into container-native Linux didn’t start with a grand plan – it started with the work. After over 8 years at Red Hat contributing to projects like Podman and bootable containers, Fedora felt like the natural home for his next chapter. In Summer 2025 he began working on Project Hummingbird, which builds directly on top of Fedora. Flock 2026 is where he wants to share what he’s learned.

His first Flock was in Budapest in 2019 – and he remembers it vividly. Stepping in at the last minute for Dan Walsh, he ended up presenting for over three hours straight on container technologies. Not a bad way to make an entrance.

For Valentin, Flock’s value isn’t primarily technical. Technical decisions tend to be made comparatively fast once a group of people rally around a cause. What matters is finding that cause together, and in-person time is what makes that possible. The implementation details, he says, are just details.

He’s also refreshingly honest about where Fedora stands in the container ecosystem. Despite being the birthplace of tools like Podman, Fedora containers don’t see wide use outside the community. Valentin has ideas about why, and how to change that. He’s coming to Flock not to present answers, but to hear other perspectives and build something together.

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora Magazine: From Antarctica to FPL : Jef Spaleta on Leading Fedora Into Its Next Chapter

2026-06-02T22:40:26+00:00

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the “CommitHistory” campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Jef Spaleta came back to Fedora at exactly the right moment. After years away, working across software startups and following his spouse’s move back to the east coast, the timing aligned perfectly with the previous project leader stepping down. With a sharpened skill set and fresh perspective, Jef felt ready to lead.

But leading Fedora in 2026 isn’t just about keeping the lights on. Jef sees the project at a critical crossroads. There is a generational transition where original founders are stepping away and institutional knowledge risks disappearing with them. His focus? Mentoring the next wave of contributors to keep Fedora sustainable for the next five to ten years.

On the state of the project, Jef is honest: Fedora continues to ship high-quality releases on schedule, a streak held for five or six years. But stability isn’t enough. He is developing a new Fedora innovation lifecycle, a dedicated space for experimental work where things can be tried, broken, and learned from without disrupting the mature processes the project depends on.

For Jef, Flock’s value is simple but profound. Digital tools work well when everyone agrees, but they fall apart when things get hard. Flock is where relationship repair happens, where tone and intent can finally be communicated in ways text never can. Looking ahead to Flock 2026, he is focusing on two priorities. First, migrating Forge infrastructure to meet the expectations of the next generation of developers, and second, shaping Fedora’s approach to AI-assisted development before the conversation shapes itself.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel. We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora Magazine: #Commit History: Tell Us About Your First Commit

2026-06-02T14:11:26+00:00

Maybe it was a one-line typo fix in the docs. Perhaps it was a package you’d been maintaining in secret for months before you finally submitted it. Maybe it was completely terrifying, or maybe it just felt like the most natural thing in the world. Whatever it was we want to hear about it.

Ahead of Flock to Fedora 2026 (June 14–16, Prague), We the Fedora CommOps team are launching #Commit History: a community campaign to collect the origin stories of Fedora contributors – the moments that brought people into this project and kept them here.

The best stories will be featured in a Fedora Magazine article published before Flock 2026, celebrating the people who make this project what it is.

Here are the questions used to get started-

What was your first contribution to Fedora – and what made you take that first step?

What did it feel like? What went wrong (or right)?

Looking back, what did that moment mean for your open source journey?

There are no wrong answers. First commits come in all shapes code, documentation, translations, design, bug reports, community work. If you’ve ever contributed to Fedora, your story belongs here.

How to share: Drop your story in the comments below, or share it on Mastodon with the hashtag #Commit History.

Whether you’ve been contributing for a decade or made your first commit last week – we want to hear from you.

Fedora Infrastructure Status: Planned Outage - Fedora Copr - copr-backend upgrade

2026-06-02T09:00:00+00:00