CVS webwml/dutch/devel/buildd
Update of /cvs/webwml/webwml/dutch/devel/buildd
In directory gluck:/tmp/cvs-serv11455/devel/buildd
Modified Files:
index.wml operation.wml
Log Message:
Dutch translation updates
--- /cvs/webwml/webwml/dutch/devel/buildd/index.wml 2009/03/03 10:24:12 1.14
+++ /cvs/webwml/webwml/dutch/devel/buildd/index.wml 2009/05/11 22:53:54 1.15
@@ -1,5 +1,5 @@
#use wml::debian::template title="Autobuilder network" BARETITLE="true"
-#use wml::debian::translation-check translation="1.18"
+#use wml::debian::translation-check translation="1.19"
<p>Het autobuilder-netwerk is een Debian-ontwikkeling die het
hercompileren van pakketten voor alle architecturen die <a
@@ -60,17 +60,10 @@
<dd>Voedt de wanna-build database met nieuwe pakketten. Het vergelijkt
de beschikbare pakketversies voor twee architecturen en toont de
verschillen (zoals die gevonden worden na vergelijken van een Sources-
-en een Packages-bestand). Meer informatie over quinn-diff kan <a
-href="http://buildd.debian.org/quinn-diff/";>hier</a> gevonden
-worden.</dd>
-
-<dt>andrea</dt>
-<dd>Een hulpprogramma dat een aantal bron-afhankelijkheden automatisch
-genereert, en die informatie samenvoegt met afhankelijkheden die
-handmatig toegevoegd zijn.</dd>
+en een Packages-bestand).</dd>
</dl>
-<p>Al deze onderdelen <a href="operation">werken samen</a> om het
+<p>Al deze componenten <a href="operation">werken samen</a> om het
builder-netwerk te laten werken.</p>
<h2>Wat moet een Debian developer doen?</h2>
@@ -137,9 +130,6 @@
gebruiker) een autobuilder zou willen opzetten:</p>
<ul>
-<li>Om lokaal te testen of de <tt>Build-Depends</tt> van een pakket
-correct gedefiniëerd zijn (i.e., door het pakket te compileren in de
-auto-builder omgeving).</li>
<li>Om te helpen in de ontwikkeling van een port naar een gegeven
architectuur (wanneer autobuilders nodig zijn)</li>
<li>Om de impact van een gegeven compiler-optimalisatie of patch na te
@@ -159,11 +149,6 @@
arch@buildd.debian.org>, bijvoorbeeld <email
i386@buildd.debian.org>.</p>
-<p>Namen van individuele beheerders kunnen ook gevonden worden op <a
-href="http://www.buildd.net/";>www.buildd.net</a>. Kies een architectuur
-en een distributie om de beschikbare autobuilders en hun beheerders te
-zien.</p>
-
<hrline />
<p><small>Deze introductie tot het autobuilder-netwerk werd geschreven
op basis van informatie verstrekt door Roman Hodek, Christian T. Steigies,
--- /cvs/webwml/webwml/dutch/devel/buildd/operation.wml 2006/04/26 10:36:48 1.1
+++ /cvs/webwml/webwml/dutch/devel/buildd/operation.wml 2009/05/11 22:53:54 1.2
@@ -1,12 +1,12 @@
#use wml::debian::template title="Outline of operation of the autobuilder network" BARETITLE="true"
-#use wml::debian::translation-check translation="1.8" maintainer="Wouter Verhelst"
+#use wml::debian::translation-check translation="1.9"
<p>Centraal in het systeem bevindt zich de <tt>wanna-build</tt>
databank, dewelke informatie over pakketversies en -states bijhoudt.
-<tt>quinn-diff</tt> vergelijkt elke dag de pakketlijsten voor de
-doelarchitectuur tegen de lijst van bronpakketten, en stuurt een lijst
-van pakketten die gehercompileerd moeten worden in de database, waar ze
-de status <tt>needs-build</tt> krijgen.</p>
+<tt>quinn-diff</tt> vergelijkt na elke update van het archief de
+pakketlijsten voor de doelarchitectuur met de lijst van bronpakketten,
+en werkt een lijst van pakketten die opnieuw gecompileerd moeten worden
+bij in de database, waar deze de status <tt>Needs-Build</tt> krijgen.</p>
<p>Alle build daemons (er kunnen er meerdere zijn) bevragen regelmatig
de databank voor pakketten in deze status en kiezen een aantal van hen
@@ -25,27 +25,27 @@
<p>
Als alles goed gaat, dan kan een afgewerkt pakket later geuploaded
-worden, wat overeenkomt met een andere status, <tt>uploaded</tt>. Daarna
+worden, wat overeenkomt met een andere status, <tt>Uploaded</tt>. Daarna
zal het uiteindelijk geïnstalleerd worden in het Debian-archief zodat
het tevoorschijn komt in de aangepaste pakketlijst voor de
doelarchitectuur. Deze lijst wordt dan samengevoegd met de databank, en
-het pakket zal de status <tt>installed</tt> verkrijgen, waar het blijft
+het pakket zal de status <tt>Installed</tt> verkrijgen, waar het blijft
tot de volgende versie van het bronpakket verschijnt.</p>
<p>
-Er zijn verschillende andere statussen; hieronder zijn: <tt>failed</tt>,
+Er zijn verschillende andere statussen; hieronder zijn: <tt>Failed</tt>,
wat gebruikt wordt voor pakketten die niet gecompileerd konden worden
door fouten in de broncode, en waarbij verwacht wordt dat de problemen
opgelost zullen worden in een volgende versie (nadat fouten gemeld
werden, uiteraard). Zulk een nieuwe versie zal meteen
-<tt>needs-build</tt> binnengaan, maar met een waarschuwing dat iets mis
+<tt>Needs-Build</tt> binnengaan, maar met een waarschuwing dat iets mis
was met de vorige versie. Samen met deze status wordt een
-foutbeschrijving opgeslagen. De status <tt>dep-wait</tt> wordt gebruikt
+foutbeschrijving opgeslagen. De status <tt>Dep-Wait</tt> wordt gebruikt
wanneer een pakket een ander pakket nodig heeft, maar waarbij deze nog
niet beschikbaar zijn en eerst opnieuw gecompileerd moeten worden. Deze
status slaat de lijst van benodigde pakketten mee op, inclusief
eventuele versies, en wanneer ze allemaal beschikbaar zijn, wordt de
-status terug naar <tt>needs-build</tt> gezet.</p>
+status teruggezet naar <tt>Needs-Build</tt>.</p>
<p>
Zoals we al gezien hebben neemt de build daemon pakketten uit de
@@ -54,11 +54,11 @@
<tt>sbuild</tt> voor het daadwerkelijke compilatieproces, en wordt voor
elke compilatie een log naar de beheerder van de daemon gestuurd. Hij
controleert de log en beslist wat ermee gedaan moet worden: het
-uploaden, het pakket op <tt>failed</tt> of <tt>dep-wait</tt> zetten, een
-aantal zaken aan de lijst met afhankelijkheden toevoegen en opnieuw
-proberen, enz... Als een positief antwoord ontvangen wordt, dan
-verplaatst de daemon het pakket naar een upload directory, vanwaar alle
-pakketten door een cronjob geuploaded worden.</p>
+uploaden, het pakket op <tt>Failed</tt> of <tt>Dep-Wait</tt> zetten, en
+een nieuwe poging doen, enz...
+Als een positief antwoord (een gesigneerd <tt>.changes</tt> bestand</tt>)
+ontvangen wordt, dan verplaatst de daemon het pakket naar een upload directory,
+vanwaar door een cronjob alle pakketten geupload worden.</p>
<p>
Kijken naar de logbestanden is de enige menselijke interventie in het
@@ -76,26 +76,10 @@
<p>Het compilatiescript <tt>sbuild</tt> doet niet veel meer dan het
aanroepen van een aantal standaard Debian-tools om de broncode te
compileren. Het helpt ook bij een aantal standaard taken en wat
-boekhouding, maar het echt speciale ding aan <tt>sbuild</tt> zijn de
-broncode-afhankelijkheden. Dikwijls hebben pakketten andere pakketten
-nodig om gecompileerd te kunnen worden, bijvoorbeeld compilers en
-bibliotheekbestanden. Het is niet praktisch om al die pakketten ten
-allen tijde geïnstalleerd te hebben staan, en het is dikwijls zelfs niet
-mogelijk omwille van conflicten. De broncode-afhankelijkheden vertellen
-<tt>sbuild</tt> nu gewoon voor elk pakket welke andere pakketten
-benodigd zijn. Het kan ze dan automatisch installeren voor de compilatie
-uitgevoerd wordt, en ze nadien ook weer verwijderen.<p>
-
-<p>
-De lijst van broncode-afhankelijkheden kan ten dele ook automatisch
-gegenereerd worden, door naar de lijst van afhankelijkheden van de
-binaire pakketten te kijken die door de broncode gegenereerd worden. Dit
-is de taak van <tt>andrea</tt>, die de afhankelijkheden in de
-i386-pakketlijst analyseert en bibliotheek-pakketten aan namen van
-ontwikkelingspakketten koppelt. Het voegt het resultaat ook samen met
-handmatige toevoegingen voor zaken die niet automatisch gegenereerd
-kunnen worden, zoals compilers of speciale tools.</p>
+boekhouding, en met de automatische installatie van
+broncode-afhankelijkheden.</p>
<hr>
<p><small>Inhoud geschreven door Roman Hodek voor het 6e internationale
-Linux-Kongress 1999</small></p>
+Linux-Kongress 1999; in 2009 door Philipp Kern voorzichtig bijgewerkt
+om beter aan te sluiten bij de huidige realiteit</small></p>
Reply to: