Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

I really want to unmask hal & dbus. KDE is the reason it's not. This needs to
be
resolved. Figure out a patch or whatever. Or take the Fedora approach and
disable hal/dbus support in KDE 3.4. With KDE 3.5, it's a non issue since it
uses the new version.

I'm not holding up this software for KDE.

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 an attachment (id=69127) [details]
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