Hello All

I've got dropline-gnome on my slack 11 and their inclded HAL working flawlessly with Rob Workmans build scripts for XFCE 4.4 http://rlworkman.net/pkgs/sources/11.0/xfce-4.4.0/ in case any one needs that to advise.

It's really sweet, ubuntu and xubuntu can't hold a candle to this 'bad boy' I know Mr. Pat V doesn't give the "same nod" (due to packages changes to which point I can understand) as other gnomes' for slack, but as far as I'm concerned for my "needs" the hard work of both Rob's xfce build & and the Dropline Team's really getting me jumping up and down with delight. I almost feel 'whole' here, but I'd like to see if the same can be done for KDE. Well, actually it's to get Mrs. Fogie off my back about the darn camera cards, she's the KDE user here hahaha. I've tried going the udev rules route, I must be a spaz but I can't get statick udev's for camera memorie's and printers...so I'm hoping to get the HAL going here. I have googled and read thread's to no avail.

Interestingly enough if Rob should read this, I only needed the URI escape perl and the xfce to build and run properly on dropline as dropline has already taken care of the vte, the udev, dbus and dbus-glib and other required's (tho dropline calls it dbus-bingings I believe).

Anyway from all the threads that I have seen here, it is suggested to re-compile the kdebase with Mr. Pat V's build script using --with hal in the build script.

I figured out that I had to add to the top of the build script the i486 and kdebase version number at top of the build script, and '-j3' for numjobs (not sure how Mr. Pat V configure's local options....so I tweaked the script).

Now I get a build of my tweaked kde-base. I then removepkg & installpkg the new and no go. The only error's that I see of any kind while passing my build script to the "|tee /home/fogie/buildkde.log" is a fontconfig...la has been moved error but I think that's a dropline bug? as they changed fontconfig and freetype packages, however it see's the font database and add's correctly as it should according to my running build log file. So my build appears to be correct, well assuming that I had tweaked it right lol.

I have not removed any of the patches that Mr. Pat V includes in source for kdebase, I'm only adjusting the buildscript as above, maybe that's it? There is a few diff patches there regarding HAL, possibly they are superceding the arguments I'm passing to the script. Maybe the stock kde in slack 11 requires different versions of udev, dbus and HAL than that included in dropline?

Can anyone shed any light on this for me? Has anyone found Utopia?

Thank you in advance, Slack On!

That's probably fixable, *but* the better option in your case is likely the other one...

That sounds right - they probably bundle several of the bindings together.
I don't know if they include the qt bindings (I'd guess that the answer to that is no, but check anyway), and if not, you'll need those. They've been added to Slackware -current, so you can get a good SlackBuild script for them from the -current sources. Those will need to be installed prior to rebuilding KDE with HAL support.

Correct.

There is a file named KDE.Options in the toplevel source/kde/ directory that the kdebase script references - that file defines the VERSION, BUILD, and other variables that you will need to rebuild kdebase properly. Just put that file in the directory above your kdebase sources - of course, make any necessary edits to it.

Yeah, you'll need to remove the references in the SlackBuild script to those HAL-related patches.

I've not personally done much at all with HAL, so some of the DLG guys can probably expand on this a bit.

I'd be willing to work with you in getting the static device links in place with udev - it shouldn't be too much trouble, and you only have to do it once [1].
After the static device links are set up and added to /etc/fstab, I think you will find that Xfce's mount plugin for the panel is extremely handy. One of the features of the new version allows you to make it ignore some devices in /etc/fstab; therefore, you don't confuse your wife with the / filesystem and such showing up - only removable devices will be listed (and you can even customize it further to ignore some of those).

With all that said, it might be useless to you, as you indicated that she is a kde user. I wonder, though, if she might actually find Xfce more usable. If she uses a lot of kde apps, then you can set up her Xfce session to start the kde services - that way, she'll still have the fast loading time of kde apps.

On the subject of kde, I guess you've already discovered this bug:
http://bugs.kde.org/show_bug.cgi?id=136123
(which is probably why you want HAL support with it)


[1] Well, not until you upgrade to the next version of Slackware. It will have a newer udev version, and that certainly means that some of the rule syntax will have changed.

Hey hey rob

Thanks for the input.

I didn't know of qtbindings, I will have to go find that.

To questions tho:
1.) from the link you gave me to the kde site, would trying to get kde/HAL going on this work or not work? or is it that thread just about the right click in konqueror only issue. i could put icons on the desktop and mount/unmount from there for devices if it's just a konqueror issue assuming I get the HAL to work.

2) Assuming hal can be done, would you suppose that I simply make/install the qtbindings over the existing dbus and dbus bindings/glib of dropline, then remove the references to the hal fixes in slackware's build script then make/install the new kdebase?

Thanks in advance

Hi!

The kde bug I referenced shouldn't affect mounting things with HAL.

The first answer depends on whether DLG's dbus-bindings package includes the qt bindings.
The second answer is yes.

Hey Old_Fogie:-)

Is it possible to have your monitor go into power save mode using Dropline gnome? In KDE 3.5.4 (Slack 11, 2.6.18 kernel) I add Option "dpms" to my monitor section of xorgconf and my monitor powers down after a pre-determined time.
Will this work in Dropline? Just curious:-)

it works for me, try this in monitor section?

@rworkman

Thanks for the 'exp-e-e-e-delicous' reply, I'll go find that qt bindings run a make, see what it makes and explode the dropline package and compare and see.

Tar Tar 4 now.

Thanks for your reply, Old_Fogie!
Just to confirm then, Old_Fogie. Are using Option "dpms" or Option "dpms" "true" in your monitor section? And your monitor goes into power-save mode?
If that is working for you I'll give Dropline another go and set it as my default environment.
Thanks, man:-)

yes I use it as I wrote there, and it does work for me.

the only thing is to remember that gnome has the power management settings in it's own section in preferences pull down menu than the screensaver.

Okay, thanks, man:-) I'll try Option "DPMS" "true" in the monitor section and enable power saving in the pull down menu. Time to give gnome another shot:-)

To clarify a few things, no, Dropline doesn't actually ship qt bindings in that particular package, because we've not needed it. Qt isn't even installed on my devel box. Qt is going to have to move out of /opt before I'm going to be terribly willing to install it.

I can't really see the dbus-qt bindings being hard to build, but they're in a slightly "interesting" state at the moment with the qt3 bindings being backported from the qt4 bindings. I'm kinda hoping with 12 that Pat'll stop doing that business with /opt and that KDE will be using qt4 (which will eliminate this as an issue entirely).

The freetype thing on the other hand is really a non-issue. Libtool (which is what's reading those .la files) is not very bright and does not know the difference between /usr/lib/libfreetype.so and /tmp/src/foo/../../../usr/lib/libfreetype.so, even though after you squint your way around all the double-dots you can tell they're the same file. Gcc and various Makefiles do lots of dandying about with directory up-references to create their paths, and every time gcc pulls in a library using an include path that has double-dots in it and libtool sees it, libtool thinks the filenames don't match and that the library has been moved so it whines about it--even though it's pretty apparent that nothing's actually been moved.

You should see Evolution build. In some spots libtool carps about 15 times in a row for practically every invocation of gcc.

Pat has put kde in /usr now for Slackware -current, and qt is (as it has been) also in /usr. At the moment, the only thing in /opt now is htdig (which, to my knowledge, is only needed by kde).

As for qt4 and kde4, I suppose that will depend on how soon it (kde4) releases and how stable it is.

I decided to try and get HAL working with xfce first but not to use the HAL from dropline-gnome.

Not that I'm in anyway opposed to dropline-gnome, as I'm using it on my main pc

However, I have other & much older pc's that are better suited for xfce then gnome or KDE, simply put they don't have the hard drive space on them, for example an old laptop I have has only 4 gig drive on it, and the minimal install for dropline-gnome over and above full install of slack 11 cd 1 fills the drive, and dropline-gnome really does need all files from cd1 in place at the time of loading. Apparently their minimal install is not functional at this time according to their forums or else I'd just use that and be done.

So my search continues, here's where I'm at:

Starting point, "full nooob" install of 2.4.33.3 ide generic kernel of slack 11.

Reboot, install the huge26.s kernel, modules and source. I Did not install headers.

1.) create messagebus group & user using rob's technique

2.) make tgz from rob w's dbus version 1.0.2 slackbuild script dated 1/25/07 (no rworkman version so I can only give date)

3.) make tgz from rob w's dbus-glib version 0.72 slackbuild script dated 12/15/2007

4.) make tgz from rob w's vte version 0.14.1 but change version to be 0.15.1 and remove pushd/popd

5.) make tgz from rob w's gamin version 0.18 slackbuild dated 01/25/2007

6.) make tgz from rob w's uri-perl version 1.35 slackbuild script dated 01/29/2007.

7.) download all files from slacky.it for hal version 0.5.8.1 from here:
http://www.slacky.eu/repository/slac...l/0.5.8.1/src/

and the buildscript makes a tgz in 10 seconds! with barely anything in it!

this error is spammed in the terminal:
"checking for BLKGETSIZE64... no
configure: error: BLKGETSIZE64 is not defined
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
"

Which after many hours of trying to figure out what that was/meant, it boils down to this:

1. slack 11's /usr/include is 2.4 kernel, hal want's the 2.6 kernel header's which obviously have the big fat warning in /extra.

So I put in the 2.6 headers, and in a few minutes I have the HAL tgz.

8.) restore pc from an image...I don't want the 26 headers in the system.

9.) install all tgz's from steps 1 thru 8.

10.) build xfce 4.4 from rworkman's script dated 2/6/07

Woohoo hal works!

However I have two new problems:

1. sshd spams this in my /var/log/syslog:
"sshd[2257]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use."

I think? that's becuase rc.messagebus is writing securely to /tmp I don't know?

2. The above only works if I use /etc/inittab at run-level "3". As kde is on the system right now, it appears KDM does not allow me to use hal. WTH! Maybe I'll try my hand at slim again, tho I found that it can break and deny me access to log in to my computer at times.

Most importantly I want the ssh to work so that I can use ssh and freenx from that pc which goes out into la-la-land over ssh ya know

If I can get this licked, then I think I'll try my hand at the KDE, but gosh, that is a real mess if you look at slacky.it's buildscripts for that...holy cow. Their scripts aren't a mess, I mean, look at the number of patches and all... overwhelming.


Thanks in advance.

figured out the ssh issue...it was the old ipv6 messing with me I forgot the stock huge26 kernel kills ssh in slack..just added to blacklist in modprobe.d and now it's a non-issue.

well off to try kde now w/dropline hal