Did the DBUS configure report linking against QT? Doesn't look like it. Maybe you have to specify --with-qt or something like that.. ./configure --help for info

configure:52033: checking for DBus-Qt bindings
configure: 52047: /opt/kde/include/dbus/connection.h
configure: 52047: /usr/include/dbus/connection.h
configure: 52047: /usr/include/dbus-1.0/dbus/connection.h
configure: 52047: /usr/local/include/dbus/connection.h
configure: 52047: /usr/local/include/dbus-1.0/dbus/connection.h
configure: 52074: /opt/kde/lib/libdbus-qt-1.so
configure: 52074: /usr/lib/libdbus-qt-1.so
configure: 52074: /usr/local/lib/libdbus-qt-1.so
configure: 52098: /usr/include/dbus-1.0/dbus/connection.h
configure: 52098: /usr/lib/dbus-1.0/include/dbus/connection.h
configure:52147: result: searched but not found

You'll probably also want pyrex installed to build the python bindings... Go check out the link I posted on page one. Really. There is nothing wrong with BLFS and it will save you the time and agrivation of having to figure out all this stuff by trial and error. Why re-invent the wheel?

I second that

So, nykey, your first answer here was completely wrong. Thanks so much for your help, only cost me about 4 hours compiling kdebase for SFA. Hey ho.
Anyway, looks like the latest version of Dbus has been split into to many seperate pieces of software to make this worth exploring anymore. At least at the moment. Can´t believe in the 21st century that this situation still exists where software a need software b, needs software c etc etc etc. Are the software writers not clever people who ought to bundle all needed software together in a single package, then get the install routine to just install those parts that are not currently on the box it is being installed to.
Anyway, life is just to short to waste anymore time on this, and as a longish time slackware user, (since 9.2), I will persevere, but this has almost got me to the point where I am considering moving to Mepis, where this particular feature just works first time out of the box.

Thanks for all your contributions. As it seems, the problem is caused by a change in KDE 3.5.4 ("almost HAL only kioslave").

I am surprised, however, that some of you also running -current seemingly don't have that very problem. But to answer some of your questions first:

- I don't want to have anything automounted.
- I would like to get a USB stick or harddisc mounted by clicking on its icon in the "System" folder on the KDE desktop
- In Slackware 10.2 stable this used to work with suitable entries in /etc/fstab provided; some of you suggested to try this, but in fact this is exactly what stopped working, although it was just fine in 10.2
- In Slackware -current (11 RC3) it stopped working, probably due to a problem in KDE 3.5.4, seemingly related to kioslave needing HAL; this would render KDE useless on non-HAL systems, I am afraid, and I really hope for a fix (because I like KDE)

Thanks for the pointers to docs explaining how to build my own HAL from source. Actually I would like to avoid that, because once Slackware 11 is out I plan to stop using -current and stick to -stable, like I did with 10.2 and earlier. I only experiment with -current, at the moment, in order to find out what I have to watch for, when I do the upgrade on production machines.

Once the upgrade is done, I prefer to rely on "vendor patches". That's one reason why I switched back from Postfix to Sendmail, BTW: If there's a security patch, Pat will make it available as a Slackware package, which is easy to install. If you compile a package from source, you must be an expert for that package in order to know which compile options to set, etc. And for how many packages to you really want to become and expert, and how much time do you have to watch for fixes and patches yourself, when you actually are not an admin, but a user, who just wants to get some work done on a rock solid system?

Not that I ever had a problem with -current, when I used it. I still prefer a -stable installation on production machines.

That was a bit off-topic, but I felt the need to explain why I don't want to compile my own HAL or other package from sources. No problem with simple packages, but with packages like Sendmail MTA or HAL I would like to avoid the risk of setting wrong options leading to security problems or instabilities.

gargamel

Which versions did you use? You should note that versions of HAL beyond 0.5.7 require PAM. If you haven't got PAM installed, it won't work properly.

I did exactly the same thing you did with the following:
DBUS-0.61
HAL-0.5.7
pmount-0.9.11

And then re-compiled kdebase with "--with-hal" enabled in the SlackBuild script, and it worked for me.

There must be something you're doing wrong. Did you add your user to the "haldaemon" and "messagebus" groups?

Also, does "ps ax" show HAL & DBUS running upon boot?

So there we are then, this illustrates my point exactly.
Nowhere on the HAL website http://freedesktop.org/wiki/Software/hal does it mention needing PAM as a dependency, and I compiled HAL with the --enable-fstab-sync, so have no need for pmount. However, I am willing to try this method.
Still doesn´t answer the question though, that if the developers of HAL know all of these dependencies are needed, then why not just include them in the download?
Anyhow, off to recompile DBUS again with the --with-qt switch, even though the install info says that this is not needed as it is detected automatically, and my environment meets all the criteria for auto detection.
Will report back if I get it going or not.

Some success,

Have recompiled Dbus with the --with-qt switch, then recompiled kdebase. Now, when I plug an external device in, I get an icon pop-up on the desktop, and can mount whatever it is. This was not the object of the exercise, but simply to get back the ability to have the kioslave-media link working again in konqueror. It also now does this, but, and this is strange.
Under control centre -> peripherals -> storage media, the enable hal backend box is still greyed out.
Also, right clicking on a mounted device and choosing safely remove is not working.
Still, will crack on and try to find answers to these 2 problems and post them here.

You know what ? I wanted to say a thing or two, but it's not worth it... you should think again then come here and tell me that I wasted 4 of your hours because you DO NOT read the dependencies of every package needed. And most of all, I didn't FORCE/TELL YOU to do that, or this, or whatever... I've just given a hint to gargamel from where to start. So please, watch your words !

*EDIT*

Btw, here's my first answer Why is it completly wrong ? Cause I didn't tell you that HAL needs this and that, and because I didn't tell you EXACTLY the parameters for configuring the software ? If you want to do something, speare some time and read the man's, info, help, FAQ's, etc ... not just waiting for someone to lay it down for you and then call him completly wrong.

Calm down, guys, vdemuth probably just was disappointed after going through all the hassle and having no success in the end --- certainly his reply wasn't meant to offend anybody, it was just affected by his disappointment, and not targeted to any particular person --- although I cannot really speak for him, that's what I think.

I guess what vdemuth was actually going to say was this: It takes quite some effort to get HAL running properly on Slackware, raising the question if it is worth it. On the other hand, some things in KDE won't work without HAL, as it seems.
He should have said this in other words, of course.
@vdemuth: Correct me, if you feel I misinterpreted your posting.

@nykey: Thanks for your helpful assistance. Your hint was correct, however, only if you really try it out it becomes clear that there's more to the two steps you mention. Thanks for your patience!

Now, let's get back in the usual Slackware forum mode: Friendly users help friendly users. This culture is part of what Slackware makes so attractive. Let's keep it up!

gargamel

Well said gargamel, and my apologies if I offended anyone, but frustration sometimes gets the better of plenty of people.
Anyway, have got it working at last, except for the greyed out box showing kde hal support, but that might well be a bug in kde. For anyone who stumbles across this post, here is how I achieved it:--
Download and compile HAL-0.5.7.1 from this link: http://people.freedesktop.org/~david...0.5.7.1.tar.gz
Configure with the --enable-fstab-sync switch.
Dowload and compile DBUS-0.6.2 from here: http://dbus.freedesktop.org/releases...us-0.62.tar.gz
Configure with the --with-qt switch. Even though the documentation says this should be autodetected, in my case it was not.
Create Slack packages of both with checkinstall, and install using installpkg.
Download and compile KDEBASE using the slackbuild version from any slackware mirror, but use the --with-hal switch. Install the newly compiled kdebase.

create this script for /etc/rc.d/rc.hald:

#!/bin/sh
# Start/stop/restart the hal daemon.

hal_start() {
if [ -x /usr/sbin/hald ]; then
if [ `/sbin/kernelversion` == "2.6" ]; then
echo "Starting HAL daemon: /usr/sbin/hald --daemon=yes"
/usr/sbin/hald --daemon=yes
else
echo "Kernel 2.6 is required for HAL features."
fi
fi
}

hal_stop() {
killall hald
}

hal_restart() {
hal_stop;
hal_start;
}

case "$1" in
'start')
hal_start
;;
'stop')
hal_stop
;;
'restart')
hal_restart
;;
*)
echo "usage $0 start|stop|restart"
esac

Thanks to Mark Veinot and Jan Zahornadsky for the script from this site http://wiki.kde.org/tiki-index.php?page=DBUS

Edit /etc/rc.d/rc.local, and insert the following:

# start the hal and messagebus stuff here:
# to allow detection and automounting
# of external usb devices, plus other
# mountable media, e.g. cd and dvd rom drives

if [ -x /etc/rc.d/rc.messagebus ]; then
if [ -w /var/run/dbus/dbus.pid ]; then
rm /var/run/dbus/dbus.pid
fi
sh /etc/rc.d/rc.messagebus start
fi

if [ -x /etc/rc.d/rc.hald ]; then
sh /etc/rc.d/rc.hald start
fi

# end hal etc here

Near the start of the rc.local file, as placing it later seems to disable the right mouse click safely remove hardware function in kde.

This approach has worked for me, without any changes to my fstab, and without the need for PAM or PMOUNT, so at the moment I am fairly happy with it. Just need to test for stability now, but time will tell on that one.

Personally, I'm not 100% comfortable with the fact that /etc/fstab is re-written every single time a USB key is inserted. So I use pmount instead. I have it working this way under Slackware current.

The odd thing is, fstab isn´t being written to as I haven´t made any of the required changes to it to allow fstab-sync to be used, and it still works. One thing that I can´t seem to get going though is the automatic playback of DVDs. Not that important I know, but now I´ve struggled through and gotten this far it would be nice. Have you any ideas?

vdemuth is your post #25 really what you did to get this working? i too am interested in adding this when 11 comes out is why I ask and so far that seems to be a pretty good explanation for hal on slack. if it's not everything would you mind updating it when you have completed your install of HAL please? thank you in advance.

Yep. That's pretty much it Old_Fogie.

There are "cleaner" ways of calling rc.hal & rc.messagebus, but vdemuth's way certainly works.

Yes, that is what I did to achieve the results I got. As I have pointed out, it still does not autolaunch into my Media Player on insertion of a DVD Videodisc, but I am happy so far. rkelsen, I would be interested in the cleaner way to call rc.hal and rc.messagebus. Can you enlighten?