Introduction

This guide is based on a Debian Women Build it Event held by Margarita Manterola (in collaboration with the OpenHatch project) on 07-May-2011

This page provides simple, step-by-step directions for taking an existing package, rebuilding it, applying changes to it, and preparing those changes so that you can send them to a bug as a patch. It is intended to be straightforward for any user with a basic knowledge of the command line to follow, while providing links to further reading about the many different ways source packages may be built.

Requirements

You need very little previous knowledge for this tutorial, just no fear of the command line :-)

Technical requirements:

To ensure these packages are all installed, run:

  • sudo apt-get install build-essential fakeroot devscripts equivs lintian

configure apt

Once you have installed the needed packages, the next thing that you need to do is make sure that you have some source repositories configured on your computer.

Open your /etc/apt/sources.list file and check if you have one or more lines that start with deb-src.

   deb-src http://http.us.debian.org/debian unstable main

These lines are needed in order to work with source packages.

If you don't have any deb-src lines, you'll need to add at least one . This is usually achieved by copying one of the existing deb lines and changing the first word to deb-src. You can do that by running an editor with admin rights (for instance, sudo gedit, sudo kate or sudo vim).

Usually, it's a good idea to use unstable as the repository, so that you'll be working with the latest version of the package. But if you intend to modify a package as it is in stable or testing you could use those distributions as well.

It is safe to configure deb-src lines for unstable even if you're using stable/testing/etc as the distribution on your system; getting sources from unstable won't impact the installed system.

Once you've added the line, you'll need to do

  • sudo apt-get update

in order to update the list of packages available for installation.

create a working directory

With the sources URL added to your apt repositories, you'll now be able to get the source of any Debian package that you like.

For this particular tutorial, we are going to download the source of one package and make a small modification to it, so that it works better.

It's always a good idea to have a directory that you use to work with source software, separated from other directories used for other stuff. In case you don't already have one, I'd suggest that you create a directory src with another one called debian inside it:

  • mkdir -p ~/src/debian/; cd ~/src/debian

Inside this directory we will get the source of the package that we want to work with.

Choose the package

In this example, we'll use a package called fdupes, a tool to detect duplicate files, and we will be fixing the Debian bug 585426.

You should install the package (or check if you have it installed and up to the latest version) before proceeding, since you'll need to have the dependencies sorted up when you want to install the modified one.

If you don't have fdupes installed, you can do this by doing:

  • sudo apt-get install fdupes

and check that the bug is still present. You can do that by running

  • fdupes --help

and checking that the second line of info for the --debug option still doesn't make any sense.

The packaging workflow

Get the source package

In order to get the source of fdupes, what you need to do is go to your chosen directory (src/debian in this example) and do (as normal user):

  • apt-get source fdupes

You have now downloaded the 3 files (.dsc, .tar.gz, .diff.gz), composing the Debian source package. 1

Once the package is downloaded, you can check the directory where you are (typing ls), and you'll find that apart from the 3 files that were downloaded you also have a directory, called fdupes-1.50-PR2. This is the unpacked source of the Debian package.

To enter that directory, type:

  • cd fdupes-1.50-PR2/

When you check the contents of this directory (typing ls again), you'll see quite a number of files of different sorts, and a debian directory.

Every Debian (or Debian derivative) package includes a debian directory, where all the information related to the Debian package is stored. Anything that's outside of that directory, is the upstream code, i.e. the original code released by whoever programmed the software.

Go into the debian directory, by typing

  • cd debian

This is the directory that the package maintainer has added to the source code to build the package.

In this directory you'll usually find lots of files related to Debian's version of the program, Debian specific patches, manpages, documentation, and so on. We won't be going any deeper about these files here. Look at its contents by typing ls.

Just keep in mind that

Let's move one directory back, by doing

  • cd ..

You should again be in the directory fdupes-1.50-PR2, the main directory of the source code.

Get the build dependencies

In order to build almost any program, you will need some dependencies installed.

The dependencies are the programs or libraries needed to compile your program. Usually it's a bunch of packages that end in -dev, but it might also be other things like automake or gcc, depending on how many development tools you've ever installed in that machine.

The mk-build-deps command from devscripts provides a way of easily installing all the needed dependencies:

  • sudo mk-build-deps -i -r

Once you've downloaded these tools, you'll be ready to build the package.

Rebuild without changes

Before making any changes to the code, let's build the package as it is right now, just to make sure that it builds and it installs properly. Do:

  • fakeroot debian/rules binary

This is the command, almost like make, that builds the package.

This command will probably take a while to run, since usually it first has to run ./configure, then it has to compile the source code and then build the packages. In fact, it will run the commands that are listed in the debian/rules file and will hopefully end with a message like:

   dpkg-deb: building package `fdupes' in `../fdupes_1.50-PR2-3_<your arch>.deb'

In your own language. <your arch> can be i386, amd64, or another name, depending on which architecture you are running your machine on.

Once the package has correctly built, the next step is to install this file with:

  • sudo dpkg -i ../fdupes_1.50-PR2-3_<your arch>.deb

After that, check that the bug is still present, running

  • fdupes --help

Edit the source code

Now, we want to actually fix this bug.

Here comes the fun part. When you are trying to fix a package bug, sometimes it will be located in the upstream source, sometimes it will be related to how the program was packaged for Debian. So you'll be editing different files depending on where the problem is.

In this particular case, the package uses the dpatch tool, a tool to manage patches for the package, so we will make use of that tool. Other packages use a different tool, called quilt, to manage patches, but we won't be covering that one in this tutorial.

To create a new patch, you'll need to do the following. Type:

  • dpatch-edit-patch 80_bts585426_fix_help 70_bts537138_disambiguate_recurse.dpatch

This will start a new shell inside a special environment, where you can edit your files and dpatch will afterwards take care of getting the differences with the original.

The name of the patch was chosen to match the pattern already established by the maintainer (i.e., the names of the other patch files in the debian/patches directory).

Now we need to edit the fdupes.c file. Go to the line 1066 and delete it. The line says:

   printf("                  \teach set of duplicates without prompting the user\n");

You can edit the file with your preferred editor (vi fdupes.c, gedit fdupes.c, kate fdupes.c, etc).

Once you are done, you should type into the console :

  • exit

It will end the special environment that dpatch created for us, and you'll have a new patch in the debian/patches/ directory. Check it out with:

  • cat debian/patches/80_bts585426_fix_help.dpatch

In order for this patch to get applied, you'll need to edit the debian/patches/00list file, and add after the last line :

   80_bts585426_fix_help

The 00list file is the dpatch file that lists all the patches that will be applied. They are applied in order, from the one appearing in the first line, till the one appearing in the last line.

Before rebuilding the package with this patch, we want to make our package different from the original one, so that we can afterwards extract the changes in order to send them as a patch to the bug. In order to do this, type:

  • dch -n

This will

So, you are editing the changelog file now. What you have to enter in this file is some description of the change that we've made. For example:

   Added a patch to fix the --help issue with the --debug option. Closes: #585426.

Do this in the line with the empty *.

Building the modified package

Once this is done, we have to first clean the building directory, so that everything is back as it started, with:

  • fakeroot debian/rules clean

And then we can rebuild the package again by doing the same thing as before:

  • fakeroot debian/rules binary

In the case that you need to debug the compiled package, particularly if it's a Segmentation Fault that you are trying to fix, you might want to compile it like this, so that the code is not optimized and not stripped and it's easier to debug:

  • DEB_BUILD_OPTIONS=nostrip,noopt fakeroot debian/rules binary

You'll see a some compiling output on screen. This is usually not very interesting, unless you are looking for a bug that is related to the compilation of the package itself. Normally, I just let this go while I do something else (grab some cookies for your coffee, for example).

This time, the package created should be: ../fdupes_1.50-PR2-3.1_<your arch>.deb, the version changed because dch changed it for us in the changelog (-3.1 instead of -3).

Installing and testing the modified package

Install it with:

  • sudo dpkg -i ../fdupes_1.50-PR2-3.1_<your arch>.deb

and test that the help is now correct. :)

If in any case what you've done has made things worst, you can always revert to Debian's version by doing:

  • apt-get install --reinstall fdupes=<previous_version>

Building the source package

Once a bug is fixed, you might want to also build the source package. This means not only the .deb file, but the other files that we downloaded at the beginning. This is done with:

  • debuild -us -uc

The extra parameters are to prevent it from signing the package, since we don't need to sign it right now.

If you've built the source package, go to the previous directory with cd .. and check the files there with ls. You'll see that you have more files there now, including 2 dsc files, one for the original package and one for the one you just made.

Sending your changes to the BTS

Once you've built any source package, you can find out the difference between your package and the original one, by using debdiff:

  • debdiff fdupes_1.50-PR2-3.dsc fdupes_1.50-PR2-3.1.dsc > my_first_debdiff.diff

In this particular case, since we used the dpatch tool, what we would send to the BTS as a patch is the dpatch file that we created, because the change that we made is enclosed there.

But if we hadn't used dpatch, we could use the output of that debdiff and send that to the BTS.

Conclusions

That's it, get ready for the next package

You're done with modifying the package, you can now keep fixing bugs in other Debian packages! These are the important commands you'll need to remember:

  • apt-get source the-package sudo mk-build-deps -i -r (...) fakeroot debian/rules binary dpkg -i the-package-blabla.deb debuild -us -uc

    debdiff package-blabla.dsc package-blabla.1.dsc > another_debdiff.diff

See also

  1. Advanced topic: downloading fdupes with apt-get source will also inform you that this package is maintained with Git. If a package is maintained in a VCS, it may be useful to download the package from the VCS in order to collaborate more effectively with the maintainer. However, you can always use apt-get source, so we'll stick with that for now. You can read more about source packages in VCSes here. (1)