This wiki was updated to MediaWiki 1.37. If you notice any issues, please report them to admin[at]

openSUSE:Maintenance update process

Jump to: navigation, search

Maintenance requests are requests by packagers to release an update for an already released distribution. This page gives on overview of the process of handling these requests.


Knowing the process behind a maintenance release allows to understand the importance of the steps of the process and should help with submitting packages that can be quickly pushed through the process.

The following flow-chart diagram illustrates the maintenance package update process. It includes several different OBS projects: Maintenance update process.png

Let's look a bit closer at some of the steps:

Check if a Leap package is inherited from SLE

Some packages from openSUSE Leap are shared with SLE. Those packages are automatically merged after the SLE-update is released. To check if your package is inherited you can look in the following package:

openSUSE Leap 15.4:

openSUSE Leap 15.4 has 4 seperate updates sources.

  • OSS repo (openSUSE:Leap:15.4:Update): largely branding and config packages only
  • Non-OSS repo (openSUSE:Leap:15.4:Update:NonFree): non-free but redistributable packages like Opera
  • Backports repo (openSUSE:Backports:SLE-15-SP3:Update): all non SLE packages in openSUSE Leap 15.4
  • SLE repo (via all SLE imported binary packages for openSUSE Leap 15.4

How to find out:

osc sm PACKAGE

If the package comes from openSUSE:Leap:15.4:Update or openSUSE:Backports:SLE-15-SP4:Update , submit to these ones. The openSUSE Maintenance team will process it.

If there is a SUSE:SLE-15:Update entry (or 15-SP1 , 15-SP2 or 15-SP3), submit it there. It will be mirrored into the SUSE Internal Buildservice and processed there.

Write a meaningful changelog-entry

For the maintenance team it's important, that a meaningful changelog-entry is provided to prepare the patch-documentation and rating. For a detailed description, please refer to the patches guideline, but here is a list of the most important information:

  • Bug reference (boo#123456, CVE-2016-1234,...)
  • short description for the fix
  • Added/modified/dropped patchnames

Open a maintenance request

After the package is ready to submit, you need to open a maintenance-request. You can achieve this with the following commands:

One package for one openSUSE release:

 $osc mr $prj $pkg $release_target

Several packages for one openSUSE release:

 $osc mr $prj $list $of $packages $release_target

Several packages for several openSUSE releases:

(This only works if your packages are in one project and the packages were branched with '$osc mbranch $pkg' or '$osc branch -M $prj $pkg')

 $osc mr $prj

Maintenance team review

The maintenance team decides whether an update will be released. They authorize the initiation of the maintenance process and start the ball rolling. They interact directly with the packager to coordinate the submission of the package that contains the fix. They ensure that the bugs being fixed are what are actually being put into the maintenance update. The decision making process is outlined in more detail below.

Source Review

The openSUSE review team does a manual review of the submission following these guidelines. Those of the review team who intend to review the maintenance submissions will find the SRs in each project's "Update" sub-project. For example, to review the submissions for openSUSE Leap 15.1, the reviewer would find the submissions in the "openSUSE:Leap:15.1:Update" project. (In reference to the graph above, note the differences between the "openSUSE:Maintenance" project and the "openSUSE:Leap:15.1:Update" project. Reviewers shouldn't be looking in the "openSUSE:Maintenance" project to do their reviews.)

QA review

openSUSE maintenance updates are tested with openQA and by our community. We are waiting around 5 days, to see if issues are reported, before we release the update.

If you want to test all pending updates, you need to register the following repository: openSUSE Leap 15.4:


From Leap 15.4, the part of Leap that comes from SUSE Linux Enterprise is using both patchinfos and dedicated channels. The channels are the same tools we use on SUSE Linux Enterprise for filtering and aggregating the binaries built from a source package and that we want to deliver to a specific product.

This change, better consolidated with Leap 15.4, unifies the way to delivery maintenance updates in Leap and SUSE Linux Enterprise.

IBS internal service links:

Given that Leap is built also with sources not coming from SUSE Linux Enterprise, we have some blocklisting mechanism for filtering out binaries from SUSE Linux Enterprise that are not supposed to land on Leap (like for example branding).

The blocklist is embedded in the perl generator script for updates: (hosted on SUSE internal gitlab).

SUSE internal gitlab - tools /

Videos / Slides

SFScon 2020 - Marina Latini - openSUSE maintenance updates