Ubuntu Manpage: bts - Befehlszeilenschnittstelle der Entwickler zum BTS

Provided by: devscripts_2.16.2ubuntu3_amd64

BEZEICHNUNG

       bts - Befehlszeilenschnittstelle der Entwickler zum BTS

ÜBERSICHT

       bts [Optionen] Befehl [Argumente] [#Kommentar] [.|, Befehl [Argumente] [#Kommentar]] …

BESCHREIBUNG

       Dies ist eine Befehlszeilenschnittstelle zur Debian-Fehlerdatenbank (BTS), die
       hauptsächlich für den Gebrauch durch Entwickler gedacht ist. Sie ermöglicht die
       Manipulation des BTS durch einfache Befehle, die an der Eingabeaufforderung oder in einem
       Skript ausgeführt werden können, führt verschiedene Plausibilitätsprüfungen der Eingabe
       durch und konstruiert und sendet E-Mails für Sie an die BTS-Steueradresse. Außerdem kann
       ein lokaler Zwischenspeicher von Webseiten und E-Mails vom BTS erzeugt und aktualisiert
       werden.

       Im Allgemeinen ist die Befehlszeilenschnittstelle das, was Sie in einer Mail an
       control@bugs.debian.org schreiben würden, nur mit vorangestelltem »bts«. Zum Beispiel:

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

       Für Ihren Komfort wurden ein paar zusätzliche Befehle hinzugefügt und dieses Programm ist
       ist weniger strikt in dem, was eine gültige Fehlernummer darstellt. Beispielsweise wird
       »severity Bug#85942 normal« wie auch »severity #85942 normal« verstanden. (Allerdings
       könnte Ihre Shell »#« als Kommentarzeichen ansehen, weswegen Sie es maskieren müssen!)

       Außerdem ermöglicht Ihnen dieses Programm zu Ihrer Annehmlichkeit Befehle auf die kleinste
       eindeutige Teilzeichenkette abzukürzen (ähnlich wie Sie CVS Befehle abkürzen lässt). So
       versteht es Dinge wie »bts cl 85942«.

       Es ist ebenfalls möglich, der E-Mail an das BTS einen Kommentar beizufügen. Falls Ihre
       Shell nicht den Kommentar in einem Befehl wie »bts severity 30321 normal #inflated
       severity« streicht, dann ist dieses Programm schlau genug herauszufinden, wo der Kommentar
       ist und ihn in die E-Mail einzufügen. Beachten Sie, dass die meisten Shells solche
       Kommentare streichen, bevor sie beim Programm ankommen, es sei denn, der Kommentar ist
       maskiert. (Etwas wie »bts severity #85942 normal« wird nicht als Kommentar angesehen!)

       Sie können mehrere Befehle angeben, indem Sie sie durch einen einzelnen Punkt trennen,
       ungefähr wie update-rc.d; ein einzelnes Komma könnte auch benutzt werden; alle die Befehle
       werden in einer einzigen E-Mail gesandt. Es ist wichtig, dass der Punkt/das Komma von
       Leerzeichen umgeben ist, damit es nicht als Teil des Befehls missverstanden wird. Zum
       Beispiel (wo nötig maskieren, so dass bts den Kommentar sieht):

        % bts severity 95672 normal , merge 95672 95673 \#sie sind identisch!

       Die Abkürzung »it« könnte benutzt werden, um auf die zuletzt erwähnte Fehlernummer Bezug
       zu nehmen, daher können Sie schreiben:

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

       Bitte benutzen Sie dieses Programm verantwortungsvoll und berücksichtigen Sie unsere
       Anwender.

OPTIONEN

bts durchsucht die devscripts-Konfigurationsdateien wie oben beschrieben.
Befehlszeilenoptionen setzen jedoch die Einstellungen der Konfigurationsdatei außer Kr.

-o, --offline
sorgt dafür, dass bts zwischengespeicherte Fehler für die Befehle show und bugs
benutzt, falls für die angeforderten Daten ein Zwischenspeicher verfügbar ist. Im
Nachstehenden finden Sie Informationen zum Befehl cache, wie Sie einen
Zwischenspeicher einrichten.

--online, --no-offline
Gegenteil von --offline; setzt alle Konfigurationsdatei-Direktiven außer Kraft, um
offline zu arbeiten

-n, --no-action
sendet keine E-Mails, gibt sie aber auf der Standardausgabe aus.

--cache, --no-cache
Soll versucht werden, neue Versionen der BTS-Seiten bei der Ausführung der Befehle
show/bugs zwischenzuspeichern? Vorgabe ist Zwischenspeicherung.

--cache-mode={min|mbox|full}
Soll nur der reine Fehler (min) oder auch die Mbox-Version (mbox) wiedergegeben werden
oder soll das ganze Ding, einschließlich der Mbox, den langweiligen Anhängen an die
BTS-Fehlerseiten und die Bestätigungs-E-Mails (full) wiedergegeben werden, wenn ein
bts cache-Befehl ausgeführt wird? Vorgabe ist min.

--cache-delay=Sekunden
Zeit in Sekunden, die zwischen jedem Herunterladen gewartet wird, um zu verhindern,
dass auf den BTS-Webserver eingehämmert wird. Vorgabe ist fünf Sekunden.

--mbox
öffnet ein E-Mail-Programm, um die Mbox zu lesen, die zu einer gegebenen Fehlernummer
für show- und bugs-Befehle gehört.

--mailreader=E-MAIL-PROGRAMM
gibt den Befehl zum Lesen der Mbox an; muss eine »%s«-Zeichenkette (ohne
Anführungszeichen) enthalten, die durch den Namen der Mbox-Datei ersetzt wird. Der
Befehl wird bei Leerzeichen getrennt und nicht an eine Shell übergeben. Vorgabe ist
»mutt -f %s«. (Außerdem wird %% durch ein einzelnes % ersetzt, falls dies nötig ist.)

--cc-addr=CC_E-MAIL_ADRESSE
sendet Kopien an eine Liste von Anwendern. CC_E-MAIL_ADRESSE sollte eine durch Kommas
getrennte Liste von E-Mail-Adressen sein.

--use-default-cc
fügt die in der Konfigurationsdateioption BTS_DEFAULT_CC angegebenen Adressen der
Liste hinzu, die mittels --cc-addr angegeben wurde. Dies ist die Vorgabe.

--no-use-default-cc
fügt der Liste der Kopien keine in BTS_DEFAULT_CC angegebenen Adressen hinzu.

--sendmail=SENDMAIL-BEFEHL
gibt den sendmail-Befehl an. Der Befehl wird bei Leerzeichen getrennt und nicht an
eine Shell übergeben. Vorgabe ist /usr/sbin/sendmail. Die Option -t wird automatisch
hinzugefügt, falls der Befehl /usr/sbin/sendmail oder /usr/sbin/exim* lautet. Für
andere E-Mail-Programme muss dies, falls sie eine -t-Option benötigen, in den
SENDMAIL-BEFEHL eingefügt werden, zum Beispiel: --sendmail="/usr/sbin/mymailer -t".

--mutt
benutzt mutt für den Versand von E-Mails. Standardmäßig wird mutt nicht benutzt, außer
für einige Befehle.

Beachten Sie, dass $DEBEMAIL oder $EMAIL in der Umgebung gesetzt sein müssen, um mutt
zum Senden von E-Mails zu verwenden.

--no-mutt
benutzt mutt nicht für den Versand von E-Mails.

--soap-timeout=SECONDS
Specify a timeout for SOAP calls as used by the select and status commands.

--smtp-host=SMTPHOST
gibt einen SMTP-Rechner an. Falls angegeben wird bts E-Mails versenden, indem es
direkt mit diesem Rechner kommuniziert, statt den sendmail-Befehl aufzurufen.

Dem Rechnername könnte ein Doppelpunkt (»:«) und eine Port-Nummer folgen, um einen
anderen Port als den vorgegebenen zu benutzen, Er könnte außerdem mit »ssmtp://« oder
»ssmtps://« beginnen, um anzuzeigen, dass SMTPS benutzt werden soll.

Beachten Sie, dass $DEBEMAIL oder $EMAIL in der Umgebung gesetzt sein müssen, um
direkte SMTP-Verbindungen zum Senden von E-Mails zu verwenden.

Beachten Sie, wenn Sie direkt über einen SMTP-Rechner senden, dass die Angabe von
Adressen in --cc-addr oder BTS_DEFAULT_CC, für die der SMTP-Rechner keine
Weiterleitung durchführt, dazu führt, dass der SMTP-Rechner die ganze E-Mail abweist.

Beachten Sie außerdem, dass die Benutzung des Befehls reassign, wenn entweder der
Modus --interactive oder --force-interactive aktiviert ist, dazu führen kann, dass ein
Cc an $newpackage@packages.debian.org hinzugefügt wird. In diesen Fällen findet der
Hinweis oben bezüglich Weiterleitung Anwendung. Die Übertragungsschnittstelle (Port
587) auf reportbug.debian.org unterstützt keine Weiterleitung und sollte als solche
nicht als SMTP-Server für bts unter den in diesem Absatz beschriebenen Umständen
genutzt werden.

--smtp-username=BENUTZERNAME, --smtp-password=PASSWORT
gibt die Anmeldedaten an, die benutzt werden, wenn eine Verbindung zu dem durch
--smtp-host angegebenen SMTP-Server hergestellt wird. Falls der Server keine
Authentifizierung verlangt, dann sollten diese Optionen nicht verwendet werden.

Falls ein Benutzername aber kein Passwort angegeben wurde, wird bts vor dem Senden der
E-Mail nach dem Passwort fragen.

--smtp-helo=HELO
gibt den Namen an, der im Befehl HELO benutzt wird, wenn eine Verbindung zu dem SMTP-
Server hergestellt wird; Vorgabe ist der Inhalt der Datei /etc/mailname, falls sie
existiert.

Beachten Sie, dass einige STMP-Server die Benutzung eines HELO möglicherweise
abweisen, die sie entweder nicht auflösen oder die nicht zum benutzenden Rechner
gehören.

--bts-server
Use a debbugs server other than https://bugs.debian.org.

-f, --force-refresh
lädt einen Fehlerbericht erneut herunter, sogar dann, wenn er sich seit dem letzten
cache-Befehl nicht geändert zu haben scheint; nützlich, falls ein --cache-mode=full
zum ersten Mal angefragt wurde (andernfalls werden unveränderte Fehlerberichte nicht
erneut heruntergeladen, nicht einmal, wenn die langweiligen Teile nicht
heruntergeladen wurden.

--no-force-refresh
unterdrückt jegliche --force-refresh-Konfigurationsdateioptionen.

--only-new
lädt nur neue Fehler beim Zwischenspeichern herunter; prüft nicht, ob es in bereits
vorhandenen Fehlern Aktualisierungen gibt.

--include-resolved
wenn Fehlerberichte zwischengespeichert werden, die einbeziehen, die als gelöst
markiert sind. Dies ist das Standardverhalten.

--no-include-resolved
kehrt das Verhalten der vorherigen Option um. Sprich, Fehler, die als gelöst markiert
sind, werden nicht zwischengespeichert.

--no-ack
unterdrückt Bestätigungs-E-Mails vom BTS. Beachten Sie, dass dies nur die CC-Kopien
der Nachrichten beeinflusst, die Kopien für Fehler sind, die nicht an das
Steuerungsprogramm gesandt wurden.

--ack
unterdrückt keine Bestätigungs-E-Mails. Dies ist das Standardverhalten.

-i, --interactive
zeigt vor dem Senden einer E-Mail an das Steuerungsprogramm den Inhalt an und
ermöglicht, ihn zu bearbeiten oder das Versenden abzubrechen.

--force-interactive
ähnlich wie --interactive, mit der Ausnahme, dass sich ein Editor öffnet bevor nach
der Bestätigung gefragt wird, ob die Nachricht versandt werden soll.

--no-interactive
sendet Steuerungs-E-Mails ohne Bestätigung. Dies ist das Standardverhalten.

-q, --quiet
zeigt, wenn bts cache ausgeführt wird, nur Informationen über neu zwischengespeicherte
Seiten an, keine Nachrichten, die aussagen, was bereits zwischengespeichert ist. Falls
diese Option zweimal angegeben wurde, werden nur Fehlermeldungen (an die
Standardfehlerausgabe) ausgegeben.

--no-conf, --noconf
keine Konfigurationsdateien lesen, Dies kann nur als erste auf der Befehlszeile
angegebene Option benutzt werden.

BEFEHLE

Sämtliche Einzelheiten über die Befehle finden Sie in der BTS-Dokumentation.
<https://www.debian.org/Bugs/server-control>

bugs [Optionen] [Fehlernummer | Paket | Paketbetreuer | : ] [Opt=Wert …]
bugs [Optionen] [src:Paket | from:Absender] [Opt=Wert …]
bugs [Optionen] [tag:Markierung | usertag:Markierung ] [Opt=Wert …]
bugs [release-critical | release-critical/ … | RC]
zeigt die Seite, die die angefragten Fehler in einem Webbrowser auflistet, unter
Benutzung von sensible-browser(1).

Optionen könnten nach dem Befehl bugs zusätzlich oder anstelle von Optionen am Anfang
der Befehlszeile angegeben werden: An diesem Punkt erkannte Optionen sind:
-o/--offline/--online, -m/--mbox, --mailreader und --[no-]cache. Diese wurden an
früherer Stelle in dieser Handbuchseite beschrieben. Falls Sie entweder die Option -o
oder --offline benutzt haben oder es bereits eine aktuelle Kopie des lokalen
Zwischenspeichers gibt, wird die zwischengespeicherte Version benutzt.

Die möglichen Argumente haben folgende Bedeutung:

(keins) Falls keins angegeben wurde, wird bts bugs Ihre Fehler unter der Annahme
anzeigen, dass entweder DEBEMAIL oder EMAIL (in dieser Reihenfolge geprüft)
auf die geeignete E-Mail-Adresse gesetzt ist.

Fehlernummer
zeigt Fehler Nummer Fehlernummer.

Paket zeigt die Fehler des Pakets Paket.

src:Paket
zeigt die Fehler des Quellpakets Paket.

Paketbetreuer
zeigt die Fehler für die Paketbetreuer-E-Mail-Adresse Paketbetreuer

from:Absender
zeigt die Fehler für die Absender-E-Mail-Adresse Absender

tag:Markierung
zeigt die Fehler, die mit Markierung gekennzeichnet sind.

usertag:Markierung
zeigt die Fehler, die mit der Benutzermarkierung Markierung gekennzeichnet
sind. Weitere Informationen über Benutzermarkierungen finden Sie in der BTS-
Dokumentation. Dies wird die Verwendung der Option users=E-Mail erfordern.

: Einzelheiten der Fehlerdatenbank selbst können, neben einer Fehlermeldeseite
mit mehr Optionen als diesem Skript, unter https://bugs.debian.org/ gefunden
werden. Diese Seite selbst wird geöffnet, falls der Befehl »bts bugs :«
benutzt wird.

release-critical, RC
zeigt die Einstiegssseite der release-kritischen Seiten des BTS. Dies ist ein
Synonym für https://bugs.debian.org/release-critical/index.html. Es ist
außerdem möglich, release-critical/debian/main.html und dergleichen zu sagen.
RC ist ein Synonym für release-critical/other/all.html.

Nach dem Argument, das spezifiziert, was angezeigt wird, können Sie wahlweise Optionen
angeben, um die Seite zu formatieren oder um zu ändern, was angezeigt wird. Diese
werden in der heruntergeladenen URL an das BTS übergeben. Übergeben Sie zum Beispiel
»dist=stable«, um Fehler zu sehen, die die stabile Version des Pakets beeinflussen,
»version=1.0«, um Fehler zu sehen, die diese Version des Pakets beeinflussen oder
»reverse=yes«, um die neusten Nachrichten im Fehlerprotokoll zuerst zu sehen.

Falls Zwischenspeicherung aktiviert wurde (sprich --no-cache wurde nicht benutzt und
BTS_CACHE wurde nicht auf no gesetzt), dann wird automatisch jede durch bts show
angeforderte Seite zwischengespeichert und danach offline verfügbar sein. Seiten, die
automatisch auf diese Weise zwischengespeichert wurden, werden bei nachfolgenden
Aufrufen von »bts show|bugs|cache« gelöscht, falls nicht innerhalb von 30 Tagen darauf
zugegriffen wurde. Warnung: Auf einem Dateisystem, das mit der Option »noatime«
eingehängt wurde, aktualisiert die Ausführung von »bts show|bugs« nicht die
Zugriffszeiten der Zwischenspeicherdateien; ein zwischengespeicherter Fehler wird dann
Gegenstand der automatischen Bereinigung 30 Tage nach seinem anfänglichen
Herunterladen, sogar dann, wenn auf ihn in der Zwischenzeit zugegriffen wurde.

Alle anderen bts-Befehle, die dieser Befehlszeile folgen, werden nach dem Beenden des
Browsers ausgeführt.

Der gewünschte Browser kann durch Setzen der Umgebungsvariable BROWSER angegeben und
konfiguriert werden. Die Konventionen folgen denen, die Eric Raymond auf
http://www.catb.org/~esr/BROWSER/ definiert hat; hier wird der maßgebliche Teil
wiedergegeben.

Der Wert von BROWSER kann aus einer Reihe von durch Doppelpunkt getrennten Browser-
Befehlsteilen bestehen. Diese sollten nacheinander durchprobiert werden, bis einer
erfolgreich ist. Jeder Befehlsteil kann optional die Zeichenkette %s enthalten; ist
dies der Fall, wird die URL, die betrachtet werden soll, dort ersetzt. Falls der
Befehlsteil kein %s enthält, wird der Browser gestartet, als ob die URL als sein
erstes Argument bereitgestellt worden wäre. Die Zeichenkette %% muss durch ein
einzelnes % ersetzt werden.

Begründung: Es muss möglich sein, mehrere Browser-Befehle anzugeben, damit Programme,
die dieser Konvention folgen, in X- oder Konsolenumgebungen das Richtige tun können.
Dabei wird X zuerst probiert. Die Angabe mehrerer Befehle kann außerdem für Leute
nützlich sein, die Dateien wie .profile über mehrere Systeme hinweg gemeinsam
benutzen. %s wird benötigt, da einige populäre Browser eine Aufrufsyntax aus der Ferne
haben, die dies erfordern. Falls %% nicht auf % verkürzt würde, wäre es unmöglich, ein
Buchstabensymbol %s in der Zeichenkette zu haben.

Auf den meisten Linux-Systemen wäre zum Beispiel Folgendes ein gute Sache:

BROWSER='mozilla -raise -remote "openURL(%s,new-window)":links'

select [Schlüssel:Wert …]
benutzt die SOAP-Schnittstelle, um eine Liste von Fehlern auszugeben, die zu den
gegebenen Auswahlanforderungen passen.

Die folgenden Schlüssel sind erlaubt und können mehrmals abgegeben werden.

package Name des Binärpakets

source Name des Quellpakets

maintainer
E-Mail-Adresse des Paketbetreuers

submitter
E-Mail-Adresse des Absenders

severity
Schweregrad des Fehlers

status Status des Fehlers; entweder open, done oder forwarded

tag auf den Fehler bezogene Markierungen. Falls users angegeben ist, könnten
zusätzlich zu den Standardmarkierungen Benutzermarkierungen enthalten sein.

owner Besitzer des Fehlers

correspondent
Adresse von jemandem, der E-Mail an das Protokoll sandte

affects Fehler, die dieses Paket beeinflussen

bugs Liste von Fehlern, in der gesucht wird

users Namen von Anwendern, die beim Abfragen von Benutzermarkierungen benutzt werden

archive gibt an, ob archivierte oder normale Fehler gesucht werden; Vorgabe ist 0
(d.h. nur normale Fehler werden gesucht). Als Sonderfall werden, falls
»archive« both ist, archivierte und nicht archivierte Fehler zurückgegeben.

Um zum Beispiel die Sammlung von Fehlern auszuwählen, die von
jrandomdeveloper@example.com versandt und mit wontfix markiert würde, könnte Folgendes
benutzt werden:

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

Falls ein Schlüssel mehrfach benutzt wird, dann enthält die ausgewählte
Fehlerzusammenstellung jene, die auf einen der bereitgestellten Werte passen, zum
Beispiel gibt

bts select package:foo severity:wishlist severity:minor

alle Fehler des Pakets Foo zurück, die entweder den Schweregrad »wishlist« oder
»minor« haben.

status [Fehler | file:Datei | fields:Feld[,Feld …] | verbose] …
benutzt die SOAP-Schnittstelle, um Informationen über die angegebenen Fehler
auszugeben (oder die, die aus den aufgelisteten Dateien gelesen wurden – verwenden Sie
-, um die Standardeingabe auszuwählen).

Standardmäßig werden alle ausgefüllten Felder für einen Fehler angezeigt.

Falls verbose angegeben ist, werden außerdem leere Felder angezeigt.

Falls fields angegeben ist, werden nur diese Felder angezeigt. Es wird keine
Gültigkeitsprüfung für irgendwelche angegebenen Felder durchgeführt.

clone Fehler neue_Kennung [neue_Kennung …]
Der Steuerbefehl clone ermöglicht es Ihnen, einen Fehlerbericht zu kopieren. Das ist
in dem Fall nützlich, in dem ein einziger Bericht tatsächlich anzeigt, dass mehrere
eigenständige Fehler aufgetreten sind. »Neue Kennungen« sind durch Leerzeichen
getrennte negative Zahlen, die in nachfolgenden Steuerbefehlen benutzt werden können,
um auf die neu kopierten Fehler Bezug zu nehmen. Für jede neue Kennung wird ein neuer
Fehler erzeugt.

done Fehler [Version]
markiert einen Fehler als erledigt. Dies erzwingt einen interaktiven Modus, da
erledigt-Nachrichten eine Erklärung enthalten sollten, weshalb der Fehler geschlossen
wird. Sie sollten angeben, welche Version des Pakets den Fehler schließt, falls
möglich.

reopen Fehler [Absender]
öffnet einen Fehler mit optionalem Absender erneut.

archive Fehler
archiviert einen Fehler, der vorher archiviert war, es gegenwärtig aber nicht ist. Der
Fehler muss alle Anforderungen für die Archivierung außer den zeitbasierten erfüllen.

unarchive Fehler
nimmt einen derzeit archivierten Fehler aus dem Archiv heraus.

retitle Fehler Titel
ändert den Titel des Fehlers.

summary Fehler [Nachrichtennummer]
wählt eine Nachrichtennummer, die als Zusammenfassung von Fehler benutzt werden soll.

Falls keine Nachrichtennummer angegeben ist, wird die Zusammenfassung geleert.

submitter Fehler [Fehler] … Absender-E-Mail-Adresse
ändert die Adresse des Einreichenden eines Fehlers oder einer Reihe von Fehlern. !
bedeutet »die Adresse der aktuellen E-Mail als neue Adresse des Einreichenden
verwenden«.

reassign Fehler [Fehler …] Paket [Version]
weist einem Fehler oder einer Reihe von Fehlern einem anderen Paket zu. Das Feld
Version ist optional; lesen Sie die Erklärung auf
<https://www.debian.org/Bugs/server-control>.

found Fehler [Version]
zeigt an, dass ein Fehler in einer bestimmten Paketversion gefunden wurde. Ohne
Version wird die Liste reparierter Versionen bereinigt und der Fehler wird erneut
geöffnet.

notfound Fehler Version
entfernt den Datensatz, mit dem Fehler in der gegebenen Version des Pakets, dem er
zugewiesen ist, vorgefunden wurde.

fixed Fehler Version
zeigt an, dass ein Fehler in einer bestimmten Paketversion behoben wurde ohne den
Offen-/Geschlossenstatus des Fehlers zu beeinflussen.

notfixed Fehler Version
entfernt den Datensatz mit dem ein Fehler in der gegebenen Version des Pakets, dem er
zugewiesen ist, behoben wurde.

Dies ist gleichbedeutend mit der Abfolge der Befehle »found Fehler Version«, »notfound
Fehler Version«.

block Fehler by|with Fehler [Fehler …]
weist darauf hin, dass ein Fehler von der Behebung durch einen Satz anderer Fehler
blockiert ist.

unblock Fehler by|with Fehler [Fehler …]
weist darauf hin, dass ein Fehler nicht länger von der Behebung durch einen Satz
anderer Fehler blockiert ist.

merge Fehler Fehler [Fehler …]
fügt einen Satz Fehler zusammen.

forcemerge Fehler Fehler [Fehler …]
fügt einen Satz Fehler mit Gewalt zusammen. Der erste aufgeführte Fehler ist der
Hauptfehler und seine Einstellungen (diejenigen, die denen in einem normalen merge
entsprechen müssen) werden den nachfolgend aufgeführten Fehlern zugewiesen.

unmerge Fehler
macht das Zusammenführen eines Fehlers rückgängig.

tag Fehler [+|-|=] Markierung [Markierung …]
tags Fehler [+|-|=] Markierung [Markierung …]
setzt oder entfernt eine Markierung für einen Fehler. Die Markierung kann entweder der
exakte Markierungsname sein oder er kann auf eine eindeutige Teilzeichenkette
abgekürzt werden. (Daher wird fixed beispielsweise die Markierung fixed, nicht fixed-
upstream setzen, aber fix wäre nicht zulässig.) Mehrere Markierungen können ebenfalls
angegeben werden. Die beiden Befehle (»tag« und »tags«) sind identisch. Wenn der
Schalter = nicht benutzt wird, muss mindestens eine Markierung angegeben werden, wobei
der Befehl

bts tags <Fehler> =

alle Markierungen vom angegebenen Fehler entfernen wird.

Das Hinzufügen/Entfernen der security-Markierung wird der Cc-Liste der Steuerungs-E-
Mail »team\@security.debian.org« hinzufügen.

affects Fehler [+|-|=] Paket [Paket …]
zeigt an, dass ein Fehler ein anderes Paket betrifft, als das, gegen das er
eingereicht wurde, was dazu führt, dass der Fehler standardmäßig in der Paketliste des
anderen Pakets aufgeführt wird. Dies sollte üblicherweise benutzt werden, wo der
Fehler ernst genug ist, um mehrere Berichte von Benutzern dem falschen Paket
zuzuweisen. Es muss mindestens ein Paket angegeben werden, sogar, wenn der Schalter =
benutzt wird, wobei der Befehl

bts affects <Fehler> =

alle Hinweise entfernt, dass Fehler andere Pakete beeinflusst.

user E-Mail-Adresse
gibt eine Benutzer-E-Mail-Adresse an, bevor der Befehl usertags verwendet wird.

usertag Fehler [+|-|=] Markierung [Markierung …]
usertags Fehler [+|-|=] Markierung [Markierung …]
setzt oder entfernt eine Benutzermarkierung für einen Fehler. Die Markierung muss
exakt den gewünschten Markierungsnamen haben; es gibt dort keine Vorgaben oder
Prüfungen von Markierungsnamen. Mehrere Markierungen können ebenfalls angegeben
werden. Die beiden Befehle (usertag und usertags) sind identisch. Wenn der Schalter =
nicht benutzt wird, muss mindestens eine Markierung angegeben werden, wobei der Befehl

bts usertags <Fehler> =

alle Benutzermarkierungen vom angegebenen Fehler entfernt.

claim Fehler [Anspruch]
zeichnet auf, dass Sie Anspruch auf einen Fehler erheben (z.B. für ein
Fehlerbearbeitungstreffen, eine »Bug Squashing Party«). Anspruch sollte ein
eindeutiges Kürzel sein, das es ermöglicht, die Fehler, auf die Sie Anspruch erheben,
zu identifizieren; oft wird eine E-Mail-Adresse benutzt.

Falls kein Anspruch angegeben wurde, wird die Umgebungsvariable DEBEMAIL oder EMAIL
(in dieser Reihenfolge geprüft) benutzt.

unclaim Fehler [Anspruch]
entfernt den Datensatz, mit dem Sie Anspruch auf einen Fehler erheben.

Falls kein Anspruch angegeben wurde, wird die Umgebungsvariable DEBEMAIL oder EMAIL
(in dieser Reihenfolge geprüft) benutzt.

severity Fehler Schweregrad
ändert den Schweregrad eines Fehlers. Verfügbare Schweregrade sind: wishlist, minor,
normal, important, serious, grave und critical. Der Schweregrad kann auf irgendeine
eindeutige Teilzeichenkette abgekürzt werden.

forwarded Fehler Adresse
markiert den Fehler als an die angegebene Adresse weitergeleitet (üblicherweise eine
E-Mail-Adresse oder eine URL für eine Fehlerdatenbank der Originalautoren).

notforwarded Fehler
markiert einen Fehler als nicht weitergeleitet.

package [Paket …]
Die folgenden Befehle werden nur auf Fehler gegen die aufgeführten Pakete angewandt;
dies dient als Sicherheitsmechanismus für die Fehlerdatenbank. Falls keine Pakete
aufgeführt sind, wird die Prüfung wieder ausgeschaltet.

limit [Schlüssel[:Wert]] …
Die folgenden Befehle werden nur auf Fehler angewandt, die dem angegebenen Kriterium
entsprechen; dies dient als Sicherheitsmechanismus für die Fehlerdatenbank. Falls
keine Werte aufgeführt sind, werden die Beschränkungen für diesen Schlüssel wieder
ausgeschaltet. Falls keine Schlüssel angegeben wurden, werden alle Beschränkungen
zurückgesetzt.

submitter
E-Mail-Adresse des Absenders

date Datum, an dem der Fehler versandt wurde

subject Betreff dieses Fehlers

msgid Nachrichtenkennung des anfänglichen Fehlerberichts

package Name des Binärpakets

source Name des Quellpakets

tag auf den Fehler bezogene Markierungen

severity
Schweregrad des Fehlers

owner Besitzer des Fehlers

affects Fehler, die dieses Paket beeinflussen

Um zum Beispiel die Zusammenstellung von Fehlern, die von nachfolgenden Steuerbefehlen
beeinflusst werden, auf diejenigen zu beschränken, die von
jrandomdeveloper@example.com versandt und mit wontfix markiert wurden, könnte
Folgendes verwendet werden:

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

Falls ein Schlüssel mehrfach benutzt wird, dann enthält die ausgewählte
Fehlerzusammenstellung jene, die auf einen der bereitgestellten Werte passen, zum
Beispiel gibt

bts limit package:foo severity:wishlist severity:minor

wird nur auf nachfolgende Steuerbefehle für Fehler des Pakets Foo angewandt, die
entweder den Schweregrad wishlist oder minor aufweisen.

owner Fehler Besitzer-E-Mail-Adresse
ändert die »Besitzer«-Adresse eines Fehlers, wobei ! »benutze die Adresse der
aktuellen E-Mail als neue Besitzeradresse« bedeutet.

Der Besitzer eines Fehlers akzeptiert die Verantwortung, ihn zu erledigen.

noowner Fehler
markiert, dass ein Fehler keinen »Besitzer« hat.

subscribe Fehler [E-Mail]
abonniert die gegebene E-Mail-Adresse für den angegebenen Fehler. Falls keine E-Mail-
Adresse angegeben wurde, wird die Umgebungsvariable DEBEMAIL oder EMAIL (in dieser
Reihenfolge) benutzt. Falls diese nicht gesetzt sind oder ! als E-Mail-Adresse
angegeben ist, wird Ihre Standard-E-Mail-Adresse verwendet.

Nach der Ausführung dieses Befehls wird ihnen eine Abonnement-Bestätigung gesandt, auf
die Sie antworten müssen. Wenn Sie einen Fehlerbericht abonniert haben, erhalten Sie
alle relevanten E-Mails und Benachrichtigungen, Benutzen Sie den Befehl unsubscribe,
um das Abonnement zu beenden.

unsubscribe Fehler [E-Mail]
beendet das Abonnement der angegebenen E-Mail-Adresse für den angegebenen
Fehlerbericht. Wie beim vorhergehenden Abonnieren werden, falls keine E-Mail-Adresse
angegeben wurde, die Umgebungsvariablen DEBEMAIL oder EMAIL (in dieser Reihenfolge)
benutzt. Falls diese nicht gesetzt sind oder ! als E-Mail-Adresse angegeben ist, wird
Ihre Standard-E-Mail-Adresse verwendet.

Nach der Ausführung dieses Befehls wird Ihnen eine Bestätigung für das Beenden des
Abonnements gesandt, auf die Sie antworten müssen. Benutzen Sie zum Abonnieren den
Befehl subscribe.

reportspam Fehler …
Der Befehl reportspam ermöglicht es Ihnen, zu melden, dass ein Fehlerbericht Spam
enthält. Er bewahrt davor, auf die Fehler-Website gehen zu müssen, um dies zu tun.

spamreport Fehler …
spamreport ist ein Synonym für reportspam.

cache [Optionen] [Betreuer-E-Mail-Adresse | Paket | src:Paket | from:Absender]
cache [Optionen] [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/.

Sie können die zwischengespeicherten Fehler mit dem Schalter -o verwenden. Zum
Beispiel:

bts -o bugs
bts -o show 12345

Außerdem wird bts die Dateien darin auf unsystematische Weise aktualisieren, da es
Informationen von der Fehlerdatenbank unter Benutzung des Befehls show herunterlädt.
Sie könnten daher den Zwischenspeicher einrichten, indem Sie die automatischen
Zwischenspeicheraktualisierungen die Fehler aktualisieren lassen, auf die Sie häufig
während der Woche Bezug nehmen.

Einige Optionen beeinflussen das Verhalten des Befehls cache. Die erste ist die
Einstellung von --cache-mode, die steuert, wieviel bts von den referenzierten
Verweisen von der Fehlerseite herunterlädt, einschließlich langweiliger Teile, wie den
Bestätigungs-E-Mails, E-Mails an den Steuer-Bot und der Mbox-Version des
Fehlerberichts. Sie kann drei Werte annehmen: min (das Minimum), mbox (das Minimum
plus der Mbox-Version des Fehlerberichts herunterladen) oder full (alles). Die zweite
ist --force-refresh oder -f. Sie erzwingt das Herunterladen sogar dann, wenn der
zwischengespeicherte Fehler aktuell ist. Die Option --include-resolved zeigt an, ob
Fehlerberichte, die als behoben markiert sind, während des Zwischenspeicherns
heruntergeladen werden sollen.

Jedes davon ist, wie nachfolgend beschrieben, in der Konfigurationsdatei einstellbar.
Dies könnte außerdem nach dem Befehl cache, ebenso wie am Anfang der Befehlszeile
angegeben werden.

Schlussendlich wird -q oder --quiet Nachrichten darüber, ob der Zwischenspeicher
aktuell ist, unterdrücken. Wird diese Option zweimal angegeben, werden alle
Zwischenspeichernachrichten (mit Ausnahme von Fehlermeldungen) unterdrückt.

Vorsicht allerdings beim Zwischenspeichern von RC-Fehlern: Es wird LANGE dauern! (Mit
über 1000 RC-Fehlern und einer Verzögerung von fünf Sekunden zwischen Fehlern, sehen
Sie sich mindestens 1,5 Stunden und wahrscheinlich bedeutend mehr als dem gegenüber.)

cleancache Paket | src:Paket | Paketbetreuer
cleancache from:Absender | tag:Markierung | usertag:Markierung | Zahl | ALL
bereinigt den Zwischenspeicher für das angegebene Paket, den Paketbetreuer. etc., wie
oben für den Befehl bugs beschrieben oder bereinigt den kompletten Zwischenspeicher,
falls ALL angegeben wurde. Dies ist nützlich, falls Sie einen permanenten
Netzwerkzugang haben oder falls Ihre Datenbank aus irgend einem Grund beschädigt
wurde. Beachten Sie, dass dieser Befehl aus Sicherheitsgründen nicht standardmäßig den
Wert DEBEMAIL oder EMAIL hat.

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
zeigt Version und Copyright-Information an.

help
zeigt eine kurze Zusammenfassung der Befehle, verdächtig ähnlich zu Teilen dieser
Handbuchseite.

UMGEBUNGSVARIABLEN

       DEBEMAIL
           Falls diese gesetzt ist, wird die Von:-Zeile in der E-Mail gesetzt, um diese E-Mail-
           Adresse anstelle Ihrer normalen E-Mail-Adresse zu benutzen (als wäre sie durch mail
           festgelegt).

       DEBFULLNAME
           Falls DEBEMAIL gesetzt ist, wird DEBFULLNAME geprüft, um den vollständigen Namen, der
           verwendet wird, zu bestimmen; falls dies nicht gesetzt ist, versucht bts einen Namen
           von Ihrem passwd-Eintrag zu bestimmen.

       BROWSER
           Falls gesetzt, gibt es den Browser an, der für die Optionen show und bugs verwendet
           wird. Lesen Sie die vorhergehende Beschreibung.

KONFIGURATIONSVARIABLEN

Die beiden Konfigurationsdateien /etc/devscripts.conf und ~/.devscripts werden in dieser
Reihenfolge durch eine Shell eingelesen, um Konfigurationsvariablen zu setzen.
Befehlszeilenoptionen können benutzt werden, um Einstellungen aus Konfigurationsdateien
außer Kraft zu setzen. Einstellungen aus Umgebungsvariablen werden zu diesem Zweck
ignoriert. Die derzeit bekannten Variablen sind:

BTS_OFFLINE
Falls dies auf yes gesetzt ist, dann ist es genauso, als wenn der
Befehlszeilenparameter --offline benutzt würde. Es hat nur Auswirkungen auf die
Befehle show und bugs. Vorgabe ist no. Weitere Informationen finden Sie in der
vorhergehenden Beschreibung des Befehls show.

BTS_CACHE
Falls dies auf no gesetzt ist, dann ist es genauso, als wenn der
Befehlszeilenparameter --no-cache benutzt würde. Es hat nur Auswirkungen auf die
Befehle show und bug. Vorgabe ist yes. Weitere Informationen finden Sie wieder beim
Befehl show weiter oben.

BTS_CACHE_MODE={min,mbox,full}
Wieviel von der Fehlerdatenbank sollte gespiegelt werden, wenn danach gefragt wird,
etwas zwischenzuspeichern? Nur das Minimum oder auch die Mbox oder das Ganze? Vorgabe
ist min, was die gleiche Bedeutung hat wie der Befehlszeilenparameter --cache-mode.
Dies hat nur Auswirkungen auf den Zwischenspeicher. Weitere Informationen finden Sie
beim Befehl cache.

BTS_FORCE_REFRESH
Falls dies auf yes gesetzt ist, dann ist es genauso, als wenn der
Befehlszeilenparameter --force-refresh benutzt würde. Es hat nur Auswirkungen auf den
Befehl cache. Vorgabe ist no. Weitere Informationen finden Sie beim Befehl cache.

BTS_MAIL_READER
Falls dies gesetzt ist, gibt es ein E-Mail-Programm an, der anstelle von mutt benutzt
wird. Entspricht der Befehlszeilenoption --mailreader.

BTS_SENDMAIL_COMMAND
Falls dies gesetzt ist, gibt es einen sendmail-Befehl an, der anstelle von
/usr/sbin/sendmail verwendet wird. Entspricht der Befehlszeilenoption --sendmail.

BTS_ONLY_NEW
lädt beim Zwischenspeichern nur neue Fehler herunter; prüft nicht auf Aktualisierungen
in Fehlern, die bereits vorliegen. Vorgabe ist no. Entspricht der Befehlszeilenoption
--only-new.

BTS_SMTP_HOST
Falls dies gesetzt ist, gibt es einen SMTP-Host an, der für den Versand von E-Mail
gegenüber dem Befehl sendmail den Vorzug bekommt. Entspricht der Befehlszeilenoption
--smtp-host.

Beachten Sie, dass diese Option eine höhere Priorität hat als BTS_SENDMAIL_COMMAND,
falls beide gesetzt sind, außer wenn die Option --sendmail verwendet wird.

BTS_SMTP_AUTH_USERNAME, BTS_SMTP_AUTH_PASSWORD
Falls diese Optionen gesetzt sind, ist es, als ob die Optionen --smtp-username und
--smtp-password benutzt würden.

BTS_SMTP_HELO
entspricht der Befehlszeilenoption --smtp-helo.

BTS_INCLUDE_RESOLVED
Falls dies auf no gesetzt ist, ist es, als ob der Befehlszeilenparameter
--no-include-resolved benutzt würde. Es hat nur Auswirkungen auf den Befehl cache.
Vorgabe ist yes. Weitere Informationen finden Sie beim Befehl cache.

BTS_SUPPRESS_ACKS
Falls dies auf yes gesetzt ist, dann ist es, als ob der Befehlszeilenparameter
--no-ack benutzt würde. Vorgabe ist no.

BTS_INTERACTIVE
Falls dies auf yes oder force gesetzt ist, dann ist es, als ob die
Befehlszeilenparameter --interactive oder --force-interactive benutzt würden. Vorgabe
ist no.

BTS_DEFAULT_CC
gibt eine Liste von E-Mail-Adressen an, an die eine Kopie der erzeugten E-Mail an den
Steuer-Bot automatisch gesandt werden sollte.

BTS_SERVER
Specify the name of a debbugs server which should be used instead of
https://bugs.debian.org.

SIEHE AUCH

       Bitte lesen Sie <https://www.debian.org/Bugs/server-control>, um weitere Einzelheiten zu
       erhalten, wie die Fehlerdatenbank unter Benutzung von E-Mails gesteuert wird und
       <https://www.debian.org/Bugs/>, um weitere Informationen über die Fehlerdatenbank zu
       erhalten.

       querybts(1), reportbug(1), pts-subscribe(1)

COPYRIGHT

       Dieses Programm unterliegt dem Copyright (C) 2001-2003 von Joey Hess <joeyh@debian.org>.
       Es wurden viele Änderungen vorgenommen unter dem Copyright (C) 2002-2005 von Julian Gilbey
       <jdg@debian.org> und dem Copyright (C) 2007 von Josh Triplett <josh@freedesktop.org>.

       Es ist lizensiert unter den Bedingungen der GPL, entweder Version 2 der Lizenz oder (nach
       Ihrer Wahl) irgendeiner späteren Version.