path: root/german/Bugs/server-control.wml

#use wml::debian::template title="Debian BTS – Kontroll-Server" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="af6db568fa508f5c59388f1ddb1a44165e40a276"
# $Id$
# Translator: Martin Schulze <joey@infodrom.org>
# Updated: Holger Wansing <linux@wansing-online.de>, 2011, 2012, 2015.

<h1>Einführung in den E-Mail-Server für Kontrolle und Manipulation</h1>

<p>Genau wie <code>request@bugs.debian.org</code> es erlaubt, <a 
   href="server-request">Fehlerdaten und -dokumentation über E-Mail</a> 
   abzurufen, erlaubt es <code>control@bugs.debian.org</code>, Fehlerberichte
   auf verschiedene Arten und Wege zu bearbeiten.</p>

<p>Der Kontroll-Server arbeitet genauso wie der Request-Server, mit
der Ausnahme, dass er einige zusätzliche Befehle unterstützt. In der
Tat ist er sogar das gleiche Programm. Die beiden Adressen werden nur
unterschieden, um zu verhindern, dass Anwender Fehler machen und
Probleme verursachen, während sie lediglich versuchen, Informationen
zu erhalten.</p>

<p>Da die für den Kontroll-Server spezifischen Befehle den Status eines
Fehlers ändern, wird eine Benachrichtigung über die Bearbeitung der
Befehle an den Betreuer des Pakets, dem die geänderten Fehler
zugewiesen sind, gesendet. Zusätzlich werden die E-Mail an den
Server und die daraus entstandenen Änderungen im Fehlerbericht
festgehalten und sind daher auf den Webseiten abrufbar.</p>

<p>Bitte lesen Sie die
<a href="server-request#introduction">Einführung zum
Request-Server</a>, die im World Wide Web bereitsteht, in der Datei
<code>bug-log-mailserver.txt</code>, oder durch Senden des Wortes
<code>help</code> an einen der E-Mail-Server, um Details der Arbeit der
E-Mail-Server zu erhalten sowie der gesamten Befehle.</p>

<p>Die <a href="server-refcard">Referenzkarte</a> für den E-Mail-Server
ist im WWW verfügbar, in
<code>bug-mailserver-refcard.txt</code> oder per E-Mail durch Senden
des Befehls
<code>refcard</code>.</p>


<h1>Befehle, die beim Kontroll-E-Mail-Server zur Verfügung stehen</h1>

<table style="margin-left:auto;margin-right:auto">
<tr>
<td align="center">Allgemeine</td>
<td align="center">Versionierung</td>
<td align="center">Duplikate</td>
<td align="center">Verschiedenes</td>
</tr>
<tr>
<!-- Allgemeine -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#reassign">reassign</a></li>
<li><a href="#severity">severity</a></li>
<li><a href="#tag">tags</a></li>
<li><a href="#retitle">retitle</a></li>
<li><a href="#submitter">submitter</a></li>
<li><a href="#affects">affects</a></li>
<li><a href="#summary">summary</a></li>
<li><a href="#outlook">outlook</a></li>
</ul>
</td>
<!-- Versionierung -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#found">found</a> |
<a href="#notfound">notfound</a></li>
<li><a href="#fixed">fixed</a> |
<a href="#notfixed">notfixed</a></li>
<li><a href="#reopen">reopen</a></li>
<!-- <dt>(close)</dt> Veraltet -->
</ul>
</td>
<!-- Duplikate -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#merge">merge</a> |
<a href="#unmerge">unmerge</a></li>
<li><a href="#forcemerge">forcemerge</a></li>
<li><a href="#clone">clone</a></li>
</ul>
</td>
<!-- Verschiedenes -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#thanks">thanks</a></li>
<li><a href="#comment">#</a></li>
<li><a href="#forwarded">forwarded</a> |
<a href="#notforwarded">notforwarded</a></li>
<li><a href="#owner">owner</a> |
<a href="#noowner">noowner</a></li>
<li><a href="#block">block</a> |
<a href="#unblock">unblock</a></li>
    <li><a href="#archive">archive</a> | <a href="#unarchive">unarchive</a></li>
          <li><a href="server-request#user">user</a> |
            <a href="server-request#usertag">usertag</a> |
            <a href="server-request#usercategory">usercategory</a></li>
</ul>
</td>
</tr>
</table>
<dl>

<dt><a name="reassign"><code>reassign</code> <var>Fehlernummer</var> 
    <var>Paket</var> [ <var>Version</var> ]</a></dt>

<dd>
<p>
Nimmt auf, dass der Fehler #<var>Fehlernummer</var> ein Fehler in
<var>Paket</var> ist. Dies kann verwendet werden, um nachträglich
einen Fehler einem Paket zuzuordnen, wenn der Benutzer
vergessen hat, die Pseudo-Kopfzeile anzugeben, oder um eine frühere
Zuweisung zu ändern. Es werden keine Benachrichtigungen an irgendjemanden
geschickt (anders als die üblichen Informationen bei der Verarbeitung).
</p>

<p>Falls Sie eine <var>Version</var> angeben, wird die Fehlerdatenbank bemerken,
dass der Fehler diese Version des frisch-zugewiesenen Pakets betrifft.</p>

<p>
  Sie können einen Fehler zwei Paketen auf einmal zuweisen, indem Sie die
  Paketnamen durch Komma trennen. Sie sollten dies allerdings <em>nur</em>
  tun, falls der Fehler durch eine Änderung in <em>einem</em> der beiden Pakete
  behoben werden kann. Falls dies nicht zutrifft, sollten Sie den Fehler
  <a href="#clone">klonen</a> und den Klon dem anderen Paket zuweisen.
</p>

</dd>


<dt><a name="reopen"><code>reopen</code> <var>Fehlernummer</var>
 [ <var>Urheber-Adresse</var> | <code>=</code> | <code>!</code> ]</a></dt>

<dd>

<p>
Öffnet #<var>Fehlernummer</var> erneut, wenn er geschlossen ist.
</p>

<p>Wenn Sie <code>=</code> als Urheber angeben, wird der gleiche
Urheber verwendet, der den Fehler ursprünglich berichtet hat, so dass
er erneut eine Bestätigung erhält, wenn der Fehlerbericht erneut
geschlossen wird.</p>

<p>Wenn Sie eine <var>Urheber-Adresse</var> angeben, wird der
Urheber auf die angegebene Adresse gesetzt. Wenn Sie wünschen, als
neuer Urheber des wieder-geöffneten Fehlerberichts eingetragen zu
werden, verwenden Sie das Kürzel <code>!</code> oder geben Sie Ihre
eigene E-Mail-Adresse an.</p>

<p>Es ist normalerweise eine gute Idee, der Person, die als Urheber
eingetragen wird, mitzuteilen, dass Sie den Bericht erneut öffnen,
damit diese Bescheid weiß, dass sie eine Bestätigung zu erwarten hat,
wenn der Bericht erneut geschlossen wird.</p>

<p>Wenn der Fehler nicht geschlossen wurde, wird reopen nichts tun,
nicht einmal den Urheber ändern. Um den Urheber eines offenen Fehlerberichts
zu ändern, verwenden Sie den <code>submitter</code> Befehl; beachten Sie, dass
dies den ursprünglichen Urheber über die Änderung informiert.</p>

<p>Falls der Fehler als in einer bestimmten Version eines Paketes geschlossen
notiert wurde, aber in einer späteren Version wieder aufgetaucht ist, ist es 
besser, stattdessen den <code>found</code>-Befehl zu verwenden.</p></dd>


<dt><a name="found"><code>found</code> <var>Fehlernummer</var> 
    [ <var>Version</var> ]</a></dt>


<dd>
<p>Notiere, dass #<var>Fehlernummer</var> in der gegebenen <var>Version</var>
des Pakets, der sie zugewiesen wurde, angetroffen wurde.
<var>Version</var> kann eine vollständig qualifizierte Version in der Form
<var>Quelltextpaketname/Version</var> sein.
</p>

<p>Die Fehlerdatenbank verwendet diese Information in Verbindung mit
korrigierten Versionen, die beim Schließen notiert werden, um Listen von
offenen Fehlern in verschiedenen Versionen jedes Pakets anzuzeigen. Sie 
betrachtet einen Fehler als offen, wenn sie keine korrigierte Version hat, oder
wenn er gefunden wurde, nachdem er korrigiert wurde.</p>

<p>Falls keine <var>Version</var> angegeben wurde, wird die Liste der
korrigierten Versionen für diesen Fehler bereinigt. Dies ist identisch zu
dem Verhalten von <code>reopen</code>.
<var>Version</var> kann eine vollständig qualifizierte Version in der Form
<var>Quelltextpaketname/Version</var> sein.
</p>

<p>Mit diesem Befehl wird ein Fehler lediglich als nicht-erledigt markiert,
   falls keine Version angegeben ist, oder falls die <var>Version</var>,
   in der der Fehler gefunden wurde, größer oder gleich der höchsten
   <var>Version</var> ist, die als korrigiert markiert wurde.
   (Falls Sie sich sicher sind, dass Sie den Fehler als nicht-erledigt
   markieren wollen, verwenden Sie <code>reopen</code> zusammen mit
   <code>found</code>).
</p>

<p>Dieser Befehl wurde als Präferenz für <code>reopen</code> eingeführt,
da es schwierig war, eine <var>Version</var> zu der Syntax dieses Befehls
hinzuzufügen, ohne unter Mehrdeutigkeiten zu leiden.</p></dd>

<dt><a name="notfound"><code>notfound</code> <var>Fehlernummer</var> 
    <var>Version</var></a></dt>

<dd>
<p>Entferne die Aufzeichnung, dass #<var>Fehlernummer</var> in der angegebenen
<var>Version</var> des Pakets, dem er zugewiesen wurde, angetroffen wurde.
<var>Version</var> kann eine vollständig qualifizierte Version in der Form
<var>Quelltextpaketname/Version</var> sein.
</p>

<p>Dies unterscheidet sich vom Schließen eines Fehlers in dieser Version 
darin, dass der Fehler nicht als in dieser Version korrigiert aufgeführt ist;
keine Information über diese Version wird bekannt sein. Es ist dazu gedacht,
Irrtümer, wann der Fehler gefunden wurde, in den Aufzeichnungen zu korrigieren.
</p></dd>

<dt><a name="fixed"><code>fixed</code> <var>Fehlernummer</var> <var>Version</var></a></dt>

<dd>
<p>Kennzeichne, dass der Fehler #<var>Fehlernummer</var> in der angegebenen
   <var>Version</var> des zugewiesenen Pakets korrigiert wurde.
   <var>Version</var> kann eine vollständig qualifizierte Version in der Form
   <var>Quelltextpaketname/Version</var> sein.
</p>

<p>Dies führt <em>nicht</em> dazu, dass der Fehler als geschlossen markiert
   wird, es ergänzt lediglich eine weitere Version, in der der Fehler
   korrigiert wurde. Verwenden Sie die Fehlernummer-done-Adresse, um einen
   Fehler zu schließen und ihn als in einer bestimmen Version korrigiert zu
   markieren.
</p></dd>

<dt><a name="notfixed"><code>notfixed</code> <var>Fehlernummer</var> <var>Version</var></a></dt>

<dd>
<p>Entferne die Aufzeichnung, dass der Fehler <var>Fehlernummer</var> in der
   angegebenen <var>Version</var> korrigiert wurde.
   <var>Version</var> kann eine vollständig qualifizierte Version in der Form
   <var>Quelltextpaketname/Version</var> sein.
</p>

<p>Dieser Befehl ist äquivalent zu <code>found</code> gefolgt von 
   <code>notfound</code> (<q>found</q> entfernt das <q>fixed</q> in einer
   bestimmten Version, und <q>notfound</q> entfernt den <q>found</q>)
   mit der Ausnahme, dass der Fehler nicht wieder geöffnet wird, wenn
   die Version, in der der Fehler gefunden wurde, größer als jede
   Version ist, in der der Fehler als korrigiert markiert wurde.
   Es ist dazu gedacht, Irrtümer in der Aufzeichnung zu korrigieren,
   wann ein Fehler behoben wurde. In den meisten Fällen benötigen Sie
   eigentlich <code>found</code>, nicht <code>notfixed</code>.
</p></dd>

<dt><a name="submitter"><code>submitter</code> <var>Fehlernummer</var>
    <var>Urheber-Adresse</var> | <code>!</code></a></dt>

<dd>
<p>
Ändert den Urheber von #<var>Fehlernummer</var> auf
<var>Urheber-Adresse</var>.
</p>

<p>Falls Sie der neue Urheber des Berichts werden wollen, können Sie die
Kurzform <code>!</code> verwenden, um Ihre eigene E-Mail Adresse
anzugeben.</p>

<p>Während der <code>reopen</code>-Befehl den Urheber von anderen mit dem zu
öffnenden zusammengeführten Fehlern ändert, beeinflusst <code>submitter</code>
zusammengeführte Fehler nicht.</p></dd>

<dt><a name="forwarded"><code>forwarded</code> <var>Fehlernummer</var> <var>Adresse</var></a></dt>

<dd>
<p>
Vermerkt, dass <var>Fehlernummer</var> an den ursprünglichen
Betreuer unter <var>Adresse</var> weitergeleitet wurde. Dieses leitet
den Bericht nicht tatsächlich weiter. Es kann dafür benutzt
werden, um eine fehlerhafte forwarded-to-Adresse zu ändern oder um
eine neue für einen Fehler zu vermerken, der bisher nicht als
weitergeleitet markiert wurde. <var>Adresse</var> sollte im Allgemeinen eine URI
sein, oder möglicherweise eine E-Mail-Adresse. Die Verwendung einer URI wo
möglich erlaubt es Werkzeugen, den Status in anderen Fehlerdatenbanken (wie
Bugzilla) für den Fehlerstatus abzufragen.
</p>

<p>
   Verwendungsbeispiel:
</p>

<pre>
   forwarded 12345 http://bugz.illa.foo/cgi/54321
</pre></dd>

<dt><a name="notforwarded"><code>notforwarded</code> 
    <var>Fehlernummer</var></a></dt>

<dd>
<p>
Vergisst jegliche Idee, dass <var>Fehlernummer</var> an einen
ursprünglichen Betreuer weitergeleitet wurde. Wenn der Fehler nicht
als forwarded markiert war, wird dieses nichts tun.</p></dd>

<dt><a name="retitle"><code>retitle</code> <var>Fehlernummer</var> 
    <var>Neuer-Titel</var></a></dt>

<dd>

<p>
Ändert den Titel des Fehlerberichts zu dem angegebenen (normalerweise
wird das <code>Subject</code> aus der E-Mail-Kopfzeile des ursprünglichen
Berichts genommen). Auch werden hiermit die Titel aller mit diesem Fehlerbericht
zusammengefassten Fehlerberichte geändert.
</p></dd>

<dt><a name="severity"><code>severity</code> <var>Fehlernummer</var> <var>Schwere</var></a></dt>

<dd>

<p>Setzt den Schweregrad für den Fehlerbericht #<var>Fehlernummer</var>
auf <var>Schwere</var>. Es wird keine
Benachrichtigung an den Benutzer verschickt, der den Fehler berichtet
hat.</p>

<p>Schweregrade sind <bts_severities>.
</p>

<p>Die Bedeutung der <a
href="Developer#severities">Schweregrade</a> finden Sie in den
allgemeinen Informationen zum Fehler-System für Entwickler.</p></dd>

  <dt><a name="affects"><code>affects</code> <var>Fehlernummer</var>
      [ <code>+</code> | <code>-</code> | <code>=</code>
      ] <var>Paket</var> [ <var>Paket</var> ... ]</a></dt>
  <dd>
    <p>
      Zeigt an, dass ein Fehler ein anderes Paket betrifft. Falls
      <var>Fehlernummer</var> das <var>Paket</var> unbenutzbar macht,
      obwohl der Fehler tatsächlich in dem Paket vorhanden ist, dem
      er zugewiesen wurde, wird der Fehler in der Voreinstellung auf
      der Fehlerseite des anderen <var>Paket</var>s aufgelistet.
      Dies sollte immer dann benutzt werden, wenn der Fehler so
      schwerwiegend ist, dass verschiedene Benutzer Fehlerberichte gegen
      das falsche Paket einsenden könnten.
      <code>=</code> setzt die Liste der betroffenen Pakete auf die
      hierauf folgend angegebenen Pakete, dies ist der Standard,
      wenn noch keine Pakete angegeben wurden; <code>-</code> entfernt
      das angegebene Paket von der Liste betroffener Pakete;
      <code>+</code> fügt das angegebene Paket zur Liste der
      betroffenen Pakete hinzu, und ist der Standard, wenn bereits Pakete
      angegeben wurden.
    </p>
  </dd>

  <dt><a name="summary"><code>summary</code> <var>Fehlernummer</var>
      [<var>Nachrichtennummer</var>] | <var>Zusammenfassungstext</var>]</a></dt>
  <dd>
    <p>
      Wählt eine Nachricht aus, die als Zusammenfassung des Fehlers
      verwendet wird. Der erste Absatz der Nachricht, der keine
      Pseudo-Kopfzeilen oder Kontrollbefehle enthält, wird ausgewertet und als
      Zusammenfassung verwendet. Diese wird oben auf der Seite des
      Fehlerberichts dargestellt. Das ist sinnvoll in Fällen, wo der
      ursprüngliche Bericht das Problem nicht richtig beschreibt oder
      es so viele Nachrichten gibt, dass das tatsächliche Problem
      schwierig zu erkennen ist.
    </p>
    <p>
      Falls die <var>Nachrichtennummer</var> nicht angegeben ist, wird
      die Zusammenfassung gelöscht. <var>Nachrichtennummer</var> ist die
      Nummer der Nachricht, wie sie in der Ausgabe des 
      Fehlerbericht-CGI-Skripts angezeigt wird; falls eine
      <var>Nachrichtennummer</var> gleich 0 angegeben ist, wird die aktuelle
      Nachricht verwendet (das heißt, die Nachricht, die an control@bugs.debian.org
      geschickt wurde und welche den summary-Kontrollbefehl enthält).
    </p>
    <p>
      Wenn die <var>Nachrichtennummer</var> nicht numerisch und auch nicht
      leer ist, wird dies als der Text angenommen, auf den der
      Zusammenfassungstext gesetzt werden soll.
    </p>
  </dd>

  <dt><a name="outlook"><code>outlook</code> <var>Fehlernummer</var>
      [<var>Nachrichtennummer</var> | <var>Vorausschautext</var>]</a></dt>
  <dd>
    <p>
      Wählt eine Nachricht, die als Vorausschau für die Behebung des Fehlers
      (oder den derzeitigen Status zur Behebung des Fehlers) verwendet wird.
      Der erste Abschnitt der Nachricht, der weder Pseudo-Header noch
      Kontrollbefehl ist, wird verarbeitet und als Vorausschau für den Fehler
      gesetzt, um oben auf der Seite des Fehlerberichts angezeigt zu werden.
      Dies ist nützlich, um die Arbeit mit anderen zu koordinieren, die mit der
      Behebung dieses Fehlers beschäftigt sind (zum Beispiel auf einer
      Fehlerbehebungsparty (Bug Squashing Party)).
    </p>
    <p>
      Falls die <var>Nachrichtennummer</var> nicht angegeben ist, wird der
      Vorausschautext gelöscht. <var>Nachrichtennummer</var> ist die
      Nummer der Nachricht gemäß der Ausgabe des Fehlerbericht-CGI-Skripts;
      wenn die <var>Nachrichtennummer</var> gleich 0 ist, wird die aktuelle
      Nachricht verwendet (das heißt, die Nachricht, die an
      control@bugs.debian.org gesendet wurde und den outlook-Kontrollbefehl
      enthält).
    </p>
    <p>
      Wenn die <var>Nachrichtennummer</var> nicht numerisch und auch nicht
      leer ist, wird dies als der Text angenommen, auf den der
      Vorausschautext gesetzt werden soll.
    </p>
  </dd>

<dt><a name="clone"><code>clone</code> <var>Fehlernummer</var> <var>NeueID</var> [ <var>NeueIDs</var> ... ]</a></dt>

  <dd>
<p>Der clone-Kontrollbefehl erlaubt es, einen Fehlerbericht zu
  duplizieren. Es ist nützlich, wenn ein einziger Bericht tatsächlich mehrere
  unterschiedliche Fehler anspricht.
  <q><var>NeueID</var></q>/<q><var>NeueIDs</var></q> sind negative
  Nummern, von Leerzeichen getrennt, die in nachfolgenden Kontrollbefehlen
  verwendet werden können, um auf die neuen duplizierten Fehlerberichte zu
  verweisen. Ein neuer Bericht wird für jede neue ID generiert.</p>

  <p>Beispielsverwendung:</p>

  <pre>
        clone 12345 -1 -2
        reassign -1 foo
        retitle -1 foo: foo sucks
        reassign -2 bar
        retitle -2 bar: bar sucks when used with foo
        severity -2 wishlist
        clone 123456 -3
        reassign -3 foo
        retitle -3 foo: foo sucks
        merge -1 -3
  </pre>
</dd>

<dt><a name="merge"><code>merge</code> <var>Fehlernummer</var> <var>Fehlernummer</var> ...</a></dt>

<dd>

<p>
Fasst zwei oder mehrere Fehlerberichte zusammen. Wenn Berichte
zusammengefasst sind, wirken sich das Öffnen, Schließen, Markieren als
Weitergeleitet bzw. dessen Aufhebung und die Zuweisung an ein Paket
jeweils auf alle Berichte dieser Menge aus und nicht nur auf einen
einzigen.
</p>

<p>Bevor Fehler zusammengefasst werden können, müssen sie sich in exakt
dem gleichen Zustand befinden: entweder sind alle geöffnet oder
geschlossen, mit den gleichen ursprünglichen Autoren als forwarded-to
markiert oder alle nicht als weitergeleitet markiert, alle dem
gleichen Paket (oder den gleichen Paketen, ein exakter
String-Vergleich wird auf die Pakete durchgeführt) zugewiesen und alle
müssen die gleiche Schwere haben. Wenn sie sich nicht im
gleichen Zustand befinden, sollten Sie <code>reassign</code>,
<code>reopen</code> und so weiter verwenden, um sicherzustellen, dass
sie sich im gleichen Zustand befinden, bevor Sie <code>merge</code>
benutzen. Die Titel müssen nicht übereinstimmen und werden von
der Zusammenfassung nicht beeinflusst. Auch die Markierungen müssen nicht
übereinstimmen, sie werden kombiniert.</p>

<p>Wenn einer der Fehler, der in einem <code>merge</code>-Befehl
aufgelistet ist, bereits mit einem anderen Fehler zusammengefasst ist,
werden alle diese Berichte mit den neuen aufgelisteten zusammengefasst.
Zusammenfassen ist wie eine Gleichheits-Relation: Es ist reflexiv,
transitiv und symmetrisch.</p>

<p>Das Zusammenfassen von Berichten bewirkt, dass eine Bemerkung im Log
jedes Berichts erscheint; auf den WWW-Seiten fügt dies Links
zu den anderen Fehlern ein.</p>

<p>Zusammengefasste Berichte verfallen gleichzeitig, und nur dann, wenn
alle der Berichte gleichzeitig die Kriterien für den Verfall erfüllen.</p></dd>

<dt><a name="forcemerge"><code>forcemerge</code> <var>Fehlernummer</var> 
    <var>Fehlernummer</var> ...</a></dt>

   <dd>
   <p>Erzwingt das Zusammenfassen zweier oder mehrerer Fehlerberichte. Während 
      bei einem normalen <q>merge</q> die Fehlerberichte exakt den gleichen 
      Zustand aufweisen müssen, wird hier der Zustand des ersten angegebenen 
      Fehlerberichts allen nachfolgend aufgeführten Fehlerberichten zugewiesen.
      Um zu vermeiden, dass Tippfehler fälschlicherweise Fehler zusammenfassen,
      müssen die Fehler im gleichen Paket sein. Lesen Sie den 
      obigen Text für eine Beschreibung, was <q>Zusammenfassen</q> bedeutet.
      </p>

   <p>Beachten Sie, dass dies das Schließen von Fehlern durch Zusammenfassen
      ermöglicht; Sie sind dafür verantwortlich, die Einreicher mit einer
      angemessenen Abschlussnachricht zu benachrichtigen, falls Sie dies 
      durchführen.</p>
   </dd>

<dt><a name="unmerge"><code>unmerge</code> <var>Fehlernummer</var></a></dt>

<dd>

<p>
Zieht einen Fehlerbericht aus einer zusammengefassten Fehler-Menge
heraus. Wenn der angegebene Bericht mit mehreren anderen
zusammengefasst ist, bleiben die anderen Fehlerberichte weiterhin
zusammengefasst; lediglich die Assoziation mit dem explizit angegebenen
Bericht wird gelöst.
</p>

<p>Wenn viele Fehlerberichte zusammengefasst sind und Sie wünschen,
diese in zwei separate Gruppen aufzuteilen, müssen Sie jeden einzelnen
Bericht einer dieser Gruppen aus der großen Gruppe herausziehen und
anschließend in der neuen Gruppe zusammenfassen.</p>

<p>Sie können mit dem Befehl <code>unmerge</code> nur einen Bericht
aus einer Menge herausziehen; wenn Sie mehr als einen Bericht aus
einer Gruppe herausziehen möchten, schreiben Sie einfach mehrere
<code>unmerge</code>-Befehle in Ihre E-Mail.</p></dd>

<dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>Fehlernummer</var> [ <code>+</code> 
    | <code>-</code> | <code>=</code> ] <var>Markierung</var> 
    [ <var>Markierung</var> ... ] [ <code>+</code> | <code>-</code>
    | <code>=</code> <var>Markierung</var> ... ] ]</a></dt>

  <dd>
  <p>Setzt Markierungen für den Fehlerbericht #<var>Fehlernummer</var>.
  Es wird keine Benachrichtigung an den Anwender geschickt, der den Fehler
  berichtet hat. Die Aktion <code>+</code> bedeutet, dass jede folgend
  übergebene Markierung hinzugefügt wird, <code>-</code> bedeutet,
  dass jede folgend übergebene Markierung entfernt wird und
  <code>=</code> bedeutet, dass die in der Liste folgenden
  Markierungen gesetzt werden sollen. Zwischen den Markierungen
  vorhandene Anweisungen <code>+</code>, <code>-</code> oder
  <code>=</code> ändern die Aktion für die nachfolgenden Markierungen.
  Voreingestellt ist, dass neue Markierungen hinzugefügt werden.</p>

  <p>Beispiel für die Benutzung:</p>

  <pre>
        \# Dasselbe wie <q>tags 123456 + patch</q>
        tags 123456 patch

        \# Dasselbe wie <q>tags 123456 + help security</q>
        tags 123456 help security

        \# Hinzufügen der <q>fixed</q> und <q>pending</q>-Markierungen
        tags 123456 + fixed pending

        \# Entfernen der <q>unreproducible</q>-Markierung
        tags 123456 - unreproducible

        \# Setze Markierungen exakt auf <q>moreinfo</q> und <q>unreproducible</q>
        tags 123456 = moreinfo unreproducible

        \# Entfernen der <q>moreinfo</q>-Markierung und Hinzufügen der
        \# <q>patch</q>-Markierung
        tags 123456 - moreinfo + patch
  </pre>

  <p>Markierungen können zurzeit folgende Werte annehmen: <bts_tags>.
  </p>

  <p>Die Bedeutung der <a href="Developer#tags">Markierungen für 
  Fehlerberichte</a>
  finden Sie in den allgemeinen Informationen zum Fehler-System für
  Entwickler.</p></dd>

<dt><a name="block"><code>block</code> <var>Fehlernummer</var> <code>by</code>
    <var>Fehlernummer</var> ...</a></dt>

  <dd>Fügt die Anmerkung hinzu, dass die Fehlerbehebung des ersten Fehlers
  durch die anderen aufgeführten Fehler blockiert wird.</dd>

<dt><a name="unblock"><code>unblock</code> <var>Fehlernummer</var> <code>by</code> <var>Fehlernummer</var> ...</a></dt>

  <dd>Entfernt die Anmerkung, dass die Fehlerbehebung des ersten Fehlers durch
  die anderen aufgeführten Fehler blockiert wird.</dd>

<dt><a name="close"><code>close</code> <var>Fehlernummer</var> [ <var>korrigierte-Version</var> ] (veraltet)</a></dt>

<dd>

<p>
Schließt den Fehlerbericht #<var>Fehlernummer</var>.
</p>

<p>Eine Benachrichtigung wird an den Benutzer geschickt, der den
Fehler berichtet hat, jedoch ist (im Gegensatz zu E-Mails an
<var>Fehlernummer</var><code>-done@bugs.debian.org</code>) der Text der E-Mail, die
das Schließen verursacht hat, <strong>nicht</strong> in dieser
Benachrichtigung enthalten. Der Betreuer, der den Bericht geschlossen
hat, sollte sicherstellen, womöglich durch Versenden einer separaten
Nachricht, dass der Benutzer, der den Fehler berichtet hat, weiß, wieso
er geschlossen wurde. Die Verwendung dieses Befehls wird daher nicht
empfohlen. Siehe auch die Informationen für Entwickler über
<a href="Developer#closing">das korrekte Schließen eines
Fehlerberichts</a>.</p>

<p>Falls Sie eine <var>korrigierte-Version</var> angeben, wird die 
Fehlerdatenbank vermerken, dass der Fehler in dieser Version des Pakets
korrigiert wurde.</p></dd>

<dt><a name="package"><code>package</code> [ <var>Paketname</var> ... ]</a></dt>

  <dd>
  <p>Beschränkt die folgenden Kommandos derart, dass sie nur auf Fehler
  angewendet werden, die hier aufgeführt sind. Sie können ein oder mehrere
  Pakete angeben. Falls Sie kein einziges Paket angeben, werden die folgenden
  Kommandos auf alle Fehler angewandt. Es wird empfohlen, dies als
  Sicherheitsvorkehrung zu verwenden, falls Sie irrtümlicherweise die falschen
  Fehlernummern erwischen.</p>

  <p>Beispielsanwendung:</p>

  <pre>
        package foo
        reassign 123456 bar 1.0-1

        package bar
        retitle 123456 bar: bar sucks
        severity 123456 normal

        package
        severity 234567 wishlist
  </pre>
</dd>

<dt><a name="owner"><code>owner</code> <var>Fehlernummer</var> 
    <var>Adresse</var> | <code>!</code></a></dt>

  <dd><p>Setzt <var>Adresse</var> als <q>Besitzer</q> von #<var>Fehlernummer</var>.
  Der Besitzer eines Fehlers beansprucht die Verantwortung für das Beheben des
  Fehlers für sich. Dies ist
  nützlich, um die Arbeit in Fällen zu verteilen, bei denen ein Paket ein Team
  von Betreuern besitzt.</p>

  <p>Falls Sie selbst der Besitzer des Fehlers werden wollen, können Sie die
  Abkürzung <code>!</code> verwenden oder Ihre eigene E-Mail Adresse
  angeben.</p></dd>

<dt><a name="noowner"><code>noowner</code> <var>Fehlernummer</var></a></dt>

  <dd>Vergisst jegliche Information darüber, dass der Fehler einen anderen
  Besitzer als den üblichen Betreuer hat. Falls der Fehler keinen Besitzer
  eingetragen hat, tut dies nichts.</dd>

<dt><a name="archive"><code>archive</code> <var>Fehlernummer</var></a></dt>

  <dd>Archiviert einen Fehler, der zu einem Zeitpunkt in der Vergangenheit
      archiviert worden wäre, aber nicht archiviert worden ist, falls der Fehler
  die Voraussetzungen für die Archivierung erfüllt. Die Zeit wird ignoriert.
  </dd>

<dt><a name="unarchive"><code>unarchive</code> <var>Fehlernummer</var></a></dt>

  <dd>Macht die Archivierung eines Fehlers rückgängig. Dies sollte in der
  Regel mit reopen und found/fixed gekoppelt werden. Fehler, deren
  Archivierung rückgängig gemacht wurde, können mit archive wieder archiviert
  werden, falls die nicht zeitbezogenen Archivierungsrichtlinien erfüllt sind.
     Sie sollten die Archivierung nicht rückgängig machen, um triviale 
     Änderungen an archivierten Fehlern vorzunehmen, z.B. den Einreicher zu
     ändern. Primär dient dieser Befehl dazu, Fehler erneut zu öffnen, die
     ohne den Eingriff der BTS-Administratoren archiviert wurden.
  </dd>

<dt><a name="comment"><code>#</code>...</a></dt>

  <dd>Einzeiliger Kommentar. Das <code>#</code>-Zeichen muss am Anfang der
  Zeile stehen. Die Kommentartexte sind in der Bestätigung enthalten,
  die dem Einsender und den betroffenen Betreuern zugeschickt wird, so
  dass Sie hiermit die Gründe für Ihre Befehle dokumentieren können.</dd>

<dt><a name="thanks"><code>quit</code></a></dt>
<dt><code>stop</code></dt>
<dt><code>thank</code></dt>
<dt><code>thanks</code></dt>
<dt><code>thankyou</code></dt>
<dt><code>thank you</code></dt>
<dt><code>--</code></dt>
<!-- #366093, I blame you! -->
<!-- <dt><code>kthxbye</code></dt> -->
<!-- Siehe... Ich habe es dokumentiert! -->

  <dd>
  Wenn dies allein in einer Zeile steht, eventuell gefolgt von Leerzeichen, so
  teilt dies dem Kontroll-Server mit, die Bearbeitung der Nachricht zu beenden;
  der Rest der Nachricht kann Erklärungen, Signaturen und alles andere
  enthalten, nichts davon wird von dem Kontroll-Server entdeckt.</dd>

</dl>

<hr />

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"