[SOLVED] Проблемы с portage (emerge)

Даже с пёрлом почти не знаком, тока с PHP! =))) У меня совпали номера строк по трассировке из исходного поста на 100% - это соотвествует sys-apps/portage-2.1.4.5. Я предложил вывод потому что он может навести Вас на мысль:

# grep -B20 -A2 'cPickle.dump(self._cache_data, f, -1)' /usr/bin/emerge
        def flush(self):
                """If the current user has permission and the internal blocker cache
                been updated, save it to disk and mark it unmodified.  This is called
                by emerge after it has proccessed blockers for all installed packages.
                Currently, the cache is only written if the user has superuser
                privileges (since that's required to obtain a lock), but all users
                have read access and benefit from faster blocker lookups (as long as
                the entire cache is still valid).  The cache is stored as a pickled
                dict object with the following format:

                {
                        version : "1",
                        "blockers" : {cpv1:(counter,(atom1, atom2...)), cpv2...},
                        "virtuals" : vardb.settings.getvirtuals()
                }
                """
                if self._modified and \
                        secpass >= 2:
                        try:
                                f = portage_util.atomic_ofstream(self._cache_filename)
                                cPickle.dump(self._cache_data, f, -1)
                                f.close()
                                portage_util.apply_secpass_permissions(

Особенно интересен комментарий сверху. Я думал он и наведёт Вас на мысль. Теперь о сути исходной проблемы... В первом листинге ниже - как этот пиклер подключается:

# grep -B1 'cPickle' /usr/bin/emerge | head -n5
try:
        import cPickle
except ImportError:
        import pickle as cPickle
--

# locate pickle|grep -E '/pickle\.py$'
/usr/lib32/openoffice/program/python-core-2.3.4/lib/pickle.py
/usr/lib64/python2.5/pickle.py

# head /usr/lib64/python2.5/pickle.py
"""Create portable serialized representations of Python objects.

See module cPickle for a (much) faster implementation.
See module copy_reg for a mechanism for registering custom picklers.
See module pickletools source for extensive comments.

Теперь всё становится совсем понятным. Особенно, если сравнить различающийся между нами вывод ls -l /var/cache/edb/ ;-) Задача пиклера - управлять сериализованным словарём, в данном случае - в этой директории. Проблема видимо как раз таки с правами (владельцем) на директорию / файлы в ней. У Вас почему-то два питона. Попробуйте забэкапить и прибить "ускоренный" пиклер - т.е. вот эти два файла: /usr/lib/python2.4/lib-dynload/cPickle.so и /usr/lib/python2.5/lib-dynload/cPickle.so, проверить по симлинкам/окружению, который из питонов активен. Далее, я так понял, можно очистить кэш /var/cache/edb/.

Ещё заметил, что у меня владельцем /var/lib/portage/world является root. И ещё замечу, что в моём варианте пиклер не содержит строки вида raise PicklingError("Can't pickle %r attribute lookup..."), следовательно, раз файл относится к питону 2.5, значит у Вас отрабатывает питоновский пиклер от версии 2.4. Возможно ещё решение восстановления питона из бинарного пакета. Надеюсь, это поможит обуздать взбесившийся портеж без переустановки!.. =)))

Выше я привёл не вариант лечения, а один из вариантов воспроизведения похожей ошибки, извиняюсь! =)))

Запости где нить что содержится в /var/db/pkg/sys-devel/libperl-*/SLOT
Похоже там что то битое

В операции участвует дерево портежей, сам портеж, питон, ну может ещё в какой-то степени glibc/ядро. Если контрольная сумма снэпшота дерева портежей после скачивания совпала, конечно мог tar/bzip сглючить. ИМХО, можно проверить без перезагрузки, создав небольшой файл (dd), смонтировав его через mount --loop, далее по хендбуку развернуть в новый раздел стейдж и снэпшот, сделать чрут и там уже позапускать emerge. Только чтобы не было привязки к glibc родительской системы, лучше экспериментировать со stage1. Если проблем не будет, тогда дело действительно не в памяти.