Building the Ubuntu kernel package(s)
Note, it is recommended to build the packages on the kernel team's server, ie zinc. They will typically build faster and the subsequent upload will also be faster if uploaded from zinc.
The following commands are for building the linux kernel package. Note 'fdr' is an alias for 'fakeroot debian/rules'. Again, if on zinc, be sure to chroot into an environment first, eg dchroot -c maverick
cd ubuntu-<RELEASE> fdr clean dpkg-buildpackage -S -rfakeroot -I.git -I.gitignore -i'\.git.*'
It's suggested to wrap the above commands into a script.
At some point in the development cycle, the final upstream version that was chosen will be released, eg for Karmic it was 2.6.35. Once the final upstream version is released, we need to upload the orig.tar.gz file for the linux package. Using Maverick as an example, the following steps were done to upload the orig.tar.gz file. This only needs to be done once.
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.tar.gz mv linux-2.6.35.tar.gz linux_2.6.35.orig.tar.gz #note the _ vs - in the name scp linux_2.6.35.orig.tar.gz zinc:. # ssh to zinc dchroot -c maverick cd ubuntu-<RELEASE> fdr clean dpkg-buildpackage -S -sa -rfakeroot -I.git -I.gitignore -i'\.git.*' # then upload the package as usual (see "Uploading the Ubuntu kernel package(s)" section below) # NOTE: do not remove the linux_2.6.35.orig.tar.gz file as it is used to then generate the .diff.gz file in subsequent builds/uploads.
The following commands are for building the linux-meta package. Again, if on zinc, be sure to chroot into an environment first, eg dchroot -c maverick
cd ubuntu-<RELEASE>-meta make clean make source
cd ubuntu-<RELEASE>-signed fdr clean dpkg-buildpackage -S -rfakeroot -I.git -I.gitignore -i'\.git.*'
LBM is obsolete as of Raring and newer releases Building the lbm package follows the same steps as the linux kernel package. Again, please note that 'fdr' is an alias for 'fakeroot debian/rules' and if on zinc, be sure to chroot into an environment first, eg dchroot -c maverick.
cd ubuntu-<RELEASE>-lbm fdr clean dpkg-buildpackage -S -rfakeroot -I.git -I.gitignore -i'\.git.*' "$@"
linux-backports-modules likely needs the help of a core-dev to sign the first upload. Also make sure it is promoted to Main. After that, anyone with appropriate kernel upload rights should be able to upload the package. If this is not the case, contact eg. cjwatson to have it added to the appropriate ACL. Also, because linux-backports-modules now contains the release name in the package (eg. precise), the seeds also need updating, ping someone on the release team (eg. pitti) to get them updated.
Uploading the Ubuntu kernel package(s)
Per Package Upload Rights
Once the package(s) have been built, they are ready for upload. However, before you are even able to upload to the main archive, you must obtain per-package upload rights for the kernel. You must apply for per-package upload rights through the Developer Membership Board (DMB). Your application will be reviewed at an upcoming DMB IRC meeting. You must attend this meeting and answer any questions regarding your application. Getting your application approved can take weeks depending when the next DMB meeting is, so get your application submitted early in the development cycle.
Examples of applications can be seen at:
Uploading linux, linux-meta, linux-signed, and lbm to the CKT PPA
Follow the same instructions as uploading to the archive, except instead do:
dput ppa:canonical-kernel-team/ppa <source.changes>
Uploading linux, linux-meta, linux-signed, and lbm to the archive
Once you have been granted per-package upload rights for the Ubuntu kernel, the following instructions are for uploading the linux kernel package to the main archive. Again, the instructions assume the kernel packages were built on the kernel team's server, ie zinc.
- Remotely sign the package
debsign -r zinc:linux_<VERSION>-<ABI>.<UPLOAD>_source.changes
- View the .changes file and verify everything looks correct prior to uploading.
- Check the release pocket is correct
- Check the package and version is correct
- Check the changelog is accurate
- Upload the package (from zinc)
The linux-meta, linux-signed, and lbm package follows the same upload instructions as the linux package. Remember that the ABI for the linux-meta, linux-signed, and lbm package need to be in lock step with the linux package.
During the release cycle there a few best practices to follow when building and uploading the kernel package(s)
- Upload typically once per week
- Wait to upload linux-meta until after linux finishes building successfully on the main archs
Once uploaded, if there was an ABI bump, send an email announcement to Ubuntu kernel-team mailing list (firstname.lastname@example.org) and the ubuntu-installer mailing list (email@example.com).
Keep a watchful eye on the milestone dates. eg. http://wiki.ubuntu.com/MaverickReleaseSchedule
- Remember the archive freezes the Tuesday before the milestone. As such, the kernel needs to be uploaded and successfully built before the archive freezes. This means the kernel for the milestone should typically be uploaded the Friday before the milestone. This allows enough lead time for the package(s) to build prior to the archive freezing.
- Be sure to communicate the milestone dates and the last day to get patches accepted into the kernel. Announce this in the weekly Ubuntu Kernel IRC meeting. Also, send an email to the Ubuntu kernel-team mailing list 1 week prior to the final kernel upload (ie ~2weeks before the milestone). This informs anyone wanting patches included in the kernel for the milestone to get them submitted ASAP.
- It's also become a frequent occurrence that we will upload a Day 0 Kernel after an official release is announced. The Day 0 Kernel typically includes high priority bug fixes and security updates. The Day 0 Kernel is uploaded to -proposed and then pocket copied to -updates and -security if needed. It should be noted that we must always bump the ABI for the Day 0 Kernel regardless if it is required or not. This ensures that a user who installs from the CD has a known good fallback kernel in the event the Day 0 Kernel introduces any regressions.