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

#use wml::debian::template title="Debians felrapporteringssystem - styrservern" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="eeaeaa4686ab3760dcfb69cfc7763efb9f48537b"

<h1>Introduktion till e-postservern för felrapportsstyrning och -manipulering</h1>

<p>
Precis som <code>request@bugs.debian.org</code> gör det möjligt att
<a href="server-request">hämta information om felrapporter via e-post</a>,
gör <code>control@bugs.debian.org</code> det möjligt att manipulera
felrapporterna på olika sätt.
</p>

<p>
Om du behöver skriva ett meddelande till felrapporten och även manipulera
felrapportens metadata, kan kommandona även inkluderas i e-postmeddelandet
till <code>nnn@bugs.debian.org</code>. Gör detta genom att börja
e-postmeddelandet med kommandona med <code>Control: </code> före.
Ett annat vanligt sätt är att skicka en kopia av e-postmeddelandet till
<code>control@bugs.debian.org</code> och starta e-postmeddelandet med
kommandona, och avsluta med <code>thanks</code>.
</p>

<p>
Styrservern fungerar precis som frågeservern, förutom att den har ett
antal extrakommandon.
Om sanningen ska fram så är det faktiskt samma program.
De två adresserna är bara separerade för att undvika att användare gör
misstag och orsakar problem när allt de ville göra var att hämta
information.
</p>

<p>
Eftersom de kommandon som gäller för styrservern faktiskt ändrar
felrapportens status sänds en kvittering på behandlingen av kommandona till
den/de ansvariga för de paket vars status ändras.
Dessutom loggas brevet som sänds till servern i felrapporten och blir därmed
tillgängligt via webbsidorna.
</p>

<p>
Se <a href="server-request#introduction">introduktion till frågeservern</a>
som finns på webben, i filen
<code>bug-log-mailserver.txt</code>, eller genom att skicka
<code>help</code> till någon av e-postservrarna för grundläggande information
om hur du använder e-postservrarna, och för de kommandon som finns
tillgängliga oavsett vilken adress du använder.
</p>

<p>
Ett <a href="server-refcard">referenskort</a> för e-postservrarna finns
tillgängligt via webben, i
<code>bug-mailserver-refcard.txt</code> eller via e-post med
<code>refcard</code>-kommandot.
</p>

<h1>Kommandon som finns på styrservern</h1>

  <table style="margin-left:auto;margin-right:auto">
    <tr>
    <td align="center">Allmänt</td>
    <td align="center">Versionshantering</td>
    <td align="center">Duplikat</td>
    <td align="center">Blandat</td>
    </tr>
    <tr>
      <!-- General -->
      <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>
      <!-- Versioning -->
      <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> Deprecated -->
	</ul>
      </td>
      <!-- Duplicates -->
      <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>
      <!-- Misc. -->
      <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 id="reassign">
  <code>reassign</code> <var>felnummer</var> <var>paket</var>
  [ <var>version</var> ]
 </dt>
 <dd>
  <p>
Anger att fel nummer <var>felnummer</var> är ett fel i paketet
<var>paket</var>.
Detta kan användas för att sätta paketnamnet om användaren glömde
pseudo-brevhuvudet, eller för att ändra en tidigare tilldelning.
Inga notifikationer sänds till någon (förutom den normala information om
kommandotydningen).
  </p>
  <p>
Om du inkluderar en <var>version</var> kommer felrapporteringssystemet
notera att felet gäller den versionen av det paket det nyss tilldelats.
  </p>
  <p>
Du kan tilldela ett fel till två paket på samma gång genom att separera
paketnamnen med ett komma. Du bör dock <em>endast</em> göra detta om
felet kan korrigeras genom en ändring i <em>något</em> av paketen.
Om så inte är fallet bör du <a href="#clone">klona</a> felet och tilldela klonen
till det andra paketet.
  </p>
 </dd>
 <dt id="reopen">
  <code>reopen</code> <var>felnummer</var>
  [ <var>ursprungsadress</var> | <code>=</code> | <code>!</code> ]
 </dt>
 <dd>
  <p>
Öppnar upp felrapport nummer <var>felnummer</var> igen och rensar alla
rättade versioner om den har stängts.
  </p>

  <p>
Som standard, eller om du anger <code>=</code>, kommer fortfarande den
ursprunglige avsändaren att stå som felrapportör, så de kommer att få
information om när den stängs på nytt.
  </p>

  <p>
Om du skickar med en ny adress (<var>ursprungsadress</var>) kommer
den att användas istället, och om du själv vill stå som avsändare av den
nyöppnade felrapporten kan du använda förkortningen <code>!</code>, eller
ange din egen e-postadress.
  </p>

  <p>
Det är vanligtvis en bra idé att tala om för personen som kommer att anges
som avsändare att du öppnar upp rapporten igen, så att de vet att de ska
förvänta sig den rapport de får när den stängs på nytt.
  </p>

  <p>
Om felrapporten inte är stängd kommer inte reopen att göra någonting, inte
ens ändra avsändare.
För att ändra avsändare för en öppen felrapport, använd kommandot
<code>submitter</code>; observera att den ursprungliga avsändaren då kommer
informeras om ändringen.
  </p>

  <p>
Om det noterats att felet stängts i en specifik version av ett paket men
återkommit i en senare version är det bättre att istället använda kommandot
<code>found</code>.
  </p>
 </dd>

 <dt id="found">
  <code>found</code> <var>felnummer</var> [ <var>version</var> ]
 </dt>

 <dd>
  <p>
Notera det faktum att <var>felnummer</var> har upptäckts i
<var>version</var> av det paket det tilldelats.
<var>version</var> kan vara en fullt kvalificerad version
på formen <var>källpaketnamn/version</var>.
  </p>

  <p>
Felrapporteringssystemet använder denna information, tillsammans med rättade
versioner som lagras när felrapporter stängs, till att visa en förteckning
över fel som är öppna i olika versioner av varje paket.
Det anser en fel att vara öppen när det inte finns någon rättad version,
eller när den upptäckts i en nyare version än det rättats i.
  </p>

  <p>
Om ingen <var>version</var> anges rensas listan över rättade versioner.
Detta är samma beteende som <code>reopen</code>.
<var>version</var> kan vara en fullt kvalificerad version
på formen <var>källpaketnamn/version</var>.
  </p>

  <p>
Detta kommando gör bara att ett fel markeras som orättat när ingen version
anges, eller som <var>version</var>en som markeras som funnen är lika med
eller större än
den <var>version</var> som markerats som rättad.
(Om du är säker på att felet inte är rättat, använd <code>reopen</code>
tillsammans med <code>found</code>.)
  </p>

  <p>
Kommandot har introducerats framför <code>reopen</code> eftersom det var
svårt att lägga till en <var>version</var> till det kommandots syntax utan
att det blev tvetydigt.
  </p>
 </dd>

 <dt id="notfound">
  <code>notfound</code> <var>felnummer</var> <var>version</var>
 </dt>

 <dd>
  <p>
Ta bort information om att <var>felnummer</var> påträffats i given
<var>version</var> av paketet till vilken det tilldelats.
<var>version</var> kan vara en fullt kvalificerad version
på formen <var>källpaketnamn/version</var>.
  </p>

  <p>
Till skillnad mot att stänga felrapporten listas inte felet som rättat i den
versionen heller, information om den versionen kommer finnas tillgänglig.
Detta kommando är avsett för att rätta felaktigheter i rapporteringen om när
ett fel påträffats.
  </p>
 </dd>

 <dt id="fixed">
  <code>fixed</code> <var>felnummer</var> <var>version</var>
 </dt>

 <dd>
  <p>
   Ange att fel <var>felnummer</var> rättades i den givna
   <var>version</var>en av paketet det är tilldelat till.
   <var>version</var> kan vara en fullt kvalificerad version
   på formen <var>källpaketnamn/version</var>.
  </p>

  <p>
Detta innebär <em>inte</em> att felrapporten stängs, den lägger bara till
ytterligare en version i vilken felet har rättats.
Använd <q>felnummer-done</q>-adressen för att stänga en felrapport
och ange att den är rättad i en specifik version.
  </p>
 </dd>

 <dt id="notfixed">
  <code>notfixed</code> <var>felnummer</var> <var>version</var>
 </dt>

 <dd>
  <p>
   Ta bort markeringen om att fel <var>felnummer</var> rättades i den givna
   <var>version</var>en.
   <var>version</var> kan vara en fullt kvalificerad version
   på formen <var>källpaketnamn/version</var>.
  </p>

  <p>
   Kommandot motsvarar <code>found</code> följt av <code>notfound</code>
   (found tar bort fixed för en specifik version, och notfound tar bort found)
   med det undantaget att
   felet inte öppnas om den funna versionen är större än någon av
   de existerande rättade versionerna. Kommandot är menat för att rätta misstag i
   uppgifterna om när ett fel rättades; i de flesta fall vill du använda
   <code>found</code>, inte <code>notfixed</code>.
  </p>
 </dd>

 <dt id="submitter">
  <code>submitter</code> <var>felnummer</var>
  <var>avsändaradress</var> | <code>!</code>
 </dt>

 <dd>
  <p>
Ändra avsändaren av felrapport nummer <var>felnummer</var> till
<var>avsändaradress</var>.
  </p>

  <p>
Om du vill bli ny avsändare av rapporten kan du använda kortformen
<code>!</code> eller ange din egen e-postadress.
  </p>

  <p>
Medan <code>reopen</code>-kommandot ändrar avsändaren för andra felrapporter
som slagits samman med den som återöppnas påverkar <code>submitter</code> inte
sammanslagna rapporter.
  </p>
 </dd>

 <dt id="forwarded">
  <code>forwarded</code> <var>felnummer</var> <var>adress</var>
 </dt>
 <dd>
  <p>
Noterar att felrapport nummer <var>felnummer</var> har vidaresänts till en
utvecklare uppströms på adressen <var>adress</var>,
men skickar inte vidare själva rapporten. 
Detta kan användas för att ändra en existerande, felaktig,
vidaresändningsadress, eller för att lägga in en ny till en felrapport som
inte tidigare markerats som vidaresänd.
<var>adress</var> ska oftast vara en URI, eller möjligen en e-postadress.
Genom att använda en URI när det går möjliggör du för
verktyg att ställa frågor till ett externt
felhanteringssystem (såsom bugzilla) om ett fels status.
  </p>
  
  <p>Exempel på användning:</p>

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

 <dt id="notforwarded">
  <code>notforwarded</code> <var>felnummer</var>
 </dt>
 <dd>
  <p>
Glömmer allting om att felrapport nummer <var>felnummer</var> har vidaresänts till
någon utvecklare uppströms.
Om felet inte hade någon vidaresändning registrerad gör detta kommando
ingenting.
  </p>
 </dd>

 <dt id="retitle">
  <code>retitle</code> <var>felnummer</var> <var>ny-titel</var>
 </dt>
 <dd>
  <p>
Ändrar titeln på felrapporten till den som anges (förinställt värde är
ärenderaden från det ursprungliga felrapporteringsbrevet).
    Kommer också ändra titlarna på alla felrapporter som detta fel
    slås samman med.
  </p>
 </dd>

 <dt id="severity">
  <code>severity</code> <var>felnummer</var> <var>grad</var>
 </dt>
 <dd>
  <p>
Sätter allvarlighetsgraden för felrapport nummer <var>felnummer</var> till
allvarlighetsgrad <var>grad</var>.
Ingen notifikation sänds till den användare som rapporterade felet.
  </p>

  <p>
Tillgängliga allvarlighetsgrader är:
<bts_severities>.
  </p>

  <p>
För <a href="Developer#severities">betydelser</a>, se
den övergripande utvecklardokumentationen för felrapporteringssystemet.
  </p>
 </dd>

  <dt id="affects"><code>affects</code> <var>felnummer</var>
      [ <code>+</code> | <code>-</code> | <code>=</code>
      ] <var>paket</var> [ <var>paket</var> ... ]</dt>
  <dd>
    <p>
      Indikerar att ett fel påverkar ett annat paket. I det fall
      <var>felnummer</var> orsakar problem i <var>paket</var>
      trots att felet i själva verket finns i det paket det
      är kopplat till, gör detta kommando att felet listas som standard i
      <var>paket</var>s fellista. Detta ska generellt användas
      när felet är allvarligt nog att föranleda användare att rapportera
      flera rapporter som kopplas till fel paket. <code>=</code> sätter
		påverkade paket till den givna listan, och är standard-inställningen
		om inga paket ges; <code>-</code> tar bort givna paket från
		listan av påverkade paket; <code>+</code> lägger till till listan
		av påverkade paket, och är standardinställningen om paket anges.
    </p>
  </dd>

  <dt id="summary"><code>summary</code> <var>felnummer</var>
      [<var>meddelandenummer</var>] <var>sammanfattning</var></dt>
  <dd>
    <p>
      Väljer ett meddelande som används som sammanfattning av felet. Det första
      stycket i det meddelandet som inte är ett
      pseudohuvud och inte ett kontroll-stycke tolkas och sätts som
      sammanfattning av felet.
      Sammanfattningen visas högst upp på felrapportsidan.
      Detta är användbart i fall originalrapporten
      inte beskriver problemet korrekt eller felet har flera
      meddelanden vilket gör det svårt att identifiera problemet.
    </p>
    <p>
      Om <var>meddelandenummer</var> inte ges, töms
      sammanfattningen. <var>meddelandenummer</var> är meddelandenumret som det
      listas i utdatat från cgi-skriptet bugreport.
    </p>
  </dd>
  <dt><a name="outlook"><code>outlook</code> <var>felnummer</var>
      [ <var>meddelandenummer</var> | <var>utsikts-text</var> ]</a></dt>
  <dd>
    <p>
		Väljer ett meddelande som skall användas som utsikt för rättelse av ett 
		fel (eller den aktuella statusen på felrättelsen). Det första avsnittet 
		som inte är en pseudoheader/kontroll i det påföljande meddelandet används
		som felets utsikter och visas överst på felrapportsidan. Det är användbart
		för koordinering med andra som arbetar med att rätta samma fel (t.ex
		under en felrättningfest).
    </p>
    <p>
		Om <var>meddelandenummer</var> icke anges, töms utsikten.
		<var>meddelandenummer</var> är det meddelandenummer som är utdata från
		bugreport-cgi-skriptet; om ett <var>meddelandenummer</var> anges som 0,
		används aktuellt meddelande (alltså meddelandet som skickades till
		control@bugs.debian.org med kontrollkommandot outlook).
    </p>
    <p>
		Om <var>meddelandenummer</var> inte är ett numeriskt värde och inte en
		tom sträng antas det att det är texten som skall användas som utsikt.
    </p>
  </dd> 
 <dt id="clone">
  <code>clone</code> <var>felnummer</var> <var>nytt-id</var>
  [ <var>nya-id</var> ]
 </dt>
 <dd>
  <p>
Klonkommandot låter dig duplicera en felrapport.
Det är användbart när en enda felrapport faktiskt indikerar att flera olika
fel har uppstått.
<q><var>Nya id</var></q> är negativa värden, avdelade med blanksteg,
vilka kan användas i följande styrkommandon för att nå de nyduplicerade
felen.
En ny rapport genereras för varje nytt id.
  </p>

  <p>Exempel på användning:</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 id="merge">
  <code>merge</code> <var>felnummer</var> <var>felnummer</var> ...
 </dt>
 <dd>
  <p>
Slår ihop två eller flera felrapporter.
När rapporter är hopslagna kommer öppnande, stängande, (av)markerande som
vidaresänd och omtilldelning till ett nytt paket av någon av felrapporterna
att få samma effekt på samtliga hopslagna rapporter.
  </p>

  <p>
Innan felrapporter kan slås samman måste de ha samma tillstånd:
antingen alla öppna eller alla stängda, med samma
"vidaresänd-uppströms"-adress (eller inte alls markerad som vidaresänd),
alla tilldelade samma paket (en exakt strängjämförelse görs på de
paket till vilka felrapporterna är tilldelade), och alla ha samma
allvarlighetsgrad.
Om de från början inte har samma tillstånd måste du använda
<code>reassign</code>, <code>reopen</code>, och så vidare, för att se till
att de är det innan du använder
<code>merge</code>.
Rubrikerna behöver inte vara lika och påverkas inte heller av
sammanslagningen.
Märken behöver inte heller vara identiska, de kommer att slås ihop.
  </p>

  <p>
Om någon av felrapporterna som listas i <code>merge</code>-kommandot redan
är hopslagen med någon annan felrapport kommer alla redan hopslagna rapporter
att slås samman med de angivna felrapporterna.
Hopslagning är som ekvivalens: reflexiv, transitiv och symmetrisk.
  </p>

  <p>
När felrapporter slås ihop noteras detta i alla rapporters logg, och på
webbsidorna inkluderas länkar till de andra felen.
  </p>

  <p>
Hopslagna felrapporter försvinner samtidigt, och bara när alla
rapporterna separat uppfyller kriterierna för att raderas.
  </p>
 </dd>

 <dt id="forcemerge">
  <code>forcemerge</code> <var>felnummer</var> <var>felnummer</var>
  ...
 </dt>
 <dd>
  <p>
  Tvingar fram en sammanslagning mellan två eller flera felrapporter.
  Den data för det första felet som anges, som måste vara identisk för att en
  normal sammanslagning ska kunna genomföras, sätts på de felrapporter som
  listas därefter. Märken slås samman som vanligt. För att undvika att
  felskrivningar av misstag slår samman felrapporter måste felen gälla samma
  paket. Se texten ovan för en beskrivning av vad sammanslagning innebär.
  </p>

  <p>Observera att detta gör det möjligt att stänga felrapporter genom en
  sammanslagning; du ansvarar för att meddela avsändaren med ett lämpligt
  stängningsmeddelande om du gör det.
  </p>
 </dd>

 <dt id="unmerge">
  <code>unmerge</code> <var>felnummer</var>
 </dt>
 <dd>
  <p>
Plockar bort en felrapport från dem den slagits samman med.
Om rapporten är sammanslagen med flera andra kommer de andra fortfarande att
vara sammanslagna med varandra; bara deras association med felrapporten som
anges här kommer att tas bort.
  </p>
  <p>
Om många felrapporter är hopslagna och du vill dela upp dem i två separata
grupper måste du först plocka isär alla rapporter i den ena gruppen en och
en, för att sedan slå ihop dessa till den nya gruppen.
  </p>

  <p>
Du kan bara plocka isär en rapport åt gången med
<code>unmerge</code>-kommandot.
Om du vill plocka isär fler än en kan du helt enkelt ange flera
<code>unmerge</code>-kommandon i ditt meddelande.
  </p>
 </dd>

 <dt id="tag"><a name="tags"><!-- match tags too --></a>
  <code>tags</code> <var>felnummer</var> [ <code>+</code> |
    <code>-</code> | <code>=</code> ] <var>märke</var> [ <var>märke</var>
    ... ] [ <code>+</code> | <code>-</code>
    | <code>=</code> <var>märke</var> ... ] ]
 </dt>

 <dd>
  <p>
  Sätter märken på felrapport nummer <var>felnummer</var>.
  Ingen notifiering sänds till den användare som rapporterade felet.
  Att välja funktionen
  <code>+</code> betyder att alla angivna märken läggs till,
  <code>-</code> betyder att alla angivna märken tas bort, och
  <code>=</code> betyder att märkena ställs om till den angivna listan.
  Om <code>+</code>, <code>-</code> eller <code>=</code>
  dyker upp mitt i listan ställer det om hur de efterföljande
  märkena behandlas.
  Förvald funktion är att lägga till.
  </p>

  <p>Exempel på hur det används:</p>

<pre>
\# samma som <q>tags 123456 + patch</q>
tags 123456 patch

\# samma som <q>tags 123456 + help security</q>
tags 123456 help security

\# lägg till märkena <q>fixed</q> och <q>pending</q>
tags 123456 + fixed pending

\# ta bort märket <q>unreproducible</q>
tags 123456 - unreproducible 

\# Ställ in exakt märkena <q>moreinfo</q> och <q>unreproducible</q>
tags 123456 = moreinfo unreproducible
  
\# ta bort märket <q>moreinfo</q> och lägg till märket <q>patch</q>
tags 123456 - moreinfo + patch
</pre>

  <p>Tillgängliga markeringar är för närvarande <bts_tags>.
  </p>

  <p>
  För <a href="Developer#tags">betydelser</a>, se
  den övergripande utvecklardokumentationen för felrapporteringssystemet.
  </p>
 </dd>

 <dt id="block">
  <code>block</code> <var>felnummer</var> <code>by</code> <var>fel</var> ...
 </dt>
 <dd>
  <p>Markera att rättningen av det första felet blockeras av det andra
  listade felet.
  </p>
 </dd>

 <dt id="unblock">
  <code>unblock</code> <var>felnummer</var> <code>by</code> <var>fel</var> ...
 </dt>
 <dd>
  <p>
  Markera att rättningen av det första felet inte längre blockeras
  av det andra listade felet.
  </p>
 </dd>

 <dt id="close">
  <code>close</code> <var>felnummer</var>[ <var>rättad-version</var> ]
  (bör ej användas)
 </dt>
 <dd>
  <p>
Stänger felrapport nummer <var>felnummer</var>.
  </p>

  <p>
Användaren som ursprungligen skickade in felrapporten meddelas, men
innehållet i det brev som stängde felrapporten inkluderas
<em>inte</em> (till skillnad från
<var>felnummer</var><code>-done@bugs.debian.org</code>).
Den som stänger rapporten bör se till att användaren som skickade rapporten
får reda på varför den stängts, till exempel genom att skicka ett separat
brev.
Därför avråds det från att använda detta kommando.
Se utvecklarinformationen om
<a href="Developer#closing">hur man stänger en felrapport på rätt sätt</a>.
  </p>

  <p>
Om du skickar med en <var>rättad-version</var> kommer
felrapporteringssystemet notera att felet rättats i den versionen av paketet.
  </p>
 </dd>

 <dt id="package">
  <code>package</code> [ <var>paketnamn</var> ... ]
 </dt>
 <dd>
  <p>
  Begränsar de kommandon som följer så att de endast kan appliceras på fel
  som sänts in mot de paket som anges.
  Du kan ange ett eller flera paket.
  Om du inte anger några paket gäller de kommandon som följer för samtliga
  paket.
  Vi ber dig använda detta som en säkerhetsåtgärd om du av misstag skulle
  använda felaktiga felnummer.
  </p>

  <p>Exempel på hur det används:</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 id="owner">
  <code>owner</code> <var>felnummer</var> <var>adress</var> | <code>!</code>
 </dt>

 <dd>
  <p>
  Ställer in <var>adress</var> till <q>ägare</q> till felrapport
  nummer <var>felnummer</var>.
  En felrapports ägare tar ansvar för att rätta den.
  Detta kan användas när ett paket tas hand om av en grupp.
  </p>

  <p>
  Om du själv vill bli ägare till felrapporten kan du använda snabbkommandot
  <code>!</code> istället eller ange din egen e-postadress.
  </p>
 </dd>

 <dt id="archive">
  <code>archive</code> <var>felnummer</var>
 </dt>

 <dd>
  <p>
  Arkiverar en felrapport som vid något tidigare tillfälle varit arkiverad
  men som inte är det för närvarande, om felrapporten uppfyller
  kraven för arkivering, förutom tid.
  </p>
 </dd>

 <dt id="unarchive">
  <code>unarchive</code> <var>felnummer</var>
 </dt>

 <dd>
  <p>
  Avarkiverar en felrapport som arkiverats tidigare.
  Avarkivering bör normalt göras tillsammans med lämpliga
  <code>reopen</code> och <code>found</code>/<code>fixed</code>.
  Felrapporter som avarkiverats kan arkiveras på nytt med
  <code>archive</code> så länge alla krav för arkivering förutom
  tid uppfylls.
  Du bör inte
  använda unarchive för att göra enkla ändringar i arkiverade fel, såsom att
  ändra avsändare; det primära syftet är att möjliggöra att
  fel som har arkiverats öppnas upp igen utan
  inblandning av administratörer.
  </p>
 </dd>

 <dt id="comment">
  <code>#</code>...
 </dt>

 <dd>
  <p>
  Enradskommentar.
  <code>#</code>-tecknet måste stå först på raden.
  Kommentarstexten kommer tas med i bekräftelsen som sänds till avsändaren
  och de berörda paketansvariga, så du kan använda detta för att
  dokumentera varför du sänder kommandona.
  </p>
 </dd>

<dt id="thanks"><code>quit</code></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> -->
<!-- See... I documented it! -->

 <dd>
  <p>
  På en ensam rad, oavsett skiftläge, möjligen efterföljd av mellanslag,
  säger åt styrservern att sluta behandla meddelandet; resten av
  meddelandet kan innehålla förklaringar, signaturer eller något annat,
  inget av det kommer att läsas av styrservern.
  </p>
 </dd>
</dl>

<hr>

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