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: 28th July – 01st August, 2025
Continue readingThis 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: 21st – 25th July 2025
Continue readingThis 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: 14 July – 18 July 2025
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
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.
This week was focused on the service’s forge and tackling the challenge of source management.
Based on community feedback, advantages and assessing our requirements, I moved the service’s forge to Forgejo. This minimal, open-source alternative to GitHub and GitLab is simpler to self-host and has significantly smoothed out our testing process.
On the implementation front, I added support for parsing issue and push events in packit-service, which allow to support parsing commands from issue comments. That being done adding support for pull_request is only trivial now and have a solid understanding of packit-service‘s event model to trigger task execution.
I hit a technical dilemma when considering handling the case of packages with new dependencies in a single Pull Request and handle their sources. The workflow requires accessing the PR’s diff, resolving it into individual files, and submitting those sources to be built in COPR.
My initial solution to this problem was to create a dedicated organization in Forgejo where every new package would get its own repository to store its sources. However, my mentor advised against this model, we discussed and realized it would become too complex and non-intuitive to work with. Instead, he clarified the path forward to focus on simple packages for now and investigate how Packit already solves this by cloning the source repository.
What’s Next?
Stay tuned, more things to share next week 🙂
Hi everyone, I am Mayank Singh, currently working on a new service for simplifying the Fedora Package Submission Process, if you’d like to know more check my previous post here.
(27 June – 8 July):
I began working on the packit-service codebase as the foundation for our project. The first goal was to prototype the user flow by creating new APIs and handlers for functionalities like detecting new packages and linting.
Pretty early on, I hit a roadblock during a test run. When the service was deployed to listen for GitHub events, it wouldn’t reject any incoming events sent through the tunnel to the local deployment. After a lot of digging, I traced the issue to the Apache configuration in the mod_wsgi-express server. This server, responsible for serving the Flask-RESTx endpoints, was misbehaving and causing all the trouble.
Another hiccup was that the service was too heavy for my system to run locally in an OpenShift environment with GitHub. My mentor stepped in and suggested a helpful workaround, disable the unnecessary services for our use case and use GitLab instead in plain docker containers, as it’s much easier to spin up and test locally. Reported a few other problems in the deployment process for development regarding Bitwarden for secrets.
With those issues resolved, I went ahead and trimming the parts of the packit-service codebase that weren’t needed for onboarding new packages. This helped me better understand its event model and the use of Celery in task execution.
This week was mostly about reusing the existing packit-service codebase and resolving issues.
With the hard parts of setup and architecture done, the next steps would be to:
Stay tuned for more updates in the next blog post!
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: 7th – 11th July 2025
Continue readingThis is the story of how I became a contributor on the Fedora Release Schedule Planner application hosted on Codeberg.
I started my open-source journey when I got my first laptop. It was old and slow, but I needed it for school, so I started looking into how to fix this.
Continue readingThis 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: 30 June – 04 July 2025
Continue readingHey everyone!
It’s already been a month, I can’t imagine how time flies so fast, busy time?? Flock, Fedora DEI and Documentation workshop?? All in one month.
As a Fedora Outreachy intern, my first month has been packed with learning and contributions. This blog shares what I worked on and how I learned to navigate open source communities.
Hi everyone, I’m working on building a service to make it easier for packagers to submit new packages to Fedora, improving upon and staying in line with the current submission process. My main focus is to automate away trivial tasks, provide fast and clear feedback, and tightly integrate with Git-based workflows that developers are familiar with.
Continue readingCopyright © 2025 Fedora Community Blog
This work is licensed under a Creative Commons Attribution 4.0 International License.
Theme by Anders Noren — Up ↑
Recent Comments