This page tries to explain quickly how bts-link works, and to answer most of the usual questions people have with it.

If you need more extensive informations about it, please contact the development mailing list.

bts-link is developed using git, on


bts-link brings the remote BTSes (Bug Tracking Systems) to our Debian BTS (aka debbugs), see the announcement.

Its purpose is to allow to Fire and forget bugs reports to upstreams, and let an automatic tool track the upstream bug status. It was once written to help the pkg-kde team, and was then extended so that other teams and other BTSes than bugzilla could be supported. Currently, bts-link supports:

  • bitbucket;

  • bugzilla (and issuezilla);

  • flyspray;

  • gforge (and fusionforge);

  • github;

  • gnats;

  • googlecode;

  • jira;

  • launchpad;

  • mantis;

  • php’s;

  • redmine;

  • roundup;

  • RT;

  • savane (from savannah);

  • sourceforge trackers;

  • trac.

How does it work ?

bts-link uses the forwarded state of debian bugs to detect URI’s of remote BTSes it knows about. The current configuration file defines which BTSes are known, and is always available from gitweb.

Then, based on its information, it polls the remote BTSes, gets the remote bug status, and resolution if the bug was closed, and acts accordingly. Depending on the remote BTS, it may know how to navigate to the proper active bug in case a remote bug was a duplicate of another one.

When it is executed ?

bts-link is executed on a Debian project machine ( every Monday and Thursday at 16.00 UTC.

Executions statistics

Here there are some statistics about all the actions performed by bts-link.

How you can help

There are several way you can help bts-link:

  • forward all your packages (upstream) bugs to upstreams BTSes, and mark the Debian bugs as forwarded;

  • alert us of any missing packages in the list of those currently checked (you can refer to the packages list in the configuration file);

  • ask to add support for any BTS not currently supported;

  • provide patches when needed :)

To hack on bts-link, join the[mailing-list] and the Salsa project, and be part of it!

Gory Details

bts-link uses usertags to store its informations. The user is and it uses status-* and resolution-* (user)tags to store those informations.

Then each time the upstream bug status changes, bts-link takes the following decisions:

  • if the bug was previously opened, then closed: it tags the debian bug fixed-upstream ;

  • if the bug was previously closed, then re-opened: it removes the tag fixed-upstream ;

  • if the upstream resolution is also detected as a wontfix-like (it does not catches everyone of them though): it adds a wontfix tag (and it will remove it also if the resolution moves from a wontfix state to another one).

  • duplicates ? : to be documented

  • merged-upstream ?

bts-link uses the tags like that:

  • fixed-upstream is meant as "hey, this bug has been reported as fixed upstream, please checks it’s true" ;

  • fixed-upstream + wontfix: this special combination means in fact wontfix-upstream but this tag does not exists.

bts-link will never ever try to change tags in any other conditions. It hence means that if you (as a Debian Maintainer) think that the bug isn’t fixed upstream, whatever upstream claims, you can completely remove the fixed-upstream tag, bts-link won’t force it back, except if upstream re-opens the bug, then closes it again.

A list of all bugs having been managed by bts-link should be available at : for the curious ones (attention, huge report).