Translations by Dino Hurem

An error occured, like I<dscfile> was not found.

See the above section "Directory name checking" for an explanation of this option.

DEVSCRIPTS_CHECK_DIRNAME_LEVEL can take the following values:

B<-spgp>, B<-sgpg>

Controls the timestamp format, as per B<date>(1). Defaults to "%H:%M:%S".

$ annotate-output make 21:41:21 I: Started make 21:41:21 O: gcc -Wall program.c 21:43:18 E: program.c: Couldn't compile, and took me ages to find out 21:43:19 E: collect2: ld returned 1 exit status 21:43:19 E: make: *** [all] Error 1 21:43:19 I: Finished with exitcode 2

Since stdout and stderr are processed in parallel, it can happen that some lines received on stdout will show up before later-printed stderr lines (and vice-versa).

This is unfortunately very hard to fix with the current annotation strategy. A fix would involve switching to PTRACE'ing the process. Giving nice a (much) higher priority over the executed program could however cause this behaviour to show up less frequently.

The program does not work as well when the output is not linewise. In particular, when an interactive program asks for input, the question might not be shown until after you have answered it. This will give the impression that the annotated program has hung, while it has not.

This program is community-supported (meaning: you'll need to fix it yourself). Patches are however appreciated, as is any feedback (positive or negative).

B<annotate-output> was written by Jeroen van Wolffelaar E<lt>jeroen@wolffelaar.nlE<gt> This manpage comes under the same copyright as annotate-output itself, read /usr/bin/annotate-output (or wherever you install it) for the details.

archpath - output arch (tla/Bazaar) archive names, with support for branches

B<archpath> is intended to be run in an arch (tla or Bazaar) working copy.

In its simplest usage, B<archpath> with no parameters outputs the package name (archive/category--branch--version) associated with the working copy.

If a parameter is given, it may either be a branch--version, in which case B<archpath> will output a corresponding package name in the current archive and category, or a plain branch name (without \(oq--"), in which case B<archpath> will output a corresponding package name in the current archive and category and with the same version as the current working copy.

This is useful for branching. For example, if you're using Bazaar and you want to create a branch for a new feature, you might use a command like this:

Or if you want to tag your current code onto a \(oqreleases\(cq branch as version 1.0, you might use a command like this:

That's much easier than using \(oqbaz tree-version\(cq to look up the package name and manually modifying the result.

Like B<archpath>, this manual page is released under the GNU General Public License, version 2 or later.

bts - developers' command line interface to the BTS

This is a command line interface to the Debian Bug Tracking System (BTS), intended mainly for use by developers. It lets the BTS be manipulated using simple commands that can be run at the prompt or in a script, does various sanity checks on the input, and constructs and sends a mail to the BTS control address for you. A local cache of web pages and e-mails from the BTS may also be created and updated.

In general, the command line interface is the same as what you would write in a mail to control@bugs.debian.org, just prefixed with "bts". For example:

% bts severity 69042 normal % bts merge 69042 43233 % bts retitle 69042 blah blah

A few additional commands have been added for your convenience, and this program is less strict about what constitutes a valid bug number. For example, "severity Bug#85942 normal" is understood, as is "severity #85942 normal". (Of course, your shell may regard "#" as a comment character though, so you may need to quote it!)

Also, for your convenience, this program allows you to abbreviate commands to the shortest unique substring (similar to how cvs lets you abbreviate commands). So it understands things like "bts cl 85942".

It is also possible to include a comment in the mail sent to the BTS. If your shell does not strip out the comment in a command like "bts severity 30321 normal #inflated severity", then this program is smart enough to figure out where the comment is, and include it in the email. Note that most shells do strip out such comments before they get to the program, unless the comment is quoted. (Something like "bts severity #85942 normal" will not be treated as a comment!)

You can specify multiple commands by separating them with a single dot, rather like B<update-rc.d>; a single comma may also be used; all the commands will then be sent in a single mail. It is important the dot/comma is surrounded by whitespace so it is not mistaken for part of a command. For example (quoting where necessary so that B<bts> sees the comment):

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

The abbreviation "it" may be used to refer to the last mentioned bug number, so you could write:

% bts severity 95672 wishlist , retitle it "bts: please add a --foo option"

Please use this program responsibly, and do take our users into consideration.

B<bts> examines the B<devscripts> configuration files as described below. Command line options override the configuration file settings, though.

Make B<bts> use cached bugs for the B<show> and B<bugs> commands, if a cache is available for the requested data. See the B<cache> command, below for information on setting up a cache.

Opposite of B<--offline>; overrides any configuration file directive to work offline.

Should we attempt to cache new versions of BTS pages when performing B<show>/B<bugs> commands? Default is to cache.

When running a B<bts cache> command, should we only mirror the basic bug (B<min>), or should we also mirror the mbox version (B<mbox>), or should we mirror the whole thing, including the mbox and the boring attachments to the BTS bug pages and the acknowledgement emails (B<full>)? Default is B<min>.

Time in seconds to delay between each download, to avoid hammering the BTS web server. Default is 5 seconds.

Open a mail reader to read the mbox corresponding to a given bug number for B<show> and B<bugs> commands.

Specify the command to read the mbox. Must contain a "B<%s>" string (unquoted!), which will be replaced by the name of the mbox file. The command will be split on white space and will not be passed to a shell. Default is 'B<mutt -f %s>'. (Also, B<%%> will be substituted by a single B<%> if this is needed.)

Send carbon copies to a list of users. I<CC_EMAIL_ADDRESS> should be a comma-separated list of emails.

Add the addresses specified in the configuration file option B<BTS_DEFAULT_CC> to the list specified using B<--cc-addr>. This is the default.

Do not add addresses specified in B<BTS_DEFAULT_CC> to the carbon copy list.

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

Use B<mutt> for sending of mails. Default is not to use B<mutt>, except for some commands.

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

Don't use B<mutt> for sending of mails.

Specify an SMTP host. If given, B<bts> will send mail by talking directly to this SMTP host rather than by invoking a B<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.

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