bts(1) — devscripts — Debian unstable — Debian Manpages

bts(1) — devscripts — Debian unstable — Debian Manpages
MANPAGES
Skip Quicknav
Index
About Manpages
FAQ
Service Information
unstable
devscripts
/ bts(1)
links
language-indep link
package tracker
raw man page
table of contents
NAME
SYNOPSIS
EXAMPLE
DESCRIPTION
OPTIONS
COMMANDS
ENVIRONMENT VARIABLES
CONFIGURATION VARIABLES
SEE ALSO
other versions
trixie
2.25.15+deb13u1
trixie-backports
2.26.7~bpo13+1
testing
2.26.7
unstable
2.26.7
other languages
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
command
s:
done
close
reopen
archive
unarchive
Bug Organisation
command
s:
reassign
clone
merge
forcemerge
unmerge
Metadata
command
s:
retitle
summary
severity
forwarded
notforwarded
blocked
unblock
submitter
Bug Linking
command
s:
affects
Version Tracking
command
s:
found
notfound
fixed
notfixed
Tagging
command
s:
tags
user
usertags
Coordination
command
s:
owner
noowner
disown
claim
unclaim
Blast radius control
command
s:
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 changes at once (new implicit bug syntax)
$ bts severity 69042 normal , merge with 43233 , retitle Another title
Many changes 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
> is happy to help if you have
questions.
You can find more on how we work at
> and
>.
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:
>,
>.
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 addresses 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:
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 achieve 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.
Workflow Mode
Options
See also "Workflows" in
DESCRIPTION
-o
--offline
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.
--online
--no-offline
Opposite of
--offline
; overrides any configuration file directive
to work offline.
-m
--mail
--mbox
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
).
-w
--web
Use web workflow for reading bugs. Opposite of
--mail
. When asked
to display bugs use a web-browser
$BROWSER
or
sensible-browser(1)
).
-n
--no-action
Do not send emails but print them to standard output.
--cache
--no-cache
Should we attempt to cache new versions of BTS pages when performing
show
bugs
commands? Default is to cache.
--cache-mode=
min
mbox
full
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
--cache-delay=
seconds
Time in seconds to delay between each download, to avoid hammering the BTS
web server. Default is 0 seconds.
--mailreader=
COMMAND
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 available on the system. See
BTS_MAIL_READER
config option.
--cc-addr=
CC_EMAIL_ADDRESS
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.
--use-default-cc
Add the addresses specified in the configuration file option
BTS_DEFAULT_CC
to the list specified using
--cc-addr
. This
is the default.
--no-use-default-cc
Do not add addresses specified in
BTS_DEFAULT_CC
to the carbon copy
list.
--sendmail=
SENDMAILCMD
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
--mutt
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
).
--no-mutt
Cancel implicit or explicit
--mutt
reverting to sending with SMTP
or system mailer instead.
--soap-timeout=
SECONDS
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
).
--smtp-host=
SMTPHOST
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
. Overridden
by
--smtp-reportbug
--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.
--smtp-username=
USERNAME
--smtp-password=
PASSWORD
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.
--smtp-helo=
HELO
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.
--bts-server
Use a debbugs server other than the default
-f
--force-refresh
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).
--no-force-refresh
Suppress any configuration file
--force-refresh
option.
--only-new
Download only new bugs when caching. Do not check for updates in bugs we
already have.
--include-resolved
When caching bug reports, include those that are marked as resolved. This
is the default behaviour.
--no-include-resolved
Reverse the behaviour of the previous option. That is, do not cache bugs
that are marked as resolved.
--no-ack
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.
--ack
Do not suppress acknowledgement mails. This is the default behaviour.
-i
--interactive
Before sending an e-mail, display the content and allow it to be edited,
or the sending cancelled.
--force-interactive
Force interactive editing immediately. Similar to
--interactive
except editor is spawned before the send/cancel/edit prompt.
--no-interactive
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
).
-q
--quiet
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).
--no-conf
--noconf
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.
bugs
options
bug_number
package
maintainer
opt
val
...]
show
options
bug number
package
maintainer
opt
val
...]
bugs
options
] [
src:
package
from:
submitter
opt
val
...]
show
options
] [
src:
package
from:
submitter
opt
val
...]
bugs
options
] [
tag:
tag
usertag:
tag
opt
val
...]
show
options
] [
tag:
tag
usertag:
tag
opt
val
...]
bugs
release-critical
release-critical/
... |
RC
show
release-critical
release-critical/
... |
RC
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.
bug_number
Display bug number
bug_number
package
Display the bugs for the package
package
src:
package
Display the bugs for the source package
package
maintainer
Display the bugs for the maintainer email address
maintainer
from:
submitter
Display the bugs for the submitter email address
submitter
tag:
tag
Display the bugs which are tagged with
tag
usertag:
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
This page itself will be opened if the command
'bts bugs :' is used.
release-critical
RC
Display the front page of the release-critical pages on the BTS. This is a
synonym for
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.
select
key
value
...]
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.
package
Binary package name.
source
Source package name.
maintainer
E-mail address of the maintainer.
submitter
E-mail address of the submitter.
severity
Bug severity.
status
Completion status of the bug. One of
open
done
, or
forwarded
tag
Tags applied to the bug. If
users
is specified, may include
usertags in addition to the standard tags.
owner
Bug's owner.
correspondent
Address of someone who sent mail to the log.
affects
Bugs which affect this package.
bugs
List of bugs to search within.
users
Users to use when looking up usertags.
archive
Whether to search archived bugs or normal bugs; defaults to
(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.
status
bug
file:
file
fields:
field
field
...] |
verbose
...
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.
reply
bug
bug-number
message-no
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.
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.
context
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.
clone
bug
to
new_ID
new_ID
...]
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.
done
bug
in
by
since
] [
version
close
bug
in
by
since
] [
version
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.
reopen
bug
submitter
(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
bug
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
bug
Unarchive a
bug
that is currently archived.
retitle
bug
title
Change the
title
of the
bug
summary
bug
] [
messagenum
Select a message number that should be used as the summary of a
bug
If no message number is given, the summary is cleared.
submitter
bug
...]
submitter-email
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.
assign
bug
...] [
to
package
package
...]
version
reassign
bug
...] [
to
package
package
...]
version
Change the assigned
package
set for all
bug
s 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 available.
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.
found
bug
[in] [
source-package
version
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
found
bug
(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
version
s you can demonstrate to be affected in the BTS.
notfound
bug
] [
in
source-package
version
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.
fixed
bug
in
by
since
source-package
version
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.
notfixed
bug
] [
in
by
since
source-package
version
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
".
block
bug
by
with
blocker-bug
blocker-bug
...]
blocked
bug
] [
by
with
blocker-bug
blocker-bug
...]
Record that a
bug
is blocked from being fixed by a set of other
blocker-bugs.
unblock
bug
] [
from
with
by
blocker-bug
blocker-bug
...]
Remove records that
bug
is blocked from being fixed by each of the
blocker bugs.
merge
bug
with
bug
bug
...]
Merge a set of bugs together.
forcemerge
bug
] [
with
bug
bug
...]
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
bug
Unmerge a
bug
tag
bug
tag
tag
...]
tags
bug
tag
tag
...]
Add or remove a
tag
s on a
bug
. The tag must be from the
predefined list of valid tags below or abbreviated to a unique substring
of one.
Abbreviations
Using
fixed
will set the tag
fixed
, not
fixed-upstream
. However
fix
would not be acceptable.
Multiple tags
Operating on several tags in one command is possible. The
or
operators define whether subsequent tags are added or
removed.
Adding and
removing
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' default 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 =
CCs
Adding or removing the
security
tag will add
"team@security.debian.org" to the CC list of the control
email.
Avaliable
tags
The list of valid tags and their significance is available at
>. 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.
Examples
# 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 =
affects
bug
] [
package
package
...]
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 =
will remove all indications that
bug
affects other
packages.
user
email
Specify a user
email
address before using the
usertags
command.
usertag
bug
] [
] [
freeform-tag
...]
usertags
bug
] [
] [
freeform-tag
...]
Mirrors
tags
command, but with freeform tags namespaced by
preceding
user
command or
$EMAIL
/$DEBEMAIL
(in that order) from the environment.
Add or remove freeform "usertags" on a
bug
The name of
freeform-tag
s 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'.
claim
bug
[for] [
claim
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
>.
unclaim
bug
] [
for
] [
claim
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.
severity
bug
severity
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.
forwarded
bug
address
Mark the
bug
as forwarded to the given
address
(usually an
email address or a URL for an upstream bug tracker).
notforwarded
bug
Mark a
bug
as not forwarded.
package
package
...]
The following commands will only apply to bugs against the listed
package
s; this acts as a safety mechanism for the BTS. If no
packages are listed, this check is turned off again.
limit
key
value
]] ...
The following commands will only apply to bugs which meet the specified
criterion; this acts as a safety mechanism for the BTS. If no
value
s are listed, the limits for that
key
are turned off
again. If no
key
s are specified, all limits are reset.
submitter
E-mail address of the submitter.
date
Date the bug was submitted.
subject
Subject of the bug.
msgid
Message-id of the initial bug report.
package
Binary package name.
source
Source package name.
tag
Tags applied to the bug.
severity
Bug severity.
owner
Bug's owner.
affects
Bugs affecting this package.
archive
Whether to search archived bugs or normal bugs; defaults to
(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.
owner
bug
owner-email
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.
noowner
bug
disown
bug
Mark a bug as having no "owner".
bug
] [
email
] [
email
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
bug
...] [
email
] [
email
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 <
> who are
responsible for the bug subscription infrastructure.
spamreport
bug
] ...
reportspam
bug
] ...
Record that
bug
constains SPAM messages. A Debian contributor will
review the bug log and remove the offending message(s).
cache
options
] [
maint_email
pkg
src:
pkg
from:
submitter
cache
options
] [
release-critical
release-critical/
... |
RC
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.)
cleancache
package
src:
package
maintainer
cleancache
from:
submitter
tag:
tag
usertag:
tag
number
ALL
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
listcachedbugs
number
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.
version
Display version and copyright information.
help
Display a short summary of commands, suspiciously similar to parts of this
man page.
ENVIRONMENT VARIABLES
DEBEMAIL
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
).
DEBFULLNAME
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.
BROWSER
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:
BTS_OFFLINE
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.
BTS_CACHE
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.
BTS_CACHE_MODE=
min
mbox
full
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.
BTS_FORCE_REFRESH
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.
BTS_WORKFLOW
={
mail
web
Set the default
Workflow Mode
. Overridden by "Workflow Mode
Options"
--mail
and
--web
, see
OPTIONS
. See also
"Workflows" in
DESCRIPTION
When set to
mail
unlocks implicit enablement of
--mutt
BTS_MAIL_READER
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 available 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.
BTS_MUTT_COMMAND
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 available 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.
BTS_SENDMAIL_COMMAND
If this is set, specifies a
sendmail
command to use instead of
/usr/sbin/sendmail
. Same as the
--sendmail
command-line
option.
BTS_ONLY_NEW
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.
BTS_SMTP_HOST
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.
BTS_SMTP_REPORTBUG
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.
BTS_SMTP_AUTH_USERNAME
BTS_SMTP_AUTH_PASSWORD
If these options are set, then it is the same as the
--smtp-username
and
--smtp-password
options being used.
BTS_SMTP_HELO
Same as the
--smtp-helo
command-line option.
BTS_INCLUDE_RESOLVED
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.
BTS_SUPPRESS_ACKS
If this is set to
yes
, then it is the same as the
--no-ack
command line parameter being used. The default is
no
BTS_INTERACTIVE
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
BTS_DEFAULT_CC
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.
BTS_SERVER
Specify the name of a debbugs server which should be used instead of
SEE ALSO
Please see <
> for
more details on how to control the BTS using emails and
> for more information about the BTS.
querybts(1)
reportbug(1)
pts-subscribe(1)
devscripts.conf(5)
This program is Copyright (C) 2001-2003 by Joey Hess
. Many modifications have been made, Copyright (C)
2002-2005 Julian Gilbey and Copyright (C) 2007 Josh
Triplett .
It is licensed under the terms of the GPL, either version 2 of the
License, or (at your option) any later version.
2026-03-31
Debian Utilities
Source file:
bts.1.en.gz (from
devscripts 2.26.7
Source last updated:
2026-03-31T15:31:22Z
Converted to HTML:
2026-04-03T20:42:44Z
debiman HEAD, see
github.com/Debian/debiman
Found a problem? See the
FAQ