Very nice, thank you for the heads-up. Updated my first post to reflect the changes.

@haarp: I guess the move from x11-overlay to Portage pretty much coincided with our conversation. _________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

and I had to add "media-libs/mesa -gallium" to /etc/portage/profile/package.use.mask
to get mesa to compile with the gallium flag, I'm using the nvidia 195.36.15 driver,
though I have added "nouveau" to the video drivers and will probably play with it some
in the near future.

With the dirty nvidia hack, and a change in my USE flags to -hal udev + an emerge --newuse world, everything is working fine except for soprano & hotplugging in KDE, though that is a KDE issue... and an issue I really don't care much about. (cli always works)

Why are you all removing hal completely? The ebuild detects if udev is activated and deactivates hal for xorg-server and everything works fine here.

hal is deprecated and not in development anymore. I'm not saying jump off right now, but plan ahead, because sooner than later hal will be no more.

Anyway since xorg 1.8 was just pushed to ~amd64, I went ahead and installed it. Had to add "IgnoreABI" to my (now minimal) xorg.conf and remove the dependency of the nvidia-drivers in my local overlay thought.

Any ideas on how long until these changes might go stable in portage? About half my system is now ~x86 using /etc/portage/package*
and I just don't want to add any more packages to the lists, but looking forward to removing HAL for a pure udev setup.

BTW, one of the reasons I don't want to do this manually now, is I am stuck using nvidia-drivers-173.* for the moment. I think that would
complicate things, or am I wrong?

As a KDE user, I've set -hal for xorg-server specifically and let it otherwise turned on.

Running KDE 4.x without hal isn't a good idea for now. Several things won't work, with mass storage hotplugging and sound among them._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

By the way, can I set -hal inside my /etc/make.conf or I will crash for sure my KDE installation ?

You could just take it out of your USE-Flags. Packages which still depend on HAL will enable it for themselves, and packages which have optional HAL support (or usage or whatever) will work fine without.

"eix" says I have 9 packages with hal use-flag, but only app-laptop/laptop-mode-tools and sys-fs/ntfs3g set it by default, the other 7 are emerged without hal. (Or updated yesterday to work without, because I simply removed it from my USE-flags.)

@XQYZ: Yes, it will eventually die. But why break your apps by manually uninstalling something that is still in use? Would you unmerge your gcc before the new version is installed?

And btw.: Nothing broke down here, everything works perfectly well with KDE-4.4.2 and hald running.

Edit: The packages I have that do depend on hal without USE-Flag:
(Note: I deleted all lines where the dependency is set by hal USE-Flag)

I'm having some problems automounting my external devices (USB, CD) after getting rid of HAL. When I plug the device in, udev correctly assigns a device node (/dev/sdX) and I can mount and unmount the device as a regular user invoking:

Code:

udisks --mount /dev/sdb1

However, when the system tries to automount or I try to mount via the Gnome Places menu, I get a dialog saying "Unable to mount 2.0 GB Filesystem: Not Authorized".

I've started consolekit in debug mode and this is what is written on /var/log/messages when I try to mount a device:

By the way, can I set -hal inside my /etc/make.conf or I will crash for sure my KDE installation ?

You could just take it out of your USE-Flags. Packages which still depend on HAL will enable it for themselves, and packages which have optional HAL support (or usage or whatever) will work fine without.

Not going to work for users of the desktop profile which sets +hal automagically. So you either have to disable it in your make.conf and manually enable it on a per-package basis (which is what I'm most likely going to to) or wait for the next profile update.

Edit: Oh well, setting -hal just brought up ntfs3g and libgphoto2 to rebuild since I already had filtered USE of it:

I do wonder though about the shortness of this list. So, even if for example e17 and KDE-4.4.2 are missing on that list, hal seems to be a silent dependency for many packages which simply won't provide some services if they find it disabled.

@Yamakuzure: sys-power/pm-utils-1.3.0-r1 does not depend on hal anymore. _________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

I had tried to write "setxkbmap xx" in my xinit script, but it won't work, instead it have to be manually executed in a terminal each time after X started. this is the only issue so far I found out with xorg-server-1.8.0 with nvidia-driver-195.36.15 on my 8400GS card

So is the correct way to configure your keymap to go back to using xorg.conf? KDE here obviously sets it up for gb here after login, but the kdm login window still uses the default US keymap - not a major problem, admittedly, but it would be nice to get it right.

Go on, someone post me a nice c&p I can pop in xorg.conf. You know you want to _________________Jingle Jangle Jewellery

So is the correct way to configure your keymap to go back to using xorg.conf? KDE here obviously sets it up for gb here after login, but the kdm login window still uses the default US keymap - not a major problem, admittedly, but it would be nice to get it right.

Go on, someone post me a nice c&p I can pop in xorg.conf. You know you want to

I have this

Code:

Section "InputDevice"

Identifier "Keyboard1"
Driver "kbd"

# Set the keyboard auto repeat parameters. Not all platforms implement
# this.