fidzu : Fedora

20 Nov 2025 10:00pm GMT

Well, it's been a few weeks since I made one of these recap blog posts. Last weekend I was recovering from some oral surgery, the weekend before I had been on PTO on friday and was trying to be 'away'.

Lots of things happened in the last few weeks thought!

15 Nov 2025 5:08pm GMT

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: 10th - 14th November 2025

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

• 4 flatpak packages stuck in updates composes
• Contributor Group (FAS) user theking2
• packages.fp.o not refreshing since 2025-10-26
• Lost access to packager-sponsors ML
• Package update stuck in zombie state?
• [Forgejo] New Organization and Teams Request: Cloud SIG
• Missing/messed-up logs for FESCo meting 2024-01-29
• Group for teamsbc
• group for EU OS
• New FAS Group, Organization and Team Request: AI/ML SIG
• New group on copr: microshift-io
• Please add jspaleta as admin to release calendar in fedocal
• CentOS Stream baseos-source repo has a checksum error
• Spread load from docsync on sundries01
• Rsync-ing public mirrors for a private mirror leads to corrupt mirror
• No crawling for mirror site since June
• Anubis provides a bunch of stats. … would be nice to get them in zabbix
• Create communishift project for fedora coreos AI helpers
• docs-rsync doing lots of IO at midnight and setting off alarms.
• [FMTS] TLS certificate for noggin service is about to expire in 30 days
• Nagios server `notify-by-fedora-messaging`command might not work
• [Forgejo] New Organization and Teams Request: CommOps
• Create Fedora Workstation organization on Forgejo?
• Issue a client certificate for fedora-image-uploader to authenticate with Azure
• Need to delete user account in FAS that has been already deleted in Discourse (discussion.fedoraproject.org) due to violations (spam, AI, etc.)
• Forgejo: Owner access to @jflory7 for @CommOps
• no-changed-when: Commands should not change things if nothing needs doing. [openshift playbooks linting]
• Move copr_hypervisor group from iptables to nftables

CentOS Infra including CentOS CI

• Failed HDD in raid array on sponsored server
• Migrate CBS lookaside cache to new RDU3/DC
• migrate mailman/MX servers for centos.org to new DC
• stream9 and stream10 BuildTargets and Tags needed for nfs-ganesha-8
• CentOS Stream Mirror request

Release Engineering

• flatpak builds fail to upload to registry
• Stalled EPEL package: sparsehash
• Changes/Ruby_3.5
• Package unretirement
• Bodhi update(s) pushed to "stable" but ending up without tags in koji and not being available in repos
• more bodhi updates with push issues
• Misconfigured redirect to EPEL mirror mirrors.edge.kernel.org
• Archive openarm_can package
• Keep compose metadata somewhere that isn't garbage-collected

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

• Minor update of Fedora Messaging from 3.8.0 to 3.9.0 on 2025-11-12: https://github.com/fedora-infra/fedora-messaging/releases/tag/v3.9.0
• Minor update of Bodhi from 25.5.1 to 25.11.1 on 2025-11-07: https://github.com/fedora-infra/bodhi/releases/tag/25.11.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 Infra and RelEng Update - Week 46 2025 appeared first on Fedora Community Blog.

14 Nov 2025 10:00am GMT

We did it again, Fedora at Kirinyaga university in Kenya. This time, we didn't just introduce what open source is - we showed students how to participate and actually contribute in real time.

Many students had heard of open source before, but were not sure how to get started or where they could fit. We did it hands-on and began with a simple explanation of what open source is: people around the world working together to create tools, share knowledge, and support each other. Fedora is one of these communities. It is open, friendly, and built by different people with different skills.

We talked about the many ways someone can contribute, even without deep technical experience. Documentation, writing guides, design work, translation, testing software, and helping new contributors are all important roles in Fedora. Students learned that open source is not only for "experts." It is also for learners. It is a place to grow.

Hands-on Documentation Workshop

After the introduction, we moved into a hands-on workshop. We opened Fedora Docs and explored how documentation is structured. Students learned how to find issues, read contribution instructions, and make changes step-by-step. We walked together through:

• Opening or choosing an issue to work on
• Editing documentation files
• Making a pull request (PR)
• Writing a clear contribution message

By the end of the workshop, students had created actual contributions that went to the Fedora project. This moment was important. It showed them that contributing is not something you wait to do "someday." You can do it today.

"This weekend's Open Source Event with Fedora, hosted by the Computer Society Of Kirinyaga, was truly inspiring!

Through the guidance of Cornelius Emase, I was able to make my first pull request to the Fedora Project Docs - my first ever contribution to the open-source world. "
- Student at Kirinyaga University

Thank you note

Huge appreciation to:

• Jona Azizaj - for steady guidance and mentorship.
• Mat H. - for backing the vision of regional community building.
• Fedora Mindshare Team - for supporting community growth here in Kenya.
• Computer Society of Kirinyaga - for hosting and bringing real energy into the room.

And to everyone who played a part - even if your name isn't listed here, I see you. You made this possible.

Growing the next generation

The students showed interest, curiosity, and energy. Many asked how they can continue contributing and how to connect with the wider Fedora community. I guided them to Fedora Docs, Matrix community chat rooms, and how they can be part of the Fedora local meetups here in Kenya.

We are introducing open source step-by-step in Kenya. There is a new generation of students who want to be part of global technology work. They want to learn, collaborate, and build. Our role is to open the door and walk together(I have a discourse post on this, you're welcome to add your views).

What Comes Next

This event is part of a growing movement to strengthen Fedora's presence in Kenya. More events will follow so that learning and contributing can continue.

We believe that open source becomes strong when more people are included. Fedora is a place where students in Kenya can learn, grow, share, and contribute to something global.

We already had a Discourse thread running for this event - from the first announcement, planning, and budget proposal, all the way to the final workshop. Everything happened in the open. Students who attended have already shared reflections there, and anyone who wants to keep contributing or stay connected can join the conversation.

You can check the events photos submitted here on Google photos(sorry that's not FOSS:))

Cornelius Emase,
Your Friend in Open Source(Open Source Freedom Fighter)

14 Nov 2025 8:00am GMT

The blog post was originally published on my Czech blog.

When we launched Vhsky.cz a year ago, we did it to provide an alternative to the near-monopoly of YouTube. I believe video distribution is so important today that it's a skill we should maintain ourselves.

To be honest, it's bothered me for the past few years that even open-source conferences simply rely on YouTube for streaming talks, without attempting to secure a more open path. We are a community of tech enthusiasts who tinker with everything and take pride in managing things ourselves, yet we just dump our videos onto YouTube, even when we have the tools to handle it internally. Meanwhile, it's common for conferences abroad to manage this themselves. Just look at FOSDEM or Chaos Communication Congress.

This is why, from the moment Vhsky.cz launched, my ambition was to broadcast talks from OpenAlt-a conference I care about and help organize. The first small step was uploading videos from previous years. Throughout the year, we experimented with streaming from OpenAlt meetups. We found that it worked, but a single stream isn't quite the stress test needed to prove we could handle broadcasting an entire conference.

For several years, Michal Vašíček has been in charge of recording at OpenAlt, and he has managed to create a system where he handles recording from all rooms almost single-handedly (with assistance from session chairs in each room). All credit to him, because other conferences with a similar scope of recordings have entire teams for this. However, I don't have insight into this part of the process, so I won't focus on it. Michal's job was to get the streams to our server; our job was to get them to the viewers.

Stress Test

We only got to a real stress test the weekend before the conference, when Bashy prepared a setup with seven streams at 1440p resolution. This was exactly what awaited us at OpenAlt. Vhsky.cz runs on a fairly powerful server with a 32-core i9-13900 processor and 96 GB of RAM. However, it's not entirely dedicated to PeerTube. It has to share the server with other OSCloud services (OSCloud is a community hosting of open source web services).

We hadn't been limited by performance until then, but seven 1440p streams were truly at the edge of the server's capabilities, and streams occasionally dropped. In reality, this meant 14 continuous transcoding processes, as we were streaming in both 1440p and 480p. Even if you don't change the resolution, you still need to transcode the video to leverage useful distribution features, which I'll cover later. The 480p resolution was intended for mobile devices and slow connections.

Remote Runner

We knew the Vhsky.cz server alone couldn't handle it. Fortunately, PeerTube allows for the use of "remote runners". The PeerTube instance sends video to these runners for transcoding, while the main instance focuses only on distributing tasks, storage, and video distribution to users. However, it's not possible to do some tasks locally and offload others. If you switch transcoding to remote runners, they must handle all the transcoding. Therefore, we had to find enough performance somewhere to cover everything.

I reached out to several hosting providers known to be friendly to open-source activities. Adam Štrauch from Roští.cz replied almost immediately, saying they had a backup machine that they had filed a warranty claim for over the summer and hadn't tested under load yet. I wrote back that if they wanted to see how it behaved under load, now was a great opportunity. And so we made a deal.

It was a truly powerful machine: a 48-core Ryzen with 1 TB of RAM. Nothing else was running on it, so we could use all its performance for video transcoding. After installing the runner on it, we passed the stress test. As it turned out, the server with the runner still had a large reserve. For a moment, I toyed with the idea of adding another resolution to transcode the videos into, but then I decided we'd better not tempt fate. The stress test showed us we could keep up with transcoding, but not how it would behave with all the viewers. The performance reserve could come in handy.

Smart Video Distribution

Once we solved the transcoding performance, it was time to look at how PeerTube would handle video distribution. Vhsky.cz has a bandwidth of 1 Gbps, which isn't much for such a service. If we served everyone the 1440p stream, we could serve a maximum of 100 viewers. Fortunately, another excellent PeerTube feature helps with this: support for P2P sharing using HLS and WebRTC.

Thanks to this, every viewer (unless they are on a mobile device and data) also becomes a peer and shares the stream with others. The more viewers watch the stream, the more they share the video among themselves, and the server load doesn't grow at the same rate.

A two-year-old stress test conducted by the PeerTube developers themselves gave us some idea of what Vhsky could handle. They created a farm of 1,000 browsers, simulating 1,000 viewers watching the same stream or VOD. Even though they used a relatively low-performance server (quad-core i7-8700 CPU @ 3.20GHz, slow hard drive, 4 GB RAM, 1 Gbps connection), they managed to serve 1,000 viewers, primarily thanks to data sharing between them. For VOD, this saved up to 98% of the server's bandwidth; for a live stream, it was 75%:

If we achieved a similar ratio, then even after subtracting 200 Mbps for overhead (running other services, receiving streams, data exchange with the runner), we could serve over 300 viewers at 1440p and multiples of that at 480p. Considering that OpenAlt had about 160 online viewers in total last year, this was a more than sufficient reserve.

Live Operation

On Saturday, Michal fired up the streams and started sending video to Vhsky.cz via RTMP. And it worked. The streams ran smoothly and without stuttering. In the end, we had a maximum of tens of online viewers at any one time this year, which posed no problem from a distribution perspective.

Our solution, which PeerTube allowed us to flexibly assemble from servers in different data centers, has one disadvantage: it creates some latency. In our case, however, this meant the stream on Vhsky.cz was about 5-10 seconds behind the stream on YouTube, which I don't think is a problem. After all, we're not broadcasting a sports event.

Minor Problems

We did, however, run into minor problems and gained experience that one can only get through practice. During Saturday, for example, we found that the stream would occasionally drop from 1440p to 480p, even though the throughput should have been sufficient. This was because the player felt that the delivery of stream chunks was delayed and preemptively switched to a lower resolution. Setting a higher cache increased the stream delay slightly, but it significantly reduced the switching to the lower resolution.

Subjectively, even 480p wasn't a problem. Most of the screen was taken up by the red frame with the OpenAlt logo and the slides. The speaker was only in a small window. The reduced resolution only caused slight blurring of the text on the slides, which I wouldn't even have noticed as a problem if I wasn't focusing on it. I could imagine streaming only in 480p if necessary. But it's clear that expectations regarding resolution are different today, so we stream in 1440p when we can.

Over the whole weekend, the stream from one room dropped for about two talks. For some rooms, viewers complained that the stream was too quiet, but that was an input problem. This issue was later fixed in the recordings.

When uploading the talks as VOD (Video on Demand), we ran into the fact that PeerTube itself doesn't support bulk uploads. However, tools exist for this, and we'd like to use them next time to make uploading faster and more convenient. Some videos also uploaded with the wrong orientation, which was likely a problem in their metadata, as PeerTube wasn't the only player that displayed them that way. YouTube, however, managed to handle it. Re-encoding them solved the problem.

On Saturday, to save performance, we also tried transcoding the first finished talk videos on the external runner. For these, a bar is displayed with a message that the video failed to save to external storage, even though it is clearly stored in object storage. In the end we had to reupload them because they were available to watch, but not indexed.

A small interlude - my talk about PeerTube at this year's OpenAlt. Streamed, of course, via PeerTube:

Thanks and Support

I think that for our very first time doing this, it turned out very well, and I'm glad we showed that the community can stream such a conference using its own resources. I would like to thank everyone who participated. From Michal, who managed to capture footage in seven lecture rooms at once, to Bashy, who helped us with the stress test, to Archos and Schmaker, who did the work on the Vhsky side, and Adam Štrauch, who lent us the machine for the external runner.

If you like what we do and appreciate that someone is making OpenAlt streams and talks available on an open platform without ads and tracking, we would be grateful if you supported us with a contribution to one of OSCloud's accounts, under which Vhsky.cz runs. PeerTube is a great tool that allows us to operate such a service without having Google's infrastructure, but it doesn't run for free either.

13 Nov 2025 11:37am GMT

Today, the Fedora Project begins the nomination period during which we accept nominations to the "steering bodies" of the following teams:

• Fedora Engineering Steering Committee (FESCo) (5 seats)

This period is open until Wednesday, 2025-11-26 at 23:59:59 UTC.

Candidates may self-nominate. If you nominate someone else, check with them first to ensure that they are willing to be nominated before submitting their name.

Nominees do not yet need to complete an interview. However, interviews are mandatory for all nominees. Nominees not having their interview ready by end of the Interview period (2025-12-03) will be disqualified and removed from the election. Nominees will submit questionnaire answers via a private Pagure issue after the nomination period closes on Wednesday, 2025-11-26. The F43 Election Wrangler (Justin Wheeler) will publish the interviews to the Community Blog before the start of the voting period on Friday, 2025-12-05.

The elected seats on FESCo are for a two-release term (approximately twelve months). For more information about FESCo, please visit the FESCo docs.

The full schedule of the elections is available on the Elections schedule. For more information about the elections, process see the Elections docs.

The post F43 election nominations now open appeared first on Fedora Community Blog.

12 Nov 2025 1:18pm GMT

My house has a handful of Amazon Echo Dot devices that we mostly use for timers, turning lights on and off, and playing music. They work well and have been an easy solution. I also use Home Assistant for some basic home automation and serve most everything I want to verbally control to the Echo Dots from Home Assistant.

I don't use the Nabu Casa Home Assistant Cloud Service. If you're reading this and you want the easy route, consider it - the cloud service is convenient. One benefit of the service is that there is a UI toggle to mark which entities/devices to expose to voice assistants.

If you take the manual route, like I do, you must set up a developer account, AWS Lambda, and maintain a hand-coded list of entity IDs in a YAML file.

- switch.living_room
- switch.table
- light.kitchen
- sensor.temp_humid_reindeer_marshall_temperature
- sensor.living_room_temperature
- sensor.temp_humid_rubble_chase_temperature
- sensor.temp_humid_olaf_temperature
- sensor.ikea_of_sweden_vindstyrka_temperature
- light.white_lamp_bulb_1_light
- light.white_lamp_bulb_2_light
- light.white_lamp_bulb_3_light
- switch.ikea_smart_plug_2_switch
- switch.ikea_smart_plug_1_switch
- sensor.temp_humid_chase_c_temperature
- light.side_light
- switch.h619a_64c3_power_switch

A list of entity IDs to expose to Alexa.

Fun, right? Maintaining that list is tedious. I generally don't mess with my Home Assistant installation very often. Therefore, when I need to change what is exposed to Alexa or add a new device, finding the actual entity_id is annoying. This is not helped by how good Home Assistant has gotten at showing only friendly names in most places. I decided there had to be a better way to do this other than manually maintaining YAML.

After some digging through docs and the source, I found there isn't a built-in way to build this list by labels, categories, or friendly names. The Alexa integration supports only explicit entity IDs or glob includes/excludes.

So I worked out a way to build the list with a Home Assistant automation. It isn't fully automatic - there's no trigger that runs right before Home Assistant reboots - and you still need to restart Home Assistant when the list changes. But it lets me maintain the list by labeling entities rather than hand-editing YAML.

After a few experiments and some (occasionally overly imaginative) AI help, I arrived at this process. There are two parts.

Prep and staging

In your configuration.yaml enable the Alexa Smart Home Skill to use an external list of entity IDs. I store mine in /config/alexa_entities.yaml.

alexa:
  smart_home:
    locale: en-US
    endpoint: https://api.amazonalexa.com/v3/events
    client_id: !secret alexa_client_id
    client_secret: !secret alexa_client_secret
    filter:
      include_entities:
         !include alexa_entities.yaml

Add two helper shell commands:

shell_command:
  clear_alexa_entities_file: "truncate -s 0 /config/alexa_entities.yaml"
  append_alexa_entity: '/bin/sh -c "echo \"- {{ entity }}\" >> /config/alexa_entities.yaml"'

A script to find the entities

Place this script in scripts.yaml. It does three things:

1. Clears the existing file.
2. Finds all entities labeled with the tag you choose (I use "Alexa").
3. Appends each entity ID to the file.

export_alexa_entities:
  alias: Export Entities with Alexa Label
  sequence:
    # 1. Clear the file
    - service: shell_command.clear_alexa_entities_file

    # 2. Loop through each entity and append
    - repeat:
        for_each: "{{ label_entities('Alexa') }}"
        sequence:
          - service: shell_command.append_alexa_entity
            data:
              entity: "{{ repeat.item }}"
  mode: single

Why clear the file and write it line by line? I couldn't get any file or notify integration to write to /config, and passing a YAML list to a shell command collapses whitespace into a single line. Reformatting that back into proper YAML without invoking Python was painful, so I chose to truncate and append line-by-line. It's ugly, but it's simple and it works.

The result is that I can label entities in the UI and avoid tedious bookkeeping.

12 Nov 2025 12:40pm GMT

11 Nov 2025 6:43pm GMT

11 Nov 2025 6:43pm GMT

11 Nov 2025 6:43pm GMT

11 Nov 2025 6:43pm GMT

11 Nov 2025 6:43pm GMT

11 Nov 2025 6:43pm GMT

11 Nov 2025 6:43pm GMT

11 Nov 2025 6:43pm GMT

11 Nov 2025 6:43pm GMT