- Use the sauce-patch commit-template (debian/commit-templates/sauce-patch) for every commit that should be retained upon a rebase
- Use the rebase-intrepid script (debian/scripts/misc/rebase-intrepid) to rebase the tree on top of the Ubuntu Intrepid git tree.
- Report any bugs in the script, it will be used for maintenance of other git trees.
- Rebase on the Ubuntu Intrepid kernel tree only when it has been tagged for upload
- This is usually signified by a commit with a message of the form Ubuntu-2.6.26-X.YZ and a corresponding tag of the same name
- Rebasing at such logical points ensures that the kernel has already been test compiled and most pre-upload problems have been resolved.
- Since this tree is expected to be rebased only a few times during the development cycle, it will have only a few un-controlled ABI bumps
- It is expected that every rebase will yield an ABI bump, but where the Ubuntu kernel might have jumped 3 ABIs, this kernel will only jump 1 version.
- Refuse to rebase on the Ubuntu Intrepid kernel at all.
- This will make your patchset hard to merge into the main tree toward the end of the development cycle if we choose to.
Setup your git environment. e.g. Add these lines (appropriately modified) to your .bashrc
export GIT_AUTHOR_NAME="Amit Kucheria"; export GIT_AUTHOR_EMAIL="firstname.lastname@example.org"; export GIT_COMMITTER_NAME="Amit Kucheria"; export GIT_COMMITTER_EMAIL="email@example.com";
Clone the git tree from zinc
git clone git://kernel.ubuntu.com/amitk/ubuntu-intrepid-lpia.git
You need an lpia chroot to work with the kernel. Creating one is covered in DebootstrapChroot.
Enter the kernel directory and run the rebase script. This should download the latest version of the Ubuntu kernel tree, export your patches, and rebase your patchset on top of the Ubuntu kernel commits.
If everything goes smoothly (no conflicts during rebase), you will be left with your patches rebased on an updated Ubuntu Intrepid kernel in a new branch auto-tmp-remote
- There are instructions on how to make this your master branch if it passes your inspection
- If the rebase fails, fix the offending patch(es) and carry these changes to your master branch as above
When committing a new patch, use the following commands
git add <file names> git commit -s -F debian/commit-templates/sauce-patch -e
This ensures that your new patch is marked SAUCE. This allows the rebase script to treat it correctly.
To change configs, I find it convenient to use the prepare target in the build system as follows
First merge the split configs
cd debian/configs/lpia for cfg in config.*; do cat config >> $cfg done rm config cd ../../..
Make changes to the config and copy it over
fakeroot debian/rules prepare-lpia make O=debian/build/build-lpia/ menuconfig (Make config changes as required) cp debian/build/build-lpia/.config debian/configs/lpia/config.lpia
fakeroot debian/rules updateconfigs
- Commit the config changes as a SAUCE patch
gitk is a useful tool to visualize the commit history.