[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[RFR] wml://devel/buildd/wanna-build-states.wml



actualización.
--- wanna-build-states.wml.orig	2005-10-17 23:15:38.000000000 +0200
+++ wanna-build-states.wml	2005-10-17 23:44:41.000000000 +0200
@@ -1,5 +1,5 @@
 #use wml::debian::template title="Estados de Wanna-build: una explicación" BARETITLE="true"
-#use wml::debian::translation-check translation="1.11" maintainer="Fernando Cerezal"
+#use wml::debian::translation-check translation="1.15" maintainer="Fernando Cerezal"
 
     <p>Esta página intenta explicar lo que significa cada estado de 
       wanna-build y que le pasará al paquete cuando esté en ese estado.
@@ -102,13 +102,19 @@
 	encontradas. Un paquete es ese estado, automáticamente,
 	sin intervención humana, se marcará como needs-build una vez 
 	dichas dependencias estén disponibles.<br>
-	Así, hay dos casos específicos en los que puede suceder que un 
-	paquete esté marcado como dep-wait para siempre; estas son cuando
-	halla un error de escritura al especificar las dependencias en 
-	<em>dep-wait</em> (así que el paquete se marca dep-wait esperando 
-	un paquete que no existe y nunca existirá) y cuando se declara una
-	dependencia en el momento de la construcción sobre un paquete que
-	está marcado como <em>not-for-us</em>, o que está en la lista 
+	Originariamente, un paquete tenía que ver un intento de construcción 
+        antes de que el responsable lo pusiera manualmente en estado 
+        <em>dep-wait</em>. Sin embargo, en agosto de 2005 se añadió algún 
+	código a wanna-build que hará que un paquete se mueva del estado 
+        <em><a href='#installed'>installed</a></em> directamente al estado
+	<em>dep-wait</em>, si eso es lo apropiado.<br>
+	Hay dos casos específicos en los que puede suceder que un paquete
+	se marque como dep-wait para siempre; estas son cuando sucede un
+	error de mecanografía especificando las dependencias de <em>dep-wait</em> 
+	(de forma que un paquete se marca como esperando una dependencia 
+	de un paquete que no existe ni existirá) y cuando se declara una
+	dependencia de momento de construcción en un paquete que está 
+	marcado como <em>not-for-us</em>, o que está en la lista 
 	<em>packages-arch-specific</em>.<br>
 	Como último ejemplo, considere tres paquetes: un paquete
 	<tt>foo</tt>, que existe solo para <tt>i386</tt>; un paquete
@@ -231,7 +237,9 @@
        que muestra el registro de buildd</a>, el prefijo <em>maybe-</em> 
        se añade, porque entre otras cosas, el hecho de que una construcción 
        se pueda marcar <em>failed</em> ahí para cosas que <em>realmente</em>
-       no son un fallo ha causado confusión en el pasado.</p> 
+       no son un fallo ha causado confusión en el pasado (o, de otra forma,
+       a veces un paquete que aparentemente se construyó satisfactoriamente 
+       relamente está roto y hay que reconstruirlo)..</p> 
 	<p>El significado del registro de resultados es el siguiente:</p>
     <dl>
       <dt><a name="successful">successful</a></dt>

Reply to: