KernelPackaging

Differences between revisions 16 and 19 (spanning 3 versions)
Revision 16 as of 2011-07-12 20:09:57
Size: 6104
Editor: timg-tpi
Comment:
Revision 19 as of 2014-12-11 16:36:16
Size: 6611
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
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. 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.
Line 50: Line 50:
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.

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.

linux

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.

linux-meta

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

linux-backports-modules-<VERSION>

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:

https://wiki.ubuntu.com/AndyWhitcroft/KernelUploadsApplication

https://wiki.ubuntu.com/LeannOgasawara/KernelUploadsApplication

Uploading linux, linux-meta, and lbm

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.

  1. Remotely sign the package
    debsign -r zinc:linux_<VERSION>-<ABI>.<UPLOAD>_source.changes
  2. 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
  3. Upload the package (from zinc)
    dput linux_<VERSION>-<ABI>.<UPLOAD>_source.changes

The linux-meta and lbm package follows the same upload instructions as the linux package. Remember that the ABI for the linux-meta and lbm package need to be in lock step with the linux package.

Best Practices

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 (kernel-team@lists.ubuntu.com) and the ubuntu-installer mailing list (ubuntu-installer@lists.ubuntu.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.


Kernel/Handbook/ReleaseManagement

Kernel/Handbook/ReleaseManagement/KernelPackaging (last edited 2014-12-12 16:41:10 by leannogasawara)