BTS(1)

📦

version 2.26.11ubuntu1 · 15 versions

2.26.11ubuntu1 · ubuntu stonking (latest)
2.22.2 · opensuse-leap 16.0
2.25.5 · epel 9
2.25.5 · epel 10
2.25.19ubuntu2 · ubuntu questing
2.22.1ubuntu1.2 · ubuntu jammy
2.25.33 · fedora 43
2.25.19 · fedora 43
2.22.1ubuntu1 · ubuntu jammy
2.23.7ubuntu0.2 · ubuntu noble
2.26.5 · fedora 44
2.23.4 · debian bookworm
2.23.7 · ubuntu noble
2.26.7 · ubuntu resolute
2.25.15 · debian trixie

✨ bts(1) ✨

okay bestie, welcome to the bts(1) manual page — this is the command-line interface for Debian's Bug Tracking System (BTS). No cap, it's giving bug-wrangling main character energy. Let's go. 💅

🌸 NAME 🌸

bts — command-line interface for Debian's Bug Tracking System (BTS). That's the name, periodt. 🫶

🦋 SYNOPSIS 🦋

💌 Send Bug Change Request 💌

Compose it like this, bestie:

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

Then you got these lil command squads:

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 💬

Reply AND change bugs at the same time? Obsessed.

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

📨 Act on Bugs from MUA or Message Context 📨

When the bug is already in your inbox energy:

bts context , commands ...  < 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: | indicates to run from (neo)mutt <pipe-entry> command (| key).

🔄 Change bug from command-line mailreader 🔄

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

👀 Show Bug selected from command-line mailreader 👀

| bts context , status
| bts context , show
| bts show                 # 'context' is implied in supported MUA
| bts subscribe

Hint: selecting several bugs/messages (<tag-prefix><pipe-message> in (neo)mutt) is supported for (only) some commands. See "COMMANDS".

$ bts subscribe 69042

🧑‍💻 List selected bugs - for scripting: 🧑‍💻

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

🌸 DESCRIPTION 🌸

okay bestie so bts is literally the command-line interface for Debian's Bug Tracking System (aka the BTS 💅). it's made for Debian contributors — and if you're reading this, that means you, yes you 🫶.

bts makes all the common bug-related tasks in Debian way more convenient, and it also levels up your workflow with offline capabilities thanks to local caching ✨.

🎀 Contributing to Bugs 🎀

Debian invites literally everyone to contribute — by reporting, analyzing, replying to and triaging bugs. no permission needed, no account needed, nothing 🔥.

all you actually need is a standard e-mail address (peep $EMAIL 👀) and a willingness to learn + collaborate. that's it. that's the whole vibe check ✅.

that being said, pls use bts and the BTS in general responsibly. start by subscribing to packages (pts-subscribe(1)) or to particular bugs that spark joy for you — like "bts subscribe 69042" 🦋. try to observe how other Debian contributors work, learn their conventions, match the energy. the Debian Mentors community <https://wiki.debian.org/DebianMentors> is so happy to help if you have questions 💜.

there's more on how we work at <https://wiki.debian.org/BugTriage> and <https://wiki.debian.org/BugReport/WorkingOn> 📚.

mistakes happen, but keep in mind other busy volunteers might have to spend time they'd rather be spending fixing bugs just to help you clean up after yourself 😭 be nice bestie.

and if you want to learn from people in an in-person setting, you might find a Bug Squashing Party or a more general Debian Event happening near you: <https://wiki.debian.org/BSP>, <https://wiki.debian.org/DebianEvents> 🎉.

🌈 Workflows 🌈

bts supports reading bugs in a web-based or e-mail-based workflow, but to actually 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. graphical browsers like firefox or chromium might feel familiar, but you should genuinely consider traditional command-line browsers like w3m(1) or lynx(1) — they let you have a way more focused workflow without context-switching 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. iconic compatibility tbh 💀.

to make reading and changing bugs actually enjoyable, a highly configurable command-line e-mail client (MUA) like 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. it's giving seamless. 🫶

WARNING: Terminal mailing can be highly addictive. no cap. proceed with caution 🔥🔥🔥

✨ E-Mail Processing ✨

since they're E-Mail BTS change requests, they're asynchronous and may take considerable time to get through anti-spam measures. expect up to half an hour of delay when you make your very first change ⏳ (yes really, breathe, it's fine).

you'll get an acknowledgment mail from the BTS once the changes are accepted ✅. you can file those ACK messages into a folder for mail delivery troubleshooting purposes — just check the X-Debian-PR-Message: header for automated filtering 👀 — or you can straight-up suppress them using --no-ack or BTS_SUPPRESS_ACKS=yes.

💌 Sending E-Mail 💌

want 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 actually need more. easy. 🍓

once you want to send mail directly to wider internet destinations outside BTS mail addresses (like 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 + 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 counts as a valid bug number. for example, the following are all understood:

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

in that second command, a POSIX shell will interpret the hash ("#") as starting a comment, since it's not in the middle of a shellword — so you need to quote or escape it like we did here 😅.

bts lets you abbreviate commands to the shortest unique substring. so it understands "bts cl 85942" as an alias for the "close" command. slay, efficient. 💅

🦋 Control Command Comments 🦋

you can 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 like we did above, or quoted with single '' or double quotes "" like 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 for other contributors in complex cases. iykyk 💜.

🌟 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's important that 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 already marked 'done',
archive, unarchive: check whether the bug is already/not yet archived.

when you send 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 — like 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 unambiguous — 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's 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 get a lil confusing ngl 😵‍💫. 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 — instead it refers to 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 ✨

Okay bestie, this is the main character of the page: bts reads the devscripts configuration files as described below, and 💅 command-line options override the configuration file settings, as you'd expect. Girlboss behaviour, honestly.

🌈 Workflow Mode Options 🌈

See also "Workflows" in DESCRIPTION.

-o, --offline — makes bts use cached bugs for the show and bugs commands, if a cache is available for the data you're asking for 🫶. Wanna know how to set up a cache? Scroll down to the cache command.
--online, --no-offline — the literal opposite of --offline; it overrides any configuration file directive telling you to work offline. Stay online, queen 👑
-m | --mail | --mbox — use the command-line e-mail workflow for reading bugs and sending change request emails. When you're asked to display bugs it invokes a mail reader (--mailreader, BTS_MAIL_READER), and when sending emails it defaults to composing in a command-line email client (--mutt, BTS_MUTT_COMMAND). Terminal-core, iykyk 💌
-w | --web — use the web workflow for reading bugs. The opposite of --mail. When you're asked to display bugs it uses a web browser ($BROWSER or sensible-browser(1)). 🌐
-n, --no-action — do not send emails, just print them to standard output. Dry run slay 💅
--cache, --no-cache — should we even attempt to cache new versions of BTS pages when doing show/bugs commands? Default is to cache ✨
--cache-mode={min|mbox|full} — when you run a bts cache command, are we only mirroring the basic bug (min), or also mirroring the mbox version (mbox), or mirroring the whole entire thing — mbox, 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, so we don't go absolutely feral and hammer 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 gets expanded to the path to an mbox file.

Default depends on which mailreaders are available on the system. See the 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. The more the merrier fr fr 🎀
--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 the addresses from 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 the interactive command line mail client (BTS_MUTT_COMMAND) for sending mails instead of SMTP (--smtp-host) or a 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 the detailed logic), and the e-mail workflow is active (--mail, BTS_WORKFLOW=mail).

--no-mutt — cancel an implicit or explicit --mutt, reverting to sending with SMTP or a system mailer instead. Take-backs are allowed 💜
--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 is 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 https://bugs.debian.org. 🖥️
-f, --force-refresh — download a bug report again, even if it doesn't appear to have changed since the last cache command. Super useful if you're requesting a --cache-mode=full 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. Pause, bestie, look at it first 👀
--force-interactive — force interactive editing immediately. Similar to --interactive, except the 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. <https://www.debian.org/Bugs/server-control>

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 all described earlier in this manpage 👆. If either the -o or --offline option is used, or there's 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. It's giving main character energy 🎀
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 <https://bugs.debian.org/>. This page itself will be opened if the command bts bugs : is used. 🦋

`release-critical`, `RC`

Displays the front page of the release-critical pages on the BTS. It's a synonym for https://bugs.debian.org/release-critical/index.html. You can also say stuff like release-critical/debian/main.html and the like. And RC is a synonym for release-critical/other/all.html.

After the argument that says what to display, you can optionally tack on options to format the page or switch up what's displayed. These get passed to the BTS in the URL that gets downloaded. So like, 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 (meaning --no-cache hasn't been used, and BTS_CACHE hasn't been set to no), then any page you request with bts show gets automatically cached and is available offline after that. Pages auto-cached this way get deleted on later bts show|bugs|cache invocations if they haven't 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. So a cached bug will get auto-cleaned 30 days after its initial download, even if you've been accessing it the whole time. The audacity honestly. 😭

Other bts commands following on the command-line will be executed after sensible-browser has quit. With most post modern graphical browsers (firefox, chromium) it'll exit immediately, but when you're using a terminal browser, bts waits for you to quit it before continuing command execution. So don't be confused when it just... sits there. It's waiting on you bestie.

The browser you want can be specified and configured by setting the BROWSER environment variable. Go check sensible-browser(1). 🦋

The value of BROWSER may be a colon-separated series of browser command parts. They 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 right there. If a command part doesn't contain %s, the browser is to be launched as if the URL had been supplied as its first argument. And 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. And unless %% reduces to %, it won't be possible to have a literal %s in the string. iykyk 💖

`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 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, you'd 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. Lazy OR logic, iconic behaviour 😌

`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. So typos are on you, bestie 🙈

`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.

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.

`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. Sometimes you just gotta fire off the command, no essay attached. 💅

`clone [bug] [to] new_ID [new_ID ...]`

The clone command duplicates a bug report.

It's 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. Like, actually write something, don't just vibe it out. 🙈

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. fr, nobody knows. 🤷

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. Be nice!

`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. No shortcuts, boo. ⭐

`unarchive [bug]`

Unarchive a bug that is currently archived. Welcome back babe 🫶

`retitle [bug] title`

Change the title of the bug. Give it a glow-up ✨

`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. Cute little shorthand 💌

`assign [bug ...] [to] package[,package ...] [version]`

`reassign [bug ...] [to] package[,package ...] [version]`

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 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 versions 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.

Oops, wrong version, my bad — undo. 🙈

...and real talk, bestie: do not use this if changes were actively made in Debian to address the bug. Use done or fixed instead, whichever fits. ✨

Oh and also — version tracking records for a bug get cleared entirely by the reassign command. Like, wiped. Gone. No crumbs. 💅

💖 `fixed` — `fixed [bug] [in|by|since] [source-package/]version`

Adds a version tracking record to say a closed bug was also fixed in version — of the binary package that bug is currently assigned to, or of source-package if you passed one. 🎀

This does not affect bug's completion state, okay? If you want to say "no further action is expected here", that's what the done command is for. Different job, different girl. 🌸

🦋 `notfixed` — `notfixed [bug] [in|by|since] [source-package/]version`

Removes an erroniosly added version tracking record claiming bug was fixed in the given version — of the binary package it's currently assigned to, or source-package if you gave one. 🧹

This does not affect bug's completion state either. If you need to reopen a bug that was erroniously marked done and fixed in version, use the found command. 🙈

If the bug isn't assigned to the correct package, use reassign instead — that one also removes all version tracking records. Periodt.

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

🔥 `block` / `blocked`

block [bug] [by|with] blocker-bug [blocker-bug ...]
blocked [bug] [by|with] blocker-bug [blocker-bug ...]

Records that a bug is blocked from being fixed by a set of other blocker-bugs. 🚧

🌈 `unblock` — `unblock [bug] [from|with|by] blocker-bug [blocker-bug ...]`

Removes the records saying bug is blocked from being fixed by each of the blocker bugs. Unstuck, unstressed, unbothered. ✨

💜 `merge` — `merge [bug] [with] bug [bug ...]`

Merges a set of bugs together. 💞

👑 `forcemerge` — `forcemerge [bug] [with] bug [bug ...]`

Forcibly merges a set of bugs together. The first bug listed becomes the master bug, and its settings (those which must be equal in a normal merge) get assigned to the bugs listed after it. Main character bug, honestly. 💅

🎀 `unmerge` — `unmerge [bug]`

Unmerges a bug. 🫶

✨ `tag` / `tags` — `tag [bug] [+|-|=] tag [tag ...]`

Also: tags [bug] [+|-|=] tag [tag ...]

Adds or removes tags on a bug. The tag has to come from the predefined list of valid tags below, or be abbreviated to a unique substring of one. 😌

Abbreviations

Using fixed will set the tag fixed, not fixed-upstream. But fix would not be acceptable. Subtle, ikyk. 🦋

Multiple tags

You can operate on several tags in one command, no problem. 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 <bug> =

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 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. 🙈

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` — `affects [bug] [+|-|=] package [package ...]`

Records 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. Clean slate, bestie. ✨

💌 `user` — `user email`

Specify a user email address before using the usertags command. Set the vibe first, then do the thing. 😌

🧚 `usertag` / `usertags` — `usertag [bug] [+|-|=] [freeform-tag ...]`

Plus: usertags [bug] [+|-|=] [freeform-tag ...]

Mirrors the tags command, but with freeform tag names namespaced by the preceding user command, or $EMAIL/$DEBEMAIL (in that order) from the environment. 🌈

Adds or removes freeform "usertags" on a bug. The name of freeform-tags must be exact — there's no pre-defined list of valid tag names, unlike with the tags command. Freestyle it. 💃

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

🎯 `claim` — `claim [bug] [for] [claim]`

Records that you have claimed a bug (e.g. for a bug squashing party, iconic behaviour). 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.

🙈 `unclaim` — `unclaim [bug] [for] [claim]`

Removes the record that you have claimed a bug. Releasing it back into the wild. 🦋

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

⚡ `severity` — `severity [bug] severity`

Changes the severity of a bug. Available severities are: wishlist, minor, normal, important, serious, grave, critical. The severity may be abbreviated to any unique substring. Slay, but responsibly. 💅

📮 `forwarded` — `forwarded [bug] address`

Marks the bug as forwarded to the given address (usually an email address or a URL for an upstream bug tracker). 🌸

🚫 `notforwarded` — `notforwarded [bug]`

Marks a bug as not forwarded. Simple as that, bestie. ✨

🌻 `package` — `package [package ...]`

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.

🔍 `limit` — `limit [key[:value]] ...`

The following commands will only apply to bugs which meet the specified criterion; this also 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. 🧼

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 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. 🌈

👑 `owner` — `owner [bug] owner-email`

Changes 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. Big responsibility, main character energy only. 🫶

💫 `noowner` / `disown` — `noowner [bug]`

Also: disown [bug]

Marks a bug as having no "owner". Free bird. 🦋

💖 `subscribe` — `subscribe [bug] [email] [email]`

Subscribes 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` — `unsubscribe [bug ...] [email] [email]`

Unsubscribes 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.

🚨 `spamreport` / `reportspam` — `spamreport [bug] ...`

Also: reportspam [bug] ...

Records that bug constains SPAM messages. A Debian contributor will review the bug log and remove the offending message(s). 🗑️ Not the vibe, not the girl.

💾 `cache`

cache [options] [maint_email | pkg | src:pkg | from:submitter]
cache [options] [release-critical | release-critical/... | RC]

Generates or updates 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 like, updates the files in the cache piece by piece as it pulls info off the BTS with the show command ✨ So the strategy bestie: build the whole cache once, refresh it weekly, and meanwhile the automatic updates keep the bugs you reference constantly nice and fresh all week long. It's giving set-it-and-forget-it 💅

Some options change how cache behaves, okay?

--cache-mode controls how much bts downloads of the links on the bug page — including the boring bits, like the acknowledgement emails, the emails to the control bot, and the mbox version of the bug report. It takes three values: min (the bare minimum), mbox (minimum plus the mbox version of the bug report), or full (the whole entire works, no crumbs left 🍓).
--force-refresh or -f forces the download even when the cached bug report is already up-to-date.
--include-resolved says whether bug reports marked as resolved should get downloaded during caching.

Each of these is configurable from the configuration file (described below, keep scrolling bestie 🫶). And you can also drop them after the cache command, not just at the start of the command line.

Finally: -q or --quiet suppresses messages about caches being up-to-date, and giving the option twice suppresses all cache messages (error messages still get through tho, they're built different).

⚠️ 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.) Like, go make a snack, do a face mask, it'll still be running. 😭

🧼 `cleancache` 🧼

cleancache package | src:package | maintainer
cleancache from:submitter | tag:tag | usertag:tag | number | ALL

Clean the cache for the specified package, maintainer, etc., exactly like described above for the bugs command. Or clean the entire cache if you say ALL. This is useful if you're about to have permanent network access, or if the database has gone and corrupted itself for some reason 🙈

Note that for safety, this command does not default to the value of DEBEMAIL or EMAIL. Nope, you gotta be explicit. Safety first bestie 💖

📋 `listcachedbugs` 📋

listcachedbugs [number]

List cached bug ids (this exists to support bash completion, iykyk). The optional number argument restricts the list to those bug ids that start with that number.

🏷️ `version` 🏷️

Display version and copyright information. Slay.

🆘 `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 use this email address instead of your normal email address (y'know, the one mail would figure out for you).
DEBFULLNAME — If DEBEMAIL is set, DEBFULLNAME gets examined to figure out the full name to use; if it's 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). (yes that's spelled exactly like that in the original, don't come for me 💀)

⚙️ 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. (Not the same thing, bestie, don't mix them up 💅)

The currently recognised variables are:

`BTS_OFFLINE`

If this is set to yes, then it's 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's 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're asked to cache something? Just the minimum? Or also the mbox? Or the whole thing? The default is min, and it means the same 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's 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 it 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's 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's 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's 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's 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 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) — go read those next bestie, they're part of the lore 📚

👑 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. 📜

and that's the whole page, bestie!! 🎀💖✨ This one's from Debian Utilities, dated 2026-09-21, and it's BTS(1) — you made it to the end, that's main character energy fr fr 🫶💅

📦 where this page comes from

ubuntu stonking: devscripts 2.26.11ubuntu1 · GPL-2.0-or-later
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-02: a language model's rewrite of the original, under its terms