Ubuntu Wiki

An ongoing responsibility of the Ubuntu Kernel Release Manager is to maintain the master git repo and any subsequent branches and/or packages. This usually involves the following series of steps:

Maintaining the linux package

1. Start with a clean git repo

   fdr clean

2. Start the new release, if an "UBUNTU: Start new release" commit isn't already in place
   • Run the kteam-tools script:

       .../kteam-tools/maintscripts/maint-startnewrelease

   • Or, the old manual way (not recommended):

     fdr startnewrelease
     debian/scripts/misc/getabis 2.6.<MINOR-VERSION> <ABI>.<UPLOAD>
       * For example:  debian/scripts/misc/get-abis 2.6.35 15.21
       * it's quicker to run this from a machine with a fast connection to the data center (ie zinc)
     git add debian.master/changelog
     git rm -rf debian.master/abi/<PREV-ABI>
       * For example:  git rm -rf debian.master/abi/2.6.35-14.20
     git add debian.master/abi/<NEW-ABI>
       * For example:  git add debian.master/abi/2.6.35-15.21
     git commit -s -e -F debian/commit-templates/newrelease

3. Bump ABI - Signed modules (circa 2016) require every release to bump the ABI.

   edit debian.master/changelog and increment the ABI by 1
   git add debian.master/changelog
   git commit --amend

4. Move the "Start new release" commit into place just after the previous release commit (with git rebase -i)

5. Prepare the release changelog entry and create a tracking bug

   fdr insertchanges
   .../kteam-tools/stable/create-release-tracker

6. Close the release

   edit debian.master/changelog and change UNRELEASED to the actual release name, eg maverick
   git add debian.master/changelog
   git commit -s -m "UBUNTU: Ubuntu-<PKG-VERSION>"
    * For example: git commit -s -m "UBUNTU: Ubuntu-2.6.35-15.22"
   git tag -s -m Ubuntu-<PKG-VERSION>

7. Build test across arch's (i386, amd64, armhf, arm64, powerpc, ppc64el)

   • Suggest using kernel team build scripts

8. Push the changes to the master-next repo. It's often a good idea to incrementally push changes to the master-next repo prior to closing the release.

   git push origin Ubuntu-<PKG-VERSION>
   git push origin master-next

Maintaining the linux-meta package

For the most part, the only time the linux-meta repo needs to be updated is when the linux package undergoes an ABI bump. The ABI for the linux-meta must stay in sync with the ABI of the linux package. Bumping the ABI for the linux-meta package can be done with the following steps:

1. Add a new changelog entry

    edit meta-source/debian/changelog and start a new changelog entry
    * if you are a vi user, just do :Call NewVersion() :Call Finalise()

2. Increment the ABI

    edit meta-source/debian/changelog and increment the ABI by 1
    Add a note in the changelog about the ABI Bump

3. Close the release

    edit meta-source/debian/changelog and change UNRELEASED to the actual release name
    git add meta-source/debian/changelog
    git commit -s -m "UBUNTU: Ubuntu-<META-PKG-VERSION>
     * For example: git commit -s -m "UBUNTU: Ubuntu-2.6.35.15.16"
    git tag -s -m Ubuntu-<META-PKG-VERSION> Ubuntu-<META-PKG-VERSION>

4. Push the changes to the master repo

   git push origin Ubuntu-<META-PKG-VERSION>
   git push origin master

Maintaining the linux-signed package

The version of linux-signed must stay in lock step with the linux kernel package. The process is as follows:

1. cd ubuntu-<release>-signed

2. ./update-version <linux-source-directory>

3. Follow the instructions printed

Kernel/Handbook/ReleaseManagement