Provided by:
dpkg-dev_1.16.1.2ubuntu7_all 
NOMBRE
dpkg-gensymbols - Generacion de ficheros <<symbols>> (informacion de
dependencia de bibliotecas compartidas)
SINOPSIS
dpkg-gensymbols [option...]
DESCRIPCI'ON
dpkg-gensymbols analiza un arbol temporal de construccion
(<<debian/tmp>> por omision) en busca de bibliotecas para generar un
fichero symbols que los describa. Este fichero, si no esta vacio, se
instala en el subdirectorio <<DEBIAN>> del arbol de construccion, para
despues incluir el contenido en la informacion de control del paquete.
Al generar estos ficheros, usa algunos ficheros <<symbols>> como
entrada proporcionados por el desarrollador. Busca los siguientes
ficheros, usando el primero que encuentra.
o debian/package.symbols.arch
o debian/symbols.arch
o debian/package.symbols
o debian/symbols
La meta principal de estos ficheros es proporcionar la version minima
asociada a cada simbolo proporcionado por las bibliotecas.
Habitualmente, se corresponde con la primera version de ese paquete que
proporciona el simbolo, pero el desarrollador lo puede incrementar
manualmente si la ABI del simbolo se extiende sin romper la
compatibilidad con versiones anteriores. Es la responsabilidad del
desarrollador que estos ficheros esten al dia y que sean apropiados,
pero dpkg-gensymbols le asiste en esta tarea.
Cuando los ficheros <<symbols>> generados difieren del proporcionado
por el desarrollador, dpkg-gensymbols mostrara las diferencias entre
ambas versiones. Mas aun, puede que falle si la diferencia es demasiado
grande, (puede configurar cuanta diferencia tolerar, consulte la opcion
-c).
MANTENER FICHEROS <<SYMBOLS>>
Los ficheros <<symbols>> son realmente utiles solo cuando reflejan la
evolucion del paquete a lo largo de varias publicaciones. Por ello, el
desarrollador tiene que actualizarlos cada vez que se anada un simbolo
nuevo, para que asi la minima version asociada concuerde con la
realidad. Para hacer esto apropiadamente puede usar los <<diff>>
contenidos en los registros de construccion. En la mayoria de los caso,
el <<diff>> se aplica directamente sobre el fichero
<<debian/package.symbols>>. Dicho esto, es necesario afinar este
proceso: se recomienda, por ejemplo, eliminar el numero de revision de
Debian de la version minima para que asi aquellas adaptaciones hacia
atras (<<backports>>) con un numero de version menor, pero con la misma
version que la fuente original, puedan satisfacer las dependencias
generadas. Si no se puede eliminar la revision de Debian porque el
simbolo se anadio debido a un cambio especifico de Debian puede afijar
<<~>> a la version.
Antes de aplicar un parche al fichero <<symbols>> el desarrollador
deberia revisar nuevamente que es adecuado. Se espera que los simbolos
publicos no desaparezcan asi que, idealmente, el parche solo deberia
anadir lineas nuevas.
Note that you can put comments in symbols files: any line with '#' as
the first character is a comment except if it starts with '#include'
(see section Using includes). Lines starting with '#MISSING:' are
special comments documenting symbols that have disappeared.
Usar la sustituci'on de #PACKAGE#
En algunos casos aislados el nombre de la biblioteca varia segun la
arquitectura. Puede usar el marcador #PACKAGE# para evitar incrustar
(<<hardcode>>) el nombre del paquete en el fichero <<symbols>>. Se
reemplazara por el nombre real del paquete durante la instalacion de
los ficheros <<symbols>>. A diferencia del marcador #MINVER#, #PACKAGE#
nunca aparecera en un fichero <<symbols>> contenido en un paquete
binario.
Usar etiquetas de s'imbolos
El etiquetado de simbolos es util para marcar aquellos simbolos que son
de alguna manera especiales. Cada simbolo puede tener un numero
arbitrario de etiquetas asociadas a este. Aunque se analizan y guardan
todas las etiquetas, dpkg-gensymbols solo entiende algunas de ellas, e
iniciara un tratamiento especial de los simbolos. Consulte la
sub-seccion Etiquetas est'andar de s'imbolos para una referencia de estas
etiquetas.
La especificacion de la etiqueta aparece a continuacion del nombre del
simbolo (no se permite un espacio vacio entre estos). Siempre comienza
con un parentesis de apertura (, finaliza con un parentesis de cierre
), y debe contener al menos una etiqueta. Varias etiquetas se separan
con un caracter |. Opcionalmente, cada etiqueta puede tener un valor
separado del nombre de la etiqueta mediante el caracter =. Los nombres
de etiqueta y valores pueden ser cadenas arbitrarias, a excepcion de
que no pueden contener ningun caracter especial: ), | y =. Los nombres
de simbolo a continuacion de una especificacion de etiqueta se pueden
entrecomillar con caracteres ' o ", permitiendo asi espacios vacios.
Por otra parte, de no existir ninguna etiqueta definida para el
simbolo, las comillas se trataran como parte del nombre del simbolo,
continuando hasta el primer espacio.
(tag1=tengo una marca|nombre de etiqueta con espacio)"simbolo
entrecomillado y etiquetado"@Base 1.0
(optional)simbolo_sin_comillas_y_etiquetado@Base 1.0 1
simbolo_sin_etiquetar@Base 1.0
El primer simbolo del ejemplo se llama s'imbolo entrecomillado y
etiquetado, y tiene dos etiquetas: tag1, con el valor tengo una marca y
nombre de etiqueta con espacio, que no tiene valor. El segundo simbolo
se llama s'imbolo_sin_comillas_y_etiquetado, y solo tiene una etiqueta
llamada optional. El ultimo simbolo es un ejemplo de un simbolo normal
sin etiquetar.
Debido a que las etiquetas de simbolos son una extension del formato
deb-symbols(5) solo pueden formar parte de los ficheros <<symbols>> de
paquetes fuente (estos ficheros deberian aparecer como plantillas
usadas para generar los ficheros <<symbols>> integrados en paquetes
binarios). Cuando invoca dpkg-gensymbols con la opcion -t, enviara por
la salida ficheros <<symbols>> compatibles con el formato
deb-symbols(5): procesa completamente los simbolos de acuerdo a los
requerimientos de sus etiquetas estandar, y elimina todas las etiquetas
de la salida. Por otra parte, en el modo plantilla (-t), todos los
simbolos y etiquetas (estandar y desconocidos) se muestran por la
salida, y se escriben en su forma original a medida que se cargan.
Etiquetas de s'imbolo est'andar
optional
Un simbolo marcado como opcional puede desaparecer de la
biblioteca en cualquier momento sin causar un fallo de
dpkg-gensymbols. Por otra parte, los simbolos opcionales
desaparecidos apareceran continuamente como <<MISSING>>
(ausente) en el <<diff>> de cada nueva revision del paquete.
Este comportamiento sirve como un recordatorio para el
desarrollador para informar de la necesidad de eliminar tal
simbolo del fichero <<symbols>>, o de anadir este nuevamente a
la biblioteca. Cuando el simbolo opcional declarado previamente
como <<MISSING>> reaparece de subito en la siguiente revision,
se actualizara a un estado <<existente>> sin modificar la
version minima.
Esta etiqueta es util para aquellos simbolos privados cuya
desaparicion no rompe la ABI. Por ejemplo, la mayoria de
plantillas de produccion de un objeto definido mas
especificamente por medio del reemplazo de ciertas variables por
valores (<<instantiation>>) de C++ se encuentran dentro de esta
categoria. Al igual que con cualquier otra etiqueta, este puede
tener un valor arbitrario: se puede usar para indicar porque el
simbolo se considera opcional.
arch=lista-de-arquitecturas
Esta etiqueta permite limitar el conjunto de arquitecturas donde
se supone que el simbolo existe. Cuando la lista de simbolos se
actualiza con los simbolos descubiertos en la biblioteca, todos
los simbolos especificos de la arquitectura que no son
relevantes para la arquitectura anfitrion se toman como no
existentes. Si un simbolo especifico a la arquitectura que
concuerda con la arquitectura anfitrion presente no existe en la
biblioteca, se aplicaran los procedimientos normales para
simbolos desaparecidos, llevando a que dpkg-gensymbols falle.
Por otra parte, si el simbolo especifico a la arquitectura se
encuentra cuando se suponia que no existe (porque la
arquitectura anfitrion presente no esta listada en la etiqueta),
pasa a ser neutral a la arquitectura (por ejemplo, se elimina la
etiqueta de arquitectura, apareciendo el simbolo en el <<diff>>
debido a la modificacion), pero no se toma como un nuevo
simbolo.
Al operar en el modo por omision (sin plantilla) solo se
escribiran al fichero <<symbols>> aquellos simbolos especificos
a la arquitectura que coinciden con la arquitectura anfitrion.
Por otra parte, en el modo plantilla todos los simbolos
especificos a la arquitectura (incluyendo arquitecturas
alternativas) siempre se escribiran al fichero <<symbols>>.
El formato de lista-de-arquitecturas es el mismo que el usado en
el campo Build-Depends de debian/control (a excepcion de los
parentesis cuadrados de cierre <<[]>>). Por ejemplo, el primer
simbolo de la lista a continuacion se considerara solo en las
arquitecturas alpha, amd64, kfreebsd-amd64 y ia64, mientras que
el segundo en todos menos armel.
(arch=alpha amd64 kfreebsd-amd64 ia64)un_simbolo
_especifico_64bit@Base 1.0
(arch=!armel)simbolo_que_armel_no_tiene@Base 1.0
ignore-blacklist
dpkg-gensymbols tiene una lista negra interna de simbolos que no
deberian aparecer en los ficheros <<symbols>>, ya que
habitualmente son solo efectos secundarios de los detallas de
implementacion de la cadena de herramientas. Si por alguna razon
desea incluir uno de esos simbolos en el fichero <<symbols>>
deberia etiquetar el simbolo con ignore-blacklist. Puede ser
necesario con alguna cadena de herramientas de bajo nivel como
libgcc.
c++ Denota el patron c++- Consulte la subseccion a continuacion Usar
patrones de s'imbolos.
symver Denota el patron de simbolos symver (version del simbolo).
Consulte la sub-seccion a continuacion Usar patrones de
s'imbolos.
regex Denota el patron de simbolos regex (expresion regular). Consulte
la sub-seccion a continuacion Usar patrones de s'imbolos.
Usar patrones de s'imbolos.
A diferencia de cualquier definicion de simbolo estandar un patron
puede cubrir varios simbolos reales de la biblioteca. dpkg-gensymbols
intentara emparejar cada patron con cada simbolo real que no tiene un
simbolo especifico de contrapartida definido en el fichero de simbolos.
En el momento que se encuentre el primer patron que coincida se usaran
todas sus etiquetas y propiedades como un definicion basica del
simbolo. Si ninguno de los patrones encaja, el simbolo se considerara
nuevo.
Un patron se considera perdido si no encaja con ningun simbolo en la
biblioteca. Por omision, esto accionara un fallo de dpkg-gensymbols
bajo -c1 o un nivel superior. Aun asi, si no desea la aparicion del
fallo, puede marcar el patron con la etiqueta optional. Entonces, si el
patron no encaja con nada simplemente aparecera en el <<diff>> como
<<MISSING>>. Aun mas, al igual que con cualquier simbolo, puede limitar
el patron a unas arquitecturas definidas con la etiqueta arch. Consulte
la seccion anterior Etiquetas de s'imbolo est'andar.
Los patrones son una extension del formato deb-symbols(5), y por ello
solo son validos en plantillas de fichero de simbolos. Por otra parte,
la parte del nombre del simbolo definido sirve como una expresion que
se comparara con el nombre@versi'on del simbolo real. Para poder
distinguir entre los diferentes tipos de patron, este se etiquetara
habitualmente con una etiqueta especial.
A dia de hoy, dpkg-gensymbols es compatible con tres tipos de patrones
basicos:
c++
Este patron se indica con la etiqueta c++. Solo encaja con el nombre
<<demangled>> de simbolos C++ (tal y como muestra la herramienta
c++filt(1)). Este patron es de utilidad para emparejar simbolos con
nombres <<mangled>> que pueden variar segun la arquitectura,
mientras que sus nombres <<demangled>> permanecen sin cambios. Un
grupo de estos simbolos son los thunk no virtuales, que tienen
direcciones relativas (<<offsets>>) especificas a la arquitectura
integradas en sus nombres <<mangled>>. Un ejemplo comun de este caso
es un destructor virtual, que bajo una herencia de diamante necesita
un simbolo thunk no virtual. Por ejemplo, incluso si
<<_ZThn8_N3NSB6ClassDD1Ev@Base>> en arquitecturas de 32bit es
<<_ZThn16_N3NSB6ClassDD1Ev@Base>> en arquitecturas de 64bit, puede
emparejarlo con un unico patron c++:
libdummy.so.1 libdummy1 #MINVER#
[...]
(c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
[...]
Puede obtener el nombre <<demangled>> del ejemplo anterior
ejecutando la siguiente orden:
$ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt
Observe que aunque el nombre <<mangled>> sea por definicion unico en
la biblioteca, no es necesariamente cierto para nombres
<<demangled>>. Puede que dos simbolos reales y distintos tengan el
mismo nombre <<demangled>>. Por ejemplo, en caso de existir simbolos
thunk no virtuales en complejas configuraciones de herencia, o con
la mayoria de constructores y destructores (ya que habitualmente g++
genera dos simbolos para ellos). Por otra parte, estas colisiones
aparecen al nivel de la ABI, y por ello no deberian degradar la
calidad del fichero de simbolos.
symver
La etiqueta symver indica este patron. Las bibliotecas bien
mantenidas tienen simbolos con version, donde cada version
corresponde con la version del autor original en la que se anadio el
simbolo. De ser asi, puede usar un patron symver para emparejar el
simbolo asociado con una version en particular. Por ejemplo:
libc.so.6 libc6 #MINVER#
(symver)GLIBC_2.0 2.0
[...]
(symver)GLIBC_2.7 2.7
access@GLIBC_2.0 2.2
Todos los simbolos asociados con las versiones <<GLIBC_2.0>> y
<<GLIBC_2.7>> llevan a una version minima de 2.0 y 2.7
respectivamente, con la excepcion del simbolo <<access@GLIBC_2.0>>.
El segundo lleva a una dependencia minima sobre la version 2.2 de
libc6, a pesar de estar en el rango del patron
<<(symver)GLIBC_2.0>>, debido a que los simbolos especificos tiene
precedencia sobre los patrones.
Tenga en cuanta que los patrones de comodin antiguos (indicados por
<<*@versio>> en el campo del nombre del simbolo) son aun
compatibles, aunque han quedado obsoletos por el nuevo estilo de
sintaxis <<(symver|optional)version>>. Por ejemplo, deberia escribir
<<*@GLIBC_2.0 2.0>> como <<(symver|optional)GLIBC_2.0 2.0>> si desea
el mismo comportamiento.
regex
Los patrones de expresiones regulares se indican con la etiqueta
regex. Buscan coincidencias con la expresion regular de perl
definido en el campo de nombre del simbolo. Una expresion regular se
empareja tal cual, por ello no olvide insertar ^ al inicio de la
misma o puede que coincida con cualquier parte de la cadena real del
simbolo nombre@versi'on. Por ejemplo:
libdummy.so.1 libdummy1 #MINVER#
(regex)"^mystack_.*@Base$" 1.0
(regex|optional)"private" 1.0
Los simbolos como <<mystack_new@Base>>, <<mystack_push@Base>>,
<<mystack_pop@Base>> y similares encajarian con el primer patron,
mientras que otros como <<ng_mystack_new@Base>> no lo harian. El
segundo patron encaja con todos los simbolos con <<private>> en su
nombre, y las coincidencias heredaran de este patron la etiqueta
optional.
Puede combinar los patrones listados anteriormente, cuando tenga
sentido. En tal caso, se procesan en el orden de las etiquetas
definidas. Por ejemplo, ambos
(c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0
(regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0
encaja con <<_ZN3NSA6ClassA7Private11privmethod1Ei@Base>> y
<<_ZN3NSA6ClassA7Private11privmethod2Ei@Base>>. Al comparar el primer
patron se <<demangle>> el simbolo sin procesar como simbolo C++, para
despues comparar el nombre <<demangled>> con la expresion regular. Por
otra parte, al comparar el segundo patron la expresion regular se
compara con el nombre sin procesar del simbolo, para despues confirmar
si es un simbolo de C++ mediante <<demangle>>. Un fallo de un patron
basico lleva a un fallo de todo el patron. Por ejemplo,
<<__N3NSA6ClassA7Private11privmethod\dEi@Base>> no encajaria con ningun
patron porque no es un simbolo valido de C++.
En general, todos los patrones se dividen en dos grupos: aliases (los
basicos c++ y symver) y patrones genericos (regex, todas las
combinaciones de varios patrones basicos). Establecer coincidencias con
patrones basados en alias es rapido (0(1)) mientras que los patrones
genericos son 0(N) (N - cuenta generica del patron) para cada simbolo.
Debido a ello, se recomienda no abusar de los patrones genericos.
Los alias (primero c++, despues symver) tienen prioridad sobre los
patrones genericos. Estos se emparejan por orden de aparicion en la
plantilla del fichero de simbolos hasta el primer resultado de exito.
Tenga en cuenta, no obstante, que no se recomienda la reorganizacion
manual de las entradas en plantillas de fichero ya que dpkg-gensymbols
genera <<diffs>> basados en el orden alfanumerico de sus nombres.
Usar <<include>>
Hay casos en los que usar un solo fichero de simbolos es
contraproducente cuando el conjunto de simbolos exportados difiere
segun la arquitectura. En estos casos, una directiva <<include>> puede
ser util de un par de maneras:
o Puede factorizar la parte comun en algun fichero externo, e incluir
ese fichero en su fichero paquete.symbols.arq usando una directiva
<<include>> como esta:
#include "packages.symbols.common"
o Al igual que con cualquier simbolo, puede etiquetar la directiva
<<include>>:
(tag|..|tagN)#include "file-to-include"
As a result, all symbols included from file-to-include will be
considered to be tagged with tag .. tagN by default. You can use
this feature to create a common package.symbols file which includes
architecture specific symbol files:
common_symbol1@Base 1.0
(arch=amd64 ia64 alpha)#include "package.symbols.64bit"
(arch=!amd64 !ia64 !alpha)#include "package.symbols.32bit"
common_symbol2@Base 1.0
Los ficheros de simbolos se leen linea a linea, y las directivas
<<include>> se procesan por orden de aparicion. Esto significa que el
contenido del fichero incluido puede sustituir cualquier contenido
aparecido antes de la directiva <<include>>, y que todo contenido a
continuacion de la directiva puede sustituir cualquier contenido del
fichero incluido. Todo simbolo (o incluso otra directiva <<#include>>)
en el fichero incluido puede especificar etiquetas adicionales, o
sustituir valores de las etiquetas heredadas en la especificacion de
etiqueta. Por otra parte, el simbolo no puede eliminar ninguna de las
etiquetas heredadas.
Un fichero incluido puede repetir la linea de cabecera que contiene el
<<SONAME>> de la biblioteca. En tal caso, sustituye cualquier linea de
cabecera leida anteriormente. Por otra parte, generalmente es mejor
evitar duplicar las lineas de cabecera. A continuacion puede ver una
manera de realizar esto:
#include "libsomething1.symbols.common"
arch_specific_symbol@Base 1.0
Buena gesti'on de bibliotecas
Una biblioteca mantenida adecuadamente tiene las siguientes
caracteristicas:
o su API es estable (los simbolos publicos nunca se eliminan, sino
que solo se anaden simbolos nuevos), y los cambios pueden
introducir una incompatibilidad solo cuando el <<SONAME>> cambia;
o Idealmente, usa el versionado de simbolos para alcanzar la
estabilidad de la ABI, a pesar de cambios internos y la extension
de la API;
o No exporta simbolos privados (tales como simbolos etiquetados como
opcionales para evitar un problema).
Al mantener un fichero <<symbols>> es sencillo notar la aparicion y
desaparicion de simbolos. Pero es mas dificil notar cambios
incompatibles en las API y ABI. Por ello, el responsable del paquete
deberia leer cuidadosamente el registro de cambios de la fuente
original en busca de casos en los que se ha roto la correcta gestion de
bibliotecas. Se deberia notificar al autor original en caso de
encontrar problemas potenciales, ya que un arreglo en la fuente
original del software es siempre preferible a un arreglo especifico de
Debian.
OPCIONES
-Pdirectorio-compilaci'on-paquete
Analiza directorio-compilaci'on-paquete en lugar de
<<debian/tmp>>.
-ppaquete
Define el nombre del paquete. Es necesario si aparece mas de un
paquete binario en <<debian/control>> (o si no existe ningun
fichero <<debian/control>>).
-vversi'on
Define la version del paquete. El valor por omision es la
version extraida de <<debian/changelog>>. Necesario en caso de
una invocacion externa al arbol del paquete fuente.
-efichero-biblioteca
Solo analiza las bibliotecas listadas explicitamente, en lugar
de buscar todas las bibliotecas publicas. Puede usar una
expresion regular en fichero-biblioteca para emparejar varias
bibliotecas con un unico argumento (de otra forma, necesita
varias -e).
-Inombre-fichero
Usa nombre-fichero como un fichero de referencia para generar el
fichero <<symbols>> integrado en el mismo paquete.
-O Muestra por la salida estandar el fichero <<symbols>> generado,
en lugar de almacenarlo en el arbol de construccion del paquete.
-Ofichero
Guarda el fichero de simbolos generado como fichero. Si el
fichero ya existe su contenido se usara como base para el
fichero <<symbols>> generado. Puede usar esta caracteristica
para actualizar un fichero <<symbols>> para que coincida con una
version mas reciente de la biblioteca del autor original.
-t Escribe el fichero <<symbols>> en modo plantilla en lugar del
formato compatible con deb-symbols(5). La diferencia mas notable
es que en modo plantilla los nombres de simbolo y etiquetas se
escriben en su forma original, en lugar de los nombres de
simbolo post-procesados con las etiquetas eliminadas en modo
compatible. Ademas, puede que se omitan algunos simbolos al
escribir un fichero estandar de deb-symbols(5) (de acuerdo a las
reglas de procesamiento de etiquetas), mientras que siempre se
insertan todos los simbolos en el modo plantilla.
-c[0-4]
Define las comprobaciones a realizar al comparar el fichero
<<symbols>> generado usando como base el fichero de plantilla.
El nivel predefinido es 1. Aumentar los niveles conlleva mas
comprobaciones, asi como la inclusion de todos los niveles
inferiores. El nivel 0 nunca falla. El nivel 1 falla si algunos
simbolos han desaparecido. El nivel 2 falla si se han
introducido simbolos nuevos. El nivel 3 falla si han
desaparecido algunas bibliotecas. El nivel 4 falla si se han
introducido bibliotecas nuevas.
Puede sustituir este valor con la variable de entorno
<<DPKG_GENSYMBOLS_CHECK_LEVEL>>.
-q No muestra informes y nunca genera un <<diff>> entre el fichero
<<symbols>> generado y el fichero de plantilla tomado como base,
ni muestra ningun aviso relativo a bibliotecas nuevas o
ausentes, o simbolos nuevos o ausentes. Esta opcion solo
desactiva la salida informativa, pero no las comprobaciones
(consulte la opcion -c).
-aarquitectura
Toma arquitectura como la arquitectura anfitrion al procesar
ficheros <<symbols>>. Use esta opcion para generar un fichero
<<symbols>> o un <<diff>> para cualquier arquitectura, siempre y
cuando sus binarios ya esten disponibles.
-d Activa el modo de depuracion. Se muestran numerosos mensajes que
explican las acciones de dpkg-gensymbols.
-V Activa el modo verboso. El fichero <<symbols>> generado contiene
simbolos obsoletos en la forma de comentarios. Ademas, en modo
plantilla los patrones de simbolo anteceden a los comentarios
que listan los simbolos reales que coinciden con el patron.
-h, --help
Muestra el modo de uso y termina.
--version
Muestra la version y termina.
V'EASE TAMBI'EN
http://people.redhat.com/drepper/symbol-versioning
http://people.redhat.com/drepper/goodpractice.pdf
http://people.redhat.com/drepper/dsohowto.pdf
deb-symbols(5), dpkg-shlibdeps(1).
AUTORES
Copyright (C) 2007-2009 Raphael Hertzog
Esto es software libre; vea la version 2 o posterior de la Licencia
Publica General GNU para condiciones de copia. NO hay ninguna garantia.
TRADUCTOR
Rudy Godoy <rudy@kernel-panik.org>, Ruben Porras <nahoo@inicia.es>,
Bruno Barrera C. <bruno.barrera@igloo.cl>, Carlos Izquierdo
<gheesh@ertis.net>, Esteban Manchado y NOK. Debian L10n Spanish
<debian-l10n-spanish@lists.debian.org>.
Revisiones por Santiago Vila <sanvila@unex.es>, Javier
Fernandez-Sanguino, Ruben Porras, Luis Uribe y Omar Campagne.