The process to backport a compiz bug fix on Trusty (current LTS release: Xenial).

Recently, I had to follow the SRU process to add a Compiz bug fix on Trusty for the 1st time. It’s useful to have the detailed steps somewhere so.. here’s what I did:

The bug fix I needed to backport was this one: #1442728

Part 1 – Launchpad

Step 1:

I edited the bug description on launchpad and included the following information:

following the SRU bug template here: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

Step 2:

In the SRU directory I downloaded the source code of the revision I wanted to backport to Trusty:

(-r 3994 is the number of the revision that contains the fix).

merged

Part 2 – Package workaround

Step 1: I installed the necessary tools:

Step 2: I downloaded the source code of compiz on Trusty inside the SRU directory:

(thanks to rbasak@FreeNode for that step)

Then, my SRU directory was like that:

where, the directory

contains the extracted package source code.

Part 3: Quilt

I patched the package using quilt (guide: http://packaging.ubuntu.com/html/patches-to-packages.html)

Here’s how:

Step 1: bzr diff and stat to see the revision changes

  • Inside compiz directory:
  • I used bzr diff to create a .diff of the change:

    (I only need the changes that have been introduced in revno 3994, that’s why I used -r 3993)
  • Then I checked which files have been modified in rev. 3994 using bzr stat:

    modified:
    plugins/composite/composite.xml.in

Step 2: I used Quilt to apply the changes to the package.

  • First, I told quilt where to apply the patches:
  • Then, I created a new patch:

    Patch debian/patches/fix-1442728.diff is now on top
  • And added it the file that has been changed (bzr stat output of part 2) to quilt:

    File plugins/composite/composite.xml.in added to patch debian/patches/fix-1442728.diff
  • To make sure that there aren’t any unwanted changes or conflicts I compare the output of:

    with the bzr diff output. This step is not necessary, it’s just an extra check.
  • I safely replaced the release file with the modified file:
  • I applied the patch:

    Patch debian/patches/fix-1442728.diff is currently applied
  • and refreshed:

Part 4: Changelog

  • Using the dch tool I edited the changelog as follows:

  • I applied the metadata:
  • Create a new .dcs and .diff for the new version:

    The SRU directory will now contain:

Quoting rbasak@Freenode for the rest:
<rbasak> An uploader would then be able to use the generated .changes file to upload.
<rbasak> If you need sponsorship, you run “debdiff .dsc .dsc” to create a debdiff, attach that to the bug, and subscribe ~ubuntu-sponsors to the bug.
<rbasak> I’ve ignored testing here. You can use sbuild to build a test package locally.
<rbasak> Or upload to a PPA for testing.
<rbasak> So you’d done most of the hard part already for the usual process I think.

Note:

After I wrote this post, I learned that there are also visual tools accessible from launchpad.net for some projects (Compiz is one of them) that can simplify this process a lot.

Leave a Reply

Your email address will not be published. Required fields are marked *