Fedora People

/rss20.xml">

Fedora People
Blog List

RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll

Day Two - Flock To Fedora 2026

Posted by Akashdeep Dhar ( Fedora Account System Username

t0xic0der ) on 2026-07-09 18:30:01 UTC

Even though it was not as good a sleep as I would have gotten at my home, I ended up having a far better respite than the day before. Well rested as I was, I woke up at around 0600am Central European Summer Time on 15th June 2026 and had Tomáš Hrčka pick up the snacks and spices that I got for him from my hotel room. After all, the last thing I would want to do was haul them all the way to the venue only to hand them over to him so that he could bring them back to the hotel. He was grateful to have the Meat Masala and the Sabzi Masala that I got from Pune. I headed downstairs at Ibis Praha Mala Strana's dining area for breakfast with the likes of Lenka Segura and Cristian Le at around 0730am after hearing back from Michal Konecny about his possible delay in arriving at the event venue that day.

It was a fun conversation to know how Cristian had been a globe trotter just like another friend of ours, Matthew Holmes, and had been all over from Romania to Japan, and from Vietnam to the Czech Republic. I found it to be an interesting point of view to add to my experience of jumping countries only when I had to participate in or organize free and open source events around the globe. When it came to breakfast though, I found myself to be just as disappointed with the food choices as the day before, so I instead focused on the conversation about Lenka's talk on Forgejo Runners on that day. Sticking to barebones lettuce salad, a warm cappuccino and scrambled eggs allowed me to stay energized for the rest of the day, or until the Lunch And Learn Matching afternoon event at the very least.

Fetching our conference backpacks from our hotel rooms, the three of us marched to the conference venue. As we had checked in to the event on the day before, I had a quick chat with Jef Spaleta, checking on his keynote preparation, while he talked with me about Fedora Mindshare's proposed experiment of using a trusted service funding platform for sourcing/distributing event funding. We also touched base on the ratification of the responsibilities of representatives to the Fedora Council. It included two folks, one from the Fedora Engineering Steering Committee and one from the Fedora Mindshare, and we agreed upon just how this had been entirely dependent on the representatives themselves so far. Having documentation could establish a baseline expectation for these liaison reps during their elected terms.

While Jef wanted to first understand the perspectives of the current liaisons, I emphasized just how important it is to have a documented baseline to begin from. As I was Fedora Mindshare's elected representative to the Fedora Council at that point in time, I remarked just how important it was to use the momentum to build the foundation that could then be iterated upon. After wishing him luck for his talk and sharing some Indian snacks with him, I moved away to chat with Tomáš. Since I was also part of the Fedora Council Townhall Session that was scheduled right after the keynote presentation, I knew that the second day was just as occupied for me as the first one. On Tomáš' (rather impromptu) request, I glanced through the draft post that conveyed the Pagure service retirement announcement, slated later.

With just how far Pagure had a reach as a general-purpose collaborative project hosting service, Tomáš chose to publish this on the Fedora Magazine. We wanted to provide a last-minute grace period for the straggling repositories before we rendered the Pagure service read-only for the foreseeable future. We wanted to avoid pushing back the decommissioning process until the end of the year 2026 and instead keep a local copy of the repositories that could be acquired on explicit request. After providing my approval, I went on to chat with Jona Azizaj inside the Plenary Hall about the Fedora Mentor Summit Contributor Recognition Awards announcement planning, and how it had to be done right before the Closing Notes were delivered by Justin Wheeler on the next day at the tail end of the conference.

Following Justin's quick event opening announcements, Jef followed through with his community and userbase metrics on the Fedora Project's growth since the last Flock To Fedora conference at around 0915am Central European Summer Time. I know how he worked with Michael Winters to attain those statistical findings, and this session was swiftly followed by the Fedora Council Strategic Proposals session at around 1000am Central European Summer Time. After a quick round of intros from the Council members, we addressed questions from attendees – both those who were attending in person and remotely. Finishing up with the session allowed me to connect with Carol Chen and Matthew again, with whom I shared some Indian snacks too, before being pulled aside by Cornelius Emase in his discussion.

During the coffee break, Cornelius and I briefly discussed the state of open source mentorship programmes with the rise of AI-assisted contributions. I looped Justin into the conversation as well, as the tireless low-quality contributions had finally pushed me into not wanting to participate as a formal mentor in free and open source software projects for the foreseeable future. My mentoring experience with the Fedora Badges Revamp Project had been the last straw, and it only made us mentors want to reinforce regulations around incessant AI tooling usage. While munching on the cookies, Justin also mentioned that he wanted to keep some time aside for having a conversation about my recent experience and discover pathways to prevent burnout occurring to selfless mentors in free and open source software.

We reflected on just how unfair it all had been - both for the applicants genuinely trying their best to make the cut and for the mentors wasting their human hours reviewing thoughtless contributions. Since Cornelius had continued to contribute to our community beyond his Outreachy mentoring participation cohort, I shared my appreciation for everything he did as a volunteer contributor. Carol joined in to cheer the conversation up as she shared just how hard her first formal mentoring experience would have been, had it not been for the likes of Justin and myself. Her Outreachy intern had been proactively participating in the mentoring programme even while using AI tooling, and that honestly felt like the correct pathway towards regular contributions to the Fedora Project, or any community for that matter.

At around 1130am Central European Summer Time, the townhall session for the Fedora Engineering Steering Committee began. As compared to that of the Fedora Council's, a smaller number of elected members were able to make it to the event. I decided to volunteer as fallback session chair personnel while the Matrix chat was being handled by someone else. All I had to do was signal Aoife Moloney, who was hosting the Ask Me Anything Session, to inform her about the time left. This was followed by Stef Walter's fancy presentation on Fedora Linux Hummingbird Linux at around 1230pm Central European Summer Time. I finished the first half of the day with a lively chat with Ankur Sinha and Kashyap Chamarthy around Two Factor Authentication Enablement for effectively securing the packager workflow.

Just like the day before, Michael Scherer and Ankur decided to help Jona and me out with the Lunch And Learn Matching social event. I was glad to note that our move to the earlier partition helped significantly as we eventually ended up having more folks. The topics on that day were Interpersonal Skills, Packaging, Events, and Infrastructure. I invited Stef and his associate into the event as well, and Kevin Fenzi followed soon after. Jona and I went around the tables to click photographs and to inform folks about the Fedora Badges, they could get when they scanned the QR code on the printed menu. Since Michael could not join the interactive workshop on Fedora Badges on the previous day, he was greatly impressed when I shared with him what the staging Fedora Badges deployment looked like at lunch.

Once we were able to establish a respectable presence at the dining tables, Jona, Ankur, and I finally decided to get something to eat. The queue had subsided by that time, and we could calmly march out with our food plates. After a brief chat with Jiri Konecny, who barely arrived at the event just that afternoon, I wished him well for his onward journey to DevConf.CZ 2026. We chanced upon Debarshi Ray in the queue as well, and finishing up a (much improved from the day before) meal allowed us to head into Lenka's talk on Forgejo Runners. I tried my best to salvage the presentation progress, which was dreadfully haunted with intermittent audio video issues. While acting as the microphone runner, I also diagnosed the audio reception by checking in with the remote attendees on the Matrix chat.

As there were a pair of wireless microphones in the Sapphire room, passing one over to Lenka allowed her to have a more hands-on approach with the talk. To add to that, it also helped improve the voice reception since the microphone on the podium was having issues. What baffled me to no end was that the scheduled talk at 0200pm Central European Summer Time managed to "rickroll" all of the folks, both in-person and remote ones - Well played, Lenka haha! Ankur and I headed in the talk on The EU CRA vs Community by Jaroslav Reznik and Roman Zhukov at around 0230pm Central European Summer Time. In the little time before the talk began, Carol reflected on how 2026 was her first time attending the Flock event, even though she usually visited many conferences and events around the globe.

Besides Michael's chat on how the Fedora Mindshare's proposed experiment had previously had auditing challenges, I decided to onboard Carol into my grand plan for the Fedora Project's APAC presence at FOSSAsia 2027. That made her the next person I reached out to, apart from jokingly mentioning it once to Cristian, who also belonged to the APAC region. As I said during the Fedora Council Townhall Session, I felt that it was crucial to meet the community members where they were and hence, intra-regional travel was a logistically feasible and cost-effective way. I spent the remaining time of the session taking notes on the policy exchange, while talking with the audio video engineering personnel to attempt fixing the YouTube livestream that broke due to the inadvertent swapping of the streaming keys.

I was informed by the engineering staff that applying corrective measures would require the livestream to be stopped. I advised them not to do so, at least until the session was finally over, as that would be an effectively less destructive method to resolve the issue. Thankfully, Gregory Sutcliffe jumped right in to swap the stream names, thereby providing an expedient workaround for the same that did not need us to stop the livestreaming then. After a Matrix chat with Michael, I slipped out at around 0330pm Central European Summer Time to discuss with him on how we could join forces in leveraging the Project Hatlas into discovering useful Fedora Badges. For a conversation that was supposed to last for thirty minutes or so, we did not realize how more than an hour had already passed by in the blink of an eye.

While the initial conversations were about how the Fedora Data Work Group and the Fedora Badges Revamp Project could help each other, we delved deeper into what ideas drive each of us towards contributing selflessly to free and open source software communities. I remarked on just how his hands-on approach towards solving effective community health metrics allowed the community to trust him with what he did and the approaches he took to get there. He also shared a great deal of informative resources that guided his core ideas and his motivation to keep pushing on with Project Hatlas. Upon deciding to connect later on the actual topic, I found myself (quite literally) swiftly ambushed by Jean-Baptiste Holcroft and Michael, who wanted to pick my brains on their needs with Fedora Messaging.

They wanted to understand just how easy (read, difficult) it would be to import retroactively about 14.6 million event messages into the Fedora Messaging service by implementing the webhook support for the Weblate platform. To make matters worse, he also wanted Fedora Badges to be awarded based on the events from these many messages. Given the limitations of the application platform, we had to write a one-shot script to process these requests retroactively first before resuming the automated consumption of messages using the webhook support. It most likely was not an easy task to achieve, but as I wanted to help him out with the same, I requested that an issue ticket be created with Fedora Infrastructure so that it could be investigated further and developed upon once we got back from the conference.

Justin quickly dropped in to provide information on the social event, which was to begin 0600pm Central European Summer Time onwards. After finishing the chat on adding approximately 14.6 million messages to the count of 3.5% of the stored Datanommer messages, I had a quick followup with Justin and Michael. I was also able to provide some snacks to both Matthew Miller and Justin when we were just about to leave for the Manifesto Culture Zone Prague for the Flock To Fedora 2026 Official Party. Joined by Carol, our group walked from the event venue, and after a quick round of instructions from Dorka Volavkova and receiving some meal coupons with the drinks, I was seated in a dedicated area with Sarah Julia Kriesch, Michael, Carol, and two more attendees, enjoying starter meals and soft drinks.

With the upper limit of 400 CZK on the meal coupon and a wide variety of cuisines to try out, the official party ended up being quite the culinary experience for us all. Do not get me wrong though - I surely miss being on a cruise boat like the previous time, but this felt like an equivalent tradeoff for someone like me who was easy to please. I stepped out along with Toshio Kuratomi, Carol, and Michael to find some bites for dinner. Being the indecisive folks that we were, Carol and I finally settled for Korean food while Michael got himself an Italian dish. While we were offered a refund for the remaining amount of the coupon price, we declined and were even offered a grape-flavoured soft drink as an appreciative gesture. I fairly struggled wondering how they ran their business with such amazing selfless thoughtfulness.

After informing the organizing committee about a potential mishap, we returned to our tables to have our dining fills. With Toshio sharing with me about new folks coming for the Dancing With Toshio Fedora Badges achievement and a little chat with Michael, the two of us were called back in by Justin and Shaun for a round of commemorative photographs. The three of us went for some gelato after the photo shoot was done, and I settled for a double scoop of raspberry and mango in a dark-coloured edible cone. This is where I met up with Nicolas Chauvet and Dominik Mierzejewski, striking chat on the Fedy project for installing third-party software applications from RPM Fusion repositories. I was surprised that he did remember my progress on the (now deprecated) NVIDIA Auto Installer for Fedora Linux.

Carol checked in with me on whether or not I wanted to leave, and as it was getting darker, it was not that bad of an idea to leave soon. As much as I wanted to stay back for a little while longer, at 0900pm Central European Summer Time - I was better off preparing for the next day of the Flock event. After finishing off the chat with the two and sharing this magical full circle moment with Justin, Carol and I walked back to the Anděl crossing before going our separate ways. I briefly came back to TESCo at around 0930pm Central European Summer Time to purchase some items for my family and friends. Deciding not to extend my activity longer, I headed back to Ibis Praha Mala Strana after around an hour to rest up and prep for the Fedora Mindshare Townhall Session that I had scheduled on the next day.

Flock 2026

Posted by Jeremy Cline ( Fedora Account System Username

jcline ) on 2026-07-09 16:14:00 UTC

Another Flock to Fedora conference has come and gone, and like last year, this one was held in Prague. Unlike last year, I was not in the middle of moving across the country (again) so I was able to attend, thanks to my employer.

As always, it was great to see so many familiar faces and meet new folks face-to-face. To those of you who weren’t able to make it, you were missed. And, as always, I spent a lot of time in the hallway track talking to people, getting a sense of what everyone was working on and interested in.

Day -1

The day before the conference started, there was a sponsorship dinner. Although Bex did all the work getting the paperwork to the correct people at Microsoft, he wasn’t able to make it to Prague in time for the dinner so I was sent. I arrived on Saturday morning after a quick connection through Dublin, which gave me plenty of time to get settled in and resist taking a nap. I spent the dinner chatting with Kevin Fenzi and Jef Spaleta, and while I can’t remember all the topics, curling was definitely mentioned.

Day 0

I volunteered to help at the check-in desk the morning of the first day, which I felt went very smoothly (the new label makers were a nice addition). It was nice to help out, but it was also a great way to match names I’ve seen on Matrix to faces as folks arrived. After my shift, I got sucked into the hallway track until lunch.

After lunch and a bit more hallway track, I went to the “PR-based Gating for Fedora: Can We Make It Work?” workshop from František Lachman. There was a lot of discussion in and around the Fedora contribution workflow which I have lots of thoughts about, but I felt there was a rather widespread desire to make things better (even if the exact way we do that isn’t clear). Lots of people who were not me brought up keeping the specfiles in one repository rather than forty thousand or however many git repositories we’re up to. In any case, I’d really like a nice pull request workflow for Fedora where I can’t mess up updates, and where we can all share the tooling we build around packaging.

I spent the rest of the day in the hallway track, doing some last minute preparations for my talk on signing, and preparing for the joint Microsoft talk with Reuben and Bex. I was happy to meet some of the Red Hat folks working on cryptography and signing, and I’m hopefully somewhere down the line we can all do approximately the same thing for signing content.

I got dinner with Bex and Reuben at some place that served North Carolina style BBQ, and it was pretty good (especially with kimchi on top!).

Day 1

This was the first day of recorded presentations. I went to the usual “State of Fedora” address, followed by the Fedora Council and FESCo panels. I thought it was interesting (but sadly unsurprising) to see downward trend of contributors, and I’d be interested to see a further breakdown of who’s leaving. I have plenty of not-backed-by-hard-data ideas about why this is happening, but I do hope it leads to a stronger focus on (and acceptance of) improving the contribution experience - the general feeling in the hallways, as I mentioned earlier, makes me somewhat optimistic.

After lunch and a bit of hallway track, I went to the “Secure by Design: Aligning Fedora with the EU Cyber Resilience Act (CRA)” workshop by Jaroslav Řezník and Roman Zhukov. A good portion of it was a run down of what the CRA entailed and how the roles it describes map into Fedora. After that I spent a bit of time preparing for my talk. My talk went well, I think, except the live demo didn’t entirely work (gpg2 + gpg-agent + gnupg-pkcs11-scd is very finicky and I forgot a setup step). With that stressful event out of the way, I was able to relax a bit at the dinner party, chat with numerous folks, and fill up on the “appetizers” they brought out in vast quantities. Big props to the event organizers, the weather was great and I really appreciated the open space and variety of food options.

Day 2

It was hard to believe it was already the final day of the conference, but I think at this point I was also feeling pretty worn out. I went to Justin’s “State of the Fedora Kernel” talk, and was glad to hear that the GitLab workflow I helped build before I left wasn’t absolutely terrible. I made some last minute edits to the slides for our “Two Years In: Accelerating Microsoft Contributions to Fedora” talk (where I was happy to have Bex and Reuben do most of the talking), then helped present that talk. Afterwards I went to the “What’s new in Fedora CoreOS” talk and managed to chat with Jean-Baptiste Trystram and Joel Capitao about signing and Konflux, which we’ll hopefully get sorted out in the next couple weeks (in the staging environment, anyway). Hopefully we’ll also be able to get Fedora CoreOS images into the Azure community gallery alongside the Cloud images.

The lightning talks were all enjoyable, and I’m really impressed some folks even managed to make up slides for theirs and nothing went terribly wrong (great work everyone). There was time for a bit more hallway track, and then I went to the Contributor Recognition Program, which concluded the presentations for Flock 2026. I spent the evening catching up with old and new friends, chatting about ideas on improving various bits of Fedora infrastructure, and how to make the contributor experience better. People were already leaving for DevConf (or home) at this point, so if I didn’t get a chance to say goodbye, I’m sorry and I hope we’ll see each other next year!

Day 3

It was an uneventful trip back home, thankfully.

I’m looking forward to put all the work I’ve done on improving Fedora’s signing infrastructure through its paces, to get support for PQC done, and I have a few ideas on what to work on next. Hopefully some of them work out and don’t lead to too many people screaming at me. Flock is a great event to get excited about the next year of work and to test the waters on wild ideas, so I’m really glad I was able to make it this year.

HDR Kodi available for Fedora

Posted by Tomasz Torcz ( Fedora Account System Username

ttorcz ) on 2026-07-09 15:53:18 UTC

RPM Fusion shipped Kodi 22-beta1 for Fedora 44. This is the version with PR adding HDR support under Wayland merged. It's a bit weird seing a beta version submitted as an update to stable branch, but hey, it works. Thanks Leigh!

It works OK under GNOME session with HDR enabled. The UI elements are bit oversaturated when playing High Dynamic Content, but the videos themselves are pretty. At last. This is the year of HDR on Linux Desktop.

If only GeForce Now would catch up with the times…

068/100 of #100DaysToOffload

Heroes of Fedora Quality for Q2 2026

Posted by Kamil Páral ( Fedora Account System Username

kparal ) on 2026-07-09 13:32:32 UTC

The second quarter of 2026 is over, and so in this post we’d like to highlight the top Fedora Quality contributors who helped us maintain the quality bar for Fedora during this time period. Fedora wouldn’t be a high-quality distribution without its community. Every single person who helped us detect and resolve issues, or verify that things work as expected, deserves our gratitude, thank you!

If you haven’t participated yet in testing Fedora, perhaps you’d like to give it a try? We gladly welcome everyone. Please look at our Fedora Quality homepage.

Testing proposed updates

When software packages are updated in Fedora (bringing bug fixes and new features), they are not released to end users immediately. They first go to the updates-testing repository, where they undergo automated testing, and also await manual feedback from human testers. This feedback can be provided through Bodhi, either by using its web interface or CLI tools, see instructions. Alerting package maintainers by posting a negative feedback with a problem description can stop the update from reaching general audience and causing issues to all our users. Testing proposed updates is a simple, yet vital process for keeping Fedora releases of high quality during their whole lifecycle. It is used both for already stable and in-development Fedora releases.

Test period: Q2 2026 (2026-04-01 – 2026-06-30)
Contributors: 408
Updates commented¹: 5103

Name	Updates commented
Derek Enz (derekenz)	882
Geraldo S. Simião Kutz (geraldosimiao)	811
Filipe Rosset (filiperosset)	437
besser82	287
bojan	263
Ian Laurie (nixuser)	214
Eugene Mah (imabug)	187
anotheruser	129
Colin Thomson (g6avk)	111
Kamil Páral (kparal)	82
Wasser Mai (wasser19641)	68
Ephraim Kaov (ephmo)	66
Adam Williamson (adamwill)	63
markec	62
Neal Gompa (ngompa)	61
Joe Ant (maketopsite)	54
František Zatloukal (frantisekz)	48
Michel Lind (salimma)	30
Cristian Ciupitu (ciupicri)	27
brett h (bretth)	24
patchman	24
Simon de Vlieger (supakeen)	24
Alex Gurenko (agurenko)	23
niels-s	23
Steve Cossette (farchord)	21
Ankur Sinha (ankursinha)	21
Carl George (carlwgeorge)	19
Benjamin Beasley (music)	17
itrymybest80	17
Fabio Valentini (decathorpe)	17
John Howard (johnh99)	16
Gilles Duboscq (gilwooden)	16
robatino	15
JR Sanders (jrsanders)	14
Pawel Buzniak (pawef10)	13
Davide Cavalca (dcavalca)	13
Peter Robinson (pbrobinson)	13
Christopher Klooz (py0xc3)	12
Oleg Obleukhov (leoleovich)	12
Petr Pisar (ppisar)	12
Patty Berge (thetick)	11
Lukáš Růžička (lruzicka)	11
Yixin Wei (esoapw)	11
Marcin Juszkiewicz (hrw)	11
rosti	11
Luca Boccassi (bluca)	10
Vadim Fedorenko (vfedorenko)	10
Daniel Anderson (lordalfredo)	10
Miro Hrončok (churchyard)	10
Mattias Ellert (ellert)	10
…and also 358 other testers who commented on less than 10 updates each, but 750 comments combined!

¹ If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.

Test days participation

Test Days are events which are partly focused on testing Changes planned for an upcoming Fedora release, but they also regularly test important areas of the Fedora distribution, like upgrades, internationalization, graphical drivers, desktop environments, kernel updates, and others. The upcoming and past events can be seen in our Testdays app.

Test period: Q2 2026 (2026-04-01 – 2026-06-30)
Contributors: 25
Test cases executed: 76

Name	Test cases executed
nielsenb	10
clnetbox	6
imabug	6
nixuser	5
pauloheaven	5
guiltydoggy	5
adriend	4
g6avk	4
anotheruser	4
bittin	3
psklenar	3
agurenko	2
bretth	2
derekenz	2
augenauf	2
geraldosimiao	2
luya	2
py0xc3	2
boniboyblue	1
itrymybest80	1
jgroman	1
kurtlindberg	1
g4ridwan	1
farel	1
pstourac	1

We sincerely thank all contributors!

Are you also interested to help? Please look at our Fedora Quality homepage.

Syslog-ng Java destination disabled

Posted by Peter Czanik ( Fedora Account System Username

czanik ) on 2026-07-09 13:19:41 UTC

For many years, syslog-ng used Java, where C libraries were unavailable. However, over the years native C libraries became available for Elasticsearch and Kafka, and HDFS practically disappeared. As a “scream test”, I am going to disable Java support in all of my syslog-ng packages.

Once upon a time, Java support was added to syslog-ng to be able to load Elasticsearch Java drivers. Later, Kafka, HDFS, and a generic HTTP destination were also added. Unfortunately, using Java was a major pain. Loading libraries required some manual configuration. Packaging the Java destination in official Linux distribution packages was possible, however, packaging the actual drivers written in Java was impossible. For a while, I maintained unofficial packaging for these drivers, but as C alternatives appeared, I removed these components. Nobody complained. Recently all drivers, except for HDFS, have been removed from the source code as well. Again: nobody complained.

Right now, we still have HDFS support in the source code, but not for long. I have been posting about it for years now, and nobody asked us to keep it. This is the last driver making use of the Java destination of syslog-ng. We will delete it soon, too.

We do not delete code related to Java right now. However, as a “scream test” I am going to disable the Java destination in all my packages. I have done it already in the official openSUSE syslog-ng package. Fedora Rawhide is next. I will also remove it from my git snapshot packages.

If you use Java with your own driver code, let us know! Otherwise, the Java destination will be not just disabled in packages but removed from code as well.

Red Hat EX467 exam

Posted by Fabio Alessandro Locati ( Fedora Account System Username

fale ) on 2026-07-09 00:00:00 UTC

Last Friday, I renewed my Red Hat Certified Specialist in Managing Automation with Ansible Automation Platform (EX467) certification. As I’m already a Red Hat Certified Architect and have passed this same exam about three years ago, I wasn’t too worried about it.

The exam still focuses on leveraging the Ansible Automation Platform in enterprise environments rather than writing Ansible code, which remains the domain of the EX294. Compared to three years ago, the platform version has been updated, but the overall structure and approach felt familiar. Timewise, the exam continues to be completable well within the allocated time if you have enough experience with the platform. This time it took me 1 hour and 38 minutes to go through it.

Megacable: Modo puente con un gateway linuxero

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-07-07 20:50:00 UTC

Hoy se me ocurrió que quiero mi módem de Megacable en modo puente. La neta, tener doble NAT es un dolor de cabeza si quieres hospedar tus servicios, recibir conexiones directas o simplemente tener un ruteo limpio. Así que decidí ponerlo en modo puente y, de paso, resolver el detalle de que el perfil de IP pública no incluye IPv6.

Aquí te cuento toda la historia y cómo configuré mi gateway con NetworkManager y Firewalld para que todo jalara bien chingón.

Note

Para fines prácticos y por mera seguridad de mi infraestructura, todas las direcciones IP (tanto IPv4 como IPv6) y nombres de dominio externos mostrados en este artículo fueron modificados. Son meros ejemplos de demostración, no te vayas con la finta.

La llamada

Para poder cambiar el módem Huawei HG8145V5 a modo puente, necesitaba las credenciales de administrador (root). El problema es que cambian todos los días. Y, ahí estuve, llamando a las 01:15 hrs y me contestaron de volada. Me tomó unas 5 llamadas para conseguir las claves del día, pero al final la paciencia rindió frutos. Me explicaron que para darme acceso de administrador y ponerme en modo puente, el procedimiento requería contratar una "IP pública dinámica".

A final de cuentas, me pareció una buena idea y decidí pagar los 100 varos extras al mes para salir del Carrier-Grade NAT (CGNAT). Al final sí se armó la cosa: me asignaron una IP pública real y con eso pudimos avanzar sin problemas.

El modem

Ya con acceso root al módem, configuré el equipo para que no se sobrescribiera la configuración con las actualizaciones automáticas remotas (TR-069) y asegurar la estabilidad de la red.

Para lograr esto, hice lo siguiente:

Entré a System Management -> TR-069.
Desmarqué Enable ACS Management y Enable Periodic Informing.
Fui a la configuración de WAN y borré por completo el perfil TR-069 de administración remota. Así les corté el cable de tajo.

Luego, modifiqué el perfil de internet principal (el cual suele llamarse algo como INTERNET_R_VID_XXX):

Cambié el WAN Mode a Bridge WAN.
Mantuve habilitado el VLAN ID con el tag correspondiente a mi zona.
En las opciones de copiado de puertos (Binding Options), seleccioné LAN1, que es donde tengo conectado el cable hacia mi gateway.

Apliqué los cambios y ¡madres!, el módem se convirtió en un simple puente transparente. Mi gateway recibió la IP pública (198.51.100.50) de volada vía DHCP en la interfaz enp3s0.

El drama

En cuanto se activó la IP pública, me di cuenta de que el IPv6 ya no estaba disponible. Volví a hablar con soporte y de manera muy clara me explicaron la situación: en su plataforma, los perfiles del BNG están separados, de modo que el perfil de IP pública es estrictamente IPv4-only. O tienes IP pública o tienes IPv6 nativo, pero no ambos al mismo tiempo.

Como yo no me iba a quedar sin IPv6, decidí usar un túnel broker. Fui a tunnelbroker.net (de Hurricane Electric), me registré y configuré un túnel apuntando a mi nueva IP pública. El servidor de Dallas, TX (198.51.100.1) fue el que me dio menor latencia (unos 62 ms promedio).

El gateway

Aquí es donde viene lo chido. Para que todo funcione de manera permanente, configuré mi gateway con NetworkManager, firewalld y radvd.

Primero, creé el túnel SIT (Simple Internet Transition) en mi gateway ruteado sobre la interfaz física:

# Crear interfaz de túnel SIT en NetworkManager
nmcli connection add \
   type ip-tunnel \
   con-name he-ipv6 \
   ifname he-ipv6 \
   mode sit \
   remote 198.51.100.1 \
   ip-tunnel.parent enp3s0 \
   ipv4.method disabled \
   ipv6.method manual \
   ipv6.addresses "2001:db8:1::2/64" \
   ipv6.gateway "2001:db8:1::1" \
   ipv6.route-metric 100 \
   connection.zone external

Note

Configurar ip-tunnel.parent en lugar de una IP local estática es un parote, porque si tu IP pública cambia, el túnel sigue amarrado a la interfaz correcta.

Luego, configuré mi interfaz de red local (enp2s0) para manejar mi prefijo ULA (para cosas locales) y el bloque IPv6 global que me dio Hurricane Electric:

# Asignar ULA y GUA pública a la LAN
nmcli connection modify enp2s0 \
   ipv6.method manual \
   ipv6.addresses "fd41::1/64, 2001:db8:2::1/64"
nmcli connection up enp2s0

El Firewall

Para que el túnel levante, el firewall debe permitir el tráfico del protocolo 41 (SIT) desde el servidor de Hurricane Electric. También quería asegurarme de no hacer NAT66 (masquerading) en mi prefijo IPv6 público para tener ruteo nativo, pero sí mantenerlo en mi prefijo ULA (fd41::/64).

Bueno, ahí va el cotorreo para configurar firewalld:

# Permitir protocolo 41 en la zona externa
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv4" source address="198.51.100.1" protocol value="41" accept'

# Quitar masquerading global de IPv6
firewall-cmd --permanent --zone=external --remove-rich-rule='rule family="ipv6" masquerade'

# Habilitar masquerading exclusivo para la ULA
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv6" source address="fd41::/64" masquerade'

# Aplicar cambios
firewall-cmd --reload

Repartiendo IPs con radvd

Para que todos los clientes de la red local obtengan sus IPs globales automáticamente mediante SLAAC, edité el archivo /etc/radvd.conf para anunciar ambos prefijos:

# /etc/radvd.conf
interface enp2s0 {
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;
   prefix fd41::/64 {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
   prefix 2001:db8:2::/64 {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
};

Encendí el servicio:

systemctl enable radvd
systemctl restart radvd

La automatización (DDNS)

Como la IP pública de Megacable es dinámica, cada vez que cambie, el túnel de Hurricane Electric se va a romper si no le avisamos al endpoint del nuevo valor de la IP.

Para no tener que andar haciéndolo a mano, me armé un script despachador de NetworkManager en /etc/NetworkManager/dispatcher.d/50-he-tunnel-update.bash que reacciona de volada cuando cambia la IP en la interfaz WAN (enp3s0) y actualiza el túnel mediante la API de HE.

Por mera seguridad, las credenciales (usuario, Update Key de la pestaña Advanced del túnel, e ID del túnel) las guardé en un archivo separado en /usr/local/etc/tunnelbroker.bash con permisos 0600.

El script del dispatcher se ve más o menos así:

#!/usr/bin/bash
# Despachador de NetworkManager para actualizar la IP del túnel
set -euo pipefail
IFS=$'\n\t'

readonly Interface="enp3s0"
readonly ConfigFile="/usr/local/etc/tunnelbroker.bash"
readonly UpdateUrl="https://ipv4.tunnelbroker.net/nic/update"

main() {
    local -r interface="${1:-}"
    local -r action="${2:-}"

    if [[ "$interface" != "$Interface" ]] || [[ "$action" != "up" && "$action" != "dhcp4-change" ]]; then
        return 0
    fi

    # shellcheck source=/dev/null
    source "$ConfigFile"

    # Enviar actualización a HE
    local response
    response=$(curl -4 -sS -G \
        --data-urlencode "username=$username" \
        --data-urlencode "password=$password" \
        --data-urlencode "hostname=$hostname" \
        --data-urlencode "myip=AUTO" \
        "$UpdateUrl")

    if [[ "$response" =~ ^(good|nochg) ]]; then
        # Reiniciar conexión he-ipv6 para refrescar
        nmcli connection up he-ipv6 &>/dev/null || true
    fi
}

main "$@"

¡Madres! Con esto, la actualización de la IP queda automatizada y el túnel se levanta solito sin importar cuántas veces Megacable nos cambie la IP WAN.

La prueba de fuego

En cuanto encendí radvd, mi workstation obtuvo su dirección IPv6 global (2001:db8:2::100/64).

Para probar si de verdad todo jalaba, levanté mi servidor Caddy local y corrí un curl desde un VPS externo (vps.ejemplo.net) apuntando directo a mi IPv6:

ssh vps.ejemplo.net "curl -6 -I -m 5 http://[2001:db8:2::100]/"

Me devolvió un hermoso HTTP/1.1 200 OK de Caddy de volón pimpón. Cero NAT, cero complicaciones y ruteo nativo directo a mi máquina. ¡Una chulada!

¿Qué te parece? Si estás atorado con el doble NAT de tu ISP, mándalos a la chingada y ármate tu propio túnel. Vale totalmente la pena.

Referencias

Day One - Flock To Fedora 2026

Posted by Akashdeep Dhar ( Fedora Account System Username

t0xic0der ) on 2026-07-07 18:30:32 UTC

Unlike the Flock To Fedora 2025 event proceedings, the workshops were planned to be frontloaded into the conference this time. As there were no presentations or townhalls on the first day, it also meant that there was no live streaming on our YouTube channel either. Heading to bed a little early the day before was the right thing to do, as that allowed me to wake up at around 0500am Central European Summer Time on 14th June 2026. Of course, the jet lag prevented me from getting proper respite, but still it was better than nothing at all. After one last look at the slide decks for the (newly created) Fedora Forge Progress Update and the (FOSSAsia-intentioned) Fedora Badges Revamp Project, I uploaded them on the Pretalx platform for them to be available to both in-person and remote attendees.

While I had Tomáš Hrčka's help for the former, I had to drive the latter by myself since Chris Onoja Idoko could not make it to the conference this time. I also found it an amusing observation that while the Fedora Badges Revamp Project was scheduled as the last presentation for FOSSAsia 2026, the workshop on the same topic was planned as the first workshop for Flock To Fedora 2026. As it was scheduled for 0900am Central European Summer Time, I had to ensure that I had the venue's audio/video setup configured properly for my purposes. On meeting the likes of Frantisek Lachman and Michal Konecny at the breakfast table at around 0700am Central European Summer Time, we shared conversations about contemporary governance and technological innovations around the world.

Michal and I left for the venue at around 0800am Central European Summer Time after a quick trip back to our rooms to fetch our conference backpacks, because we anticipated the early crowd to be denser at the registration desk with the attendees rolling in swiftly. Amidst meeting up with a bunch of familiar faces during our short walk to the event venue, I could not shake the familiar feeling of attending the Flock event at the same place and at nearly the same time as the previous year. Unlike the last time, I did not assume that I would automatically get registered when my proposals got selected, and that led the registration check to go smoothly. Meeting up with Dorka Volavkova at events had always been a pleasure, especially even more so when she promptly helped out with the venue's audio/video setup.

Running into the likes of Kevin Fenzi and Alexander Bokovoy in the hallway track did lead to some interesting community conversations, but I decided to keep those short to be present in the Opal room and prepare my distributable apparatus of sticky notes and sketch pens that I flew in all the way from Kolkata for this usage. Since the event venue provided multiple thin-sized A4 notebooks and rolling ballpoint pens at the attendee seats, all I had to do was provide the sticky notes for the hands-on activity on the heuristic user experience evaluation. After wishing Hristo Marinov the best, as even he was running an interactive workshop at the same time although in a different room, I found attendees gradually arriving at the Opal room for my workshop by around 0915am Central European Summer Time.

I realized that I had to manage the workshop's cadence on the move to ensure that I was addressing both the folks who had been there from the beginning and those who were just joining after some time. As I wanted to respect the time of the three folks - Vittorio Cioe, Jonáš Hubený, and Vít Smolík - who decided to join, I kicked off the workshop session then while recapping for the joining folks whenever we had them dropping in every now and then. My intuition to front-load the years-long backstory of the revamp initiative was on point, as it made little to no sense to start off the interactive parts with just three people attending. While I explained the architecture of the project system and the progress of the efforts through the multiple years, the attendee number increased from just three to over fifteen.

It was the right time to begin handing out the sticky notes, all while revealing the staging instance of the Fedora Badges deployment to the community. Gauging the individual awareness of the project also helped me cater specifically to those who did not know much about it but were deeply engrossed in learning. Since I had to cover the design modernization too, I blended superficial experience with technical talks, all while giving folks the time to provide feedback on the overall experience. While folks like Matthew Miller, Matthew Holmes, Justin Wheeler, Jona Azizaj, Cornelius Emase, and Ankur Sinha added to the activity as longtime volunteers, I also got feedback from interested newcomers to Fedora Badges like Shawn Dunn, Emmanuel Seyman, Guillermo Leiro, Misia Mary, Vittorio, Jonáš, Vit and more.

Matthew even mentioned handing over the ecosystem Discourse syncing script that integrated the achievements from the Fedora Badges backend into the Fedora Discussion platform. I was also helped with brilliant photography by Jakub Jelen and Misia, who took care of the entire event's photography efforts. The lenient ask of using either a mobile phone or a laptop computer to access the staging service also allowed me to obtain more involved feedback that I was able to take back to Aurelien Bompard and Shounak Dey. The second half of the interactive session became more involved, and I ended up overshooting the designated time by ten minutes or so. As there had been a twenty-minute-long break planned between the one-hour-and-forty-minute-long workshops, that was not really a deal breaker.

While I did not necessarily eat into someone else's designated time, I barely had about ten minutes to take a resting breath before heading back into the Sapphire room. If you can believe it - not only, did I have two workshops to organize on that day, but those were also scheduled in succession. With Tomáš being surprised that his HDMI support on Fedora Linux Asahi Remix was working flawlessly, I made it into the room at around 1055am Central European Summer Time. This was also a whole lot more packed with folks than the previous one, so the two of us decided to start five minutes after the designated time. If I had to attribute why there were relatively more folks here than in the previous workshop, a small part of it would be the scheduled time, but a large part had to do with the significant relevance.

Being a critical initiative for the last couple of years in the Fedora Project, we were now heading into the Dist Git service aspect and were planning on rendering the Pagure service read-only. I spent the first half sharing the progress updates since the previous year's Flock event before handing it over to Tomáš for the plans for the Dist Git migration development. I made it a point to inform attendees on the housekeeping aspects, continuous integration, private issues, migration progress, learning pathways, and community involvement with due credit. That helped us take advantage of the attendees being present there in person for interactivity. The reception was a lot better than the previous year, with the folks participating not only in the hands-on updates but also in the future plans of the critical initiative.

We encouraged the attendees to pause us in between to ask questions or convey concerns as they felt like it. Sure enough, we had discussions around the potential private branches feature from Justin Forbes, the lookaside cache technological implementation from Miro Hroncok, the forced-pushing prevention policy from Fabio Valentini, the possible Pagure documentation change from David Duncan, the Pagure sunsetting service action from Ankur, the Forgejo Actions trigger config from Frantisek, the potential Bugzilla replacement development from Kevin, and other things. Even though there were a lot of talks to do, the workshop interactions felt well-spaced in a way that could be absorbed in the notes that I was taking along the way to share with the team members who could not attend the event.

The neighbouring discussions also included concerns about the support for the Packager Dashboard, the templating of project repositories to include the files for European Union Cyber Resilience Act Stewardship, the need for SSH access for Dist Git project repositories, the methods for conveying the archival state of the source repositories, and other areas. Finishing off the workshop at around 1245pm Central European Summer Time, my involvements continued at the dining area with the Fedora Mentor Summit 2026's Lunch And Learn Matching. Ankur also decided to accompany me in helping out with the organization, and we headed to the lunch area to meet with Shaun McCance and Jona, who were helping prepare the tables for the folks to discuss various topics, all while enjoying delicious food.

On Shaun's expedient advice, we used the whiteboard to draw the attendee crowd towards us, while detailing the topics scoped for discussions on that day. On the fifth year of the Fedora Mentor Summit event, we departed from the need for pre-dated registration for the Lunch And Learn Matching and opened it up to everyone at the conference. This not only allowed for greater participation along the way, but we were also able to curate the involvement based on the selected topics for the three days. Take, for instance, the topics for that day: Documentation, Operations, Development, and Marketing. In a community where everyone is both a mentor and a mentee, anyone could join any table they desired to share what they have or learn from the others, thus making meaningful connections at an in-person event.

Astonishingly enough, it was mostly down to Jona and me at the event to run the Fedora Mentor Summit 2026 proceedings, as many of the helping folks could not make it to Flock To Fedora 2026. We decided to get seated ourselves after setting up the table presences with the likes of Hristo, Kevin, Cornelius, and Ankur with their interested topics. I also suggested to Jona that he take the first separated dining segment from the next day onwards to be able to catch attendees right after they had taken their plates, since the Pretalx platform mistakenly noted that the social event was taking place in the Sapphire room. Also, offering a distinct Fedora Badge allowed us to pull in more folks to our little event, and we were able to close the lunch event as a success by around 0145pm Central European Summer Time.

This also meant that I had no more scheduled obligations for the day - some free time that I used to catch up with the likes of Michael Scherer and Carol Chen after a year or so, since I did not visit FOSDEM that year. Paired up with Ankur now, the two of us headed into the Fedora Data & Analytics Workshop, which was chaired by Michael Winters at around 0200pm Central European Summer Time. Honestly, it was rather impressive to see just how he was able to use the Datanommer store in building a Data Lakehouse that could potentially answer question on effective community health metrics. He even detailed my previous attempts at generating the activity information that I worked on ages ago, called Fedora Contributor or User Activity Statistics, and how he built the first prototype of the Hatlas Project.

The interactive workshop also detailed a variety of data-related infrastructure tools that he made use of and our frustrations with the synchronously built Datagrepper API for fetching information. With Jef Spaleta and Matthew working to fetch data for the Fedora Project Leader Keynote to be presented on the next day, that also involved a bunch of technical debugging and agentic development. Following the closing of that workshop and meeting with Michael on Fedora Badges, Ankur and I headed next into Ellis Low's interactive workshop on Do-It-Yourself AI: Build a Private Customizable Chatbot on Lean Hardware at around 0400pm Central European Summer Time. While the presenter suggested building the projects from source, Ankur and I realised that both of them were packaged in Fedora Linux.

We suggested the use of the officially updated llama-cpp and whisper-cpp packages on Fedora Linux while competing on CPU-bound build times and running lighter hardware models. Strangely enough, at around this time, I found myself banned inadvertently by the automated moderation from one of the Flock To Fedora 2026 Matrix rooms after posting photographs from the event to serve the remote folks, since the workshop proceedings were not live streamed on that day. I was startled, but the banning action was immediately rectified by Steve Cosette, who helped us by remotely moderating the chatrooms manually. We also ran the Docs2DB project locally on our laptops from the PyPI source, and it was impressive to see just how the documentation database could be queried as if it were an expensive chatbot.

I appreciated the deeper focus on decentralizing artificial intelligence workloads and the greater emphasis on running models on local hardware. While Ellis did acknowledge the potential shortcomings of CPU inferencing, the advantages found in data security far outweighed the possible frustrations with slower task. The first day of the event's proceedings was done by 0600pm Central European Summer Time, and I realized that I barely had a few minutes to make it to the lobby for a group dinner with my colleagues from the Red Hat Community Linux Engineering Team. After meeting the ever disciplined and always punctual Fedora Quality Assurance Team at the venue lobby, we marched towards the dining place soon, as we wanted to be back at the venue for the International Candy Swap event too.

I caught up with the likes of Adam Williamson, Kamil Paral, Kashyap Chamarthy, and Lukas Ruzicka, and after being joined by Lenka Segura and Michal, we finally made it to the restaurant. As luck would have it, even this ended up being an Asian place like the day before, but I honestly did not have any complaints with that. Following Tomáš' meal advice from the day before on the dish, and after a chat on the introductory mails for the sysadmin-main incoming membership with Kevin, we departed for the venue again at around 0700pm Central European Summer Time for the International Candy Swap event. Michal and I had to run back to Ibis Praha Mala Strana first to fetch our event offerings, but we were able to rush back to the celebration place right when the introductions were barely about to kick off.

Making a note of the potential allergens and origin introductions for my delicious haul on the paper piece, we went around the table with those discussions. For the hard candies of flavours like Orange, Guava, Mango, Lychee, Tamarind, and Coffee that I flew in all the way from Kolkata, I feared that I might have overdone those additions to the already massive toothache variety. Since Michal and I were stuffed from the team dinner, we had to be extremely choosy with what we tried tasting. I was accompanied by Christopher Klooz, Artur Frenszek-Iwicki, Kacper Skrzyński, Matthew, Ankur, and Emi for the tasting trials before finding a nearby table for a round of Michal's board game, Cyanide and Happiness: Trial By Trolley. We took turns playing the train driver and made comically difficult choices for scoring high.

After being briefly joined by Matthew and Justin at the game table, I found myself getting sleepier by the passing minute, so I decided to call it quits after the first couple of games. I realized that I was struggling to get adequate sleep anyway, and the last thing I would want to do then was to deprive myself of what was duly deserved. I struck a chat with Jona about the planning of the next day's Fedora Mentor Summit proceedings, all while following Justin's advice in getting small pieces of regional candies I wanted to fly back home for my family and friends. I decided to head back to my hotel right after bidding everyone farewell at around 1030pm Central European Summer Time and attempt to catch some shut eye to see just how successful I would end up being after the super eventful first day.

Reflections on Organizing Flock as Fedora Community Architect

Posted by Justin Wheeler ( Fedora Account System Username

jflory7 ) on 2026-07-07 08:00:00 UTC

Reflections on Organizing Flock as Fedora Community Architect

This is the third and final post in my series on Flock to Fedora 2026. The first post covered the highlights of what happened at the event. The second post looked behind the scenes at how Flock gets organized. This post is more personal — it is about what organizing Flock has taught me over the last four years.

The Underrated Importance of Having Fun

The hallway track does not exclusively take place in hallways. At Flock to Fedora, we have a long-standing tradition of fantastic, inclusive social events which invite people to connect over something other than Fedora, Linux, and open source. As someone who has attended several of these social events and now had the privilege to co-organize some of them, I realize this is something truly unique to how we do Flock to Fedora. A lot of attention, time, and care is spent on curating thoughtful evening programming which gets our community to bond, get to know each other, and honestly, have some fun.

In the heavily-corporate world of Open Source in the 2020s, we may not get to discuss the role and importance of having fun as often as we should. But in my experience in Fedora, having fun together as a community is how we build the trust and relationships that get us through some of our most challenging and difficult moments as a project and community. So, whether "hallway track" takes place in the actual venue hallway, a river boat cruise, a local pub, or over a board game, all of these things are critical ingredients to making the Fedora community sustainable for all of the time we spent from wherever we call home, collaborating over video calls, Matrix, Discourse, mailing lists, and the overwhelming number of other places where Fedora contribution conversations take place.

Global Equity and Regional Access

There are lots of things on my mind about Flock 2027, but of course, I am thinking about the where question. Where should the next edition take place? What continent should the next Flock take place? Should we repeat cities more often, or go to brand-new places? How can we make sure we are not only appealing to our long-time contributors, but also our global community of people in regions where we historically had low engagement and participation?

These are the kind of questions that keep me up late at night. Inclusion is critically important to me. Fedora is nothing without the global diversity and perspective we have. Everyone can participate and influence the future of their favorite operating system, and Fedora has processes to ensure that influence is fair, equitable, and open to the community regardless of who you are or where you come from. Therefore, the location decision carries many delicate considerations that are not always obvious to people who have the privilege to attend Flock wherever and whenever it may be.

I do not have answers here, but I am excited to analyze the survey results later this month. The data always tells me a perspective grounded in actual feedback from the community. While there are various complex factors that go into where and when the next Flock will be, I always value what our community has to say about this. I look forward to sharing the results of the Flock 2026 post-event survey and what the community has to say about the next edition of Flock to Fedora.

Virtual Experience Enhancements

The virtual/hybrid experience of Flock is a critical part of how we should be thinking ahead to Flock 2027. Since Flock restarted after the COVID-19 pandemic, we invested significantly more into our virtual, hybrid experience. It is unfortunate that this often ends up as being one of the most expensive costs of the entire event, even eclipsing spend on our financial assistance program and sponsored travel. Yet, it is critically important, both for people who cannot travel yet are key figures in the community, and for the long-term memory of the project contributors about what we are doing and focusing on now. There is also the benefit to the wider Linux and Open Source ecosystem to have visibility into what we are discussing and doing in Fedora from the live-stream and recorded sessions.

I am content with how we have piloted the use of Matrix to curate virtual engagement in live sessions at Flock. While it is surely not perfect, it is amazing to me to compare the digital infrastructure we have in 2026 to my first Flock in 2015. This is simply a level of engagement we could never have facilitated over IRC. I know we have a lot to improve on. But I am keen to think more about how we keep this part of the event planning as a critical, important part. The virtual experience was not important or financially possible for the first Flock edition in Charleston, South Carolina back in 2013. But in 2026, it is more important than ever.

I want to think more about how we can lean on Fedora’s First Foundation to show the rest of the Open Source ecosystem how to create the most inclusive, most engaging hybrid event experience there is. Perhaps we can lean on lessons from our virtual Fedora Release Parties we conduct twice a year.

Looking Ahead

Some of the things I am most proud of about Flock 2026 are our record-breaking attendance and sponsorship, and how the community continues to rally around this event. I eagerly anticipate reading the complete results of the Flock 2026 post-event survey and what people have to say, good and bad, about this year’s edition. The entire Flock organizing team puts in a lot of effort and time to build an event that represents the Fedora community. Since Flock is our annual flagship contributor event, this is a very important task!

The trajectory of Flock to Fedora is on the right path. There are still some friction points we need to improve, we need to start earlier on some things, and we need to leave room for the community to get involved. All that said, the signs I am watching are showing healthy growth. Now, we must not rest on our laurels, and sustain this momentum to deliver quality results for the entire Fedora community.

Bye-bye, Flock 2026. Here we come, Flock 2027!

Fedora Package Review Process reimagined

Posted by Jakub Kadlčík ( Fedora Account System Username

frostyx ) on 2026-07-07 00:00:00 UTC

The Fedora Package Review Process is clunky, archaic, and not on par with what we expect when contributing to Open Source projects in this century. We all know that, and we all want it to improve. That being said, we need to realize what is currently our main bottleneck. Even though the process is not friendly to new contributors, they are doing just fine - at all times, we have hundreds of new packages in the queue. Our biggest problem is our inability to effectively review them.

I don’t think we talk about this problem enough. That’s why it felt so validating to hear Miro Hrončok voice my exact thoughts during the Flock to Fedora 2026 keynote.

In this blog post, I am going to elaborate on the ideas that we (mostly Miro) came up with, shooting shit in the hallway after the session.

Proposing new packages through PRs

This is an obvious one, we talked about the same idea with Zbigniew Jędrzejewski-Szmek at Flock to Fedora 2025. It is a necessary prerequisite for any potential improvements, which will allow us to have a workflow that contributors are familiar with, inline code comments, CI/CD, and other things that are not possible in Bugzilla.

Proposing new packages through PRs would be trivial to implement if we had all Fedora packages in a monorepo. Which we don’t, and we probably don’t want to have. And even if we wanted to have, it would require massive changes throughout the ecosystem.

As a workaround, we discussed having an intermediate repository on the forge.fedoraproject.org into which we would only propose new packages. It would have Packit CI enabled, and therefore every proposed package would automatically get a scratch build and a test suite run on top of it. Currently supported tests are rpmlint, rpminspect, and license-validate. We know that adding new tests is easy, as I am currently working on support for fedora-review.

Of course, a final approval from a fellow package maintainer would still be needed. Once accepted, we would merge the PR and automatically create a new DistGit repository and import the package. Then we would delete all data from the intermediate repository to keep it clean.

Bulk review

The review queue is and always has been in hundreds. Many of the packages are dependencies for something else, and people have no motivation to review them separately. And even if they do, it’s not always easy to test them on their own. This currently leads to accepting broken packages that nobody tested or ignoring the tickets completely.

We discussed the possibility of proposing multiple packages within one PR. They could be reviewed, tested, and accepted all at once.

For such PRs, we could automatically create a new project in Copr and build the packages in the order they were committed. We could nicely use Copr’s build batches feature here. If multiple packages were added in one commit, they could be built in parallel. If the contributor decides to force-push into their PR, we would wipe the Copr project and start over.

Auto import into DistGit

There is no reason why the contributor would have to manually run

fedpkg request-repo my-package 12345
fedpkg request-branch --all-releases

fedpkg clone foo
cd foo
fedpkg import /path/to/the/foo.src.rpm
fedpkg push
fedpkg build

fedpkg switch-branch f44
git rebase rawhide
fedpkg push
fedpkg build
# ...
# repeat for f43, f42, etc

We can request all the DistGit repositories and branches for them. And once they are created, we can automatically import the packages. There are some open questions though. How can the contributor signalize what branches they want? Should we use the git history from the PR? Can we use Forgejo actions to trigger the requests and imports?

Proposal vs prototype

I realize this is not a formal proposal but merely a blog post on my personal website. That was an intentional decision. We’ve been discussing and bike-shedding this topic for years, and yet we don’t have much to show for it. I am writing this article mainly not to forget the ideas we’ve had, and even though I am interested in your thoughts, this is not an RFC. I already started implementing a prototype, and soon I’ll record a demo for you. Then, I’ll start bothering you and asking for feedback.

In my opinion, it doesn’t have to be perfect. We just need to kick this off, implement something small that works, and improve it as time goes.

Maybe I should also say that I am not aiming to replace the current Package Review Process. My goal is to provide an alternative version of this process and allow contributors to choose which one they want to follow. Then, someday in the future, if the alternative turns out to be popular, possibly deprecating the old review process.

I am not a tool

Posted by Miro Hrončok ( Fedora Account System Username

churchyard ) on 2026-07-07 00:00:00 UTC

I work at Red Hat in the Python Maintenance team mostly taking care of the Python ecosystem in Fedora. For the past year or so, I’ve been motivated by my employer to use agentic AI to deliver my work. Clearly, we are not the only ones.

At the beginning, I struggled to find reasonable use cases for this tool. I maintain software, which involves a lot more communication and coordination than actually writing code. When people ask me what I do, I often half-jokingly reply that I read and write a lot of emails. How can AI boost my productivity when I spend 80% of my time essentially talking to people? Where is the fun in replacing the remaining 20% of actually crafting code with more talking, this time to half-competent robots?

In time, I found ways to use AI that felt productive. And, ever so hypocritically, not only at work. But at what cost? I am supporting an industry that regularly harms open source projects such as Fedora, helps destroy the planet and uses stolen data. Moreover, I’ve become reliant on a proprietary tool. Is my AI-boosted contribution to Fedora worth it?

Despite my moral dilemma, I still love my job. I am a long-standing, well-known Fedora contributor, working for the most part on whatever I feel is needed, earning a competitive salary. In theory, I could go look for another job where I would not be motivated to do this, but I wouldn’t be able to keep doing the thing I love. I try to make the best out of this situation and, despite my initial distaste, use the tool to improve the project. So at the end of the day, I close my eyes and think of Fedora¹.

However, the implications of embracing AI are not just impacting me. The nature of my work means I’ve made hundreds (thousands?) of small open source contributions here and there. And sometimes, when I use AI to deliver those, it kinda feels like bringing a chunk of meat to a vegan BBQ. The people on the receiving end of my contribution for the most part don’t care about my job sustainability or IBM shareholders, nor should they.

Once, I used AI to contribute to a Fedora packaging project. It was reluctantly reviewed by another long-standing, well-known Fedora contributor (who happens not to be employed by Red Hat and is not well-compensated for this work). When talking to them, I realized that they were uncomfortable reviewing such a change. I made them uncomfortable by choosing to use AI for this. My employer made me uncomfortable; I passed it on to a volunteer. What an outstanding open source citizen.

I appreciate the irony of this; and yet, I am no slop generator. I understand what I submit and I put my name on it. I disclose the usage for transparency, because it matters. I don’t just drop a vibecoded patch on an open source project. If you have an AI policy, I read it and respect it. So it pains me deeply when our carefully considered contributions are outright branded AI slop or LLM hallucinations, and the person bringing them is evaluated solely on the basis of the tool they used. Especially when such judgment is made by people I respect².

No, I am not a tool. Please don’t treat me as such.

PS On a lighter note, here are some examples of AI usage that somehow eliminate this problem for me:

Debugging a problem — in our team we’ve been very successful in showing a failing test to Claude and telling it that it started failing with Python 3.15. While burning thousands of tokens and wasting gallons of drinking water it can usually successfully determine what caused the failure. We were able to determine this ourselves in the past, but this actually boosted our productivity. We can then report the problem to upstream after we have verified the find.
My own/my team’s semi-internal tooling —³ the omnipresent bunch of random scripts I am not proud of and which would desperately need a rewrite but ain’t nobody got time for that. Just slop ‘em. If it works, it works. If it doesn’t, roll-back. Nobody needs to see this code anyway. Excellent for AI — I am still kinda killing the planet but at least I don’t shove it in your face.
Reporting to management — somehow people keep asking me what I did. There’s no dilemma in providing AI-generated reports to the same people who asked me to use AI. If nothing else, it demonstrates how progressive I am with it.
Reviews for me — when I don’t use AI to generate code, but rather ask it to review my design and implementation, nobody is forced to deal with my AI usage. For example, I wrote this blogpost myself, then asked AI for feedback on typos, grammar, tone, voice, argument, rhetoric, structure, flow…⁴

And perhaps even more so, my mortgage and the food on my table. ↩
And precisely because of that I choose to not link those cases here. This is not about naming and shaming. ↩
This m-dash was copy-pasted from websearch results by a human. ↩
If nothing else, at least the model pretends it appreciates my sarcasm. ↩

Bots de Telegram: La consola de ChatOps definitiva para Sysadmins

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-07-06 21:15:00 UTC

Hoy te vengo a hablar de una herramienta que, para muchos, nomás sirve para mandar memes o jugar trivias en chats grupales. Pero la neta, si eres sysadmin o te late el desmadre del self-hosting y la administración de servidores, la API de Bots de Telegram es una mina de oro. Es, sin temor a equivocarme, la consola de ChatOps más barata y potente que te puedes echar a la bolsa.

Dejate de andar batallando con pasarelas de SMS de paga o configurando servidores de correo SMTP que de todos modos van a terminar en la carpeta de spam. Con un bot de Telegram tienes un canal de comunicación directo, encriptado y gratis para controlar tus fierros desde cualquier lugar.

Aquí te cuento las características clave y ejemplos bien prácticos para que los corras tú mismo:

Alertas automáticas en caso de fallos

Para notificaciones rápidas, no necesitas montar ninguna infraestructura compleja. Puedes crear un script de notificación para systemd que te avise de volada si algún servicio importante se cae.

Primero, creas el script que hace el envío:

# /usr/local/bin/systemd-telegram-notify.bash
#!/usr/bin/bash
set -euo pipefail
IFS=$'\n\t'

readonly BotToken="123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
readonly ChatId="987654321"

main() {
    local -r service_name="${1:-}"
    if [[ -z "$service_name" ]]; then
        printf "Usage: %s <service_name>\n" "${0##*/}" >&2
        return 1
    fi

    local message
    message=$(printf "❌ *Servicio Caído*\n*Host:* %s\n*Servicio:* \`%s\`\n*Hora:* %s" \
        "$(hostname)" \
        "$service_name" \
        "$(date '+%Y-%m-%d %H:%M:%S')")

    curl -s -X POST "https://api.telegram.org/bot${BotToken}/sendMessage" \
         -d "chat_id=${ChatId}" \
         -d "parse_mode=MarkdownV2" \
         -d "text=${message}"
}

main "$@"

Luego, creas un archivo de unidad de servicio genérico para systemd:

# /etc/systemd/system/telegram-notify@.service
[Unit]
Description=Enviar alerta de Telegram al fallar %I

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-telegram-notify.bash %i

Ahora, en cualquier servicio que quieras vigilar (como nginx.service), nomás agregas la directiva OnFailure=telegram-notify@%n.service en la sección [Unit]. Si el servicio truena, ¡te llega el pitazo al celular de inmediato!

Comandos de control y autenticación segura

Puedes programar tu bot para que escuche comandos y te regrese el estado del sistema. Lo mejor es que la API de Telegram hace la autenticación por ti. Cada mensaje entrante contiene el ID numérico verificado del usuario.

Aquí tienes un micro-daemon en Crystal, sin dependencias externas, que escucha comandos de diagnóstico de forma segura:

# /usr/local/bin/telegram-bot.cr
require "http/server"
require "json"
require "process"

ADMIN_ID = 987654321_i64
BOT_TOKEN = "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"

server = HTTP::Server.new do |context|
  if context.request.method == "POST" && context.request.path == "/webhook"
    if body = context.request.body
      payload = JSON.parse(body.gets_to_end)
      msg = payload["message"]?
      sender_id = msg.try(&.["from"]?.try(&.["id"]?.try(&.as_i64?)))
      text = msg.try(&.["text"]?.try(&.as_s?)) || ""

      if sender_id == ADMIN_ID && text.starts_with?("/status")
        # Ejecuta un comando rápido de diagnóstico
        stdout = IO::Memory.new
        Process.run("df", args: ["-h", "/"], output: stdout)
        disk_res = stdout.to_s

        reply = "Estado de discos:\n<pre>#{disk_res}</pre>"
        send_reply(msg.not_nil!["chat"]["id"].as_i64, reply)
      end
    end
  end

  context.response.content_type = "application/json"
  context.response.status = HTTP::Status::OK
  context.response.print({status: "ok"}.to_json)
end

def send_reply(chat_id : Int64, text : String)
  client = HTTP::Client.new(URI.parse("https://api.telegram.org"))
  payload = {
    chat_id: chat_id,
    text: text,
    parse_mode: "HTML"
  }.to_json

  client.post(
    "/bot#{BOT_TOKEN}/sendMessage",
    headers: HTTP::Headers{"Content-Type" => "application/json"},
    body: payload
  )
end

address = server.bind_tcp "0.0.0.0", 8443
puts "Escuchando en http://#{address}"
server.listen

Local Bot API Server: Control local sin límites

Esta característica es una joya para sysadmins. Si no quieres que tu tráfico de red salga a los servidores en la nube de Telegram, puedes correr tu propio Local Bot API Server.

Aquí tienes un archivo de servicio de systemd para tener tu pasarela local corriendo como servicio del sistema:

# /etc/systemd/system/telegram-bot-api.service
[Unit]
Description=Telegram Bot API Local Server
After=network.target

[Service]
Type=simple
User=telegram
ExecStart=/usr/local/bin/telegram-bot-api --local --api-id=tu_api_id --api-hash=tu_api_hash --dir=/var/lib/telegram-bot-api --working-dir=/var/lib/telegram-bot-api/temp
Restart=always

[Install]
WantedBy=multi-user.target

Una vez activado, nomás apuntas tus peticiones de curl o Crystal a http://localhost:8081/bot<token>/ y listo. Ya puedes subir respaldos de hasta 2GB directamente usando la ruta local (ej. file:///var/backups/dump.sql).

Mensajería enriquecida para reportes detallados

Con el motor de Rich Messages (Bot API 10.1), ya no estás limitado a bloques de texto plano feos. Puedes mandar reportes detallados usando plantillas HTML avanzadas que se renderizan de forma nativa en la app de Telegram.

Aquí tienes un ejemplo de cómo estructurar y mandar un reporte que contiene una tabla de estados y un bloque colapsable para logs de error:

# /usr/local/bin/send-report.cr
require "http/client"
require "json"

BOT_TOKEN = "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
CHAT_ID = "987654321"

# Plantilla HTML que entiende el motor Rich HTML de Telegram
rich_html = <<-HTML
<h1>Reporte del Servidor srv01</h1>
<hr/>
<p>Estado de los servicios críticos de la infraestructura:</p>
<table bordered striped>
  <tr><th>Servicio</th><th>Estado</th></tr>
  <tr><td>Nginx Webserver</td><td>🟢 Activo</td></tr>
  <tr><td>MariaDB Cluster</td><td>🟢 Activo</td></tr>
  <tr><td>Podman Daemon</td><td>🔴 Inactivo</td></tr>
</table>
<br/>
<details>
  <summary>Ver logs de error de Nginx</summary>
  <pre>2026/07/06 15:30:12 [error] 1234#0: *5 open() "/var/www/html/favicon.ico" failed</pre>
</details>
HTML

payload = {
  chat_id: CHAT_ID,
  rich_message: {
    html: rich_html
  }
}

response = HTTP::Client.post(
  "https://api.telegram.org/bot#{BOT_TOKEN}/sendRichMessage",
  headers: HTTP::Headers{"Content-Type" => "application/json"},
  body: payload.to_json
)

puts "Respuesta: #{response.status_code} - #{response.body}"

Tip

Usa el método sendRichMessageDraft para streamear salidas de terminal largas o procesos lentos en tiempo real con la etiqueta animada <tg-thinking>. ¡Parece magia!

Conclusión

A final de cuentas, los bots de Telegram dejaron de ser solo una herramienta recreativa para convertirse en una interfaz de control de sistemas sumamente flexible. La neta, integrarlos en tus scripts de administración te ahorra un montón de desveladas y te da el control de tu infraestructura en la palma de tu mano.

¿Y tú, ya usas Telegram para monitorear tus servidores o sigues dependiendo del correo?

Referencias

From June 29 to July 05

Posted by Aurélien Bompard ( Fedora Account System Username

abompard ) on 2026-07-06 06:59:00 UTC

Across the various Fedora working groups, the primary focus is actively preparing for the upcoming Fedora 45 release cycle, marked by a large influx of system-wide Change Proposals such as GNU Toolchain updates, Fontconfig 2.18, and the transition to oo7 as the default secrets provider. Concurrently, a major infrastructure modernization effort is underway, with multiple teams—including Infrastructure, Release Engineering, and Docs—coordinating the final stages of the repository migration from Pagure to Forgejo, alongside the adoption of Konflux for unified container builds and Zabbix for system monitoring. On the governance front, leadership has indefinitely paused the Community Initiatives process to design a new Technology Innovation Lifecycle (Sandbox) for incubating large, experimental features. Despite the resulting closure of the AI Developer Desktop proposal, artificial intelligence remains a strong technical focus across the project, with groups exploring local LLM integrations like the "Anthony" voice assistant and expanding AI/ML framework packaging. Finally, security and compliance are key priorities, as teams ramp up policy preparations for the EU Cyber Resilience Act (CRA) and push necessary incompatible package updates to mitigate high-severity vulnerabilities.

Announcements

The Fedora Council has paused the Community Initiatives process, closing the AI Developer Desktop proposal until a new strategic direction mechanism is designed, and is actively seeking community feedback on a proposed Technology Innovation Lifecycle Process (this statement was also cross-posted to the announce and devel-announce lists). In community news, the F44 Election Results have been announced for the Council, FESCo, Mindshare, and EPEL Steering Committee. Additionally, maintainers are urged to review the list of long-term FTBFS (Fails To Build From Source) packages scheduled for retirement in early August ahead of the Fedora 45 branch so they can be fixed or exempted.

A large batch of Change Proposals has been submitted for Fedora 45. System and security updates include enabling Shadow Stack by default on x86_64, switching to oo7 as the default Secrets Service Provider to replace KWallet and GNOME Keyring, and disabling DNF5 vendor changes by default to prevent unexpected package overwrites in multi-vendor setups. Core software updates feature a GNU Toolchain update (GCC 16.2, glibc 2.44, binutils 2.47, GDB 17.2), Ruby on Rails 8.1, and Fontconfig 2.18. Finally, user experience improvements are proposed with Stratis Storage support in Anaconda and a highly customizable Bash Color Prompt 1.0.

Council

The Council made a significant shift in project governance this week by suspending the Community Initiatives process indefinitely. As a result, the Fedora AI Developer Desktop Initiative proposal was closed, though contributors are strongly encouraged to continue this work through collaborative spaces like the AI/ML SIG. Leadership is now directing community feedback toward the proposed Fedora Innovation Lifecycle (Sandbox) to establish a better framework for incubating large, experimental features. In other news relevant to the broader Linux ecosystem, the Council officially approved extending the "Fedora Atomic" branding to encompass Fedora's bootable container base images.

To improve contributor engagement and clarity, a new community policy document was merged to help manage user expectations around volunteer response times. The Council also finalized the F44 Council election interview questions, shifting the focus toward candidates' strategic visions and governance experience. Furthermore, new discussions are underway regarding improvements to Fedora's public-facing presence to better attract new contributors, alongside a forum thread clarifying trademark guidelines for regional community sites migrating their infrastructure.

Learn more about the Council team.

FESCo

This week, FESCo reviewed a large batch of Fedora 45 Change Proposals, including updates to the GNU Toolchain, LLVM 23, Ruby on Rails 8.1, Fontconfig 2.18, Bash Color Prompt 1.0, and libxml2. Major system-wide feature discussions included enabling Shadow Stack by default on x86_64, disabling DNF5 vendor change by default, switching the default secrets service provider to oo7, and adding Stratis storage support in Anaconda. The committee also debated policy and infrastructure topics, such as the upcoming Forgejo distgit migration, handling pre-built binary content in node_modules, and whether to drop signoff requirements from the defunct Fedora crypto team to unblock modern cryptography libraries like aws-lc.

In terms of contributor engagement and process, FESCo is looking for volunteers to co-own an upcoming Change Proposal to make 2FA mandatory for all packagers. During their weekly meeting, members clarified that the proposed "technology innovation lifecycle" (sandbox) process is not intended to bypass FESCo approval. Finally, the non-responsive maintainer process was initiated for the ledger package, opening the door for new co-maintainers to take over.

Decisions

Council Representative: It was agreed that decathorpe will continue as FESCo's Council representative until the end of his current term.
ELN Draft Builds: FESCo approved permitting the ELNBuildSync (EBS) service to use draft builds in Koji sidetags inherited from eln-build for ELN rebuild batches. The Kojihub policy will be updated to grant the eln-buildsync user permissions to tag and promote these draft builds.

Learn more about the FESCo team.

Mindshare

This week, the Mindshare group discussed using Fedora trademarks with 3rd party projects. A representative from the Polish Fedora community, which has been active since 2003, sought guidance on compliance regarding their fedora.pl domain, automated emails, logos, and favicons after losing their infrastructure sponsor. Respondents directed the inquiry to the official Fedora trademark guidelines, highlighting that the community's usage likely falls under the allowable provisions for "Community Sites and Accounts."

Learn more about the Mindshare team.

Workstation / GNOME

The Fedora Workstation Working Group discussed "Anthony," a voice-driven desktop assistant utilizing local large language models (LLMs) for task automation and accessibility. The team explored hardware constraints, security improvements—such as transitioning from TCP ports to D-Bus portals for flatpak sandboxing—and leveraging existing accessibility trees. Contributors are encouraged to test the project and help with internationalization efforts by aligning it with IBus speech-to-text initiatives. Additionally, the upcoming Fontconfig 2.18 release was noted, which may require a rebuild of all font packages due to cache format changes.

On the forums, a community proposal to merge GNOME Software and DNFdragora into a single, unified package manager for all Fedora editions was met with skepticism. Respondents highlighted that GNOME Software must remain distro-agnostic, the merger would not suit environments like KDE Plasma, and maintaining a strict separation between GUI application management and CLI package management remains the preferred, less confusing approach for users.

Decisions

The group decided to explore integrating the Anthony voice control project into Fedora Workstation as a default feature.
A dedicated meeting will be organized to discuss collaboration between the Anthony project and general IBus speech-to-text efforts.
The regular meeting schedule will be paused for the month of July to accommodate summer travel and the GUADEC conference, with plans to reconvene in August.

Learn more about the Workstation / GNOME team.

Server

The Server Working Group met on July 1, 2026 to coordinate early testing for the upcoming Fedora 45 release and to advance the new Fedora Home Server spin-off. To proactively catch virtual machine and networking issues, the team is starting F45 Rawhide testing ahead of schedule, with an immediate focus on VM images and NFS client connections. A dedicated project board will soon be established to organize these F45 testing efforts, providing a clear and accessible way for community contributors to get involved.

Significant progress was also made on the Fedora Home Server spin-off. The group finalized the core application stack for the upcoming alpha release, prioritizing essential home lab services, privacy, and self-hosted management. Furthermore, the team discussed the image development process, comparing KIWI and Image Builder. To lower the barrier to entry for new contributors, they opted for a local-first development philosophy, ensuring anyone can build and test the spin-off images on their own machines.

Decisions

The alpha version of the Fedora Home Server spin-off will initially include Samba, NFS, Mail service (IMAP/POP3 storage), Cockpit, Calendar and to-do server, Apache reverse proxy, and Ansible.
The working group will use the home server repository to share all configuration data and installation instructions, allowing interested contributors to easily set up their own local image development environments.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team focused heavily on monitoring modernization, officially removing Nagios and Collectd in favor of Zabbix, while actively refining Zabbix triggers, predictive disk space checks, and SLA structures. Significant progress was also made on OpenShift migrations, including standardizing openshift-apps playbooks to use a new deployment role and migrating ELNBuildSync. Routine maintenance continued with careful RHEL 10 virthost reinstalls to avoid outages, and testing Forgejo 15.0.3 in staging. The team also resolved several minor service disruptions, including a Postorius 500 error caused by missing email bodies and Anubis proxy lockouts.

In the forums, a helpful discussion clarified the roles of Bugzilla, Forgejo, and Dist-Git for users confused by the ongoing transition away from Pagure. Contributors also explored the possibility of shared LLM inference services for community applications like Log Detective, and proposed restoring pre-commit hooks in the infra/ansible repository to gradually improve code quality. For contributors looking to get involved, the ongoing Zabbix template refinements and Ansible playbook conversions offer excellent, low-risk entry points into infrastructure work.

Decisions

Nagios and Collectd are officially deprecated and are being removed from Ansible and servers.
Pagure.io will become read-only at the end of July, with Fedora-related projects migrating to the new Forgejo instance (forge.fedoraproject.org).
Old openQA Proof-of-Concept instances running in AWS will be deleted to save resources.

Learn more about the Infrastructure team.

Release Engineering

The Fedora 45 release cycle is officially ramping up, with the Mass Rebuild scheduled for July 15th and the creation of F47 release signing keys due shortly after. The Release Engineering team is currently reviewing several F45 system-wide changes, including Stratis Storage in Anaconda, Fontconfig 2.18, and disabling DNF vendor changes by default. In broader news, investigations into building a Fedora container base image using Konflux are ongoing, and an updated respin of Fedora 44 featuring Linux kernel 7.1 is planned for the coming weeks.

Infrastructure migrations from Pagure to Forgejo are continuing, prompting active architectural discussions on whether to process fedora-scm-requests using native Forgejo Actions or by extending the existing Toddlers infrastructure. During their weekly meeting, the team also clarified procedures for stalled EPEL requests and coordinated prep work for the upcoming mass rebuild. Furthermore, a significant pipeline improvement was unblocked when FESCo approved a policy to allow draft builds for ELN, which will allow the ELNBuildSync process to safely restart after crashes without prematurely consuming NVRs.

Decisions

FESCo approved a policy permitting the ELNBuildSync service to use draft builds in Koji sidetags inherited from eln-build for ELN rebuild batches (Ticket #13374).
The team clarified that users requesting to take over stalled EPEL packages must already be official package maintainers (in the FAS packager group) before they can be added as repository collaborators (Meeting).

Learn more about the Release Engineering team.

Quality

The Quality team saw active discussions and tool developments this week, highlighted by a community proposal to eliminate Fedora's version numbering in favor of automatic, version-less updates. The community largely pushed back on the idea, noting that the current release model is necessary for users who prefer to delay updates for stability, and that rolling-release alternatives already exist. In broader ecosystem news, a new GTK4 frontend for DNF5 called DNF UI has reached its 0.3.x series and is actively seeking user feedback. Behind the scenes, Quality Engineering (QE) advanced their compose-critical package script to an MVP state, progressed on the Dist-git PR test feature, and investigated significant bugs, including a grub2 issue breaking image builds and a haveged update causing boot failures.

There are several immediate opportunities for contributors to get involved in testing. The team is calling for participation in the Linux Kernel 7.1 Test Days (running June 28 to July 4) for Fedora 43 and 44, which was also announced on the test mailing list. Additionally, testers are invited to validate the latest Fedora 45 Rawhide 20260630.n.0 nightly compose to help ensure the stability of upcoming releases.

Learn more about the Quality team.

Design

The Design team is finalizing the F45 default wallpaper following the end of its feedback period, and is actively working on several branding initiatives, including simplified icons for Fedora Messaging tools, Artemis, and various Matrix bot avatars. Infrastructure and asset management were also key topics, with discussions on migrating the fedora-logos package from pagure.io and whether to archive old Community Blog and Fedora Magazine image repositories. Additionally, preparations are underway to automate Flock 2026 YouTube thumbnails using Inkscape extensions and schedule data.

A major focus this week is the development of a Contributor Onboarding Video Series to help newcomers navigate Fedora's systems. To make these videos more authentic, the team has launched an open call for horizontal video footage from past Fedora events to replace stock assets. Contributors are also invited to help design Community Personas that visually represent different types of Fedora participants, offering a highly creative way to get involved.

Decisions

Community Event Footage: The team aligned to solicit horizontal video footage from Fedora events via an open call on Fedora Discussions to replace stock assets and enhance future video content.
Icon Design Refinement: The Datagrepper interface icon will be simplified, moving away from complex line art to utilize color blocks and shading for improved visual clarity at smaller sizes.

Learn more about the Design team.

Docs

The Fedora Docs team is actively modernizing its infrastructure and continuous integration pipelines. A major focus is refactoring the local preview script (docsbuilder.sh) and exploring a shared Forgejo Actions workflow that utilizes a pre-built container image to enable fast, cross-referenced CI builds for individual pull requests. To address security issues in outdated containers, the team plans to transition container builds to Konflux and Quay.io, aligning with broader Fedora infrastructure practices. Additionally, the team is finalizing its migration to Forgejo ahead of the July 31 Pagure.io sunset, investigating monitoring solutions for staging build failures, and evaluating tools like CryptPad for collaborative draft writing.

To better distribute documentation maintenance and empower subject matter experts, the team launched a "Fedora Docs Captain" pilot program to embed documentation liaisons within specific groups, starting with the Kernel, Multimedia, and AI/ML SIGs. There are immediate opportunities for contributors to help refactor multiple contribution guides—including those for Quick Docs and new modules—to emphasize the modern local authoring workflow. The team is also working to unblock and refine the documentation translation processes alongside the localization team.

Decisions

Repository PR and Forking Guidelines: During the June 30 meeting, the team agreed that pull requests should normally be submitted via a fork, particularly for changes requiring lengthy discussion and refinement. However, organization owners and content owners who maintain an article on an ongoing basis may submit pull requests from upstream branches or push directly. Repository settings will be adjusted to enforce branch protections, ensuring only owners can push to main and requiring at least one review approval before merging.

Learn more about the Docs team.

Internationalization

In a recent discussion, returning contributor Javier Blanco inquired about the current activity levels on the translation mailing lists. The community welcomed him back and clarified that the mailing lists are currently quiet because the majority of localization work is now handled upstream, with contributors often utilizing alternative communication channels such as Matrix and forums.

To provide deeper context on the state of the localization community, Jean-Baptiste shared two presentations detailing the structural health and tooling of open-source translation efforts. These included an analysis of language community health using 20 years of Fedora translation data and a proposal for new tools to improve translator efficiency. Contributors interested in improving localization workflows and community collaboration are encouraged to review these resources.

Learn more about the Internationalization team.

EPEL

This week, the EPEL team focused heavily on addressing security vulnerabilities through necessary incompatible updates and package retirements. Notably, caddy was updated across multiple branches to resolve 22 CVEs, and an incompatible update for routinator was proposed to address several high-severity vulnerabilities. Contributors are also discussing a proposal to drop the rust-rpki binary subpackage to simplify package maintenance. Furthermore, early planning discussions for EPEL 11 have begun, with current conversations centering around the challenges of maintainer ownership and content resolver workflows.

Decisions

The steering committee approved an incompatible update for syncthing to v2 in EPEL 10.3 and 10.2. Because of outdated SQLite and Golang dependencies in older RHEL releases, syncthing will be retired in EPEL 8 and 9 around July 14 to mitigate unresolvable CVEs.
The committee confirmed the rollout of the incompatible update replacing p7zip with 7zip in EPEL 9, which has been pushed to testing without automatic karma or time-based pushes to ensure adequate community feedback.

Learn more about the EPEL team.

ELN

The ELN SIG meeting on June 30, 2026, was brief due to low attendance and participants being occupied with other tasks, such as debugging EBS with Fedora Infrastructure. Consequently, no major subjects were discussed, and no formal decisions were made during this session.

For those looking to engage with the group, contributors are encouraged to bring topics for discussion to the next scheduled meeting, which will take place on Tuesday, July 7, 2026, at 12:00 EDT.

Learn more about the ELN team.

Atomic

The Fedora Atomic Initiative discussed a draft Change Proposal to unify all atomic and bootc variant pipelines into a single monorepo using Konflux. This consolidation aims to streamline infrastructure across teams by establishing a shared atomic tenant for bootc base images, Atomic Desktops, and potentially Fedora CoreOS. To manage the scope and avoid disrupting existing workflows, the migration will be iterative. The immediate focus is moving bootc images to the new forge to verify builds, which will be followed by dedicated change requests for official artifact signing and the broader pipeline unification.

In community discussions, interest continues to build around the proposal to create a systemd-sysexts SIG. This initiative presents a great opportunity for contributors to help design the official building, distribution, and documentation of systemd system-extensions, which are crucial for extending atomic systems with software that doesn't run well in containers or Flatpaks.

Decisions

The team agreed to pursue a unified atomic Konflux tenant and monorepo to house current bootc base images, Atomic Desktops, and potentially future variants.
The pipeline unification will be broken down into smaller, sequential change requests, starting with migrating bootc images to the new forge and establishing artifact signing before fully transitioning other variants.

Learn more about the Atomic team.

CoreOS

In the CoreOS meeting, the team reviewed upcoming Fedora 45 changes, noting that a GoLang update and an RPM 6.1 version bump will require dedicated tracking issues and investigation, while the adoption of PURL metadata is not expected to affect Fedora CoreOS. Contributors interested in packaging can engage with the ongoing work to support passing Butane configs directly to instances, which prompted a restructuring of how Ignition and Butane are maintained. For the broader Linux community, Podman 6.0 has officially landed in Rawhide and is ready for testing. Additionally, the forum proposal to create a systemd-sysexts Special Interest Group (SIG) continues to gather support from developers interested in building and distributing systemd system-extensions.

Decisions

The team agreed to combine the Ignition and Butane spec files, making Butane a subpackage of Ignition and archiving the standalone Butane spec.

Learn more about the CoreOS team.

AI & ML

During their July 2nd meeting, the AI & ML SIG discussed upcoming packaging and testing plans, noting that the ollama 0.30.x update will likely be delayed until Fedora 46 due to upstream instability with llama-cpp. The group is actively seeking testing and packaging help to diversify supported llama-cpp backends, particularly for the upcoming Vulkan transition. In broader community news, there is an active proposal to evolve the SIG into the "Fedora AI Working Group" to better reflect its expanding scope in both hardware enablement and open AI best practices. Additionally, there is a large backlog of open tickets for packaging major AI frameworks and tools—including TensorFlow, Bazel, and various Python libraries—alongside early discussions about proposing a dedicated Fedora AI Spin and building hardware-enabled inferencing images.

To boost contributor engagement, the SIG is revamping its documentation to create a more welcoming onboarding experience and is forming a new "Skills Reviewers" sub-team to curate shared AI skills using the Agent Skills specification. The group also addressed the management of donated AMD GPU nodes (like gpu01), emphasizing the need for public documentation to clarify hardware allocation and CI usage. This initiative aims to ease bureaucratic friction, provide transparency on how community hardware is utilized, and make it easier for contributors to understand how they can leverage these resources.

Decisions

@jflory7 will open a ticket to propose a new "Hardware" module for the documentation site to track and manage hardware donated for Fedora Infrastructure.
@jflory7 will chair the next SIG meeting on July 16, 2026.

Learn more about the AI & ML team.

RISC-V

The RISC-V group focused heavily on expanding infrastructure and hardware support this week. Discussions are underway with the cloud vendor Scaleway to host potential Fedora Koji builders in their Paris datacenter, an effort being coordinated through RISE. Hardware availability for developers is also improving: the newly released Milk-V Titan boards are currently shipping to RISC-V engineers for Fedora use, which will further aid platform optimization and broader Linux ecosystem integration.

On the software front, active development continues on the Fedora Omni kernel to expand support for devices like the Muse Pi Pro and K3, while steady progress is being made on the Fedora RISC-V tracker. To avoid disruptive surprises, contributors should note ongoing 'fedora-devel' discussions regarding potential improvements to the Changes Process, as well as internal deliberations about implementing two-factor authentication (2FA) for packagers.

Decisions

It was decided to provision an additional "K3" hardware unit (sponsored by CLE) to maintainer DavidA to serve as a new Fedora RISC-V Koji builder.

Learn more about the RISC-V team.

Security

The Security SIG held a meeting this week to welcome new members from Red Hat's Product Security and Open Source Office. The expanded team will focus on navigating the upcoming EU Cyber Resilience Act (CRA) and implementing practical, developer-centric security measures. The group also initiated a debate on the scope of the Security Docs repository, specifically whether it should consolidate all Fedora security topics or strictly house documentation actively maintained by the SIG to prevent stale content. This documentation discussion will continue in upcoming meetings.

For contributors looking to get involved, the SIG noted that help is needed with defining security policies, which are obligatory for the CRA Steward role. Community members can follow the published meeting agendas to see when topics of interest are being discussed or drop into open office hours to participate.

Decisions

Agendas for upcoming meetings will be published in advance. If there are no agenda items, the scheduled time will serve as informal open-floor office hours.
Formal decisions within the SIG now require a quorum of at least three member votes.

Learn more about the Security team.

Go

During the Go SIG meeting, members discussed the upcoming Go release and shared that a mass prebuild of Go 1.27rc1 has been completed; contributors are encouraged to review the prebuild results report to catch any potential regressions. The team also highlighted ongoing work on a new Go utility designed to test Kubernetes installations locally on VMs, which will help validate new Fedora Kubernetes releases (like 1.36) before deployment. Furthermore, participants praised Fedora's current approach to vendored Go packages, noting it provides a smoother packaging experience compared to other ecosystems.

In terms of packaging standards, the SIG reviewed Issue #67 regarding CGO_CFLAGS. A contributor proposed establishing default values for these flags that are consistent with Fedora's standard build practices, as some packages currently require manual configuration to build correctly. The team will investigate past configurations and work toward defining sensible defaults that packagers can easily override if necessary.

Learn more about the Go team.

Perl

This week's activity in the Perl group centered around package maintenance and compatibility pull requests. Notably, a pull request for perl-Module-Starter-Plugin-CGIApp was submitted to fix compatibility with Module::Starter 1.80+ author arrayrefs. Additionally, contributors opened PRs to prevent building Class::Storage::Debug in bootstrap mode for perl-SQL-Abstract and to utilize -any virtual provides for MariaDB/MySQL dependencies within perl-Test-mysqld.

Decisions

The maintainer for perl-Module-Starter-Plugin-CGIApp decided against adopting the %autorelease and %autochangelog macros, requesting their removal from the pending compatibility pull request.

Learn more about the Perl team.

Rust

Michel Lind submitted a Request for Comments (RFC) to drop the rpki binary subpackage from the rust-rpki crate. These unneeded programs were accidentally shipped due to a bug in older versions of cargo2rpm (< 0.3.0) and unnecessarily complicate package maintenance by requiring frequent license audits for statically-linked dependencies.

Since the crate is currently only used by routinator, Lind proposed retiring the binary packages to simplify ongoing maintenance. As this counts as a package retirement, Lind is seeking clearance on the EPEL side and noted that the removal could be gated to only affect Fedora 45 and newer if required.

Learn more about the Rust team.

Other Discussions

Future of the Fedora i3 Spin in Fedora Linux 45 (cross-posted to the devel and i3wm mailing lists): Justin Wheeler called for new maintainers to keep the i3 Spin alive for F45, noting light maintenance recently. Dan Čermák and Eduard Lucena stepped up to continue packaging and comps/bug tracking respectively, ensuring the Spin will continue to be produced.
Hummingbird Community Meeting Notes - 25 June 2026: Laura Santamaria shared notes from the Hummingbird community meeting, discussing community growth, DevConfCZ recaps, AI integration with a "human-in-the-loop" approach, image requests, and LTS strategy. Adam Miller and Jorge Castro further discussed the potential of integrating AI agents natively into the OS via an OpenClaw experience.
Some news about the Audinux activity for June: Yann Collette shared updates on the Audinux repository, highlighting the return of kernel-rt builds and listing 21 new packages (mostly audio plugins and tools) and 140 package updates added in June 2026.
How can we improve the Changes Process?: Maxwell G proposed modernizing the Fedora Changes Process by moving away from the Wiki and wikitext to a Git-based repository using Markdown and structured metadata (like YAML/TOML frontmatter). The discussion highlighted frustrations with the current fractured discussions across mailing lists and Discourse, and the burden on the Change Wrangler, though some raised concerns about the maintenance of custom web apps versus using existing forges.
F45 Change Proposal: Grub EFI For Confidential Computing (self-contained): Aoife Moloney announced a proposal to create an independent, minimal GRUB package for UEFI to boot Unified Kernel Images (UKIs) for Confidential Computing. The thread discussed the trade-offs of using an intermediate "bootstrap" kernel versus a minimal GRUB, with Lennart Poettering noting that Windows has proven PCR prediction viable for broad audiences and Linux is getting closer to that goal.
How can I contact the crypto team?: Gordon Messmer inquired about adding AWS's s2n-tls and aws-lc to Fedora, noting modern crypto libraries are moving away from runtime configuration. Simo Sorce and others debated the risks of relying on corporate-owned libraries like aws-lc that don't integrate well with distribution policies, while acknowledging that upstreams like rustls are increasingly defaulting to them over OpenSSL.
binary content in node_modules: Gordon Messmer asked about handling pre-built binaries and WebAssembly files bundled inside node_modules during Node.js package reviews. He suggested using a tool like npm2rpm to avoid bundling modules with native binaries, requiring them to be installed as system modules instead.
Distribution conditionals in spec files: Florian Weimer proposed updating the Packaging Guidelines to explicitly permit macros like %fedora, %rhel, %centos, %epel, and %hummingbird. The discussion revealed a divide between maintainers who prefer a single spec file across multiple distributions (like LLVM) and those who find the resulting "macro jungle" harder to read and maintain.
F45 Change Proposal: oo7 Secrets Service Provider (system-wide): Aoife Moloney shared a proposal to switch the default Secrets Service provider from KWallet and GNOME Keyring to oo7. Bilal Elmoussaoui (oo7 author) clarified that it automatically migrates existing keyrings and supports multiple keyrings, addressing concerns about compatibility and maintenance of the older daemons.
Inactive packager script notifications from fork (and a related thread): Several active packagers received false-positive inactivity notifications. Jef Spaleta apologized, explaining that while testing the script's transition to the Forgejo API on a personal fork, the @username mentions in the ticket templates accidentally triggered live notifications.
Other discussions included a call for a zig co-maintainer, a proposal to Disable Vendor Change by Default, the Council Bi-Weekly Meeting Agenda, packaging the JS Trix editor, a list of New packages in Fedora Linux, multiple review swaps requests across the lists, FCOS release related issues on ppc64le, the archiving of fedora-lorax-templates, dropping rust-rpki's rpki binary subpackage, the Council Statement on the Future of Community Initiatives (and duplicate), the expiration of the MPEG-4 Visual final patent, a proposal for Stratis Storage in Anaconda, a proposal for Bash Color Prompt 1.0, an invitation to the Java SIG Matrix room, and an issue with s390x cloud images hanging.

Orphaning packages

List of long term FTBFS packages to be retired in August: Miro Hrončok posted the first reminder for packages failing to build from source since F42, which will be retired before F45 branching.
Orphaned package wavemon updated to 0.9.7: Viktor Erdelyi provided a COPR build for the orphaned wavemon package, and Iñaki Ucar successfully unretired and updated it in Fedora.
Question about the orphaned "fx" package: Emanuele Petriglia asked about the controversy that led to fx being orphaned and subsequently submitted a Bugzilla review ticket to package its new Go-based rewrite.
Orphaned packages looking for new maintainers: An automated report listed packages that will be retired in six weeks unless adopted by a new maintainer.

Package updates

[rawhide] fmt and spdlog upgrade/soname bump: Frantisek Zatloukal announced rebuilds for packages depending on fmt-12.1.0 and spdlog-1.17.0 in a side tag.
[heads-up] libcamel soname version bump in evolution-data-server 3.61.1: Milan Crha completed the soname bump and side tag merge for evolution-data-server.
[heads-up] updating onnx to 1.21.0 & onnxruntime to 1.26.0 in rawhide: Diego Herrera announced an upcoming soname and protobuf version bump for onnx and onnxruntime.
RFC: incompatible update for routinator for Fedora and EPEL 9 and 10: Michel Lind announced an incompatible update to routinator 0.15.2 to fix multiple high-severity CVEs, including a path traversal vulnerability.
Highfive 3.3.0 coming to rawhide: Ankur Sinha successfully updated highfive to 3.3.0.
GNOME 51.alpha update: Milan Crha created a side tag for the GNOME 51.alpha update and invited other maintainers to include their related updates.
xmlsec 1.3 update: Tomas Halman announced that the xmlsec 1.3 update has landed in Rawhide.
Upgrade to sundials 7.8.0: Antonio Trande announced an upcoming upgrade to Sundials 7.8.0 in Rawhide.
F45 Change Proposal: Ruby on Rails 8.1 (self-contained): Aoife Moloney forwarded a proposal by Vít Ondruch to update the Ruby on Rails stack to 8.1.
F45 Change Proposal: GNU Toolchain Update (system-wide): Aoife Moloney forwarded Carlos O'Donell's proposal to update the GNU Toolchain to gcc 16.2, binutils 2.47, glibc 2.44, and gdb 17.2.
F45 Change Proposal: Fontconfig 2.18 (system-wide): Aoife Moloney forwarded Akira TAGOH's proposal to update fontconfig to 2.18.

New contributor introductions

Self Introduction: Simone: Simone (tollsimy), a computer engineer with a background in electronics, embedded systems, and cloud infrastructure, introduced themselves and expressed a desire to give back to the Fedora community.

Arriving At Flock To Fedora 2026

Posted by Akashdeep Dhar ( Fedora Account System Username

t0xic0der ) on 2026-07-05 18:30:48 UTC

My onwards journey began at around 0600pm Indian Standard Time on 12th June 2026 when I departed for the Netaji Subhash Chandra Bose International Airport (CCU) in Kolkata. After my longstanding troubles with the travel agency, I was able to rebook the previously cancelled connecting flight from Dubai (DXB) to Prague (PRG). When I thought that I was finally out of the woods, my backpack was weighed at the Emirates desk for the first time. While my check-in luggage was well under the weight limit of 25 kilograms, my backpack ended up weighing a little more than 7 kilograms. Upon my declining to move my electronics into the check-in luggage, as that would have ended up being a safety hazard, I was finally able to make it to the immigration gates at around 0700pm Indian Standard Time.

Although the Fast Track Immigration Trusted Travellers' Programme would have helped me cut through the moderately occupied passenger queue, I decided to join the manual queue anyway as the digital kiosk wanted me to have my biometric entries registered in advance. Imagine having to verify your identity after doing so multiple times with the passport verification and visa registration! After a quick discussion about the requirements with the immigration staff, I was able to breeze through the security checks quite swiftly. With the first leg of my onwards journey, Emirates EK0573, departing at around 0900pm Indian Standard Time, I had about an hour before boarding began. To my surprise, it did start early at around 0750pm Indian Standard Time after I was done chatting with my family members.

Given that I had a dreadfully arduous eight-hour layover period ahead of me at Dubai International Airport (DXB), I initially planned on catching some sleep on the flight itself. Amidst munching on the served dinner and watching Oshi No Ko (2023), I had limited success with resting my eyes as the onwards flight moved closer to the first stop. As there was no hurry to make it to the next flight, I went for one of the twin seats at the very end of the aircraft, 50K. Chatting with my fellow passenger and dozing off right after, I did not realize how quickly the five hours passed, and I found myself landing at Dubai International Airport (DXB) at around 12:00am Gulf Standard Time. Unfortunately, my first flight did not land directly at the terminal gates and, hence, we had to board the transit bus instead.

It took around 30 to 40 minutes for the buses to get us to Terminal 3, and after a rather uneventful security check, I was back indoors. The time it took to get to the terminal gates helped me realize just how massive the area was - or conversely, just how slowly our transit bus was moving. I did not have any complaints as I had nothing to do for the eight-hour-long wait before my second leg kicked off. While I initially planned on getting myself a sleeping pod, I eventually decided to find myself a reclining area to sleep in near the silent area of Gate B26. After building rudimentary security for my travelling backpack so that I would get tugged awake in the rare occurrence of someone attempting to pull it away from me, I decided to try catching up on some sleep. Of course, you know just how it must have gone...

Those eight hours felt like eternity as I kept zoning in and out of my sleep state while the night grew darker and colder with the passing of time. In retrospect, I should have carried some warm clothing, which I ended up skipping this time because the summer season had me confused. But it felt a whole lot safer amidst a bunch of travellers struggling to catch some sleep, rather than being somewhere alone. The moment I was just about to catch some shut eye, I was nudged awake by a helpful person who thought I was waiting for the flight to Delhi departing at around 0355am Gulf Standard Time. While they apologized after I told them about my situation, I thanked them for their well-intentioned, caring gesture towards ensuring that their (potentially possible) fellow passenger was not left behind.

After about an hour of trying to sleep again, I eventually gave up on my attempts at around 0630am Gulf Standard Time and instead decided to browse the Dubai Duty Free Stores. As my flight was departing from Gate B31, that would mean that I could also slowly start moving towards the departure gate too. I also wanted to get something for my family and friends from there because I would be unable to do so on my way back with a layover of just 90 minutes. Using the public WiFi at the international airport behind a secure VPN allowed me to connect with my brother over a WhatsApp call. After making a couple of purchases for the house warming, I finally made it to the departure gate, where I could simply get to the second flight without queuing as the boarding had already begun by that time.

This time around too, I had to board a transit bus that took us from the terminal gates to Emirates EK0139, and even that took long. That explained to me why the boarding had begun sooner, as they had to compensate for the travelling time to the actual flight as well. Seated at 44K, I had a small talk with a fellow traveller from the Philippines while I tried to plug my work laptop into the power outlets. I also noticed a lot of travellers from East Asia flying into Prague, which was mostly an interesting observation to make. After multiple failed attempts at getting some power to my work laptop—even after using the plug converters offered by the flight stewardesses—I eventually had to stow it into my travelling backpack. That meant that I had to discover other ways to keep myself occupied for the next seven hours!

I knew that sleep had become quite the exorbitant affair at that point, and while I clearly needed some, there was no way in which I could have gotten it given just how the timezone shift had affected my internal biology. I continued chatting with the (rather overprepared) Philippines traveller, who had a full-blown travelling kit, all while continuing to watch Oshi No Ko (2023). Just like the fellow passenger from the first flight, I helped her with some pictures from the airplane window too. When it came to the meals, I intentionally kept it lightweight and strictly avoided alcoholic liquor to ensure that I was well hydrated. In between keeping myself entertained and zoning out of consciousness, I soon found myself nearing Václav Havel Airport Prague (PRG) at around 0100pm Central European Summer Time.

With zero transit buses to catch, as we landed directly at the arrival gates, I left for the automated immigration registration kiosks after bidding my fellow passengers farewell. There were manual checks too, which got expedited due to the presence of these automated border check kiosks, and I was able to pass through the massive queue in just about 20 minutes or so. As I observed that the passengers from East Asia were struggling with the language choices, I decided to stay back a little to help them pick the correct language using nothing but gestures to connect. While I initially planned on purchasing a Czech Republic SIM card from there, I decided to get to the hotel first because it had been 24 hours since I had left home, and some rest after checking in would do wonders in helping my body recover.

Using Uber's automated digital kiosk to book a rented cab and the public WiFi for authorization purposes, I was finally able to get to the Ibis Praha Mala Strana hotel by about 0200pm Central European Summer Time. This was the same hotel where I stayed the last time too, and it was just convenient to stay at a location which was barely a couple of minutes away from the event venue. I got in touch with the likes of Michal Konecny and Tomáš Hrčka after checking into Room 401, all while checking in with the likes of Kevin Fenzi and Justin Wheeler. One of the first things I worked on as I waited for Michal and Tomáš to become available was ensuring that the staging Fedora Badges deployment was working correctly, as I wanted to use that as an apparatus for experiments in the workshop the next day.

I witnessed my plans of getting some rest turn to blazing ashes before my eyes as I stepped out to meet Michal, who had just checked in at around 0300pm Central European Summer Time. We moved on to have a late lunch at an Asian restaurant in the Nový Smíchov Shopping Centre's food court, all while catching up after almost a year since meeting in person. Surprisingly enough, we ran into Aoife Moloney when we went downstairs into the TESCo supermarket to purchase some cold drinks. As Michal purchased some cookies to share during the International Candy Swap Event, I kept an eye out for SIM cards to purchase. I was lucky to find a Vodafone kiosk right after exiting TESCo, and I ended up getting one without even having to share my personal details or passport information, for that matter.

With my connectivity restored, Michal and I quickly visited the hotel to drop our things before heading out to the event venue. While the event venue had remained the same from the previous year, the institution got renamed from Vienna House Andel Prague to OREA Hotel Andel Prague due to the management change. Much akin to a corridor conversation during FOSDEM events, the two of us met up with Hristo Marinov, whom we caught up with before running into Emma Kidney at the same place too. Amidst the talks about Forgejo Runners for Fedora Atomic and heading to Brno for DevConf.CZ 2026, our circle became bigger with the joining of Lenka Segura and Tomáš. As I wanted to join Tomáš to prepare for the Fedora Forge interactive workshop the next day, I quickly left for the conference venue.

While there was nothing significant to be done at the event venue on that day as the event was starting the next day, going there definitely gifted us Clement Verna, with whom I was meeting again after almost three years. Leaving Hristo to have a chat with him after a swift introduction to the Fedora CoreOS team members, Michal and I ran into Daniel Mellado and Fernando Fernandez Mancera at an adjacent cafeteria. Since I could not visit the FOSDEM 2026 event, I was meeting them again after almost a year as well since the previous Flock event. After a quick chat with Kacper Skrzyński, the two of us went into a nearby bookstore as Michal wanted to redeem a discount coupon while buying two volumes of the Chainsaw Man (2018) manga at around 0500pm Central European Summer Time.

Coincidentally enough, we met up with Tomáš again at the Anděl crossing and, with Michal heading back to the hotel, Tomáš and I moved through Nový Smíchov Shopping Centre to make our way into the green hills behind it. With just how tucked in it was behind the low-height concrete structures, it was surprising how he knew about the location in the first place. Visiting a densely vegetated park area also reminded me of us doing the same thing about a year back, although that was a different location and we had more folks around. The peaceful ambience of the green zone allowed us to work on the workshop preparations all while catching up on our conversations. Even though I initially planned on demonstrating the private issues feature, I ultimately ended up scrapping it in favor of more interaction.

Tomáš' initial dining plans with the Fedora Quality team members did not come to fruition as they seemed to have gone for food already. After some more visits to the Nový Smíchov Shopping Centre to purchase some mineral water, the two of us headed over to a nearby quaint Vietnamese-themed restaurant called Old Hanoi at around 0700pm Central European Summer Time. With some delicious bites after the dry meat I had on the incoming flight, and even more fun conversations, this felt like the right way to kick off the next three days of community celebrations at Flock To Fedora 2026. I had already been running on fumes while being awake for almost over 30 hours by that time, so I decided to call it a day a little early at around 0830pm Central European Summer Time to get some well-deserved rest.

misc fedora bits: start of july 2026

Posted by Kevin Fenzi ( Fedora Account System Username

kevin ) on 2026-07-04 19:35:58 UTC

"Today's the fourth of july. Another june has gone by."

(appologies to Amiee Mann).

Here's another short recap of the last week from me. I was off Thursday, and Friday was a holiday, and I'm off next monday too, so this was a short week.

aarch64 builders and vmhosts reinstalls

I spend a bit of time reinstalling our aarch64 bvmhosts. These are the machines that run all our buildvm-a64 instances. You would think this would be a trivial task, but of course not.

When we got these machines as part of the datacenter move last year, we couldn't get them to pxe boot from their 25G network. So, we ended up patching some 1G connections to them to provision them. Then those links were removed. So, I needed to fix the issue this time.

Turned out it was just some settings in the network card eeprom/settings. To adjust it, I had to build a kernel module, load that, then poke at the settings with a tool. Quite a pain, but luckily only a one time thing.

After that, they pxe booted fine and were easy to reprovison with rhel10. Except, then I hit the next thing: One of them had a bad memory stick in it. We had hit this before, but after reseating all the memory it came up ok, but that memory just decided to croak this time.

So, dc operations folks did a bunch of testing and isolated the bad memory. Should be on the way in to get a replacement now. Until the replacement arrives that machine is down memory, so a few buildvm's on it are shutdown. Shouldn't matter too much.

Staging openshift workers network

Last week we moved a number of servers to balance power in racks. That went fine, but networking folks noticed that 3 of the machines were not properly using 802.3ad/lacp. That is, they were only connected on one interface. These machines were our staging openshift workers.

It took me quite a lot of poking around to see what happened and how to fix it. Openshift has a lot of ways it configures network and it was not clear at all to me the flow. I did finally figure it out though: I had installed them with net.ifnames=0 set. This meant they had eth2 and eth3 interfaces that were the active ones. After the install, they booted without that and so the interface names changed. The new ones didn't have any config, so it just picked the first one and ran it's ovh setup on. So, I had to go in and setup NetworkManager to know about the new interface names so it would bond them, then the openshift setup script would just take that bond device and setup on it.

I wish openshift made it easier to tweak this.

Off on monday, see everyone tuesday!

As always, comment on the fediverse: https://fosstodon.org/@nirik/116863452466227942

Session Participations - Flock To Fedora 2026

Posted by Akashdeep Dhar ( Fedora Account System Username

t0xic0der ) on 2026-07-03 18:30:25 UTC

Session Participations - Flock To Fedora 2026

Here is the list of sessions that I participated in during Flock To Fedora 2026, which was organized from June 14th 2026 to June 16th 2026 in Prague, Czechia.

Fedora Badges Revamp Project Progress Update

Metadata

Verdict: Rejected
Location: Unavailable
Schedule:
- Undefined
Submitters:
- Akashdeep Dhar
- Shounak Dey
Type:
- Short presentation
  25 minutes
Themes:
- Empowering Collaboration: Tools and Practices for Fedora's Future
- Welcoming New Voices: Pathways for Fedora Contributors
- Driving Innovation: Fedora and Emerging Technologies
Complexity:
- Beginner
  Anyone can follow along without previous context
Resource:
- https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/VQ87RYXJJCBYGK39XAKQX8CMZHGF7SXZ

Abstract

How do you replace the engine of a moving car? Or better yet, how do you replace the heart of a living human? For decades, Fedora Badges has been a crucial partner for gamifying contributor engagement, but its ageing frontend technologies and backend infrastructure were becoming unmaintainable. This talk dives into the multi-year project to completely revamp Fedora Badges, piece by piece, while having it run just fine with sustainably equivalent feature parity. We will explore the transition from a legacy system to a modern architecture with our move from synchronous backend libraries like Flask to asynchronous backend libraries like FastAPI and from static templating systems like Jinja to progressive interface frameworks like React.

Particulars

Identifying technical debt and associated risks of maintaining legacy systems past their end-of-support timeline
Why we moved on to a modern stack centered around asynchronous processing and progressive application
Moving code was not hard, moving data was - Complexities and learnings of the runtime active migration procedure
Evolving system administration from legacy centered virtual machines to cloud native OpenShift deployments
Demonstration and interactions of the live deployment of Fedora Badges, with the plans for further development
Interactive feedback from the participants on both the backend infrastructure and frontend technologies

Takeaways

Strategies for tackling massive technical debt acquired through years in established open source projects
Real world lessons on live migration of databases and tooling using examples from Fedora Infrastructure
Understanding the benefits of modern stack for community tooling and onboarding community contributors
Balancing technical innovation with community continuity - You can revamp, but should you revamp?
Encouragement and retention of voluntary contributors through gamifying aspects of community activities
Strategies for ensuring the longevity of the project codebase by working with various community disciplines

References

Update on Fedora Badges Revamp Project - https://gridhead.net/update-on-fedora-badges-revamp-project/
Tahrir - Fedora Infrastructure - GitHub - https://github.com/fedora-infra/tahrir
#badges-team topics on Fedora Discussions - Discourse - https://discussion.fedoraproject.org/tag/badges-team
Fedora Badges - Advanced Reconnaissance Crew - https://fedora-arc.readthedocs.io/en/latest/badges/index.html
Discourse as frontend for Fedora Badges - Discourse - https://discussion.fedoraproject.org/t/so-we-investigated-discourse-to-confirm-if-it-is-worthy-of-be...
Getting Fedora Badges Back in Shape - Discourse - https://discussion.fedoraproject.org/t/getting-fedora-badges-back-in-shape/42942

Fedora Badges Revamp Project - Design and Development Workshop

Metadata

Verdict: Accepted
Location: Opal hall, OREA Hotel Andel's Prague
Schedule:
- 14th June 2026, 0900am - 1040am CEST
Submitters:
- Akashdeep Dhar
- Chris Onoja Idoko
Type:
- Workshop / BoF
  1.8 hours
Themes:
- Empowering Collaboration: Tools and Practices for Fedora's Future
Complexity:
- Beginner
  Anyone can follow along without previous context
Resource:
- https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/HUXM7JYBFJMRUMDQXVBWPCBYD9XENEM3

Abstract

How do you replace the engine of a moving car while simultaneously replacing its paintjob? For over a decade, Fedora Badges has been the cornerstone of gamifying contributions and engaging achievements. However, as we head into 2026, the project faces a double deficit: crippling technical debt on the backend, and a trust problem regarding undeployed modern artwork redesigns.

Our hybrid session dives into the multi year perspective of the Fedora Badges Revamp Project and the artwork design mentoring initiative. In the first half, we will explore the live migration of legacy synchronous systems to a modern application stack, on a staging environment. In the second half, we will find ourselves leveraging the Forgejo Migration to get redesigned artworks online.

This “Design To Deploy Sprint” takes advantage of the recent aggressive move away from Fedora Pagure to Fedora Forge, to finally integrate our lost modern style guidelines into the upcoming Fedora Badges revamp. Thus, emerging from our past coordination disconnects to not just move code and data, but evolve the reward system that unmistakably, establishes the Fedora Project brand.

Questions

Primary question: How can we simultaneously modernize the legacy Fedora Badges system for the Fedora Forge era while designing modern gamification incentives to revitalize various subprojects and SIGs?
Engagement question: How do we retroactively honor the modern badge artwork redesigns to restore the trust among the community designers while keeping up with the evolving requirements of the communities?

Relevance

Experience sharing: Understanding the user personas interacting with the Fedora Badges service platform, their happinesses and their pain points, to find targets to pursue and potentially improve.
Coordination healing: To openly acknowledgement the disconnection and discover ways to ensure that the efforts do not go unnoticed and time does not go sidelined due to more pressing affairs.
Tangible progress: To give a milestone update to the community about the engineering progress and design efforts - all while setting the community expectations on the project’s future.
End-to-end onboarding: To produce a verified batch of production-ready artwork and provide a hands-on experience to the attendees so that they can immediately start contributing to the design.

Methodology

Part 1 - The Engine (Technical walkthrough)
- Identifying the potential risks of continually maintaining legacy systems and finding reasons to modernize the stack
- Recognizing the complexities of the migrating data and evolving service system administration to cloud-native deployments
- Interacting with the staging environment and discussing on balancing technical innovations with community continuity
Part 2 - The Paintjob (Design modernization)
- Reviewing the legacy guidelines against the modern ones and capitalizing on the Forgejo migration for the artwork overhaul
- Collaborating with the attendees to create/refine existing badge artworks using the modern artwork design guidelines
- Uploading the refined badges design artwork to demonstrate the roadmap for the replacing legacy badges artwork process

Forging Fedora Project's Future With Forgejo

Metadata

Verdict: Accepted
Location: Sapphire hall, OREA Hotel Andel's Prague
Schedule:
- 14th June 2026, 1100am - 1240pm CEST
Submitters:
- Akashdeep Dhar
- Tomas Hrcka
Type:
- Workshop / BoF
  1.8 hours
Themes:
- Empowering Collaboration: Tools and Practices for Fedora's Future
Complexity:
- Intermediate
  Some background knowledge/context is required
Resource:
- https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/UGZ9KQXDHNX7ZURGENPH3VMZQCMBJ93U

Abstract

Fedora Project is undergoing significant infrastructure changes that affect everyone from distribution users to individual contributors - that is, migrating from Pagure to Forgejo as its primary Git forge for both source code and package sources. Our talk chronicles the journey from the early days of collective debating between GitLab and Forgejo with Fedora Council, through the ongoing migration of thousands of repositories with Fedora Infrastructure.

While the initiative began due to the need to move away from Pagure, it gradually evolved into one that also aimed at fixing the long-standing pain points faced with workflows. We got the opportunity to streamline the processes that made sense about a decade back, and have since then, slowly started getting in the way of contribution. This also allowed us to contribute back to the Forgejo upstream with the features that would end up benefiting all.

This workshop aims to progress along with the work that we have been up to so far with creating solutions for migrating projects from Fedora Pagure and Package Sources. Participants can take advantage of the learnings on building compatibility bridges, CI/CD workflow modernisation, granular permission models, existing toolchain integration and comprehensive documentation writing, while working on building the Fedora Forge platform.

Resources

Fedora Moves Towards Forgejo - Fedora Magazine https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/
Announcing the Soft Launch of Fedora Forge - Fedora Community Blog https://communityblog.fedoraproject.org/announcing-the-soft-launch-of-fedora-forge/
Forging Fedora’s Future with Forgejo - Fedora Community Blog https://communityblog.fedoraproject.org/forging-fedoras-future-with-forgejo/
Git Forge Initiative - Fedora Council - Fedora Wiki https://fedoraproject.org/wiki/Initiatives/Git_Forge_Initiative_2025
Dist Git Move - Advanced Reconnaissance Crew - Read The Docs https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html
Dist Git Comparison - Advanced Reconnaissance Crew - Read The Docs https://fedora-arc.readthedocs.io/en/latest/dist-git-comparison/index.html

Fedora Mentor Summit: Lunch and Learn Matching

Metadata

Verdict: Accepted
Location: Lunch area, OREA Hotel Andel's Prague
Schedule:
- 14th June 2026, 1245pm-0145pm CEST
- 15th June 2026, 0100pm-0200pm CEST
- 16th June 2026, 0100pm-0200pm CEST
Submitters:
- Akashdeep Dhar
- Cornelius Emase
- Jona Azizaj
- Justin Wheeler
- Kevin Fenzi
- Luis Bazan
Type:
- Social event
  45 minutes
Themes:
- Freedom: The Open Frontier
- Friends: Our Fedora Story
- Features: Engineering Fedora's Core
- First: Blueprint for the Future: Fedora Linux 45 & 46
- Empowering Collaboration: Tools and Practices for Fedora's Future
- Welcoming New Voices: Pathways for Fedora Contributors
- Driving Innovation: Fedora and Emerging Technologies
Complexity:
- Beginner
  Anyone can follow along without previous context
Resources:

Abstract

Mentorship has always been a big part of what makes Fedora special. After a great response last year, we’re bringing back the Mentor–Mentee Lunch at the Fedora Mentor Summit at Flock 2026, with a small tweak. A casual lunch matching session where everyone can meet face-to-face, share stories, swap ideas, and connect over common goals.

Instructions

Anyone attending Flock can join.
Participants are grouped based on topic of interest, no pre-signup required.
Each day features different topics, so people can explore multiple areas across the event.
Need a conversation starter? We’ll have a few prompts ready to help break the ice.
Take a group selfie during lunch and you’ll earn a Fedora Badge as a fun keepsake.

Topics

Day 1 - Sunday, 14th June 2026
- Documentation
- Operations
- Development
- Marketing
Day 2 - Monday, 15th June 2026
- Packaging
- Infrastructure
- Interpersonal Skills
- Events
Day 3 - Tuesday, 16th June 2026
- Artificial Intelligence
- Governance
- Release Engineering
- Design

No formal structure - just good food and good conversation with someone else who cares about growing the Fedora community.

Fedora Council Strategic Proposals

Metadata

Verdict: Accepted
Location: Plenary hall, OREA Hotel Andel's Prague
Schedule:
- 15th June 2026, 1100am - 1240pm CEST
Submitters:
- Akashdeep Dhar
- Aleksandra Fedorova
- Aoife Moloney
- Jef Spaleta
- Jona Azizaj
- Justin Wheeler
- Miro Hroncok
- Peter Boy
- Petr Bokoc
Type:
- Long presentation
  55 minutes
Themes:
- Empowering Collaboration: Tools and Practices for Fedora's Future
- Driving Innovation: Fedora and Emerging Technologies
Complexity:
- Intermediate
  Some background knowledge/context is required
Resource:
- https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/UTX3M9QDPCM3DCN8ARXXBXPHKT8K97XB

Abstract

The Fedora Council would like to provide an overview of in-progress draft proposals to the community and hold a live community question and answer session to help refine the proposals further before adoption as project policy.

This proposal is an action item from the Fedora Council Strategic Summit to ensure we take advantage of Flock as a key milestone to communicate the status of strategic policy work items that were agreed to as part of the meeting.

Fedora Mindshare Townhall Session - From Conferences To Recognition

Metadata

Verdict: Accepted
Location: Plenary hall, OREA Hotel Andel's Prague
Schedule:
- 16th June 2026, 0245am - 0345pm CEST
Submitters:
- Akashdeep Dhar
- Aoife Moloney
- Emma Kidney
- Gregory Sutcliffe
- Joseph Gayoso
- Justin Wheeler
- Luis Bazan
- Mat H
- Samyak Jain
Type:
- Long presentation
  55 minutes
Themes:
- Welcoming New Voices: Pathways for Fedora Contributors
Complexity:
- Beginner
  Anyone can follow along without previous context
Resource:
- https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/JX8ZPEBRMVMZQTV3EDPEHHUH7W7BGYL7

Abstract

From getting resources for swagpacks to laying foundations for conferences, the Fedora Mindshare Townhall Session creates an inclusive and structured space for attendees to meet with their representatives, discuss community health, talk engagement strategies, and identify recognition opportunities and evaluate regional growth. This session will briefly cover what the committee has been up to since the last Flock To Fedora conference, before opening up the space for curious questions and open conversations.

While focusing on surfacing challenges and exploring opportunities related to contributor experience, crossteam collaboration, event impacts and outreach effectiveness, participants will be encouraged to share perspectives from their home regions, propose improvements to the committee's processes, and identify concrete next steps that can strengthen the Fedora Project's global community over the next release cycles. Hence, this session intends to take full advantage of both the participants and attendees present at the event.

Fedora Mentor Summit: Contributor Recognition

Metadata

Verdict: Accepted
Location: Plenary hall, OREA Hotel Andel's Prague
Schedule:
- 16th June 2026, 0400pm-0420pm CEST
Submitters:
- Akashdeep Dhar
- Cornelius Emase
- Jona Azizaj
- Justin Wheeler
Type:
- Short presentation
  25 minutes
Themes:
- Empowering Collaboration: Tools and Practices for Fedora's Future
Complexity:
- Beginner
  Anyone can follow along without previous context
Resources:
- https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/JPWK8PH3QKMBWXGQHPXBGKUBXRECR8AP

Abstract

Fedora is built by contributors working across many areas such as development, documentation, design, quality assurance, infrastructure, user support, mentoring, and outreach, many of which happen behind the scenes. The Fedora Contributor Recognition Program was created to recognize and reward outstanding contributions to the Fedora community. In this session, we will explain how the program works, from the open nomination process to the review and selection process carried out by experienced Fedora contributors using criteria such as impact, quality, innovation, and community engagement. We will also share lessons learned from running the program last year. The session will conclude with the announcement of this year’s winners, celebrating their work and highlighting the many ways people contribute to Fedora.

Transmission: Córrelo como servicio de usuario

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-07-03 16:45:00 UTC

Hoy me dió por tener corriendo mi daemon de BitTorrent preferido: Transmission, como un servicio de sistema. La neta, correrlo de manera global con el usuario transmission por defecto está chido si estás en un servidor dedicado, pero en mi compu personal (mi Fedora 44 de diario) es una lata. Yo quería que leyera mis configuraciones locales, que las descargas cayeran directo en mi carpeta personal (~/Downloads/torrents) y, sobre todo, que se levantara nomás cuando yo inicio mi sesión de usuario.

Así que me di a la tarea de crearle un servicio de usuario a nivel de systemd para quitarme de broncas. Aquí te cuento de volada cómo lo armé pa' que no le batalles.

Procedimiento

Para lograr que jale como un servicio local y lea tus configuraciones de usuario, el proceso está bien pleada. Nomás sigue estos pasos:

Crear el archivo de servicio de usuario: En lugar de modificar el archivo global en /usr/lib, copié la base del servicio y creé un archivo local en tu $HOME.

# ~/.config/systemd/user/transmission-daemon.service
[Unit]
Description=Transmission BitTorrent Daemon
Wants=network-online.target
After=network-online.target
Documentation=man:transmission-daemon(1)

[Service]
Type=notify-reload
ExecStart=/usr/bin/transmission-daemon -f --log-level=error -g %E/transmission

# Hardening
CapabilityBoundingSet=
DevicePolicy=closed
KeyringMode=private
LockPersonality=true
NoNewPrivileges=true
MemoryDenyWriteExecute=true
PrivateTmp=true
PrivateDevices=true
ProtectClock=true
ProtectKernelLogs=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectSystem=true
ProtectHostname=true
ProtectKernelTunables=true
ProtectProc=invisible
RestrictNamespaces=true
RestrictSUIDSGID=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictRealtime=true
SystemCallFilter=@system-service
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM

[Install]
WantedBy=default.target

Note

Le quité la directiva User=transmission porque los servicios de usuario de systemd ya corren con tu propio UID de cajón. Además, agregué la opción -g %E/transmission (usando el especificador de systemd %E que apunta al directorio raíz de configuración del usuario, que por defecto es ~/.config o el valor de $XDG_CONFIG_HOME) para que lea los mismos archivos que usa la interfaz gráfica (GTK) de Transmission y no se me haga un desmadre con directorios separados.

Recargar systemd y arrancar el servicio: Una vez guardado el archivo, dile a systemd que recargue tu configuración de usuario y levanta el daemon de volada.
```
systemctl --user daemon-reload
systemctl --user enable --now transmission-daemon.service
```
Evitar que se te sobreescriban los cambios: Si necesitas cambiar alguna configuración en el settings.json (por ejemplo, habilitar la interfaz web o el RPC), ten mucho cuidado. Si editas el archivo con el daemon corriendo, al momento de reiniciarlo o apagar la compu el daemon va a vaciar su estado en memoria y te va a mandar tus cambios a la chingada.

Para evitar esto, el flujo correcto es detener el servicio antes de meterle mano al archivo:
```
systemctl --user stop transmission-daemon.service

# Edita tu ~/.config/transmission/settings.json ahora sí

systemctl --user start transmission-daemon.service
```

¿Cómo quedó el cotorreo?

Una vez que el daemon arranca con la ruta de tu configuración local, la integración es transparente y bien chingona:

Descargas automáticas: Todo cae directamente en tu directorio configurado (por ejemplo, ~/Downloads/torrents).
Directorio de monitoreo: Si dejas caer un archivo .torrent en la carpeta de watch (en mi caso, la misma carpeta de descargas), el daemon lo detecta y lo empieza a bajar de volón.
Control Remoto: Como habilité el RPC, puedo administrar mis descargas desde el navegador entrando a http://localhost:9091/ o usando clientes como transmission-remote-gtk sin que me consuma recursos tener la interfaz gráfica de Transmission abierta todo el día.

Warning

¡Cuidado con correr ambos al mismo tiempo! Si tienes el daemon activo en segundo plano e intentas abrir la interfaz gráfica de Transmission (GTK), van a chocar por el puerto de red (generalmente el 51413) y pueden corromper los archivos de estado. Te recomiendo usar la interfaz web o una herramienta remota para controlar el daemon. La ventaja es que te vas a ahorrar un buen de memoria RAM.

Conclusiones

La neta, configurar Transmission como servicio de usuario es un paro enorme si eres de los que deja descargas corriendo en segundo plano pero no quieres configurar un servidor dedicado para eso. Con unos cuantos minutos y systemd de tu lado, dejas tu Fedora 44 bien optimizada y lista para el jale pesado.

¿Cómo la ves? A poco no está bien suave tener el control total de tus torrents sin desmadres de permisos, no?!

Referencias

Community Update – Week 27

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-07-03 11:00:00 UTC

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 29 June – 3 July 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

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

RISC-V

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

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

AI

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

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

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

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

Forgejo

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

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

EPEL

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

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

UX

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

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

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

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

🎲 PHP 8.6 as Software Collection

Posted by Remi Collet ( Fedora Account System Username

remi ) on 2026-07-03 05:38:00 UTC

Version 8.6.0alpha1 has been released. It's still in development and will soon enter the stabilization phase for the developers and the test phase for the users (see the schedule).

The RPMs of this upcoming new version of PHP 8.6, are available in remi repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) in a fresh new Software Collection (php86) allowing its installation beside the system version.

As I (still) strongly believe in SCL's potential to provide a simple way to allow installation of various versions simultaneously, and as I think it is useful to offer this feature to allow developers to test their applications, to allow sysadmin to prepare a migration or simply to use this version for some specific application, I decide to create this new SCL.

I also plan to propose this new version as a Fedora 46 change (as F45 should be released a few weeks before PHP 8.6.0).

Installation :

yum install php86

⚠️ To be noticed:

the SCL is independent from the system and doesn't alter it
this SCL is available in remi-safe repository (or remi for Fedora)
installation is under the /opt/remi/php86 tree, configuration under the /etc/opt/remi/php86 tree
the FPM service (php86-php-fpm) is available, listening on /var/opt/remi/php86/run/php-fpm/www.sock
the php86 command gives simple access to this new version, however, the module or scl command is still the recommended way.
for now, the collection provides 8.6.0-alpha1, and alpha/beta/RC versions will be released in the next weeks
some of the PECL extensions are already available, see the extensions status page
tracking issue #342 can be used to follow the work in progress on RPMS of PHP and extensions
the php86-syspaths package allows to use it as the system's default version

ℹ️ Also, read other entries about SCL especially the description of My PHP workstation.

$ module load php86
$ php --version
PHP 8.6.0alpha1 (cli) (built: Jun 30 2026 11:28:16) (NTS gcc x86_64)
Copyright © The PHP Group and Contributors
Built by Remi's RPM repository  #StandWithUkraine
Zend Engine v4.6.0-dev, Copyright © Zend by Perforce
    with Zend OPcache v8.6.0alpha1, Copyright ©, by Zend by Perforce

As always, your feedback is welcome on the tracking ticket.

Software Collections (php86)

🛡️ PHP version 8.2.31, 8.3.31, 8.4.21 and 8.5.6

Posted by Remi Collet ( Fedora Account System Username

remi ) on 2026-05-08 05:52:00 UTC

RPMs of PHP version 8.5.6 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.4.21 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.3.31 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.2.31 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

ℹ️ These versions are also available as Software Collections in the remi-safe repository.

ℹ️ The packages are available for x86_64 and aarch64.

🛡️ These Versions fix 8 to 13 security bugs (CVE-2026-6735, CVE-2026-7259, CVE-2025-14179, CVE-2026-6722, CVE-2026-7261, CVE-2026-7262, CVE-2026-7568, CVE-2026-7258, CVE-2026-6104, CVE-2026-42371, CVE-2026-7263, CVE-2026-29078, CVE-2026-29079), so the update is strongly recommended.

Version announcements:

ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

Fedora Rawhide now has PHP version 8.5.6
Fedora 44 - PHP 8.5.6
Fedora 43 - PHP 8.4.21
Fedora 42 - PHP 8.4.21

⚠️ To be noticed :

EL-10 RPMs are built using RHEL-10.1
EL-9 RPMs are built using RHEL-9.7
EL-8 RPMs are built using RHEL-8.10
intl extension now uses libicu74 (version 74.2)
mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

🎲 PHP version 8.4.23RC1 and 8.5.8RC1

Posted by Remi Collet ( Fedora Account System Username

remi ) on 2026-06-19 03:59:00 UTC

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.

RPMs of PHP version 8.5.8RC1 are available

as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
as SCL in remi-test repository

RPMs of PHP version 8.4.23RC1 are available

as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
as SCL in remi-test repository

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

dnf module switch-to php:remi-8.5
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

ℹ️ Notice:

version 8.5.8RC1 is in Fedora rawhide for QA
EL-10 packages are built using RHEL-10.2 and EPEL-10.2
EL-9 packages are built using RHEL-9.8 and EPEL-9
EL-8 packages are built using RHEL-8.10 and EPEL-8
oci8 extension uses the RPM of the Oracle Instant Client version 23.26 on x86_64 and aarch64
intl extension uses libicu 74.2
RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

⚙️ PHP version 8.4.22 and 8.5.7

Posted by Remi Collet ( Fedora Account System Username

remi ) on 2026-06-05 04:40:00 UTC

RPMs of PHP version 8.5.7 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.4.22 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

ℹ️ These versions are also available as Software Collections in the remi-safe repository.

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ There is no security fix this month, so no update for versions 8.2.31 and 8.3.31.

Version announcements:

ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

Fedora Rawhide now has PHP version 8.5.7
Fedora 44 - PHP 8.5.7
Fedora 43 - PHP 8.4.22

⚠️ To be noticed :

EL-10 RPMs are built using RHEL-10.2
EL-9 RPMs are built using RHEL-9.8
EL-8 RPMs are built using RHEL-8.10
intl extension now uses libicu74 (version 74.2)
mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

🛡️ PHP version 8.2.32, 8.3.32, 8.4.23, and 8.5.8

Posted by Remi Collet ( Fedora Account System Username

remi ) on 2026-07-03 04:31:00 UTC

RPMs of PHP version 8.5.8 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.4.23 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.3.32 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.2.32 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

ℹ️ These versions are also available as Software Collections in the remi-safe repository.

ℹ️ The packages are available for x86_64 and aarch64.

⚠️ PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.

🛡️ These Versions fix 3 security bugs (CVE-2026-12184, CVE-2026-14355), so the update is strongly recommended.

Version announcements:

ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

Fedora Rawhide now has PHP version 8.5.8
Fedora 44 - PHP 8.5.8
Fedora 43 - PHP 8.4.23

⚠️ To be noticed :

EL-10 RPMs are built using RHEL-10.2
EL-9 RPMs are built using RHEL-9.8
EL-8 RPMs are built using RHEL-8.10
intl extension now uses libicu74 (version 74.2)
mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

Securing agentic identity

Posted by Matthew Garrett ( Fedora Account System Username

mjg59 ) on 2026-07-03 00:38:23 UTC

As is the case for many people working in the security industry, the last few months of my life have been focused on dealing with people wanting to use LLMs everywhere. From an enterprise security perspective that’s not an inherent problem - what’s more of a problem is that people want those agents to have access to resources like their calendar and email and so on, and now we have somewhat non-deterministic agents that seem very enthusiastic to achieve what you asked whether that’s a good idea or not, and we’re combining this with credentials that give them access to sensitive data, and leaving those credentials on disk where they can be committed into git repos or exfiltrated to some other service to make use of them on the agent’s behalf or well just any other number of things, at which point your CEO’s email is suddenly readable by everyone and you’re having a bad day.

As I mentioned in my last post, pretty much every strong mechanism for keeping credentials in place is just not supported in the wider world. We can imagine a universe where agents use hardware (or at least hypervisor) backed certificates to obtain credentials and any that end up leaking are worthless as a result. But, sadly, that’s not an option for most people using existing identity providers. The state of the art is that you use the device code flow and a human authenticates and the token ends up back inside the agent environment and then it proceeds to do whatever it wants with it and you just hope that you wake up the next morning without an awful infoleak occurring.

(An aside: I do not like the device code flow as used in enterprise environments, and I never will. The identity provider doesn’t have a real opportuity to inspect the security posture of the system asking for the token, and as a result some identity providers will restrict tokens that are issued in this way. The common alternative of doing stuff using a more standard flow and having a redirect URI pointing at localhost works fine for local systems and is a pain for remote ones, even if you can commit crimes with SSH forwarding. I’m going to suggest something that I think is better, and you are free to disagree)

I’m not in a position to get every identity provider and service provider to change their security posture, so I’m somewhat stuck in terms of the tokens they’re willing to issue me - largely either JWTs or opaque access tokens, with no support for any mechanism of binding that token to an instance. The token that’s going to have to be provided to the remote service is something I have little influence over. But that doesn’t mean I can’t influence the token that lands inside the agent’s environment. I can issue a placeholder token to the agent, and force it to communicate via a proxy that swaps out the placeholder for the real thing. The worst the agent can do is exfiltrate the placeholder token, and as long as malicious actors don’t have access to that proxy, it doesn’t matter - nobody else can do anything with the placeholder.

This isn’t a terribly novel insight, and it seems like almost everybody has reinvented this on their own. But a lot of these implementations involve you somehow obtaining the real token in advance and then pasting that into something that generates a placeholder that you provide to your agent environment somehow, and it’s all a bit clunky and awkward, and it also means that you need to deal with something that keeps track of the mapping between placeholders and real tokens and oh no we’ve just invented a secret store, and if you want this to work at scale and reliably you’re just invented a high availability distributed secret store, and a lot of people who’ve read that are now shaking their heads and reaching for gin. Can we simplify this, and improve security at the same time? I think we can!

Remember when I said “as long as malicious actors don’t have access to that proxy, it doesn’t matter”? What if they do? What if they compromise one machine inside your environment and are then able to email a bunch of employees and convince their agents to send more tokens back to them and then delete the email before a human reads it? Now you have someone inside the wall with access to those tokens, and presumably with access to the proxy, and now they can be anyone whose agent was gullible enough to think sending them a token was a good idea. This isn’t good!

So, I thought for a while, and I came up with a new idea. We can have a broker service that obtains credentials for us. We can run that centrally, away from the agents. A client in an agentic environment can request a token, and that can result in a URL being generated and the user being directed to open a URL in a browser and authenticate. When the user authenticates, the authentication flow redirects the confirmation back via the broker, and the broker obtains the real auth token. The obvious thing to do now would be to return the auth token to the client in the agentic environment, but we don’t do that. Instead, we mint a new JWT, and add a new claim - one that contains an encrypted copy of the token. In the process we can copy over all the original claims, because those aren’t secret - and now even if the client inspects the token to figure out what access it has, it’ll get a correct answer. We sign the new token with our own signing key, and pass that back to the client. The client now has a legitimate JWT that is utterly useless, because the signature isn’t trusted by anyone other than us.

How does it use it? It makes an API request via a proxy, including the new token in the Authorization: header. The proxy verifies the signature on the token, and then decrypts the original token and swaps out the fake token for the real one. The remote API sees what it expects, and everyone is happy. There’s never a real token in the agentic environment, but also we don’t need to store anyting anywhere. The only state is the encryption keys, and those can be injected into the environment at startup. You need to scale? Just start more of these processes. You need to support multiple availability zones? Just start more of these processes in different places. No persistent data is ever held in the broker or the proxy. You don’t need to care about distributed databases or secret stores.

This felt wonderfully elegant and I felt smug about coming up with a better idea, and then I went to a bar earlier this week and sat down to read RFC 8705 and the guy next to me saw that over my shoulder and asked what I was reading and I explained why I was interested and we talked about agentic identity and then he mentioned that fly.io had something that sounded very similar and I read that and gosh yes it is very similar, so damn you fly.io for stealing my ideas 3 years before I even had them. Anyway. Now I need to do better.

Remember that there’s still a risk around anyone who has access to the proxy having access to the encrypted keys? We can remove that risk as well. It’s not uncommon for agentic environments to have an identity issued via something like SPIFFE, at which point they have a client certificate. You can probably guess where I’m going with this. If we require that an agent present a client cert to the broker when requesting a token, we can embed a representation of that client cert into the token we mint. The proxy can then require mTLS for the client connection, and can verify that the presented certificate matches the one represented in the token. If it does then whoever’s using the token has access to the private key associated with the environment it was issued to. If we then ensure that the private keys backing these certificates are either hardware or hypervisor backed, and as such tied to a specific instance, we now have a high degree of confidence that the token can only be used in its intended environment. Even if our identity provider doesn’t support RFC 8705, we can.

This is fairly straightforward where you’re using a platform where your identity provider is also the environment that’s consuming your tokens, and more annoying for third parties. The broker potentially needs some amount of third party vendor knowledge to make that work for everyone. This is even more the case where login isn’t via your identity provider (thanks, github), but none of this is insurmountable - just annoying. And where vendors issue opaque tokens rather than JWTs, this still isn’t a problem; we can just mint a new JWT that includes the opaque token as an encrypted claim, and include the same certificate binding. The opaque token ends up being the thing that’s presented to the third party, but only after we’ve verified the mTLS binding.

In an ideal world none of this would be necessary - someone would spin up a new agentic environment, a user would prove their identity, and a certificate embodying that identity would be issued to the environment with a private key that can’t be exfiltrated. That certificate would be sufficient to obtain new certificates associated with the same private key, and we could still bind that into mTLS identity. This would be much simpler, but browsers don’t support it, so it’s not likely to happen any time soon.

Anyway. Even if we can’t have the best thing, we can do better than we are at the moment, and also it would be lovely if we could standardise on this rather than have everyone build their own thing. The end.

Friday Links 26-22

Posted by Christof Damian ( Fedora Account System Username

cdamian ) on 2026-07-02 22:00:00 UTC

The Little Mermaid statue on a rock in Copenhagen harbour, with the industrial harbour skyline behind it

Rand’s perspective on All Hands is worth a read this week. I did enjoy the interview with the airline pilot.

Quote of the Week

The first rule is that a measurement—any measurement—is better than none.

High Output Management

Andrew S. Grove

Leadership

In defense of AI mandates (xpost) - interesting perspective. You will lose people obviously, in some way or another.

What size project needs a code of conduct?

Posted by Ben Cotton ( Fedora Account System Username

bcotton ) on 2026-07-02 12:00:00 UTC

I’m part of a project that’s been hibernating longer than many projects have existed. As part of awaking from slumber, the project’s leadership decided to adopt a code of conduct. Like me, they believe that it’s a necessary starting point for a community in 2026 (or whatever year you read this) and a rare exception to the “don’t add policies until you need them” rule.

Some people, as is usually the case, questioned the need for a code of conduct this early. The project is small, barely active, and fairly collegial. Why bother? As I’ve written before, planning ahead is the most important part of code of conduct enforcement. The worst time to figure out how to deal with bad behavior in your community is while you’re trying to deal with bad behavior in your community.

But how large does a project really have to be before it needs a code of conduct? I’m tempted to say “one person. Maybe two.” That’s a justifiable answer because a code of conduct defines the acceptable behavior for everyone who interacts with the project. It’s not just for core contributors; it’s for everyone who stops into a chat channel, files an issue, submits a pull request, and so on. As long as there’s one person for someone to interact with, a code of conduct is a reasonable part of the project’s governance.

A better answer might be “three people”. This means that if two people are having trouble, there’s one person to address the issue.

As I said above, a code of conduct should be part of the initial foundation of a project. It’s just as important as git init to building a healthy, sustainable open source community. This means that no project is too small to have a code of conduct.

This post’s featured photo by krakenimages on Unsplash.

The post What size project needs a code of conduct? appeared first on Duck Alignment Academy.

How Flock to Fedora Gets Organized

Posted by Justin Wheeler ( Fedora Account System Username

jflory7 ) on 2026-07-02 08:00:00 UTC

Flock to Fedora is the flagship contributor community event for the Fedora Project. A lot of work goes into Flock, with planning efforts usually kicking off ten months before the conference target dates. This is often the invisible work which the community rarely gets a window into seeing.

This blog post pulls back the curtain on what it actually looks like to organize Flock. It is the second post in a three-part series on Flock to Fedora 2026. The first post covers the highlights of what happened at the event. The third post shares my personal reflections on the experience.

The FCA Role and Flock

Flock to Fedora is a key part of the Fedora Community Architect (FCA) role at Red Hat. It is the flagship event of the Fedora Project community, and all three FCAs before me played pivotal roles in the organization of Flock to Fedora. However, Flock is the only event of its kind that I organize in the calendar year. While I support other events in the Fedora community, I do not take the role of a core organizer in any other event like I do with Flock.

There is a structural tension in the FCA role when it comes to Flock. There are several months of the year where the Flock event planning workload is light, and we are working through small steps at a time. But in the two to three months before Flock, the workload ramps up significantly. The team is working together more often and there are more tasks to coordinate. Meanwhile, the rest of the FCA’s responsibilities — supporting the community, budgeting, coordinating with Red Hat — do not scale down to make room.

This is not a new challenge; it is endemic to the role. All four years I have been involved as a core Flock organizer, this dynamic has been present. Perhaps there is a way to streamline and schedule Flock in a more programmatic way, so certain steps can happen earlier and others can get involved and help out. It is worth noting for anyone who inherits or reshapes this role in the future.

The Flock Organizing Team

Flock to Fedora would be nothing if not for the people who put in the time, effort, love, and care to make it the community event that it is. It is because of the amazing colleagues and teammates in the Flock core planning team that we pull off the high-quality, engaging event we do. I am incredibly grateful to the various folks who contribute various levels of time into the Flock event planning process. So, this section of my post is where I give some sincere thank-yous to Fedora Friends who take up an exceptional share of the planning work. All names are in alphabetical order:

Allison d’Amboise: Operations support, sponsorship & legal support
Ananya Nalavathu: Foundations Wall, social media support, #CommitHistory interview campaign
Aoife Moloney: Event Co-Lead
Dorka Volavkova: Event Co-Lead
Emma Kidney: Design, print, & brand/identity support
Greg Sutcliffe: Matrix virtual experience support
Jason Brooks: Operations support
Jef Spaleta: Strategic support
Jennifer McGinnis: Operations support
Jennifer Schimmoller: On-site event support, logistics, and event execution
Jess Chitas: Flock website UI/UX improvements
Jona Azizaj: Event Co-Lead
Joseph Gayoso: Social media support
Juliana Furlow: Sponsored Travel coordinator
Kevin Fenzi: Matrix virtual experience support
Lidija "Lydia" Balija: CfP lead, ops support
Madeline Peck: Design, print, & brand/identity support
Shaun McCance: Event Co-Lead

A photograph of four smiling Flock to Fedora organizers posing together at the Monday night social reception. They are standing in front of a warmly lit bar area and a large blue Fedora graphic banner. Left to right: Jennifer Schimmoller, Dorka Volavkova, Jona Azizaj, Aoife Moloney.

Figure 1. Four Flock to Fedora organizers standing together and smiling at the Monday night social reception. Y’all are amazing! Left to right: Jennifer Schimmoller, Dorka Volavkova, Jona Azizaj, Aoife Moloney.

There are even more people who have contributed something to Flock. But these are the people who went above and beyond to contribute to the success of the event. I could not do Flock without each and every one of them!

Workflow Experiment: Public Issue Tracking

I also tried out a new approach to public project management for Flock 2026. There is a new Fedora Forge repository under the Fedora Council organization, council/flock. I attempted to use this as a way to track ongoing work and have more public-facing project management to demonstrate what actually goes into executing Flock.

A screenshot of a dark-themed issue tracker for the "council/flock" Fedora Forge repository, displaying a list of seven open and 119 closed tasks. The visible open issues include post-event tasks such as processing reimbursements and publishing session recordings, each detailed with color-coded area and priority labels, the "2026 Post-Event" milestone, progress bars, assignee avatars, and comment counts.

Figure 2. A screenshot of a Fedora Forge issue tracker for the council/flock repository displaying various open and closed Flock 2026 event management tasks.

I rate the use of this experimental repository as a mixed success. Its biggest issue was that it was incorporated late into the planning cycle and I did not involve other Flock team members in the repository workflow. So, it was largely a tool that I used alone. I provided few and sparse updates until May on the various issues.

I did use AI-assisted workflows to help process meeting summaries and transcripts into issue updates. Our Flock 2026 organizer team was already using AI assistance for note-taking and generating transcripts from our regular video meetings. After Flock ended, I used a structured interview format with an AI agent to review all open issues in the Fedora Forge API, answer follow-up questions about their status, and create a record of what was accomplished and what remained.

While this tool was not directly useful to planning Flock 2026, it could be a useful starting point for other tools to analyze, plan, and suggest timelines for various Flock planning and execution work. The final goal in using the repository after Flock 2026 was to get unwritten institutional knowledge into a public issue tracker so it could be referenced in the future when we actually need to look back and remember what we did before and what lessons we learned.

Paperwork: Sponsor Contracts

It is the most boring thing ever, perhaps, but Red Hat Legal approved an updated Flock to Fedora sponsor contract. This is something that me and my colleague Shaun McCance have been working on for years, as part of the CentOS Connect and Flock to Fedora event planning. The challenge with our old sponsor contract was that it had requirements which did not actually make sense for Flock. For example, a sponsor had to provide a proof of insurance with a significant deductible for their event sponsorship. This is actually somewhat standard for corporate events where companies rent big, expensive exhibit booths. But Flock does not have, and never had, sponsor booths. Our community is always too immersed in the hallway track, and we encourage sponsors to send their reps to participate in the hallway track to get more out of their sponsorship.

While the insurance requirement was one of the most notorious challenges, especially for smaller companies and organizations, there were other changes made as well. I will not list them all, but the greatest advantage of this was the ability to bring back some past sponsors due to less corporate verbiage in the contract, and more community-friendly language. We did not add anything new to the contract; we only removed lots of content and sections. All in all, this made our contracts shorter, leaner, more aligned with the actual event we produce, and importantly, easier for other company’s legal teams to review, process, and sign.

We got these updated contracts in January, which was part of why we were delayed somewhat in our sponsor outreach. However, now that we have the updated contract, we can start earlier on the sponsor outreach since we will only have to get an approval next year on a contract update which mostly changes dates, years, and not much else.

Preventing token theft

Posted by Matthew Garrett ( Fedora Account System Username

mjg59 ) on 2026-07-02 02:23:45 UTC

When you log into a service you’re given an authentication token. Each further request to the site includes that token, allowing the server to figure out who you are and ensuring that you have access to your data. Depending on site policy, this token may either be stored in memory (and so vanish if you restart your browser) or disk. The token is the proof of your identity. As far as the site is concerned, anyone with your token is you. These tokens may be traditional browser cookies, but they may also be stored in either site local storage or (if you’re not using a browser) in some other storage location.

In recent years we’ve seen infostealer malware (like LummaC2) gain the ability to exfiltrate user tokens, allowing attackers to gain access to the user’s data without needing to retain access to the user’s machine. This attack is viable even if the site has strong MFA requirements, so passkeys don’t help. Encrypting the tokens on disk doesn’t prevent the malware from scraping them out of the browser’s RAM or obtaining whatever key is used to encrypt them. This feels like a pretty hard problem to solve.

But that hasn’t stopped people from trying! Dirk Balfanz wrote an IETF draft describing a mechanism for using self-signed certificates for TLS authentication. This uses the mutual authentication feature of the TLS protocol that requires both sides prove their identity to each other. In regular TLS, the remote site presents a signed certificate that tells you who it is. When performing mutual authentication, you then present a certificate to the remote site telling it who you are. These client certificates are largely unused outside enterprise environments because they’re a huge pain to deploy. It’s not so much that this has sharp edges, it’s that it’s entirely made of sharp edges. Managing certificate deployment to your devices is hard. Browsers get confused if the certificates change under them. You have one certificate and it lives forever, so sites you present it to can track your identity. Users are prompted to choose a certificate to authenticate with, and if they pick the wrong one everything breaks and is hard to recover. I’ve deployed this and I did not have a good time.

But Balfanz’s idea was simple. Rather than require certificates to be deployed, browsers would simply generate a certificate on the fly. The goal wasn’t to prove the device or user’s identity in any global way - but it would associate a TLS session with a specific certificate. You could then, for example, include a hash of the certificate in the cookie, and if someone tried to use that cookie without presenting that certificate then the cookie could be rejected. If the browser used a hardware-backed private key for the certificate then it would be impossible for an attacker to steal it. Sure, you could still steal cookies, but you wouldn’t be able to use them.

This was written almost 15 years ago, and seems simple, elegant, and functional. It didn’t happen. Part of the reason for that is that, well, it wasn’t quite so simple. One problem was privacy related. Cookies are only sent after the TLS session is established, so anyone monitoring the network doesn’t know anything about the user identity. A naive implementation of this approach would have meant the client certificate being sent before session establishment, and now user identity can be tracked (no longer an issue if this was implemented on top of TLS 1.3, but this was a log time ago). This was avoided by reordering the client handshake, but that meant having to modify the TLS specification and implementations would have to be updated to support this. Another was that figuring out the granularity of the certificates was difficult. You’d want to use different certificates for every site to avoid them effectively becoming tracking cookies, but you need to provide the certificate before cookies are set, and you don’t know what origin the site is going to set in its cookies. If you generate a certificate for a.example.com and a different one for b.example.com, and a.example.com sets a cookie for *.example.com and includes the certificate you used for a.example.com, that cookie isn’t going to work on b.example.com and things are broken. This meant supporting it wasn’t as straightforward as it seemed - you’d need to ensure that your cookie scope was compatible with the certificate scope. You could probably make this work well enough by aligning it with the Public Suffix List, but there was still some risk of expectations not being aligned.

And, perhaps most importantly, TLS session resumption (replaced by pre-shared keys in TLS 1.3) somewhat defeats the purpose of the exercise - clients store state that allows them to re-establish a TLS connection without performing certificate exchange (this reduces overhead if a connection gets interrupted or you switch to a new network or anything along those lines), and anyone in a position to steal cookies could steal that state as well.

The followup attempt was channel IDs. This simplified the implementation somewhat - rather than certificates, a raw public key would be sent, along with proof of possession of the private key in the form of a signature over a portion of the TLS handshake. This was required even in the event of session resumption, which avoided having to worry about theft of session secrets. The timing of the exchange was after the encrypted session had been established, so user identity couldn’t be leaked that way either. Cookies could then be bound to this identifier. Unfortunately it didn’t really deal with the problem of scoping keys in a way that would match cookie requirements, and the spec suggests that the right way of handling this is to scope keys to TLDs, which would enable user tracking across sites (Chrome’s implementation apparently restricted it to eTLD+1, which would match the third party cookie policy and avoid the tracking risk).

Chrome added support for this, but it was removed in early 2018. The discussion of some of the pain points in that message is interesting, explicitly calling out problems with connection coalescing across domains and the incompatibility with zero-RTT TLS1.3. The overall consensus at the time seems to be that trying to solve this entirely at the TLS layer has too many rough edges, and a different approach should be taken.

And so almost 7 years after the initial draft for origin bound certificates, we come to token binding. This ended up being a rather more complex endeavour, covering 3 different RFCs describing how it impacts TLS, how to incorporate it into HTTP, and how to manage all the various parties involved in the process. The short version is that it’s pretty similar to channel ID, except that there’s also a documented mechanism for allowing tokens to be bound to one party and consumed by another, avoiding any need for widely scoped keys. Token binding effectively solved all the issues in the original proposal, but at the cost of somewhat more complexity.

The RFC was finalised in October 2018. Chrome removed its (incomplete, draft) support for token binding in November 2018. Edge carried support until late 2024. Despite getting all the way through the RFC process, it’s functionally dead.

The process up until this point had been largely initiated by Google, with Microsoft contributing significantly to the token binding standards. The work had been focused on identifying a generic solution to the problem rather than tying it to any specific authentication flow. The next step was in a different direction - rather than trying to fix this for the entire internet, how about we try to fix it for OAuth?

RFC 8705 is titled “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”. This is basically the 2011 approach, but (a) with an explicit definition of how the certificate should be incorporated into issued auth cookies, and (b) with a proviso that well uh if you’re going to use tokens issued by your IdP to authenticate to someone else then well you’re going to need to use the same cert for both. This is probably fine for the company-owned-laptop case where you’re actually fine with multiple sites being able to tie identities together (that’s kind of the point here!), and also works for “I am using an app and not a browser”, but doesn’t work for more generic scenarios. It also doesn’t seem to take the session resumption case into account at all? Support for RFC8705 seems poor, as far as I can tell of the big players only Auth0 implements it. In theory it works fine with self-signed client certs but in reality that’s going to be almost as difficult to support across multiple platforms as just issuing proper client certs in the first place, so deployment is going to be kind of a pain. But the good news is it doesn’t rely on any TLS extensions or custom browser behaviour, so at the client side it works fine with any browser.

Which brings us on to RFC 9449, “Demonstrating Proof of Possession”. This goes even further than RFC8705 in terms of reducing the burden of deployment - it works fine with existing browsers, and it doesn’t even require any certs. The client generates a keypair and provides the pubkey when requesting the cookie. The cookie contains the pubkey. Every request to the service now provides the cookie with the pubkey and also provides a signature over the URI and HTTP method. If the signature matches the pubkey in the token then clearly the signature came from the machine the token was issued to, and everything is good.

This does come with some downsides, though. The first is that it uses browser interfaces to generate the keys (typically crypto.subtle.generatekey()) and as far as I can tell there are no browsers that guarantee that that key is going to be generated in hardware even if it’s marked non-exportable, so anyone able to steal the cookies can also steal the keys. The second is that the signature only covers the URI and HTTP method, and not the message content or any other headers, so anyone able to exfiltrate a valid signature can replay it against the same URI with different message content. The recommended way to handle this is to reject any signatures that weren’t generated within the last few seconds, which is a wonderful additional way to allow clock skew to give you a Bad Day. And the third is that every single request has to be separately signed, which is not intrinsically a problem because computers are fast and have multiple cores, but if you’re trying to solve the first problem by sticking the key in a TPM then you’re dealing with something that’s slow and single threaded and that’s maybe acceptable if you’re using client certificates (because there’s going to be one signature per session and you can use the same session for multiple requests) but probably not if you’re dealing with a user opening a browser that restores previous tabs and each of those is a webapp that fires off 100 requests in parallel.

In case it wasn’t clear, I don’t like DPoP. It doesn’t feel like it actually solves the underlying problem that we see in the real world (malware running in a context where if it can grab the tokens it can grab the keys), it adds a massive amount of overhead, and it has baked in replay vulnerabilities. I don’t know why it exists and I’m incredibly suspicious of vendors telling me that it fixes my problems, because if they’re telling me that then I’m going to end up assuming that they either don’t understand my problems or they don’t understand their technology, and neither of those is good.

Still. Then we get to the thing that prompted me to write this - Chrome’s announcement that they had launched device-bound session credentials. This is interesting because it’s a Chrome feature that’s explicitly intended to counter on-device malware, which was one of the things that was out of scope in 2018 when token binding was being removed. Since this is entire web level it doesn’t have to be an RFC, and so is instead defined by W3C. I’m going to handwave all the complexity and say that it’s basically a way to register a public key when a cookie is issued, and then prove possession of the private key when it’s time to renew the cookie. By making the cookies shortlived and having support for rotating them in the background, user impact is basically zero and while it’s still possible for an attacker to exfiltrate and use a cookie they’ll only be able to do so for a short window before it needs to be refreshed - something the attacker can’t do, since they don’t have the private key. This avoids the DPoP overhead because you only need to do signing once per cookie per cookie lifetime, and not on every single request. I don’t like this due to the window where exfiltrated tokens can be used, but it feels like a strict improvement over the status quo. An extension called device-bound session credentials for enterprise allows pre-enrollment of device keys, so even though the actual runtime DBCE flow doesn’t involve certificates, certificates can be used for device registration in enterprise environments and you can make sure that auth cookies only go to trusted devices. Unfortunately this is Chrome-only, and so we’re going to need to wait for it to be backported to all the random app frameworks for it to have widespread support on mobile or for almost everyone’s desktop app that’s actually three websites in an Electron wrapper. Mozilla’s current position is that they’re not in favour of it, so I guess we’ll see where Safari lands in terms of broad uptake.

The last thing on my list is another client cert/OAuth binding, this one still in draft state at the time of writing. This one is aimed primarily at the use of agent-driven tooling, where you have something running in the background using a whole bunch of tools that are each acting on your behalf. Authenticating to all of them separately isn’t a fun time, but giving broadly scoped access tokens to a non-deterministic agent and trusting that it’ll never post them somewhere public also isn’t a fun time. The key distinction between it and RFC8705 is that it’s aimed at connections rather than sessions, which avoids the worries about session resumption. This is done with TLS Exporters, which in TLS 1.3 should be unique to the connection even over session resumption (TLS 1.2 may reuse some of the same key material for exporters over session resumption, so it’s recommended to enforce 1.3 for this). By providing a new signature alongside the cookie on every new connection, the client proves that it still has access to the private key. This is a very new spec and I haven’t had much time to work through it yet, but my naive understanding is that unlike RFC8705 this would require some additional client support to be able to regenerate the client signature on every TLS reconnection.

This doesn’t avoid all the problems that RFC8705 has, including how to scope certificates. For the agentic use case that probably doesn’t matter - all these tools are acting on behalf of the same user, it’s fine if all the sites involved know they’re the same user. But it doesn’t solve the general purpose user use case, and right now DBSC seems like the best we have there.

But. Part of me still wonders whether Dirk Balfanz’s approach was the right one. Yes, there’s risk associated with TLS session resumption, but in the worst case you could just switch that off for high risk setups. The cookie scope argument is real, and also in cases where it could violate privacy the site owner could already choose to broaden their cookie scope and violate your privacy, and in cases where it breaks things you could just not make use of it. The other problems are largely fixed by TLS 1.3, and then we’re just left with “Browsers handle client certificates badly” to which my answer is “Yes, and we should fix that anyway”.

Despite having a pretty good answer to this solution over a decade ago, the closest we have to actual deployment is something that offers strictly worse security guarantees. And tokens keep getting stolen, and compromises keep occurring, and for the most part people shrug and get on with things.

O nome da capital da Noruega

Posted by Avi Alkalay ( Fedora Account System Username

aviram ) on 2026-07-01 11:29:29 UTC

Mais um nome de lugar que, em português, falamos errado porque herdamos uma grafia estrangeira.

Kristiania era o nome desta cidade de 1624 a 1925 porque o rei dinamarquês Cristiano IV queria se auto-homenagear quando a reconstruiu após um grande incêndio. 20 anos após a Noruega conquistar sua independência da Suécia, o parlamento decidiu voltar ao seu gracioso, simples, elegante e também imponente nome original medieval.

A forma sonora como os noruegueses chamam sua capital é:

ÚSSLU

Alguns sotaques regionais também falam:

ÚSHLU

Contaram-me também que em certas rodas mais “frescas” se fala também:

ÚSSLO

Então, da mesma forma que achamos estranho quando estrangeiros falam, erradamente, “braçill” ao invés de “brazil”, também deveria ser considerado estranho quando falamos “ózlo”.

Agora que sei disso, devo continuar falando “ózlo” ou o correto “ússlu”? Há quem diga que se eu ficar só no “ússlu” vão me achar um fresco e exibido. Então acho que vou ficar variando. No mínimo para gerar conversas curiosas em festas.

Flock to Fedora 2026: What Happened

Posted by Justin Wheeler ( Fedora Account System Username

jflory7 ) on 2026-06-30 08:00:00 UTC

In the blink of an eye, it was over almost as quickly as it began. But the three days at the annual Flock to Fedora conference from 14–16 June 2026 in Prague, Czechia were packed with the kind of engagement that keeps the Fedora community going. Flock to Fedora, or often simply referred to as Flock, is the flagship contributor community event for the Fedora community. Flock is a place where the "doers" of our community gather annually to share our work, discuss ongoing collaborations, and shape the future of our next year ahead. Ultimately, it is one of my favorite parts of the Fedora Project. Being one of the lead organizers is one of the greatest privileges of serving in the Fedora Community Architect role at Red Hat.

This blog post is my attempt to capture the highlights of Flock 2026 while they are fresh in mind. The Linux and open source media already began their coverage. So, I thought this was a good moment to share my perspective on the event. This was my ninth Flock that I have attended and the fourth Flock where I played a leading role as an organizer.

Note	This is the first post in a three-part series on Flock to Fedora 2026. The second post covers how Flock gets organized behind the scenes. The third post shares my personal reflections on organizing Flock as Fedora Community Architect.

The Hallway Track

I often tell people that the 45 days before Flock are some of the most stressful days of my entire year. But all four times I have done this, once I actually arrive at Flock and the conference gets going, the stress melts away. I am still running around a lot, taking care of this or that, but the important things always come together. Our speakers deliver great content, people reconnect after a long time of not seeing someone, and the hallway track is constantly lively. This year was no exception. I was pleasantly pleased to see and hear the community vibe which is essential to Flock was once again re-created.

Both my lived experience from nine years of Flock and the post-event data since we began collecting it in 2024 tells us one thing, absolutely. One of the most-valued parts of the Flock to Fedora experience is what is commonly known as "hallway track." If this is a new term to you, it is not too hard to understand. It plays on the idea that while there are usually tracks of speaker programming and content at a conference, there is also an unspoken track on the schedule. This "hallway track" is the informal conversations that take place outside of the speaker halls. They happen organically and they are usually unscripted. In-person attendees of Flock have been telling us for years that the "hallway track" at Flock is a critical, spotlight part of what makes the event worth attending.

A group selfie of several individuals wearing blue Flock to Fedora conference lanyards gathered around a long dining table in a room with large glass windows. A handwritten sign reading "Development" sits on the table among plates and glasses as the group poses for the camera held by a man in the foreground.

Figure 1. A group selfie of people wearing blue Flock to Fedora conference lanyards seated at a dining table featuring a handwritten "Development" sign.

So, while it appears the Fedora community has vast opinions about Flock, what it is, and what it is supposed to be, we all seem to agree on one thing. Getting the face-time to speak with other Fedora contributors is invaluable and drives critical engagement that keeps people in our community. I genuinely think without Flock to bring our core contributor community together once a year, we might all be burnt-out, exhausted, and tired from the online engagement we have been doing for more than 23 years. The in-person time is where the Fedora Friends Foundation comes out on full display. The hallway track is where people can go from colleagues to friends. When we talk about building trust in a community, it is experiences like the Flock to Fedora hallway track that turn trust-building from a concept to a concrete, practical thing.

"Generational Switchover" and Packager Data Trends

One of the most poignant parts of Flock 2026 came in the "State of Fedora" keynote delivered by the Fedora Project Leader, Jef Spaleta. Several thoughts were put forward, but what clearly generated buzz was a graph produced by Michael Winters from the Fedora Data Working Group.

A line graph titled "Year-over-Year Package Committers by Month." The x-axis tracks the month from 1 to 12. The y-axis measures unique Fedora package committers from 320 to 460. The graph plots data and dashed trend lines for three distinct years: 2020 in blue with a trend slope of -1.90, remaining mostly above 420; 2023 in orange with a steeper trend slope of -6.02, steadily declining from roughly 410 to 335; and 2026 in green, which only includes data for months 1 through 4, starting at 350 and dropping to 325 with the steepest trend slope of -8.70.

Figure 2. A line graph titled "Year-over-Year Package Committers by Month" showing a downward trend in the number of unique Fedora package committers across the years 2020, 2023, and early 2026.

Michael single-handedly developed user-level access to the wealth of packaging data we have been working to analyze, and the result was a striking visualization of the number of unique package committers in Fedora over a six-year span. The graph shows what seems to be a significant decline of the number of unique packagers actually working in Fedora Linux over a six-year span. The data appears to indicate a sharp decline in the number of unique packagers in 2026 so far versus the unique packagers in 2020 and 2023. It is a graph that is certainly concerning.

Jef put forward theories of what he thought the data could be indicating. At one point, he mentioned the idea of generational switchover, and that one era is ending and a new one is beginning. In the session following his keynote, the Fedora Council Q&A, this topic of generational switchover came up even more. Obviously, people felt concerned or triggered in some sort of way by this data. While the Fedora Council originally planned for the panel to focus more on a "what/how" conversation, we ended up having more of a "why" conversation with attendees.

It was a comment made by Aleksandra Fedorova which really stuck with me. At one point, she and I had touched on a shared experience for an in-person F41 Release Party in Potsdam, Germany. The interesting part of this was the unique intersection of both the local organizer, René Kuhn, and newcomer, junior students from the university (i.e., where the event was held) and old-timer, experienced contributors like myself and Aleksandra. Aleksandra mentioned that her experience at this F41 Release Party reminded her that the young people and students of today were just like many of us with several years behind us were when we began in Free Software and Open Source. She said that it was not actually young people who were changing, but us, the people who had been here for years, who have changed. We are no longer the same young people we were. We are more experienced, more exhausted, perhaps more burnt-out, than we were in our own youth and entry to the Free Software movement. I encourage you to watch the full panel discussion once it is available, but this is a thought that is sticking with me after Flock ended.

Record-Breaking Sponsor Engagement

We had a record-breaking level of engagement on the sponsor side of Flock 2026. We raised more sponsorship funding from a larger number of unique sponsors than we have received in years. This milestone shows us a couple of things:

We have a diverse group of engaged sponsors, mostly from downstream products and companies, which care about the sustainability and well-being of Fedora.
We are growing the amount of sponsorship for Flock to Fedora, which can enable us to think on a bigger, grander scale for future editions.
Our processes are getting better at selling Flock sponsor packages, and processing contracts, purchase orders, and invoices.

The sponsorship side of Flock really became more critical after the COVID-19 pandemic, when we returned to Flock to Fedora after a few years of Nest with Fedora virtual conferences. I remember as an attendee from 2015 to 2019 that while there were other sponsors, it was obviously Red Hat who was the most engaged, the most committed, and the one footing most of the actual costs. To be honest, this is still true today. However, the pool of engaged sponsors is diversifying. We have more commercial downstreams from Fedora Linux than we have ever had at any point in our history. To me, this represents healthy growth, even if it does raise more questions about how to sustain that growth and balance the increasing interest in Fedora Linux in a fair and equitable way.

Everyone tries to influence the direction of a project they care about. That is simply how communities work. What matters is whether the processes for exerting that influence are fair, equitable, and open to everyone. In Fedora, they are. Our sponsors do not buy influence in Fedora Linux. What is impressive about most of our Flock sponsors is that there are often coordinated groups of paid engineers and contributors from these companies who show up to do real, actual work in the Fedora community. They submit Fedora Changes, get them reviewed by FESCo, and integrated into Fedora Linux — the same process available to anyone. Our hardware vendor sponsors can also participate in initiatives like Fedora Ready, to provide greater assurance and information for Linux consumers to purchase hardware which has a guaranteed quality experience with Fedora Linux. Our sponsors are not complacent and they do not rely on financial sponsorship to get them special favors. If they want something done, they show up and do the work themselves, together with the input and participation of the rest of the community.

A special thank-you to the individual folks at our various sponsoring organizations who raise the Fedora Project flag in their teams, departments, and entire organization. Without you, these special, collaborative relationships we have would not be possible.

Fill Out the Flock 2026 Post-Event Survey!

If you are reading this blog post, attended Flock in-person or virtually, and it is before 8 July 2026, stop everything you are doing. Go and complete the Flock 2026 post-event survey right now. This is only because it is the most important part of the entire future Flock planning process. As one of the people with access to the data and also involved with the planning for future Flock editions, nothing else matters more than this. While I am always listening to what people have to say in the hallway or making my own observations at the conference, the survey gives us real data to understand what people think and feel about Flock to Fedora. I always read every single comment and response in the survey. It matters to the entire Flock organizing team that we build an event that reflects the desires and wishes of our community.

The survey is open to both in-person and virtual attendees. We know that the Fedora community is global and spread out all over the world. We also know that travel is not necessarily an equitable act; not everyone can afford to travel, or even is physically able to travel. Therefore, we invite everyone who considers themselves a part of the Fedora community and participating with Flock to share their opinions.

After all, if we only sent our survey to our in-person European conference attendees, it seems quite likely that we will keep hearing about how Europe is the best location for Flock. So, even our virtual attendees and people who could not travel in-person to Flock 2026 can share their feedback and voice to help us make a better and more inclusive Flock in the next editions.

A DNS Record That Existed Everywhere Except CI

Posted by Miroslav Vadkerti ( Fedora Account System Username

mvadkert ) on 2026-06-30 00:00:00 UTC

A flaky CI failure where a freshly-created DNS record was unresolvable from inside the cluster, but resolved fine from my laptop a few minutes later. The culprit was negative DNS caching, driven by the zone’s SOA, poisoning lookups for our ephemeral per-job records.

My Halfway Journey as an AI/ML Engineering Outreachy intern at the Fedora Project: building toward…

Posted by Francois Gonothi Toure ( Fedora Account System Username

gtfrans2re ) on 2026-06-29 20:08:29 UTC

My Halfway Journey as an AI/ML Engineering Outreachy intern at the Fedora Project: building toward a tool for 30 years of RPM Packaging guidelines

Image promptly created with Google Gemini’s Nano Banana

From May 18, 2026, to the present, I have been deep-diving into the Fedora Project as an Outreachy and Software Freedom Conservancy intern, working on an AI/ML project that will ultimately help Fedora’s RPM packagers navigate the 30-year history of RPM packaging guidelines.

Fedora is now a community that I call family, and every Fedoran I have encountered has been incredibly helpful and supportive in ways I can hardly put into words. From my esteemed mentors, Carol Chen, Dominik Kawka, and Justin Wheeler (one of the Fedora Project maintainers), to the members of the AI/ML Special Interest Group and the Fedora Infrastructure Team, and everyone else I have had the chance to learn from since the beginning of my internship, I have loved every moment of it and intend to be a lifelong contributor to the Fedora Project.

So what have I done and contributed so far?

Even before the internship officially began, I had the chance to interact with and get support from my mentors as part of my preparation. During this time, I continued deepening my knowledge of RamaLama and RamaLama RAG that I had started building during the contribution phase. In doing so, I explored and documented the document-processing and retrieval-pipeline architecture, converting both single PDF files and entire directories of PDF files, and tested custom GPU and graphics accelerators to get everything running.

I also explored running OpenAI’s GPT-OSS with RamaLama. In parallel, I got started with RPM packaging by familiarizing myself with the RPM package management system and even simulating my own implementation of RPM-based systems. With my mentors’ support, I successfully ran and tested the RamaLama Sandbox-Goose, tinkering with several examples and building and deploying agentic AI systems with it for my own projects. If you would like to learn more about this preparatory work, you can find it here: https://github.com/gtfrans2re/fedora-summer-ml-prep-2026

As for my contributions since the internship began, I really cannot take the credit alone; this work is made possible by mentors who pour a great deal of effort and time into creating and following up on the issues I work on.

Here are the issues I have been working on as part of my contributions so far:

[Gonothi] Identify and scope a RAG mini-project candidate (#145): Together with my mentors, we proposed and scoped a small-scale RAG mini-project using RamaLama to test retrieval workflows before tackling the full Fedora RPM Packaging Guidelines. The outcome was a selected, well-scoped mini-project candidate that let me begin RAG pipeline testing with RamaLama in Sprint 6.
[Gonothi]: RAG Mini-Project — enhance a model with Fedora Magazine Blog Article Guidelines (#146): This issue involved enhancing a model using RamaLama RAG on the Fedora Magazine and Community Blog writing guidelines and past published articles, to help reviewers evaluate draft submissions. The result is a working RAG prototype that validates the pipeline before tackling the full RPM documentation.
[Gonothi]: Welcome and onboarding (#148): I completed onboarding tasks and connected with key people across Fedora, which helped me get to know the project and community and strengthened the foundation for my Outreachy work.
[Gonothi]: RAG Mini-Project — explore deploying on Quay.io (#149): For the OCI images created via the RamaLama RAG pipeline in #146, I made them publicly available on Quay.io (https://quay.io/user/gtfrans2re/) for distribution, ensuring the RAG images are accessible to other users.
[Gonothi] Familiarize more with AI/ML SIG, and Packaging process (#150): This ongoing issue (due July 6, 2026) is helping me get better acquainted with the teams and processes that will support the main internship project.
[Gonothi] Identify 3–5 relevant A-level scientific conferences or journals (#151): Under my mentors’ guidance, I scouted potential conferences and journals where the final work from this internship could be published or presented. The outcome was a shortlist of suitable venues.
[Gonothi] Evaluating RAG systems and other tools (#154): This issue had me explore tools that help with RAG evaluation, model selection, CPU/GPU usage profiling, and scaling ML workloads, to understand each tool’s value and integrate those that can benefit my project.
[Gonothi] Request to join the fi-apprentice group (#13393): On my mentors’ recommendation, I requested membership in the fi-apprentice group to gain read-only access to Fedora infrastructure machines, so I can learn the setup and find areas to contribute. Joining as an apprentice is an interim step to familiarize myself with the infrastructure (including bastion access) while dedicated GPU/server resources are being provisioned for the project.

Highlights of what I have learned from other interns, my mentors, and my community:

So far, I have connected with several other interns over the Outreachy Zulip chat platform and with some of them on LinkedIn. It is always great to read about their experiences during the monthly Outreachy chats, and over the past two chats, I have been genuinely inspired by their journeys and portfolios.

As for my mentors, from day one, they made me feel as though we had known each other for years. They are kind, open-minded, and incredibly generous in sharing learning resources to help me prepare for the work ahead. I have learned to use Replicate API tokens to run AI models from Google Colab and from Python. Carol Chen even generously shared an API token with me so I could test this out. My mentors also pointed me to resources for exploring and testing open-source LLMs for building and deploying AI and agentic AI systems locally and showed me how to use RamaLama Sandbox-Goose to ship an AI agent locally before deployment. They introduced me to tools like llmfit for fitting models on a local machine with efficient CPU and GPU memory management. And, as they suggested, I worked through several RPM packaging examples to understand the overall process and how AI and ML might help speed it up.

One thing my mentors did that meant a great deal to me was helping me find the resources to join the Linux meetup community in Montréal and Québec, a network of Linux and open-source users in my region, so I could attend meetups and keep learning alongside like-minded people. This also led me to the Red Hatters in Canada group, through which I was invited to Red Hat Tech Day in Montréal on June 11, where I got to learn about and use Red Hat AI and Red Hat OpenShift AI to build and secure AI and agentic AI systems in Red Hat Enterprise Linux cloud environments.

As for the wider community, I have joined and am getting acquainted with the Fedora AI/ML Special Interest Group (SIG), where I interact with group members, as well as the Fedora Infrastructure Team through the fi-apprentice program. I will also be attending Flock to Fedora, Fedora’s annual contributor conference, held this year, June 14–16, in Prague, virtually, to meet more Fedorans and learn about the technology we all build on. Beyond that, I have connected with many Fedorans to learn more about what they do, including Aoife Moloney from the Fedora Operations Architect team, Jona Azizaj from the Fedora EDIA team, and Madeline Peck from the Fedora Design Team.

What I am most proud of building so far:

The contribution I am most proud of is the mini-project at the heart of my work so far: an AI-powered editorial assistant for the Fedora Community Blog and Fedora Magazine, built with RamaLama RAG. It is a deliberately smaller, well-scoped problem chosen as the foundation for the larger RPM Packaging Guidelines project to come, a way to prove out the entire RAG pipeline end-to-end on a manageable corpus before tackling 30 years of packaging documentation.

The tool helps new authors and reviewers check whether a draft article meets Fedora’s editorial standards before submission. It flags missing required elements, such as a featured image or the “Read More” tag, and checks tone, structure, technical accuracy, and topic scope against the publications’ own writing guidelines and past published articles.

Building it taught me how the whole pipeline fits together in practice:

Preparing the data: I fetch articles from both publications via the WordPress REST API and let RamaLama RAG ingest the HTML directly. A key lesson from my mentors here was that RamaLama already uses Docling internally to convert documents into a structure-aware representation optimized for retrieval, so feeding it the original HTML preserves more meaning than pre-flattening everything to plain text or Markdown.
Building the vector stores: Using the ramalama rag command, I build OCI images for the Community Blog, the Magazine, and a combined corpus, and publish them on Quay.io so others can pull and run the tool without rebuilding anything from scratch.
Choosing and testing models: I benchmarked several open-weight models and, with my mentors’ input, narrowed the local lineup to the newer, more efficient Gemma 4 and Granite 4, a reminder that on constrained hardware, model generation and efficiency matter as much as raw size.
Making it usable: I built a Streamlit interface where an author can paste a draft and get instant editorial feedback, and I documented a full local development guide plus a quickstart so anyone can run the tool on their own machine.

What I am proudest of is not any single component but the fact that it works as a complete, reproducible, fully open-source pipeline (Apache 2.0) running entirely on local, open-weight tooling, no proprietary services required. You can find the project here:https://forge.fedoraproject.org/ai-ml/editorial-guide-ramalama

I presented this tool to Michal Konečný from the Community Blog editorial team and pitched it to the Fedora Magazine editors, and the encouraging early feedback has been one of the most rewarding parts of the internship so far.

Adjustments to scope, timeline, and tasks:

The overall arc of the internship remains the same: the mini-project is the proving ground for the main project on the Fedora RPM Packaging Guidelines. A few refinements have happened along the way, all of them improvements rather than changes of direction.

On scope, we expanded the mini-project from the Community Blog alone to include Fedora Magazine, since the pipeline generalized well to both. On the technical side, guided by my mentors, I removed a redundant manual ingestion step once we confirmed that RamaLama already handles document conversion and chunking internally, and I narrowed the model lineup to Gemma 4 and Granite 4 for efficiency on local hardware. The one external constraint has been computed: running the heavier models locally pushes my current machine to its limits, and dedicated GPU/server resources are being provisioned to unblock that, which is also why I am getting acquainted with Fedora’s infrastructure through the apprentice program in the meantime.

As I move into the second half of the internship, the focus shifts toward applying everything I have learned from this mini-project to the much larger and more ambitious main project: building a RAG-powered tool for three decades of Fedora RPM packaging guidelines. I could not be more excited for what is ahead.

Regards,
Gonothi

Loadouts For Genshin Impact v0.1.17 Released

Posted by Akashdeep Dhar ( Fedora Account System Username

t0xic0der ) on 2026-06-29 18:30:00 UTC

Loadouts For Genshin Impact v0.1.17 Released

Hello travelers!

Loadouts for Genshin Impact v0.1.17 is OUT NOW with the addition of support for recently released artifacts like Celestial Gift and Disenchantment in Deep Shadow, recently released characters like Nicole, Lohen and Prune and for recently released weapons like Angelos' Heptades and Disaster and Remorse from Genshin Impact Luna VII or v6.6 Phase 2. Take this FREE and OPEN SOURCE application for a spin using the links below to manage the custom equipment of artifacts and weapons for the playable characters.

Resources

Installation

Besides its availability as a repository package on PyPI and as an archived binary on PyInstaller, Loadouts for Genshin Impact is now available as an installable package on Fedora Linux. Travelers using Fedora Linux 42 and above can install the package on their operating system by executing the following command.

$ sudo dnf install gi-loadouts --assumeyes --setopt=install_weak_deps=False

Installation command for Fedora Linux

Changelog

Replace native compilation with integrated building by @gridhead in #544
Automated dependency updates for GI Loadouts by @renovate[bot] in #545
Automated dependency updates for GI Loadouts by @renovate[bot] in #547
Remove unused class variable by @sdglitched in #550
Fix incorrect type hint for refi_stat by @sdglitched in #551
Update dependency nuitka to >=2.0.0,<5.0.0 by @renovate[bot] in #552
Trigger test workflow on pull_request by @sdglitched in #559
Add the recently added artifact set Celestial Gift to the GI Loadouts roster by @sdglitched in #557
Add the recently added character Prune to the GI Loadouts roster by @sdglitched in #556
Automated dependency updates for GI Loadouts by @renovate[bot] in #553
Introduce the recently added weapon Angelos' Heptades by @gridhead in #560
Automated dependency updates for GI Loadouts by @renovate[bot] in #563
Introduce the recently added character Nicole to the roster by @Ank-22 in #565
Introduce the recently added artifacts Disenchantment in Deep Shadow by @gridhead in #561
Introduce the recently added character Lohen to the roster by @gridhead in #562
Introduce the recently added weapon Disaster and Remorse by @Ank-22 in #568
Update actions/checkout action to v7 by @renovate[bot] in #567
Stage the release v0.1.17 for Genshin Impact Luna VII (v6.6 Phase 2) by @sdglitched in #574

Artifacts

Two artifacts have debuted in this version release.

Celestial Gift

Bonus for Two Piece Equipment
Energy Recharge + 20%.
Bonus for Four Piece Equipment
If the equipping character has completed Witch's Homework, after they use an Elemental Skill, they also gain "Light's Guidance" for 20s: All nearby party members gain a 20% Elemental DMG Bonus corresponding to the equipping character's Elemental Type. The equipping character can trigger this effect while off-field. DMG Bonuses provided by Artifact Sets with the same name do not stack.
When your party has the Hexerei: Secret Rite effect, Light's Guidance is upgraded to "Mortal Hymn": All nearby party members gain a 40% Elemental DMG Bonus corresponding to both the equipping character and the current active party member's Elemental Type instead. If both characters have the same Elemental Type, these bonuses will not stack.

Disenchantment in Deep Shadow

Bonus for Two Piece Equipment
ATK +18%.
Bonus for Four Piece Equipment
Increases Superconduct Reaction DMG by 80%. When the wielder attacks opponents affected by Superconduct, this attack's CRIT Rate is increased by 16%. An all-new blessing may be obtained as you make your way toward Snezhnaya...

Characters

Three characters have debuted in this version release.

Nicole

Nicole is a catalyst-wielding Pyro character of five-star quality.

Lohen

Lohen is a polearm-wielding Cryo character of five-star quality.

Prune

Prune is a catalyst-wielding Anemo character of five-star quality.

Weapons added

Two weapons have debuted in this version release.

Angelos' Heptades

Crown of the Final Scion - Scales on ATK %.

Disaster and Remorse

Dolorous Stroke - Scales on Crit Rate.

Appeal

While allowing you to experiment with various builds and share them for later, Loadouts for Genshin Impact lets you take calculated risks by showing you the potential of your characters with certain artifacts and weapons equipped that you might not even own. Loadouts for Genshin Impact has been and always will be a free and open source software project, and we are committed to delivering a quality experience with every release we make.

Disclaimer

With an extensive suite of over 1580 diverse functionality tests and impeccable 100% source code coverage, we proudly invite auditors and analysts from MiHoYo and other organizations to review our free and open source codebase. This thorough transparency underscores our unwavering commitment to maintaining the fairness and integrity of the game.

The users of this ecosystem application can have complete confidence that their accounts are safe from warnings, suspensions or terminations when using this project. The ecosystem application ensures complete compliance with the terms of services and the regulations regarding third-party software established by MiHoYo for Genshin Impact.

All rights to Genshin Impact assets used in this project are reserved by miHoYo Ltd. and Cognosphere Pte., Ltd. Other properties belong to their respective owners.

Your _get_type() function is not G_GNUC_CONST: Part Two

Posted by Michael Catanzaro ( Fedora Account System Username

catanzaro ) on 2026-06-29 15:32:49 UTC

This blog post is a sequel to Your _get_type() function is not G_GNUC_CONST.

GNOME developers have long used G_GNUC_CONST, which expands to __attribute__((const)), to annotate GObject _get_type() functions, despite knowing that it is incorrect to do so. const functions by definition have no side effects, but _get_type() functions actually have a side effect the first time the function is called: they initialize the type. Why apply an incorrect annotation to these functions? Because it makes the code faster.

Although this was long known to be incorrect, it worked fine in practice… until now. Regrettably, Sam James has discovered that GCC 16 may optimize away the type initialization, resulting in crashes. This is our fault for providing the compiler with wrong information about our code, so it’s time to audit your use of const attributes to remove them from _get_type() functions. Most GNOME programs use these attributes only for _get_type() functions, but if you use it in more places, then check to make sure those functions are actually const, as defined by the GCC documentation.

Sadly, there is no suitable replacement attribute for _get_type() functions. Two decades ago, Behdad requested a new idempotent attribute for expressing the desired semantics, but nobody has implemented it.

From June 22 to June 28

Posted by Aurélien Bompard ( Fedora Account System Username

abompard ) on 2026-06-28 23:14:00 UTC

Across the Fedora project, teams are heavily focused on preparing for the upcoming Fedora 45 release, with groups including Quality, Workstation, Server, Cloud, and CoreOS actively coordinating system-wide changes, mass rebuilds, and issuing calls for F45 Test Day proposals. Simultaneously, a massive infrastructure transition is underway as Infrastructure, Release Engineering, Mindshare, and IoT urgently migrate repositories, issue trackers, and automated workflows from the sunsetting Pagure platform to the new Fedora Forge (Forgejo). Security and policy enforcement also dominate current efforts, highlighted by the newly enacted Two-Factor Authentication (2FA) mandate for provenpackager members, ongoing discussions around cryptographic library management, and extensive CVE patching within EPEL. Finally, improving the contributor experience remains a central priority, with the Docs and Design teams actively modernizing onboarding materials, while groups like Mindshare and Ambassadors recruit volunteers to support community engagement and upcoming global events.

Announcements

For Fedora contributors, there are several important infrastructure and policy updates to be aware of this week. FESCo now requires two-factor authentication for all provenpackager members, with a grace period extending to September 24, 2026, before non-compliant accounts are temporarily downgraded. Additionally, history has been rewritten for 71 package git repositories to fix long-standing git fsck issues; contributors with existing checkouts of these specific repos will need to perform fresh clones. A planned one-hour outage occurred on June 25th, temporarily affecting download-ib01, torrent, and fedorapeople services. In ecosystem news, discussions are ongoing regarding the future of Pagure.io and the transition to Forgejo, while Fedora Documentation translations are once again available following their successful migration to the new Fedora Forge. Finally, the F44 Election Results have been announced, officially seating new members for the Council, FESCo, Mindshare, and the EPEL Steering Committee.

In news relevant to the broader Linux community, Fedora has addressed the upcoming expiration of Microsoft's UEFI Secure Boot keys. Existing machines will continue to boot normally without panic, and Fedora Rawhide (f45) already includes a first-stage boot loader signed with multiple keys to ensure maximum compatibility moving forward. On the community front, Fedora was heavily represented at the XV P.I.W.O. Poznań Free Software Fest in Poland, which saw record attendance and hosted the historical signing of the SPOIWO declaration—a new coalition advocating for digital sovereignty and open-source software in public institutions.

Council

The Council discussed the Draft Council Proposal for the Fedora Innovation Lifecycle, a framework designed to handle experimental, large-scale projects that are too complex for the standard ChangeProposal process. The proposed lifecycle introduces Sandbox, Curation, and Integration stages to help solve the "innovator's dilemma" by nurturing big ideas within the project boundary. While some participants questioned if existing tools like Copr and the current Changes Process could simply be improved, proponents argued that a dedicated Sandbox is necessary for massive, interlocking changes to prove their viability without being hindered by strict technical policies early on. This structured pathway aims to foster innovation and sustainable contributor engagement for strategic initiatives, such as the ongoing RISC-V architecture bring-up, which currently has to operate outside the project as a remix.

Learn more about the Council team.

FESCo

FESCo welcomed new members following the F44 elections and opened nominations for the Fedora Council Engineering Representative. A major security policy update was announced, requiring all provenpackager group members to enable Two-Factor Authentication (2FA) by September 24, 2026, with discussions underway to potentially expand this requirement to all packagers. Additionally, FESCo approved several system-wide changes for Fedora 45, including updates to RPM 6.1, Golang 1.27, Erlang 27, and the adoption of PURL Metadata. New F45 Change Proposals were also introduced for community feedback, such as a minimal GRUB EFI build for Confidential Computing and offering the Lazarus IDE with multiple widgetsets.

The committee is actively seeking input on managing binary executable content in node_modules and whether to drop the signoff requirement from the defunct Fedora crypto team for new cryptography libraries. Contributors are also invited to discuss the upcoming Forgejo distgit migration and a proposal to allow draft builds for ELN rebuild batches. To streamline issue tracking, FESCo is migrating its public issues to the new forge, archiving private issues, and temporarily opening its mailing list to non-subscribers for sensitive reports.

Decisions

Two-factor authentication is now required for the provenpackager group, with a 3-month grace period before enforcement.
FESCo public issues will be migrated to the new forge, while private issues will be archived in a separate repo. The FESCo mailing list will temporarily accept emails from non-subscribers for private reports.
The Fedora Operations Architect was added as a sponsor for the "fesco" FAS group and as a mailing list admin.
Approved F45 System-Wide Changes: Adopt PURL Metadata, Erlang 27, RPM 6.1, Golang 1.27, and Versioned libgit2 packages.
Added containerd, moby-engine, rootlesskit, and docker-distribution to the Update Policy Exception List.

Learn more about the FESCo team.

Packaging Committee

During the Packaging Committee meeting, members addressed several guideline updates and packaging challenges. The committee reviewed FPC#1551 regarding versioned packages and agreed to remove the strict guideline stating they "MUST NOT conflict with all other versions," noting that general conflict guidelines are sufficient and development subpackages often unavoidably conflict. The group also discussed the ongoing issue of NodeJS packages shipping pre-built JavaScript blobs instead of building from source. While no immediate enforcement was enacted, the committee highlighted a strong need for improved NodeJS packaging tooling—presenting an excellent opportunity for contributor engagement—and suggested a potential future flag date to enforce compliance.

Additionally, the committee discussed FPC#1546 concerning the use of non-Fedora distribution conditionals (such as SUSE or Azure Linux macros) in spec files. Rather than strictly banning or allowlisting specific macros, it was agreed that new, comprehensive multi-distro guidance will be drafted. This upcoming proposal will aim to support cross-distribution compatibility for ecosystems sharing Fedora's packaging roots without cluttering spec files or burdening Fedora maintainers.

Learn more about the Packaging Committee team.

Mindshare

During the June 23 CommOps meeting, the team prepared for the impending mid-July sunset of Pagure.io by coordinating the migration of Fedora Magazine and Community Blog repositories to Forgejo. To improve news accessibility for newcomers and the broader Linux community, the team explored alternatives to dense LLM-generated summaries and approved a proof-of-concept for a human-curated "This Week in Fedora" Matrix news bot, inspired by similar tools used by GNOME and Ansible (hebbot).

Planning has officially kicked off for the Virtual F45 Release Party, tentatively scheduled for October 30, 2026. The team is actively seeking volunteers to lead various work streams, including a lead "Wrangler," speaker coordination, and video production. Furthermore, there is a high-profile engagement opportunity open: CommOps is searching for a new representative to serve on the Fedora Mindshare Committee to help guide global outreach and event operations.

Learn more about the Mindshare team.

Ambassadors

The Ambassadors group is beginning preparations for All Things Open 2026 in Raleigh-Durham, North Carolina. A call for participation has been issued for Fedora Ambassadors planning to attend, offering an excellent engagement opportunity to help shape the project's official event presence. Contributors interested in collaborating, representing the project, or helping staff a potential joint Fedora and CentOS nonprofit booth are encouraged to reply to the forum thread as soon as possible so resources can be mobilized. Further coordination regarding the official booth plan is expected to take place after July 5th.

Learn more about the Ambassadors team.

Workstation / GNOME

A new EXT4 mount option called rralloc (round-robin allocator) was proposed and discussed this week. Designed as an optional, mount-time allocation policy that leaves the on-disk format unchanged, it aims to reduce allocator contention and improve tail latencies for high-concurrency workloads on modern SSD and NVMe storage. The developer is currently seeking feedback and identifying potential use cases to gauge community interest and justify its broader adoption.

In preparation for the upcoming release, the Quality team has issued a call for Fedora 45 Test Days. Contributors are encouraged to review the accepted Fedora 45 changes and propose focused testing events for specific features by filing a ticket on Fedora Forge.

Learn more about the Workstation / GNOME team.

KDE

In recent discussions, it was noted that KDE Gear 26.04 was initially blocked on Fedora 43 due to a gpgme dependency update (requiring version 2.0+) that conflicted with Fedora's soname bump policy. Thanks to upstream commits lowering the requirement to version 1.24.2, this hurdle was cleared. KDE Gear 26.04 will now be pushed to Fedora 43 alongside Plasma 6.7.1, and the update is currently available in Bodhi for community testing.

Looking ahead to the next release cycle, the Fedora QA team has announced a Call for Fedora 45 Test Days. Contributors are highly encouraged to review the accepted F45 ChangeSet and propose specific testing events by filing a ticket on Fedora Forge. This is a prime opportunity for community members to help organize and lead focused testing for new features or critical distribution areas.

Learn more about the KDE team.

Server

The Server Working Group discussed several updates to the distribution and its documentation during their weekly meeting (also summarized on the mailing list). To better support users in regions with fragile or slow internet connections, the group agreed to re-include PPP and xDSL connection support packages in the base distribution media. Additionally, a call for Fedora 45 Test Days was announced across the forum and mailing list, inviting contributors to propose and host testing events for upcoming features.

On the documentation front, the team approved plans to create comprehensive OpenSSH guides and assigned action items to clean up existing NFS installation instructions. To improve security practices and consistency, all Server documentation will be updated to align with the Fedora Docs Style Guide, specifically transitioning command-line examples to use sudo [command] rather than root shells. Contributors interested in helping with these documentation updates or ongoing PXE boot and Kickstart configurations are encouraged to engage with the team.

Learn more about the Server team.

Infrastructure

The Infrastructure team managed several significant server moves and reinstalls this week, including relocating 11 OpenQA, Copr, and OpenShift worker nodes to optimize datacenter power usage, and reinstalling the download-ib01 host with RHEL 10. A major topic of discussion across meetings and the forum was the ongoing migration from the sunsetting Pagure platform to Fedora Forge. The team is actively exploring solutions for handling private security tickets on Forgejo, considering alternative workflows like private Discourse categories, while also assisting teams in archiving their old Pagure repositories. Additionally, a recent RabbitMQ certificate refresh surfaced a bug in the fedora-messaging library where it only read the first CA certificate in a combined file, which was promptly fixed and released.

In community-facing services, a forum discussion highlighted a growing need for shared, open LLM inference hosting within Fedora infrastructure to support tools like Log Detective and meeting summarization bots. The team also addressed a backlog of s390x builds by provisioning an additional builder, resolved Rawhide mirror 404 errors, and granted a storage quota increase on fedorapeople.org to host Flock 2026 video recordings. Ongoing operational work for contributors includes a major cleanup of legacy Nagios and collectd monitoring in favor of Zabbix, and migrating OpenShift applications to standardized Ansible roles.

Decisions

To mitigate staging connection failures, the team decided to temporarily restore the old RabbitMQ server certificates until the patched fedora-messaging library is widely adopted.
The team decided to provision an additional s390x builder to alleviate a severe backlog of long-running package builds.

Learn more about the Infrastructure team.

Release Engineering

During the Release Engineering meeting, the team prioritized the scm-requests migration ahead of the upcoming Pagure decommission. This involves updating fedpkg to file tickets in Forgejo and determining the safest backend method for processing those requests. The team also prepared for the upcoming mass rebuild cycle, the rollout of F47 keys, and finalizing the Fedora 42 End of Life process. Over on the forum, a community member shared their configuration and a brief guide on building a customized Fedora 44 XFCE live ISO using kiwi-ng.

Ticket activity this week centered heavily on package unretirements (kdevelop-python, rust-git-absorb, wavemon, pcl) and implementing a related fix for Koji owner synchronization to ensure unretired packages are properly assigned. The team also addressed Rawhide gating issues by untagging a problematic haveged build that was breaking FreeIPA upgrade tests, and reviewed upcoming Fedora 45 system-wide changes regarding Stratis storage in Anaconda and disabling DNF5 vendor changes by default.

Decisions

For the scm-requests migration, the team decided to update the existing toddlers code to process Forgejo tickets rather than switching to Forgejo Actions. This was chosen to avoid the security risks of storing highly privileged distgit admin tokens in Action secrets.
Patrik will take the lead responsibility for managing the upcoming mass rebuild cycle.

Learn more about the Release Engineering team.

Quality

During their weekly meeting, the Quality team reviewed their recent Flock and DevConf attendance, highlighting productive discussions on openQA failure analysis, Fedora CI improvements, and the ongoing effort to move testing to dist-git PRs. On the technical front, the massive OpenSSL 4 update landed in Rawhide; while it initially broke FreeIPA replication tests and gated all updates, these failures were temporarily bypassed to allow the merge. Additionally, Adam Williamson shared early work on a new system for tracking critical path packages to improve dependency gating, and the team noted that a Kernel 7.1 test week will be scheduled soon.

A Call for Fedora 45 Test Days has been officially issued, inviting the community to review the accepted ChangeSet and propose focused testing events via Fedora Forge. In other community news, volunteers have stepped up to help maintain the Packager Dashboard and Oraculum, though more contributors are always welcome to join the effort. Finally, nightly release validation testing is ongoing, with new composes nominated for Fedora 45 Rawhide and Fedora-IoT 45 RC.

Decisions

Temporarily bypass FreeIPA replication test failures on Rawhide to allow the OpenSSL 4 update to merge.
Disable the use of haveged in FreeIPA tests to resolve recent Rawhide update blocking issues.

Learn more about the Quality team.

Design

The Fedora Design team made significant progress on release artwork this week, officially completing and uploading the Fedora 45 Beta wallpaper. While the final wallpaper is expected in early July, the team is currently troubleshooting Inkscape export crashes related to high-resolution gradients. In event design, the Flock 2026 livestream splash screens were completed and closed, and a new ticket was opened to automate the creation of YouTube thumbnails for individual Flock talks.

There are excellent opportunities for contributor engagement, including a fun new request to design an avatar for the Fedora Matrix Moderation bot. Ongoing community projects also saw major updates: the team is finalizing a community onboarding flyer after implementing accessibility and design feedback, and the Contributor Onboarding Video Series is nearing completion after receiving official voiceovers from the Fedora Project podcast and undergoing final visual and audio tweaks.

Decisions

The Fedora 45 Beta wallpaper will be used to internally test JXL packaging while the final version is completed.
Based on viewer feedback, future Flock livestream templates will prioritize maximizing the screen size allocated for presented content (slides and workshops) to improve readability.
The community onboarding flyer will drop the "technical vs. non-technical" grouping requirement to better accommodate the current design layout.

Learn more about the Design team.

Docs

This week, the Docs team focused heavily on modernizing the documentation ecosystem and improving the onboarding experience. Several mentored issues are open for newcomers to help update contribution guides, including shifting the focus to local authoring workflows, updating the Quick Docs contribution guide, and creating a beginner-friendly "Git for Writers" article. Broader restructuring efforts are also underway, such as planning a modern design for the Docs homepage, exploring UI/UX enhancements for knowledgebase-style pages, and piloting a new "Fedora Docs Captain" role to decentralize documentation leadership across various Fedora Working Groups and SIGs. In the forums, a community member shared a detailed guide on creating a custom Fedora 44 XFCE live ISO using KIWI-ng.

Behind the scenes, the team is actively cleaning up legacy infrastructure by deleting outdated docs pages from the Fedora Wiki and unprotecting specific wiki categories to facilitate change proposal management. Ongoing policy discussions include whether to enforce opening PRs exclusively from forks and the potential creation of a formal code style guide to ensure syntax consistency across repositories.

Decisions

To address security vulnerabilities in the outdated docsbuilder.sh container image, the team decided to request a testing-farm runner on the Fedora Forge staging instance to test building new container images, with a long-term plan to transition to Konflux.

Learn more about the Docs team.

Internationalization

During the Internationalization meeting, the team reviewed the tracker for Fedora 45 changes, noting that the LibreOffice dictionaries change is planned for this week, while the fontconfig change is still in progress. Members were reminded to assist with Fedora 43 bug triaging and were briefed on upcoming proposal submission deadlines for Fedora 45 system-wide and infrastructure changes.

On the mailing list, a new contributor volunteered to assist with Norwegian Bokmål translations for core projects like systemd, Anaconda, and dnf. The team welcomed the contributor, confirmed that their manual review of AI-drafted translations complies with the Fedora AI-Assisted Contributions Policy, and requested a re-upload of recent systemd translations that were lost due to a Weblate merge conflict.

Learn more about the Internationalization team.

COPR

Following the end-of-life of Fedora 42 on May 27, 2026, the COPR team announced the disabling of all Fedora 42 chroots. Consequently, contributors can no longer submit new builds for fedora-42 architectures, including x86_64, i386, ppc64le, aarch64, and s390x.

To avoid disruptive surprises, project owners should note that existing Fedora 42 build results will be preserved for 180 days. After this grace period, they will be automatically removed unless contributors take explicit action to prolong the chroots' lifespan within their specific projects.

Learn more about the COPR team.

EPEL

During the EPEL meeting on 2026-06-24, the steering committee discussed several upcoming package transitions and security updates. Contributors are encouraged to review issue #368 regarding a proposed incompatible update or retirement for syncthing (v1.30 to v2) ahead of next week's vote. Additionally, significant work is underway to address CVEs in EPEL packages. The caddy package will be fast-forwarded in EPEL 10, may require an incompatible update in EPEL 9, and is facing potential retirement in EPEL 8 due to build complexities without go-vendor-tools. Furthermore, the KDE SIG has stepped in to help update qt6-qtwebengine in EPEL 9 to resolve a large number of outstanding CVEs, ensuring the package remains available for its active user base rather than being dropped.

Decisions

Issue #367: The committee approved proceeding with the incompatible update of p7zip to 7zip for EPEL 9, provided appropriate announcements are made. Approval for EPEL 8 will be handled asynchronously once COPR build tests for EPEL 8-specific dependencies (conky-manager and retrace-server) are completed.

Learn more about the EPEL team.

ELN

During the ELN meeting, the team provided status updates on ELNBuildSync (EBS) and bootc integration. The migration of EBS to Fedora Infrastructure is 95% complete, with the Ansible playbook functioning in staging and the team currently awaiting OIDC secrets from Fedora Infra to finalize the deployment. To improve crash recovery, the team proposed a new approach to run EBS batches as Draft Builds right up until submission to Bodhi. This change is pending approval in FESCo issue #3621, and the corresponding pull request is already prepared.

Additionally, progress on bootc compose images is nearing completion. The work is ready to merge but is temporarily blocked waiting for preceding merge requests to land and for Konflux team members to return from PTO, though the bootc team is actively looking into unblocking the process.

Learn more about the ELN team.

Atomic

This week, discussions continued regarding the proposal to create a systemd-sysexts SIG. This proposed Special Interest Group aims to build and distribute systemd system-extensions based on Fedora content, providing a way to add extensibility to atomic systems for software that does not run well in containers or Flatpaks. The initiative continues to gather interested contributors to help design the distribution, discoverability, and official building processes.

In contributor engagement opportunities, the QA team has issued a call for Fedora 45 Test Days. With the Fedora 45 schedule progressing, community members are encouraged to review the accepted ChangeSet and propose features or distribution areas that would benefit from focused community testing. Contributors can propose and organize a test day by filing a ticket on the Fedora Forge.

Learn more about the Atomic team.

CoreOS

During the CoreOS meeting, the team focused heavily on upcoming Fedora 45 changes ahead of the proposal deadlines. Preparations are underway for the F45 pivot change request, the relocation of RPM repository configs to /usr, and upcoming proposals to introduce an oom-kill service and default zram for CoreOS. In the forums, a community member proposed a new EXT4 mount option called rralloc (round-robin allocator) designed to reduce allocation hotspotting and improve tail latencies for high-concurrency workloads. Additionally, interest continues to grow around the proposal to create a systemd-sysexts SIG.

There are several immediate opportunities for contributor engagement this week. The team is actively seeking code reviews and local testing for a major Ignition pivot PR and an Afterburn configuration logic PR. Furthermore, the QA team has issued a call for Fedora 45 Test Days, inviting community members to propose and organize testing events for upcoming features via Fedora Forge. Finally, the team welcomed apiaseck back to the FCOS release rotation.

Decisions

The team agreed to file a formal change request for an Ignition RPM update to boost its visibility and promote the feature to potential users, even though a formal request is not strictly required by the release process.

Learn more about the CoreOS team.

IoT

During the Fedora IoT Working Group Meeting, the team reviewed OpenQA test results for current and upcoming releases. For Fedora IoT 44 (Stable), a new test failure surfaced for rpmostree-rebase on x86_64 and aarch64, alongside a known iot_clevis failure. Meanwhile, Fedora IoT 45 (Rawhide) tests improved after a recent x86 failure and are currently looking stable enough for Rawhide.

In broader community news, the migration of Fedora IoT repositories from Pagure to Forge is expected to happen very soon, potentially within the week. The team is currently waiting on the necessary group creation before moving things over, which contributors should keep in mind for upcoming engagement and issue tracking.

Learn more about the IoT team.

Cloud

This week, the Cloud group received a call for Fedora 45 Test Days proposals. Contributors and community members are encouraged to review the accepted Fedora 45 ChangeSet to identify features or areas of the distribution that would benefit from focused testing. Anyone interested in organizing or hosting an online test event can propose one by filing a ticket on Fedora Forge, making this an excellent engagement opportunity to help ensure the quality and stability of the upcoming Fedora 45 release.

Learn more about the Cloud team.

AI & ML

The Fedora AI initiative has relocated the repositories for the AI Developer Desktop Remix. Contributors and interested community members can now find and engage with the project at its new organization home on Codeberg. This migration is an important update for existing developers to ensure their local environments are synced with the new upstream location, and it provides a centralized hub for the broader Linux community to explore the remix.

Learn more about the AI & ML team.

RISC-V

During the June 23 meeting, the RISC-V group confirmed that Fedora 44 is being kept up to date with major package bumps, including GCC. The Fedora 45 rebuild has officially started with an initial focus on language toolchains, and the team is preparing for a Python 3.14 to 3.15 rebuild utilizing bootstrap sidetag strategies discussed in a recent Flock lightning talk. To avoid workflow disruptions, existing contributors should note that the dist-git overlay has been officially migrated from the old fedora.riscv.rocks infrastructure to forge.fedoraproject.org/riscv/.

Hardware capacity for the architecture continues to grow, with two SpacemiT K3 systems recently added to the Fedora Koji builders to maintain build momentum, and two more on the way. Finally, the group shared their Flock presentation slides and highlighted an open planning ticket for contributors interested in joining the discussion on the long-term roadmap for promoting riscv64 to a primary Koji architecture.

Learn more about the RISC-V team.

Security

The Security SIG met to discuss improving meeting structures, predictability, and ticket prioritization to prevent contributor burnout and maximize meeting value. To help contributors better prioritize their time and know when specific issues will be discussed, the team agreed to start publishing meeting agendas in advance rather than relying solely on ticket labels or ad-hoc discussions.

Additionally, Fedora's CRI-O packager put out a call for SELinux experts to help investigate a potential CRI-O, composefs, and SELinux bug affecting Fedora CoreOS. This presents a highly focused opportunity for contributors with SELinux knowledge to engage and assist with a critical container runtime issue that impacts the broader Linux container ecosystem.

Learn more about the Security team.

Gaming

This week, a community member proposed packaging nbsdgames for Fedora. This project is a lightweight collection of 21 terminal-based games that depends solely on ncurses. Because the author is unfamiliar with Fedora's specific packaging guidelines, this serves as an excellent, low-barrier engagement opportunity for an existing or new contributor looking to help expand the Fedora Games repository. To assist potential packagers, the author noted that using make nb or make nbinstall during the build process will easily prevent any naming conflicts with other existing game packages.

Learn more about the Gaming team.

Perl

This week, the Perl group's activity was centered around routine package maintenance. Specifically, Jitka Plesnikova opened and successfully merged a pull request to bump the perl-App-cpm package to version 1.1.2, addressing bug report rhbz#2492221.

Learn more about the Perl team.

Other Discussions

A guide was shared on how to properly set a Fedora profile picture using Libravatar, including troubleshooting login loops and avatar update delays.
Meeting notes for the Hummingbird project clarified its relationship with Fedora and defined "Agentic OS" simply as Linux with Kubernetes and standard GitOps workflows, rather than autonomous AI magic.
A recap of the Fedora Mentor Summit at Flock 2026 highlighted successful Lunch & Learn sessions and community-building activities like sticker matching.
The 2026 Fedora Contributor Recognition Program Winners were announced, celebrating Ankur Sinha, Fabio Valentini, and Justin Forbes for their outstanding community contributions.
A thread initially about an AI bot making unauthorized Bugzilla changes evolved into a deep discussion about Two-Factor Authentication (2FA), exploring recovery token strategies and Kerberos ticket renewals via sssd-kcm and GNOME Online Accounts.
Following FESCo's decision, the 2FA policy for provenpackagers is now active, prompting discussions on using kinit with Yubikey OTPs and obtaining 7-day renewable Kerberos tickets.
A Change Proposal for a minimal GRUB bootloader tailored for Confidential Computing and Unified Kernel Images (UKIs) sparked debate over whether to include filesystem drivers (like Btrfs) or rely solely on FAT and the EFI System Partition.
A discussion addressed the policy violation of shipping pre-built WASM and ELF binaries inside node_modules source archives, leading to proposals for new tools like npm2rpm to automatically strip them.
A request to package AWS s2n-tls and aws-lc raised concerns about the responsiveness of the Fedora Crypto Team and whether the strict gatekeeping process for new cryptographic libraries needs reform.
A proposal to explicitly permit macros like %rhel, %centos, and %hummingbird in spec files was met with pushback from some developers who consider %rhel an antipattern that causes packaging divergence.
Other discussions this week included a call for Packager Dashboard maintainers, feedback on Node.js metapackages, help with git authentication for package releases, new helper scripts for upstream releases, an issue with redhat.com emails failing DMARC, handling Sphinx autodoc in RPM builds, optimizing compose disk space, addressing unmerged CMake 4 PRs, GCC plugin version dependencies, ideas to improve the Changes Process, centralizing GNOME SRPM macros, a planned infrastructure outage, the migration of the FESCo ticket tracker, a call for F45 Test Days, the disabling of F42 chroots in Copr, identifying package metadata in side-tag testing, and the resolution of git fsck issues in 71 package repos.

New contributor introductions

Joshua Thomas introduced himself on the fedora-join list, expressing interest in contributing to QA and leveraging his homelab environment for Rawhide testing.

Orphaning packages

Non-responsive maintainer checks were initiated for the fastnetmon, pyserial (where the maintainer subsequently replied), and ledger packages.
The showtime, python-poetry-plugin-export, and libgsasl packages were officially orphaned or announced to be orphaned soon.
Developers expressed interest in claiming and unorphaning the fx and python-persist-queue packages.

Package updates

A mass rebuild was coordinated for the fmt and spdlog upgrades, overcoming temporary Koji builder stalls.
A Change Proposal was announced to update libxml2 to version 2.15.3, requiring a system-wide mass rebuild and deprecating its Python bindings.
Rebuilds were announced for the libcamel soname bump in evolution-data-server 3.61.1 and the Openbabel-3.2.0 upgrade.
License changes were noted for the powdertoy and perl-Graphics-Toolkit-Color packages following upstream updates.

misc fedora bits: end of june 2026

Posted by Kevin Fenzi ( Fedora Account System Username

kevin ) on 2026-06-27 18:22:49 UTC

Time for a recap of the last week in my #fedora infra space (here in longer form).

Overall this week was a bunch of catch up from being away at flock, along with recovering from Jetlag.

RHEL10 migrations

I scheduled an outage on thursday for the last of the external colo virthosts to get a RHEL10 reinstall. I had tried to do it in the last outage, but I wasn't able to do it in the normal way that preserved all the guests data. This time I managed to get it done, but it took longer than I would have liked and I hit a number of fun issues:

Using a remote console I can't hold down shift to get a grub menu, so I had to hit escape at the right time.
rdp for Fedora is not great still. gnome-connections is still the winner, but even it has quirks.
The /boot/efi partition still did not want to let me reformat it as part of the install. I thought it was because there was a spare in the raid1 for it, but I grew it to use that spare and it still didn't help. So, I ended up just deleting it and recreating it.

Finally all reinstalled, reprovisioned and all the guests brought back up.

There's still a number of hosts to move, and we are down to trickier ones, but we will look at another outage probibly week after next to do more.

2fa in Fedora

Fesco decided to require all provenpackagers to enroll a 2fa token. There's a lot of talk about expanding that to packagers, or even everyone.

I thought I would share some info around this for interested folks who may not have seen it in all the various threads or tickets:

The Fedora account system frontend (noggin) supports enrolling TOTP tokens. Once you enroll one you must use it to login to the account system, to get a kerberos ticket, and to login to any web application with your fedora account.

You can (and should!) enroll more than one token. As far as I know, there's no limit to number you can add. You can also disable or delete tokens, so long as you still have one token enrolled. ie, you can never delete the last one. Any enrolled, non deactivated token will work to authenticate you. So, it's good to have at least one saved off to a safe place in case you loose access to your primary token.

If you somehow loose access to all your tokens, the recovery process is to mail admin@fedoraproject.org and you will be asked to prove you are you. This may be a gpg signed email (with the key associated with your account), using your ssh key associated with the account, or other means.

So, please make sure you have a backup token to avoid that. :)

TOTP is pretty common and has been around a long time. Lots of software is capable of storing your secret and displaying tokens.

s390x builds backup and koji session bug

On friday morning our koji s390x builders were getting swamped. It was the same story with a lot of large builds taking up builders so other things couldn't get in. Or so I thought at first, but on digging there was another problem. It was caused by a koji bug (already fixed upstream, but not released yet). This caused tasks to get freed and just sit there and not progress.

I have applied the patch and updated our hubs, and then went through and reassigned all the tasks I could see that were still having problems. Let me know if you see any I missed.

I also pulled in 2 more builders to the general build pool

One I had set to only do kernel builds a while back when we were trying to get security updates out fast.
One was a compose host, but I think we can be fine with one less compose host.

So adding those two helped process the backlog too.

I've also filed another request for more resources, but so far it hasn't really gone anywhere. ;(

Some PTO next week

Next week, I am going to be taking thursday off and friday is a holiday in the US, and I am taking off the following monday too.

Of course I'll still be around, but possibly doing other things. :)

As always, comment on the fediverse: https://fosstodon.org/@nirik/116823567269032135

onak 0.6.5 released

Posted by Jonathan McDowell ( Fedora Account System Username

u1f35c ) on 2026-06-27 15:44:00 UTC

I had intended that the next release of onak, my OpenPGP keyserver, would be 0.7.0, and include OpenPGP v6 support (RFC9580). However events conspired to make a 0.6.5 release a really good idea.

Firstly, I threw an LLM at the code base and asked it to review it. This isn’t intended to be a post about LLMs, but there’s a considerable amount of pressure at work to be “AI native”. I’m very much an “AI” sceptic, so I figured throwing it at a code base I know well might be an interesting exercise. It did find a bunch of embarrassing mistakes, but I don’t think there was anything earth shattering that a human reviewer wouldn’t have pulled me on. The problem is with a hobby project with a single user there’s no actual review of my work.

I also enabled GitHub’s security scanning. It mostly complained about format strings, and those were easy enough to fix up.

Next I threw AFLplusplus at the code. I’d previously tried American Fuzzy Lop, but not in some time. AFL++ found a whole bunch of places I should really have checked available buffer lengths and wasn’t doing so. It really is an incredibly easy tool to get up and running.

valgrind is also a tool I’ve used before, and rate highly. Thankfully it didn’t find anything in my testing this time.

Finally I threw a few more automated tests into the mix and discovered something has changed around dynamic linking such that the libonak symbols in the dynamic key database backends were using private copies, rather than the main binary. This caused problems with seeing the correct configuration settings in some instances.

All in all this release is not my proudest moment; a bunch of the issues fixed should never have made it to a release.

(Also, just to explicitly state it, all the actual code in this release was artisanly crafted by me, in vim. The only involvement of an LLM was for a review pass.)

Available locally or via GitHub.

0.6.5 - 27th June 2026

Lots of fixes/improvements around length checking

Added extra basic tests for maxpaths/sixdegrees/CGI

Correctly end transactions in the stacked backend

Ensure the file backend avoids stale key data on updates

Fix decoding of v2/3 signature creation times

Fix EdDSA signature parsing when r < 249 bits long

Fix migration of bools from old to new config style

Fix parsing of new config details for DB parameters

Fix problems with linking + dynamic backends

Fix RSA-SHA2-384 signature checking

Fix sixdegrees parsing of keyids with high bit set

Handle failures in maxpath more gracefully

Make new style config path match old path

Migrate Fedora OS via partition cloning efficiently over network

Posted by Kamil Páral ( Fedora Account System Username

kparal ) on 2026-06-26 17:01:08 UTC

How to migrate Fedora OS from one system to another, across network or (better) a Thunderbolt connection, without cloning the whole disk contents, saving SSD life.

Background

When migrating a Linux installation from a source drive to a target drive of a different size, traditional block-by-block tools like dd don’t allow to migrate to a smaller drive, and also waste SSD life by writing unused blocks. This guide describes a simple approach in which different disk sizes can be used, and the process is performed over network (or Thunderbolt), so that it’s not necessary to place two physical disks in the same device. The target system is exactly the same as the original, with all partition and filesystem UUIDs staying the same, which means no post-migration OS configuration is necessary. The time and SSD wear is minimized by pre-shrinking partitions and skipping unallocated disk space entirely. The default Fedora Workstation disk layout is supported, including LUKS encryption of the system partition.

This guide expects the following disk layout:

/dev/nvme0n1p1 — ESP (most often FAT)
/dev/nvme0n1p2 — Boot partition (most often Ext4)
/dev/nvme0n1p3 — System partition (most often Btrfs, optionally encrypted using LUKS)

For simplicity, this will not try to skip copying all unused blocks, just most of them. The first two partitions will be cloned in raw mode. The third partition will be shrunk first (thus saving lots of blocks from being copied, and also supporting smaller target drives), and then cloned in raw mode.

Migration steps

Shrink the system partition on the source system

On the source system:

Delete all necessary data, prune cash dirs, empty the trash, etc.
Boot to a Fedora Workstation Live system from a USB drive.
Install necessary tools: sudo dnf install gparted pv
Run Gparted. In it, unlock the system partition, if encrypted. Then shrink the partition to a reasonable degree. For example, if the partition has 950 GB (from a 1 TB disk), but only 300 GB is used, you can shrink it e.g. to 350 GB. That still leaves enough free space for regular usage if you had to boot it for any reason, and saves 600 GB from being copied needlessly. This operation might take some time, because any data blocks currently present after the new size limit will need to be moved (therefore don’t be too aggressive in setting the limit). If your partition was encrypted, make sure that both the LUKS encryption container and the filesystem inside it correctly show up as resized.
Unmount all partitions (if any), lock the encrypted partition (if applicable) and close GParted.

Erase the target system

On the target system:

Ensure that this is really the system you want to completely erase (and replace with the OS from the source system).
Ensure that the disk size is sufficient to fit all partitions from the source system (now that the system partition on the source system has been shrunk).
Boot to a Fedora Workstation Live system from a USB drive.
Install necessary tools: sudo dnf install sfdisk sgdisk
Unmount all partitions (if any). You can use e.g. GNOME Disks for this.
Erase the whole drive (make sure you’re using the correct system): sudo wipefs -a /dev/nvme0n1
Discard all blocks on your drive (better for your SSD longevity): sudo blkdiscard -v /dev/nvme0n1

Establish an Ethernet/Thunderbolt network link

If you have both systems connected to the network and intend to use it, skip the Thunderbolt setup section below. Instead figure out the IP addresses of both systems (using the ip address command) and go to the Connectivity test.

Thunderbolt setup

If you want something faster than a regular network, have Thunderbolt ports on both systems and a fast USB-C cable ready, you can use that instead. With Thunderbolt, you can transfer data with 10 Gb/s speeds or more, compared to the common 1 Gb/s of a standard Ethernet.

On both laptops, after connecting them through a Thunderbolt cable, locate the network interface name: ip link
Look for an interface like thunderbolt0.
Assign static IP addresses to them:

Source system:
bash sudo ip addr add 192.168.5.1/24 dev <interface_name>
sudo ip link set <interface_name> up
Target system:
bash sudo ip addr add 192.168.5.2/24 dev <interface_name>
sudo ip link set <interface_name> up

Connectivity test

Let’s use a well-named variable for both numbers, so that we don’t mix them up later. On both systems, run:

   export SOURCE_IP=192.168.5.1
   export TARGET_IP=192.168.5.2

Test connectivity between your systems.

From the source system: ping $TARGET_IP
From the target system: ping $SOURCE_IP

You should see both systems pinging the other system correctly.

Replicate partition table from source to target

This will make an exact copy of the source system partition table (including partition UUIDs) on the target system. Then we will adjust it to the different disk size.

On target system, start listening for data and save it:

   nc -l -p 2000 > table.txt

On source system, dump the partition table and send it over:

   sudo sfdisk --dump /dev/nvme0n1 | nc $TARGET_IP 2000

On target system, apply the partition layout to the disk:

   sudo sfdisk /dev/nvme0n1 < table.txt

And then fix the GPT backup header location (because it’s unlikely that you have both disks of exactly the same size):

   sudo sgdisk --move-second-header /dev/nvme0n1

Copy all partitions

Everything should be ready now to transfer all partitions data.

Clone the ESP partition (p1):

On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p1 bs=4M

On source system, send the data:

   sudo dd if=/dev/nvme0n1p1 bs=4M | pv | nc $TARGET_IP 2000

Clone the Boot partition (p2):

On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p2 bs=4M

On source system, send the data:

   sudo dd if=/dev/nvme0n1p2 bs=4M | pv | nc $TARGET_IP 2000

Clone the System partition (p3):

On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p3 bs=4M

On source system, send the data:

   sudo dd if=/dev/nvme0n1p3 bs=4M | pv | nc $TARGET_IP 2000

Expand the System partition on the target system

Now that the target system is a complete clone of the source system, you can expand the System partition to fully utilize the remaining disk space:

Install GParted on the target system: sudo dnf install gparted
In Gparted, unlock the system partition, if encrypted. Then enlarge it according to your preferences. If your partition was encrypted, make sure that both the LUKS encryption container and the filesystem inside it correctly show up as resized.

Reboot the target system

You can now reboot the target system, and you should see your OS and data exactly the same as on your source system. The process is now complete.

Boot problems

In case the target system has a very different hardware from the source system (e.g. a different brand of a graphics card), the drivers might be missing from the current kernel initramfs and you can see a black screen or kernel errors. In that case, reboot the system again, press F8 repeatedly during boot to get into the GRUB bootloader menu, and boot the rescue Fedora option, instead of the default one. That should hopefully boot using the generic image (which should contain all known drivers), and then you can regenerate all the kernel images using your current hardware setup with: sudo dracut --regenerate-all --force

Mentions of other cloning approaches

Using dd
This works fine when cloning to a larger disk (if you fix the partition table afterwards), but unused blocks are written needlessly (wearing down SSD), and migrating to a smaller drive is problematic.
Native Btrfs streams using btrfs send and btrfs receive
This perfectly copies only used blocks of the main partition, but it only submits a single subvolume. Which means there’s some extra work needed to make sure exactly the same subvolumes are replicated from source to target. Also, this works above the LUKS encryption, which also needs to be created manually on the target (while keeping IDs, etc).
Using Clonezilla
Clonezilla will copy LUKS partitions as raw data, because it can’t see inside. Furthermore, it doesn’t support cloning to a smaller drive by default (there are some tweaks in Expert Mode, but you need to repair the GPT backup table manually anyway).
Sparse-copying the whole disk
You can clone and restore the whole disk image with sparse blocks support, as seen in this guide. With a little tweaking, this approach could potentially be used even for my use case. One would need to make sure all the unallocated blocks are freed and really contain zeroes (which means running fstrim or blkdiscard and testing if it zeroed it out), and the partitions would need to be shrunk first in case of migrating to a smaller drive. The GPT backup header would need to be fixed (the same way as in the main article). So this might be a viable alternative approach for those who know how to tweak the steps.

The end of the AArch64 desktop experiment

Posted by Marcin Juszkiewicz ( Fedora Account System Username

hrw ) on 2026-06-26 11:18:00 UTC

After about eleven months of using an AArch64 desktop, I decided to end that experiment.

Hardware used

About a year ago, I bought myself an Ampere Altra system. After moving some hardware around and making a few extra orders, the final setup was:


CPU	Ampere Altra Q80-30 processor (80 cores at 3.0GHz)
RAM	128 GB (8x 16GB HMA82GR7CJR8N-XN)
GPU	AMD Radeon RX6700XT
NVME	Lexar LM970 2TB ADATA SX8200 Pro 1TB
Motherboard	ASRock Rack ALTRAD8UD-1L2T
PSU	MSI MPG A850G (850W)
Case	Endorfy 700 Air
USB3	no-name USB 3.2/10Gbps controller (PCIe x4)

To be fair, I should mention that this is a server motherboard, not a desktop one, and Altra systems were never meant to be desktops (despite companies selling them as such). Naturally, the list of tested/approved devices (Qualified Vendor List (QVL for TLA fans)) is quite short and for Ampere Altra systems, it does not contain AMD Radeon GPU cards. They can be made to work, but this often requires additional effort.

The extra USB 3.2 controller allowed me to have more USB devices than the motherboard alone supported, and gave me some 10Gbps ports for connecting external NVMe drives.

The whole system was running just fine^* under Fedora 42–44.

The first issue

Have you noticed the small “*” at the end of the previous paragraph? The system I used was not quite Fedora — I had to use my own, self-built kernel.

You see, the PCI Express controller in the Ampere Altra has some issues. Let me quote the description of the Ampere Altra erratum 82288 patches:

Per Altra family erratum, PCIE_65 may cause invalid addresses to be generated on PCIe mmio writes, impacting certain device types, notably AMD GPUs, and thus the Altra family is not generally compatible with those device types.

And longer description from patch itself:

PCIe device drivers may map MMIO space as Normal, non-cacheable memory attribute (e.g. Linux kernel drivers mapping MMIO using ioremap_wc). This may be for the purpose of enabling write combining or unaligned accesses. This can result in data corruption on the PCIe interface’s outbound MMIO writes due to issues with the write-combining operation.

The workaround modifies software that maps PCIe MMIO space as Normal, non-cacheable memory (e.g. ioremap_wc) to instead Device, non-gathering memory (e.g. ioremap). And all memory operations on PCIe MMIO space must be strictly aligned.

So, to have a working Linux system, I had to rebuild the kernel on every package update. Which usually meant “weekly”. Each Monday or Tuesday, I would update the local copy of the Fedora kernel package repository and build it using my own versioning scheme, like “7.0.2-200.fc44.pcie65.6”. The “pcie65” part reminded me which patches I had applied, and the “6” was a counter for the patch rebases.

I cloned the repository from GitHub and then rebased patches, adapting them whenever they needed work. The side effect was that I often used a newer kernel than the official Fedora release — there is a “stabilisation” branch in the Fedora kernel package repo where the soon-to-be-pushed version is present. So, when Fedora had 6.19.y kernel, I had 7.0.z one.

So many cores, not enough speed

As I wrote in my previous post, having eighty CPU cores does not mean that the system is a good, fast desktop machine.

AMD GPU started failing

As I mentioned above, to get my AMD Radeon RX6700XT running properly I had to alter kernel with the out-of-tree patches. It worked, I could play some games, watch videos with hardware-assisted video decode acceleration.

Until one day, around the Linux 7.0 release, when it started to fail. Running a game ended with:

kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0

Over and over again. Watching YouTube videos became impossible due to 720 out of 750 frames being dropped, etc.

Normally I would start to bisect the kernel to find out where the problem is. But I was running a tainted kernel due to PCIE65 patches so who knew where the problem actually was…

Let’s get Nvidia

I bought an Nvidia RTX 2060 graphics card and put it in place of the AMD Radeon. It turned out that if I wanted to use it with the nouveau kernel driver I still needed PCIE65 patches applied…

So I tried default Fedora kernel with Nvidia binary driver. And it worked fine. Video decoding was accelerated, some games under Wine worked as well.

But then I started FreeCAD. And OrcaSlicer. And in both cases I got crash and exit…

It turned out that there was no org.freedesktop.Platform.GL.nvidia in Flatpak repositories for AArch64. And I used both of those tools quite often.

Powering up the old x86-64…

At that point, I gave up. And booted my x86-64 system, which had been powered off all that time. There were a lot of cables to move, some new ones to arrange, and now I have both “wooster” (Ampere Altra) and “puchatek” (Ryzen 5 3600) systems running under my desk.

Moving from 80 cores to 6 cores (12 threads) was a weird experience. A much smaller number, yet things work fine. I can load all threads and the music still plays. All games from my Steam library are playable. A working FreeCAD allows me to finish designing cases for my home projects and I can 3D print prototypes straight from OrcaSlicer.

The “wooster” system stays powered on, churning through RISC-V package builds. It may be weak in single-thread, but it flies when it comes to multi-core load.

Conclusion

As for the Ampere Altra, I am not planning to repeat this experiment. Another AArch64 desktop attempt would require a completely new hardware platform. And I have no plans to spend over twenty thousand PLN to buy an Nvidia DGX Spark system.

Community Update – Week 26 2026

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-26 10:00:00 UTC

Week: 22 – 26 June 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

CentOS Infra including CentOS CI

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

RISC-V

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

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

AI

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

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

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

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

Forgejo

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

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

UX

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

Beta Wallpaper ticket closed

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

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

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

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

Fedora Documentation translations again available

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-26 09:19:27 UTC

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

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

Flock 2026 and Devconf.cz 2026 trip report

Posted by Adam Williamson ( Fedora Account System Username

adamwill ) on 2026-06-26 08:45:01 UTC

Long time no blog, once again - as always, I'm mostly posting on Mastodon now, so follow there if you're missing the Content. This is a bit big, though, so it goes here!

I was in Prague for Flock 2026 and Brno for Devconf.cz 2026 recently. Didn't have any issues with travel, fortunately. I was in Prague a day early for a Red Hat "face-to-face", which went fine. Had a fairly quiet/jetlagged dinner with Kevin and Tomas on the first night, and a nice dinner with Lenka Segura, Kashyap Chamarthy, Cristian Le, Frantisek Lehman and Laura Barcziova on the second night; most of them I was meeting for the first time in person, which is always good.

Flock 2026

Flock started for real the next day with workshops. I started with "The Future of Fedora Atomic", about how we can reach the goal of all the Atomic images being based on a shared bootc base container, then went to "Forging Fedora Project’s Future With Forgejo". In the afternoon I went to "PR-based Gating for Fedora: Can We Make It Work?", which was about the idea of moving all automated testing/gating to run against dist-git pull requests (instead of mainly against updates, as is the current case).

These were all more "talking shops" than "workshops", really, but they at least mostly produced interesting conversations and concrete ideas. In particular, Cristian and I were able to determine a set of priorities for Fedora CI from the "PR-based gating" session - there was a lot of discussion of potential issues and concerns further down the road of the potential migration, but in the end we found it pretty clear that we need to improve the reliability of the existing tests and pipelines, and the ease of interpreting the results, and that's uncontroversial work that can be done first.

There was also a request from Petr Khartskhaev that we make it possible to run the openQA tests on dist-git pull requests. This had already been requested by Mo Duffy before. I've resisted doing this for all dist-git pull requests because I know at least some would fail when changes to multiple packages need to be grouped and tested together. The update system allows us to group builds into updates, but dist-git does not yet have any way to mark multiple PRs as a logical group for testing/promotion. However, someone suggested a better idea: do it by request, not for all PRs automatically. So I decided to go ahead and do it. Instead of doing another workshop, I hid in the corner of the "Languages in Floss" session and bodged up a working prototype, which is deployed to staging openQA. If you comment /openqa test on a dist-git pull request, tests on it will run in staging openQA. I'm currently working on getting the results reliably reported back to the pull request.

We had a team dinner that evening, again good to meet people and a good mix of work and social chat. At some point in there I met our relatively new RH team member Jaroslav Groman in-person for the first time, which was great - he's been doing excellent work on digging out from under our tooling tech debt and it's great to have him aboard. Peter Sklenar unfortunately wasn't able to come this time.

Day two was session heavy. There was an opening keynote track with Jef's "State of Fedora" address, live Fedora Council and FESCo meetings (effectively), and a Hummingbird talk from Stef Walter. The State of Fedora produced a couple of very talked-about sets of statistics, one showing Fedora (and friends) usage climbing solidly and one showing Fedora contributor numbers declining worryingly. The usage numbers are great, of course - especially the rapidly-growing numbers for KDE and our awesome downstream distro friends (the uBlue-verse, Asahi, Bazzite et. al.) We definitely need to dig into the contributor numbers some more, see what's going on, and whether and what we need to do to reverse the trend. There are a lot of interesting questions about whether it's Red Hatters, community maintainers, or both who are declining, and how this relates to other trends like the CVE tsunami, mushrooming language ecosystems, the rise of Flatpaks / Snaps / AppImages and so on.

The Council and FESCo sessions touched on those topics and several others, though interestingly not the AI Desktop proposal which I was kinda expecting to hear a lot about. I kinda tuned out and hacked through some of them to be honest. Stef's talk gave a good clear overview of Hummingbird - I kinda knew it going in, but it's always good to have it summarized quickly and clearly (at least I thought so).

I unfortunately didn't know about the Lunch and Learns (somehow missed them on the schedule), or else I would have gone to some! But still had plenty of fun/productive lunches with various folks. In particular I met Vít Smolík (smoliicek) in person, which was great. He's been helping out with the data team and infrastructure team and is doing some great work.

In the afternoon I went to the "Packit and Fedora: The CI Story Continues" talk, which was a good summary of the work to rationalize the mess of different systems we have/had testing pull requests. It's much better than it was before. Then I went to "Fedora Server – What you can expect from the next two releases", which was great because it clearly explained the idea of the "Home Server" spinoff which I hadn't really been clear on. And of course it was good to see Peter Boy and Emmanuel Seyman again. Alexander Bokovoy also explained his latest authentication stuff, which as always I didn't entirely understand but filed under "sounds like Alexander has it under control"...

I skipped another session to do some hacking, then went to "The Engineer’s Guide to Design", which was really interesting - I like going to slightly off-the-beaten-path talks. I don't really work on front-end UX stuff a lot, but it was still interesting to hear a perspective from someone who's been both an engineer and a designer on the impedance mismatches that can happen and the basic concepts it's useful for both sides to know about the other. Then I saw "Artifact Signing in Fedora", where Jeremy Cline gave some background and an overview of his ongoing project to rewrite the Fedora signing server, which is badly-needed work that we're really grateful for.

In the evening we had the official party, at a really nice outdoor food court with a reserved space for the conference. The organizers brought over so many appetizers I barely needed to use the meal ticket, but managed to force down some tacos nevertheless. Had a great time chatting with various folks, then later headed to a Belgian beer bar for more drinks with Justin Forbes and several others.

On the final day I started with "The Packager's Guide to openQA Failures" of course - Lukas Ruzicka (my openQA henchman) did a great job covering openQA failure analysis from the perspective of a packager, and I contributed a few notes here and there. We had a good crowd who seemed really interested, which is always great news. After that I saw Kevin Fenzi's "scrapers gotta scrape scrape scrape" talk on all the fun we've been having with scraper networks flooding our infrastructure. I know some but not all of it beforehand, and of course Kevin explained it well and the audience was very engaged. Plus I got to tell my story about the time I thought a dastardly new scraper network had figured out how to evade Anubis, but it turned out that the call was coming from inside the house (i.e. I had done a slightly silly thing in openQA which made it effectively DoS Koji...)

After the coffee break I saw "Fedora Test Days - a11y", which was actually a somewhat wider talk from a couple of RH folks working on accessibility testing about their current testing and future plans. It was really interesting and it was good to be able to speak with them briefly about the possibilities of using openQA for this. I stayed in the same room for "Two Years In: Accelerating Microsoft Contribution to Fedora", where Jeremy Cline, Brian Exelbierd and Reuben Olinsky covered some Microsoft's (much-welcomed) contributions to Fedora and also some stuff about Azure Linux.

After that was "Upgrading Fedora Infrastructure from Nagios to Zabbix" - this migration has been ongoing for a while but was much-needed as a modernization and also a better architecture. I found it very useful as I do have plans to add more detailed monitoring of openQA and the talk was very helpful in letting me know how to get started with that.

After lunch came lightning talks. I had proposed one about "new stuff we did in Fedora CI lately", which kinda overlapped with some of the full-length talks in the end, but it still got a lot of votes, so Cristian Le and I went up second and did a rapid redux of the Packit consolidation work, improved result displays, optimizations and improvements to the generic tests, addition of rmdepcheck and so on. My voice was giving out by this point but we just about got through it. There were a lot of other great talks and everyone managed to come in under time, which was impressive.

After that was a Fedora Mindshare session which I half-followed and half-hacked/dozed through (was starting to get tired at this point!), then the "Fedora’s Contributor Recognition Program" session where much-deserved awards were handed out to Ankur Sinha, Fabio Valentini and Justin Forbes. I was on the voting panel for this so it was great to see the culmination, and the trophies contributed by the Nairobi GNU/Linux Users Group were awesome.

I almost forgot to mention the whole time I was struggling with some sort of wifi driver bug - it seems there was a troublesome AP or something at the hotel which caused my laptop to crash constantly. And the hotel wifi was terrible, and I only had 5GB of data on my phone, so I couldn't really rebase to F44 to avoid it. Lots of fun.

Devconf.cz 2026

That was the end of Flock; things wound down and I had dinner with...some people...somewhere (possibly the third Vietnamese of the trip? Things are getting fuzzy). The next day was a welcome quiet day traveling from Prague to Brno - train and bus, no problem except waiting for the bus was very hot. I stayed at the Hotel Vaka, which I've never been at before, but it's quite nice. The whole event was a bit weird because Moto GP (the motorbike equivalent of Formula 1) moved their Brno race to the same weekend Devconf.cz would usually be on, and took all the hotels, so devconf was hastily moved to Thursday/Friday. Hotels were still hard to get and I only just managed to grab this one at a decent rate. I was able to rebase my laptop finally and stop worrying about wifi crashes, and had a nice quiet pizza dinner at Doe Boy.

So a shortened devconf started with the opening session, then another Hummingbird keynote, this time with Valentin Rothberg as well as Stef Walter. It added a bit of detail compared to Stef's Flock talk, and there wasn't anything else on. Then I saw "OpenShift CI: What if we stopped retesting everything all the time?", which was an interesting talk about the tradeoffs involved in doing automatic retests of complex merge chains in a big project with lots of PRs trying to be merged all the time (OpenShift). It wasn't directly applicable to anything I do, exactly - Fedora updates don't quite map to PRs in a git repo - but in a more general sense it was useful in suggesting methods for thinking about this kind of complex tradeoff and how to measure the impact and efficiency of testing processes.

Next I saw David Duncan's "From Laptop Chaos to Fedora Cloud: Quadlets and Containers", mainly because it was David, but it turned out to be a good talk about a way to make a relatively complex multi-container side project buildable and deployable the same way on your laptop and in The Cloud, using systemd quadlets. I've dealt with this general area before a few times. David made a solid case that quadlets are a good approach, in his usual fun and personable style.

After that I saw Zbigniew's "New security features in systemd" - honestly I missed some of this one, but got the gist of why systemd is trying to modernize various mechanisms here. Then I went to "Beyond the Screen: A Deep Dive into Linux Accessibility for Developers" by Vojtech Polasek, which was one of my highlights of the week - a really good explanation of how computer interaction really works for blind people, and what properties applications should have (and avoid) to make them usable. This is obviously very important for testing purposes.

Next I went to "Stop Looking for the Perfect Prompt: The Design-First Workflow for Coding Agents" to get my corporate mandatory minimum AI Content(tm) - it was actually a pretty good and accessible talk on different approaches to LLM-based feature development. I still don't really use LLM code generation heavily (for a start, I spend so little time actually sitting at a blank screen typing significant amounts of code that it's not really worth worrying about), but it's good to keep up with the latest ideas about how to do this kinda thing. Continuing with the AI theme I took in Tomas Tomecek and Laura Barcziova's "How AI helped us ship updates in a Linux distro", which was a practical talk on the system behind Hummingbird and the actual approach it takes to (sort-of) AI-driven package builds.

After that I think I did some Fedora booth cover for a while. Lukas Ruzicka and Vojtech Trefny were holding the booth down for most of the weekend, but I stopped by and did an hour here and there to give them some relief. It's always a lot of fun chatting to people about Fedora, other distributions or stuff that has nothing to do with Linux at all. Lukas had set up a Framework laptop with a MIDI keyboard attached to show off that it's pretty practical to do audio creation on stock Fedora kernel and audio stack these days; Vojtech and I had absolutely no idea how to use it, so we had lots of fun trying to talk about it to people and eventually telling them to come back when Lukas would be there...

In the evening we had the conference party, which was at the same outdoor swimming pool it's been at for a couple of years(?) now. It's a great venue - you can grab some food and a drink and then relax in the shade under some trees. I wound up sitting round with a really interesting mixed group of folks (Red Hat and non-Red Hat, some big cheeses, some medium-size cheeses and some fresh faced...cheese curds? Help, my metaphor is falling apart) most of the night, it was a great evening. Walked back most of the way to the hotel with Stef Walter, setting the world to rights as is the tradition after a few drinks at conference parties...

On the second day I started with "From Podman to Production: Building Trusted Container Images with Konflux on OpenShift" by Vladimir Sokolenko, which was probably the most understandable and useful Konflux talk I've seen so far. I think I then maybe did a bit more booth cover(?) and some hacking, then wrapped up with a nice three-talk track in the same room - "Identical Testing Environments from Laptop to CI with tmt and Testing Farm" by Cristian and Petr Šplíchal (covering their work to make tests more reproducible from Testing Farm to your local system), "systemd-sysext in Production: What We Learned Extending /usr Without a Package Manager" by Brian Exelbierd and Daniel Zaťovič (a really good retrospective on their experience using sysext in the real world to ship additional / alternative software on Flatcar), and "Local package layering on bootc systems with DNF5" by Evan Goode (explaining his design and plans for providing a convenient, dnf-ish interface to "overlaying" packages on bootc-based installs). I met Evan in person for the first time at the party, and it was great talking to him. I hope his work on this goes well - we really need it for the glorious bootc-based future.

After that was the traditional wrap-up session with the trivia quiz (I won a t-shirt!) and then I said bye to a lot of people and melted off (it was extremely hot) to the train station...to find that my train to Vienna was delayed by nearly an hour. Ah, well. Eventually made it to my hotel in Vienna (which was incredibly nice, just wish I'd stayed there longer...) and had an excellent dinner at Iki (highly recommended if you're in the area). Got in a couple of swims in the nice-but-small hotel pool before and after sleeping, then had a Vienna take on avocado toast (interesting!) for breakfast and headed off to the airport, and that was another trip in the books.

Friday Links 26-21

Posted by Christof Damian ( Fedora Account System Username

cdamian ) on 2026-06-25 22:00:00 UTC

Shaggy sheepdog sculpture on a plinth in a gallery

This week I enjoyed the last episode in the Industry Special from Escape Collective about Chinese brands. The Overnight Success podcast is worth subscribing to, even if you are not into bicycles. It’s about founders and their businesses.

Quote of the Week

The technologies we use to try to “get on top of everything” always fail us, in the end, because they increase the size of the “everything” of which we’re trying to get on top.

Four Thousand Weeks

Oliver Burkeman

Leadership

Struggle Creates Value - “We are going to, and we need, to struggle together.”

Planned Outage - download-ib01, torrent, people outage

Posted by Fedora Infrastructure Status ( Fedora Account System Username

admin ) on 2026-06-25 20:00:00 UTC

We will be reinstalling the virthost that runs download-ib01, torrent.fedoraproject.org and fedorapeople.org. During the outage these sites will be down.

Not all policy enforcement needs to be automated

Posted by Ben Cotton ( Fedora Account System Username

bcotton ) on 2026-06-25 12:00:00 UTC

I am a big proponent of the “don’t make rules you can’t (or won’t) enforce” maxim. The careful reader will notice that the word “automatically” does not appear anywhere in that advice. Automated policy enforcement is good. It reduces maintainer burden, gives the community a consistent experience, and…you know…makes sure the project’s policies are enforced.

Sometimes automated policy enforcement is easy. There are plenty of tools out there to require a certain degree of password length/complexity, ensure commits have a DCO signoff, and so on. Sometimes the technical implementation is harder. That doesn’t mean the policy can’t go forward.

The Fedora Engineering Steering Committee just decided to require two-factor authentication for members of the provenpackager group (people who have essentially project-wide privileges for package maintenance). In the discussion about whether to adopt such a policy, folks pointed out a few legitimate concerns. The account system can’t require two-factor authentication for only a specific group. Some entry points to the packaging systems are accessible with an SSH key, which limits the protection of a two-factor authentication policy.

These are both good arguments. The counter argument is that such a policy improves the security of the project, even when unevenly followed. Manual audits can check for ongoing compliance.

In general, you can rely on good-faith actors to follow policies that are:

well reasoned with meaningful benefit to the project or the person
clearly and obviously communicated
well documented with a reasonably smooth user experience.

If all of those are true, and you have some way to manually check compliance, then it’s okay if the enforcement can’t be automated. This is especially true when partial compliance is a meaningful improvement over a default of zero compliance.

This post’s featured photo by Dim Hou on Unsplash.

The post Not all policy enforcement needs to be automated appeared first on Duck Alignment Academy.

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

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-25 10:18:38 UTC

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

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

Teamwork makes the dream work

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

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

Photo of the organizing team, with 26 people visible in the picture. That's not the whole team!

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

Busy, busy day

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

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

Photo of the event hall, with the organizers setting up tables with pizza.

Focus photo of one of the organizers bringing in 5 boxes of pizza.

The Fedora Community was represented by:

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

Historical moment: creation of SPOIWO

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

Group photo taken after the signing ceremony of the SPOIWO declaration. The printed declaration is visible in the back, propped up above the heads of the people in front.

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

Exceeding all expectations

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

Photo of the people gathering at the freebie table, taken from the upper balcony.

Photo of the event hall, showing the mass of people present during the lunch break. Taken from the upper balcony.

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

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

Partial Outage - 2 of 5 Openshift workers down

Posted by Fedora Infrastructure Status ( Fedora Account System Username

admin ) on 2026-06-25 09:30:00 UTC

Some hosts are being relocated and have been taken down for that purpose. OCP workers 04 and 05 are on the list.

While this should have been transparent to end users, it has caused unforseen consequences with the Apache LoadBalancer setup for Openshift Apps, when requests mistakenly get sent to …

On Podman 6 and weeding out legacy

Posted by Fabio Alessandro Locati ( Fedora Account System Username

fale ) on 2026-06-25 00:00:00 UTC

Podman 6.0 was released yesterday. This is a fairly big and important release, since they removed the support for cgroups v1, iptables, CNI, slirp4netns, and BoltDB. All features that depend on those dependencies have not been dropped; they are only supporting the modern replacements that have been available and the defaults for a while. In fact, they are now provided by cgroups v2, nftables, Netavark, Pasta, and SQLite, respectively.

I have been running Podman on my personal infrastructure for a few years now, mostly using Quadlet to manage services through Systemd. Personally, I do not envision any impact for me, since I already use all the new alternatives. Similarly, all other Fedora users should have a fairly smooth upgrade, unless they forced any of the removed options in their config, which should be very rare.

De CentOS Stream 9 a 10 con leapp

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-06-24 12:50:00 UTC

Ahora te voy a contar una de esas aventuras de SysAdmin que te ponen a sudar frío, pero que al final te dejan con una sonrisa de oreja a oreja.

Acabo de migrar mi servidor físico de CentOS Stream 9 a CentOS Stream 10 usando Leapp. La neta, aunque el proceso es noble, me topé con varias broncas en el camino (desde falta de espacio en boot hasta conflictos de red) y aquí te dejo el mapa completo para que usted, ¡pare de sufrir!

El Parote de Dracut Hostonly

Antes de que pudiera siquiera pensar en correr el preupgrade, me di cuenta de que mi partición /boot (de apenas 1 GB) estaba al 65% de capacidad. Como DNF necesita instalar el nuevo kernel y Leapp requiere mínimo 100 MB libres para maniobrar, no se iba a armar la cosa.

Como tengo XFS sobre LVM en la raíz (y esa chingadera no se puede encoger online ni offline), no podía simplemente reparticionar el disco. Por fortuna, hace un ratito te conté cómo apliqué el paro definitivo para tu boot con dracut hostonly.

Siguiendo esos pasos, reduje el peso de cada RAM disk de ~235 MB a ~69 MB. Eso me devolvió ~330 MB libres de inmediato, dejando mi boot al 32% de uso y abriendo la puerta para continuar con el upgrade sin tener que andarme metiendo en desmadres de reparticionar discos en vivo.

Note

La neta es que, mi servidor físico (local), no está en producción. Nomás que... me da weva conectarle un monitor y un teclado para moverle...

Preparando Leapp y el Preupgrade

Con el espacio libre resuelto, instalé las herramientas necesarias para la migración. En CentOS Stream, esto se hace a través de los paquetes de ELevate:

dnf install leapp-upgrade-el9toel10

Una vez instalado, corrí la herramienta de diagnóstico para buscar inhibidores (bloqueos del sistema):

leapp preupgrade

El Desmadre de ifcfg y los Inhibidores

El reporte inicial me arrojó un inhibidor de alto riesgo: Legacy network configuration found.

Resulta que en CentOS Stream 10 se eliminó por completo el soporte para los viejos archivos ifcfg-* en /etc/sysconfig/network-scripts/. Si no migras esto, tu tarjeta de red no va a levantar al reiniciar y tu servidor va a quedar incomunicado en la calle.

Migrar la conexión a formato `keyfile` (nativo de `NetworkManager`): Utilicé la herramienta nativa de NetworkManager para convertir el perfil.
```
nmcli connection migrate enp6s0
```
NetworkManager automáticamente borró el archivo ifcfg-enp6s0-1 y creó el nuevo perfil estructurado en /etc/NetworkManager/system-connections/enp6s0.nmconnection.
Limpieza de systemd: Leapp también detectó symlinks rotos de servicios viejos (como vdo.service y zabbix-server-mysql.service) que andaban estorbando. Los borré de volada:
```
rm -f /etc/systemd/system/multi-user.target.wants/zabbix-server-mysql.service /etc/systemd/system/multi-user.target.wants/vdo.service
```

Corrí de nuevo leapp preupgrade y esta vez arrojó exit code 0 (¡libre de inhibidores!). Aunque advirtió que mi procesador (AMD Family 15h) ya no tiene soporte oficial por Red Hat, verifiqué con el linker que soporta la microarquitectura x86-64-v3 sin bronca.

La Gran Migración

Con el semáforo en verde y mis respaldos al día, arranqué la descarga de paquetes. (mentiras... ni respaldé nada...)

Warning

¡Mucho ojo con la sesión SSH! La descarga e instalación del entorno temporal pesa más de 2 GB. Si tu SSH se desconecta por timeout a la mitad del jale, el proceso padre va a morir por un error de "Broken pipe" y va a tronar el instalador gacho. Para evitar desmadres, lo ideal es correr todo dentro de una sesión de tmux (o screen) para que puedas desconectarte y reconectarte sin perder la ejecución:

# Iniciar una sesión de tmux
tmux new -s upgrade

# Correr el upgrade
leapp upgrade

Si por alguna razón la red parpadea o se te cierra la sesión, sólo tienes que volver a conectarte y restaurar el cotorreo con tmux a -t upgrade.

Cuando el comando terminó con éxito y me indicó que todo estaba listo, ejecuté el reinicio:

reboot

El sistema se apagó, cargó el kernel especial de actualización (ELevate-Upgrade-Initramfs), ejecutó la transacción de paquetes y se volvió a reiniciar de manera automática.

Verificación y Limpieza Final

Al volver a entrar por SSH, verifiqué que ya estaba del otro lado:

cat /etc/os-release

Ya chingamos: CentOS Stream 10 (Coughlan)` con kernel 6.12.0.

Sin embargo, el comando systemctl is-system-running me devolvió el estado degraded. El culpable era el servicio systemd-networkd-wait-online, el cual estaba habilitado por una instalación vieja pero no tenía perfiles activos (ya que NetworkManager controla todo el desmadre).

Lo desactivé para dejar el sistema limpiecito:

systemctl disable --now systemd-networkd systemd-networkd-wait-online systemd-networkd.socket
systemctl reset-failed

Volví a checar el estado y finalmente quedó en running. ¡Chulada de sistema!

Conclusiones

La neta es que migrar con Leapp es bastante fácil si sabes leer los reportes y previenes los bloqueos antes de reiniciar. La clave de esta historia fue optimizar dracut y no dejar ningún perfil ifcfg de red vivo.

¿Qué te parece? ¡¿Te avientas la actualización de tus servidores a CentOS Stream 10?! Si no te animas, échame un grito. :)

Referencias

Dracut hostonly: El paro definitivo para tu /boot de 1 GB

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-06-24 11:45:00 UTC

Hoy me topé con un dolor de cabeza clásico de los que administramos servidores: la partición /boot de uno de mis servidores físicos (dev1.casa.g02.org) andaba agonizando. Apenas medía 1 GB y ya estaba al 65% de su capacidad. Con el upgrade que andaba haciendo, meter otro kernel iba a hacer que todo valiera madres por falta de espacio.

La primera ocurrencia lógica es: "pues le quito espacio a la raíz (/) y se lo paso a /boot". Pero, ¡oh sorpresa! Mi partición raíz está formateada con XFS y vive dentro de un volumen lógico (LVM). Para los que no sepan, XFS no se puede encoger (shrink). Así que esa idea valió madre de volada.

Investigando las entrañas del sistema, me di cuenta de que cada imagen de initramfs generada por dracut pesaba la grosería de ~235 MB. ¿Por qué tanto desmadre? Resulta que por defecto, el sistema las compila en modo "genérico", empacando todos los drivers habidos y por haber por si decides mudar el disco a otra compu.

Pero como mi servidor es una máquina física bien establecida, ¿para qué quiero drivers de Hyper-V, VMware o NVMe si mi disco es un SATA común y corriente? Ahí es donde entra la magia del modo hostonly en dracut.

Configuración de Volada

Para no andar batallando en el futuro, creé una regla persistente para que todas las futuras imágenes de boot se compilen optimizadas:

Crear el archivo de configuración: Creé un archivo drop-in para dracut con la opción mágica.
```
# /etc/dracut.conf.d/hostonly.conf
hostonly="yes"
```
Regenerar las imágenes: Reconstruí los RAM disks para todos los kernels instalados para aplicar el cambio inmediatamente.
```
dracut -f --regenerate-all
```
Verificar el espacio: Chequé cuánto espacio gané con este parote.

Resultados del Parote

El resultado de esta optimización fue inmediato y super chido:

initramfs-5.14.0-691.el9.x86_64.img: Bajó de 234 MB a 69 MB.
initramfs-5.14.0-710.el9.x86_64.img: Bajó de 235 MB a 69 MB.
initramfs-5.14.0-710.el9.x86_64kdump.img: Bajó a 43 MB.

¡Me ahorré más de 330 MB en total! El uso de la partición /boot bajó del 65% al 32%, dándome espacio de sobra para varios kernels más sin tener que andarnos preocupando por fallos de espacio en la siguiente actualización de DNF.

Warning

¡Ojo con la portabilidad! Si decides mudar tu disco físico a otra máquina con hardware totalmente diferente, el sistema podría no arrancar porque el initramfs optimizado no tendrá esos drivers. La ventaja es que la imagen de rescate (rescue) siempre se genera en modo genérico, así que puedes bootear con ella y volver a compilar el initramfs para el nuevo hardware.

Conclusiones

La neta es que es mejor optimizar lo que ya tienes antes de meterte en desmadres de reparticionar discos en caliente, sobre todo cuando tienes XFS en el camino. Con una sola línea de configuración le di un respiro enorme a la máquina y me ahorré un dolor de cabeza enorme.

¿Cómo la ves? Si andas sufriendo por espacio en tu partición de boot, ya te la sabes: ¡dale una oportunidad a hostonly, no?!

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

Day -1

Day 0

Day 1

Day 2

Day 3

Testing proposed updates

Test days participation

syslog-ng logo

La llamada

El modem

El drama

El gateway

El Firewall

Repartiendo IPs con radvd

La automatización (DDNS)

La prueba de fuego

Referencias

The Underrated Importance of Having Fun

Global Equity and Regional Access

Virtual Experience Enhancements

Looking Ahead

More in this series

Proposing new packages through PRs

Bulk review

Auto import into DistGit

Proposal vs prototype

Alertas automáticas en caso de fallos

Comandos de control y autenticación segura

Local Bot API Server: Control local sin límites

Mensajería enriquecida para reportes detallados

Conclusión

Referencias

Table of contents

Announcements

Council

FESCo

Decisions

Mindshare

Workstation / GNOME

Decisions

Server

Decisions

Infrastructure

Decisions

Release Engineering

Decisions

Quality

Design

Decisions

Docs

Decisions

Internationalization

EPEL

Decisions

ELN

Atomic

Decisions

CoreOS

Decisions

AI & ML

Decisions

RISC-V

Decisions

Security

Decisions

Go

Perl

Decisions

Rust

Other Discussions

Orphaning packages

Package updates

New contributor introductions

aarch64 builders and vmhosts reinstalls

Staging openshift workers network

Fedora Badges Revamp Project Progress Update

Metadata

Abstract

Particulars

Fedora People
Blog List

RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll