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, помогу обновить, если надо. И свежему гному свежий python-module-dbus не помешал бы.
(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
