Development & Packaging Archives – Fedora Community Blog

Category: Development & Packaging (page 1 of 15)

All articles in this category are related to engineering teams in the Fedora Project, in particular teams working on packaging and release engineering. https://fedoraproject.org/wiki/Development

Packit as Fedora dist-git CI: final phase

Hello Fedora Community,

We are back with the final update on the Packit as Fedora dist-git CI change proposal. Our journey to transition Fedora dist-git CI to a Packit-based solution is entering its concluding stage. This final phase marks the transition of Packit-driven CI from an opt-in feature to the default mechanism for all Fedora packages, officially replacing the legacy Fedora CI and Fedora Zuul Tenant on dist-git pull requests.

What we have completed

Over the past several months, we have successfully completed the first three phases of this rollout:

Phase 1: Introduced Koji scratch builds.
Phase 2: Implemented standard installability checks.
Phase 3: Enabled support for user-defined TMT tests via Testing Farm.

Through the opt-in period, we received invaluable feedback from early adopters, allowing us to refine the reporting interface and ensure that re-triggering jobs via PR comments works seamlessly.

Users utilising Zuul CI have been already migrated to using Packit. You can find the details regarding this transition in this discussion thread.

The Final Phase: Transition to Default

We are now moving into the last phase, where we are preparing to switch to the default. After that, you will no longer need to manually add your project to the allowlist. Packit will automatically handle CI for every Fedora package. The tests themselves aren’t changing – Testing Farm still does the heavy lifting.

Timeline & Expectations

Our goal, as previously mentioned, is to complete the switch and enable Packit as the default CI by the end of February 2026. The transition is currently scheduled for February 16, 2026.

To ensure a smooth transition, we are currently working on the final configuration of the system. This includes:

Opt-out mechanism: While Packit will be the default, an opt-out mechanism will be available for packages with specialised requirements. This will be documented at packit.dev/fedora-ci.
Documentation updates: Following the switch, we will also adjust official documentation in other relevant places, such as docs.fedoraproject.org/en-US/ci/, to reflect the new standard.

We will keep you updated via our usual channels in case the target date shifts. You can also check our tasklist in this issue.

How to prepare and provide feedback

You can still opt-in today to test the workflow on your packages and help us catch any edge cases before the final switch.

While we are currently not aware of any user-facing blockers, we encourage you to let us know if you feel there is something we have missed. Our current priority is to provide a matching feature set to the existing solutions. Further enhancements and new features will be discussed and planned once the switch is successfully completed.

Bugs/Feature Requests: Please use our issue tracker.
Discussion: Join the conversation on discussion.fedoraproject.org.
Chat: Reach out to us in the #packit:fedora.im channel on Matrix.

We want to thank everyone who has tested the service so far. Your support is what makes this transition possible!

Best,

the Packit team

Fedora Design Team © CC BY-SA 4.0

2 Weeks Left: The Flock 2026 CFP Ends Feb 2

January 20, 2026 / Justin Wheeler / 0 Comments

Prague is calling! The deadline for the Flock 2026 CFP (Call for Proposals) is fast approaching. You have until Monday, February 2nd to submit your session ideas for Fedora’s premier contributor conference.

We are returning to the heart of Europe (June 14–16) to define the next era of our operating system. Whether you are a kernel hacker, a community organizer, or an emerging local-first AI enthusiast, Flock is where the roadmap for the next year in Fedora gets written.

If you haven’t submitted yet, here is why you should.

Packit as Fedora dist-git CI: Phase 1 completed

March 4, 2025 / Laura Barcziová / Comments Off

Hello Fedora Community,

We are excited to share an update on the Packit as Fedora dist-git CI change proposal. This initiative aims to transition Fedora dist-git CI to a Packit-based solution, deprecating Fedora CI and Fedora Zuul Tenant. The change affects the triggering and reporting mechanism for tests but does not alter the tests themselves or the test execution service (Testing Farm). The transition will be gradual, allowing maintainers to try the integration out, provide feedback and catch issues early. You can read more about the benefits and why we are doing this in the proposal.

A banner image with a black background, dotted with various stars, much like a galaxy system. Four rockets with colors of the Fedora Four Foundations leave a colored trail behind them that overlaps, as the rockets propel toward the right-side of the image in lockstep. White text is overlaid on the image, reading "The Fedora Project community." This image is often used with Fedora elections.

Image by Ryan Lerch. CC BY-SA 4.0

2024 Git Forge Evaluation

April 5, 2024 / Matthew Miller / Comments Off

Vol. I – Fedora Council 2024 Hackfest

During the Council’s February 2024 hackfest, we discussed the future of Fedora’s git forge – that is, the platform Fedora uses for version control and tracking for packages, source code, documentation, and more. This topic has been around for quite some time. If you are just coming into this conversation, or would like a refresher, #git-forge-future is a good place to start.

Instead of one huge post, the Fedora Council divided the follow-ups from our hack-fest into a mini-series of posts throughout April that will cover all the topics we discussed and made decisions on. In each post, we will walk through one core topic, and share our discussion and thought process on how we reached our outcomes. The first in this series, because why not start strong 🙂 , is an update on our git forge evaluation. Read on for important information.

Growtika, Justin W. Flory. CC BY-SA 4.0.

Forthcoming Kubernetes (K8S) changes in F40/Rawhide

January 30, 2024 / Brad Smith / Comments Off

The Kubernetes team has released Kubernetes v1.29, which is the version that will be included in Fedora 40. There are four important changes to Kubernetes in Fedora associated with this release that may merit attention.

A small package wrapped in brown paper and string with the text "Fedora Packaging"

Photo by freestocks on Unsplash

Kubernetes and Fedora Linux 37 Update

October 31, 2023 / Brad Smith / Comments Off

Kubernetes updates for Fedora Linux 37 have been on hold pending an update to the version of Go available Go has now been updated (thanks Alejandro Sáez!). Kubernetes 1.25.15 was submitted to testing on 29 October and will be available for general download 1 week later. See Fedora dist-git for current information on what versions of Kubernetes are available for Fedora in stable and testing.

Kubernetes Support On Fedora Linux 37

September 28, 2023 / Brad Smith / 1 Comment

Kubernetes v1.25 is the version available for Fedora Linux 37 from Fedora repositories. Starting with Kubernetes v1.25.12, Kubernetes developers changed the version of the go language used to compile Kubernetes from v1.19 to v1.20. Fedora 37 currently provides go language v1.19. As a result, the latest version of Kubernetes available in the Fedora repository is v1.25.11 which is several versions behind the current v1.25 release. Kubernetes v1.25.12 included an important security patch for clusters that include Windows nodes.

Photo by freestocks on Unsplash

A new way to find a package reviewer

July 25, 2023 / Matthew Miller / Comments Off

Package reviews are an important part of how Fedora delivers well-built RPMs. When one contributor wants to add a new package, another packager has to check it first. It’s how we all hold each other to the high standard we’ve set for ourselves. Of course, that means to add a new package to the repos, you first have to find someone to do the review. Last week, I added a new way to do that: the Package Review Swaps category on Fedora Discussion. Huge thanks to Felix Kaechele for the idea and initial process design.

Important changes to software license information in Fedora packages (SPDX and more!)

July 29, 2022 / Matthew Miller / Comments Off

On behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce!

New docs site for licensing and other legal topics

All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at https://docs.fedoraproject.org/en-US/legal/. Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki.

Fedora license information in a structured format

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at https://gitlab.com/fedora/legal/fedora-license-data. This data is then presented in easy tabular format in the documentation, at https://docs.fedoraproject.org/en-US/legal/allowed-licenses/.

Historically, this information was listed in tables on the Fedora Wiki. This was hard to maintain and was not conducive to using the data in other ways. This format will enable automation for license validation and other similar process improvements.

New policy for the License field in packages — SPDX identifiers!

We’re changing the policy for the “License” field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects.

Updated licensing policies and processes

Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated.

New guidance on “effective license” analysis

Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way.

When do these changes take effect?

The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that!

Thank you everyone!

A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/

Backwards-incompatible changes in Bodhi

May 9, 2022 / abompard / Comments Off

The 6.0 release of Bodhi — Fedora’s update gating system — will be published in a few days. We will deploy it to production a couple weeks after the Fedora release. It includes backwards-incompatible changes. Here’s what you need to know.