В /usr/lib/python2.6/site-packages/logilab/common/modutils.py написано STD_LIB_DIR = join(sys.prefix, 'lib', 'python%s' % sys.version[:3]), что, вероятно, не совсем правильно. Из-за этого на x86_64 не проходит тест test/unittest_modutils.py::test_knownValues_is_standard_module_4 (ищет StringIO в STD_LIB_DIR).
Насколько приемлем будет такой вариант? http://git.altlinux.org/people/real/packages/python-module-logilab-common.git?p=python-module-logilab-common.git;a=commitdiff;h=33ef3a2a77d2814381d9489e73e2eee283f80163 Ничего не сломает? А то ведь сам logilab лежит не в /usr/lib64, а в /usr/lib.
(В ответ на комментарий №1) > Насколько приемлем будет такой вариант? > http://git.altlinux.org/people/real/packages/python-module-logilab-common.git?p=python-module-logilab-common.git;a=commitdiff;h=33ef3a2a77d2814381d9489e73e2eee283f80163 > > Ничего не сломает? А то ведь сам logilab лежит не в /usr/lib64, а в /usr/lib. Ну STD_LIB_DIR используется только для поиска стандартных модулей (всё что не в site-packages), а лежат ли они на x86_64 только в lib64, или и там и там, я не в курсе. Если и там и там - вообще всё переписывать надо.
У питона 3 noarch-пакета: python-relaxed-2.6.5-alt2.noarch.rpm python-strict-2.6.5-alt2.noarch.rpm python-user-scripts-2.6.5-alt2.noarch.rpm Так что тут либо надо всё тестировать, что касается logilab, и исправлять, либо собрать в предложенном варианте и ждать наборсов в багзилле. Мне не нравятся оба варианта :(
Ну значит забить и оставить багу висеть. Пусть кому надо, тот и чинит, мне pylint (а, следовательно, и logilab.*) на альтовом x86_64 не понадобится никогда, а рассказывать апстриму про наши мягко говоря странные design decisions с биарчевым питоном я не хочу.
Обновил пакет. Проблема осталась? Если нет, через неделю закрываю.
Проблема решена отказом от альтового биарча, так что понятия не имею.
Поскольку возражений не поступало, багу закрываю.
