| Summary: | KDE support of hal/dbus | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Doug Goldstein (RETIRED) <cardoe> |
| Component: | New packages | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aaron123456789, avuton, betelgeuse, d, hanno, mhf |
| Priority: | High | ||
| Version: | 2005.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 107943 | ||
| Attachments: | kubuntu_23_hal_api.diff | ||
|
Description
Doug Goldstein (RETIRED)
2005-09-10 17:10:27 UTC
With all due respect pmount was held up for months when it was perfectly useable on KDE 3.4, and I commented on the bug several times. I am working on the issue, but I am pretty busy right now with real life. If any of the other KDE devs have any time I would appreciate a hand with this one - the new versions works without issue on KDE 3.5 alpha1. pmount was held up because the Gnome herd is lazy and was asserting their influence. We're done with the Gnome herd. Things will not be set by their time. pmount is in the tree. I have been researching this, and doing some of my own tests here and I am unable to get the new hal/pmount working with KDE 3.4. I don't have lots of time right now, the KDE bug is here - http://bugs.kde.org/show_bug.cgi?id=101075 If anyone has any ideas on this please let me know - I can't find any useful looking patches from other distros either, but I could have missed something. See comment 15 from the upstream bug - http://bugs.kde.org/show_bug.cgi?id=101075#c15 It seems there are no plans to backport support of the new versions of hal/dbus to KDE 3.4, and my searches for a patch have not been successful. If anyone out there has got this working then please let us know, otherwise I think we will have to wait for KDE 3.5 (beta 1 should be out later this week). FYI, Ubuntu Breezy supports KDE 3.4 with the new hal/dbus-API, so maybe have a look at their patches and how they do it? OK - looking at their patches I managed to make some progress. Patching our kdebase-kioslaves-3.4.2 split ebuild with kubuntu_23_hal_api.diff allowed it to compile successfully with the new hal/dbus and new devices are shown and removed. That cannot be mounted automatically on my system though! I will see if I can get to the bottom of this over the weekend - I am open to ideas. It seems they use ivman for volume management so I am not sure if that is a factor. Just to keep this bug up to date, by applying the kubuntu hal api patch the media manager compiles with the new hal/dbus combo. It sees plug in and removal events, and seems to mount the devices. It seems to get confused when clicking on the devices and shows no contents though. media:/sdf shows nothing, typing /media/sdf shows me the contents of the device. Close but no cigar... Ideas welcomed - if not I will see if I can dig a little deeper this weekend. Created attachment 69127 [details, diff]
kubuntu_23_hal_api.diff
Attaching the kubuntu patch, from their breezy builds. This allows compilation
with the new hal/dbus, hal plugins and removals are triggered, partitions
mounted. The media manager does not seem to see the mount event, or navigate to
the volume contents however as I said previously.
Why would we want to do this? KDE 3.4* works perfectly with the stable versions of dbus and hal already in the tree. If it isn't broken, don't touch it. any update on this? Thanks! My main dev system died earlier tonight, don't know how long it will take me to get fixed. That is the system I was testing this stuff on and my dev box so I won't be able to do any further work on it until I get it fixed up. Anyone else from the KDE herd able to take a look into this? Right - I have committed and masked kde-base/kdebase-kioslaves-3.4.2-r1. This version *should* work with the new hal/dbus and does here. It seems originally that there was something screwed up on my system with pmount/hal. It is masked because I want it to receive more testing and comment from others in the KDE herd. I would appreciate comments of success or failure with this revision with the new hal/dbus. If this works then hopefully it will allow the gnome herd to put 2.12 into testing and stabilise it later! Thanks for your patience. did testing the masked build go well? I would have preferred more feedback, but it has mostly been positive. There do still seem to be some issues with upgrading from old versions, but I am now unable to reproduce this with any of the builds in the tree. I would appreciate feedback from any and all for successful use as well as failure. Working perfectly here even after up/downgrading across available versions in the tree. Marcus, thank you for taking this on. Packages suggested in you blog work allright with CDROM, USB key and USB HD. Floppy mounts but kioslave does not seem to see mount status change. The icon remains unmounted and konqueror lists 'Unmounted Floppy'. Clicking again on floppy icon results in further mount attempt. Manual mounting/unmounting changes konqueror status/icons with CD and USB but not with floppy . Installation: Uptodate, gcc 3.3.6, python 2.4.2 (dbus wanted it), 2.6.13.1 kernel, minimal kde as below dbus-0.36.2 hal-0.5.4 pmount-0.9.3-r3 kcheckpass-3.4.2 kcminit-3.4.1 kcontrol-3.4.2-r1 kdebase-data-3.4.2 kdebase-kioslaves-3.4.2-r1 kdebase-pam-6 kde-env-3-r4 kdelibs-3.4.2-r1 kdesktop-3.4.2 kdesu-3.4.1 kdialog-3.4.1 kdm-3.4.2 khelpcenter-3.4.2 khotkeys-3.4.2 konqueror-3.4.2-r1 libkonq-3.4.2 Michael (In reply to comment #9) > Why would we want to do this? KDE 3.4* works perfectly with the stable versions > of dbus and hal already in the tree. If it isn't broken, don't touch it. It does work only imperfectly. Events are missed at times and most recently the floppy had disappeared alltogether. It also identified mounted hda/hdc hard disk partitions as floppies until I found the desktop entries and changed them... The new version seems to be much faster and hides hda/hdc hard disk partitions. If we could get rid of that useless progress dialog during mount, it would be even less imperfect... (In reply to comment #16) > It does work only imperfectly. Events are missed at times and most recently > the floppy had disappeared alltogether. It also identified mounted hda/hdc hard > disk partitions as floppies until I found the desktop entries and changed > them... > > The new version seems to be much faster and hides hda/hdc hard disk partitions. Yeah should have chosen my words a little better. > > If we could get rid of that useless progress dialog during mount, it would be > even less imperfect... Well I have not looked at the code but I think it would be great to have progress dialogs in general implemented like they do it in Swing. The progress dialog does not by default show up until a second or two has passed (I don't remember what accurate delay is), but this is off topic for this bug. Any way I think I have figured out why we need to get the new hal/dbus supported. Just noticed that the CDR is identified as CDW. Now you mention it floppies don't work here either, although I have to admit I rarely use them and had to have a good look to find one! It would be nice to have everything working perfectly, but this was always a new feature with some rough edges remaining (including the changing API...) As always I am open to any patches you may have to fix the floppy drive issue :) The progress dialog issue would be something to file upstream IMO, I am uncertain whether the floppy drive issue is local to us or not. Were it not for the Gnome team with the 2.12 release I would not have patched KDE 3.4 for the new API as in general it is better to stay as close to upstream as possible. KDE 3.5 supports the new API out of the box. Likely not kde problem, seems to be a bug in hal. The hald output below shows that hald moans about a missing volume for floppy during munt state change although sysfs_path was set during initial scan. From the source it seems that sysfs_path was not usable. Entry OK in /sys/block/fd0. Behavior/messages of mounting by konqueror and mount same. FUI, logging can be performed by stopping /etc/init.d/hald and starting hald with debug: # hald --daemon=no --verbose=yes BTW, In my installations hald will not be stopped by hald stop Hald output: [ snip ] 03:07:07.111 [I] hald.c:89: Added device to GDL; udi=/org/freedesktop/Hal/ devices/volume_uuid_4322_4E64 03:07:07.112 [I] blockdev.c:547: block_add: sysfs_path=/sys/block/fd0 dev=/dev/ floppy/0 is_part=0, parent=0x00000000 03:07:07.113 [I] blockdev.c:620: doing floppy drive hack for floppy 0 03:07:07.115 [I] blockdev.c:371: Probing PC floppy /dev/floppy/0 to see if it is present 3702: 03:07:07.119: probe-pc-floppy.c:73: Checking if /dev/floppy/0 is actually present 3702: 03:07:07.120: probe-pc-floppy.c:88: floppy drive name is 'H1440' 03:07:07.121 [I] hald_dbus.c:2964: local_server_message_handler: destination=(null) obj_path=/org/freedesktop/DBus/Local interface=org. freedesktop.DBus.Local method=Disconnected 03:07:07.121 [I] hald_dbus.c:2980: Client to local_server was disconnected 03:07:07.121 [I] hald_dbus.c:2990: unregistered 03:07:07.141 [I] util.c:554: child exited for pid 3702 03:07:07.142 [I] blockdev.c:281: entering; timed_out=0, return_code=0 03:07:07.152 [I] device_info.c:1370: *** Matched file /usr/share/hal/fdi/policy/ 10osvendor/10-storage-policy.fdi 03:07:07.153 [I] blockdev.c:139: Add callouts completed udi=/org/freedesktop/ Hal/devices/computer_storage [ snip ] 03:26:46.957 [I] osspec.c:243: total_read=17 buf='mount@/block/fd0' 03:26:46.957 [I] blockdev.c:220: mount_status_changed for '/sys/block/fd0', is_mounted=1 03:26:46.958 [I] blockdev.c:240: Couldn't find hal volume for /sys/block/fd0 03:26:48.879 [I] osspec.c:243: total_read=18 buf='umount@/block/fd0' 03:26:48.879 [I] blockdev.c:220: mount_status_changed for '/sys/block/fd0', is_mounted=0 03:26:48.880 [I] blockdev.c:240: Couldn't find hal volume for /sys/block/fd0 Perhaps the herd handling hal could have a look. It sounds like it is possibly an upstream issue, but you could search for existing bug, and/or file a new one on the issue. As far as I know this issue is basically resolved. Marking as FIXED. To anyone who wondered about floppies, from the changelog of pmount: 0.9.6 ----- - pmount-hal: support device argument - pmount manpage: fix default mount options inconsistency - pmount-hal: full support for HAL expored mount policy (including global and per-drive policy, and the "exec" option) - autotoolized build system, thanks to Aaron Bockover - pmount: fixed umask parsing, umask 000 works now - pmount-hal: full support for storage devices to mount floppies and similar devices |