Scroll to navigation

BTS(1) BTS(1)

NAME

bts - command-line interface for Debian's Bug Tracking System (BTS)

SYNOPSIS

Send Bug Change Request

bts [options] command [#comment] [, command [#comment]] ...

  • Bug State commands:
    done|close, reopen, archive, unarchive.
  • Bug Organisation commands:
    reassign, clone, merge, forcemerge, unmerge.
  • Metadata commands:
    retitle, summary, severity,
    forwarded, notforwarded,
    blocked, unblock,
    submitter.
  • Bug Linking commands:
    affects.
  • Version Tracking commands:
    found, notfound, fixed, notfixed.
  • Tagging commands:
    tags, user, usertags.
  • Coordination commands:
    owner, noowner|disown, claim, unclaim.
  • Blast radius control commands:
    package, limit.

Compose Quoted Reply With In-Line Bug Changes

bts reply bug-no[#msg-no] , command [#comment] [command [#comment]]...

Set Implicit Bug from MUA Message Context

bts context < bug-message.eml

Read Bugs (Web or E-Mail)

bts show|bugs bug-selection...

Prepare to Work Offline

bts cache|cleancache bug-selection...

Manage $EMAIL Subscription

bts subscribe|unsubscribe bug-number

Contribute to Spam Fighting

bts reportspam|spamreport bug-number...

Scripting

  • List matching bug numbers:
    bts select bug-selection...
  • Fetch Live Bug Status:
    bts status bug-number
  • List bugs in local cache (for shell completion):
    bts listcachedbugs

About bts(1)

bts version|help

EXAMPLE

Change bugs

 $ bts severity 69042 normal
 $ bts merge 69042 43233
 $ bts retitle 69042 This is a better bug description

Many canges at once (new implicit bug syntax)

 $ bts severity 69042 normal , merge with 43233 , retitle Another title

Many canges at once (classic syntax)

 $ bts severity 69042 normal , merge it 43233 , retitle it Another title
 $ bts severity 69042 normal , merge -1 43233 , retitle -1 Another title

Read complete bug report discussion

 $ bts show 69042         # in a browser
 $ bts show --mbox 69042  # in a mailreader - all messages

List bugs

 $ bts show wget          # all bugs in a package
 $ bts show from:$EMAIL   # reported by you

Read all mails for several bugs

 $ bts show --mbox             # in packages maintained by you
 $ bts show --mbox deb@e.mail  # .. or someone else's
 $ bts show --mbox src:wget    # in a source package

Reply to bug

 $ bts reply 43233            # reply to bug no. 43233
 $ bts reply 43233 , done     # .. and add pseudoheader to close
 $ bts done 43233 , reply     # .. other way around also works
 # Quote a message
 $ bts reply 43233#15         # reply to bug no. 43233 quoting message 15
 $ bts reply 43233#15 , done  # .. and add Control: pseudoheader to close

Reply to bug on stdin, i.e. from command-line mailreader (MUA)

 $ bts reply -                  # reply and quote piped bug message
 $ bts reply - , close          #.. and close bug
 $ bts severity normal , close  #.. 'reply -' is implied inside supported MUA

Hint: Run from (neo)mutt <pipe-entry> command ("|" key).

Change bug from command-line mailreader

 $ bts context , retitle 'flub: Does not nub!' , reassign flub

Subscribe $EMAIL to a bug:

 $ bts subscribe 69042

List selected bugs - for scripting:

 $ bugs=$(bts select src:libc6)
 $ for bug in $bugs; do echo $bug needs fixing; done

DESCRIPTION

bts is the command-line interface for Debian's Bug Tracking System (BTS). It is intended for use by Debian contributors and if you're reading this that means *you*.

bts helps make the many common tasks involving bugs in Debian more convenien and enhances your workflow with offline capabilities through local caching.

Contributing to Bugs

Debian invites everyone to contribute by reporting, analyzing, replying to and triaging bugs -- without the need for permission or so much as an account.

A standard e-mail address (see $EMAIL) and a willingness to learn and collaborate is all that's needed to participate.

That being said we ask you to use bts and the BTS in general responsibly. Start by subscribing to packages (pts-subscribe(1)) or particular bugs of interest to you ("bts subscribe 69042"). Try to observe other Debian contributors' working conventions. The Debian Mentors community <https://wiki.debian.org/DebianMentors> is happy to help if you have questions.

You can find more on how we work at <https://wiki.debian.org/BugTriage> and <https://wiki.debian.org/BugReport/WorkingOn>.

Mistakes happen, but consider that other busy volunteers may have to use time they could otherwise spend fixing bugs to help you clean them up.

To learn from other people in an in-person setting you may find a Bug Squashing Party or more general Debian Event to attend near you: <https://wiki.debian.org/BSP>, <https://wiki.debian.org/DebianEvents>.

Workflows

bts supports reading bugs in a web- or e-mail-based worflow, but to make changes bts will always send e-mail to a BTS service e-mail address (service@bugs.debian.org).

The web-based workflow supports both graphical and command-line browsers. While graphical browsers such as firefox or chromium may be familiar, you should consider traditional command-line browsers such as w3m(1) or lynx(1) for allowing a more focused workflow without context switches out of your terminal.

The software running the Debian BTS, "Debbugs", has first-class support for these browsers being from the same era of computing.

To make reading and changing bugs enjoyable a highly configurable command-line e-mail client (MUA) such as mutt(1), neomutt(1) or aerc(1) is recommended. By using bts reply and bts context together with your MUA's pipe command you can make full use of bts without so much as leaving your MUA. WARNING: Terminal mailing can be *highly* addictive.

E-Mail Processing

Being E-Mail BTS change requests are asynchrounous and may take considerable time to get through anti-spam measures. You should expect up to half an hour of delay when making your first change.

You will receive an acknowledgment mail from the BTS when the changes are accepted. You can file ACK messages into a folder for mail delivery troubleshooting purposes (check the X-Debian-PR-Message: header for automated filtering) or suppress them using --no-ack or BTS_SUPPRESS_ACKS=yes.

Sending E-Mail

To get started with bts right now use --smtp-reportbug to send emails exclusively to BTS addressess without having to worry about configuration until you need more.

Once you want to send mail directly to wider internet destinations outside BTS mail addresses (for CC'ing people) bts supports the following:

  • interactive command-line E-Mail clients (MUAs): mutt, neomutt and aerc using --mutt,
  • connecting directly to an SMTP server using --smtp-host,
  • system mailer (sendmail compatible) (see --sendmail)

Control Commands

The commands used by bts mirror Debbugs control commands but with support for abbreviations, more relaxed syntax and helpful local validation and cross-checking of the current bug state on the BTS server.

Debbugs control reference: <https://www.debian.org/Bugs/server-control>

bts is also less strict about what constitutes a valid bug number. For example the following are understood:

 $ bts severity Bug#85942 normal
 $ bts severity \#85942 normal

In the latter command a POSIX shell will interpret the hash ("#") as starting a a comment since it's not in the middle of a shellword, so you need to quote or escape it it as we've done here.

bts allows you to abbreviate commands to the shortest unique substring. It understands "bts cl 85942" as an alias for the "close" command.

Control Command Comments

It is possible to add comments to BTS control commands to explain why the changes were made:

 $ bts severity 30321 normal \#Not as severe as claimed

Note that POSIX shells will remove these comments unless the hash "#" comment character is escaped with a backslash as we've done above or quoted with single '' or double quotes "" as below.

 $ bts severity 30321 normal '# Still not all that severe'

Generally speaking it's preferred to use the reply command to include "Control" pseudoheaders in your response to the bug report instead. However including comments can still be useful in that context to document what you want to achive to other contributors in complex cases.

Multiple Commands

You can send multiple commands in a single e-mail by separating them with a period or comma, like so:

 $ bts severity 95672 normal , done 96642 0.38-7 \#Fixed by fix-it.patch

It is important the commas are surrounded by whitespace so your shell passes them to bts as distinct arguments.

 $ bts severity 95672 normal , merge 95672 95673 \#they are the same!

Consistency Checks

Many commands support internal and online consistency checks. For example:

  • fixed, found: complain when the record that's being made already exists in the BTS,
  • notfixed, notfound: complain when the record being removed doesn't exist,
  • done: checks whether the bug is alread marked 'done',
  • archive, unarchive: check whether the bug is already/not yet archived.

When multiple commands all checks must succeed before any email is sent so you may fearlessly iterate on bts commands.

Many of the checks involve fetching online information from the BTS. Use --offline to disable these. Purely bts internal consistency checks such as marking the same bug as done twice cannot be bypassed this way.

The Implicit Bug

To refer to the last mentioned bug number minus one "-1" may be used. The deprecated alias "it" is also allowed. For example you could write:

 $ bts severity 95672 wishlist , retitle -1 bts: please add a foo option

Alternatively you can also omit the bug number entirely as long as the resulting usage is unambigous, i.e. the argument(s) don't look like bug-numbers.

 $ bts done 95672 , fixed 0.1-3

Every command allows at least one keyword of to/by/from/with/since/email/+/-/= (see COMMANDS) to disambiguate the meaning.

Commands that take multiple bug numbers (assign/merge/blocked) require the use of a keyword to omit the implicit bug argument, but it is optional for other commands.

 $ bts reopen 95672 , merge with 123456   # is equivalent to:
 $ bts reopen 95672 , merge -1 123456
 $ bts reopen 95672 , blocked by 123456   # is equivalent to:
 $ bts reopen 95672 , blocked -1 123456

When the clone command is involved the meaning of -1 can become confusing. Below we allocate -1 as a "new ID" instead of using it to refer to the previously mentioned bug number 95672. Consequently:

 $ bts done 95672 , clone to -1 -2        # is equivalent to:
 $ bts done 95672 , clone 95672 to -1 -2

and similarly

 $ bts done 95672 , clone -1 -1 -2        # expands to:
 $ bts done 95672 , clone 95672 -1 -2

Further, after the clone -1 command '-1' no longer refers to the implicit bug number, but rather the number newly allocated by the BTS server. You can use 'it' or the keyword syntax to disambiguate.

 $ bts clone 95672 to -1 -2 , done        # expands to:
 $ bts clone 95672 to -1 -2 , done 95672

whereas

 $ bts clone 95672 to -1 -2 , done -1     # is already fully expanded.

OPTIONS

bts examines the devscripts configuration files as described below. Command-line options override the configuration file settings as you'd expect.

See also "Workflows" in DESCRIPTION.
Make bts use cached bugs for the show and bugs commands, if a cache is available for the requested data. See the cache command, below for information on setting up a cache.
Opposite of --offline; overrides any configuration file directive to work offline.
Use command-line e-mail workflow for reading bugs and sending change request emails. When asked to display bugs invoke a mail reader (--mailreader, BTS_MAIL_READER). When sending emails default to composing in a command-line email client (--mutt, BTS_MUTT_COMMAND).
Use web workflow for reading bugs. Opposite of --mail. When asked to display bugs use a web-browser ($BROWSER or sensible-browser(1)).
Do not send emails but print them to standard output.
Should we attempt to cache new versions of BTS pages when performing show/bugs commands? Default is to cache.
When running a bts cache command, should we only mirror the basic bug (min), or should we also mirror the mbox version (mbox), or should we mirror the whole thing, including the mbox and the boring attachments to the BTS bug pages and the acknowledgement emails (full)? Default is min.
Time in seconds to delay between each download, to avoid hammering the BTS web server. Default is 0 seconds.
A (shell) command invoked to read a bug mailbox.

The COMMAND must contain the replacement marker "%s" which is expanded to path to an mbox file.

Default depends on mailreaders avalable on the system. See BTS_MAIL_READER config option.

Send carbon copies to a list of users. CC_EMAIL_ADDRESS should be a comma-separated list of email addresses. Multiple options add more CCs.
Add the addresses specified in the configuration file option BTS_DEFAULT_CC to the list specified using --cc-addr. This is the default.
Do not add addresses specified in BTS_DEFAULT_CC to the carbon copy list.
Specify the system mailer (sendmail compatible) command to use for sending email.

The command will be split on white space and will not be passed to a shell. Default is /usr/sbin/sendmail. The -t option will be automatically added if the command is /usr/sbin/sendmail or /usr/sbin/exim*. For other mailers, if they require a -t option, this must be included in the SENDMAILCMD, for example: --sendmail="/usr/sbin/mymailer -t".

Conflicts with explicit --mutt, --smtp-hots and --smtp-reportbug. Overrides implicit --mutt and BTS_SMTP_HOST.

Use interactive command line mail client (BTS_MUTT_COMMAND) for sending of mails instead of SMTP (--smtp-host) or system mailer (--sendmail).

Note that one of $DEBEMAIL or $EMAIL must be set in the environment in order to use mutt to send emails.

If --mutt is given --interactive and --force-interactive are ineffective.

--mutt is implied when bts is invoked from inside a command-line mail client as determined by $_ (see BTS_MUTT_COMMAND for detailed logic) and e-mail workflow is active (--mail, BTS_WORKFLOW=mail).

Cancel implicit or explicit --mutt reverting to sending with SMTP or system mailer instead.
Timeout when fetching bug status information from the BTS in --online mode.

Defaults to 5 seconds when --interactive or --mutt are active; 30 seconds otherwise (--no-interactive).

Specify an SMTP host. If given, bts will send mail by talking directly to this SMTP host rather than by invoking a sendmail command.

The host name may be followed by a colon (":") and a port number in order to use a port other than the default. It may also begin with "ssmtp://" or "smtps://" to indicate that SMTPS should be used.

If SMTPS not specified, bts will still try to use STARTTLS if it's advertised by the SMTP host.

Note that one of $DEBEMAIL or $EMAIL must be set in the environment in order to use direct SMTP connections to send emails.

Conflicts with --mutt and --sendmail. Overidden by --smtp-reportbug.

Use the the reportbug.debian.org SMTP server to send bug reports and change requests (no account registration or authentication needed).

Equivalent to --smtp-host=reportbug.debian.org:587 --interactive.

Note that reportbug.debian.org is rate limited to a small number of mails per hour and only email destined for bugs.debian.org is accepted. Consequently using --cc-addr, BTS_DEFAULT_CC, reply or reassign commands will likeley cause mails to be rejected while sending.

Specify the credentials to use when connecting to the SMTP server specified by --smtp-host. If the server does not require authentication then these options should not be used.

If a username is specified but not a password, bts will prompt for the password before sending the mail.

Specify the name to use in the HELO command when connecting to the SMTP server; defaults to the contents of the file /etc/mailname, if it exists.

Note that some SMTP servers may reject the use of a HELO which either does not resolve or does not appear to belong to the host using it.

Use a debbugs server other than the default https://bugs.debian.org.
Download a bug report again, even if it does not appear to have changed since the last cache command. Useful if a --cache-mode=full is requested for the first time (otherwise unchanged bug reports will not be downloaded again, even if the boring bits have not been downloaded).
Suppress any configuration file --force-refresh option.
Download only new bugs when caching. Do not check for updates in bugs we already have.
When caching bug reports, include those that are marked as resolved. This is the default behaviour.
Reverse the behaviour of the previous option. That is, do not cache bugs that are marked as resolved.
Suppress acknowledgment mails from the BTS. Note that this will only affect the copies of messages CCed to bugs, not those sent to the control bot.
Do not suppress acknowledgement mails. This is the default behaviour.
Before sending an e-mail, display the content and allow it to be edited, or the sending cancelled.
Force interactive editing immediately. Similar to --interactive, except editor is spawned before the send/cancel/edit prompt.
Immediately send bug change request e-mails without confirmation.

This is the default behaviour except if --mutt is implicitly active and for some commands which require composing a written reply (done, reply).

When running bts cache, only display information about newly cached pages, not messages saying already cached. If this option is specified twice, only output error messages (to stderr).
Do not read any configuration files. This can only be used as the first option given on the command-line.

COMMANDS

For full details about the commands, see the BTS documentation. <https://www.debian.org/Bugs/server-control>

Display selected bugs in a web browser (default or --web) or in a mail reader when --mbox is given.

Options that may be specified after the bugs sub-command in addition to or instead of options at the start of the command-line are: -o/--offline/--online, -m/--mbox, --mailreader and --[no-]cache. These are described earlier in this manpage. If either the -o or --offline option is used, or there is already an up-to-date copy in the local cache, the cached version will be used.

When using --mbox reading more than one bug report's mails at once using the argument syntax described below is possible.

The meanings of the possible arguments are as follows:

(none)
If nothing is specified, bts bugs will display your bugs, assuming that either DEBEMAIL or EMAIL (examined in that order) is set to the appropriate email address.
Display bug number bug_number.
Display the bugs for the package package.
Display the bugs for the source package package.
Display the bugs for the maintainer email address maintainer.
Display the bugs for the submitter email address submitter.
Display the bugs which are tagged with tag.
Display the bugs which are tagged with usertag tag. See the BTS documentation for more information on usertags. This will require the use of a users=email option.
:
Details of the bug tracking system itself, along with a bug-request page with more options than this script, can be found on https://bugs.debian.org/. This page itself will be opened if the command 'bts bugs :' is used.
Display the front page of the release-critical pages on the BTS. This is a synonym for https://bugs.debian.org/release-critical/index.html. It is also possible to say release-critical/debian/main.html and the like. RC is a synonym for release-critical/other/all.html.

After the argument specifying what to display, you can optionally specify options to use to format the page or change what it displayed. These are passed to the BTS in the URL downloaded. For example, pass dist=stable to see bugs affecting the stable version of a package, version=1.0 to see bugs affecting that version of a package, or reverse=yes to display newest messages first in a bug log.

If caching has been enabled (that is, --no-cache has not been used, and BTS_CACHE has not been set to no), then any page requested by bts show will automatically be cached, and be available offline thereafter. Pages which are automatically cached in this way will be deleted on subsequent "bts show|bugs|cache" invocations if they have not been accessed in 30 days. Warning: on a filesystem mounted with the "noatime" option, running "bts show|bugs" does not update the cache files' access times; a cached bug will then be subject to auto-cleaning 30 days after its initial download, even if it has been accessed in the meantime.

Other bts commands following on the command-line will be executed after sensible-browser has quit. With most post modern graphical browsers (firefox, chromium) will exit immediately, but when using a terminal browser bts wait for you to quit it before continuing command execution.

The desired browser can be specified and configured by setting the BROWSER environment variable. See sensible-browser(1).

The value of BROWSER may consist of a colon-separated series of browser command parts. These should be tried in order until one succeeds. Each command part may optionally contain the string %s; if it does, the URL to be viewed is substituted there. If a command part does not contain %s, the browser is to be launched as if the URL had been supplied as its first argument. The string %% must be substituted as a single %.

Rationale: We need to be able to specify multiple browser commands so programs obeying this convention can do the right thing in either X or console environments, trying X first. Specifying multiple commands may also be useful for people who share files like .profile across multiple systems. We need %s because some popular browsers have remote-invocation syntax that requires it. Unless %% reduces to %, it won't be possible to have a literal %s in the string.

Uses the SOAP interface to output a list of bugs which match the given selection requirements.

The following keys are allowed, and may be given multiple times.

Binary package name.
Source package name.
E-mail address of the maintainer.
E-mail address of the submitter.
Bug severity.
Completion status of the bug. One of open, done, or forwarded.
Tags applied to the bug. If users is specified, may include usertags in addition to the standard tags.
Bug's owner.
Address of someone who sent mail to the log.
Bugs which affect this package.
List of bugs to search within.
Users to use when looking up usertags.
Whether to search archived bugs or normal bugs; defaults to 0 (i.e. only search normal bugs). As a special case, if archive is both, both archived and unarchived bugs are returned.

For example, to select the set of bugs submitted by jrandomdeveloper@example.com and tagged wontfix, one would use

bts select submitter:jrandomdeveloper@example.com tag:wontfix

If a key is used multiple times then the set of bugs selected includes those matching any of the supplied values; for example

bts select package:foo severity:wishlist severity:minor

returns all bugs of package foo with either wishlist or minor severity.

Uses the SOAP interface to output status information for the given bugs (or as read from the listed files -- use - to indicate STDIN).

By default, all populated fields for a bug are displayed.

If verbose is given, empty fields will also be displayed.

If fields is given, only those fields will be displayed. No validity checking is performed on any specified fields.

Compose a reply to a bug BTS including bug changes.

A draft is prepared, quoting message-no or the latest non-automated message taken from either 1) the bug-number's online MBOX message archive or 2) the MBOX or single raw email message written to standard input (-).

All other bug change commands given are included in the mail as pseudoheader lines -- mostly 'Control:' but more idiomatic headers bts knows about may be used instead.

A reply command reading from STDIN is executed implicitly before other commands when bts is invoked from a supported MUA (see --mutt). The implicit command is cancelled when an explicit reply, context, show|bugs or status command is present.

Read email or MBOX from stdin to establish implicit bug context.

Similar to reply but for sending plain control@ messages without including a written rationale.

The clone command duplicates a bug report.

It is useful in the case where a single report actually indicates that multiple distinct bugs have occurred. "New IDs" are negative numbers, separated by spaces, which may be used in subsequent control commands to refer to the newly duplicated bugs. A new report is generated for each new ID.

Indicate no further action is expected on bug.

Changes bug's completion state to "done", closing it for now. Optionally add a version tracking record that it was fixed in version.

The BTS will record who completed a bug. You can see this in the bug status 'done' field:

    $ bts status 123456 fields:done

The done command always asks you to compose a mail interactively. Please document why the bug is being closed in your message.

While you should specify which version of the package fixed the bug if possible you can also do this later with the fixed command.

Bugs which remain closed for about a month without email activity are archived (made read-only). Use unarchive to undo this.

Closed, but non-archived bugs can be reopened with the found command.

(Deprecated) Record that a bug previously marked done should be acted upon again by the maintainer. Optionally change submitter -- unclear why you'd want to do this here.

Clears all fixed version tracking records only if bug is currently closed -- not very predictable behaviour and it is somewhat rude.

Instead prefer the more predictable found command (without arguments) if you really want to do this, but also consider the more respectful approach documented there.

Archive a bug that has previously been archived but is currently not. The bug must fulfill all of the requirements for archiving with the exception of those that are time-based.
Unarchive a bug that is currently archived.
Change the title of the bug.
Select a message number that should be used as the summary of a bug.

If no message number is given, the summary is cleared.

Change the submitter mail address of a bug or a number of bugs, with ! meaning the BTS should use the mail address of the change request e-mail message.
Change the assigned package set for all bugs given. This indicates all the specified bugs are presumed to need fixing in one of these packages.

Clears all existing version tracking records (found and fixed) for each bug. If the optional version is given a 'found' record for the new packages is added. If the affected version is is not yet known use the found command once an analysis is avalable.

If other packages are merely receiving unactionable reports use the affects command to make the bug show up in their bug listings.

If the bug is likeley to need individual fixes across several packages you should instead clone the bug and reassign the clone to the other package(s). For example:

 $ bts clone 69042 to -1 , assign -1 to other-package

The command adds the maintainers of the new package to CC if --mutt or --force-interactive are active.

Add a version tracking record to indicate bug was found to be present in the given version of the binary package to which bug is currently assigned or source-package if given.

This implicitly changes bug's completion state to not done indicating it should be acted upon by the maintainer unless version is less than the current highest fixed version on record, see:

    $ bts status 123456 fields:fixed_versions
(Expert) Clear all fixed version tracking records in bug and change it's completion state to indicate that it is not done and should be acted upon my the maintainer -- this is somewhat rude so you better be sure.

To be respectful consider using the reply command and appeal to the maintainer for why they should still act on the bug. You can simultaniously use additional found commands to record which versions you can demonstrate to be affected in the BTS.

Remove a mistaken record that bug is present in the given version of the binary package to which it is currently assigned or source-package if given.

Do not use this if changes were actively made in Debian to address bug. Use done or fixed instead as appropriate.

Version tracking records for a bug are cleared entirely by the reassign command.

Add a version tracking record to indicate a closed bug was also fixed in version of the binary package bug is currently assigned to or source-package if given.

This does not affect bug's completion state. Use the done command to indicate no further action is expected on a bug instead.

Remove an erroniosly added version tracking record for bug being fixed in the given version of the binary package to which it currently assigned or source-package if given.

This does not affect bug's completion state. Use the found command to reopen a bug that was erroniously marked done and fixed in version.

If the bug is not assigned to the correct package use the reassign command instead which also removes all version tracking records.

Note: notfixed is equivalent to the sequence of commands "found bug version", "notfound bug version".

Record that a bug is blocked from being fixed by a set of other blocker-bugs.
Remove records that bug is blocked from being fixed by each of the blocker bugs.
Merge a set of bugs together.
Forcibly merge a set of bugs together. The first bug listed is the master bug, and its settings (those which must be equal in a normal merge) are assigned to the bugs listed next.
Unmerge a bug.
Add or remove a tags on a bug. The tag must be from the predefined list of valid tags below or abbreviated to a unique substring of one.
Using fixed will set the tag fixed, not fixed-upstream. However fix would not be acceptable.
Operating on several tags in one command is possible. The + or - operators define whether subsequent tags are added or removed.
The tag command defaults to adding tags (+) while the tags command will currently complain if none of +/-/= are specified. In a future release (Forky+1) the 'tags' deafult operation will change to overriding the tags set (=).

At least one tag must be specified, unless the = flag is used. The command below will remove all tags from the specified bug.

 $ bts tags <bug> =
Adding or removing the security tag will add "team@security.debian.org" to the CC list of the control email.
The list of valid tags and their significance is available at <https://www.debian.org/Bugs/Developer#tags>. The current valid tags are:

patch, wontfix, moreinfo, unreproducible, fixed, help, security, upstream, pending, d-i, confirmed, ipv6, lfs, fixed-upstream, l10n, newcomer, a11y, ftbfs

There is also a tag for each release of Debian since "potato". Note that this list may be out of date, see the website for the most up to date source.

 # Add moreinfo tag
 $ bts tag 123456 moreinfo
 $ bts tag 123456 +moreinfo
 $ bts tag 123456 + moreinfo
 # Add fixed, remove wontfix and unreproducible tags
 $ bts tag 123456 +fixed -wontfix -unreproducible
 $ bts tag 123456 +fixed -wontfix  unreproducible
 # Clear tag list
 $ bts tags 123456 =
Record that a bug affects a package other than the bug's assigned package.

The given bug will be listed in the affected package's bug list. This should generally be used where the bug is severe enough to cause multiple reports from users to be assigned to the wrong package. At least one package must be specified, unless the = flag is used. The command

 $ bts affects <bug> =

will remove all indications that bug affects other packages.

Specify a user email address before using the usertags command.
Mirrors tags command, but with freeform tags namespaced by preceeding user command or $EMAIL/$DEBEMAIL (in that order) from the enviornment.

Add or remove freeform "usertags" on a bug. The name of freeform-tags must be exact, there is no pre-defined list of valid tag names unlike with the tags command.

See tags command for detailed usage. TODO: check usage is exactly the same regarding '+moreinfo' vs '+ moreinfo'.

Record that you have claimed a bug (e.g. for a bug squashing party). claim should be a unique token allowing the bugs you have claimed to be identified; an e-mail address is often used.

If no claim is specified, the environment variable DEBEMAIL or EMAIL (checked in that order) is used.

See <https://lists.debian.org/msgid-search/20050908170731.GA20584@cyan.localnet>.

Remove the record that you have claimed a bug.

If no claim is specified, the environment variable DEBEMAIL or EMAIL (checked in that order) is used.

Change the severity of a bug. Available severities are: wishlist, minor, normal, important, serious, grave, critical. The severity may be abbreviated to any unique substring.
Mark the bug as forwarded to the given address (usually an email address or a URL for an upstream bug tracker).
Mark a bug as not forwarded.
The following commands will only apply to bugs against the listed packages; this acts as a safety mechanism for the BTS. If no packages are listed, this check is turned off again.
The following commands will only apply to bugs which meet the specified criterion; this acts as a safety mechanism for the BTS. If no values are listed, the limits for that key are turned off again. If no keys are specified, all limits are reset.
E-mail address of the submitter.
Date the bug was submitted.
Subject of the bug.
Message-id of the initial bug report.
Binary package name.
Source package name.
Tags applied to the bug.
Bug severity.
Bug's owner.
Bugs affecting this package.
Whether to search archived bugs or normal bugs; defaults to 0 (i.e. only search normal bugs). As a special case, if archive is both, both archived and unarchived bugs are returned.

For example, to limit the set of bugs affected by the subsequent control commands to those submitted by jrandomdeveloper@example.com and tagged wontfix, one would use

bts limit submitter:jrandomdeveloper@example.com tag:wontfix

If a key is used multiple times then the set of bugs selected includes those matching any of the supplied values; for example

bts limit package:foo severity:wishlist severity:minor

only applies the subsequent control commands to bugs of package foo with either wishlist or minor severity.

Change the "owner" address of a bug, with ! meaning "use the address on the current email as the new owner address".

The owner of a bug accepts responsibility for dealing with it.

Mark a bug as having no "owner".
Subscribe the given email address to the specified bug reports.

If no email address is specified, the environment variable DEBEMAIL or EMAIL (in that order) is used. If those are not set, or ! is given as email address, your mail system will determine the address used.

After executing this command, you will be sent a subscription confirmation to which you have to reply. When subscribed to a bug report, you receive all relevant emails and notifications.

Use the unsubscribe command to undo the subscription.

Unsubscribe the given email address from the specified bug reports.

As with subscribe above, if no email address is specified, the environment variables DEBEMAIL or EMAIL (in that order) is used. If those are not set, or ! is given as email address, your mail system will determine the address used.

You will receive an unsubscription confirmation to which you need to reply for the unsubscription to be effectiv.

Currently there is no self-service mechanism to list all your subscriptions or to unsubscribe from all bugs. Contact the Debian Listmaster Team <https://wiki.debian.org/Teams/ListMaster> who are responsible for the bug subscription infrastructure.

Record that bug constains SPAM messages. A Debian contributor will review the bug log and remove the offending message(s).
Generate or update a cache of bug reports for the given email address or package. By default it downloads all bugs belonging to the email address in the DEBEMAIL environment variable (or the EMAIL environment variable if DEBEMAIL is unset). This command may be repeated to cache bugs belonging to several people or packages. If multiple packages or addresses are supplied, bugs belonging to any of the arguments will be cached; those belonging to more than one of the arguments will only be downloaded once. The cached bugs are stored in $XDG_CACHE_HOME/devscripts/bts/ or, if XDG_CACHE_HOME is not set, in ~/.cache/devscripts/bts/.

You can use the cached bugs with the -o switch. For example:

  bts -o bugs
  bts -o show 12345

Also, bts will update the files in it in a piecemeal fashion as it downloads information from the BTS using the show command. You might thus set up the cache, and update the whole thing once a week, while letting the automatic cache updates update the bugs you frequently refer to during the week.

Some options affect the behaviour of the cache command. The first is the setting of --cache-mode, which controls how much bts downloads of the referenced links from the bug page, including boring bits such as the acknowledgement emails, emails to the control bot, and the mbox version of the bug report. It can take three values: min (the minimum), mbox (download the minimum plus the mbox version of the bug report) or full (the whole works). The second is --force-refresh or -f, which forces the download, even if the cached bug report is up-to-date. The --include-resolved option indicates whether bug reports marked as resolved should be downloaded during caching.

Each of these is configurable from the configuration file, as described below. They may also be specified after the cache command as well as at the start of the command-line.

Finally, -q or --quiet will suppress messages about caches being up-to-date, and giving the option twice will suppress all cache messages (except for error messages).

Beware of caching RC, though: it will take a LONG time! (With 1000+ RC bugs and a delay of 5 seconds between bugs, you're looking at a minimum of 1.5 hours, and probably significantly more than that.)

Clean the cache for the specified package, maintainer, etc., as described above for the bugs command, or clean the entire cache if ALL is specified. This is useful if you are going to have permanent network access or if the database has become corrupted for some reason. Note that for safety, this command does not default to the value of DEBEMAIL or EMAIL.
List cached bug ids (intended to support bash completion). The optional number argument restricts the list to those bug ids that start with that number.
Display version and copyright information.
Display a short summary of commands, suspiciously similar to parts of this man page.

ENVIRONMENT VARIABLES

If this is set, the From: line in the email will be set to use this email address instead of your normal email address (as would be determined by mail).
If DEBEMAIL is set, DEBFULLNAME is examined to determine the full name to use; if this is not set, bts attempts to determine a name from your passwd entry.
If set, it specifies the browser to use for the show and bugs options. See sensible-brower(1).

CONFIGURATION VARIABLES

The two configuration files /etc/devscripts.conf and ~/.devscripts are sourced by a shell in that order to set configuration variables. Command-line options can be used to override configuration file settings. Environment variable settings are ignored for this purpose. The currently recognised variables are:

If this is set to yes, then it is the same as the --offline command line parameter being used. Only has an effect on the show and bugs commands. The default is no. See the description of the show command above for more information.
If this is set to no, then it is the same as the --no-cache command line parameter being used. Only has an effect on the show and bug commands. The default is yes. Again, see the show command above for more information.
How much of the BTS should we mirror when we are asked to cache something? Just the minimum, or also the mbox or the whole thing? The default is min, and it has the same meaning as the --cache-mode command-line parameter. Only has an effect on the cache. See the cache command for more information.
If this is set to yes, then it is the same as the --force-refresh command-line parameter being used. Only has an effect on the cache command. The default is no. See the cache command for more information.
Set the default Workflow Mode. Overidden by "Workflow Mode Options" --mail and --web, see OPTIONS. See also "Workflows" in DESCRIPTION.

When set to mail unlocks implicit enablement of --mutt.

Interactive command-line mail client (MUA) to use for reading mailbox files when using the mail workflow (--mail, BTS_WORKFLOW=mail).

Default depends on mailreaders avalable on the system. The following are tried in order (first match wins):

  • A (supported) MUA bts is running inside of as determined by examining $_, the 'underscore' environment variable).
  • 'mutt -f %s' -- if mutt is installed,
  • 'neomutt -f %s' -- if neomutt is installed,
  • 'aerc -I mbox:%s' -- if bts is invoked from inside aerc,
  • 'aerc mbox:%s' -- if aerc is installed otherwise.

Can be overridden by --mailreader command-line option.

The '%s' is replaced by the path to an MBOX file.

Interactive command-line mail client (MUA) to use for interactively composing and sending mails when --mutt is active or implied.

Default depends on mail clients avalable on the system. The following are tried in order:

  • A supported MUA bts is running inside of as determined by examining $_, the 'underscore' environment variable).
  • 'mutt -H %s' -- if mutt is installed,
  • 'neomutt -H %s' -- if neomutt is installed,

The '%s' is replaced by the path to a raw draft email message file including headers.

If this is set, specifies a sendmail command to use instead of /usr/sbin/sendmail. Same as the --sendmail command-line option.
Download only new bugs when caching. Do not check for updates in bugs we already have. The default is no. Same as the --only-new command-line option.
If this is set, specifies an SMTP host to use for sending mail rather than using the sendmail command. Same as the --smtp-host command-line option.

Note that this option takes priority over BTS_SENDMAIL_COMMAND if both are set, unless the --sendmail option is used.

If set to yes use Debian's open submission reportbug.debian.org SMTP server to send bug reports and change requests. No account registration or authentication is needed but submissions are rate-limited to a couple per hour.

If set to yes it is equivalent to setting both BTS_SMTP_HOST=reportbug.debian.org:587 and BTS_INTERACTIVE=yes.

If these options are set, then it is the same as the --smtp-username and --smtp-password options being used.
Same as the --smtp-helo command-line option.
If this is set to no, then it is the same as the --no-include-resolved command-line parameter being used. Only has an effect on the cache command. The default is yes. See the cache command for more information.
If this is set to yes, then it is the same as the --no-ack command line parameter being used. The default is no.
If this is set to yes or force, then it is the same as the --interactive or --force-interactive command-line parameter being used. The default is no.
Specify a list of e-mail addresses to which a carbon copy of the generated e-mail to the control bot should automatically be sent.
Specify the name of a debbugs server which should be used instead of https://bugs.debian.org.

SEE ALSO

Please see <https://www.debian.org/Bugs/server-control> for more details on how to control the BTS using emails and <https://www.debian.org/Bugs/> for more information about the BTS.

querybts(1), reportbug(1), pts-subscribe(1), devscripts.conf(5)

COPYRIGHT

This program is Copyright (C) 2001-2003 by Joey Hess <joeyh@debian.org>. Many modifications have been made, Copyright (C) 2002-2005 Julian Gilbey <jdg@debian.org> and Copyright (C) 2007 Josh Triplett <josh@freedesktop.org>.

It is licensed under the terms of the GPL, either version 2 of the License, or (at your option) any later version.

2025-12-28 Debian Utilities