Sync

CVS version numbers

danish/devel/testing.wml: 1.18 -> 1.19

1 files changed, 65 insertions, 65 deletions

diff --git a/danish/devel/testing.wml b/danish/devel/testing.wml
index d9ff9e51b4d..89dcd5a14d1 100644
--- a/danish/devel/testing.wml
+++ b/danish/devel/testing.wml
@@ -1,47 +1,47 @@
 #use wml::debian::template title="Debians 'testing'-distribution" BARETITLE=true
-#use wml::debian::translation-check translation="1.20"
+#use wml::debian::translation-check translation="1.21"
 #include "$(ENGLISHDIR)/releases/info"
 
 <p>For at få generelle, brugerorienterede oplysninger om distributionen 
-"testing", se <a href="$(DOC)/FAQ/ch-ftparchives#s-testing">Debians 
+<q>testing</q>, se <a href="$(DOC)/FAQ/ch-ftparchives#s-testing">Debians 
 OSS</a>.</p>
 
 <p>En vigtig ting at bemærke, både for almindelige brugere og udviklerne af
-"testing", er at sikkerhedsopdateringer til "testing" <strong>ikke varetages af
-sikkerhedsteamet</strong>.  For flere oplysninger, se 
+<q>testing</q>, er at sikkerhedsopdateringer til <q>testing</q> <strong>ikke 
+varetages af sikkerhedsteamet</strong>.  For flere oplysninger, se 
 <a href="../security/faq#testing">sikkerhedsteamets OSS</a>.</p>
 
-<p>Denne side handler primært om ting vedrørende "testing", der er vigtige for
-Debian-udviklere.</p>
+<p>Denne side handler primært om ting vedrørende <q>testing</q>, der er vigtige 
+for Debian-udviklere.</p>
 
-<h2>Hvordan "testing" fungerer</h2>
+<h2>Hvordan <q>testing</q> fungerer</h2>
 
-<p>"Testing"-distributionen genereres automatisk.  Den genereres ud fra 
-distributionen "unstable" af nogle skripter som prøver at flytte pakker der
+<p><q>Testing</q>-distributionen genereres automatisk.  Den genereres ud fra 
+distributionen <q>unstable</q> af nogle skripter som prøver at flytte pakker der
 indenfor rimelighedens grænser ikke forventes at indeholde vigtige fejl.  Det
-gøres på en måde, der sikrer at afhængigheder med andre pakker i "testing" 
+gøres på en måde, der sikrer at afhængigheder med andre pakker i <q>testing</q> 
 altid er opfyldt.</p>
 
-<p>En (given version af en) pakke bliver flyttet til "testing" når den opfylder
+<p>En (given version af en) pakke bliver flyttet til <q>testing</q> når den opfylder
 samtlige følgende kriterier:</p>
 
 <ol>
-  <li>Den skal have været i "unstable" i 10, 5 eller 2 dage, afhængigt af hvor 
+  <li>Den skal have været i <q>unstable</q> i 10, 5 eller 2 dage, afhængigt af hvor 
   meget upload af pakken hastede;</li>
   
   <li>Den skal være oversat og ajourført på alle arkitekturer som den tidligere
-  har været oversat til i "unstable";</li>
+  har været oversat til i <q>unstable</q>;</li>
   
   <li>Den skal have færre udgivelseskritiske fejl, eller det samme antal, som
-  versionen i "testing" (se nedenfor for <a href="#faq">flere 
+  versionen i <q>testing</q> (se nedenfor for <a href="#faq">flere 
   oplysninger</a>);</li>
   
   <li>Alle dens afhængigheder skal <em>enten</em> kunne opfyldes af pakker som
-  allerede er i "testing", <em>eller</em> skal kunne opfyldes af en gruppe
+  allerede er i <q>testing</q>, <em>eller</em> skal kunne opfyldes af en gruppe
   pakker som vil blive placeret deri på samme tid;</li>
   
-  <li>Processen med at placere pakken i "testing" må ikke medføre at andre 
-  pakker i "testing" holder op med at virke. (Se nedenfor for 
+  <li>Processen med at placere pakken i <q>testing</q> må ikke medføre at andre 
+  pakker i <q>testing</q> holder op med at virke. (Se nedenfor for 
   <a href="#faq">flere oplysninger</a>.)</li>
 </ol>  
 
@@ -49,21 +49,21 @@ samtlige følgende kriterier:</p>
 Candidate</q>.</p>
 
 <p>Opdateringsskriptet viser hvornår enhver pakke kan tænkes at blive flyttet
-fra "unstable" til "testing".  Dets uddata er dobbelt:</p>
+fra <q>unstable</q> til <q>testing</q>.  Dets uddata er dobbelt:</p>
 
 <ul>
   <li><a href="http://ftp-master.debian.org/testing/update_excuses.html">\
       Opdateringsundskyldningerne</a>
       [<a href="http://ftp-master.debian.org/testing/update_excuses.html.gz">\
       gzip'et</a>]: liste over alle kandiderende pakkeversioner og deres 
-      generelle status på deres vej ind i "testing"; dette er noget kortere og 
+      generelle status på deres vej ind i <q>testing</q>; dette er noget kortere og 
       pænere end
   </li>
   <li><a href="http://ftp-master.debian.org/testing/update_output.txt">\
       opdateringsuddataene</a>
       [<a href="http://ftp-master.debian.org/testing/update_output.txt.gz">\
       gzip'et</a>]: de komplette, noget mere råt udseende uddata fra
-      "testing"-skripterne, efterhånden som de kommer igennem kandidaterne.
+      <q>testing</q>-skripterne, efterhånden som de kommer igennem kandidaterne.
   </li>
 </ul>
 
@@ -79,21 +79,21 @@ fejl.</p>
 
 <p>Sådanne fejl antages at have betydning for hvorvidt en pakke vil blive 
 udgivet med den stabile udgave af Debian: generelt, hvis en pakke har åbne
-udgivelseskritiske fejl mod sig, kommer den ikke ind i "testing", og dermed
-bliver den heller ikke udgivet i "stable".</p>
+udgivelseskritiske fejl mod sig, kommer den ikke ind i <q>testing</q>, og dermed
+bliver den heller ikke udgivet i <q>stable</q>.</p>
 
-<p>Optællingen af fejl i "testing" for en pakke, er omtrent antallet af fejl
-på det seneste tidpunkt hvor versionen i "testing" svarede til versionen i
-"unstable".  Fejl hørende til <strong><current_release_name></strong> eller
+<p>Optællingen af fejl i <q>testing</q> for en pakke, er omtrent antallet af fejl
+på det seneste tidpunkt hvor versionen i <q>testing</q> svarede til versionen i
+<q>unstable</q>.  Fejl hørende til <strong><current_release_name></strong> eller
 <strong><current_testing_name></strong> tælles ikke med.  Fejl hørende til 
 <strong>sid</strong> tælles til gengæld med.</p>
 
-<h3><q>Hvordan kan overførslen af en pakke til "testing" overhovedet få andre
+<h3><q>Hvordan kan overførslen af en pakke til <q>testing</q> overhovedet få andre
 pakker til at holde op med at virke?</q></h3>
 
 <p>Strukturen på distributionsarkiverne er sådan, at de kun kan indeholde en
 version af en pakke; en pakke defineres via sit navn.  Derfor, når 
-kildekode-pakken <tt>acmefoo</tt> overføres til "testing", sammen med sine
+kildekode-pakken <tt>acmefoo</tt> overføres til <q>testing</q>, sammen med sine
 binære pakker <tt>acme-foo-bin</tt>, <tt>acme-bar-bin</tt>, 
 <tt>libacme-foo1</tt> og <tt>libacme-foo-dev</tt>, fjernes den gamle 
 version.</p>
@@ -111,7 +111,7 @@ også påvirke pakker, hvortil der er knyttet versionsafhængigheder af typerne
 <p>Når de binære pakker som leveres af en kildekodepakke ændrer sig på denne
 måde, skal alle pakker som er afhængige af de gamle binære filer ændres til at 
 være afhængige af de nye binære filer i stedet for.  Da installering af den 
-sådan kildekodepakke i "testing" får alle pakker, som er afhængige af den, til 
+sådan kildekodepakke i <q>testing</q> får alle pakker, som er afhængige af den, til 
 at holde op med at virke, skal man være omhyggelig:  Alle afhængige pakker skal
 opdaterede og parate til selv at blive installeret, så de fortsat vil virke og,
 når alt er parat, vil manuel indgriben af den udgivelsesansvarlige eller en
@@ -120,31 +120,31 @@ assistent normalt være påkrævet.</p>
 <p>Hvis du har problemer med komplicerede pakkegrupper som denne, så kontakt
 debian-devel eller debian-release for at få hjælp.</p>
 
-<h3><q>Jeg forstår det stadig ikke!  "testing"-skripterne siger at denne pakke
-er en "valid candidate", men den er stadig ikke overført til "testing".</q></h3>
+<h3><q>Jeg forstår det stadig ikke!  <q>testing</q>-skripterne siger at denne pakke
+er en <q>valid candidate</q>, men den er stadig ikke overført til <q>testing</q>.</q></h3>
 
 <p>Dette har tilbøjelighed til at ske, når en installering, direkte eller 
 indirekte, vil få andre pakker til at holde op med at virke.</p>
 
 <p>Husk at overveje din pakkes afhængigheder.  Lad os antage at din pakke er
 afhængig af libtool, eller libltdl<var>X</var>.  Din pakke vil ikke blive 
-overført til "testing", før den rigtige version af libtool er parat til at 
+overført til <q>testing</q>, før den rigtige version af libtool er parat til at 
 følge med.</p>
 
 <p>Det vil dermed ikke ske, før en installering af libtool ikke resultere i at
-ting, som allerede er i "testing" holder op med at virke.  Med andre ord, 
+ting, som allerede er i <q>testing</q> holder op med at virke.  Med andre ord, 
 indtil alle andre pakker som er afhængige af libltdl<var>Y</var> (hvor 
 <var>Y</var> er den tidligere version) er blevet genoversat, og alle deres
 udgivelseskritiske fejl er væk, osv., vil ingen af disse pakker bliver overført
-til "testing".</p>
+til <q>testing</q>.</p>
 
 <p>Her er <a href="http://ftp-master.debian.org/testing/update_output.txt">\
 tekstuddataene</a> [<a href="http://ftp-master.debian.org/testing/update_output.txt.gz">gzip'et</a>]
 nyttige: de giver tips (omend meget kortfattede) til hvilke pakker som holder
-op med at virke, når en "valid candidate" overføres til "testing".</p>
+op med at virke, når en <q>valid candidate</q> overføres til <q>testing</q>.</p>
 
 <h3><q>Hvorfor er det nogle gange svært at få <kbd>Architecture: 
-all</kbd>-pakker overført til "testing"?</q></h3>
+all</kbd>-pakker overført til <q>testing</q>?</q></h3>
 
 <p>Hvis <kbd>Architecture: all</kbd>-pakken skal overføres, skal det være 
 muligt at opfylde alle dens afhængigheder på <strong>alle</strong> 
@@ -152,7 +152,7 @@ arkitekturer.  Hvis den er afhængig af bestemte pakker som kun kan oversættes
 på et begrænset antal af Debians arkitekturer, så kan det ikke lade sig 
 gøre.</p>
 
-<p>Dog vil "testing" indtil videre ignorere <kbd>Architecture: 
+<p>Dog vil <q>testing</q> indtil videre ignorere <kbd>Architecture: 
 all</kbd>-pakkers installérbarhed på ikke-i386-arkitekturer.  (<q>Det er en 
 stort 'hack' og jeg er ikke stolt over at have gjort det, men...</q> --aj)</p>
 
@@ -166,7 +166,7 @@ undersøg build-logfilerne og ret de problemer som eventuelt er forsaget af din
 pakkes kildekode.</p>
 
 <p>Hvis du tilfældigvis bemærker at den nye version af pakken er oversat til 
-nogle arkitekturer, men ikke viser sig i "testing"-skripternes uddata, er du 
+nogle arkitekturer, men ikke viser sig i <q>testing</q>-skripternes uddata, er du 
 nødt til at være lidt mere tålmodig indtil den ansvarlige buildd-vedligeholder 
 overfører filerne til Debians arkiv.</p>
 
@@ -174,7 +174,7 @@ overfører filerne til Debians arkiv.</p>
 version af pakken, på trods af at du har overført en rettelse til en tidligere
 fejl, er grunden formentlig at den er markeret som ventende på afhængigheder
 (Dep-Wait).  Se også listen over disse såkaldte
-<a href="http://buildd.debian.org/stats/">wanna-build-tilstande</a> ("states") 
+<a href="http://buildd.debian.org/stats/">wanna-build-tilstande</a> (<q>states</q>) 
 for at blive helt sikker.</p>
 
 <p>Disse problemer bliver som regel rettet med tiden, men hvis du har ventet i
@@ -192,22 +192,22 @@ pakker fra den ustabile distribution.  Generelt bør man af almindelig høflighed
 orientere den relevante tilpasnings-postliste.</p>
 
 <h3><q>Er der nogen undtagelser? Jeg er sikker på at <tt>acmefoo</tt> lige er
-blevet overført til "testing" på trods af at alle krav ikke er opfyldt.</q></h3>
+blevet overført til <q>testing</q> på trods af at alle krav ikke er opfyldt.</q></h3>
 
-<p>Udgivelsesadministratorene ("release managers") kan tilsidesætte reglerne på 
+<p>Udgivelsesadministratorene (<q>release managers</q>) kan tilsidesætte reglerne på 
 to måder:</p>
 
 <ul>
   <li>De kan beslutte at beskadigelsen som skyldes overførslen af et nyt
       bibliotek vil gøre ting bedre, fremfor værre, og slippe den igennem 
       sammen med sin flotile af afhængige pakker.</li>
-  <li>De kan også manuelt fjerne pakker fra "testing" som ikke virker, så nye
+  <li>De kan også manuelt fjerne pakker fra <q>testing</q> som ikke virker, så nye
       ting kan installeres.</li>
 </ul>
 
 <h3><q>Har du et rigtigt, ikke-trivielt eksempel?</q></h3>
 
-<p>Her er et: når kildekode-pakken <tt>apache</tt> overføres til "testing", 
+<p>Her er et: når kildekode-pakken <tt>apache</tt> overføres til <q>testing</q>, 
 sammen med sin binære pakker <tt>apache</tt>, <tt>apache-common</tt>, 
 <tt>apache-dev</tt> og <tt>apache-doc</tt>, fjernes den gamle version.</p>
 
@@ -215,10 +215,10 @@ sammen med sin binære pakker <tt>apache</tt>, <tt>apache-common</tt>,
 <var>et-eller-andet</var>), apache-common (&lt;&lt;
 <var>et-eller-andet</var>)</code>, så denne ændring ødelægger alle disse
 afhængigheder.  Som følge deraf skal alle Apache-moduler oversættes mod den nye
-version af Apache for at "testing" kan opdateres.</p>
+version af Apache for at <q>testing</q> kan opdateres.</p>
 
 <p>Lad os uddybe dette lidt mere:  efter alle modulerne er blevet opdateret i
-"unstable" så de fungerer med den nye Apache, vil "testing"-skripterne prøve
+<q>unstable</q> så de fungerer med den nye Apache, vil <q>testing</q>-skripterne prøve
 <tt>apache-common</tt> og finde ud af at det får alle Apache-modulerne til at 
 holde op med at virke, fordi de har <code>Depends: apache-common (&lt;&lt; 
 <var>den aktuelle version</var>)</code>, og de prøver 
@@ -237,7 +237,7 @@ fungerer.</p>
 <p>Når alt har været prøvet, kontrollerer de hvor mange pakker der ikke længere 
 virker, afgører om det er værre eller bedre end det oprindelige, og enten 
 acceptere alt eller glemme det.  Du kan se det i <tt>update_output.txt</tt> på 
-linierne "<code>recur:</code>".</p>
+linjerne <q><code>recur:</code></q>.</p>
 
 <p>For eksempel:</p>
 
@@ -247,10 +247,10 @@ linierne "<code>recur:</code>".</p>
 
 <p>betyder i bund og grund <q>har allerede opdaget at <var>foo</var> og
 <var>bar</var> forbedrer situationen, jeg prøver nu <var>baz</var> for at se 
-hvad der sker, selvom det får ting til at holde op med at virke</q>.  Linierne 
-i <tt>update_output.txt</tt> som begynder med "<code>accepted</code>" indikerer
-at situationen lader til at være blevet forbedret, og linierne med
-"<code>skipped</code>" gør det værre.</p>
+hvad der sker, selvom det får ting til at holde op med at virke</q>.  Linjerne 
+i <tt>update_output.txt</tt> som begynder med <q><code>accepted</code></q> indikerer
+at situationen lader til at være blevet forbedret, og linjerne med
+<q><code>skipped</code></q> gør det værre.</p>
 
 <h3><q>Filen <tt>update_output.txt</tt> er fuldstændig ulæselig!</q></h3>
 
@@ -264,39 +264,39 @@ at situationen lader til at være blevet forbedret, og linierne med
      * i386: ginac-cint, libginac-dev
 </pre>
 
-<p>Dette betyder at hvis <tt>cln</tt> overføres til "testing", vil 
+<p>Dette betyder at hvis <tt>cln</tt> overføres til <q>testing</q>, vil 
 <tt>ginac-cint</tt> og <tt>libginac-dev</tt> ikke kunne installeres i 
-"testing" på i386.  Bemærk at arkitekturene kontrolleres i alfabetisk 
+<q>testing</q> på i386.  Bemærk at arkitekturene kontrolleres i alfabetisk 
 rækkefølge og kun den første arkitektur med problemer vises - det er grunden 
 til at alpha-arkitekturen vises så ofte.</p>
 
-<p>Linien "got" indeholder antallet af problemer i "testing" på de forskellige
+<p>Linjen <q>got</q> indeholder antallet af problemer i <q>testing</q> på de forskellige
 arkitekturer (indtil den første arkitektur hvor der findes problemer - se
-ovenfor).  "i-45" betyder, at hvis <tt>cln</tt> blev overført til "testing", 
+ovenfor).  <q>i-45</q> betyder, at hvis <tt>cln</tt> blev overført til <q>testing</q>, 
 ville der være 45 pakker på i386 som ikke kan installeres.  Nogle af posterne
 over og under <tt>cln</tt> viser at der var 43 uinstallérbare pakker i 
-"testing" på i386, på det tidspunkt.</p>
+<q>testing</q> på i386, på det tidspunkt.</p>
 
-<p>Linien "skipped: cln (0) (150+4)" betyder at der stadig er 150 pakker som
+<p>Linjen <q>skipped: cln (0) (150+4)</q> betyder at der stadig er 150 pakker som
 skal gennemgås efter denne pakke indtil denne kontrol af alle pakker er 
 gennemført, og at 4 pakker allerede er fundet, som det ikke planlægges at 
-opgradere, fordi de ville ødelægge afhængigheder. "(0)" er irrelevant og kan
+opgradere, fordi de ville ødelægge afhængigheder. <q>(0)</q> er irrelevant og kan
 roligt ignoreres.</p>
 
 <p>Bemærk at der er flere kontroller af alle pakker i et gennemløg af 
-"testing"-skriptet.</p>
+<q>testing</q>-skriptet.</p>
 
-<p><i>Jules Bean påbegyndte indsamlingen af de ofte stillede spørgsmål med 
-svar</i>.</p>
+<p><em>Jules Bean påbegyndte indsamlingen af de ofte stillede spørgsmål med 
+svar</em>.</p>
 # Created: Sat Dec  8 12:44:29 GMT 2001
 
 <h2>Yderligere oplysninger</h2>
 
-<p>Skripterne opfanger også fejl der kan beskrives som "uhyggeligt alvorlige og
-skulle slet ikke have været her".  Disse er alle "man behøver ikke engang at
-bekymre sig om at overveje, at inkludere denne pakke"-forseelser, som 
+<p>Skripterne opfanger også fejl der kan beskrives som <q>uhyggeligt alvorlige og
+skulle slet ikke have været her</q>.  Disse er alle <q>man behøver ikke engang at
+bekymre sig om at overveje, at inkludere denne pakke</q>-forseelser, som 
 forhåbentlig vil forsvinde under frysningen, fejludryddelsesdage osv.
-<br>
+<br />
 Der findes lister over sådanne fejl vedrørende alle tre distributioner:</p>
 
 <ul>
@@ -317,11 +317,11 @@ holdt udenfor testing-distributionen.</p>
 <p>Det kan være interessant at læse en ældre 
 <a href="http://lists.debian.org/debian-devel-0008/msg00906.html">\
 forklarende e-mail</a>.  Den eneste mangel er, at den ikke tager højde for
-pakkepuljen ("package pool"), fordi denne blev implementeret af James Troup
+pakkepuljen (<q>package pool</q>), fordi denne blev implementeret af James Troup
 efter e-mail'en blev skrevet.</p>
 
 <p>Koden til testing er tilgængelig fra
 <a href="http://ftp-master.debian.org/testing/update_out_code/">\
 ftp-master</a>.</p>
 
-<p><i>Anthony Towns har stået for implementeringen af "testing".</i></p>
+<p><em>Anthony Towns har stået for implementeringen af <q>testing</q>.</em></p>