[sisyphus] Sisyphus: broken dependancies? hal-device-manager

[Alexey Morozov]

On Sun, Feb 06, 2005 at 11:07:48PM +0300, Alexey Rusakov wrote:
> >>2lav@: О - третий прецедент на hal-device-manager и пятый в сумме по 
> >>проблеме.
> >А причем здесь Липатов-то? :-)
> Просто в своё время именно с ним мы обсуждали проблему, которую я в 
> очередной раз описываю ниже. "Ухожу, ухожу", прошу прощения за 
> упоминание его имени всуе.
Да нет, просто он ни мэйнтэйнер пакета, ни "лицо, высказазавшее
заинтересованность" во всей этой машинерии.

> >Алексей, если Вы не знаете источника проблемы, не надо предлагать решения
> Я предлагаю не решение, а workaround. Ещё раз (где-то третий, наверное) 
Это НЕ workaround. Вы мне поверите, что, несмотря на то, что я
все эти пакеты собирал на своей машине, h-d-m как падал, так и падает.

> описываю изначальную проблему. Извините за многословность, пожалуйста, 
> дочитайте до конца.
...
> (просто взял src.rpm и сделал rpmbuild --rebuild), установил полученное 
> - работает! Вернулся к пакету из Сизифа - падает.
Миракль. Багу повесили мэйнтэйнеру?

> python-modules-pygnome (которая не только у Виталия, но и у меня не 
> воспроизводилась); это был уже не коредамп, а следующая ошибка:
Ну, дак ведь это _другая_ ошибка. Зачем их в кучу-то лепить?

> $ meld
> RuntimeError: can't create const
> Traceback (most recent call last):
>   File "/usr/lib/meld/meldapp.pyc", line 90, in on_response
> 
> AttributeError: '__main__.GnomeFileEntry' object has no attribute 
> 'get_full_path'
Несоответствие gtk, libgnome и их питоньих обвязок.

> У меня похожая проблема проявляется много где, например,
> в hal-device-manager:
Это НЕ похожая проблема. Это, вообще-то _две_ проблемы.
> 
> RuntimeError: can't create const
Собственно, вот это - проблема номер раз. Я с ней и не разбирался.

> Traceback (most recent call last):
>  File "/usr/bin/hal-device-manager", line 18, in ?
>    DeviceManager()
>  File "/usr/share/hal/device-manager/DeviceManager.py", line 81, in
> __init__
>    self.update_device_list()
>  File "/usr/share/hal/device-manager/DeviceManager.py", line 195, in
> update_device_list
>    self.virtual_root = self.build_device_tree()
>  File "/usr/share/hal/device-manager/DeviceManager.py", line 269, in
> build_device_tree
>    parent_name = properties["info.parent"]
> TypeError: unsubscriptable objectф
А вот это - проблема номер два. Суть её в том, что _dbus_ (не libgnome,
не питон, не питонья обвязка над gtk :-)) версии 0.22 в _некоторых_ случаях
не вполне корректно сериализовал/десериализовывал данные сообщения.
В результате, в качестве свойств (properties) возвращался не хэш с
некоторыми обязательными полями, а None. О чем, собственно, питон и
ругался благим матом.

> Точно такую же диагностику получил я, попытавшись запустить 
> hal-device-manager. Человек, начавший тему - третий, известный мне, 
> увидевший то же самое.
> 
> А теперь не надо мне говорить гордое программистское "у меня всё 
> работает", потому что это никому не поможет, а я и так подозреваю, что у 
> вас оно работает.
У меня как раз без хаков тоже не работало (на dbus-0.22).

> Вместо этого было бы очень интересно узнать ваше 
> мнение о том, как с этим справиться.
С этим справиться двумя способами: проапгрейдиться до dbus-0.23 и/или
дохакать hal-device-manager, чтобы он не был так доверчив к данным,
приехавшим в сообщении от HAL. Впрочем, учитывая сомнительную полезность
h-d-m, я рекомендовал бы проапгрейдиться и забыть о проблеме до
следующего падения :-).

> Банальное любопытство. Спасибо за хинт про dbus-monitor.
Вот уж точно, "хинт" :-). В его истинном значении :-))

P.S. Там в Сизиф поехал kvm. Он, наверняка, глючный.
Умоляю, прежде чем пересобирать его под чтение мантр, изложите, по
крайней мере, проблему здесь :-).

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20050207/63cae7a8/attachment-0003.bin>