Tutorial to Re-Build a Debian Package

https://wiki.debian.org/BuildingTutorial
02/04/15

Contents
1 Debian Source Package

2 How to Download a source package

2.1 With apt-get source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 From debian.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2
2
2

3 Working with a source package

3.1 How to build the Debian package . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 How to extract the source files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2
2
3

4 Introduction to Re-Build a Package

5 Requirements

6 configure apt
6.1 create a working directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Choose the package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
4
4

7 The packaging workflow

7.1 Get the source package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4
4

8 Get the build dependencies

9 Rebuild without changes

10 Edit the source code

11 Building the modified package

12 Building the source package

12.1 Sending your changes to the BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8
8

13 Conclusions
13.1 Thats it, get ready for the next package . . . . . . . . . . . . . . . . . . . . . . . . .
13.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8
8
9

14 Questions and Answers

15 How to download, modify, build and install a Debian source package

10

16 Advanced Building Tips

16.1 Useful packages . . . . . . .
16.2 Using the changelog . . . . .
16.3 Building the source package
16.4 Using interdiff . . . . . . . .
16.5 Using lintian . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

17 Referncias

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

11
11
11
12
12
13
13

Debian Source Package

This definition of a source package is due to Debian. The source packages provide you with all of the
necessary files to compile or otherwise, build the desired piece of software. It consists, in its simplest
form, of three files:
The upstream tarball with .tar.gz ending
A description file with .dsc ending. It contains the name of the package, both, in its filename
as well as content (after the Source: keyword).
A tarball, with any changes made to upstream source, plus all the files created for the Debian
package.
This has a .debian.tar.gz (source format: 3.0)
or a .diff.gz ending (source format: 1.0)
Why looking at a source package?
If you want to study packaging, or a specific package.
If you want to know which compile-time options are enabled for a specific package DebianPackageConfiguration.
Why bother with source package if there is a binary package?
Some build systems (e.g. cmake) and ad-hoc scripts provide a convenient way to produce Binary
packages (i.e. .deb files for Debian, .rpm for RedHat, etc) in a uniform fashion. Although such
approach sounds appealing at first, it is not only insufficient for upload into Debian proper, where
source package is required, but might be inferior, because binary-only distribution
does not even provide a unified way to obtain the sources of a corresponding software (as it is
now with "apt-get source package")
makes it difficult (if not impossible at all) for a user/contributor to rebuild .deb package due
to lack of standardization in build procedures and description of build-dependencies. It is
often mitigated by upstream authors with detailed descriptions in README, but instructions
would vary from package to package, are not guarantee to be complete; thus altogether making
rebuilding not straightforward and fragile. So it is of no surprise why Debian policy demands
source packages with standardized build procedures Debian needs to rebuild architectureagnostic software for all (>12) supported platforms.
manually composes "Depends:" for a generated .deb and those quite often would not be correct across Debian suites/releases, thus complicating installation procedures. Quick and dirty
solution is often to build statically thus loosing benefits of modularity in Debian, making the
software less robust and secure.
2

How to Download a source package

Sources are normally not installed. You can only install them if you know the package name.
How to find the name of the source package
On http://www.debian.org/distrib/packages, there is a search engine which will go to: http:
//packages.debian.org/src:<name>.
A source package could generate many .debs. To know the source package name, see the Source:
field in the output of
apt - cache show package_name

2.1

With apt-get source

One way to obtain source packages is with

apt - get source < package name >

You need a deb-src entry in your /etc/apt/sources.list file, like:

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

A source package is downloaded in the current directory and is not installed (it will not appear
in the installed package list), so you need not be root to use apt-get source.

2.2

From debian.org

You can do a manual download, from http://www.debian.org/distrib/packages.

When you are on the page of the package, choose a distribution, and you will have a link to the
three files which make the source package.

3
3.1

Working with a source package

How to build the Debian package

You need root privileges or fakeroot to build the .[50]deb. To automatically build the DebianPackage
after download, you can also use
apt - get -- build source package_name

If you want to make optimized packages from source to your machine in order to possibly get
faster operation, install and use apt-build (which in order uses apt-get source -b ...)

3.2

How to extract the source files

Assuming the files of the source package are present in the same directory, to unpack a source package,
you can typically use:
dpkg - source -x .../ path / to / package_name . dsc

All the files will be unpacked into a directory: package-version.

See also UsingQuilt

Introduction to Re-Build a Package

This tutorial is based on a BuildingTutorial, Debian Women, Build it Event held by Margarita
Manterola (in collaboration with the OpenHatch project) on 07-May-2011
This tutorial is about taking an existing package, re-building it, applying changes to it, and
preparing those changes so that you can send them to a bug as a patch.

Requirements

You need very little previous knowledge for this tutorial, just no fear of the command line :-)
Technical requirements:
You should have a working Debian distribution or a Debian based distribution.
You should have administration rights in this computer (either root or sudo). Every time that
admin rights are needed, well include sudo in front. If you dont use sudo, just get the rights
whatever way you like.
build-essential
fakeroot
devscripts
Remember:
sudo apt - get install build - essential fakeroot devscripts

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 in 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 dont have any deb-src lines, youll need to add at least one . This is usually achieved by
copying one of the existing deb lines and changing it to deb-src. You can do that by running an
editor with admin rights (sudo gedit, sudo kate or sudo vim).
Usually, its a good idea to use unstable as the repository, since youll 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.
If you use stable/testing/whatever as your running distribution, getting source from unstable
wont affect it.
Once youve added the line, youll need to do
4

sudo apt - get update

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

6.1

create a working directory

With the sources URL added to your apt repositories, youll 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.
Its 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 dont already have one, Id 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.

6.2

Choose the package

In this example, well 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 youll need to have the dependencies sorted up when you want to install the
modified one.
If you dont 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 doesnt make any sense.

7
7.1

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.
It probably also informed you that fdupes is maintained with Git.
Once the package is downloaded, you can check the directory where you are (typing ls), and
youll 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:
5

cd fdupes -1.50 - PR2 /

When you check the contents of this directory (typing ls again), youll 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 thats 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 youll usually find lots of files related to Debians version of the program, Debian
specific patches, manpages, documentation, and so on. We wont be going any deeper about these
files here. Look at its contents by typing ls.
Just keep in mind that
the rules file is the executable file that we will be running in order to build the package.
in the patches directory, there are also a number of patches applied by the maintainer
Lets move one directory back, by doing
cd ..

You should be again at 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 its 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 youve ever installed in that machine.
apt provides a way of easily installing all the needed dependencies:
sudo apt - get build - dep fdupes

Once youve downloaded these tools, youll be ready to build the package.

Rebuild without changes

Before making any changes to the code, lets build the package as it is right now, just to make sure
that it builds and it installs properly. Do:
debuild -b - uc - us

The extra parameters are to build a binary only package (.deb) and prevent it from signing the
package, since we dont need to sign it right now.
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:
6

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

In your own language. <your arch> can be i386, amd64, 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

10

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 youll 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 wont be covering that one in this tutorial.
To create a new patch, youll need to do the following. Type:
dpatch - edit - patch 80 _ bt s 5 85 4 26 _ fi x_ he l p 70 _ b t s 5 3 7 1 3 8 _ d i s a m b i g u a t e _ r e c u r s e .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 first parameter is the name assigned to the new patch: 80_bts585426_fix_help
the second parameter is the last patch that should be applied before applying the new one:
70_bts537138_disambiguate_recurse.dpatch
The name of the patch was chosen to match the pattern already established by the maintainer.
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 youll have a new patch in
the debian/patches/ directory. Check it out with:
cat debian / patches /80 _ bt s 58 5 4 26 _ fi x _ he l p . dpatch

In order for this patch to get applied, youll need to edit the debian/patches/00list file, and
add after the last line:
80 _b t s5 8 5 42 6 _f i x _h e lp

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
add a new entry in the changelog file, maybe with your name (depending on other configurations
that we are not going to cover), with the current date,
and open the changelog with the configured command-line editor.
In case this is vi, and its your first time with vi, you can start editing by pressing the
Insert key, and after you are finished, you can save an close by pressing: ESC:wq
So, you are editing the changelog file now. What you have to enter in this file is some description
of the change that weve 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 *.

11

Building the modified package

Once this is done, just build the package again with the same command as before:
debuild -b - uc - us

Add -tc option if you want to clean build artifacts.

In the case that you need to debug the compiled package, particularly if its 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 its easier to debug:
DEB_ BUILD_OP TIONS = ' nostrip noopt debug ' dpkg - buildpackage -b - uc - us

Youll 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:
8

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 youve done has made things worst, you can always revert to Debians version
by doing:
apt - get install -- reinstall fdupes = < previous_version >

12

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

If youve built the source package, go to the previous directory with cd .. and check the files
there with ls. Youll 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.

12.1

Sending your changes to the BTS

Once youve 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 hadnt used dpatch, we could use the output of that debdiff and send that to the BTS.

13
13.1

Conclusions
Thats it, get ready for the next package

Youre done with modifying the package, you can now keep fixing bugs in other Debian packages!
These are the important commands youll need to remember:
apt - get source the - package
apt - get build - dep the - package
(...)
fakeroot debian / rules binary
dpkg -i the - package - blabla . deb
dpkg - buildpackage - us - uc
debdiff package - blabla . dsc package - blabla .1. dsc > another_debdiff . diff

13.2

Feedback

I hope you enjoyed the tutorial, please send me your feedback if you feel like it, or modify this wiki
if you want to add some useful information I might have left out.
9

14

Questions and Answers

QUESTION: Is the number 80_ in the name of the patch a cosmetic thing?
ANSWER: Its so that you can get them in order when you list them with ls. The order of
application is the order in which they appear in the 00list file. Some maintainers choose to give them
numbers, some dont. But when you are patching a package, you should try to follow whichever
pattern the maintainer chose.
QUESTION: About dpatch-edit-patch params, where did you get your params? I mean the
bts****
ANSWER: The first one is the name of the patch. I chose a name similar to the other ones.
"bts" stands for "bug tracking system", the number is the bug number that we are closing.
QUESTION: How does dch pick the number "3.1"?
ANSWER: We used dch -n, because we are not the maintainer of the package (n stands for
non-maintainer). Then its 3.1. If you were the maintainer, youd have done dch -i, and it would
have chosen -4
QUESTION: When sending a patch to the BTS, do we send anything about the changelog?
ANSWER: Not necessarily, but you can send that too, it depends on the bug that you are
fixing. Sending the debdiff output is always acceptable.
If youre sending only a small and simple patch its normal to let the maintainer write the
changelog; if its a big NMU update then yes you should send the changelog as part of your big patch
to the BTS.
QUESTION: Sending a changelog with a NMU is considered not polite?
ANSWER: What some (not all) maintainers dont like is if when someone actually uploads an
NMU. Sending a patch to the BTS is always/immer/siempre/sempre well received!
QUESTION: What is the quickest/easiest way to find out which tool (if any) is used to manage
patches?
ANSWER: If theres a build dependency on quilt or dpatch in debian/control. Or if theres a
debian/README.source file.
QUESTION: Does this workflow work for all packages?
ANSWER: The workflow is quite general. The only thing that might change is the patch
management system (dpatch/quilt/none). The rest is basically always the same.
See also
If you want to go on a little bit further in your package making, you can read some of the
AdvancedBuildingTips
You can find a tutorial about creating new packages for Debian at
Introduction to Debian Packaging
Packaging is the page that gather everything about packaging on this wiki

15

How to download, modify, build and install a Debian source

package

This fast review is based on a following question in ubuntu forum.

QUESTION: If I want to make minor changes to the source code of a Debian package, how
do I go about downloading, incrementing the package version, building the (modified) source, and
installing it on my computer?
ANSWER: Theres basically two ways to do it, the first one is the classic form, youll get the
source with:
10

Classic: First get the source package with:

apt - get source package

Then youll be able to modify it:

cd package
vim some_file

Rebuild it:
sudo apt - get build - dep package
dch -i
debuild - us - uc -b

Note that the command dch -i will will open your editor to edit the changefile, heres where
you can increment the package version.
And now you can install it:
sudo dpkg -i ../ package . deb

New Ubuntu Approach: The new way (the Ubuntu way) is by using bzr branches, youll get the
code by using:
bzr branch lp : ubuntu / package # which will download the latest ubuntu package
bzr branch lp : ubuntu / trusty / package # to get the package in trusty

You can also get the code using:

lp - source package # lp - source is part of the ubuntu - dev - tools pkg

Then youll be able to edit it:

cd package
vim some_file

Rebuild it:
dch -i
debcommit
bzr bd -- -b - us - uc

And install it:

sudo dpkg -i ../ package . deb

I recommend that you check the Ubuntu packaging guide out to know the details.
Also you might encounter problems if the package depends of others
11

16

Advanced Building Tips

Once youve downloaded, modified and built a Debian package, you usually feel that you could keep
doing it, since its so easy. Here we presents some advanced tips to do it.
And its just like that, but even if the BuildingTutorial is a good introduction to modifying Debian
packages, there were some things that were left out on purpose, to keep it simple. So, here youll
find some extra tips to take full advantage of some of the many Debian tools.

16.1

Useful packages

Although they might not be build dependencies, theres a bunch of useful packages that anyone
interested in helping Debian development should have installed:
build-essential: includes the essential packages for building your own ones, this is probably already
installed in your system, but it never hurts to check.
devscripts: lots of useful scripts for Debian Development (including: dch, debuild, uscan, uupdate
and many others).
lintian: package checker, that verify the built package is in good shape regarding Debian Policy.
diff, patch and patchutils: utilities for working with patches.
And heres a useful command line, to copy and paste:
apt - get install build - essential devscripts lintian diff patch patchutils

16.2

Using the changelog

The debian/changelog file is one of the important files in the debian directory. Lets take one
changelog entry as an example:
control - center (1:2.8.1 -3) unstable ; urgency = low
* debian / rules :
- Corrected erroneous line responsible for not including the . desktop
files ( Closes : # 274401)
* debian / patches :
- Suppressed ' Text Editor ' in the " preferred applications " as it ' s useless
with the new mime type system .
-- Arnaud Patard < arnaud . patard@rtp - net . org > Thu , 25 Nov 2004 21:16:04 +0100

There are many things to notice in this entry: in the first line you have the name and version
of the source package, also the distribution to which it is initially uploaded to (unstable), and the
urgency level (this is used by Debian bots to determine when the package is ready to enter testing).
Then, we have a bulleted list with the files that were changed and a very brief summary of the
reasons for the changes. Note the 274401, this is used by Debian bugs bot to automatically close
bugs.
Finally, we can see the name and email of the last person to change the package and the date on
which it was changed.
Now, to edit the changelog, if you have installed devscripts youll have a nifty command
dch that prefills a lot of this information and opens your preferred editor. Although you can edit
everything manually if you want, I recommend using dch.

12

Important: when you first start modifying a package, youll want to make a new version of it,
so that you can differentiate it from the original one. So, the first time you are about to edit a
changelog entry, you should do
dch -i

This will add a whole new entry, incrementing the version number and letting you write which
files you modified. After that, you can always add more info about your changes by just using dch.

16.3

Building the source package

When you do debian/rules binary you just build the binary package, the one that you want to
install on your system. But in many cases you want to also build the source package (which is
actually composed of three files: package_version.orig.tar.gz, package_version.diff.gz and
package_version.dsc).
To do this there are lots of tools. Here, well be using dpkg-buildpackage that comes with the
dpkg-dev package (part of build-essential).
Provided you already modified the package and the packages changelog, youll build it by doing:
dpkg - buildpackage - rfakeroot

(There are many option to pass to dpkg-buildpackage, -S for example, will only build the source
package, -tc will clean the compiled files after making the package, etc. See man dpkg-buildpackage
for more info)
Once youve done this, youll find a new trio of files in your parent directory, that will have almost
the same name as the ones you downloaded but with a change in the version number.

16.4

Using interdiff

If youve built a package, incremented the version number in the changelog file, and now you have
two sets of three files (two source packages) you can gather what the changes between versions were
very easily by using interdiff:
interdiff -z p ack ag e_ old ve rs ion . diff . gz pa ck age _n ew ver si on . diff . gz > your . patch

After running this command you can inspect the contents of your.patch, it should contain everything that you changed to the package. If you are solving a bug in the Debian BTS, this is what you
should send to the bug number.
Note that interdiff only makes sense when you havent changed the upstream source (this is
to say, the package_version.orig.tar.gz has to be the same).

16.5

Using lintian

Not all Debian packages comply perfectly with Debians policy. Sometimes this is due to the policy
getting quickly updated, sometimes this is because of lack of time from the maintainer, sometimes
because its not easy for certain software to be totally compliant.
In any case, these tools provide us with an easy way to find problems in Debian packages. Using
them is easy: you just run them against the .diff.gz and .dsc files of your source package.
Depending on the package, you could get no messages, some messages or a lot of messages. These
messages are usually brief and not always will you know what they mean, but many times theyll
point you to the problematic part of the package.
13

Of course, these tools are just an aid, not a replacement to actually reading Debians policy.

17

Referncias

1. https://wiki.debian.org/BuildingTutorial?diffs=1&show_att=1&action=rss_rc&unique=
0&page=BuildingTutorial&ddiffs=1
2. https://wiki.debian.org/FrontPage
3. https://wiki.debian.org/BuildingTutorial?action=raw
4. https://wiki.debian.org/BuildingTutorial?action=print
5. https://wiki.debian.org/FindPage
6. https://wiki.debian.org/TitleIndex
7. https://wiki.debian.org/WordIndex
8. https://wiki.debian.org/HelpOnFormatting
9. http://www.debian.org/
10. https://wiki.debian.org/
11. https://wiki.debian.org/BuildingTutorial?action=login
12. https://wiki.debian.org/FrontPage
13. https://wiki.debian.org/RecentChanges
14. https://wiki.debian.org/FindPage
15. https://wiki.debian.org/HelpContents
16. https://wiki.debian.org/BuildingTutorial
17. http://www.debian.org/
18. https://wiki.debian.org/
19. https://wiki.debian.org/BuildingTutorial?action=login
20. https://wiki.debian.org/BuildingTutorial
21. https://wiki.debian.org/BuildingTutorial?action=info
22. https://wiki.debian.org/BuildingTutorial?action=AttachFile
23. https://wiki.debian.org/BuildingTutorial?action=fullsearch&context=180&value=linkto:
"BuildingTutorial"
24. https://wiki.debian.org/DebianWiki/EditorGuide#translation
25. https://wiki.debian.org/es/BuildingTutorial
26. https://wiki.debian.org/it/BuildingTutorial
27. https://wiki.debian.org/pt_BR/BuildingTutorial
14

28. https://wiki.debian.org/BuildingTutorial#Introduction
29. https://wiki.debian.org/BuildingTutorial#Requirements
30. https://wiki.debian.org/BuildingTutorial#configure_apt
31. https://wiki.debian.org/BuildingTutorial#create_a_working_directory
32. https://wiki.debian.org/BuildingTutorial#Choose_the_package
33. https://wiki.debian.org/BuildingTutorial#The_packaging_workflow
34. https://wiki.debian.org/BuildingTutorial#Get_the_source_package
35. https://wiki.debian.org/BuildingTutorial#Get_the_build_dependencies
36. https://wiki.debian.org/BuildingTutorial#Rebuild_without_changes
37. https://wiki.debian.org/BuildingTutorial#Edit_the_source_code
38. https://wiki.debian.org/BuildingTutorial#Building_the_modified_package
39. https://wiki.debian.org/BuildingTutorial#Installing_and_testing_the_modified_package
40. https://wiki.debian.org/BuildingTutorial#Building_the_source_package
41. https://wiki.debian.org/BuildingTutorial#Sending_your_changes_to_the_BTS
42. https://wiki.debian.org/BuildingTutorial#Conclusions
43. https://wiki.debian.org/BuildingTutorial#That.27s_it.2C_get_ready_for_the_next_
package
44. https://wiki.debian.org/BuildingTutorial#Feedback
45. https://wiki.debian.org/BuildingTutorial#Questions]_and_Answers
46. https://wiki.debian.org/BuildingTutorial#See_also
47. http://women.debian.org/
48. https://wiki.debian.org/DebianWomen/BuildItEvent
49. http://openhatch.org/
50. https://packages.debian.org/sudo
51. https://packages.debian.org/build-essential
52. https://packages.debian.org/fakeroot
53. https://packages.debian.org/devscripts
54. https://packages.debian.org/fdupes
55. https://bugs.debian.org/585426
56. https://packages.debian.org/fdupes
57. https://packages.debian.org/fdupes
15

58. https://packages.debian.org/fdupes
59. https://packages.debian.org/automake
60. https://packages.debian.org/gcc
61. https://packages.debian.org/apt
62. https://packages.debian.org/dpatch
63. https://packages.debian.org/quilt
64. https://packages.debian.org/debdiff
65. mailto:marga@debian.org
66. https://wiki.debian.org/AdvancedBuildingTips
67. https://wiki.debian.org/IntroDebianPackaging
68. https://wiki.debian.org/Packaging
69. https://wiki.debian.org/eugene
70. http://moinmo.in/
71. http://moinmo.in/Python
72. http://validator.w3.org/check?uri=referer
73. https://wiki.debian.org/Teams/DebianWiki
74. http://bugs.debian.org/wiki.debian.org
75. http://git.debian.org/?p=collab-maint/wiki.debian.org.git;a=summary
76. http://www.dg-i.net/

16