openSUSE:Kernel git

Jump to: navigation, search
There are two openSUSE kernel repositories. Development happens in the kernel-source repository. This is a quilt-like series of patches plus scripts and .spec files to produce the kernel RPM package. There is a second repository, called kernel (also known as the expanded tree). This one has the same layout as the upstream kernel repository, so you can directly compile it or hack on it.

Getting Started

First, install git, the newer the better. git-core-1.5.6 or newer is known to work, if you are using an older GIT and encounter problems, please report them (ideally with a patch attached) to If you do not encounter problems, please update the sentence about which minimum version is known to work.

Setting up a clone

 git clone

This will create the master branch only, to set up further branches, do

 git checkout -b $branch origin/$branch

and later just

 git checkout $branch

Use git branch -r to see which branches exist. See also #Branch Names below.

Some people prefer to have a separate clone for each branch they work on. You can either copy the clone in this case, or clone again, but use the --reference option (assuming that kernel is a pre-existing clone):

 git clone --reference kernel kernel-15.2

Note that if you are only working with one or a few branches in a clone, it is a good idea to delete the other branches and change the configuration to only fetch the branches you are interested in (by default, everything is fetched if you do a git pull).

 git checkout -b openSUSE-15.2 origin/openSUSE-15.2
 git branch -D master
 git config remote.origin.fetch +refs/heads/openSUSE-15.2:refs/remotes/origin/openSUSE-15.2

If you are going to commit anything, it is time to introduce yourself:

 git config [--global] "Your Name Comes Here"
 git config [--global] your@email

Branch Names

The openSUSE kernel branches are named openSUSE-$version, e.g. openSUSE-42.3 or openSUSE-15.1. SLE branches use SLE${version} for the GA branches and SLE${version}-SP${number} for service packs. In the kernel-source repository, each branch also has a README.BRANCH file indicating the purpose of the branch.

An overview of active branches can be found on

Please note: branches for products which reached EOL will be removed from the git repositories.

Get your current kernel config

The easiest way to get your current kernel config :

  cp /boot/config-`uname -r` .config

Using the kernel-source repository

As already noted, development happens in the kernel-source repository. This repository also hosts the .config files and rpm spec files to build rpm packages. To clone it, run

 git clone
 cd kernel-source

The install-git-hooks script sets up a commit hook and other helpers, so that common mistakes are caught automatically. The layout of the repository is following

  • config/$arch/$flavor: Config files
  • patches.*/: Patches applied to the vanilla tree. and patches.rpmify are special in that these are also applied to the kernel-vanilla flavor.
  • rpm/: Spec files and scripts that end up in the rpm package.
  • kabi/: Kabi reference files.
  • scripts/: Scripts for use inside the repository.

To generate a quilt tree so that you can add patches or update existing ones, run


This unpacks the vanilla linux tarball in the tmp/ subdirectory, applies the patch series and generates the necessary metadata for quilt. The script should be used to refresh patches, so that they have a common format. Each kernel patch requires a header, see the README file for details. New patches need to be added to the series.conf file in the top-level directory. If you are backporting an upstream patch, put it in the sorted section of that file using git_sort (a set of scripts inside the SUSE kernel repository). When you are done, commit your changes with


This will launch an editor with a pre-generated changelog entry. If you are only adding patches, it is enough to use the changelog as is, otherwise expand it if needed and type :wq. Please use scripts/log when committing, so that the changelog has a unified format.

Refreshing other patches

After a patch is added somewhere in the middle of series.conf, some patches further down may have to be refreshed. This can be tiresome when adding a larger patch series. In this situation, you can:

  • git tag base
  • add all patches to series.conf
  • ./scripts/log # without refreshing any other patch
  • git rebase -i -x ~/bin/kseries_check base
  • git tag -d base

The content of ~/bin/kseries_check is:

 if hash rapidquilt 2> /dev/null ; then
   scripts/ -q --rapid --dry-run || exit 1
   scripts/ -q --fast > /dev/null 2>&1 || exit 1

It will drop you in a shell whenever a patch needs to be refreshed. Do the refresh and then run:

  • git reset HEAD^
  • ./scripts/log
  • git rebase --continue

Building kernel packages


This creates a source package in the kernel-source subdirectory. You can use rpmbuild to build a kernel RPM, or if you have a Build Service account, use the osc_wrapper script:

 scripts/osc_wrapper                                  # local build
 scripts/osc_wrapper kernel-source/kernel-debug.spec  # locally build a flavor other than "default"
 scripts/osc_wrapper upload home:$login:kernel        # remote build

Submitting your changes to the kernel team

Please remember that the recommended way to have a patch included in the openSUSE kernel is to push it upstream (Linus' tree for master, v5.x.y for released products). If you want to change something in the packaging, scripts or config files, send your patches to