[devel] I: [python3] python.req: ERROR

[Aleksey Avdeev]

15.02.2013 05:42, Dmitry V. Levin пишет:
> On Fri, Feb 15, 2013 at 05:29:11AM +0400, Aleksey Avdeev wrote:
>> 15.02.2013 04:37, Dmitry V. Levin пишет:
>>> On Fri, Feb 15, 2013 at 04:03:51AM +0400, Aleksey Avdeev wrote:
>>>> 15.02.2013 03:36, Dmitry V. Levin пишет:
>>>>> On Fri, Feb 15, 2013 at 01:21:15AM +0400, Aleksey Avdeev wrote:
>>>>>> 14.02.2013 22:48, Aleksey Avdeev пишет:
>>>>>>> 14.02.2013 21:38, Aleksey Avdeev пишет:
>>>>>>>> 14.02.2013 21:07, Dmitry V. Levin пишет:
>>>>>>>>> On Thu, Feb 14, 2013 at 08:10:16PM +0400, Aleksey Avdeev wrote:
>>>>>>>>>> Приветствую.
>>>>>>>>>>
>>>>>>>>>>   В расшаренном таске 89971 (см.
>>>>>>>>>> <http://git.altlinux.org/tasks/89971/l>) идёт подготовка к помещению в
>>>>>>>>>> Сизиф python3-3.3.0-alt1.
>>>>>>>>>
>>>>>>>>> А "AutoReqProv: nopython" там зачем добавлен?  Вы полагаете, что python,
>>>>>>>>> собранный таким образом, можно будет использовать?
>>>>>>>>
>>>>>>>>   Причина: python.req.py корёжит на синтаксисе python3.
>>>>>>>
>>>>>>>   А сейчас всё нормально...
>>>>>>
>>>>>>   Поправка: оно нормально отработало на people. А на git.alt данная
>>>>>> причина опять выплыла (см.
>>>>>> <http://git.altlinux.org/tasks/89971/logs/events.3.1.log>):
>>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>
>>>>>> 2013-Feb-14 18:49:14 :: [x86_64] #240 python3.git 3.3.0-alt1: build start
>>>>>> /usr/lib/rpm/python.req.py:
>>>>>> /usr/src/tmp/python3-buildroot/usr/lib/python3.3/_osx_support.py:
>>>>>> line=354 IGNORE module=distutils
>>>>>> python.req: ERROR:
>>>>>> /usr/src/tmp/python3-buildroot/usr/lib/python3.3/_pyio.py: invalid
>>>>>> syntax (line 261)
>>>>>
>>>>> /usr/lib/python3.3/*.py на x86_64?  Что это еще за чудо такое?
>>
>>   Это у нас так логи от [x86_64] и [i586] сборочница перемешивает.
> 
> Тогда не страшно, всегда можно посмотреть отдельные логи.

  Да.

> 
>>> Зачем использовать bootstrap, когда все должно собираться и так?
>>
>>   Как именно? Прошу помощи.
>>
>>   Похоже, что у нас ситуация, когда скрипт исполняемый текущим python3.2
>> (в chroot ставиться python3-3.2.3-alt3, см.
>> <http://git.altlinux.org/tasks/89971/build/240/x86_64/srpm.log>, => он и
>> используется в rpm`овских скриптах) не может переварить код от python3.3
>> (вполне корректный, с точки зрения самого python3.3). Вполне возможно,
>> что дело в несовместимостях между классов/методов python3.2 и python3.3
> 
> При сборке питона скрипты питон.{req,prov} должны исполняться
> свежесобранным питоном.  Насколько я помню, так всегда было,
> и вряд ли стоит менять полезную традицию.

  Здесь ничего сказать не могу: ещё не лазил на столько глубоко в эту
кухню (если полезу -- гарантированно сорву заданные сроки). Более того,
я уже нарвался на то, что моё предположение о работе и взаимодействии
скриптов python{,3}{req,prov}{,.{py,files}} оказалось не верным (то,
когда объяснял почему "AutoReqProv: nopython" ни на что не влияет, а
оказалось что это не так).

> 
> Ну а nopython не нужен просто потому, что python.{req,prov} не должен
> обрабатывать файлы python3, и наоборот.  Если это правило нарушено, значит,
> надо что-то исправить: либо файлы не на месте, либо питон.{req,prov}.files
> отстали от жизни.

  Файлы на месте: всё собранное (исполняемое) в %_libdir/python3.3/, и в
%_libdir/python3.2 ничего не попадает.

  На счёт скриптов python{,3}{req,prov}{,.{py,files}} могу сказать
только то, стандартный вариант их использования (когда они работают
сами, без указаний в спеке) приводит к ошибкам python.req.py. (Причём на
лицо диагностика обработчика ошибок исполняющего скрипт интерпретатора.)
Т. е. проблема в скриптах скорее всего есть.

  На данный момент, я не знаю как исправить проблему в корне. Нашёл
только, как обойти проблему с помощью bootstrap`а.

-- 

С уважением. Алексей.


----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 897 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20130215/8fcef9ac/attachment-0001.bin>