on device connect .xsession-errors spits out:

QObject::connect: Cannot connect (null)::ejectPressed(QString) to SolidAutoEject::onEjectPressed(QString)
QObject::connect: Cannot connect (null)::ejectPressed(QString) to SolidAutoEject::onEjectPressed(QString)
QObject::connect: Cannot connect (null)::ejectPressed(QString) to SolidAutoEject::onEjectPressed(QString)
QObject::connect: Cannot connect (null)::ejectPressed(QString) to SolidAutoEject::onEjectPressed(QString)
QObject::connect: Cannot connect (null)::ejectPressed(QString) to SolidAutoEject::onEjectPressed(QString)
QObject::connect: Cannot connect (null)::ejectPressed(QString) to SolidAutoEject::onEjectPressed(QString)
file retriever error: 149

Thank you for taking the time to report this issue to us.  This is an issue which is best addressed by the upstream developers.

Please file a report at bugs.kde.org , and when done add the upstream report info to this report.

We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates.

Thank you for the bug report.

This bug has been triaged

Steven M. Parrish
KDE & Packagekit Triager 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Attached upstream bug report.

After talking with Rex, the general consensus is that this is not a Solid issue, but a HAL or some other lower layer issue. I am reassigning this bug to HAL.

It appears as though HAL is not giving the device a proper interface...

[rrix@TheSwan kfacebook]$ hal-device /org/freedesktop/Hal/devices/usb_device_5ca_1880_R5U880_00003
udi = '/org/freedesktop/Hal/devices/usb_device_5ca_1880_R5U880_00003'
  info.vendor = 'Ricoh Co., Ltd'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'usb'  (string)
  usb_device.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6'  (string)
  usb_device.configuration_value = 1  (0x1)  (int)
  usb_device.num_configurations = 1  (0x1)  (int)
  usb_device.num_interfaces = 1  (0x1)  (int)
  usb_device.device_class = 0  (0x0)  (int)
  usb_device.device_subclass = 0  (0x0)  (int)
  usb_device.device_protocol = 0  (0x0)  (int)
  usb_device.vendor_id = 1482  (0x5ca)  (int)
  usb_device.product_id = 6272  (0x1880)  (int)
  usb_device.vendor = 'Ricoh Co., Ltd'  (string)
  usb_device.product = 'USB2.0-FLASH Media'  (string)
  usb_device.device_revision_bcd = 1  (0x1)  (int)
  info.subsystem = 'usb_device'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_5ca_1880_R5U880_00003'  (string)
  usb_device.num_ports = 0  (0x0)  (int)
  info.product = 'USB2.0-FLASH Media'  (string)
  usb_device.speed = 480  (double)
  usb_device.linux.device_number = 4  (0x4)  (int)
  usb_device.max_power = 300  (0x12c)  (int)
  usb_device.can_wake_up = true  (bool)
  usb_device.bus_number = 2  (0x2)  (int)
  usb_device.serial = 'R5U880-00003'  (string)
  linux.device_file = '/dev/bus/usb/002/004'  (string)
  usb_device.version = 2  (double)
  usb_device.is_self_powered = false  (bool)
  info.bus = 'usb_device'  (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6'  (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_1d6b_2_0000_00_1d_7'  (string)
  info.linux.driver = 'usb'  (string)

[rrix@TheSwan kfacebook]$ solid-hardware mount /org/freedesktop/Hal/devices/usb_device_5ca_1880_R5U880_00003
Error: /org/freedesktop/Hal/devices/usb_device_5ca_1880_R5U880_00003 does not have the interface StorageAccess.

Does anyone have any insight on this issue? It is affecting multiple versions of Fedora (12 and Alpha 13) on KDE 4.4.1 :(

On my lenovo laptop, uninstalling hdaps resolved the issue, if some of you are in this case, try this.

Annnnd this indeed did work. looking at the configuration file, it applies hdapsd to /dev/sda .... and /dev/sdb; my thinkpad only has one harddrive. Maybe we should look at changing the default configuration to apply to only one drive instead of two.

Reassigning to hdapsd for RFC.

Hi, I'm the hdapsd maintainer. This bug puzzles me, as hdapsd should have no influence on HAL at all. Hdaps should even exit itself when called on USB "sdb", as it have no unload_heads available.

Maybe the problem is caused by custom udev rule installed by hdapsd? This rule emits upstart event when block devices are added. 

May the person affected try remove /etc/udev/rules.d/99-hdapsd.rules and see if problem persist?

(In reply to comment #8)
> Hi, I'm the hdapsd maintainer. This bug puzzles me, as hdapsd should have no
> influence on HAL at all. Hdaps should even exit itself when called on USB
> "sdb", as it have no unload_heads available.
> 
> Maybe the problem is caused by custom udev rule installed by hdapsd? This rule
> emits upstart event when block devices are added. 
> 
> May the person affected try remove /etc/udev/rules.d/99-hdapsd.rules and see if
> problem persist?    

Removing the udev rule does indeed solve the problem.

BTW, where is the place to report further bugs about hdapsd. In my case (Thinkpad X200 Tablet) the hdapsd daemon is not loaded by the upstart script included in the RPM. However, manually starting is working without problems.

I'm going to rename hdapsd's udev rule. It was added only temporary, as it should be emitted by upstart itself (according to documentation, and apparently HAL or Solid are rightfuly expecting this event). But somehow upstart does not emit this.
For Fedora 13, man upstart shows that syntax for this rule has changed and hdapsd package do not ship custom rule.

So, please someone affected by this bug change "block-device-added" into "hdapsd-custom-rule" in /etc/udev/rules.d/99-hdapsd and /etc/event.d/hdapsd file and report back if this solves problem and starts hdapsd.


And Stephan, you can report hdapsd bugs in this bugzilla, under "hdapsd" component.

(In reply to comment #10)
> So, please someone affected by this bug change "block-device-added" into
> "hdapsd-custom-rule" in /etc/udev/rules.d/99-hdapsd and /etc/event.d/hdapsd
> file and report back if this solves problem and starts hdapsd.

After the mentioned modifications hdapsd is successfully started by upstart. However, KDE's device manager does not recognize any USB stick as hdapsd takes the corresponding sdb kernel event.

This can be solved by adding 'ATTRS{removable}=="0"' to /etc/udev/rules.d/99-hdapsd so that hdapsd only takes care about non-removable hard disks. This is sufficient for me. However, I do not know if this might be a problem with devices like a Thinkpad's Ultrabay HDD.

hdapsd-20090401-5.fc12.1 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/hdapsd-20090401-5.fc12.1

It been almost a month and the hdapsd update wasn't tested by anyone. Could some of you check if the issue still appears and provide corresponding karma in Bodhi?

I'd just push it to stable, karma be darned.

Kevin, I won't push untested update to stable distro. I cannot test myself - I don't use KDE, don't have any F12 installations left, don't have spare thinkpad laptop to install and test - virtual machine won't cut.

So, if nobody interested in step up and provide karma, this update will linger in -testing.

> Kevin, I won't push untested update to stable distro.

That's not a productive attitude to have. Bugs must be fixed, no matter what.

Even under the new update policies which will get in force, it will be possible to push an update to stable with no karma if it has been in testing for at least a week.

BTW, being a provenpackager, it would be easy for me to bump, rebuild and push directly to stable. Don't force me to do that.

http://lwn.net/Articles/387521/

Does comment #11 not count as sufficient feedback?

Else, rrix, can you comment ?

I don't see how mmcgrath's link is relevant in any way to this bug! It's just Lionel Debroux's usual trolling, he's being trying to destroy my image by blatant character assassination for years.

Isn't fixing a serious bug which affects my packages one of the things provenpackager is for?

Quoting from https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Who_is_allowed_to_modify_which_packages :

> If 
> a packager doesn't fix important bugs in time 

Check. The bug is important as it breaks an important functionality in KDE. It isn't being fixed in time, the fix hasn't been pushed out to stable for a month.

> there are problems known that might be bad for the whole Project or a lot of users of the repo/a particular package

Check. All users of KDE who have the offending package installed are affected.

> the changes are quite minor or considered as a general cleanup to a lot of packages 

Check. The changes are quite minor here.

> then provenpackagers are allowed to fix stuff in other peoples packages.

So that's my point.


But anyway, I really want the maintainer to just push the update!

The maintainer wants karma.  You want the bug pushed.  So instead testing and giving him the karma he wants....  You actually make a threat to bypass him completely and push it on your own.  I posted the link to provide others (not you) with context about you since I suspect your reaction will be sent to several people just as it was sent to me.

We're currently discussing on #fedora-kde how to test this reliably. Of course we need to first reproduce the bug before being able to test a fix. I think installing the package if it's not always installed and plugging in some USB device SHOULD be sufficient as a reproducer, maybe I'll just try that.

Hmmm, looking at the history again, it seems you need to have at least one disk claimed by hdapsd to reproduce the bug. This means the good news is that the bug is not as widespread as I thought (though it still affects most/all Thinkpads, it seems, which is quite common hardware), the bad news is that it's harder to reproduce it. I don't think my machines are affected, I actually don't remember having seen this bug ever.

I could list various excuses as to why I haven't karma'd that update, or even replied to this bug report, but they wouldn't solve anything. My apologies for falling off the face of the earth. I've been running that build from updates-testing for ... a while now, and it works. I'm going to +1 it, hopefully someone else can test it and get it out the door ASAP. It won't make GA, but we can hopefully get it in a few days after release.

As for what it affects, the software is mostly used, I think, on thinkpad devices. Many thinkpads have an accessory called ultrabase (i don't have one) which allows you to have a second HDD on /dev/sdb, hence the reason hdapsd claims sdb. So really, all you need to test this is a system which hdapsd supports, and a thumb drive.

hdapsd-20090401-5.fc12.1 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

As the reporter, I'm going to go ahead and close this bug, since the issue is solved in updates. If anyone else is still affected by this issue, please re-open it.