Re: [gentoo-user] depclean wants to remove hal, which kills xdm
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?
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
On Tue, Dec 21, 2010 at 6:41 AM, Allan Gottlieb gottl...@nyu.edu wrote: SNIP 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? To me, yes. If you make a mistake and depclean hal by mistake then it seems you can get it back in. allan PS Why is no one else having this problem? I don't use xdm? Granted, it seems my current state is a bit strange. There is a lot of stuff on my system that says it depends on hal, but then again i don't start it explicitly. Other things apparently do however: c2stable ~ # equery depends hal [ Searching for packages depending on hal... ] app-cdr/k3b-2.0.0 (sys-apps/hal) app-emulation/vmware-workstation-7.1.2.301548 (sys-apps/hal) app-misc/hal-info-20090716 (=sys-apps/hal-0.5.10) gnome-base/gnome-applets-2.30.0-r1 (battstat hal? =sys-apps/hal-0.5.3) gnome-base/gnome-vfs-2.24.3-r1 (hal? =sys-apps/hal-0.5.7) gnome-base/gvfs-1.6.4-r2 (hal? =sys-apps/hal-0.5.10) gnome-extra/gnome-power-manager-2.30.1 (hal? =sys-apps/hal-0.5.9) kde-base/solid-4.4.5 (hal? sys-apps/hal) media-libs/libgphoto2-2.4.9 (hal? =sys-apps/hal-0.5) x11-base/xorg-server-1.7.7-r1 (hal? sys-apps/hal) x11-drivers/xf86-input-virtualbox-3.2.12 (hal? sys-apps/hal) xfce-base/exo-0.3.107 (hal? sys-apps/hal) xfce-base/thunar-1.0.2 (hal? sys-apps/hal) c2stable ~ # rc-update show bootmisc | boot checkfs | boot checkroot | boot clock | boot consolefont | boot dbus | default hostname | boot keymaps | boot local | default nonetwork localmount | boot modules | boot net.eth0 | default net.lo | boot netmount | default ntp-client | default ntpd | default rmnologin | boot sshd | default syslog-ng | default udev-postmount | default urandom | boot vixie-cron | default vmware | default xdm | default c2stable ~ # /etc/init.d/hald status * status: started c2stable ~ # I sort of figure that one of these days I'll see what I can build that uses it today without it and then see how things go. In the short terms it's sort of 'it ain't broke so...' Note that I don't 'try' to use hal. It just shows up. I don't ask for it in package.use and it's supposedly disabled in make.conf. Ah, the mysteries of Life... ;-) c2stable ~ # cat /etc/portage/package.use | grep hal c2stable ~ # cat /etc/make.conf | grep hal USE=nptl nptlonly -ipv6 fortran unicode -hal dbus X -bluetooth -esound -timidity -cups -java gnome gstreamer kde qt4 qt3support -arts -eds pngi policykit c2stable ~ # Cheers, Mark
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
Allan Gottlieb wrote: Dalerdalek1...@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 :-) :-)
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
On 12/21/10 15:41:20, Allan Gottlieb wrote: My plan is to stay like this until xorg 1.9 hits ~amd64 since I It is already unmasked in ~amd64 (It's running just fine here) Helmut.
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
On 12/21/2010 9:41 AM, Allan Gottlieb wrote: To summarize 1. All is running fine but. 2. deplcean wants to remove hal and when it does xdm will not run. Is it just xdm that doesn't run? That is, if you disable xdm and log in via the console, can you run startx? It's possible that your Xorg configuration is relying on some device or setting that HAL is providing for you but udev itself isn't. (Can't think of anything specific offhand, though). If this were the case, trying to run X by itself as root should also fail. You would also see the errors in your Xorg.0.log file, pointing to whichever device is the problem. To fix this, you'd need to find and remove the offending device reference. A good first start is to try simply removing any xorg.conf you happen to have lying around and let X try to find everything itself (without HAL). --Mike
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
Helmut Jarausch jarau...@igpm.rwth-aachen.de writes: On 12/21/10 15:41:20, Allan Gottlieb wrote: My plan is to stay like this until xorg 1.9 hits ~amd64 since I It is already unmasked in ~amd64 (It's running just fine here) Bingo. There was a mesa problem a while ago (7.8.2) that caused me to mask =media-libs/mesa-7.8.2. This caused me to mask xorg-server above the current running one. I didn't notice that mesa did advance and I am running 7.9-r1. So I just now unmasked both mesa and xorg-server and update world updated xorg-server and xinit. Let's see if this now permits me to let depclean remove hal. thank you all for your help! allan
[gentoo-user] depclean wants to remove hal, which kills xdm
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 can easily add hal to world, but should xdm depend on it? allan
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
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. Have you look on how X.org packages are built on your computer. You should build it with udev support. I can easily add hal to world, but should xdm depend on it? allan -- Vincent-Xavier JUMEL GPG Id: 0x2E14CE70 http://thetys-retz.net Rejoignez les 5312 adhérents de l'April http://www.april.org/adherer Parinux, logiciel libre à Paris : http://www.parinux.org
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
Vincent-Xavier JUMEL endymion+gen...@thetys-retz.net 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.
Have you look on how X.org packages are built on your computer. You
should build it with udev support.
I think it is enabled for xorg-server
gottl...@ajglap ~ $ eix xorg-server
[I] x11-base/xorg-server
Available versions: 1.7.6 1.7.7-r1 [m](~)1.8.2 [m](~)1.9.2
[m](~)1.9.2.902 {debug dmx doc hal ipv6 kdrive minimal nptl sdl static-libs
tslib +udev xorg}
Installed versions: 1.7.7-r1(09:59:41 AM 12/19/2010)(ipv6 kdrive nptl sdl
xorg -debug -dmx -hal -minimal -tslib)
Homepage:http://xorg.freedesktop.org/
Description: X.Org X servers
To be sure I temporarily added it to make.conf but an emerge update
world did not want to merge any packages
I can easily add hal to world, but should xdm depend on it?
I still wonder why xdm, which claims to need hal doesn't depend on it
and why suddenly depclean wants to remove it.
allan
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
On Monday 20 December 2010 15:55:40 Allan Gottlieb wrote:
Vincent-Xavier JUMEL endymion+gen...@thetys-retz.net 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.
Have you look on how X.org packages are built on your computer. You
should build it with udev support.
I think it is enabled for xorg-server
gottl...@ajglap ~ $ eix xorg-server
[I] x11-base/xorg-server
Available versions: 1.7.6 1.7.7-r1 [m](~)1.8.2 [m](~)1.9.2
[m](~)1.9.2.902 {debug dmx doc hal ipv6 kdrive minimal nptl sdl
static-libs tslib +udev xorg} Installed versions: 1.7.7-r1(09:59:41 AM
12/19/2010)(ipv6 kdrive nptl sdl xorg -debug -dmx -hal -minimal -tslib)
Homepage:http://xorg.freedesktop.org/
Description: X.Org X servers
**
Installed versions: 1.7.7-r1(09:59:41 AM 12/19/2010)(ipv6 kdrive nptl sdl
xorg -debug -dmx -hal -minimal -tslib)
**
It's installed with hal disabled.
To be sure I temporarily added it to make.conf but an emerge update
world did not want to merge any packages
Add --newuse to the flags and it should pick it up:
emerge -vauD --newuse world
I can easily add hal to world, but should xdm depend on it?
I still wonder why xdm, which claims to need hal doesn't depend on it
and why suddenly depclean wants to remove it.
See above, hal isn't added to the installed xorg-server use-flags
--
Joost
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
Allan Gottlieb wrote:
Vincent-Xavier JUMELendymion+gen...@thetys-retz.net 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.
Have you look on how X.org packages are built on your computer. You
should build it with udev support.
I think it is enabled for xorg-server
gottl...@ajglap ~ $ eix xorg-server
[I] x11-base/xorg-server
Available versions: 1.7.6 1.7.7-r1 [m](~)1.8.2 [m](~)1.9.2
[m](~)1.9.2.902 {debug dmx doc hal ipv6 kdrive minimal nptl sdl static-libs
tslib +udev xorg}
Installed versions: 1.7.7-r1(09:59:41 AM 12/19/2010)(ipv6 kdrive nptl
sdl xorg -debug -dmx -hal -minimal -tslib)
Homepage:http://xorg.freedesktop.org/
Description: X.Org X servers
To be sure I temporarily added it to make.conf but an emerge update
world did not want to merge any packages
I can easily add hal to world, but should xdm depend on it?
I still wonder why xdm, which claims to need hal doesn't depend on it
and why suddenly depclean wants to remove it.
allan
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?
I hope this gives you ideas.
Dale
:-) :-)
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
On 12/20/2010 10:04 AM, J. Roeleveld wrote: 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. Installed versions: 1.7.7-r1(09:59:41 AM 12/19/2010)(ipv6 kdrive nptl sdl xorg -debug -dmx -hal -minimal -tslib) ** It's installed with hal disabled. And, you should probably leave it that way. HAL is going away, so there's no point in rebuilding X just to get HAL support now. You should start by just rebuilding XDM and see if it's HAL requirement goes away. You could also try a good revdep-rebuild, though I'm not sure HAL is a link-time dependency that will get picked up that way. --Mike
