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-setupto 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!)
- Check the configs to make sure all configs are still on
Build/push happens like a normal
Rawhide
Rawhide is so amazing it gets its own special page