Differences between revisions 39 and 40
Revision 39 as of 2013-11-10 17:16:01
Size: 5808
Comment: fix typo
Revision 40 as of 2018-02-06 13:00:57
Size: 6088
Editor: LauraArjona
Comment: add section "The basics about Bug triaging and closing" with link to "Bug triaging and bug closing" talk
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:

= The basics about Bug triaging and closing =

If you are new to the Debian Bug Tracking System, you may want to watch Solveig's talk [[https://wiki.debian.org/DebianWomen/Projects/MiniDebconf-Women/2014/Talks#Bug_triaging_and_bug_closing|"Bug triaging and bug closing"]]
 

Translation(s): English - Français


(what you have to know for your 1st BSP)

Note: this is a rough draft, written by a guy that never fixed a bug before... so any additions, improvements, etc. are very welcome.

The basics about Bug triaging and closing

If you are new to the Debian Bug Tracking System, you may want to watch Solveig's talk "Bug triaging and bug closing"

Picking RC bugs

The first thing you do is, of course: pick yourself a bug. If you are new to bug squashing it can be quite daunting to find a bug appropriate for your skill level. There is a primer on how to choose RC bugs which should help you. A list of RC bugs are found on bugs.debian.org. But a much more flexible list is found on udd.debian.org.

A convenient method to focus your attention on a smaller list of RC bugs that are important to you is to log in to a Debian system that you use often (i.e. your laptop/workstation/server) and run the rc-alert command from the devscripts package. If you want to concentrate on bugs that are still open in the unstable distribution run rc-alert -d U or read the man page for more options on filtering and sorting.

Claiming bugs

Before you start to work on a bug you should announce your intention on #debian-bugs (on irc.debian.org) and claim it using

bts claim <bugnumber> <your@email>

(that's a command-line tool that is available through the devscripts package.)

Your bug will then be marked as claimed on http://udd.debian.org/bugs.cgi after some time.

Fixing bugs

Getting the source

To ensure that you get the latest source for the package check http://incoming.debian.org and http://packages.qa.debian.org. Go to the directory where you want to edit the source and get all the required files with

dget -x [url to the dsc file]

(dget is in the devscripts package). Alternatively, you can use

apt-get source <source_package>

if you have an unstable deb-src line in /etc/apt/sources.list

Before hacking

In the package directory do dch -i. This invokes an editor with an already prepared update of the changelog. First, the new version number should be adjusted, according to the following scheme (applies to non-maintainer uploads):

  • if the old version was package-X-Y then the new version number is package-X-Y.1

  • if the old version was package-X-Y.2 then the new version number is package-X-Y.3

  • if the old version was simply package-X then the new version is package-X-0.1

On the first line after the package version, mark your changes as non-maintainer upload:

  * Non-maintainer upload

On the next lines explain what the changes will be, e.g.

  * Fixed this and that (closes: #123456).

Note: Non-maintainer uploads should contain only minimal changes, and only changes relating to RC bugs.

Actually fix the bug

Fix the bug (how? The answer is beyond the scope of this HOWTO).

Build the new source package

To get a new source package, run e.g. the following:

dpkg-buildpackage -us -uc -S

(Make sure you incremented the version number via dch as mentioned above, or the original source package will be overwritten!)

Build the new binary package(s)

Quick and dirty

There is the quick and dirty method (for testing purposes). After installing all build-depends (apt-get build-dep [package]) for the package,

fakeroot debian/rules binary

builds a deb which you can install (but not upload).

Using pbuilder

The recommended method is to use pbuilder - for several reasons:

  • your system does not get cluttered with all the packages necessary to satisfy the build-depends
  • the build-depends are taken care of automatically
  • the package is created in a clean, minimal environment. This ensures that the package will build on (presumably) any system, and not just your own.

If you want more details on pbuilder read the manual. Here we willl just describe what steps are needed to build the package.

You can use the default configuration if you just install the pbuilder and cdebootstrap packages.

First, create a base chroot image with

sudo pbuilder create

This creates /var/cache/pbuilder/base.tgz. As you're downloading a lot of packages, you might want to append --mirror http://192.168.2.248/debian/ or so. If you already have such a base chroot image update it with

sudo pbuilder update

pdebuild (invoked in the package directory) builds the new source package and the binary package(s) in one go. The resulting binary package(s) are found in /var/cache/pbuilder/result/.

Test the new binary package(s)

Using pbuilder

To test your newly created packages by installing them into your base chroot image:

sudo pbuilder login --bindmounts /var/cache/pbuilder/result/

and inside the chroot:

dpkg -i /var/cache/pbuilder/result/*.deb

Congratulations, if everything works. Next, upload a patch to the bug tracking system and consider to upload the fixed package.

Upload patch to the bug tracking system

Create the diff-file with

debdiff old-package.dsc new-package.dsc > new-package.diff

and send it (as attachment) to [bugnumber]@bugs.debian.org together with some (friendly) explanations if necessary.

Tag the bug as "patch available" by running

bts tags [bugnumber] + patch

Upload fixed package

Find a Debian member with upload privs or if you are one of those, just upload!