Hi everyone, I’m Mayank Singh, and I’ve been working on a GSoC 2025 project aimed at simplifying the packaging process in Fedora.

I have been working on making an implementation of the new package review process, where everything happens in one place around git. Instead of switching between Bugzilla tickets, for hosting the source rpm and logs. Instead new contributors can review their packages through pull requests.

Let’s dive into a brief comparison between the current Bugzilla process and the new one.

The current Bugzilla process

If you want a package that is not available in Fedora repositories yet, the process looks something like:

• Package Recipe: start by writing a .spec file, which declares your package sources and instructions on building it.
• Build: the same specfile is then used to build a Source RPM.
• Upload: upload the Source RPM and specfile to a file host or a place like fedorapeople.
• New Ticket: Now, start a new bugzilla ticket with the SRPM url and Spec url along with the description of the package.
• Fedora-review-service: This service builds your package in COPR from the provided SRPM and specfile URL, runs fedora-review after a successful build to report compliance.
• Review Cycle: A reviewer comes along, provides feedback, make changes, upload again. This creates a tedious, repetitive cycle for every minor change.

This process isn’t reliable, it forces developers to constantly juggle multiple tools and tabs. This creates a fragmented and disjointed experience.

The new process

We try to solve this problem by trying to focus the workflow around git. A tool developers already use daily. The process is made much simpler in these steps:

• Fork the central package review repository on forgejo.
• Commit your .spec files and patches.
• Start a new Pull Request.

The service takes care of the rest for assisting in the review process.

Once the Pull Request is open, the following automated actions are triggered to assist the review:

Checking the latest entry here, we can find the Testing Farm run and inspect the logs to trace the cause of failure.

The checks failed due to a broken package and its dependencies.

• Automatic Build: The service clones your changes into a COPR build environment and builds the package.
• Direct Feedback: After a successful build, the fedora-review tool runs, and its formatted output is posted directly as a comment in the pull request discussion.
• Testing: The service runs installability and rpmlint checks using Testing Farm.
• Commit Status Updates: The status of the COPR build and all tests is reported back directly to the pull request via commit statuses (the green checkmarks or red crosses).

If a change is needed, one can just push a new commit and the service takes care of building and testing now.

Check out the service here: review

Under the Hood

The service is based on the packit-service codebase to handle COPR builds, Testing Farm integration, and orchestration of the actions described above with forgejo support.

Repo link: packit/avant

Future Scope

Looking ahead, this workflow can be extended to transfer the packages into dist-git after approval of the package.

Big thanks to my mentor and Fedora community for guidance throughout the GSoC timeline.

Feedback’s appreciated ! Thank you.

This week in the Fedora project, we did some small changes to the details and reporting of information in the service.

Small Changes

Better Review Comments

Previously, we were fetching the text version of the fedora-review report, the problem was it had way too much text for a comment and I had to parse the text file, to format the comment before posting into sections in collapsible tags manually.

While testing, I found out that the tool also publishes a json version with proper segregation of categories, items, checks and the related documentation to each rule. It made it much easier to parse and comment.

Clearer Status Reporting

Another small change was to report the status for install-ability and rpmlint checks separately from Testing Farm. My mentor suggested this approach to make it easier for users to interpret feedback.

One can check detailed logs of each run by going to dashboard through the details button.

Testing

I’m still working through some challenges with unit testing. The tricky part is mocking external dependencies to properly test the integration code in the service. The aim is to catch smaller bugs earlier with better coverage in ogr, the library that’s being used for interacting with forgejo.

What’s Next?

We almost have a way to review packages directly within a Forgejo repository. This will allow us to set up a dedicated repo for performing package reviews with automated feedback from tools and experienced packagers.

In the future, this idea could be extended further as Fedora moves to Forgejo, even handling dist-git setup.

For now, my next tasks are:

• Deploying the service
• Writing setup instructions for local development
• Setting up the bot account
• Completing the work needed for merging the relevant code upstream

I’m grateful to my mentor, František Lachman, for his constant support and guidance.

This week in the project, we covered the changes on how we handle the pull request to make it a more intuitive process.

No config? No problem!

One of our key goals is to reduce friction for contributors as much as possible. With that in mind, my mentor suggested we align our required file structure with the standard dist-git layout, which defines a package simply with a specfile and patches for the upstream source.

Previously, our service required a packit.yaml configuration file in the repository just to trigger COPR builds and Testing Farm jobs. We have now eliminated this dependency. By parsing the specfile directly from within a pull request, our service can infer all the required context automatically. This removes the need for any boilerplate configuration.

Small troubles

As I have mentioned before that we are currently using the rawhide container images for development, since the current stable Fedora release does not have the required versions of the python bindings for forgejo.

The problem was I was running a dnf update before installing anything in the container and for some reason ca-certificates got upset in the container, which caused the service to not be able to communicate over the network.

With some hit and trial, I discovered that removing that line and simply just not updating can work. That fixed it for now, but the good news is Fedora 43 is going to enter a Beta or a package freeze phase so there should not be any such problems now.

What’s Next?

With these core features now in place, my focus for the upcoming weeks will be on two main tasks:

1. Documentation: I’ll be writing documentation for the service, covering its usage for end-users and development guidelines for future contributors.
2. Upstreaming Code: The final step is to contribute the Forgejo integration code back to the upstream OGR and packit-service projects so the wider community can benefit from the forgejo integration, still in progress.

This week in the project, we added the support for status reporting of the package actions via commit statuses.

Continue reading