ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | version 1.0.0 is too old, blows up some Sugar activities. Please, update to 1.1.1. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | viy <viy> | ||||
| Component: | python-module-dbus | Assignee: | Nobody's working on this, feel free to take it <nobody> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aen, boyarsh, ldv, real.altlinux.org | ||||
| Version: | unstable | ||||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
|
Description
viy
2012-12-08 01:19:21 MSK
(In reply to comment #0) > version 1.0.0 of python-module-dbus is too old, > some sugar activities requires more fresh python-module-dbus. > Please, update python-module-dbus to 1.1.1. > > Я sugar собираю, мне срочно надо, поэтому если выдать мне acl, помогу обновить, > если надо. Возможно, что ваше "срочно" не поможет. Тесты в dbus-python вылетают c "unichr() arg not in range(0x10000) (narrow Python build)" Лечится это просто -- пересборкой самого python c --enable-unicode-ucs4, ну и, -- всего остального питона, ибо это ABI breakage. Глянул в федору -- в федорах питон собирается с ucs4 c 2003 года. Насколько ситуация серьезна для сизифа в целом, не могу судить. #85718 (В ответ на комментарий №2) > #85718 Хотел бы помочь с транзакцией. Прошу вас сделать #85718 [shared]. там у пакетов libimobiledevice aris libplist aris строгий acl, может, было бы лучше чтобы вы их лично в транзакцию добавили. Или потом выписать approve. (В ответ на комментарий №3) Извиняюсь за беспокойство, [shared] выписывать не нужно, но потом понадобится approve. (In reply to comment #4) > (В ответ на комментарий №3) > Извиняюсь за беспокойство, [shared] выписывать не нужно, но потом понадобится > approve. Без shared вы ничего не добавите в задание -- сделал. И учтите, что это только начало, -- при следующей проверке вылезет более внушительный список. (In reply to comment #3) > (В ответ на комментарий №2) > > #85718 > Хотел бы помочь с транзакцией. > Прошу вас сделать #85718 [shared]. > там у пакетов > libimobiledevice aris > libplist aris > строгий acl, может, было бы лучше чтобы вы их лично в транзакцию добавили. Свои пакеты, я сам добавлю. (В ответ на комментарий №5)
> (In reply to comment #4)
> И учтите, что это только
> начало, -- при следующей проверке вылезет более внушительный список.
для того и роботы существуют ;)
будет повод тщательно протестировать girar-nmu utils с новыми библиогтеками для робота.
(В ответ на комментарий №7) > (В ответ на комментарий №5) > > (In reply to comment #4) > > И учтите, что это только > > начало, -- при следующей проверке вылезет более внушительный список. > > для того и роботы существуют ;) > будет повод тщательно протестировать girar-nmu utils с новыми библиогтеками для > робота. Я бы все же предложил обсудить с @python и в devel@ возможные последствия такого шага и его целесообразность. (In reply to comment #7) > (В ответ на комментарий №5) > > (In reply to comment #4) > > И учтите, что это только > > начало, -- при следующей проверке вылезет более внушительный список. > > для того и роботы существуют ;) > будет повод тщательно протестировать girar-nmu utils с новыми библиогтеками для > робота. Уже сейчас сборка того, что вы набросали в задание очень быстро обломается. Надо анализировать сборочные зависимости. (В ответ на комментарий №8) > Я бы все же предложил обсудить с @python и в devel@ возможные последствия > такого шага и его целесообразность. Да, конечно. С текущими acl эта сборка пробная, она заведомо не пройдет в Сизиф. (В ответ на комментарий №9) > Уже сейчас сборка того, что вы набросали в задание очень быстро обломается. > Надо анализировать сборочные зависимости. Да, действительно. Надо будет перевызвать робота с сортировкой по зависимостям и перезалить. (В ответ на комментарий №10) > > Я бы все же предложил обсудить с @python и в devel@ возможные последствия > > такого шага и его целесообразность. > Да, конечно. С текущими acl эта сборка пробная, она заведомо не пройдет в > Сизиф. Пока хотел бы оценить масштаб требуемой транзакции. Хотел бы вынести на обсуждение, когда станет более-менее ясно, чьи пакеты будут затронуты. (In reply to comment #1) > Возможно, что ваше "срочно" не поможет. Тесты в dbus-python вылетают c > "unichr() arg not in range(0x10000) (narrow Python build)" Лечится это просто > -- пересборкой самого python c --enable-unicode-ucs4, ну и, -- всего > остального питона, ибо это ABI breakage. $ rpmsodiff /ALT/Sisyphus/files/x86_64/RPMS/libpython-2.7.3-alt4.x86_64.rpm /tasks/85718/build/40/x86_64/rpms/libpython-2.7.3-alt5.x86_64.rpm |grep symbols 85 symbols removed 85 symbols added Почти *всего* остального питона. Наверное, есть модули, в которых совсем не используется unicode и которые можно не пересобирать, но после python-2.7.2-alt5 мы уже не можем полагаться на анметы, потому что их будет меньше, чем пакетов, использующих символы PyUnicodeUCS2_*. Не факт, кстати, что можно не пересобирать noarch-модули, возможно, они тоже нуждаются в перекомпиляции. Оно нам действительно надо? (В ответ на комментарий №13) > Оно нам действительно надо? В свете p7 возможно, и не надо. Но тогда sugar в p7 под вопросом. В общем, готов принять любое решение. Дмитрий, не могли бы вы в devel@ резюме написать? у меня почтовый ящик для переписки с devel@ временно недоступен :( Для справки, ссылка на соответствующий коммит в dbus-python http://cgit.freedesktop.org/dbus/dbus-python/commit/?id=f6066573d25508f5cbbc5c12254086d419bb8828 А как в у нас в python3, интересно? И не переходит ли sugar на него? (In reply to comment #14) > (В ответ на комментарий №13) > > Оно нам действительно надо? > > В свете p7 возможно, и не надо. Но тогда sugar в p7 под вопросом. > В общем, готов принять любое решение. > > Дмитрий, не могли бы вы в devel@ резюме написать? Резюме? Да у меня пока что одни вопросы. (In reply to comment #15) > Для справки, ссылка на соответствующий коммит в dbus-python > http://cgit.freedesktop.org/dbus/dbus-python/commit/?id=f6066573d25508f5cbbc5c12254086d419bb8828 Ну так там просто часть тестов написана в рассчете на ucs4. Это точно еще не основание для пересборки всего питона. (В ответ на комментарий №16) > А как в у нас в python3, интересно? %configure ... --with-wide-unicode > И не переходит ли sugar на него? на gtk3; но (еще) не на python3. (В ответ на комментарий №18) > (In reply to comment #15) > > Для справки, ссылка на соответствующий коммит в dbus-python > > http://cgit.freedesktop.org/dbus/dbus-python/commit/?id=f6066573d25508f5cbbc5c12254086d419bb8828 > Ну так там просто часть тестов написана в рассчете на ucs4. > Это точно еще не основание для пересборки всего питона. И меня бы устроило обновление только dbus-python. Если и есть приложения, которые используют ucs4, то они и так сейчас заведомо не работают - хуже не будет. (В ответ на комментарий №19) > (В ответ на комментарий №16) > > А как в у нас в python3, интересно? > %configure ... --with-wide-unicode > > И не переходит ли sugar на него? > на gtk3; но (еще) не на python3. http://wiki.sugarlabs.org/go/GoogleCodeIn2012/Python3 Но еще важнее: http://lwn.net/Articles/523465/ ("GNOME 3.8 will depend on Python 3") Если этому верить, то вряд ли стоит затевать пересборку python 2.7. А вот готовиться к переходу на python3 стоит заранее. 1. На данный момент слишком мало питоньих модулей умеют Python 3. 2. В team найти добровольца взяться за обучение вряд ли получится. Тут нужен отдельный человек, на полный рабочий день, с вменяемой оплатой труда. (В ответ на комментарий №22) > 1. На данный момент слишком мало питоньих модулей умеют Python 3. > > 2. В team найти добровольца взяться за обучение вряд ли получится. Тут нужен > отдельный человек, на полный рабочий день, с вменяемой оплатой труда. 1. Я все надеюсь, что Gnome Team выполнит свои планы, а стало быть необходимые модули будут. 2. Эта тема совсем не для bugzilla. (Но вакансии у нас есть, я писал об этом. Если что, -- в личную почту или на org@ .) А если попробовать заменить в этом тесте реализацию функции uni(x) для python2:
import struct
def uni(x):
return struct.pack('<I', x).decode('utf-32le')
В принципе сам Python 2 как-то может работать с символами за пределами BMP даже при сборке с ucs2, но функции unichr и ord с ними не работают.
http://www.gossamer-threads.com/lists/python/python/856665#856665
http://www.python.org/dev/peps/pep-0261/
Created attachment 5671 [details]
disable ucs4 tests
Прикладываю патч, убирающий проверку работы с usc4 символами.
С этим патчем у меня dbus-python благополучно собрался,
а после его установки в эмулятор в Sugar заработали змейка pippy
и черепашка turtleart :)
можно выкладывать? (In reply to comment #25) > Created an attachment (id=5671) [details] > disable ucs4 tests > > Прикладываю патч, убирающий проверку работы с usc4 символами. Вы это серьезно? Тест ведь, насколько я понимаю, отнюдь не на проверку работы с usc4, он просто использует unichr(), потому что так проще было закодить тест. Попробуйте лучше тот вариант, который предложил Сергей. Ок, можно и так. Уже в понедельник попробую. Прокатило с такой вот реализацией uni(x):
def uni(x):
- return unichr(x)
+ hi,lo=divmod(x-0x10000,0x400)
+ if hi>0:
+ return unichr(0xd800+hi)+unichr(0xdc00+lo)
+ else:
+ return unichr(x)
python-module-dbus-1.1.1-alt2 -> sisyphus: * Tue Dec 11 2012 Igor Vlasenko <viy@altlinux> 1.1.1-alt2 - fix for our usc4-impaired python 2.7 build as patch2 thanks to vsu@ and ldv@. (closes: #28202) * Sat Dec 08 2012 Yuri N. Sedunov <aris@altlinux> 1.1.1-alt1 - after 1.1.1 snapshot (c57c4d28) - %check section |
