/rss20.xml">
fedora

Fedora People
Blog List
RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll

Infra and RelEng Update – Week 03 2025

Posted by Fedora Community Blog on 2025-01-17 10:00:00 UTC

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 13 – 17 January 2025

I&R infographic

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

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

Major update of Anitya from 1.10.0 to 2.0.0 on 2025-01-10: https://github.com/fedora-infra/anitya/releases/tag/2.0.0

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

The post Infra and RelEng Update – Week 03 2025 appeared first on Fedora Community Blog.

pagure.io outage

Posted by Fedora Infrastructure Status on 2025-01-15 02:00:00 UTC

pagure.io is currently unreachable due to network issues. We have reported them and are waiting for a solution/ETA.

The network has returned.

Running Stable Diffusion with AUTOMATIC1111 locally

Posted by Fedora Magazine on 2025-01-13 08:00:00 UTC

Generative AI continues to make strides, enabling developers and enthusiasts to create everything from realistic images to intricate artworks using AI models. Stable Diffusion, one of the leading image generation models, allows users to generate high-quality images from text prompts. AUTOMATIC1111 provides a powerful and user-friendly interface for running Stable Diffusion locally, offering a range of customization options and extensions.

In this article, we will cover:

  1. Setting up Stable Diffusion with AUTOMATIC1111 on Fedora.
  2. Running Stable Diffusion on localhost.
  3. Integrating Stable Diffusion with OpenWebUI.
  4. Generating images using prompts and interacting with LLaMA 3.3.

What is Stable Diffusion?

Stable Diffusion is a state-of-the-art text-to-image generation model developed by Stability AI. It is designed to take natural language prompts and generate corresponding images with impressive fidelity and diversity. Unlike cloud-based solutions, running Stable Diffusion locally ensures greater control, privacy, and flexibility.

What is AUTOMATIC1111?

AUTOMATIC1111 is a popular web-based interface for Stable Diffusion, designed for ease of use while offering extensive features for customization, fine-tuning, and extension support. With a clean UI and powerful backend, it has become the go-to solution for those looking to run Stable Diffusion locally.

Setting Up Stable Diffusion with AUTOMATIC1111

Before starting, ensure your Fedora system meets the following requirements:

  • Python 3.10 or later installed (I’ve tested with 3.10.14 and 3.10.16)
  • NVIDIA GPU with CUDA support (for GPU-based inference) or AMD
  • Sufficient disk space for model files (at least 10GB)
  • Podman installed (for OpenWebUI integration)

Installing Dependencies

$ sudo dnf install make gcc openssl-libs zlibrary-devel bzip2-devel readline-devel sqlite3pp-devel wget
curl llvm ncurses* xz-devel tk-devel libffi-devel zlib* liblzma* openssl*

Setting Up Python with pyenv

To manage different Python versions efficiently, we recommend using pyenv. Follow these steps to install and configure Python 3.10 using pyenv:

  1. Install pyenv: curl https://pyenv.run | bash
  2. Install Python 3.10 using pyenv: pyenv install 3.10
  3. Set Python 3.10 as the global version: pyenv global 3.10

It is now necessary to export $PATH to bashrc and reload bashrc to complete the pyenv setup. The following commands will help.
Pyenv will prompt : export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init - bash)"
Reloading .bashrc : source .bashrc

Cloning the AUTOMATIC1111 Repository

AUTOMATIC1111 provides a GitHub repository that contains all necessary scripts for running Stable Diffusion locally. Let’s start by creating a directory.

$ mkdir stable-diffusion && cd stable-diffusion

Clone the repository using the following command:

wget -q https://raw.githubusercontent.com/AUTOMATIC1111/stable-diffusion-webui/master/webui.sh

Making the webui.sh : chmod +x webui.sh
Running ./webui.sh

Note : if you are getting this error:

RuntimeError: Torch is not able to use GPU; add –skip-torch-cuda-test to COMMANDLINE_ARGS variable to disable this check

executing the command .webui.sh as follows should help!

export COMMANDLINE_ARGS="--medvram --opt-split-attention --skip-torch-cuda-test"
./webui.sh

Once the interface is running, open your browser and navigate to http://localhost:7860 to start generating images using text prompts.

Integrating Stable Diffusion with OpenWebUI

OpenWebUI provides a unified graphical interface for interacting with multiple AI models, including LLMs like LLaMA. Integrating Stable Diffusion with OpenWebUI allows users to interact with both text and image generation models from a single interface.

Running OpenWebUI with Stable Diffusion Support

To enable Stable Diffusion in OpenWebUI, we need OpenWebUI to run locally with models loaded the appropriate container configuration. The process is explained in my previous article for running Open WebUI and Llama locally. Once everything is set, we need to kill all instances of webui.sh and relaunch it with two switches as follows:

./webui --listen --api

Loading OpenwebUI’s setting for any Admin/User profile will have a section for Images and one should be able to add the Automatic1111’s base URL in my case it’s 127.0.0.1:7860.

Interacting with LLaMA 3.3 and Generating Images

Once OpenWebUI is up and running with Stable Diffusion integrated, you can start interacting with LLaMA 3.3. Here’s how you can generate an image using a prompt:

  1. Input a creative text prompt.
  2. Allow LLaMA 3.3 to process the prompt and pass it to Stable Diffusion.
  3. View the generated image directly in the OpenWebUI interface.

In my case, Llama3.3 gave me an elaborate prompt for my rudimentary string. The image icon can be used to generate the image.

Conclusion

By following this guide, you can set up Stable Diffusion with AUTOMATIC1111 on Fedora and enhance your experience by integrating it with OpenWebUI. This setup provides a powerful local environment for both text and image generation, offering flexibility, privacy, and impressive results. Whether you’re a developer, artist, or AI enthusiast, running these models locally opens up new possibilities for creativity.

Infra and RelEng Update – Week 02 2025

Posted by Fedora Community Blog on 2025-01-10 14:49:56 UTC

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 06 – 10 January 2025

Infra&Releng Infographic

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

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

Minor update of Fedora Messaging from 3.6.0 to 3.7.0 on 2025-01-03

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

The post Infra and RelEng Update – Week <week number=""> 02 2025</week> appeared first on Fedora Community Blog.

Running Generative AI Models Locally with Ollama and Open WebUI

Posted by Fedora Magazine on 2025-01-07 08:00:00 UTC

Artificial Intelligence, particularly Generative AI, is rapidly evolving and becoming more accessible to everyday users. With large language models (LLMs) such as GPT and LLaMA making waves, the desire to run these models locally on personal hardware is growing. This article will provide a simple guide on setting up Ollama—a tool for running LLMs locally—on machines with and without a GPU. Additionally, it will cover deploying OpenWebUI using Podman to enable a local graphical interface for Gen AI interactions.

What is Ollama?

Ollama is a platform that allows users to run LLMs locally without relying on cloud-based services. It is designed to be user-friendly and supports a variety of models. By running models locally, users can ensure greater privacy, reduce latency, and maintain control over their data.

Setting Up Ollama on a Machine

Ollama can be run on machines with or without a dedicated GPU. The following will outline the general steps for both configurations.

1. Prerequisites

Before proceeding, ensure you have the following:

  • A system running Fedora or a compatible Linux distribution
  • Podman installed (for OpenWebUI deployment)
  • Sufficient disk space for storing models

For machines with GPUs, you will also need:

  • NVIDIA GPU with CUDA support (for faster performance)
  • Properly installed and configured NVIDIA drivers

2. Installing Ollama

Ollama can be installed with a one-line command:

curl -fsSL https://ollama.com/install.sh | sh

Once installed, verify that Ollama is correctly set up by running:



ollama --version

Running LLMs Locally

After setting up Ollama, you can download a preferred model and run it locally. Models can vary in size, so select one that fits your hardware’s capabilities. For example: I would personally use llama3.3 70B model. That is around 42GiB and might not fit everyone. There *is* a model for everyone, even for raspberrypis -YES. Please find one that you will be fit for your system here .
On machines without a GPU, Ollama will use CPU-based inference. While this is slower than GPU-based processing, it is still functional for basic tasks.

Once you are done, running ollama run <model_name> will work!

Ollama CLI bring up the moment the model and tells me about 25th December

Deploying OpenWebUI with Podman

For users who prefer a graphical user interface (GUI) to interact with LLMs, OpenWebUI is a great option. The following command deploys OpenWebUI using Podman, ensuring a seamless local setup.

1. Downloading OpenWebUI Container

Start by pulling the OpenWebUI container image:

podman run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main
Ollama API is exposed(by default) at 127.0.0.1:11434 hence the mapping

2. Running the OpenWebUI Container

Once the image is downloaded, running ; ensure by running podman ps to list the existing containers. Access the OpenWebUI interface by opening your web browser and navigating to localhost:8080

Open WebUI will help you create one or multiple Admin and User accounts to query LLMs. The functionality is more like an RBAC—you can choose to customize which model can be queried by which User and what type of generated responses it “should” be giving. The features help set guardrails for users who intend to provision accounts for a specific purpose.

On the top-left, we should be able to select models. You can add more models by simply running ollama run <model_name> and then refreshing the localhost when the fetching is complete. It should let you add multiple models.

Interacting with the GUI

With OpenWebUI running, you can easily interact with LLMs through a browser-based GUI. This makes it simpler to input prompts, receive outputs, and fine-tune model settings.

Using LLaVA for Image Analysis

LLaVA (Large Language and Vision Assistant) is an extension of language models that integrates vision capabilities. This allows users to upload images and query the model about them. Below are the steps to run LLaVA locally and perform image analysis.

1. Pulling the LLaVA Container

Start by pulling the LLaVA model: ollama pull llava

2. Running LLaVA and Uploading an Image

Once the model is download, access the LLaVA interface via web UI on the browser. Upload an image and input a query, such as:

LLaVA will analyze the image and generate a response based on its visual content.

Other Use Cases

In addition to image analysis, models like LLaVA can be used for:

  • Optical Character Recognition (OCR): Extract text from images and scanned documents.
  • Multimodal Interaction: Combine text and image inputs for richer AI interactions.
  • Visual QA: Answer specific questions about images, such as identifying landmarks or objects.

Conclusion

By following this how-to, you can set up a local environment for running generative AI models using Ollama and OpenWebUI. Whether you have a high-end GPU or just a CPU-based system, this setup allows you to explore AI capabilities without relying on the cloud. Running LLMs locally ensures better privacy, control, and flexibility—key factors for developers and enthusiasts alike.

Happy experimenting!

Managing IPv4 Address Conflict Detection with NetworkManager

Posted by Fedora Magazine on 2025-01-01 08:00:00 UTC

This article describes address conflict detection with NetworkManager, providing examples to demonstrate the new features.

Detecting any potential address conflict in IP networks is paramount to avoid issues such as:

  • Intermittent connectivity.
  • Transmission errors.
  • Downtime.

The mechanisms to avoid IP address conflicts vary depending on the IP protocol version, and are valid for both static and dynamic IP.

RFC 4862, published in 2007, defines a Duplicate Address Detection (DAD) procedure as a mechanism to avoid duplicated IPv6 addresses.

In 2008, RFC 5227 established the IPv4 Address Conflict Detection (ACD). This mechanism broadcasts ARP probe packets to detect duplicated IPv4 addresses.

Fedora 40 introduced an important change for NetworkManager. Since that release, the ACD mechanism is enabled by default, waiting up to 200ms for a duplicated IP in the network.

With this feature, when an IP address is already in use, NetworkManager won´t configure the interface and it will notify the MAC address currently linked to that IP address.

The following section shows the ACD mechanism in action.

Testing the feature in Fedora 41:

We have two systems with Fedora 41 where we’ll configure the interfaces enp0s8 with the same IP address: 10.0.0.2/24. These are named VM1 and VM2.

Fedora system VM1:

The device enp0s8 appears as disconnected:

# cat /etc/fedora-release
Fedora release 41 (Forty One)
# nmcli dev
DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
lo      loopback  connected (externally)  lo
enp0s8  ethernet  disconnected            --

Now acquire the MAC address of enp0s8 for later checks:

# nmcli -f general.hwaddr dev show enp0s8
GENERAL.HWADDR:                         08:00:27:09:58:BA

Now start a packet capture (in background) over enp0s8 to verify the behavior when NetworkManager tries to configure the network interface:

# tcpdump -i enp0s8 &
[1] 1789
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), snapshot length 262144 bytes

Through NetworkManager CLI (nmcli) the following command will configure the IP address 10.0.0.2/24 in enp0s8 in VM1:

# nmcli con add con-name enp0s8 ifname enp0s8 type ethernet ip4 10.0.0.2/24 ipv6.method disabled
Connection 'enp0s8' (78af198d-a052-456c-9f69-17bb50dabf60) successfully added.

The results of the last command shows the ARP request sent by broadcast to verify the IP address 10.0.0.2 is available.

00:18:09.030677 ARP, Request who-has 10.0.0.2 tell 0.0.0.0, length 28
00:18:09.056795 ARP, Request who-has 10.0.0.2 tell 0.0.0.0, length 28
00:18:09.114868 ARP, Request who-has 10.0.0.2 tell 0.0.0.0, length 28

There is no answer to that query, so the IP address is successfully configured in enp0s8:

# nmcli dev
DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
enp0s8  ethernet  connected               enp0s8
lo      loopback  connected (externally)  lo

# ip -br addr show enp0s8
enp0s8           UP             10.0.0.2/24

Fedora system VM2:

The device enp0s8 appears as disconnected:

# cat /etc/fedora-release
Fedora release 41 (Forty One)

# nmcli dev
DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
lo      loopback  connected (externally)  lo
enp0s8  ethernet  disconnected            --

Now acquire the MAC address of enp0s8 at VM2:

# nmcli -f general.hwaddr dev show enp0s8
GENERAL.HWADDR:                         08:00:27:EF:CE:FD

Before configuring the IP address in enp0s8, capture packets in the interface:

# tcpdump -i enp0s8 &
[1] 1342
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), snapshot length 262144 bytes

Now, configure the same IP address 10.0.0.2/24 that was set in VM1:

# nmcli con add con-name enp0s8 ifname enp0s8 type ethernet ip4 10.0.0.2/24 ipv6.method disabled
Connection 'enp0s8' (62f5b868-097b-4c7f-85ac-d4aa70f1db68) successfully added.

From the tcpdump the ARP requests asking for the MAC linked to 10.0.0.2 can be seen. This time the replies are pointing to MAC address of enp0s8 at VM1: 08:00:27:09:58:BA

00:32:16.787092 ARP, Request who-has 10.0.0.2 tell 0.0.0.0, length 28
00:32:16.791156 ARP, Reply 10.0.0.2 is-at 08:00:27:09:58:ba (oui Unknown), length 46
00:32:17.026120 ARP, Request who-has 10.0.0.2 tell 0.0.0.0, length 28
00:32:17.030038 ARP, Reply 10.0.0.2 is-at 08:00:27:09:58:ba (oui Unknown), length 46
00:32:17.236314 ARP, Request who-has 10.0.0.2 tell 0.0.0.0, length 28
00:32:17.240817 ARP, Reply 10.0.0.2 is-at 08:00:27:09:58:ba (oui Unknown), length 46

As the IP is already used by VM1, the NetworkManager will not configure enp0s8 in VM2. The device will still appear as disconnected without IP address set:

# nmcli dev
DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
lo      loopback  connected (externally)  lo
enp0s8  ethernet  disconnected            --

# ip -br addr show enp0s8
enp0s8           UP

Now check the NetworkManager´s logs from the system´s journal:

# journal -xe
... output omitted ...
vm2 NetworkManager[809]: <info>  [1733739965.4208] device (enp0s8): state change: config -> ip-config (reason 'none', managed-type: 'full')
vm2 NetworkManager[809]: <warn>  [1733739965.4400] device (enp0s8): IP address 10.0.0.2 cannot be configured because it is already in use in the network by host 08:00:27:09:58:BA
vm2 NetworkManager[809]: <info>  [1733739965.4403] device (enp0s8): state change: ip-config -> failed (reason 'ip-config-unavailable', managed-type: 'full')
vm2 NetworkManager[809]: <warn>  [1733739965.4406] device (enp0s8): Activation: failed for connection 'enp0s8'

The output above describes the default behavior for Fedora 40 and later. However, it introduces up to 200 ms delay in performing the duplicate IPv4 check as mentioned above.

Can the IPv4 Conflict Detection be tailored for particular use cases?

Yes. Sometimes, the delay for a specific use cases can be reduced or the ACD mechanism may be turned off. This is possible to achieve through the ipv4.dad-timeout property. When this property is set to 0, the IP duplicated check is disabled. This can be set globally or per network interface.

Getting back to the previous example, we can turn off the ACD mechanism in the enp0s8 interface at VM 2 when configuring the IP address 10.0.0.2/24:

# nmcli con add con-name enp0s8 ifname enp0s8 type ethernet ip4 10.0.0.2/24 ipv6.method disabled ipv4.dad-timeout 0
Connection 'enp0s8' (ff6bfee8-8562-44a0-8584-ec1a4eaef704) successfully added.

This time, the network interface will appear with the IP address successfully set:

# nmcli con show
NAME    UUID                                  TYPE      DEVICE
enp0s3  592c6372-3025-3daa-8c3f-9209022d61ed  ethernet  enp0s3
enp0s8  ff6bfee8-8562-44a0-8584-ec1a4eaef704  ethernet  enp0s8
lo      cfda4123-c93a-40c1-a4b6-f7fd3e06db1f  loopback  lo

# ip -br addr show enp0s8
enp0s8           UP             10.0.0.2/24

As was seen above, disabling ACD will allow configuring a duplicated IPv4 address in the network. This is something to avoid unless the configuration approach followed can guarantee an IPv4 address duplication is unlikely or impossible to occur in the network.

System insights with command-line tools: lslogins and lsmod

Posted by Fedora Magazine on 2024-12-30 08:00:00 UTC

Continuing our exploration of commands that provide insights into the inner workings of your Fedora Linux system, we turn our focus to more simple ones like lslogins and lsmod. These tools offer information about user accounts and kernel modules, respectively.

lslogins: Look into User Accounts

lslogins is a command that extracts and displays detailed information about user accounts on your system. It pulls data from /etc/passwd and /etc/shadow files, along with system logs, to give you a comprehensive overview. It is especially useful to look for login failures and to list group memberships.

Basic Usage

Run the command without arguments to display a summary of all user accounts:

lslogins

This provides an overview including UID (User ID), GID (Group ID), user name, and last login details.

Common options and usage example

  • -u: Display only user accounts and root (filtering out system accounts with UIDs below 1000).
  • -G: Display information about exiting groups
  • -g <group>: Show users of a specific group (e.g. wheel which usually has sudo-permissions on a Red Hat system).
  • -e: Display in an export-able key-value output format, separated by space.
  • -L: List last logins and password information (empty, logged, nologin).

Examples, listing the last logins and password information (empty, logged, nologin) of non-system user accounts on my laptop as well as group memberships:

$ lslogins -L -p -u
 UID USER      LAST-TTY LAST-HOSTNAME LAST-LOGIN PWD-EMPTY PWD-LOCK PWD-DENY NOLOGIN HUSHED PWD-METHOD
   0 root                                                                          0        
1000 ahaerter  tty2     tty2               01:16                                   0      0

$ lslogins -G -u
 UID USER       GID GROUP     SUPP-GIDS  SUPP-GROUPS
   0 root         0 root                 
1000 ahaerter  1000 user      971,10,977 docker,wheel

lsmod: Listing Kernel modules for further inspection

The Linux kernel is fundamentally monolithic in design, but it also provides the capability to load and unload modules at runtime. A kernel module is generally understood as a component or an extension of the kernel. For example, hardware drivers (e.g., Wi-Fi cards, sound cards, etc.) are usually implemented as modules. The lsmod command provides a nice overview of all currently loaded kernel modules.

Basic usage

Simply type:

lsmod

This displays a table with three columns:

  1. Module: The name of the kernel module.
  2. Size: The memory size (in bytes) the module occupies.
  3. Used By: Lists the dependent modules or kernel features.

Example output:

$ lsmod
Module                  Size  Used by
overlay               241664  0
tun                    73728  2
snd_usb_audio         614400  0
snd_usbmidi_lib        57344  1 snd_usb_audio
snd_ump                49152  1 snd_usb_audio
snd_rawmidi            57344  2 snd_usbmidi_lib,snd_ump
hid_jabra              16384  0
uinput                 20480  0
rfcomm                102400  16
snd_seq_dummy          12288  0
snd_hrtimer            12288  1
wireguard             122880  0
curve25519_x86_64      36864  1 wireguard
libcurve25519_generic    45056  2 curve25519_x86_64,wireguard
ip6_udp_tunnel         16384  1 wireguard
udp_tunnel             36864  1 wireguard
nf_conntrack_netbios_ns    12288  1
nf_conntrack_broadcast    12288  1 nf_conntrack_netbios_ns
nft_fib_inet           12288  1
nft_fib_ipv4           12288  1 nft_fib_inet
nft_fib_ipv6           12288  1 nft_fib_inet
nft_fib                12288  3 nft_fib_ipv6,nft_fib_ipv4,nft_fib_inet
[...]

Usage examples

While lsmod doesn’t have options, pairing it with other commands enhances its utility:

  • Combine with modinfo: Get detailed information about a specific module, including its author, license, and description.
  • Debug with dmesg: Correlate kernel log messages with loaded modules to diagnose boot-time issues.
modinfo <module_name>
sudo dmesg | grep <module_name>

Conclusion

Commands like lslogins and lsmod can give you easy insights into user management and kernel behavior. Try them out today, and think about combining their output with other tools to appreciate their capabilities.

Fedora Chooses Forgejo!

Posted by Fedora Community Blog on 2024-12-24 16:31:46 UTC

The Fedora Council is pleased to announce that we have chosen Forgejo as the replacement for our git forge! That means you’ll see Forgejo powering our package sources (src.fedoraproject.org) as well as our general git forge (what pagure.io is today). It has been a long road to get here, and we cannot thank the Fedora community enough for your patience and support throughout. 

For deeper context into what went into this decision, we will walk you through the last few months from the council’s perspective. You may want to grab a tea or coffee or beverage — this might be a few paragraphs long 🙂

In the beginning

If you’d like to read more about the early stages of this saga, please visit the announcement from two weeks ago. There are lots of helpful links to more documentation about the investigation of both GitLab and Forgejo, as well as more detail about the history of this change.

We have liftoff!

This all officially started after the Council’s face-to-face meeting in February 2024. We made a list of all potential replacements for Pagure, including Pagure itself. Over the course of several hours, we ruled out almost all of the candidates, for various reasons, and in the end we were left with Forgejo and GitLab CE (self-hosted). We published a blog post about this, and then got to work figuring out requirements to hand to the team doing this investigation. As Fedora Council is a main governing body of the entire project, we tried to keep the requirements to the project’s holistic needs, and not weigh in on too many technical aspects — those would be better reviewed by our community and FESCo. So, with two options to choose from and a list of requirements to investigate them against, we began the formation of the git forge investigation 2024.We just needed the right folks to be part of the investigation team. Enter CLE!

The council made an official request to the Community Linux Engineering team (CLE, which includes the former CPE) to drive an investigation into the two options. The investigation team, ARC (“Advance Recon Crew”) launched the investigation in May 2024 with a call to all folks who would be impacted by a change to our current dist-git setup. They asked for use-cases in the form of user stories so they had a better picture of what Fedora needs. Since dist-git has more specific technical demands than general project hosting, the investigation centred around dist-git — we started with the hardest part first!

Throughout 2024, the investigation team promoted awareness of the upcoming change by speaking at Fedora release parties and at Flock, and by the summer they had managed to deploy a test instance of each forge option, to evaluate  each use case. The results of that are can be read at the ARC team’s read-the-docs page. 

Options, so many options!

The Council requested a write up comparing each option. It was sweet to hear that there are no insurmountable ‘blockers’ for Fedora in terms of technical effort, but also bittersweet as it was going to be harder to make a final decision.

Accessibility

Both projects prioritize accessibility as a core value and implement UI best practices. However, Forgejo faces challenges, as it heavily relies on Fomantic UI, a framework not inherently accessibility-friendly. While Forgejo’s upstream, Gitea, applies patches to improve accessibility, significant issues remain that require time and effort to resolve. Accessibility is important to Fedora, and a strategic priority for the Council, and Forgejo lists it as one of their core values, so we hope to collaborate on making this better.

Functionality

In terms of issue tracking, GitLab limits some critical features to premium tiers, while Forgejo offers all functionality without restrictions or fees.

An interesting distinction is syntax highlighting: both solutions leverage the same JavaScript library, but Forgejo uniquely highlights RPM spec files by default.

GitLab supports auto-merging of merge requests, allowing users to define rules for automatic merges once conditions are met. Forgejo lacks this feature. However, its implementation of “actions” is API-compatible with GitHub Actions, enabling potential integration with third-party services or custom pipelines—albeit with significant development effort required.

Maintenance

Forgejo’s deployment documentation is relatively sparse, but Codeberg, a reference deployment, successfully supports over 143,000 registered users. The deployment is documented and available in Codeberg Infrastructure repositories (They even use Ansible!). GitLab offers more comprehensive versioned documentation, covering deployment, security, and maintenance. Additionally, GitLab provides an official OpenShift operator for GitLab CE, ensuring seamless container-based deployment.

Contribution

GitLab CE operates under the MIT license, while Forgejo uses GPLv3 or later.

  • GitLab CE: Actively synchronizes with its proprietary upstream, which is highly active (over 30,000 commits to the main branch in 2024, from 1435 distinct contributors). However, contributions are only accepted for the Enterprise Edition (EE). The official “community fork” has only 5 accepted merge requests ever.
  • Forgejo: While less active upstream (about 3500 commits in 2024, from 250 contributors), Forgejo and its base, Gitea, accept contributions openly from all users, clearly a more inclusive development process.

Quality (Fedora QA)

By the time Fedora QA were in a position to look into each option for their use cases, the Council had already been trending towards choosing Forgejo. So in an effort to reduce time, we asked the QA team to just look at Forgejo when validating their use cases. QA found the majority of their use cases to be either working or likely working (meaning even though the Forgejo configuration and deployment details are not completely finalized at the moment, and see a path forward for satisfying their needs). However, they did identify several concerning shortcomings in Forgejo’s issue tracking features. None of them seem to be a complete blocker, at least from QA perspective, but they are highly-visible regressions and other parties might be affected by them as well, and will need to be prioritized in reconciling them before a migration can happen. Priority will be given to having the ability to move issues between repos to help with debugging, being able to search all of dist-git combined in order to avoid duplication of bugs being reported or opened, and to be able to create private issues in public repositories.

Reaching the decision

After tracking the investigation for months, the Fedora Council had multiple meetings both on Matrix chat and in video conferences to ask questions about each forge and to improve our understanding of just how big this change will be. In one meeting, the council needed to refresh our requirements list to make sure we were asking for the right information at the end of the report. We had initially wanted no recommendation from the investigation team from the report, however as the work continued, it became necessary to change that to needing a recommendation. The investigation team could find no technical blockers to recommend one forge over another, both will require work.  This brought about several conversations amongst council members as to whether they already had a preference for one option or the other. It was great conversation and it appeared that once again Forgejo was taking the lead on virtue of their open-source nature. Some of us on the council liked the well documented, and somewhat familiar option of GitLab, but when faced with the reality that sometime in the near future, Fedora may find itself needing to make changes to our git forge, and one option might require money we don’t have, or not allow the changes we might need to make, and we did not want to limit the project in any way. And so, Forgejo galloped on down to the finish line!

One pivotal conversation was with the ARC team lead, where they walked the council through a mapping of use cases. This included complexity estimates for the sysadmin and developer work needed to deploy either option.

The diagram shows personas in the project like packagers, developers, etc and how they interact with a git forge in Fedora. The numbers indicate how complex the interaction is with the forge, with 1 being low and 10 being highest. These complexity numbers were determined from lack of documentation on how the services and features work in Fedora. Added caution was used as the team was unfamiliar with how some personas work, and with no documentation to work from….well, best put 10’s across the board for some things 🙂 For others, like packaging, and being a general user of Fedora  and other similar personas, because of good documentation available on those workflows, the team felt like they could follow the logic and did not add any complexity number. That is not to say that there won’t be any difficulties to overcome when we deploy and begin to use Forgejo for these personas, but I think we can all agree that the complexity can certainly lessen a bit when you have good (or any!) documentation on how something is set up and you feel more confident you can make it work!

After we announced the Council’s lean towards Forgejo, we asked the community for one last sanity check on this big decision. Two weeks have passed, and the feedback has been largely positive with no technical objections to this choice. A Council ticket captured: APPROVED by unanimous consensus with no abstentions (+9, 0, 0). Fedora will move to Forgejo!

State of Play

 We have made the decision to choose Forgejo, and will look to our community to help plan and execute the migration. The CLE team has already done some investigation into how our dist-git setup works, so if you would like to learn about it you can read the overview here. Please be prepared to see this work happening slowly, and likely across multiple releases. We will continue to focus on dist-git functionality first, and eventually finish with project hosting. This will take time and your patience will be invaluable and greatly appreciated. For right now, a lot of folks are away from their computers to enjoy some time with friends and family so we will start this change in January.

The next chapter

There is a lot still unwritten for Fedora’s git forge change. We are only scratching the surface, but we have taken an important step forward – choosing our path. We will have to take our time and break this down into smaller phases so we don’t get overwhelmed, so if you’re wondering about bugzilla and the project’s bug tracking future, don’t worry – we are too! We will be exploring that too if not exactly as part of this per se, but rather a logical next step and something we will be keeping in mind. Our focus is to deploy Forgejo, develop the features the project needs to build and release Fedora Linux and function as a project, and replace the existing forges with the new solution.

In January 2025, there will be open meetings happening every Wednesday from January 15th on Matrix. If you would like to be involved with this work, or have any questions, please do join that meeting. The details can be found on the releases calendar in Fedocal. We will also use the tag #git-forge-future when posting on discussion.fpo and we intend to see this plan take the form of an overall change request not tied to any release, with several smaller change requests tied to it which we hope will allow us make this project-wide change in controlled and careful increments.

On behalf of the Fedora Council, I would like to once again thank you all for your contribution to this change, and most importantly to the investigation team who took this on and have done an excellent job reviewing Forgejo for Fedora. I look forward to 2025, it will be a big year! 

The post Fedora Chooses Forgejo! appeared first on Fedora Community Blog.

F41 Election Results

Posted by Fedora Community Blog on 2024-12-23 12:54:33 UTC

The Fedora Linux 41 election cycle has ended. We had one group eligible for an election campaign this cycle. Below are the results of the FESCo election, and Mindshare Committee election. Thank you to all who participated, both voters, especially our great candidates and congratulations to the elected members!

FESCo

Five FESCo seats were open this election. A total of 166 voters participated and cast 729 ballots, meaning a candidate could accumulate up to 996 votes.

# VotesCandidate
709Kevin Fenzi
527Zbigniew Jędrzejewski-Szmek
504David Cantrell
465Tomáš Hrčka
415Fabio Alessandro Locati
359Josh Stone

Mindshare

There were two candidates nominated for the Mindshare Committee, however as Sumantro Mukherjee is already an elected member, there was only one eligible candidate nominated for election. Therefore, Luis Bazan has been automatically re-elected to the Mindshare committee. Congratulations Luis!

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

Infra and RelEng Update – Week 51 2024

Posted by Fedora Community Blog on 2024-12-20 10:00:00 UTC

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 16 – 20 December 2024

Infra&Releng Infographic

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

The post Infra and RelEng Update – Week 51 2024 appeared first on Fedora Community Blog.

Fedora Server User Survey: Your Cattle or Your Pets

Posted by Fedora Magazine on 2024-12-20 08:00:00 UTC

Do you use Fedora Server? The Fedora Server Working Group would love to hear from you through our short 10 question survey. Your answers will help us focus our efforts to improve Fedora Server and provide better support for your use cases.

We Have Ideas

The Fedora Server Working Group discusses, plans, and implements the longer-term goals in upcoming releases. We have ideas like a ready-to-use home server appliance image, or special support for VPS/VDS installation in virtual environments, offered by Amazon Lightsail or Contabo. In some systems, the provision of a specially adapted image can greatly simplify operation.

We Need Your Input

Fedora Server’s wide use is not sufficiently represented by our small working group. This means your feedback is important. Our current ideas and goals are biased towards our interests and use cases in the Fedora Server Working Group. We can learn from you, users who deploy Fedora Server in a variety of places to meet your unique needs.

Tell Us How You Use Fedora Server

Perhaps you like to spin up multiple instances for short clustered workloads, treating Fedora Server like an unnamed herd of cattle. You might, instead, carefully name your home lab servers after ships from Star Trek or droids from Star Wars. Perhaps treating Fedora Server like beloved family pets. Your small or medium-sized company may run a public website for your Internet presence. You may have deployed Fedora Server as part of a larger server cluster with different operating systems. Each of these scenarios could benefit from specific adjustments to our default Fedora Server Edition. Have you already tweaked your install of Fedora Server? Through this survey, you can bring your experience and expertise to the wider community who loves Fedora Server as much as you do.

We Need Your Feedback

Therefore, no matter how you use Fedora Server, we would love to hear from you. We hope to learn…

  1. Where Fedora Server is deployed?
  2. What are the common use cases for Fedora Server?
  3. What improvements can we make in default packages, documentation, or services for our community?

Go HERE to take the 10 question survey. The Fedora Server Working Group appreciates your time and interest in Fedora Server.

Fedora Asahi Remix 41 is now available

Posted by Fedora Magazine on 2024-12-17 15:00:00 UTC

We are happy to announce the general availability of Fedora Asahi Remix 41. This release brings the newly released Fedora Linux 41 to Apple Silicon Macs.

Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. It was unveiled at Flock 2023 and first released later in December with Fedora Asahi Remix 39.

In addition to all the exciting improvements brought by Fedora Linux 41, Fedora Asahi Remix 41 provides x86/x86-64 emulation integration including support for AAA games to Apple Silicon. The game support is based on the new conformant Vulkan 1.4 driver. It also continues to provide extensive device support, including high quality audio out of the box.

Fedora Asahi Remix offers KDE Plasma 6.2 as our flagship desktop experience. It also features a custom Calamares-based initial setup wizard. A GNOME variant is also available, featuring GNOME 47, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.

You can install Fedora Asahi Remix today by following our installation guide. Existing systems, running Fedora Asahi Remix 39 or 40, can be updated following the usual Fedora upgrade process. Upgrades via Fedora Workstation’s Software application are unfortunately not supported and DNF’s System Upgrade plugin has to be used.

Please report any Remix-specific issues in our tracker, or reach out in our Discourse forum or our Matrix room for user support.

Fedora Operations Architect Report

Posted by Fedora Community Blog on 2024-12-16 21:29:29 UTC

Hi folks! We are nearing the end of 2024 and before we do, here is a small highlight on some of our upcoming changes for F42 and some other topics of interest around the project right now.

Fedora Linux 42

A.K.A, the answer to life, the universe and everything. Below are some changes currently in review by our community, and some that are now with FESCo for voting.

Our Change Set page has a list of the currently accepted changes, and below are a list of some key dates:

  • December 18th – Changes requiring infrastructure changes
  • December 24th – Changes requiring mass rebuild
  • December 24th – System Wide changes
  • January 14th – Self Contained changes
  • February 4th – Changes need to be Testable
  • February 4th – Branching
  • February 18th – Changes need to be Complete

Be sure to keep an eye on the Fedora Linux 42 release schedule, and our Fedora Linux 43 and Fedora Linux 44 are now live also.

Hot Topics

Elections

The F41 elections is live, and we have one election currently running. The Fedora Engineering Steering Committee (FESCo) has five (5) open seats, and you can vote for the candidates up for election by visiting the elections app. The voting period will close on Friday 20th December @ 23:59:59 UTC and the results of the election will be announced on Monday 23rd December.

The candidates up for the FESCo election are:

Git Forge Update – Fedora Moves Towards Forgejo

The Fedora council have released an announcement on the intention to go with Forgejo for the projects git forge option in 2025 in the Fedora Magazine. Before the decision is made though, there is a last call for feedback – the council believe this is the right choice, and we have been working with the investigation team and doing our own due diligence, but if there is a reason we should not choose forgejo, please let us know on this feedback thread before Wednesday 18th December. The council will put this decision to a formal vote on this date.

If Forgejo is voted by council as the path forward, you can expect a more in depth announcement on how we reached this decision, and an overview of what features we will need to develop, what ones we will be able to make use of immediately, and a call to arms for those who would like to take an active part in this very big change in 2025.

New Btrfs SIG

A new Btrfs sig has been formed in Fedora! If you would like to take part, or find out more about the work this group will do/is doing, check out their announcement on the devel-announce mailing list.

Boot-C

For all things happening in boot-c this week in Fedora, be sure to read their most recent post, and for all the updates on boot-c in Fedora, use the #bootc-initiative tag on discussion.fpo.

Reminders

FOSDEM Travel

If you are traveling to FOSDEM and would like to connect with others from the project who will be there too, please add your details to the event sheet.

‘Shutdown’ Period

Just a reminder that we are heading into what is known to some as the ‘shutdown’ period. A lot of folks around the project are either already, or soon to be, enjoying some well deserved time away from the computers, or at the very least some reduced time 🙂 Please be mindful that your messages and tickets may go unanswered for the next few weeks, and I would suggest re-pinging or re-commenting in early January. Infra will be monitored, but only serious requests, eg ones that are going to bring the whole project to a stop, are likely to get immediate attention.

The post Fedora Operations Architect Report appeared first on Fedora Community Blog.

Infra and RelEng Update – Week 50 2024

Posted by Fedora Community Blog on 2024-12-13 10:00:00 UTC

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 09 – 13 December 2024

I&R infographic

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

The post Infra and RelEng Update – Week 50 2024 appeared first on Fedora Community Blog.

EPEL 10 is now available

Posted by Fedora Community Blog on 2024-12-12 20:00:00 UTC

On behalf of the EPEL Steering Committee, I’m happy to announce the availability of EPEL 10. EPEL 10 already contains over 10,000 packages, built from over 3,600 source packages. This is a result of the hard work of over 150 Fedora package maintainers.

What is EPEL?

Extra Packages for Enterprise Linux (EPEL) is an initiative within the Fedora Project to provide high quality additional packages for CentOS Stream and Red Hat Enterprise Linux (RHEL). The goal for EPEL packages is to enhance these distributions, without disturbing or replacing packages from the default repositories.

What’s new?

For the EPEL 9 release, we started building packages about six months before the RHEL 9 release by using CentOS Stream 9 as the initial build environment. For EPEL 10, we’re expanding on that approach and doing the same thing for each minor version of RHEL 10. We will have separate DNF repositories for each minor version of RHEL 10, including CentOS Stream 10 as the leading minor version. Packages built for one minor version will carry forward to the next minor version. You can find more details about this structure in our branching documentation.

Requesting packages

While many packages are already available in EPEL 10, it’s possible that your favorite package isn’t one of them yet. We don’t automatically branch packages from the previous major version to the next major version. Individual package maintainers opt-in to building for each new major version. You can request additional packages by following our package request guide.

Getting started

Ready to start using EPEL 10? Check out our getting started guide for instructions to set up the repository on your system.

The post EPEL 10 is now available appeared first on Fedora Community Blog.

dist-git outage

Posted by Fedora Infrastructure Status on 2024-12-11 10:30:00 UTC

We will switch authentication from OpenID to OIDC (OpenID Connect). There will be a short outage to do this.

Fedora Project Leader Matthew Miller: A change of hats!

Posted by Fedora Magazine on 2024-12-10 17:00:00 UTC

Okay, wow… deep breath….

Hi everyone!

I’ve been the Fedora Project Leader for more than ten years. That’s half of Fedora’s existence as a distribution project. It is my dream job, and I love it, and honestly, I could do it forever.

However, I don’t think I should do it forever. When I started in this role, I thought: I’m going to aim for five years.  But, when I got there, I felt like I’d just found my footing. We had a series of great releases, a super-productive Fedora Council meetup in Minnesota, and Flock to Fedora in Budapest was amazing. With that energy, I saw so much more to work on. I definitely wasn’t done.

Now, after another five years, it’s time. The project is in great shape. We have high community engagement, stronger support than we’ve seen in years from our major sponsor, and increasing popularity and visibility in the whole Linux world. We build the distro of choice for new CPU architectures like RISC-V, and vendors ship our OS on laptops. Atomic  image mode is awesome. We’re on a good path for big infrastructure improvements.1 I want all this to keep expanding — and more! To get there, I think we need someone with new energy and fresh ideas standing in my place.

Stay tuned for a job posting from Red Hat, and details about all that. I’m hoping we can hire someone awesome early in 2025, and make the official handover on the release of auspiciously-numbered Fedora Linux 42.

I’m not going to leave Fedora, though. As I said above, although it might not always feel like it from the outside, Red Hat support for Fedora is stronger than ever, and I plan on helping that grow even more. I’m stepping into a full-time management role in the Community Linux Engineering organization, so Fedora will still be part of my day job, just in a different way2.

Likewise, I’ll be nearby as a resource for the incoming FPL. This is a big, difficult job, and I know from experience (thanks, Robyn!) that it’s crucial to have someone close who understands what it’s like to provide support. I want the next person to feel confident and up-to-speed in quite a lot less than five years.

Thank you, everyone, for making Fedora the best Linux distro ever. Thank you for listening to my good ideas and being patient with many more bad ones. I would not be here without your support and friendship all these years, through difficult times and amazing times3. I love you all!

– Matthew

  1. New git forge, better CI, a more modern and flexible build system, more workflow automation… and I’ll convince you all to switch from mailing lists to Discourse, eventually! ↩︎
  2. Actually, that’s a lie. The first thing I’m going to do is sleep for a month. But, after that. ↩︎
  3. Often, both at once. ↩︎

Please direct replies and comments to the announcement on Fedora Discussion. Thank you!

F41 Elections Voting is now Open!

Posted by Fedora Community Blog on 2024-12-09 20:57:39 UTC

Voting in the Fedora Linux 41 elections is now open. Go to the Elections app to cast your vote. This cycle we have just one election to vote in – FESCo. Voting closes at 23:59 UTC on Friday, 20thDecember and don’t forget to claim your “I Voted” badge when you cast your ballot. Links to candidate interviews are below.

Fedora Engineering Steering Committee (FESCo)

There are five seats open for the Fedora Engineering Steering Committee (FESCo).

Mindshare Committee

As one of the nominees for the Mindshare Committee is already an active elected member, Sumantro Mukherjee, the current eligible nominee number matches the open seats, and so the eligible nominated candidate will be automatically elected in. Early congratulations, Luis Bazan!

The post F41 Elections Voting is now Open! appeared first on Fedora Community Blog.

FESCo election: Interview with Zbigniew Jędrzejewski-Szmek

Posted by Fedora Community Blog on 2024-12-09 20:52:50 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with Zbigniew Jędrzejewski-Szmek

  • Fedora Account: Zbigniew Jędrzejewski-Szmek
  • Nick: zbyszek
  • Matrix Channels typically found in: fedora-devel, fedora-python, systemd, mkosi
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I see the role of FESCo as a place where all voices are heard so that a consensus decision can be reached. It is individual community members, SIGs, and other groups who should propose and implement changes. FESCo is the place where questions about motivation, backwards compatibility, user experience, schedules and contingency plans are asked and answered. I think it’s totally fine when the majority of decisions by FESCo is unanimous after that.

Overall, I think Fedora is doing OK. We are consistently delivering very solid releases regularly, with latest packages, and with a number of interesting new features in each release. The release of F39 was delayed, but this can be attributed to internal Red Hat problems. I hope we’re past this and will be back on track for F40.

To maintain the position of Fedora as the most innovative distro, we need to keep adapting and implementing big new initiatives. I would love to see Fedora more widely used, with more packages delivered more reliably. I very much support the FPL’s goal to double the number of contributors. Coincidentally, I think it’ll be easier to engage new contributors, including existing upstream maintainers, when the packaging story is streamlined.

We have a number of initiatives that improve specific areas, but we’re not doing enough to build tools and procedures that provide a uniform and consistent experience. For example, we have rpmautospec, but it’s not universally used. We have automatic bodhi updates for rawhide, but the same functionality is not available for stable releases. We have gating, but it’s still very hard to use, with lots of false positives. Packit is being used by some packages, but it’s something on the side, only awkwardly integrated with the normal Fedora packaging infrastructure. We need to build a more coherent packaging experience so that we can do bold, innovative things in Fedora.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I’m active in systemd upstream, and I’ve been doing systemd package maintenance in Fedora since 2013; if you’ve submitted a systemd bug in Bugzilla or in the upstream bugtracker, chances are I’ve looked at it. I maintain a few dozen packages, and I try to do new package reviews regularly (469 so far). I’ve been in FESCo since F28. I’be been involved in various initiatives, like the transition of various upstream to Python 3, mass rename of Python 2 packages during the transition to Python 3, improvements to packaging tools (rust2rpm, rpmautospec), transition of the packaging documentation from the wiki, ELF package notes, reproducible builds, updating of Packaging Guidelines for new techniques. I try to help with all aspects of packaging, but I’m especially interested in mass cleanups and automatization of various packaging processes.

How do you handle disagreements when working as part of a team?

Team members must trust each other and be transparent about their reasoning and motivations. If that is true, technical differences can be explained away or proven with actual code. For all this to work, the group must share a common goal.

What else should community members know about you or your positions?

Continue my wishlist of 2024 into 2025, as I have done in previous election years:

  • Clean up bodhi update gating so that false failures are infrequent and packagers start relying on the status and always consider the results.
  • Figure out how rpmautospec should be used during initial packaging and during review. The documented method before and after review must be consistent.
  • Convert 90+% of packages to SPDX license tags.
  • Set up a continuous rebuilds of rawhide/amd64 to gather statistics on build reproducibility of Fedora packages. Once the common issues have been resolved, plan towards making build reproducibility an official feature.
  • SystemdSecurityHardening
  • continue the work on Unified Kernel Images and non-dracut initrds. This year we should get a pre-built initrd as an option for normal users.

The post FESCo election: Interview with Zbigniew Jędrzejewski-Szmek appeared first on Fedora Community Blog.

FESCo election: Interview with Tomas Hckra

Posted by Fedora Community Blog on 2024-12-09 20:51:18 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with Tomas Hckra

  • Fedora Account: Tomas Hckra
  • Nick: jednorozec/humaton
  • Matrix Channels typically found in: fedora-releng, #fedora-devel, #fedora-devel, #fedora-noc
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

As a product owner of Community linux engineer team, I bring to the table insight on the planning and capacity that the team that is running fedora infrastructure, release engineering and Quality has, and this perspective can bring some new opinions into the steering process. My focus is mostly on user/contributor self-service where possible so we can remove obstacles for new people coming into the Fedora project.

How do you currently contribute to Fedora? How does that contribution benefit the community?

Over the last decade, I went through package maintenance and app development. Currently, I am part of the release engineering team, helping out with releases and related infrastructure work. Right now I am working on dropping the Product Definition Center from our workflows so we can reduce the complexity in our package-related processes and tooling.

How do you handle disagreements when working as part of a team?

Most of the team disagreements I was part of were caused by communication issues and misunderstanding of one or the other side. So I strongly believe that most problems are resolvable by listening, considering the other side, and communicating about the disagreement clearly. The next step is building consensus keeping in mind all the viewpoints that caused the conflict in the first place.

What else should community members know about you or your positions?

I am a full-on open-source nerd, everything in my house is running open-source SW. I am not shy of public speaking you can find some of my talks on YouTube like this one about opensource home automation: https://www.youtube.com/watch?v=HUhHaHnzhYA

Two main ideas that define my approach to technology:
“I want all things open and all sources shown”
“Where is a serial console there is a way”

The post FESCo election: Interview with Tomas Hckra appeared first on Fedora Community Blog.

FESCo Election: Interview with Josh Stone

Posted by Fedora Community Blog on 2024-12-09 20:50:28 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with Josh Stone

  • Fedora Account: Josh Stone
  • Nick: jistone
  • Matrix Channels typically found in: #rust:fedoraproject.org
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I’m proud of Fedora, both as a user and contributor, and continuing to serve on FESCo would be another way for me to contribute to its success. I don’t have a list of things that I would change in Fedora, but even steering along the current course requires time and attention, and there will always be new changes on the horizon. I think that I have relevant experience to continue to help as an elected member of FESCo.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I maintain the Rust toolchain in Fedora, keeping up with its releases every 6 weeks for all Fedora branches, and sometimes point release in-between. We decided long ago that rolling rebases made the most sense for Fedora, since Rust developers are often eager to use new features. This keeps Fedora relevant for Rust developers, and helps Rust SIG packagers to not worry about the toolchain version when updating crates. I also work closely with the LLVM maintainers, both for coordinating Rust needs and in more general issues.

How do you handle disagreements when working as part of a team?

Disagreements are natural, and the goal should be to reach consensus, which may require difficult conversations about pros and cons and compromise positions. But even then, it’s not always possible to reach agreement, and hopefully in that case there is a governance structure to fall back on — whether that’s a decision maker in a team lead or manager, or a democratic process like voting in FESCo decisions. Ultimately, it’s important to operate in good faith and assume the same in others, and agree to commit and move on when a decision has been made.

What else should community members know about you or your positions?

I’m a member of Red Hat’s Platform Tools team, where I also maintain the Rust toolchain for RHEL. In a previous role, I worked on SystemTap for Fedora and RHEL, giving me broad experience across the entire system. In the upstream Rust community, I’m a member of the library, release, and security-response teams, and I previously served as a Project Directoron the board of the Rust Foundation. So while my current contributions to Fedora are narrowly focused, I think I have a lot to offer in the larger view as a FESCo member.

The post FESCo Election: Interview with Josh Stone appeared first on Fedora Community Blog.

FESCo election: Interview with David Cantrell

Posted by Fedora Community Blog on 2024-12-09 20:49:13 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with David Cantrell

  • Fedora Account: dcantrell
  • Nick: dcantrell
  • Matrix Channels typically found in: fedora-ambassadors, #fedora-ci, #fedora-devel, #fedora-qa, #rpm, and #rpm-ecosystem & you can also ping me directly
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

Fedora is important to me as both a project and a community. I want to continue to help steer Fedora’s engineering direction and ensuring that the project succeeds and grows. Specifically I want to see it continue to embrace more container-based delivery alongside the traditional RPM model. Making Fedora even easier to work with in a container: to maintain, to update, and to deploy. We also have a lot of hardware opportunities and seeing the Asahi Project move to using Fedora as their base was great. On FESCo we discuss all of these sorts of things and more and I want to continue to hear from the users and developers and help guide the project.

How do you currently contribute to Fedora? How does that contribution benefit the community?

Aside from FESCo, I also serve as the engineering representative on the Fedora Council. I am a Fedora Ambassador and a sponsor for new contributors. I maintain a range of packages and am the upstream developer for a number of projects. My recent large project has been the rpminspect program which is used in a handful of CI environments to validate builds and check policy compliance.

I run both the latest stable release of Fedora and rawhide and report bugs when I encounter them and submit patches when possible.

I try to answer questions for as many people as I can and when I can’t, I try to help find someone who can.

How do you handle disagreements when working as part of a team?

In my experience, disagreements come up because everyone is very passionate about the task or topic at hand. It’s important to remember that most of these should end in compromise. I do my best to make my points clear and understood while at the same time listening to everyone else. Sometimes the conversation itself is enough to clear up disagreements. Maybe I didn’t have the full story or maybe someone else didn’t. As long as we are willing to have these conversations and reach a compromise, things go well.

What else should community members know about you or your positions?

My day job is working at Red Hat, where I have been working on RHEL and Fedora full time for 19 years. Prior to that I worked at a number of companies doing Linux development or admin work and even before that I worked on the Slackware Linux distribution.

Outside of work I enjoy restoring old and obsolete computers, making contacts (or actively pretending to make contacts) via amateur radio, and boating in and around Boston Harbor and New England.

I live in Medford, Massachusetts.

The post FESCo election: Interview with David Cantrell appeared first on Fedora Community Blog.

FESCo election: Interview with Fabio Alessandro Locati (Fale)

Posted by Fedora Community Blog on 2024-12-09 20:48:21 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024

Interview with Fabio Alessandro Locati (Fale)

  • Fedora Account: Fale
  • Nick: fale
  • Matrix Channels typically found in: #atomic-desktops:fedoraproject.org, #sway:fedoraproject.org, #golang:fedoraproject.org, #devel:fedoraproject.org, #coreos:fedoraproject.org, #iot:fedoraproject.org, #mobility:fedoraproject.org, #websites:fedoraproject.org, #fedora-arm:matrix.org
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I have been around the Fedora community for many years now: my FAS account is dated January 2010 (close to 15 years!), and I’ve contributed with many different hats to the Fedora project. In the beginning, I started as an ambassador, and over time, I’ve also become a packager and a packaging mentor, and I have joined multiple SIGs such as the Golang, Sway, and Atomic Desktop. For many years, I’ve been interested in immutable Linux desktop, Mobile Linux, and “new” languages (such as Go) packaging challenges, which are also becoming more relevant in the Fedora community now. Having contributed to the Fedora Project for a long time in many different areas, and given my experience and interest in other projects, I can bring those perspectives to FESCo.

How do you currently contribute to Fedora? How does that contribution benefit the community?

Currently, most of my contributions fall in the packaging area: I keep updating the packages I administer and try to find different solutions for packaging new languages and maintaining the Sway artifacts.
My current contributions are important to keeping Fedora first, not only in terms of package versions but also in terms of best practices and ways to reach our users.

How do you handle disagreements when working as part of a team?

I think disagreements are normal in communities. I have a few beliefs entering and during any disagreement that guide me. First, I always separate the person from their argument: this allows me to discuss the topic without being influenced by the person making the points. The second believe I always have in mind during disagreements is that all people involved probably have a lot of things they agree on and a few they don’t agree on (otherwise, they would not be part of the conversation in the first place): this allows me to always see the two sides of the disagreement as having way more in common than in disagreement. The third belief I always hold during a discussion is that the people arguing on the opposite side of the disagreement are trying to make sure that what they believe as right becomes a reality: this allows me always to try to see if there are aspects in their point of view that I had not considered or not appropriately weighted.
Thanks to my beliefs, I always manage to keep disagreements civil and productive, which often leads to a consensus. It is not always possible to agree on everything, but it is always possible to disagree in civil and productive ways.

What else should community members know about you or your positions?

Let’s start with the fact that I’m a Red Hat employee, though what I do in my day job has nothing to do with Fedora (I’m a specialist for Ansible, so I have nothing to do with RHEL as well), so I have no alter motives around my contributions. I use Fedora on many devices (starting from my laptop) and have done so for many years. I contribute to the Fedora Project because I found in it and its community what I deem to be the best way of creating the best operating system :).
I’ve been using Sway exclusively on my Fedora desktop since I brought it in Fedora in 2016. On the other systems, I use either Fedora Server, Fedora CoreOS, or Fedora IoT, even though lately, I prefer the latter for all new non-desktop systems.
I see the Fedora Community as one community within a sea of communities (upstream, downstream, similarly located ones, etc.). I think the only way for all those communities to be successful is to collaborate, creating a higher-level community where all open-source communities collaborate for the greater good, which – in my opinion – would be a more open-source world.

The post FESCo election: Interview with Fabio Alessandro Locati (Fale) appeared first on Fedora Community Blog.

FESCo election: Interview with Kevin Fenzi

Posted by Fedora Community Blog on 2024-12-09 20:45:31 UTC

This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December 2024.

Interview with Kevin Fenzi

  • Fedora Account: Kevin
  • Nick: nirik
  • Matrix Channels typically found in: #fedora-admin/admin, #fedora-noc/noc, #fedora-releng/releng, #fedora-devel/devel
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I wish to continue to serve the fedora community on FESCo to provide history and help make today’s decisions based on yesterdays learning.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I currently am lucky to be employed by Red Hat working full time on Fedora Infrastructure. But outside of that ‘day job’ I try and do as many things as I can to help the fedora community: Maintaining packages, providing feedback on plans or ideas, doing release engineering tasks (often in non ‘work’ times).

How do you handle disagreements when working as part of a team?

I try and reach consensus until it becomes clear thats not possible. However, it almost always is possible, you just need to look at things from other perspectives and consider what solution would work for everyone. This is not foolproof, but helps to handle disagreements when they happen.

What else should community members know about you or your positions?

I’m happy to talk to anyone from the community anytime about fedora items. Feel free to contact me on matrix or email. I’m human and make mistakes, but I like to think I learn from them and do better over time. 🙂

The post FESCo election: Interview with Kevin Fenzi appeared first on Fedora Community Blog.

© 2016 Red Hat, Inc. and others. Please send any comments or corrections to the websites team.

The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content.

Your words are your own, duh. Nothing here represents Fedora™, Red Hat, Inc, or pretty much anything else. If you think it does then you are badly misled