Debian GNU/Hurd
Desenvolvimento da distribuição
Empacotando software no Hurd
Os pacotes específicos do Hurd são mantidos em https://salsa.debian.org/hurd-team/.
Portando pacotes do Debian
Se você quer ajudar o porte do Debian GNU/Hurd, você deve se familiarizar com o sistema de empacotamento do Debian. Uma vez que você tenha feito isso lendo a documentação disponível e visitando o canto dos(as) desenvolvedores(as), você deve saber como extrair pacotes-fonte do Debian e construir um pacote Debian. Aqui está um curso rápido para as pessoas realmente preguiçosas:
Obtendo fontes e construindo pacotes
A obtenção de código-fonte pode ser feita ao simplesmente executar
apt source pacote
, que também vai extrair o fonte.
A extração do pacote-fonte do Debian requer o arquivo
package_version.dsc
e os arquivos listados nele. Você constrói o
diretório de construção do Debian com o comando
dpkg-source -x package_version.dsc
A construção de um pacote é feita no agora existente diretório de construção do
Debian package-version
com o comando
dpkg-buildpackage -B "-mMyName <MyEmail>"
.
Em vez de -B
, você pode usar
-b
se você também quiser construir partes do pacote
independente de arquitetura (mas isso geralmente é inútil, pois eles já estão
disponíveis no arquivo e construí-los pode exigir dependências adicionais).
Você pode adicionar -uc
para evitar a assinatura do pacote com sua
chave OpenPGP.
A construção pode requerer pacotes adicionais instalados. A forma mais simples
é executar apt build-dep pacote
, que vai instalar todos os
pacotes requeridos.
Usar o pbuilder pode ser conveniente. Ele pode ser construído com
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
e então pode-se usar pdebuild -- --binary-arch
, o que vai lidar com
o download de dependências de construção e outras coisas, e colocar o resultado
em /var/cache/pbuilder/result
Escolha um
Quais pacotes precisam ser trabalhados? Bem, cada pacote que ainda não foi portado, mas precisa ser portado. Isso muda constantemente, então é preferível se concentrar primeiro em pacotes com muitas dependências reversas, o que pode ser visto no gráfico de dependência de pacote https://people.debian.org/~sthibault/hurd-i386/graph-radial.pdf atualizado todo dia, ou na lisa de mais procurados https://people.debian.org/~sthibault/hurd-i386/graph-total-top.txt (esta é a lista de mais procurados no longo prazo, a lista de mais procurados no curto prazo é https://people.debian.org/~sthibault/graph-top.txt). Usualmente, é também uma boa ideia escolher nas listas de desatualizados https://people.debian.org/~sthibault/hurd-i386/out_of_date2.txt e https://people.debian.org/~sthibault/hurd-i386/out_of_date.txt, já que esses estavam funcionando e agora estão quebrados provavelmente devido a alguns poucos motivos. Você também pode só escolher um dos pacotes ausentes aleatoriamente, ou verificar os logs de autoconstrução na lista de discussão debian-hurd-build-logs, ou usar a lista wanna-build de https://people.debian.org/~sthibault/hurd-i386/failed_packages.txt. Alguns problemas de construção são mais fáceis de consertar que outros. Tipicamente, "undefined reference to foo" (referência não definida para foo), onde foo é algo como pthread_create, dlopen, cos, ... (o que está obviamente disponível em hurd-i386), que somente mostra que a etapa de configuração do pacote esqueceu de incluir -lpthread, -ldl, -lm, etc., também no Hurd. Note, contudo, que funções ALSA MIDI não estão disponíveis.
Além disso, verifique se o trabalho já feito feito em https://alioth.debian.org/tracker/?atid=410472&group_id=30628&func=browse, https://alioth.debian.org/tracker/?atid=411594&group_id=30628&func=browse e no BTS (https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd), e https://wiki.debian.org/Debian_GNU/Hurd, e no estado atual dos pacotes em buildd.debian.org, por exemplo, https://buildd.debian.org/util-linux.
É melhor enviar a correção do porte para o(a) próprio(a) upstream, já que é onde ela terá que entrar eventualmente; é melhor discutir diretamente com eles(as) do que por meio do mantenedor do pacote Debian. Podemos facilmente aplicar a correção como um upload para o conjunto unreleased do Debian enquanto esperamos que o patch seja lançado pelo(a) upstream e caia no Debian.
Pacotes que não serão portados
Alguns desses pacotes, ou partes deles, podem ser portados posteriormente, mas atualmente eles são considerados, no mínimo, não portáveis. Normalmente eles são marcados como NotForUs no banco de dados buildd.
-
base/makedev
, porque o Hurd vem com sua própria versão deste script. O pacote-fonte do Debian somente contém uma versão Linux específica. -
base/modconf
ebase/modutils
, porque módulos são um conceito específico ao Linux. -
base/netbase
, porque o restante das coisas que estão ali são muito específicas ao kernel Linux. O Hurd usainetutils
em vez disso. -
base/pcmcia-cs
, porque este pacote é específico ao Linux. -
base/setserial
, porque é específico ao kernel Linux. Entretanto, com o porte dos drivers de conjunto de caracteres Linux para o GNU Mach, nós poderíamos ser capazes de usá-lo.
Problemas gerais de porte
Uma lista de problemas comuns está disponível no site web do(a) autor(a) original (upstream). Os seguintes problemas comuns são específicos ao Debian.
Antes de tentar corrigir alguma coisa, verifique se no porte do kfreebsd* talvez tenha alguma correção recente, que só precisa ser estendida para o hurd-qualquer.
-
foo : Depende: foo-data (= 1.2.3-1) mas não será instalado
A resposta curta é: o pacote
foo
falhou ao construir no hurd-qualquer, e isso precisa ser corrigido, veja a falha de construção em sua página de status buildd.debian.org.Isso normalmente acontece quando o pacote
foo
atualmente falha ao construir, mas costumava construir normalmente antes. Useapt-cache policy foo foo-data
para ver que, por exemplo, a versão1.2.3-1
dofoo
está disponível e uma versão mais novafoo-data
versão2.0-1
está disponível. Isso ocorre porque no debian-ports, pacotes independentes da arquitetura (arch:all) são compartilhados entre todas as arquiteturas e, portanto, quando é feito o upload de uma versão mais nova do pacote fontefoo
(que constrói o pacotefoo
e pacotes bináriosfoo-data
), o pacote mais novo arch:allfoo-data
é instalado, mesmo se o pacote binário mais novo hurd-qualquerfoo
não pode ser construído, levando a versões incompatíveis. Corrigir isso requer fazer com que o repositório debian-ports use dak em vez de mini-dak, que ainda está sendo desenvolvido. -
alguns símbolos ou padrões desapareceram no arquivo de símbolos
Alguns pacotes mantêm uma lista dos símbolos que devem aparecer nas bibliotecas. No entanto, esta lista é geralmente obtida em um sistema Linux e, portanto, inclui símbolos que podem não fazer sentido em sistemas não Linux (por exemplo, devido a um recurso somente no Linux). No entanto, pode-se introduzir condicionais no arquivo
.symbols
, por exemplo:(arch=linux-any)linuxish_function@Base 1.23
-
Dependência quebrada do libc6
Alguns pacotes usam uma dependência errônea em
libc6-dev
. Isto está incorreto porque olibc6
é específico de algumas arquiteturas do GNU/Linux. O pacote correspondente para o GNU élibc0.3-dev
, mas outros SOs terão pacotes diferentes. Você pode localizar o problema no arquivodebian/control
da árvore-fonte. Soluções típicas incluem detectar o SO usandodpkg-architecture
e inserir no próprio código o soname, ou melhor, use um OU lógico, por exemplo:libc6-dev | libc6.1-dev | libc0.3-dev | libc0.1-dev | libc-dev
. Olibc-dev
é um pacote virtual que funciona para qualquer soname, mas você tem que colocá-lo somente como a última opção. -
undefined reference to snd_*, SND_* undeclared
Alguns pacotes usam ALSA mesmo em arquiteturas não Linux. O pacote oss-libsalsa fornece alguma emulação sobre OSS, mas é limitado à 1.0.5, e algumas funcionalidades não são fornecidas, como todas as operações de sequenciador.
Se o pacote permitir, o suporte a alsa deve ser desabilitado nas arquiteturas
!linux-any
(por exemplo, por meio de uma opçãoconfigure
), e um qualificador[linux-any]
deve ser adicionado aoBuild-Depends
do alsa, e o oposto adicionado paraBuild-Conflicts
, comoBuild-Conflicts: libasound2-dev [!linux-any]
. -
dh_install: Cannot find (any matches for) "foo" (tried in ., debian/tmp)
Isso tipicamente acontece quando o(a) autor(a) original (upstream) não instalou algo porque o SO não foi reconhecido. Algumas vezes é uma coisa besta (por exemplo, não sabe que a construção de uma biblioteca compartilhada no GNU/Hurd é exatamente como no GNU/Linux) e isso precisa de correção. Algumas vezes faz realmente sentido (por exemplo, a não instalação de arquivos de serviço systemd). Neste caso, pode-se usar dh-exec: construa a dependência em dh-exec, chmod +x o arquivo .install e prefixe as linhas problemáticas com, por exemplo, [linux-any] ou [!hurd-any].
Hackeando com o instalador do Debian
To build an ISO image, the simplest is to start from an existing one from the Hurd CD images page. You can then mount it and copy it: Para construir uma imagem ISO, o mais simples é começar a partir de uma existente na página de imagens de CD do Hurd. Você pode então montá-lo e copiá-lo:
mount debian-sid-hurd-i386-NETINST-1.iso /mnt cp -a /mnt /tmp/myimage umount /mnt chmod -R +w /tmp/myimage |
Você pode montar o disco ram inicial e, por exemplo, substituir um tradutor por sua própria versão:
gunzip /tmp/myimage/initrd.gz mount /tmp/myimage/initrd /mnt cp ~/hurd/rumpdisk/rumpdisk /mnt/hurd/ umount /mnt gzip /tmp/myimage/initrd |
Agora você pode reconstruir a iso com grub-mkrescue:
rm -fr /tmp/myimage/boot/grub/i386-pc grub-mkrescue -o /tmp/myimage.iso /tmp/myimage |