Allan Gottlieb wrote:
Dale<rdalek1...@gmail.com> writes:
Le 20 décembre à 15:12 Allan Gottlieb a écrit
Something seems wrong.
Yesterday depclean removed hal and then xdm wouldn't run.
Re-merging hal (with -1) fixed this, but again today depclean wants to
remove it.
I'm running amd64 here but xdm doesn't show it needing hal here. It's
not even in the USE flags and I did a emerge -epv xdm and it still
didn't show it. It did pull in policykit tho.
Could it be that it doesn't use hal anymore and you need to figure out
what it is using? I know hal is going away but I haven't read that it
already was. That said, I did notice that policykit was pulled in
yesterday. Of course, xdm doesn't show it needs it either. Could it
be udev?
To summarize
1. All is running fine but.
2. deplcean wants to remove hal and when it does xdm will not run.
3. I have run emerge world with --newuse, and have run revdep-rebuild,
and have remerged xdm.
4. Currently I just refuse depclean's offer to remove hal, halinfo, and
dmidecode.
My plan is to stay like this until xorg 1.9 hits ~amd64 since I believe
at that time hal is going away and hence xdm won't need it.
Does this sound reasonable?
allan
PS Why is no one else having this problem?
Well, if it helps any, I'm already running xorg 1.9. Here is my list:
[I--] [ ~] x11-base/xorg-drivers-1.9 (0)
[I--] [ ~] x11-base/xorg-server-1.9.2.902 (0)
They are working fine here so you may want to just go ahead and
upgrade. This is the settings for mine here:
[ebuild R ] x11-base/xorg-server-1.9.2.902 USE="ipv6 nptl udev xorg
-dmx -doc -kdrive -minimal -static-libs -tslib" 0 kB
It uses udev instead of hal. I didn't have to run a unstable version of
udev either.
I'm sure it is some sort of setting somewhere but no idea why you are
the only one running into this.
Dale
:-) :-)
