В настоящее время я пытаюсь настроить префикс Gentoo. Я взял скрипт начальной загрузки и запустил его, он прошел половину этапа и завершил установку заголовков ядра до того, как Portage сломался. Похоже, что скрипт продолжал пытаться установить еще несколько пакетов, но любая попытка вызвать emerge просто приводит к ImportError:

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

Как ни странно, есть, на самом деле, каталог на $EPREFIX/usr/lib/python2.7/site-packages/portage в комплекте с __init__.py и десяток модулей по крайней мере пару. И вызов префикса python2 напрямую с помощью -c 'import portage' прекрасно работает (попытка сделать это с помощью Python хост-системы дает ImportError). Насколько я могу судить, все должно быть с использованием префикса Python; префиксные bin находятся в начале $PATH . Возможно, что-то во внутренностях скрипта по ошибке сбрасывает или игнорирует $PATH?

2 ответа2

0

Перепроверьте свой python ! Это может быть не та версия, которую вы ожидаете. В моей системе python был связан с python3.5 , хотя у sys-apps/portage (который предоставляет пакет Python portage ) еще не было цели для Python 3.5. Argh!

На этом этапе вы не сможете пересобрать portage с разными целями (потому что emerge работает), поэтому проверьте все установленные версии Python (или покопайтесь в $EPREFIX/usr/lib/python*/site-packages) пока вы не найдете один с пакетом portage . Если у вас есть работающий eselect (я сделал), вы можете его использовать (см. eselect python help); в противном случае вы, вероятно, можете просто изменить символическую ссылку вручную. После этого Portage работал нормально для меня.


Что касается начальной загрузки Prefix… кажется, что если вы просто снова запустите скрипт в интерактивном режиме, он начнется снова, с самого начала. Я не хотел начинать все сначала, поэтому я переключился на «ручной» процесс начальной загрузки и поднялся на третьем этапе, где сценарий не удался. Я действительно не уверен, почему этот метод рекомендуется против, учитывая, что скрипт начальной загрузки выполняет всю работу, как в рекомендованном методе.

-1

Я столкнулся с той же самой кросс-компиляцией проблемов друинга для системы, основанной на руке - armv7a-hardfloat-linux-gnueabi. Проблема началась после того, как я обновил portage eix и portage-utiles. в следующий раз chroot и env-update или emerge процесс не удался с точным сообщением, отправленным выше.

Я подумал, что это должно быть связано с исполнением скрипта python и появилось python-exec из среды хоста - emerge прошел нормально, но не решил проблему. Я начал осматривать каталоги lib и понял, что из-за среды crossse-dev я получил lib64 в /usr и там в директории portage. Я объединил их с /usr /lib и сделал асимлинк из /usr /lib -> /usr /lib64. то же самое в /. описанная проблема исчезла для меня.

Я не знаю, будет ли это применимо и к вашему делу, но это может дать вам новый намек, в каком направлении искать;)

ура!

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .