Bugzilla Bug 206468

If hald is not running when I run vmplayer, I get this:

griffon26@griffon27 ~> vmplayer 
process 8096: Attempt to remove filter function 0xb5587e58 user data 0x8252038,
but no such filter has been added
  /usr/lib/libdbus-1.so.3 [0xb556aba2]
  /usr/lib/libdbus-1.so.3 [0xb556a074]
  /usr/lib/libdbus-1.so.3 [0xb555eda3]
  /usr/lib/libdbus-1.so.3(dbus_connection_remove_filter+0x2a1) [0xb5537b49]
  /usr/lib/libhal.so.1(libhal_ctx_shutdown+0x81) [0xb5587ddc]
 
/opt/vmware/player/lib/lib/libvmwarebase.so.0/libvmwarebase.so.0(HAL05Init+0x389)
[0xb6edeea9]
 
/opt/vmware/player/lib/lib/libvmwarebase.so.0/libvmwarebase.so.0(HALInit+0x1b)
[0xb6edd7db]
 
/opt/vmware/player/lib/lib/libvmwarebase.so.0/libvmwarebase.so.0(HostDeviceInfo_Init+0x75)
[0xb6edd095]
  /opt/vmware/player/lib/bin/vmplayer(_ZN6player6Player11PostGtkInitEv+0x257)
[0x80c87f7]
 
/opt/vmware/player/lib/lib/libgtkmm-2.4.so.1/libgtkmm-2.4.so.1(_ZN3Gtk6RunSig12gtk_callbackEPv+0x58)
[0xb74d8f98]
 
/opt/vmware/player/lib/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0(gtk_main+0x7d)
[0xb785d04d]
 
/opt/vmware/player/lib/lib/libgtkmm-2.4.so.1/libgtkmm-2.4.so.1(_ZN3Gtk4Main8run_implEv+0x17)
[0xb74d8047]
 
/opt/vmware/player/lib/lib/libgtkmm-2.4.so.1/libgtkmm-2.4.so.1(_ZN3Gtk4Main3runEv+0x22)
[0xb74d7e32]
  /opt/vmware/player/lib/bin/vmplayer(main+0x72) [0x80c6da2]
  /lib/libc.so.6(__libc_start_main+0xe0) [0xb613e400]
  /opt/vmware/player/lib/bin/vmplayer(_ZN3Gtk10CellLayoutD1Ev+0x81) [0x80c6ca1]

But adding hald to need in the vmware init script and restarting it allows me
to run vmware-player just fine. I've seen this on 2 systems already.

Hi Maurice, I apologize for the extended delay.  I believe this issue was seen
elsewhere and I was hoping for a resolution on it before I replied, but it
rather slid off the bottom of my ever increasing vmware bug list.  It seems
only to occur when dbus is running but hal isn't, however I believe that dbus
is becoming more and more of a dependency, so I've added this requirement into
the vmware-player ebuilds (it was already present in the vmware-workstation
ebuilds) currently in the tree (please give the servers a couple of hours to
propagate the changes).  It's probably not worth bumping the ebuilds, but any
new emerges should include this fix.

I'm including it as a use not a need, which hopefully should be enough (because
I don't believe it's a requirement), however there may still be instances where
the issue occurs.  Hopefully this bug will allow people to track down why. 
Please reopen this bug if you feel it hasn't been fixed.  Thanks...  5:)