Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])

−

<pre>

+

= Source checkout info =

−

cvs -d:pserver:anonymous@cvs.fedora.redhat.com:/cvs/pkgs co kernel

+

−

</pre>

+

−

and then

+

<pre>

<pre>

−

cd kernel/devel ; make prep

+

fedpkg co -B kernel

</pre>

</pre>

+

+

This gets you the git checkout and sets up branches for f13, f14, and master (devel).

+

Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.

You'll then be left with a kernel-2.6.? directory, containing both an unpatched 'vanilla-2.6.?' dir, and a linux-2.6.?-noarch hardlinked dir which has the Fedora patches applied.

You'll then be left with a kernel-2.6.? directory, containing both an unpatched 'vanilla-2.6.?' dir, and a linux-2.6.?-noarch hardlinked dir which has the Fedora patches applied.

+

+

The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:

+

+

<pre>

+

fedpkg co -Ba kernel

+

</pre>

= Contributing to the Fedora kernel =

= Contributing to the Fedora kernel =

Line 27:

Line 66:

* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).

* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).

* To request commit access to the Fedora kernel:

* To request commit access to the Fedora kernel:

−

* If you don't have one already, get a [[PackageMaintainers/Join|fedora account]]

+

* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one

−

* Visit [https://admin.fedoraproject.org/pkgdb/packages/name/kernel the package db entry for the kernel] and request access for the branch(es) you are interested in.

+

* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.

−

* Once approved, replace the :pserver:anonymous part of the cvs line above with :ext:YOURUSERNAME

+

* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.

−

* *please* subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.

+

* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.

−

* If you're interested in adding an out of tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first.

+

= Building =

= Building =

−

Commit access also gives you ability to build kernels that go out to end-users when you 'make build'. Please note the caveats.

+

Commit access also gives you the ability to build kernels that go out to end-users when you 'make build'. Please note the caveats.

* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.

* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.

* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.

* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.

* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.

* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.

* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].

* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].

+

+

= Policies =

+

Below are some of the policies we use when it comes to various aspects of the Fedora kernel

+

+

* [[KernelRebases]]

+

* [[KernelDriverPolicy]]

+

* [[KernelStagingPolicy]]

+

* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]

= Other handy links =

= Other handy links =

* [[KernelCommonProblems]]

* [[KernelCommonProblems]]

* [[KernelBugTriage]]

* [[KernelBugTriage]]

+

* [[Building a custom kernel]]

+

* [[Building a non-debugging kernel]]

+

* [[How to use kdump to debug kernel crashes]]

* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]

* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]

−

* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]

+

* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]

−

* Plans for the next release are discussed on the [[KernelDevel]] page.

+

* [[KernelTestingInitiative]]

−

* Links to viewcvs

+

* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.

IRC

Every two weeks, the fedora kernel team meets in the #fedora-meeting[?] channel on freenode.net for a one hour meeting. (Details on times at Meeting_channel)

Source checkout info

fedpkg co -B kernel

This gets you the git checkout and sets up branches for f13, f14, and master (devel).
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.

You'll then be left with a kernel-2.6.? directory, containing both an unpatched 'vanilla-2.6.?' dir, and a linux-2.6.?-noarch hardlinked dir which has the Fedora patches applied.

The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:

fedpkg co -Ba kernel

Contributing to the Fedora kernel

For one-off fixes, send them to the fedora-kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase

If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).

Building

Commit access also gives you the ability to build kernels that go out to end-users when you 'make build'. Please note the caveats.

The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.

Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.

If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through bodhi . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.