CI moved to Copr

tl;dr: we have started to use an internal Jenkins instance in combination with a public Copr – please update the URLs of DNF nightly builds repos and do the same with your project ;-D

I thought that it might be a good idea to incorporate all the ideas I had on my TODO list into our continuous integration process before I leave the DNF team. I would say that this effort was quite successful and that the process has improved a lot. I believe that it might be interesting (or even inspirational) for you to know how it works.

Originally, we started with a Jenkins job hosted by Fedora infrastructure which build RPMs on every new commit pushed upstream. Later, it turned out that it would be really nice if it would test submitted pull requests as well. There is a Jenkins plugin for almost anything you can come up with. That goes for GitHub pull requests as well. Unfortunately, you have to ask Fedora infrastructure to install any additional plugin you need. And what is worse, the plugin is designed so that the GitHub credentials must be configured globally. But we didn’t want to provide access to our repository to anyone who use the same Jenkins instance.

Since we were a bit impatient to wait whether the plugin can be changed, Michal succeeded to install Jenkins on our internal OpenStack instance. This change allowed us to structure (hence speed up) the continuous integration process a bit. I mean, we do not build just RPMs of DNF. We build also hawkey and the core DNF plugins and even two more dependencies – librepo and libcomps. Among other things, this allows us to develop against the most recent versions of these libraries and it also provides us with an additional assurance that a new version of these libraries will not break DNF. You can imagine that building RPMs of five projects for two architectures and for multiple versions of Fedora (sequentially) can take some time. With our own Jenkins instance, we don’t need to be ashamed to create 5 different Jenkins jobs where each is split to two sub-jobs, one for each architecture. Moreover, one job can be configured as an upstream of another job so that e.g. if a new build of hawkey was successful, Jenkins may trigger a build of DNF to test whether the new version of hawkey did not break DNF. A nice side effect of this split is also that e.g. a new change in DNF does not trigger a new build of hawkey – that means less builds at the same time, hence faster builds.

At the same time, something has happened with the hosted Jenkins. All DNF builds started to fail there. In the Job configuration, there is no “Multiple SCMs” option any more. I suspect, that the Multiple SCMs Plugin broke after an update or they have uninstalled this plugin. This proved to be another advantage of having an own Jenkins instance along with the fact that Fedora infrastructure does not guarantee availability of their Jenkins instance. This issue have caused another problem. Originally, with the launch of the continuous integration process, we also promised users to provide nightly builds of DNF. With a failing public Jenkins and a succeeding but private Jenkins, users have lost the access to the nightly builds.

Luckily, the people around Copr, have recently added the possibility to upload SRPMs to Copr. Copr is most likely the best place were to host RPMs of project snapshots. So, we decided to use Copr to build RPMs on every Git change (and the pull requests as well). This again sped up the build, allowed us to build on more architectures and we also got the best public hosting for our nightly builds.

To sum it up, our continuous integration have transformed a lot. Our internal Jenkins instance currently watches our GitHub repository (including the pull requests), on every change, it builds the SRPM of the appropriate component (hawkey, DNF, core DNF plugins, librepo, libcomps) using tito (in most cases), then it uploads the source RPM to Copr which builds the binary RPMs (using the RPMs from the previous builds), reports the result through emails and/or GitHub API and potentially triggers builds of the other dependant projects. If I gained your attention, I would be honoured, if you would like to take a look at the CI script here: You can find some instructions to set your own Jenkins job up there as well. Please note that the ability of tito to upload a SRPM to Copr is coming soon. Then you probably won’t need this script any more.

Since the new approach works very good, we are going to disable the job at If you are still interested in using nightly builds of DNF (at your own risk!), please, enable Copr rpmsoftwaremanagement/dnf-nightly, e.g. using:

dnf copr enable rpmsoftwaremanagement/dnf-nightly

DNF 1.1.1 and DNF-PLUGINS-CORE 0.1.11 Released

Good News everyone,

after another 3 weeks, new versions of DNF and DNF-PLUGINS-CORE have been released. DNF 1.1.1 brings mark command feature while DNF-PLUGINS-CORE adds 4 new filters from “dnf list” command and extending functionality of `–arch` and `–tree` switches. Additionally around 15 bugs have been fixed.

For more detailed information about the releases see DNF and DNF plugins release notes.

DNF 1.1.0 and DNF-PLUGINS-CORE 0.1.10 Released

Another crucial release of DNF is out with a lot of new features and over 20 bug fixes.

Basic control mechanism for weak dependencies was added. Now you are able to query for all weak dependencies forward and backward way in repoquery and allow/disallow installing weak dependencies through `install_weak_deps` DNF configuration option.

Moreover with all DNF stack you will be able to take advantage of rich dependencies in F23 along with newly added MIPS architecture support.

Although DNF team encourages users to “do the things in the right (DNF) way”, we still listen to community and implement the most requested features, the DNF is missing from yum. I am talking about `–skip-broken` in install command. To install the biggest given set of packages without raising error, when all dependencies cannot be satisfied, could be achieved by setting `strict` DNF configuration option.

More information can be found in DNF and DNF plugins release notes.

Enjoy this release and look forward to the next version.

DNF 1.0.2 released

Finally there’s the new release of DNF which fixes the bugs which were highly demanded from Fedora community (former yum users). When a transaction is not successfully finished DNF preserves downloaded packages until the next successful transaction. The resolution configuration hints are printed to the output and user is notified which packages were skipped during update in case there are conflicts. The new –repofrompath switch was added and many more.

Yum is dead, long live DNF

Do you wonder why you don’t have yum package installed on the Fedora 22 clean installation and why you get warnings when calling /usr/bin/yum executable or any yum-util plugin about deprecation of Yum? You see right, Yum is gone. Literally. And DNF is the new default Fedora package manager.

DNF is fork of Yum with the state-of-art SAT-based dependency solver and was supposed to replace Yum in Fedora 22. Now with the release of DNF version 1.0  it is the time to fulfill this destiny. This radical change was inevitable. Yum would not survive the “Python 3 as default” Fedora initiative meanwhile DNF is able to run on Python 2 and Python 3. Command line interface was preserved when it made logical sense of command semantic. Fortunately DNF Python API is completely different from Yum. All known incompatibilities between these two projects are documented. In Fedora 22 Core is DNF only and Yum is officially considered dead project. If anyone wants to download Yum she or he can. The package is still called the same and Python API remains for the time being. Just the yum executable file was renamed to yum-deprecated, and yum calls from command line are redirected to DNF. This way you can maintain both Yum and DNF on the system at the same time.

The reason of initiating DNF project was because of the biggest three pitfalls of Yum: undocumented API,  broken dependency solving algorithm and inability to refactor internal functions. The last mentioned issue is connected with the lack of documentation. Yum plugins are using any method from Yum code base thus any change there would cause the sudden crash of the Yum utility. The DNF aim was to avoid mistakes made in Yum. From the start all exposed API functions were properly documented. The tests were included with almost every new commit. No quick and dirty hacks are allowed. The project is directed by agile development – the features that have the greatest impact on users are operatively implemented with higher priority.

Nowadays DNF team is working on porting the rest of popular plugins from Yum to DNF and improving the user experience. To make the switch for you a little easier we have implemented DNF migration plugin for importing installed packages, groups and transaction metadata from Yum to the new Fedora package manager. Happy transition and enjoy the DNF ride!

Jan Silhan, by DNF team

DNF 0.6.5 and DNF-PLUGINS-CORE 0.1.6 Released

Good news, everyone. New version of DNF and DNF-PLUGINS-CORE was built for F22 and F23. The documentation of yum and DNF differences was extended by yum plugin alternatives part and erase command  was deprecated in favor of remove command name. DNF is getting more and more stable with 20 bug fixes while DNF-PLUGINS-CORE 0.1.6 newly adds Config manager.

With regard to packaging changes, DNF is running on Python 3 from F23 and dnf-yum compatible subpackage does not conflict with yum anymore. Read more on release notes of DNF and plugins.