We are thrilled to announce the soft launch of Fedora Forge, our new home for Fedora Project subprojects and Special Interest Groups (SIGs)! This marks a significant step forward in modernizing our development and collaboration tools, providing a powerful platform built on Forgejo. For more background on why we chose Forgejo, see the previous community blog post.

A New Home for Fedora Collaboration

We designed Fedora Forge as a dedicated space for official Fedora Project work. Unlike pagure.io, which hosted personal projects alongside Fedora Project work, we focus on supporting subprojects and SIGs. This structured approach streamlines our efforts and simplifies contribution to official Fedora teams.

We are migrating projects from select teams, including: Release Engineering (RelEng), Council, and Fedora Engineering Steering Committee (FESCo). This phase-based approach lets us test the platform thoroughly before opening it to more subprojects and SIGs.

However, If you are a leader of a team or SIG and would like to request a new organization or team on Fedora Forge, please see our Requesting a New Organization and/or Team guide for detailed instructions.

Seamless Migration with Pagure Migrator

The Pagure Migrator is a key part of this launch. We developed and upstreamed this new Forgejo feature to ensure smooth transitions. This utility moves projects from Pagure-based Git forges seamlessly. It brings over historical data like pull requests, issue tickets, topics, labels, and users. As subprojects and SIGs move over, their valuable history and ongoing work come with them. This ensures continuity and a painless transition for contributors.

Get Ready for What’s Next!

This soft launch is just the beginning. As we test the waters by settling these first subprojects and SIGs on Fedora Forge, we will be preparing to open it up in the coming weeks. We are confident that Fedora Forge will become an invaluable tool for the community, providing a robust and modern platform for collaboration.

Please use the #git-forge-future tag on Fedora Discussion to communicate your feedback and the #fedora-forgejo:fedoraproject.org channel on Fedora Chat to collaborate with us.

The post Announcing the Soft Launch of Fedora Forge appeared first on Fedora Community Blog.

And just like that, the Fedora 43 Wallpaper has been finalized!

I recently attended Flock (for the first time ) at the beginning of the summer. I had the privilege of facilitating a workshop with Emma Kidney about getting started in the Fedora Design Team. You can read Emma’s workshop recap here if you didn’t get the opportunity to attend! Participants helped create inspiration for the F44 wallpaper.

Now that it’s the end of the summer, I thought it might be a good time to discuss the F43 wallpaper process.

Let’s rewind to the start

If you’re not a blog post person, then you can always see the process documented on the F43 ticket here.

The first step involves a list of people or topics in STEM that the community can vote on. We were choosing between people whose last name starts with R, since we’ve followed the alphabet for the past 18 wallpapers.

Jess Chitas wrote on the ticket, “Thinking of ones that would make really nice wallpapers- Vera Rubin was an Astronomer who worked on galaxy rotation rates. Rooting for this one myself, a galaxy wallpaper would be epic! Wilhelm Röntgen essentially discovered the X-ray. Something with the skeleton could be cool? Henry Augustus Rowland worked with diffraction gratings (lots of colour!!)

Vera Rubin and Wilhelm Röntgen made it into the poll (which can be found here on Fedora discussions), but Sally Ride ultimately won!

Sally Ride

Sally Ride (May 26, 1951 – July 23, 2012) was a physicist and astronaut who became the first American woman in space on June 18, 1983. The third woman ever!

After finishing her training at NASA, she served as the ground-based CapCom for the second and third Space Shuttle flights. She helped develop the Space Shuttle’s robotic arm, which helped her get a spot on the STS-7 mission in June 1983.

Two communication satellites were deployed, including the first Shuttle pallet satellite. Ride operated the robotic arm to deploy and retrieve SPAS-1, which carried ten experiments to study the formation of metal alloys in microgravity. 

Mind Map

The mind map we created together in a design team meeting.

Based on Ride’s career, we started gathering images. We looked up the books she had worked on that had exclusive photographs of her missions. Her work in education and STEM made us think of the infographic posters that usually hang in classrooms. Ride’s mission happened in the 80s, which is technically too late to classify as mid-century. However, the bright, colorful mid-century space art and retro futurism felt perfectly suited to represent her optimism and approach to learning in STEM.

Sketches

I usually do quick sketches on paper or my iPad and came up with these three options. The first one isn’t a wallpaper, so much as a blueprint for an exploring spacecraft. More realistic vs ones with exaggerated shapes for children’s books. I was much happier with the second and third compositions. That’s why we always push to come up with multiple ideas, because it’s like working a muscle. The design muscle!

People commented on the ticket that we could go forward with sketch 2 or sketch 3. I brought sketch 2 into Krita and started drawing over it on a new layer. I wanted to map out how the clouds would billow out and where stars could be.

Rough and Final Drafts

At this point, I received feedback from people on the Fedora Design team. It was suggested to bring the clouds on the right down a little and perhaps add a moon in the sky. The color and arch of the sunrise and sunset were also things we discussed in our weekly team meeting (open to community members ), and I believe they turned out pretty great.

Post F43 Thoughts

Without the community, these wallpapers wouldn’t happen! If you’re a passionate artist or designer, you’re more than welcome to participate in this recurring project.

The post Fedora 43 Wallpaper Wrap Up appeared first on Fedora Community Blog.

Over the past few Fedora releases, the Anaconda team has been gradually replacing the GTK-based installer with a new web-based interface. As this work expands, we want to share a quick update on the current status, where things are headed, and how to stay involved.

Current Status

• The WebUI was introduced in Fedora 42 Workstation Live ISO as the  default installer, supporting Live image installations only. DNF-based installs are not yet supported, this is planned for a future phase.
• A change proposal for Fedora 43 has been approved, enabling the WebUI by default for all Fedora Spins and KDE.
• Community testing has already taken place, and we’ve received an incredible amount of useful feedback. Thank you to everyone who participated and helped us shape the experience! We are now actively reviewing and processing that feedback to guide the next phases of development.

Below is an example of the WebUI installer in action, as currently used in one of the Fedora Spins.

Documentation Update

The existing Fedora Installation Guide is outdated and no longer reflects the current installer. Our team is open to co-owning updated installer documentation and hosting it upstream to keep it accurate and maintainable.

To reduce the documentation overhead, we’re working on autogenerated docs directly from the source code. While this is still early work, we have a small but up-to-date example live now: Web UI Installer documentation

Roadmap (Shared at Flock 2025)

Here’s a rough view of how we plan to roll out the WebUI across Fedora editions:

Get Involved

We’re open to contributions across all areas of the project – from design suggestions, to feature development, testing, and documentation. If you’re interested in helping out or learning more, join us in the #anaconda:fedora.im Matrix channel. We’d be happy to talk!

The post Anaconda WebUI: Progress Update and Roadmap appeared first on Fedora Community Blog.

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

Week: 1st – 5th September 2025

Infrastructure & Release Engineering

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

Fedora Infra

• Disablement of this account
• Opt-in for AWS region to ap-southeast-6 acct:125523088429
• Flatpak fails to install runtime/org.fedoraproject.Platform/x86_64/f42 (checksum mismatch)
• OOM on mailman3
• Outage: Upgrade of Copr servers – 2025-08-28 06:00 UTC
• oraculum Bugzilla API key has expired
• Fix group ‘db-sig’
• create private mailing list and pkgdb group for “ai-packagers-sig”
• 400 – Bad Request (redirect_uri) logging into https://www.pagure.io/kernel-tests
• Need to delete user account in FAS that has been already deleted in Discourse (discussion.fedoraproject.org) due to violations (spam, AI, etc.)
• OpenShift worker logs are not archived on log01

CentOS Infra including CentOS CI

• CentOS Stream 9 Testing does not connect to t_functional
• Let’s make the composes layout consistent
• Reinstall existing recycled server for other main reference mirror (rdu3 swap)
• Archived spam
• [DC move hardware swap] – migrating internal mirror.rdu2 role to different hardware
• [SN#1654] git.centos.org migration to GitLab

Release Engineering

• Untag mozjs128-128.11.0-7.fc44
• F43 stable push requests
• Stalled EPEL package: perl-Cairo
• Orphan python-zope-exceptions
• rpms/zabbix7.0 epel10 was accidentally retired by merging rawhide, which introduced dead.package
• Please remove gnome-sig commit access from several packages
• Can’t orphan golang-github-ryszard-goskiplist
• Fedora 43 Beta Freeze (Starts August 26)
• Unorphan xmount
• xmount should be version 1.2.0 from new/migrated repository
• Please unretire python-pylint-venv
• Unretire qtile
• Unretire rust-secret-service
• Unretire python-qcengine
• Access to fedoraproject SMTP server for sending orphaned packages report
• Improve the mass-tag script so it notify if something is broken and verify permissions

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

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

Fedora documentation has been perceived as a weak point for years. But in reality, the situation is very mixed. I would like to briefly describe the current situation and how we got there. Based on this experience, I will present 5 theses about how Fedora Docs can be improved in the long term.

The current situation

The project is ‘dormant’ to say the best, showing all the signs of a deteriorated community and a ‘dead’ project.

• The team is dissolved with no consistent organization.
• Documentation has broken down into an active and maintained part, which is managed by the editions (mostly installation instructions), and a non-edition-specific part, which is largely obsolete with a few highlights maintained by groups with a special interest.
• There is a long list of unprocessed MRs, but no plan for improvement. 

At the same time, the situation is better than it was about 4 years ago, when our documentation consisted of a completely outdated “Installation Guide” and an equally outdated “Administration Guide,” whose instructions were insufficient for installing any of our distribution media or performing any administrative tasks. We now have a strong documentation at least for some Editions, but huge shortcomings in Edition agnostic areas, specifically Administration topics.

This situation is quite unsatisfactory. And it has negative consequences for Fedora as a whole. Our distribution is considered “difficult” to use, at least in part due to missing or even misleading long outdated documentation. Other distributions are more attractive and are considered „easy“ and „quick“ to use. They are gaining users and thus also potential contributors, which Fedora is losing.

An example of this effect is ArchLinux, whose documentation is considered excellent and exemplary and – among others – a recommendation to choose it.

In the end, the documentation malaise contributes to the fact, that the outstanding engineering results achieved through the great personal commitment of many Fedora contributors do not receive the attention and impact they deserve.

A brief look back – a roller coaster ride 

To investigate possible causes, it is helpful to briefly recall how this situation developed. 

• At the beginning, i.e., during the first about 10 releases, we saw strong development in the area of Fedora documentation. At its peak, it consisted of a wide range of documentation on topics of varying scope. From a broad Administration Guide to specialized documentation on specific topics such as Grub or setting up a home server, everything was included.
• After the initial enthusiasm and appeal of something new, a period of decline began: A gradual decrease in the number of participants, meetings becoming increasingly rare over time due to a lack of participants, and eventually no longer taking place at all; loss of focus; loss of organization, goals, and planning. And with each new release, the amount of documentation decreased.
  At the time, the technology, DocBook and Publican, was identified as the root cause of the problem. It was then replaced by another technology – Antorra and the Git workflow.
• Once again, there was a brief resurgence of interest due to the appeal of something new. A large amount of the existing documentation was migrated, partly manually and partly automatically. Once the technical part was done, things started to slow down again, and in the end, only Petr remained as a “lone warrior” with a completely outdated installation guide and an equally outdated administration guide.
• The revitalization in 2022 initiated by Ben, initially brought a strong upswing, not so much in the number of active contributors but above all in the continuous work of an active core group on a defined and “focusable” task. There were different sub-areas that could be worked on by different contributors and produced a common result.
  And a new problem was raised: a high hurdle for authors due to the Git workflow. This is familiar to “technicians”, but who write rarely documentation, and is a hurdle for authors and users who like to write but are hindered by unfamiliar tooling. 
  And just another change in technology was brought into play: the wiki.
• Then, in 2023, it all came crashing down again, this time because two key members had to leave and we had no one to replace them. Another downturn began. Various initiatives involving online workshops were unable to stop this.
• Since mid-2024, the Docs Team has once again become a dormant entity. There is no focused planning or goals setting at all. 
  Instead, once again, a switch to a different technology came up: the documentation plugin of the discussion forum .

Afterall, we’re stuck in a slump again. Not quite as bad as around 2020, but you can feel it everywhere. At the moment, the current curation does not make the dire situation quite so blatantly obvious. However, with each new release, the shortcomings of generic, edition-independent documentation become increasingly apparent and urgent, particularly the Quick Docs and, above all, the Administrator’s Guide.

How to improve – the essential requirements 

1. A change in technology is not a solution

Fedora has repeatedly discussed and implemented technical solutions or changes to resolve the Docs issues. However, the actual cause were not technical problems, but rather a gradual decline in the communities, recognizable by the typical symptoms mentioned above.

A technological change is more likely to destroy a community or accelerate a decline that is already taking place. It ends up uncovering new usage problems that don’t reduce the original problem but further hinder a solution.

Instead, it is beneficial to adapt the technology to the needs and existing skills in the community.

2. Extraordinary strong community building essentially required

The solution to Doc’s predicament is to build a strong community (or several communities) and put serious, extraordinary effort into it to make them viable and sustainable right from the start. In retrospect, this was the fatal flaw of Ben’s otherwise very successful 2022 initiative. We started with too few resources and focused too early on documentation work.

Any Docs community requires special efforts to be sustained. A community focused on a technical product has a quasi-natural long-term focus. In a Docs community, this focus is highly volatile. It requires members who continuously maintain communication, actively involve new members, recognize and seize opportunities to initiate communication within the team and with other teams, as well as continuously propose projects and goals that provide a focus for several different skills and members.

Such extensive and continuous community work is a prerequisite for effective documentation, alongside the actual documentation tasks. In the best case scenario, this happens automatically, with someone naturally stepping forward to take on this tasks. Otherwise, it is something that needs to be specifically considered and promoted when building a Docs team.

3. Self-contained short “Instructions” instead of monolithic “Guides”

Monolithic guides require considerable time and commitment. An author has to familiarise themselves not only with the chapter in question, but also with the documentary context. Follow-up work in subsequent or preceding sections may also be necessary to maintain over all consistency of content. This is an unavoidable consequence of the inherent structure and nature of extensive monolithic text bodies. 

This peculiarity is problematic for a group of volunteer authors consisting mainly of regular users. Changes in membership are a regular occurrence in open source projects. Replacing or adding an author in a team writing and maintaining a monolithic text body is difficult and time-consuming, resulting in additional barriers. At the end it makes successful and productive work highly volatile.

However, it’s not just a matter of community, but also of usability and quality assurance. Shorter and thematically focused texts enable users to achieve success more quickly. The text may optionally provide links to broader information for those who want to acquire deeper knowledge. And updates due to changes in the software are easier and require less effort and quicker to accomplish and thus enable their timeliness.

4. Upstream first

The objective of Fedora documentation are the Fedora specific implementations and regulations, and how to accomplish a specific task, or use a specific software, in the Fedora runtime environment. This is an area where users and maintainers can excel. And this is where they are the experts. 

Upstream projects usually provide general, distribution-agnostic documentation themselves. And there are numerous books and general information sites on specific software or Linux technologies. It makes no sense and is unnecessary effort to duplicate this documentation. The frequently referred to ArchLinux documentation is not a model to follow. Infact, it is in large parts a curation of various upstream documentations, compiled in one place and therefore the advantage of being easy to find.. 

The gap is applying this general info to your specific situation and Fedora distribution. And sometimes, finding this general info in an accurate, up-to-date, and readable version. A consistent quality feature of every Fedora documentation article is therefore its focus on the use case in Fedora and valuable links to upstream and more general documentation. 

5. Bridging the gap between „engineering“ and „writing“

In Fedora, packaging and documentation are two completely different areas that do not interact or communicate in a systematic way. Although every “engineer” is quick to assure you that documentation is incredibly important, they are incredibly quick to disappear when it comes to contributing to it.

Vice versa, Fedora users are quick to post on our communication channels looking for solutions to problems or configuration suggestions for software. But they quickly disappear when it comes to making the solutions available to others. 

At the end, writers get stuck because technical and/or valid usage informations are missing.

The documentation of the editions demonstrates an efficient alternative. Documentation is part of the scope of their Working Groups, thereby uniting technical and application/usage knowledge. 

Of course, we cannot just apply this approach to all documentation. But it offers a promising strategy: Encourage and initiate communication between various experts – technicians, writers, users – but without introducing additional workload. The challenge is to create opportunities for such exchanges within the context of our existing Fedora Project activities. As an example, we could include an evaluation of the relevant documentation in the kernel test days. Or, we could dedicate one time slot on Flock to an exemplary technical area and its documentation. Implementing this strategy is without any doubt difficult and requires a high degree of innovative ideas, imagination and experimentation. And it will take some times.

Coda

The outlined strategy goes far beyond what can be achieved with a familiar SIG. A central coordinated initiative is needed to bring together several SIGs on a project-related basis. It also changes the tasks of the Docs team. Writing documentation is still part of the job, but a key focus is now on curating Fedora documentation and specifically initiating and instigating opportunities for exchange between different experts — in other words, community building.

The post Fedora Docs – current state and conclusions from our experiences appeared first on Fedora Community Blog.

We are excited to announce the general availability of the MetaSource (or MDAPI 4) in both the staging and production Fedora Infrastructure environments. The release includes an architectural rewrite of the MDAPI from Python to Go, making it a performant source of RPM repositories metadata as a REST service with 1:1 API compatibility. More details about the developments and acknowledgements are below.

Rewrite

The project faced a critical challenge due to its dependence on SQLite3-based RPM repositories metadata which were deprecated by the Fedora Linux 41 release. Rather than applying temporary workarounds on the existing codebase, we took this opportunity to fundamentally redesign the project. The improvements included optimized processing of XML-based RPM repositories metadata, swifter response towards HTTP REST operations, interactive documentation for ecosystem experience, stellar coverage across functional testcases among other things. The move from Python to Go programming language allowed us to take advantage of the performance benefits and resource efficiency – all while ensuring that the solution stays simple enough to maintain for a high-throughput HTTP service for a cloud-native first deployment.

Comparison

Sustained querying

MetaSource (or MDAPI v4.0.0) performs roughly 33% faster than MDAPI v3.1.7 while using about 30% lesser memory than that on sustained querying operations. This means that MetaSource would be able to address approx 50% additional requests without furthering resource consumption. Please note that the results may vary depending on unknown variables like network bandwidth and querying nature.

Concurrent querying

MetaSource (or MDAPI v4.0.0) performs roughly 52% faster than MDAPI v3.1.7 while using about 14% lesser memory than that on concurrent querying operations. This means that MetaSource would be able to address approx 110% additional requests without furthering resource consumption. Please note that the results may vary depending on unknown variables like network bandwidth and querying nature.

Appeal

This project would not have been possible without the help of Akashdeep Dhar, Kevin Fenzi, David Kirwan, Michal Konecny, James Antill, Steve Milner, Shounak Dey and countless others who have either contributed to Fedora Infrastructure projects ecosystem or the createrepo_c project. We ask the readers to contribute to the project by developing, maintaining, testing or documenting the project.

The post Introducing MetaSource (or MDAPI 4) appeared first on Fedora Community Blog.

This isn’t a goodbye. I have mixed feelings about this, but it’s not the end. My Outreachy internship with the Fedora Project DEI team is wrapping up, but I’m here to stay. I remember my first discourse post, quoting from it: “… regardless of the outcome, I’m here to stay!” Yes, I meant it. 

It’s been an awesome journey working with the community, contributing to projects that matter, and learning along the way. I’m grateful to everyone who supported me, and a special thanks goes to my mentor, Jona Azizaj.

Here’s a look at what I’ve been working on recently:

Event Checklist

We now have a Fedora Project Inclusive Event Checklist live in Fedora Docs:
Read it here
Discussion thread

We got feedback from the community and this helps organizers plan inclusive, accessible Fedora events worldwide. If you have suggestions, you can open a ticket or drop by the Fedora DEI Matrix room.

Community Proposals

1. Supporting Regional Communities

See the Discussion thread

This proposal explores how Fedora Project can better support local communities with resources and events. I’d love to see more people plan meetups in their regions – I’ll be glad to help anyone curious about starting one.

2. Fedora Wallpaper Proposal

See the Discussion thread

Together with Mat H, we proposed creating a series of region-inspired Fedora wallpapers – a simple but powerful way to celebrate Fedora Project’s global diversity. For each release, the Fedora Project could feature a wallpaper inspired by a different world region, helping people feel seen and connected to the project.

Upcoming Outreach: High Schools & Universities

See the Discussion thread

I’m also working on outreach plans for high schools and universities.

• High school events: fun, inspiring introductions to open source and free software (under 90 minutes).
• University events: deeper engagement with contributions, workflows, and career pathways (up to 3 hours).

Earlier this year, I helped organize a Fedora event at Murang’a University, which went smoothly thanks to early approvals and strong collaboration with the local tech club. Now, I want to take this energy to high schools and beyond, helping the next generation of contributors discover Open Source and the Fedora Project.

Looking ahead

This internship might be ending, but my Fedora journey isn’t. I’ll keep contributing to DEI efforts, community engagement, and documentation.

Thanks again to the Fedora Project community for making this such a meaningful experience. This is just the beginning.

About me (and a little note)

Ok, small break here (and no, this isn’t an ad ). Just wanted to put this out there: I’m also starting to look for new roles where I can grow as a Community Manager, developer, product manager, and technical writer — while staying active in open source. If you’ve read this far, and later come across opportunities – or just want to know a bit more about me – feel free to reach out (easiest way? Connect with me on LinkedIn).

So, who am I?

• My biggest strength is community work – engaging with people, running events, building connections. That’s where I’ve got real, paid experience.
• On the side, I’ve been coding. Right now I’m learning C, aiming for low-level systems and kernel stuff.
• I’ve been freelancing in technical writing for about 2 years.
• I’m a curious person, so catching up with new tools comes naturally. Example: I’d never touched Fedora Project’s Antora docs before, but picked it up fast and started contributing. I even showcased that in my Outreachy portfolio.

Sometimes I say: “given a chance, I’ll prove it—and challenge myself.”

On community work:
I’ve been active since 2022 in my campus days (not long ago, ). MLSA, GDSC, Avalanche, and of course Fedora. More about that in this post: How open communities shaped my journey.

I really enjoy advocacy work – it feels natural to me.

And yeah, shoutout to MatH, who inspired me to install a custom Fedora Linux setup and run it with sway. It has been a fun ride configuring things to my liking.

Finally… I guess you probably won’t read those linked posts there (But you probably don’t). Don’t worry, I was just joking with you there .

See you around, and thank you for reading this far!

Cheers, Your Friend in Open Source | Open Source Freedom Fighter

The post Not a goodbye, wrapping up my Fedora Project DEI internship appeared first on Fedora Community Blog.

As a part of our move from Fedmsg to Fedora Messaging in the last year, we announced the general availability of the Webhook To Fedora Messaging service. While the project was developed to replace the (now decommissioned) GitHub2Fedmsg service, we did not have a user interface for managing webhook binds with Fedora Messaging. The migrating users of the GitHub2Fedmsg service had to hence request for the creation of webhook binds via an issue tracker and the incoming users had to utilize the Swagger UI to create the webhook binds by themselves – which worked just fine but was definitely not ideal.

Given that since then, the project has evolved significantly into an ecosystem of Webhook-based communications to the Fedora Messaging. The support for Forgejo and GitLab repositories was added to support the Fedora Project’s and CentOS Project’s transitions to these platforms respectively. With active discussions around the frontend requests and design architectures, we finally came around to making an interactive user interface available for the Webhook To Fedora Messaging users. Please feel free to give it a try on the production environment and consider helping with the maintenance efforts of the project!

The post Introducing User Interface for Webhook To Fedora Messaging appeared first on Fedora Community Blog.

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

Week: 25 Aug – 29 Aug 2025

Infrastructure & Release Engineering

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

Issues closed this week:

Fedora Infra

• We removed a spam thread from the devel mailing list and banned the user. 
• We closed an issue for an expired Copr certificate; it was not an infra problem.
• We removed spam from the Fedora Users mailing list and banned the offending user. 
• We reactivated a user’s Fedora.im account that was reported as deactivated.
• We banned a user and deleted their spam messages from the fedora-users list. 
• We closed a duplicate ticket for spam on the Fedora Users mailing list. 
• We fixed a repository checksum mismatch for a CentOS Stream 9 package.
• We fixed an issue where repository forks became read-only, preventing pull request merges.
• We resolved a user’s login issues, likely caused by a propagation delay for new accounts. 
• We fixed outdated package data by resolving sqlite metadata generation and storage issues.
• We increased vCPUs on Libravatar.org

CentOS Infra including CentOS CI

• Document Flight Plan for Red Hat IT network team
• [SN#1580] [spike] : investigating options/alternatives for the upcoming DC move 
• Rollout new internal TLS certs for Stream infra 
• CS RPM signing not working
• Please confirm CS Koji is posting messages to fedora-messaging correctly

Release Engineering

• We unretired the python-asciitree package for a new maintainer on rawhide and f43.
• A request to unretire python-cx-oracle was withdrawn as a newer package exists. 
• We unretired the mpop package for a new maintainer on rawhide and f43.
• We created the f44-openjdk sidetag to enable the BuildJdkOncePackEverywhere feature for Fedora 44.
• We granted a user commit access to the ykpers package for EPEL branches.
• We granted a user commit access for the stalled openspecfun EPEL package request. 
• We granted a user commit access for the stalled libXScrnSaver EPEL package request. 
• We unretired the python-requests-pkcs12 package for a new maintainer for f43 and rawhide.
• We unretired the gputop package for a new maintainer on the rawhide and f43 branches. 
• We deleted an accidentally created branch in the rpms/json repository. 
• We unretired pgbouncer
• Stalled EPEL package: fltk
• Stalled EPEL package: libXp
• We removed s390x from noarch builders to prevent SRPM and noarch jobs from stalling.
• We closed a request to unretire the bettercap package, awaiting a new package review. 
• We resolved an unmergeable pybind11 pull request by fixing incorrect server-side repository permissions.
• Stalled EPEL package: pam_yubico

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

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

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

Week: 18 Aug – 22 Aug 2025

Infrastructure & Release Engineering

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

Fedora Infra

Closed issues this week:

• We added a new sponsor to the Mindshare Committee FAS group to help with administrative tasks.
• We blocked a user who was sending spam to our mailing lists.
• We removed spam from the Fedora Users list and banned the responsible user.
• We removed a spammer from the fedora-users list, banned their account, and deleted the message.
• We resolved a connection failure for the staging cloud-image-uploader by updating it to use a new certificate.
• We directed a user to the correct process for becoming a package maintainer instead of creating repositories directly.
• We fixed the Fedora 43 metalinks by manually updating the mirror manager’s master directory list.
• We closed an issue regarding incorrect log messages from the mirror manager crawler as the behavior is by design.
• We created DNS subdomains for the new Forgejo deployment in staging and production. 
• We found a user’s incorrect git remote caused their fedpkg upload to fail. 
• We fixed hardcoded links in our staging distgit that pointed to production authentication. 
• We redirected the outdated infrastructure wiki to our current documentation.

CentOS Infra including CentOS CI

Closed issues this week:

• rebase ncurses pkg for infra needs (el9)
• [SN#1309] fixing infra repo dependency for el 9.3 
• New tags needed for Samba v4.23 in Storage SIG for CentOS Stream 9 and 10
• [NFV SIG] Create group for NFV SIG in https://gitlab.com/CentOS/
• Provide rpm-specs-latest.tar.xz / git-seed-latest.tar.xz with c10s content 
• [SN#1700] Custom container image to serve SIG’s docs?

Release Engineering

Closed issues this week:

• We changed ownership of packages with non-responsive maintainers.
• `f45` keys were created.
• Untagged `llibcerf` build
• Resigned f43 tagged packages with f44 key
• Unretire `efitools`
• Properly retired golang-codeberg-gbcox-mpris-webhook package
• We retired FTI packages
• New repo for `intel-npu-driver`
• Updated `tag2distrepo,keys` for `coreos-pool`.
• We added `released_on` properties in Bodhi
• Few Stalled Epel Package tickets

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

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

Hi, I am Mayank Singh, welcome back to this blog series on the progress of the new package submission prototype, if you aren’t familiar with the project, feel free to check out the previous blogpost here.

Extending Forgejo support

As Forgejo is expected to become the git forge for Fedora in future and based on community discussions. I thought it did be great to support Forgejo in this project.

packit-service supports both GitLab and GitHub thanks to OGR library. It provides a unified interface for interacting with git forges.
The library has a good support for GitHub and GitLab features but the Forgejo integration is still not quite on par with them, few important functions like adding comments and reactions are still missing.
I worked on adding the support for the necessary parts so that packit-service can work with Forgejo.
There are few bugs related to serialization in the code, which I plan to fix this week.

New Package Builds from New Pull Requests

I’ve added a simple handler to read from a new Pull Request and its description to parse packit commands. This allows users to trigger a build for a new package without needing a packit configuration file in the repository.

For example, adding this line the PR description will trigger a new build for this particular package name.

/packit copr-build package_name: <libexample>

The system dynamically constructs a minimal package config and feeds it into Packit’s internal build logic. Test jobs are expected to work as well, although this is yet to be fully verified.

The current implementation is a quick prototype that reuses as much of the existing packit-service logic as possible. There’s still more work to be done around building the full package context.
My mentor has also shared feedback suggesting a cleaner approach, which I’ll be iterating on in the next phase.

What’s Next?

• Fix remaining serialization bugs.
• Build and test the Testing Farm integration for running test jobs on the built packages.
• Improve the source handling logic based on recent feedback.

Thanks for reading and stay tuned for more next week.

The post Simplifying Package Submission Progress (15 July – 22 July) – GSoC ’25 appeared first on Fedora Community Blog.

This week in the project involved bug fixes, integration cleanup and small improvements.

Bug Fixes and Workarounds

A key function required for the Forgejo integration which is used to fetch files from repositories was broken in the current Fedora 42 release due to an upstream bug in Forgejo’s OpenAPI spec. While the bug is already fixed in newer versions, it couldn’t be backported cleanly due to dependency constraints.

To move forward, I upgraded the service to run on Fedora Rawhide. However, Rawhide had its own quirks, the celery package was broken. To work around this, I installed celery directly from PyPI instead, which resolved the issue for now.

There were also several issues related to how data was being passed between the celery tasks. In particular, raw comment objects from Forgejo events were being passed around, which are not JSON-serializable and caused failures. With help from my mentor, added fixes in the logic to ignore the problematic object from being included in the payload.

Improvements and features

Enabled the `fedora-review` tool for all COPR builds in the codebase by monkey-patching the API call to enable fedora-review, which is not available directly otherwise from the packit API. This allows us to get a list of tasks and requirements for Fedora packaging compliance for the corresponding build of the package.

As of now, COPR builds and testing of the builds work. I started working on status reporting, it’s still rough, and I attempted to get comments working, but I’ll need to add more support in the OGR library to implement commit status properly.

What’s Next?

• Add support for Forgejo commit status API.
• Comments about status and builds from the service
• Add unit tests for the new functionality
• Upstream Forgejo code to packit-service

The post Simplifying Package Submission, Progress (22 July – 29 July) – GSoC ’25 appeared first on Fedora Community Blog.

As part of my Outreachy internship with the Fedora Project, I’m building an API to modernize how Fedora plans its release cycles.

With the help of my mentor Tomáš Hrčka, the goal is to replace the current XML-heavy system currently on pagure.io with something flexible, easy to use, and well-structured.

Explore the source code on Codeberg: Fedora Release Schedule Planner.

Why This Project Matters

Fedora’s current release planning tools rely on manual XML editing, which is challenging for newcomers and difficult to scale. This project aims to:

• Improve contributor experience with interactive API documentation.
• Support seamless querying and updating of release data.
• Allow smoother integration with Fedora’s broader tooling.

Progress Highlights

• Framework migration:
  • Transitioned from Flask to FastAPI (PR Link)
  • Leveraged Pydantic for data validation due to deep integration with FastAPI
  • Introduced auto-generated Swagger documentation

• Code refactor:
  • Adopted modular architecture with clean routing (PR Link)
  • Standardized endpoint naming
• CI/CD setup:
  • Integrated a CI pipeline using Forgejo Actions for automated testing (PR Link)

These changes already make onboarding contributors easier and improve testability.

What’s Next

I’m excited about these upcoming milestones:

• Refining and aligning tests with the FastAPI structure.
• Integrating with Fedora infrastructure for live data.
• Strengthening the deployment pipeline for production.

Challenges

My biggest challenge and opportunity is simultaneously learning new backend technologies like FastAPI and OpenID Connect for authorization, along with techniques to improve developer onboarding. Though the learning curve is steep, my mentor’s continuous guidance on the Fedora infrastructure, career development and general advice makes it manageable.

Reflections

This internship has been an incredible learning experience. I’m gaining hands-on exposure to backend architecture, continuous integration practices, and open-source collaboration. More importantly, the chance to build something lasting for Fedora makes the work genuinely rewarding.

There’s a lot left to tackle, and I’m looking forward to pushing it further.

The post Outreachy Internship Update: Building the Fedora Release Schedule Planner API appeared first on Fedora Community Blog.