path: root/swedish/devel/testing.wml

#use wml::debian::template title="Debians uttestningsutgåva" BARETITLE=true
#use wml::debian::translation-check translation="8900568ad5473cc15ea75f71f489b4f2b7ae659e"
#include "$(ENGLISHDIR)/releases/info"

<p>
För grundläggande information om uttestningsutgåvan riktad till användare,
se <a href="$(DOC)/manuals/debian-faq/ftparchives#testing">Debians frågor och svar</a>.
</p>

<p>
Det är viktigt för både vanliga användare och utvecklare av uttestningsutgåvan
att notera att säkerhetsuppdateringar för uttestningsutgåvan <strong>inte
hanteras av säkerhetsgruppen</strong>.
För ytterligare information, se
<a href="../security/faq#testing">säkerhetsgruppens frågor och svar</a>.
</p>

<p>
Denna sida täcker huvudsakligen aspekter hos uttestningsutgåvan
som är viktiga för Debianutvecklare.
</p>

<h2>Hur uttestningsutgåvan fungerar</h2>

<p>
Uttestningsutgåvan (<q lang="en">testing</q>)
genereras automatiskt.
Den skapas från den instabila utgåvan via ett antal skript vilka försöker
flytta över paket som det är rimligt att anta att de saknar
utgivningskritiska fel.
Detta görs på ett sätt som ser till att beroenden hos andra paket alltid
uppfyllda.
</p>

<p>
Ett paket (i en given version) kommer att flyttas över till uttestningsutgåvan
när det uppfyller samtliga följande kriterier:
</p>

<ol>
 <li>
  Det måste ha funnits i den instabila utgåvan under minst 10, 5 eller 2
  dagar, beroende på hur brådskande det insända paketet var;
 </li>

 <li>
  Den måste ha kompilerats och àjourförts för samtliga arkitekturer det
  tidigare har kompilerats för i den instabila utgåvan;
 </li>

 <li>
  Den får inte ha släppkritiska fel som inte redan finns i den nuvarande
  versionen i uttestningsutgåvan (se nedan för
  <a href="#faq">ytterligare information</a>);
 </li>

 <li>
  Alla dess beroenden måste <em>antingen</em> uppfyllas av paket som redan
  finns i uttestningsutgåvan, <em>eller</em> uppfyllas av den grupp paket
  som skulle installeras samtidigt;
 </li>

 <li>
  Steget att installera paketet i uttestningsutgåvan får inte resultera i att
  andra paket som redan finns där slutar fungera.
  (Se nedan för <a href="#faq">ytterligare information</a>.)
 </li>
</ol>

<p>
Ett paket som uppfyller de tre första punkterna ovan kallas en
<q lang="en">Valid Candidate</q> (<em>giltig kandidat</em>).
</p>

<p>
Uppdateringsskripten visar när varje enskilt paket kan flyttas över från den
instabila utgåvan till uttestningsutgåvan.
Dess utdata består av två delar:
</p>

<ul>
 <li>
  <a href="https://release.debian.org/britney/update_excuses.html">
  Uppdateringsursäkterna</a>
  [<a
href="https://release.debian.org/britney/update_excuses.html.gz">gzippat</a>]:
  förtecknar samtliga kandidatpakets versioner och deras generella status på
  väg in i uttestningsutgåvan; denna är något kortare och mer lättläst än
 </li>

 <li>
  <a href="https://release.debian.org/britney/update_output.txt">
  Uppdateringsutdatat</a>
  [<a href="https://release.debian.org/britney/update_output.txt.gz">gzippat</a>]:
  den kompletta, något råa utdatan från skripten för uttestningsutgåvan när
  de rekurserar genom kandidaterna
 </li>
</ul>

<h2><a name="faq" id="faq">Ofta ställda/besvarade frågor</a></h2>

# Note to translators: these two first items are almost the same as
# https://www.debian.org/doc/manuals/developers-reference/pkgs.html#faq


<h3><q>Vad är utgivningskritiska fel, och hur räknas de?</q></h3>

<p>
Alla fel som har en högre allvarlighetsgrad anses vara
<em><a href="https://bugs.debian.org/release-critical/">utgivningskritiskt</a></em>
(<em lang="en">release-critical</em>).
För närvarande gäller detta graderna
<strong lang="en">critical</strong> (kritiskt),
<strong lang="en">grave</strong> (gravt) och
<strong lang="en">serious</strong> (allvarligt).
</p>

<p>
Sådana fel anses ha betydelse för huruvida paketet kan ges ut i en stabil
utgåva av Debian: normalt sett kommer inte ett paket som har öppna kritiska
fel mot sig komma in i uttestningsutgåvan, och som en följd därav kommer det
inte heller in i den stabila utgåvan.
</p>

<p>
Antalet fel i <q>testing</q> är alla utgivningskritiska fel som är markerade
att gälla <tt>paket/versions</tt>-kombinationer som är tillgängliga i
<q>testing</q> för en utgiven arkitektur.
</p>

<h3><q>Hur kan installation av ett paket i uttestningsutgåvan få andra paket
att sluta fungera?</q></h3>

<p>
Distributionsarkiven är så strukturerade att de endast kan hantera en
version av ett paket, där paket definieras av sitt namn.
Så när källkodspaketet <tt>acmefoo</tt> installeras i uttestningsutgåvan,
tillsammans med dess binärpaket <tt>acme-foo-bin</tt>,
<tt>acme-bar-bin</tt>, <tt>libacme-foo1</tt> och <tt>libacme-foo-dev</tt>
tas den gamla versionen bort.
</p>

<p>
Den gamla versionen av paketet kan dock ha erhållit ett paket med ett
gammalt so-namn för ett paket, till exempel <tt>libacme-foo0</tt>.
Om man tar bort det gamla <tt>acmefoo</tt> försvinner <tt>libacme-foo0</tt>,
vilket gör att de paket som beror på det slutar att fungera.
</p>

<p>
Uppenbarligen påverkar detta huvudsakligen paket som erhåller en föränderlig
uppsättning paket i olika versioner (vilket i sin tur huvudsakligen gäller
bibliotek).
Det kan dock även påverka paket med versionsberoenden som har deklarerats
med operatorerna ==, &lt;= eller &lt;&lt;.
</p>

<p>
När den uppsättning binärpaket som kommer från ett källkodspaket ändras på
detta sätt måste alla paket som beror på de gamla binärerna uppdateras så
att de istället beror på de nya binärerna.
Eftersom de paket som berodde på det i uttestningsutgåvan kommer gå sönder
om man installerar ett sådant källkodspaket till den måste det göras
omsorgsfullt:
alla paket som beror på det måste uppdateras och i sig vara redo att
installeras så att de inte går sönder, och när allting är färdigt krävs
vanligtvis manuellt ingripande av utgivningsansvarige eller en assistent.
</p>

<p>
Om du har problem med komplicerade paketgrupper av det här slaget, kontakta
debian-devel eller debian-release för hjälp.
</p>

<h3><q>Jag förstår fortfarande inte! Skripten för uttestningsutgåvan säger
att paketet är en giltig kandidat, men det har fortfarande inte kommit
med.</q></h3>

<p>
Detta händer oftast när paketet, direkt eller indirekt, skulle få ett annat
paket att sluta fungera.
</p>

<p>
Kom ihåg att tänka på ditt pakets beroenden.
Säg att ditt paket beror på libtool, eller libltdl<var>X</var>.
Ditt paket kommer inte in i uttestningsutgåvan förrän rätt version av
libtool är redo att komma in.
</p>

<p>
Detta i sin tur kommer inte att ske förrän installationen av libtool kan ske
utan att andra saker i uttestningsutgåvan går sönder.
Med andra ord, tills alla paket som beror på libltdl<var>Y</var> (där
<var>Y</var> är en tidigare version) har kompilerats om och deras kritiska
fel har försvunnit, osv, kommer inget av dessa paket att kommer med i
uttestningsutgåvan.
</p>

<p>
Det är här 
<a href="https://release.debian.org/britney/update_output.txt">\
textutdatat</a>
[<a href="https://release.debian.org/britney/update_output.txt.gz">gzippat</a>]
är användbart: de ger tips (om än korthuggna) om vilka paket som kommer
sluta fungera om en giltig kandidat kommer in i uttestningsutgåvan. (Se <a
href="$(DOC)/manuals/developers-reference/pkgs.html#details">\
Utvecklarreferensen för mer information</a>).
</p>

<h3><q>Varför är det ibland svårt att få paket med <kbd>Architecture:
all</kbd> in i uttestningsutgåvan?</q></h3>

<p>
Om <kbd>Architecture: all</kbd>-paketet ska kunna installeras måste det vara
möjligt att uppfylla dess beroenden på <strong>samtliga</strong>
arkitekturer.
Om den beror på ett specifikt paket som bara kompilerar på en delmängd av
Debians arkitekturer kan inte så ske.
</p>

<p>
Uttestningsutgåvan kommer dock för närvarande att ignorera
<kbd>Architecture: all</kbd> vad gäller pakets installerbarhet på
icke-i386-arkitekturer.
(<q>Det är ett fult hack och jag är inte stolt över att ha utfört det,
men...</q> &ndash;aj)
</p>

<h3><q>Mitt paket fördröjs eftersom det inte är à jour för en viss arkitektur.
Vad kan jag göra?</q></h3>

<p>
Kontrollera status för ditt paket i
<a href="https://buildd.debian.org/build.php">databasen över byggloggar</a>.
Om paketet inte kan byggas kommer det att markeras som
<em lang="en">failed</em> (misslyckat); undersök byggloggarna och rätta de
eventuella problem som orsakas av ditt pakets källkod.
</p>

<p>
Om du upptäcker att vissa arkitekturer har byggt den nya versionen av ditt
paket men att de inte visas i utdatat från skripten för uttestningsutgåvan
behöver du bara ha lite tålamod till dess att respektive buildd-ansvariga
sänder in filerna till Debianarkivet.
</p>

<p>
Om du upptäcker att vissa arkitekturer inte har byggt den nya versionen av
ditt paket över huvud taget, trots att du sände in en rättelse för ett
tidigare fel är orsaken troligen att det markerats såsom väntande på
beroenden (<span lang="en">Dep-Wait</span>).
Du kan även se listan över de så kallade
<a href="https://buildd.debian.org/stats/">
<span lang="en">wanna-build</span>-tillstånden</a> för att försäkra dig om
det.
</p>

<p>
Dessa problem rättas för det mesta till slut, men om du väntat under en
längre tidsperiod (typ två veckor eller mer), påpeka det för respektive
anpassnings buildd-ansvarige om en sådan adress finns angiven på
<a href="$(HOME)/ports/">anpassningens webbsida</a>, eller till
anpassningens sändlista.
</p>

<p>
Om du explicit har uteslutit arkitekturen från Architecture-litsan i
control-filen och paketet tidigare har byggts för den arkitekturen måste du
be om att det gamla binärpaketet tas bort från arkivet innan ditt paket kan
komma in i uttestningsutgåvan.
Du måste sända in en felrapport mot &rdquo;ftp.debian.org&rdquo; och be om
att den uteslutna arkitekturens paket skall tas bort den instabila utgåvan.
Generellt sett bör även den relevanta anpassningens sändlista informeras av
artighetsskäl.
</p>

<h3><q>Finns det undantag? Jag är säker på att <tt>acmefoo</tt> just kom in
i uttestningsutgåvan utan att det uppfyller alla kraven.</q></h3>

<p>
Den ansvarige för utgåvorna kan åsidosätta reglerna på två sätt:
</p>

<ul>
 <li>
  Han kan bestämma att de problem som uppstår när nya paket installeras gör
  situationen bättre, inte sämre, och låta det komma in tillsammans med sin
  flottilj av beroende paket.
 </li>

 <li>
  Han kan även manuellt ta bort paket från uttestningsutgåvan som skulle
  sluta fungera, så att nya paket kan installeras.
 </li>
</ul>

<h3><q>Kan du ge ett riktigt, icke-trivialt exempel?</q></h3>

<p>
Här är ett: när källkodspaketet <tt>apache</tt> installeras i
uttestningsutgåvan tillsammans med sina binärpaket <tt>apache</tt>,
<tt>apache-common</tt>, <tt>apache-dev</tt> och <tt>apache-doc</tt> tas den
gamla versionen bort.
</p>

<p>
Alla Apachemoduler beror dock på <code>apache-common (&gt;=
<var>något</var>), apache-common (&lt;&lt; <var>något</var>)</code>, så
denna ändring förstör för samtliga dessa beroenden.
Därför måste samtliga Apachemoduler kompileras om mot den nya versionen av
Apache för att uttestningsutgåvan ska uppdateras.
</p>

<p>
Låt oss gå in på lite mer detaljer om detta: när alla moduler har uppdateras
i den instabila utgåvan så att de fungerar med Apache prövar
uttestningsskripten <tt>apache-common</tt> och upptäcker att det förstör
alla Apachemoduler eftersom de har
<code>Depends: apache-common (&lt;&lt; <var>nuvarande version</var>)</code>,
och prövar sedan <tt>libapache-<var>foo</var></tt> för att få reda på att
den inte kan installeras eftersom den har <code>Depends: apache-common
(&gt;= <var>den nya versionen</var>)</code>.
</p>

<p>
Senare kommer de dock att använda en annan sorts logik (ibland på grund av
manuellt ingripande): de kommer att ignorera det faktum att
<tt>apache-common</tt> förstör saker och fortsätta med det som fungerar; om
det fortfarande inte fungerar när vi gjort vad vi kan, så synd, men det
kanske <strong>kommer att</strong> fungera.
Senare kommer alla slumpmässiga <tt>libapache-<var>foo</var></tt>-paket att
prövas och skripten ser att de faktiskt fungerar.
</p>

<p>
När allt har prövats kontrolleras hur många paket har förstörts, beräknas om
det är bättre eller sämre än hur det var tidigare och antingen accepteras
allt eller så struntas det i.
Du ser detta i <tt>update_output.txt</tt> på raderna med
<q><code>recur:</code></q>.
</p>

<p>
Till exempel:
</p>

<pre>
     	  recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
</pre>

<p>
betyder i grund och botten att <q>efter att redan ha upptäckt att
<var>foo</var> och <var>bar</var> gör situationen bättre prövar jag nu
<var>baz</var> för att se vad som händer, även om det får saker att sluta
fungera</q>.
Raderna i <tt>update_output.txt</tt> som börjar med
<q><code>accepted</code></q> indikerar att situationen verkar bli
bättre, och <q><code>skipped</code></q>-rader gör situationen värre.
</p>

<h3><q><tt>update_output.txt</tt>-filen är helt oläslig!</q></h3>

<p>Det är inte en fråga. ;-)</p>

<p>Låt oss ta ett exempel:</p>

<pre>
 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev
</pre>

<p>
Detta betyder att om <tt>cln</tt> tas med i uttestningsutgåvan kommer
<tt>ginac-cint</tt> och <tt>libginac-dev</tt> inte att kunna installeras på
i386 i uttestningsutgåvan.
Observera att arkitekturerna kontrolleras i bokstavsordning och att bara
problem för den första arkitekturen med problem visas &ndash; det är därför
Alphaproblem förekommer så ofta.
</p>

<p>
Raden som börjar på <q>got</q> innehåller antalet problem i
uttestningsutgåvan för de olika arkitekturerna (fram till den första
arkitekturen där ett fel upptäcktes &ndash; se ovan).
<q>i-45</q> betyder att om <tt>cln</tt> tas in i uttestningsutgåvan
skulle det finnas 45 oinstallerbara paket på i386.
Några av posterna ovanför och nedanför <tt>cln</tt> visar att det fanns 43
oinstallerbara paket i uttestningsutgåvan för i386 vid den tidpunkten.
</p>

<p>
Raden <q>skipped: cln (0) (150+4)</q> betyder att det fortfarande
finns 150 paket att gå genom efter detta paket innan denna kontroll av
samtliga paket är färdig, och att fyra paket redan hittats som skripten inte
planerar att uppgradera eftersom de skulle förstöra beroenden.
<q>(0)</q> är irrelevant, så den kan du lugnt strunta i.
</p>

<p>
Observera att alla paket testas flera gånger när uttestningsskripten körs.
</p>

<p><em>Jules Bean samlade ursprungligen de ofta ställa frågorna och
svaren.</em></p>

<h2>Ytterligare information</h2>

<p>
Följande sidor innehåller ytterligare information om det aktuella
tillståndet för uttestningsutgåvan och hur paket förflyttas från den
instabila utgåvn och dit:
</p>

<ul>
<li>Statistik för binärpaket som inte är à jour för
<a href="https://release.debian.org/britney/testing_outdate.txt">testning</a>,
<a href="https://release.debian.org/britney/stable_outdate.txt">stabila</a>
</li>
<li>Beroendeproblem i
<a href="https://qa.debian.org/debcheck.php?list=INDEX&amp;dist=testing">testning</a>,
<a href="https://qa.debian.org/debcheck.php?list=INDEX&amp;dist=stable">stabila</a>
</li>
</ul>

<p>
Det kan vara intressant att läsa ett äldre
<a href="https://lists.debian.org/debian-devel-0008/msg00906.html">förklarande
e-brev</a>.
Dess enda stora fel är att den inte tar paketpoolerna i beaktning, då dessa
implementerades av James Troup efter att brevet skrevs.
</p>

<p>
Koden för uttestningsutgåvan kan hämtas från
<a href="https://release.debian.org/britney/update_out_code/">ftp-master</a>.
</p>

<p>
<em>Anthony Towns får äran för att ha implementerat uttestningsutgåvan.</em>
</p>