Por que o Portage reclama por falta de um módulo Python 'portage'?

0

Atualmente, estou tentando configurar um prefixo do Gentoo. Eu peguei o script de bootstrap e rodei-o, e ele ficou no estágio três e terminou de instalar os cabeçalhos do kernel antes do Portage quebrar. Parece que o script tentou instalar mais alguns pacotes, mas qualquer tentativa de invocar emerge resulta em ImportError :

Traceback (most recent call last):
  File "$EPREFIX/usr/bin/emerge", line 41, in <module>
    import portage
ImportError: No module named 'portage'

Curiosamente, é , na verdade, um diretório em $EPREFIX/usr/lib/python2.7/site-packages/portage , completo com __init__.py e pelo menos algumas dúzias de módulos. E invocar o prefixado python2 diretamente com -c 'import portage' funciona muito bem (tentando que com o Python do sistema host dê esse ImportError ). Até onde posso dizer, as coisas deveriam estar usando o prefixo Python; os bin s prefixados estão na frente de $PATH . Talvez algo nos componentes internos do script esteja redefinindo ou ignorando $PATH ?

    
por Blacklight Shining 11.02.2016 / 14:10

2 respostas

0

Verifique novamente seu python ! Pode não ser a versão que você espera. No meu sistema, python foi linkado simbolicamente para python3.5 , mesmo que sys-apps/portage (que fornece o pacote portage Python) ainda não tivesse um destino para o Python 3.5. Argh!

Nesse ponto, você não poderá recompilar portage com destinos diferentes (porque emerge está corrompido), portanto, verifique todas as versões do Python instaladas (ou procure por $EPREFIX/usr/lib/python*/site-packages ) até encontrar um com um pacote portage . Se você tem um eselect de trabalho (eu fiz), você pode usá-lo (ver eselect python help ); senão, você pode provavelmente escapar apenas alterando manualmente o symlink. Portage funcionou bem para mim depois disso.

Quanto ao bootstrap de prefixo… parece que se você simplesmente executar o script interativamente novamente, ele começará tudo de novo, desde o começo. Eu não queria começar de novo, então mudei para o processo de bootstrap "manual" e peguei no terceiro estágio, onde o script falhou. Eu realmente não tenho certeza porque este método é recomendado contra, dado que o script de bootstrapping faz todo o trabalho, assim como no método recomendado.

    
por 11.02.2016 / 14:10
-1

Eu encontrei o mesmo problema com a compilação cruzada de um sistema baseado em braços - armv7a-hardfloat-linux-gnueabi. O problema começou depois que eu atualizei o portage eix e o portage-utiles. na próxima vez, chrooting e env-update ou emerge o processo com a mensagem exata postada acima.

Eu pensei, ele deve estar relacionado ao executrion do script python e emergiu python-exec do ambiente host - emerge correu bem, no entanto, não resolveu o problema. Eu estive procurando nos diretórios lib e percebi que, devido ao ambiente crosse-dev, eu obtive uma lib64 em / usr e lá uma diretora de portage. Eu os fundei com o / usr / lib e fiz o asymlink de / usr / lib - > / usr / lib64. o mesmo sob /. o problema descrito desapareceu para mim.

Eu não sei se isso vai se aplicar ao seu caso também, mas pode dar uma nova dica para você procurar:)

aplausos!

    
por 27.03.2016 / 16:44