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>
show [Optionen] [Fehlernummer | Paket | Paketbetreuer | : ] [Opt=Wert …]
show [Optionen] [src:Paket | from:Absender] [Opt=Wert …]
show [Optionen] [tag:Markierung | usertag:Markierung ] [Opt=Wert …]
show [release-critical | release-critical/ … | RC]
Dies ist ein Synonym für bts bugs.
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
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 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.
Debian-Hilfswerkzeuge 2016-03-23 BTS.DE(1)