Kernel/DayToDay

The ever exciting day to day tasks that make the Fedora kernel run

Getting started

If you are new to maintaining the fedora kernel, you will need to make sure the following are set up

• Get a Fedora Account
• Create a Bugzilla Account
• Ask one of the existing Fedora kernel developers to add you to the appropriate permissions list (TODO: Document what these lists are)
• $ fedora-packager-setup to generate a fedora cert

Getting the Fedora kernel sources

$ fedpkg clone kernel

If you haven't gotten the appropriate permissions yet, you can clone anonymously

$ fedpkg clone -a kernel

Add a new patch to the kernel

See this page for details about adding individual patches to the spec file. You also need to make sure you actually apply the patches.

Test it with

$ fedpkg -v prep

to make sure it applies okay. You probably want to make sure it builds as well:

$ fedpkg local

When you are finished, you can do

$ rpmdev-bumpspec -c "Fixed that bug (rhbz 123456)" kernel.spec

to update the kernel.spec.

Push a change

Make sure you add any new files (new patches you are bringing in for the first time etc.)

$ git add fix-this.patch

$ git add fix-that.patch

Commit the result with git commit or fedpkg:

$ fedpkg commit -m "Fixed that bug (rhbz 123456)"

Once you've made sure the commit is how you want, you can push

$ git push origin HEAD:<branch name>

If you checked out the source anonymously, you will need to change $PROJECT_DIR/.git/config to use ssh:// instead of git:// e.g.

[remote "origin"]
        url = git://pkgs.fedoraproject.org/kernel
        fetch = +refs/heads/*:refs/remotes/origin/*

Change the git:// to ssh://

Once that is finished, you can do a scratch build

$ fedpkg build --scratch

Stable kernel update

For going from 4.x.y -> 4.x.z

Download the patch from kernel.org (not the incremental version)

Remove the last patch from the sources file e.g.

--- a/sources
+++ b/sources
@@ -1,3 +1,3 @@
 d3fc8316d4d4d04b65cbc2d70799e763  linux-3.19.tar.xz
 15d8d2f97ce056488451a5bfb2944603  perf-man-3.19.tar.gz
-f0f457204a1b286cc2ff04e470b01d64  patch-3.19.5.xz

Use fedpkg to upload the patch file to the cache

$ fedpkg upload patch-x.y.z

fedpkg has now updated the sources file for you in git.

Bump the stable update in kernel.spec

 # Do we have a -stable update to apply?
-%define stable_update 5
+%define stable_update 6

You can now run

$ fedpkg prep

to grab the code and apply patches. You will probably find conflicts and patches that no longer apply. Remove them from the .spec file. Repeat until success.

You can now commit and push like any other commit

Major Rebase

For going from 4.y -> 4.z . If/When 5.0 happens more steps will apply (maybe kernel.spec will be able to handle them without a problem by then)

This works similar to the stable update although it is a bit more complicated.

• Grab the base (linux-4.z) from kernel.org
• Grab the stable update (patch-xxx) from kernel.org
• Grab perf-man-XXX from what rawhide has
  • If rawhide is missing the binary you can update it from the kernel source tree:

cd tools/perf/Documentation
make
tar -czvf perf-man-4.<whatever>.tar.gz *.1

• fedpkg upload
• Update your kernel.spec

 # base_sublevel is the kernel version we're starting with and patching
 # on top of -- for example, 3.1-rc7-git1 starts with a 3.0 base,
 # which yields a base_sublevel of 0.
-%define base_sublevel 0
+%define base_sublevel 1

-%define stable_update 8
+%define stable_update 2

• • NOTE: If this is the first major rebase since a fedora release has reached EOL the global release will probably need to be adjusted

 # For non-released -rc kernels, this will be appended after the rcX and
 # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
 #
-%global baserelease 300
+%global baserelease 200
 %global fedora_build %{baserelease}

• There is no one 'right' way to rebase but the steps below have worked reasonably well
  • Checkout the last stable release on the rawhide branch (if rebasing to 4.x, checkout the rawhide release of 4.x)
  • diff the stable kernel.spec against the rawhide kernel.spec to get a patch. Ignore everything except the addition or removal of patches.
  • Apply the patch to the kernel.spec. You now have the patch state from rawhide at the last stable release.
  • Add/remove patches as appropriate
    • Grab any new patches from the rawhide stable tag
  • Run make prep
    • If you run into conflicts you can easily grab the patch from rawhide

git checkout <stable commit -- name-of-patch.patch

• • Check the configs to make sure all configs are still on
    • Once again, grab from rawhide as needed
    • In general, most new features should be left off unless it looks exciting and not dangerous (both requirements are necessary!)

Build/push happens like a normal

Rawhide

Rawhide is so amazing it gets its own special page