GNOME Bugzilla – Bug 429571
crash in Gimmie: push button "Library"
Last modified: 2007-04-26 07:18:25 UTC
What were you doing when the application crashed? push button "Library" Distribution: Fedora Core release 6 (Zod) Gnome Release: 2.16.3 2007-01-31 (Red Hat, Inc) BugBuddy Version: 2.16.0 System: Linux 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 11:38:26 EDT 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 70101000 Selinux: Permissive Accessibility: Disabled Memory status: size: 0 vsize: 0 resident: 0 share: 0 rss: 0 rss_rlim: 0 CPU usage: start_time: 0 rtime: 0 utime: 0 stime: 0 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 0 ----------- .xsession-errors (20 sec old) --------------------- (gnome-panel:4997): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x94670b0 (gnome-panel:4997): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x94670b0 (gnome-panel:4997): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x94670b0 (gnome-panel:4997): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x94670b0 (gnome-panel:4997): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x94670b0 (gnome-panel:4997): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x94670b0 (gnome-panel:4997): GConf-WARNING **: Directory `/apps/panel/toplevels/top_panel_screen1/screen' was not being monitored by GConfClient 0x94670b0 (gnome-panel:4997): GConf-WARNING **: Directory `/apps/panel/toplevels/bottom_panel_screen1/screen' was not being monitored by GConfClient 0x94670b0 -------------------------------------------------- Traceback (most recent call last):
+ Trace 127631
self._show()
self.topic_win = self.topic.get_topic_window()
self.topic_window = TopicMenu(self)
self._add_toolbar_items()
for i in self.topic.get_toolbar_items(self.tooltips):
btn = PlacesMenuButton(tooltips)
self.set_menu(PlacesMenu())
for item in device_source.get_items():
for i in self.get_items_uncached():
yield DriveItem(drive)
raise ValueError, "Cannot find URI to open for drive '%s'" % drive
Seems to me like it is an indention-error. From gimmie_computer.py: if not uri: for volume in drive.get_mounted_volumes(): if volume.is_user_visible(): # FIXME: Using the first volume URI for a device is # broken. There could be multiple, though I don't # know under what circumstances this would happen. uri = volume.get_activation_uri() break else: raise ValueError, "Cannot find URI to open for drive '%s'" % drive This apparently triggers the error each time, instead of the wished behaviour(when volume.is_user_visible() returns False) Adding an indention to the else-block resolves the bug for me: if not uri: for volume in drive.get_mounted_volumes(): if volume.is_user_visible(): # FIXME: Using the first volume URI for a device is # broken. There could be multiple, though I don't # know under what circumstances this would happen. uri = volume.get_activation_uri() break else: raise ValueError, "Cannot find URI to open for drive '%s'" % drive
Created attachment 86927 [details] [review] Indents the function properly Same as above comment, only in patch-format
Thanks for the patch. This bug has already been fixed in SVN. *** This bug has been marked as a duplicate of 421620 ***