Nota: La página original es más nueva que esta traducción.
Debian GNU/Hurd
Desarrollo de la distribución
Empaquetado de software Hurd
Los paquetes específicos de Hurd se mantienen en https://salsa.debian.org/hurd-team/.
Adaptar paquetes de Debian
Si quiere ayudar con la arquitectura GNU/Hurd, debería familiarizarse con el sistema de empaquetado de Debian. Una vez que lo haya hecho, leyendo la documentación disponible y visitando el Rincón de los Desarrolladores debería saber cómo extraer los fuentes de los paquetes de Debian y compilar un paquete Debian. He aquí un curso acelerado para los muy perezosos:
Obtener el código fuente y construir paquetes
Se puede obtener el código fuente simplemente ejecutando apt source
package
, que también extraerá los fuentes.
Para extraer el contenido de un paquete de fuentes de Debian se necesita
el fichero
package_version.dsc
y los ficheros listados en él. El
directorio de compilación de Debian se construye con la orden
dpkg-source -x package_version.dsc
La construcción de un paquete se lleva a cabo en el nuevo directorio de construcción de Debian
package-version
con la orden
dpkg-buildpackage -B -rsudo "-mMiNombre <MiCorreo>"
.
En lugar de -B
se puede usar
-b
si también quiere construir las partes del paquete que
son independientes de la arquitectura (aunque esto normalmente resulta inútil puesto que ya están
disponibles en el archivo y construirlas puede requerir dependencias
adicionales). Puede utilizar
-uc
para evitar firmar el paquete con su clave pgp.
La construcción puede necesitar que se instalen paquetes adicionales.
La manera más sencilla es ejecutar apt build-dep package
,
que instalará todos los paquetes necesarios.
Puede ser conveniente usar pbuilder. Se puede construir con
sudo pbuilder create --mirror http://deb.debian.org/debian-ports/ --debootstrapopts --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --debootstrapopts --extra-suites=unreleased --extrapackages debian-ports-archive-keyring
y entonces se puede usar pdebuild -- --binary-arch
que gestionará la descarga de las dependencias, etc. y colocará el resultado en /var/cache/pbuilder/result
Escoja uno
¿En qué paquetes se necesita trabajar? Bien, cualquiera que aún no haya sido adaptado, y lo necesite. Esto cambia de forma constante, de manera que es preferible concentrarse primero en paquetes que tengan muchas dependencias inversas, lo que puede verse en el gráfico de dependencias de paquetes https://people.debian.org/~sthibault/graph-radial.pdf que se actualiza cada día, o en la lista de más solicitados https://people.debian.org/~sthibault/graph-total-top.txt (ésta es la de más solicitados a largo plazo, la de más solicitados a corto plazo es https://people.debian.org/~sthibault/graph-top.txt). También suele ser buena idea escoger de la lista de desactualizados https://people.debian.org/~sthibault/out_of_date2.txt y https://people.debian.org/~sthibault/out_of_date.txt, ya que esos solían funcionar, y ahora están rotos probablemente solo por un par de razones. Puede simplemente escoger uno de los paquetes que faltan de manera aleatoria, o mirar los registros de autoconstrucción en la lista de correo debian-hurd-build-logs, o usar la lista wanna-build de https://people.debian.org/~sthibault/failed_packages.txt . Algunos problemas de construcción son más fáciles de corregir que otros. Típicamente, "undefined reference to foo", donde foo es algo como pthread_create, dlopen, cos, ... (que obviamente están disponibles en hurd-i386), que solamente muestra que el paso de configuración del paquete olvidó incluir -lpthread, -ldl, -lm, etc. en el Hurd también. Tenga en cuenta sin embargo que las funciones ALSA MIDI no está disponible.
También, compruebe si ya se ha realizado trabajo en https://alioth.debian.org/tracker/?atid=410472&group_id=30628&func=browse, https://alioth.debian.org/tracker/?atid=411594&group_id=30628&func=browse, y el BTS (https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd), y https://wiki.debian.org/Debian_GNU/Hurd, y el estado de los paquetes en vivo en buildd.debian.org, p.ej. https://buildd.debian.org/util-linux.
Paquetes que no van a ser adaptados
Algunos de estos paquetes, o partes de ellos, podrían ser adaptables más adelante, pero, al menos actualmente, se consideran inadaptables. Normalmente se marcan como NotForUs en la base de datos de buildd.
-
base/makedev
, porque el Hurd viene con su propia versión de este guión. El paquete de fuentes de Debian sólo contiene una versión específica para Linux. -
base/modconf
ybase/modutils
, porque el concepto de módulo es específico de Linux. -
base/netbase
, porque el resto de cosas que hay en él es muy específico del núcleo Linux. El Hurd, en su lugar, utilizainetutils
. -
base/pcmcia-cs
, porque este paquete es específico para Linux. -
base/setserial
, porque es específico para el núcleo de Linux. Sin embargo, con la adaptación de los gestores de dispositivos de caracteres al Mach de GNU, quizá podamos utilizarlo.
Generalidades de la adaptación
Se puede encontrarUna lista de asuntos comunes en el sitio web del proyecto original. Los siguientes asuntos comunes son específicos de Debian.
Antes de arreglar algo, compruebe si la adaptación kfreebsd* quizá ya tiene un arreglo, y simplemente se debe extender a hurd-i386.
-
foo : Depende: foo-data (= 1.2.3-1) pero no va a instalarse
La respuesta breve es: ha fallado la compilación del paquete
foo
en hurd-i386, lo que debe corregirse. Vea cuál es el fallo de compilación es su página de estado en buildd.debian.org.Esto ocurre típicamente cuando la compilación del paquete
foo
falla en la actualidad, pero solía ir bien antes. Useapt-cache policy foo foo-data
para ver que, por ejemplo, están disponibles la versión1.2.3-1
defoo
y una versión más reciente defoo-data
:2.0-1
. Esto se debe a que, en debian-ports, los paquetes independientes de la arquitectura (arch:all) se comparten entre todas las arquitecturas y, por lo tanto, cuando se sube una versión más reciente del paquete fuentefoo
(del cual se generan los paquetes binariosfoo
yfoo-data
), se instala el paquete más reciente arch:allfoo-data
, aunque el paquete binario hurd-i386foo
más reciente no compile, dando lugar a versiones incompatibles. La corrección de esto pasa por hacer que el archivo de debian-ports utilize dak en lugar de mini-dak, lo cual es todavía un trabajo en curso. -
han desaparecido del fichero de símbolos algunos símbolos o patrones
Algunos paquetes mantienen una lista de los símbolos que se espera que aparezcan en bibliotecas. Sin embargo, esta lista se obtiene habitualmente en un sistema Linux y, por lo tanto, incluye símbolos que pueden no tener sentido en sistemas no Linux (por ejemplo, relacionados con una funcionalidad exclusiva de Linux). Ahora bien, se pueden incluir condicionales en el fichero
.symbols
, por ejemplo:(arch=linux-any)linuxish_function@Base 1.23
-
Dependencia con libc6 rota
Algunos paquetes dependen erróneamente de
libc6-dev
. Esto es incorrecto porquelibc6
es específica a algunas arquitecturas de GNU/Linux. El correspondiente paquete para GNU eslibc0.3-dev
pero otros Sistemas Operativos tendrán otras diferentes. Puede localizar el problema en el ficherodebian/control
en el árbol de código fuente. Soluciones típicas son detectar el SO usandodpkg-architecture
e insertando en el código el soname, o mejor, usar un OR lógico. P.ej.:libc6-dev | libc6.1-dev | libc0.3-dev | libc0.1-dev | libc-dev
. El paquetelibc-dev
es un paquete virtual que funciona para cualquier soname pero tiene que ponerlo sólamente como última opción. -
referencia no definida a snd_*, SND_* no declarado
Algunos paquetes usan ALSA incluso en arquitecturas no-Linux. El paquete oss-libsalsa proporciona alguna emulación sobre OSS, pero está limitado a 1.0.5, y no se proporcionan algunas características, como las operaciones de secuenciador.
Si el paquete lo permite, el soporte de alsa debería deshabilitarse en las arquitecturas
!linux-any
(p.ej. a través de una opciónconfigure
), y añadir un cualificador[linux-any]
alBuild-Depends
de alsa, y el añadir el opuesto aBuild-Conflicts
, comoBuild-Conflicts: libasound2-dev [!linux-any]
. -
dh_install: no se encuentra (nada que concuerde con) "foo" (se ha intentado en debian/tmp)
Esto ocurre típicamente cuando el proyecto original no instaló algo porque no reconoció el sistema operativo. A veces es algo tonto (p.ej. no sabe que construir una biblioteca compartida en GNU/Hurd es exactamente igual que en GNU/Linux) y eso necesita una corrección. A veces tiene sentido, de hecho (p.ej. no instalar los archivos de servicios de systemd). En ese caso, uno puede usar dh-exec: haciendo depender la construcción de dh-exec, hacer chmod +x en el archivo .install, y encabezar las líneas problemáticas con p.ej. [linux-any] o [!hurd-any].
Modificación del instalador de Debian
Para generar una imagen ISO, lo más sencillo es partir de una imagen preexistente de las incluidas en la página de imágenes de CD de Hurd. A continuación, puede montarla y copiarla:
mount debian-sid-hurd-i386-NETINST-1.iso /mnt cp -a /mnt /tmp/myimage umount /mnt chmod -R +w /tmp/myimage |
Puede montar el disco RAM inicial, y, por ejemplo, reemplazar un traductor por una versión preparada por usted:
gunzip /tmp/myimage/initrd.gz mount /tmp/myimage/initrd /mnt cp ~/hurd/rumpdisk/rumpdisk /mnt/hurd/ umount /mnt gzip /tmp/myimage/initrd |
Ahora puede generar la nueva imagen ISO con grub-mkrescue:
rm -fr /tmp/myimage/boot/grub/i386-pc grub-mkrescue -o /tmp/myimage.iso /tmp/myimage |