Bugzilla – Bug 214820
"halmount -e /device" gives a Python traceback
Last modified: 2007-06-05 11:17:40 UTC
halmount from ivman-0.6.12-17 seems to have some problems: - "halmount /dev/hdc" works - "halmount -u /dev/hdc" works - "halmount -e /dev/hdc", however, always throws the following traceback (whether the device is mounted or not): $ halmount -e /dev/hdc Traceback (most recent call last): File "/usr/bin/halmount", line 298, in <module> m.eject(name) File "/usr/bin/halmount", line 246, in eject ret = obj.Eject([""], dbus_interface="org.freedesktop.Hal.Device.Volume") File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 25, in __call__ ret = self._proxy_method (*args, **keywords) File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 102, in __call__ reply_message = self._connection.send_with_reply_and_block(message, timeout) File "dbus_bindings.pyx", line 456, in dbus_bindings.Connection.send_with_reply_and_block TypeError: exceptions must be strings, classes, or instances, not type Package versions: ivman-0.6.12-17 hal-0.5.8_git20060927-11 hal-devel-0.5.8_git20060927-11 hal-gnome-0.5.8_git20060927-11 hal-resmgr-0.1_SVNr114-8 dbus-1-qt3-0.62-24 dbus-1-mono-0.63-16 dbus-1-x11-0.94-4 dbus-1-glib-0.71-14 dbus-1-0.94-4 dbus-1-python-0.71-15 dbus-1-devel-0.94-4 dbus-1-glib-devel-0.71-14 dbus-1-qt3-devel-0.62-24
HAL is to blame. Eject moved from /usr/bin/eject to /bin/eject [1] [1] snipplet from eject.changes 88 ------------------------------------------------------------------- 89 Tue Sep 19 16:01:35 CEST 2000 - olh@suse.de 90 91 - move binary to /bin 92
Created attachment 103043 [details] The fix.
/usr/eject?! You surely meant /bin/eject.
Created attachment 103046 [details] The fix. Take two. Yes, thanks for the watching closely.
Please submit a fixed package for Beta1+, so that we can see which other eject issues depend on this.
(In reply to comment #1) > Eject moved from /usr/bin/eject to /bin/eject [1] > > > [1] snipplet from eject.changes > > 88 ------------------------------------------------------------------- > 89 Tue Sep 19 16:01:35 CEST 2000 - olh@suse.de > 90 > 91 - move binary to /bin > 92 I taked a look at Fedora, Mandriva, Debian and some other distributions. SUSE is the only one which moved eject to bin. All other distributions have currently eject in /usr/bin.
this change is 6 years old. how does it break now? I cant remember why I moved it. Maybe for this academic /usr can be unavailable. If you move eject, make sure that all packages get fixed. And why does everyone use absolete path names anyway?
Let's not move the eject binary back from /bin to /usr/bin now, please. Who knows how many of the thousands of packages in the tree expect it in /bin. There is 1 package (hal) which is known to expect it in /usr/bin, so let's better patch this 1 package.
*** Bug 216545 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > *** Bug 216545 has been marked as a duplicate of this bug. *** Is it HW depending? I was trying installation from the same CD set at different HW (Intel Pentium 4 1.50 GHz, Intel 82845 845 Brookdale Chipset, DVD-ROM GDR8163B). Everything went O.K.
Still present in Beta 1 plus. -> Beta 1 plus
submitted a new HAL version with correct path, but we need a general upstream fix.