PatchTesting

Differences between revisions 11 and 12
Revision 11 as of 2009-03-16 21:16:01
Size: 4737
Editor: c-24-21-50-133
Comment:
Revision 12 as of 2009-03-16 21:24:44
Size: 4795
Editor: c-24-21-50-133
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
1) Install the affected software 1) Install the affected software.
Line 12: Line 12:
2) Recreate the bug following the test case 2) Recreate the bug following the test case that should exist in the bug's description.
Line 18: Line 18:
1) get the source package for the affected software 1) Get the source package for the affected software.
Line 22: Line 22:
2) Download the patch from the bug report 2) Download the patch from the bug report.
Line 31: Line 31:
Each patch can different so you'll need to examine them carefully to find out how many '''/''' to strip. Each patch can be different so you'll need to examine them carefully to find out how many '''/''' to strip.
Line 33: Line 33:
The next step of testing the patch involve creating a new version of the package that you can install and test. This can either be done on your local [[ https://wiki.ubuntu.com/PackagingGuide/Basic#Building%20the%20Source%20Package | build system ]] or using a [[ https://help.launchpad.net/Packaging/PPA | PPA ]]. The next step of testing the patch involves creating a new version of the package that you can install and test. This can either be done on your local [[ https://wiki.ubuntu.com/PackagingGuide/Basic#Building%20the%20Source%20Package | build system ]] or using a [[ https://help.launchpad.net/Packaging/PPA | PPA ]].
Line 35: Line 35:
4) Change directories into the source 4) Change directories into the source.
Line 39: Line 39:
5) We'll edit the debian changelog primarily to increment the package version number to something like iperf-2.0.4-3ubuntu1~ppa1 5) We'll edit the debian changelog primarily to increment the package version number to something like iperf-2.0.4-3ubuntu1~ppa1.
Line 43: Line 43:
6) Create files necessary for creating a new version of the package 6) Create files necessary for creating a new version of the package.
Line 69: Line 69:
1) Enter the virtual machine and install the new version of the package 1) Enter the virtual machine and install the new version of the package.
Line 77: Line 77:
2) Try to recreate the bug following the test case again
2) Try to recreate the bug following the test case again.

Once you've found a bug with a patch you can help out by testing that patch! Not sure how to find one? Use a Launchpad search or this report

The following process covers how to recreate the bug, building a patched package and then verifying that the updated patch fixes the bug report. All of the steps in the process use an iperf bug as an example.

Recreating the bug report

The first step in testing a bug report with a patch is being able to recreate the original bug! This should ideally be done in the development release of Ubuntu and can be done in a virtual machine. The virtual machine could be a chroot, a kvm image or a VMware image.

1) Install the affected software.

2) Recreate the bug following the test case that should exist in the bug's description.

Building a patched package

After you've recreated the bug report its time to test the fix that's been included in the bug report!

1) Get the source package for the affected software.

  • apt-get source iperf

2) Download the patch from the bug report.

  • wget http://launchpadlibrarian.net/23018796/iperf-die-on-bind-fail.patch

3) Apply the patch to the source package. The '-p' option tells patch how many / to strip from the patch file. In this case the first line of that patch looks like --- /tmp/iperf-2.0.4/src/Listener.cpp and I'm in a directory with an iperf-2.0.4 folder. (This was created by step 1). So for patch to be able to find the Listener.cpp file, which is being changed, I need to strip off the first 2 /. This is done via:

  • patch -p2 < iperf-die-on-bind-fail.patch

Each patch can be different so you'll need to examine them carefully to find out how many / to strip.

The next step of testing the patch involves creating a new version of the package that you can install and test. This can either be done on your local build system or using a PPA.

4) Change directories into the source.

  • cd iperf-2.0.4

5) We'll edit the debian changelog primarily to increment the package version number to something like iperf-2.0.4-3ubuntu1~ppa1.

  • dch -i

6) Create files necessary for creating a new version of the package.

  • a) local
    • debuild -S -uc -us
    b) PPA
    • debuild -S -sd

7) Upload to ppa or build locally

  • a) local
    • sbuild -d jaunty iperf_2.0.4-3ubuntu1.dsc
      or
      sudo pbuilder build iperf_2.0.4-3ubuntu1.dsc
    b) PPA
    • dput my-ppa iperf_2.0.4-3ubuntu1\~ppa1_source.changes

Testing the patched package

Now that we've created a new version of the package containing the patch we need to test it to ensure that it resolves the original bug report.

1) Enter the virtual machine and install the new version of the package.

  • a) local
    • sudo dpkg -i iperf_2.0.4-3ubuntu1_amd64.deb
    b) PPA
    • update /etc/apt/sources.list

    • install PPA version of the package

2) Try to recreate the bug following the test case again.

Bug report actions

Now that testing of the patch has been completed the bug report should be updated so that the patch can be acted on. If the patch fixed the bug tag:

  • add a comment indicating steps taken and results
  • tag the bug as patch-test-passed
  • set the status to Triaged
  • subscribe (not assign) the relevant sponsors team to the bug report

If the patch did not fix the bug:

  • add a comment indicating steps taken and results
  • tag the bug as patch-test-failed
  • set the status to Incomplete

For bonus points you could add the patch the packages patch system and then prepare a debdiff, which you've nearly done already and add that to the bug report.

Bugs/PatchTesting (last edited 2009-03-17 15:42:41 by c-24-21-50-133)