|Deletions are marked like this.||Additions are marked like this.|
|Line 4:||Line 4:|
|= What is a Stable Release Update =||= What is a Stable Release Update? =|
|Line 14:||Line 14:|
|Whoever fixes the bug should do it upstream on the original source. If you did not do the bug fix yourself, but find out there is one, you'll need to retrieve it. Simplest is if you retrieve only that part of the code, which fixes the bug. Often, this exists as one commit, for example a git commit. Using a upstream commit is also the simplest way to create a patch for the package you want to fix.
|Line 18:||Line 16:|
|Either you fix the bug yourself, or you find code that fixes it. In both cases, it is very helpful to have the fix in the form of a patch. Read more on [[UbuntuStudio/CreatePatchFromCommit|creating a patch from a commit]].|
|Line 19:||Line 18:|
Find the upstream fix. Then, create a patch of it.
|If the original source in the package is much older than the bug fix, there is a chance you won't be able to apply the patch directly, as the source has changed so much since then. In this case, you will need to apply the fix manually, and this will require for you to understand the code fairly well.|
What is a Stable Release Update?
A stable release update simply means doing an update on a package that exists on a stable release, i.e. not a package in the development release. There is a special procedure for doing updates on stable release packages. Read more at StableReleaseUpdates.
When to do a SRU
Currently, as far as Ubuntu Studio is concerned, we only do one kind of SRU - to fix a serious bug. The bug needs to result in some kind of crash that stops the user from accomplishing a task using any of the applications used on a Ubuntu Studio desktop. The bug-fix should optimally only fix that specific bug, and not cause any regressions.
Fix Bug and do a SRU
Create Bug Fix
Either you fix the bug yourself, or you find code that fixes it. In both cases, it is very helpful to have the fix in the form of a patch. Read more on creating a patch from a commit.
If the original source in the package is much older than the bug fix, there is a chance you won't be able to apply the patch directly, as the source has changed so much since then. In this case, you will need to apply the fix manually, and this will require for you to understand the code fairly well.
Create bzr branch with the new fix
Get the source for the development version. You'll always start by fixing the development version first. Using jackd2 as example.
bzr branch ubuntu:jackd2
You'll also want to get the source for all releases where you want to add the fix, going back one release at the time (if the development release includes the fix, just skip it).
bzr branch ubuntu:quantal/jackd2 jackd2-quantal bzr branch ubuntu:precise/jackd2 jackd2-precise
We'll start by creating a debian patch using edit-patch. Decide the name for the patch (some packages have a convention for how to name patches). Use a name that describes what the patch fixes.
edit-patch will create a temporary folder in /tmp/. While in there, apply your upstream patch doing:
patch -p1 < /path/to/jackd2-upstream-fix.patch
Hopefully your patch was well applied. If not, you may need to add changes manually, which will require for you to know a bit about the code used for that package.
Once changes were applied, use Ctrl+D to exit edit-patch. This will create the debian/patches/patch, and opens debian/changelog. Adjust it to contain the correct info. Rename RELEASE to the release in question (precise, in this case), and describe what the patch does (here I just add which bug it fixes).
jackd2 (1.9.8~dfsg.1-1ubuntu2) precise; urgency=low * debian/patches/jackdbus-stop-fix.patch: [fixes LP: #956438] -- Kaj Ailomaa <firstname.lastname@example.org> Mon, 18 Mar 2013 16:25:32 +0100
When ready, close down the editor. You'll be asked if to commit. Answer No. We still need to update the patch description.
OK to commit? [Y/n/e]
To edit the patch description, open your patch with your text editor of choice:
At the top, you see a header, looking something like this:
## Description: add some description ## Origin/Author: add some origin or author ## Bug: bug URL
Follow the Debian Patch Tagging Guidelines on what to add. For example:
## Description: This patch, consisting of two upstream git commits, fixes an issue where jackdbus is left unresponsively, running in the background, when attempting to stop it. ## Origin/Author: upstream https://github.com/jackaudio/jack2/commit/aa02feeacfa533a07f04e916334637b57eaac5a2, https://github.com/jackaudio/jack2/commit/700489b429b0edb7046b169278e3e6751e3$ ## Bug: https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/956438 ## Applied-Upstream: 1.9.9
We're all done with changes. Let's commit now, so that the changes stay permanent, using debcommit:
That will have created a bzr commit based on your additions to debian/changelog.
Test your fix
You may either test your fix locally, or upload it to a PPA.
Upload to PPA
Upload to PPA. Make sure you have a GPG signing key ready.
sudo apt-get build-dep jackd2 bzr get-orig-source fakeroot debian/rules clean debuild -S -sa dput ppa:<username>/<ppa>
Build package locally. There are a few ways to do that. One way is (will build for this release and arch):
sudo apt-get build-dep jackd2 bzr get-orig-source fakeroot debian/rules clean debuild -S -sa dpkg-buildpackage
Upload your branch, and create a merge request
First, let's make sure the bzr branch is clean
Then, push it to a new branch, based on the original package name and release, like so:
bzr push lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>
bzr push lp:~zequence/ubuntu/precise/jackd2/fix-for-956438
Then, open launchpad in a browser and create a merge request by doing: