20.02.2013 10:25, Ivan A. Melnikov пишет: > 2013/2/20 Aleksey Avdeev : > [...] >> Другой вариант: Изменить 096-bytecompile_python3.brp так, чтобы при >> наличии переменной RPM_BUILD_PYTHON_LANG для работы python`а >> выставлялась локальная локаль ($RPM_BUILD_PYTHON_LANG)... Но помоему это >> ещё более криво. > > Если (когда?) какой-нибудь апстрим положит два питноновских файла, > один в utf-8, а другой в latin-1 с прописаным соответсвенно encoding, > такой вариант решения тоже разломается. Если системная локаль UTF8, то нет, т. к. она включает в себя всё множество символов latin-1. (Если я правильно понял диагностику ошибки, проблему вызывают символы, не отображаемые на системную локаль.) > Мне кажется, надо учить > 096-bytecompile_python3.brp понимать -*- encoding: ... -*-, и > использовать utf-8 по умолчанию. Кто возьмётся за отображение множества python`их лангов на системное? Насколько я знаю, они перекликаются, но не совпадают. Как показывает практика, для большинства python`овских пакетов LC_ALL=C на период байт компиляции вполне достаточно (их сборка не сломана). => LC_ALL=C вполне хорошее умолчание. Но как, опять таки, показала практика, в стадо python пакетов затесалась минимум одна паршивая овца: UTF8 на этапе байткомпиляции нужен как минимум для python3-module-pycairo. Может, конечно, за в процессе перехода на python3.3 что-то ещё такое выплывет... Но думаю, мы уже можем положиться на то, что таких пакетов будет мало. (По крайней мере на данный момент.) Проблема в том, что эти пакеты набо тоже как-то собирать... Значит (как я понимаю задачу) надо ввести механизм, позволяющий задать для _некоторых_ пакетов (подойдёт даже если это будет явный список исключений, заданный в неком файле) вместо LC_ALL=C локаль заданную мантейнером (или прибить гвоздями одну из UTF8, как альтернативу C), как миниум на этапе байткомпиляции. -- С уважением. Алексей.