Re: [gentoo-user] scrapping hal
On Thursday 28 October 2010 04:50:18 Dale wrote: I think KDE is moving away from hal to tho. I read somewhere the switch is coming. I think it is switching to policykit at some point. I notice it is already in the USE flags for kdelibs here, disabled here at the moment tho. That would be if it doesn't change again. On this ~amd64 box: $ emerge -pv xorg-server [...] [ebuild R ] x11-base/xorg-server-1.9.1 USE=ipv6 nptl udev xorg - dmx -doc -kdrive -minimal No mention of hal there. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] scrapping hal
Peter Humphrey wrote: On Thursday 28 October 2010 04:50:18 Dale wrote: I think KDE is moving away from hal to tho. I read somewhere the switch is coming. I think it is switching to policykit at some point. I notice it is already in the USE flags for kdelibs here, disabled here at the moment tho. That would be if it doesn't change again. On this ~amd64 box: $ emerge -pv xorg-server [...] [ebuild R ] x11-base/xorg-server-1.9.1 USE=ipv6 nptl udev xorg - dmx -doc -kdrive -minimal No mention of hal there. They are probably already moved away from hal. Everybody knows it is going and that is a bleeding edge version of xorg too. I'm still on 1.7.*. Which brings me to my next question. How is xorg 1.9 working for ya? Any gotchas? May try it here. Dale :-) :-)
Re: [gentoo-user] scrapping hal
On Thursday 28 October 2010 11:46:30 Dale wrote: Which brings me to my next question. How is xorg 1.9 working for ya? Any gotchas? May try it here. No problems so far. I had to unmask a more recent version of xorg because version 1.7.7 was incompatible with kernel 2.6.36. Well, I could have gone back to an earlier kernel, but what the hell? -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] scrapping hal
Apparently, though unproven, at 12:46 on Thursday 28 October 2010, Dale did opine thusly: Peter Humphrey wrote: On Thursday 28 October 2010 04:50:18 Dale wrote: I think KDE is moving away from hal to tho. I read somewhere the switch is coming. I think it is switching to policykit at some point. I notice it is already in the USE flags for kdelibs here, disabled here at the moment tho. That would be if it doesn't change again. On this ~amd64 box: $ emerge -pv xorg-server [...] [ebuild R ] x11-base/xorg-server-1.9.1 USE=ipv6 nptl udev xorg - dmx -doc -kdrive -minimal No mention of hal there. They are probably already moved away from hal. Everybody knows it is going and that is a bleeding edge version of xorg too. I'm still on 1.7.*. Which brings me to my next question. How is xorg 1.9 working for ya? Any gotchas? May try it here. xorg-server 1.8 and 1.9 use mesa-7.8.2, and there's reports around that that version of mesa causes desktop slowdowns. mesa-7.7.1 as used by xorg- server-1.7 is reported to be fine Me, I'm undecided. I have a slow sluggish desktop, but it might be the nvidia drivers, mesa, X-server, kernel config, wrong elevator or even just the shitty IO scheduler design on desktops that the kernel devs are recently waking up to admitting to. Lots of stuff to change one at a time and see what results... -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] scrapping hal
Alan McKinnon wrote: Apparently, though unproven, at 12:46 on Thursday 28 October 2010, Dale did opine thusly: Peter Humphrey wrote: On Thursday 28 October 2010 04:50:18 Dale wrote: I think KDE is moving away from hal to tho. I read somewhere the switch is coming. I think it is switching to policykit at some point. I notice it is already in the USE flags for kdelibs here, disabled here at the moment tho. That would be if it doesn't change again. On this ~amd64 box: $ emerge -pv xorg-server [...] [ebuild R ] x11-base/xorg-server-1.9.1 USE=ipv6 nptl udev xorg - dmx -doc -kdrive -minimal No mention of hal there. They are probably already moved away from hal. Everybody knows it is going and that is a bleeding edge version of xorg too. I'm still on 1.7.*. Which brings me to my next question. How is xorg 1.9 working for ya? Any gotchas? May try it here. xorg-server 1.8 and 1.9 use mesa-7.8.2, and there's reports around that that version of mesa causes desktop slowdowns. mesa-7.7.1 as used by xorg- server-1.7 is reported to be fine Me, I'm undecided. I have a slow sluggish desktop, but it might be the nvidia drivers, mesa, X-server, kernel config, wrong elevator or even just the shitty IO scheduler design on desktops that the kernel devs are recently waking up to admitting to. Lots of stuff to change one at a time and see what results... Since you are undecided, I'm decided. I'm sticking with what I have now. I just got mine to speed up again and I don't want to be trying to narrow down problems again. What's the old saying, if it's working, don't fix it. lol Dale :-) :-)
Re: [gentoo-user] scrapping hal
Apparently, though unproven, at 16:36 on Thursday 28 October 2010, Dale did opine thusly: What's the old saying, if it's working, don't fix it. What's the old saying, if it's working, don't fix it, until it's ancient, not supported and your box won't update world anymore so you are up the creek without a paddle and shit outta luck There ya go, fixed that for ya Dale :-) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] scrapping hal
On Thursday 28 October 2010 13:35:49 Alan McKinnon wrote: xorg-server 1.8 and 1.9 use mesa-7.8.2, and there's reports around that that version of mesa causes desktop slowdowns. mesa-7.7.1 as used by xorg- server-1.7 is reported to be fine This box has been the most sluggish box I've ever seen for several months now. Mesa-7.7.1 was not fine here - or something else wasn't. Me, I'm undecided. I have a slow sluggish desktop, but it might be the nvidia drivers, mesa, X-server, kernel config, wrong elevator or even just the shitty IO scheduler design on desktops that the kernel devs are recently waking up to admitting to. Lots of stuff to change one at a time and see what results... Puzzling, innit? -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] scrapping hal
Alan McKinnon wrote: Apparently, though unproven, at 16:36 on Thursday 28 October 2010, Dale did opine thusly: What's the old saying, if it's working, don't fix it. What's the old saying, if it's working, don't fix it, until it's ancient, not supported and your box won't update world anymore so you are up the creek without a paddle and shit outta luck There ya go, fixed that for ya Dale :-) Well, if I wanted to stay fairly ancient, I could have stayed with Mandrake. They were pretty slow to release packages and even then they were way behind. lol That's one thing about Gentoo, you get new stuff pretty quick even if you run stable. If you run unstable, you get things really quick, bugs and all. ;-) Speaking of ancient: Apr 16 2009 /boot/bzImage-2.6.23-r8-8 I still got that old kernel in there. I would be surprised if it would boot and work. I bet udev would really have issues with that old thing. I'm not running that tho. I am actually up to 2.6.35-gentoo-r4 so far. See, I'm not completely ancient. lol Dale :-) :-)
Re: [gentoo-user] scrapping hal
On Thu, Oct 28, 2010 at 10:25 AM, Dale rdalek1...@gmail.com wrote: That's one thing about Gentoo, you get new stuff pretty quick even if you run stable. If you run unstable, you get things really quick, bugs and all. ;-) Unstable is still pretty stable. If you really want to have fun start to use some live ebuilds and rebuild new versions each day from svn/git, and then deal with problems that occur because they expect some specific git version of a library, so you use live ebuild of that, which breaks other ebuilds which are made to work with the stable release, and... :)
Re: [gentoo-user] scrapping hal
Dale asks: They are probably already moved away from hal. Everybody knows it is going and that is a bleeding edge version of xorg too. I'm still on 1.7.*. Me too. Which brings me to my next question. How is xorg 1.9 working for ya? Any gotchas? May try it here. X starts, but crashes about a minute after logging into KDE4. I had similar experiences with 1.8. I'm using the radeon drivers for my ATI Radeon HD 3200 card. Wonko
[gentoo-user] scrapping hal
I've been off the list a good while and wondered if there is some kind of guide to scrap hal. I understand it is being done away with upstream and will probably require some changes on users part. I'm also guessing there is some kind of replacement that I need to learn about if it effects my longtime reliance on xorg.conf to keep using my huge desktops I like to use. For yrs I've used. Subsection Display Depth 24 Modes 1280x1024 #1024x768 800x600 640x480 Virtual 2048 1536 ViewPort0 0 EndSubsection EndSection in /etc/X11/xorg.conf To get a 2048x1536 desktop to flop around on. I've never seen or heard of a way to get that without using xorg.conf. Other things, I noticed was the onetime I did try to dump hal I ended up with no mouse or keyboard and fiddled with that a couple days, finally going back to hal. That has been probably a yr or more ago now. Back to the point: Can anyone provide some URLS that will help me form a battle plan or even better a brief outline of (generally) how to proceed with more or less painlessly dumping hal?
Re: [gentoo-user] scrapping hal
Apparently, though unproven, at 23:06 on Wednesday 27 October 2010, Harry Putnam did opine thusly: I've been off the list a good while and wondered if there is some kind of guide to scrap hal. I understand it is being done away with upstream and will probably require some changes on users part. I'm also guessing there is some kind of replacement that I need to learn about if it effects my longtime reliance on xorg.conf to keep using my huge desktops I like to use. For yrs I've used. Subsection Display Depth 24 Modes 1280x1024 #1024x768 800x600 640x480 Virtual 2048 1536 ViewPort0 0 EndSubsection EndSection in /etc/X11/xorg.conf To get a 2048x1536 desktop to flop around on. I've never seen or heard of a way to get that without using xorg.conf. Other things, I noticed was the onetime I did try to dump hal I ended up with no mouse or keyboard and fiddled with that a couple days, finally going back to hal. That has been probably a yr or more ago now. Back to the point: Can anyone provide some URLS that will help me form a battle plan or even better a brief outline of (generally) how to proceed with more or less painlessly dumping hal? It should all just work automagically with no real effort from you. However, you cannot just unmerge hal and expect stuff to work, you might still need it, as in: $ emerge -pv --depclean hal Calculating dependencies... done! sys-apps/hal-0.5.14-r3 pulled in by: app-cdr/k3b-2.0.1 app-emulation/virtualbox-ose-3.2.10 app-misc/hal-info-20091130 dev-libs/e_dbus- kde-base/solid-4.5.2 media-gfx/gimp-2.6.10 media-libs/libgphoto2-2.4.9 Recent xorg-server (i.e. 1.9.1 do not have hal in USE anymore. For earlier versions, you may still need to set USE=-hal udev for xorg-server in package.use. Then rebuild xorg-server. If you are *updating* xorg-server while doing this, then you might need to rebuild mesa and all the drivers as usual for an xorg update. As for xorg.conf. It's not quite true that you don't need an xorg.conf - this is still needed to define Screens and Devices if you have more than just one video adapter at native resolution. The part you don't need without hal is the Input section. Once you have rebuilt xorg-server and made sure you run a recent udev plus evdev in the kernel, comment out ALL Input sections in xorg.conf and all references to them. Restart X. It should all JustWork(tm). In the rare event it doesn't, post back with logs etc and we'll take it from there. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] scrapping hal
On Wed, Oct 27, 2010 at 4:06 PM, Harry Putnam rea...@newsguy.com wrote: I'm also guessing there is some kind of replacement that I need to learn about if it effects my longtime reliance on xorg.conf to keep using my huge desktops I like to use. For yrs I've used. Subsection Display Depth 24 Modes 1280x1024 #1024x768 800x600 640x480 Virtual 2048 1536 ViewPort 0 0 EndSubsection EndSection in /etc/X11/xorg.conf To get a 2048x1536 desktop to flop around on. I've never seen or heard of a way to get that without using xorg.conf. I think you would use xrandr to set it, or your desktop environment's GUI settings panel (or equivalent).
Re: [gentoo-user] scrapping hal
On Wed, Oct 27, 2010 at 4:31 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Wed, Oct 27, 2010 at 4:06 PM, Harry Putnam rea...@newsguy.com wrote: I'm also guessing there is some kind of replacement that I need to learn about if it effects my longtime reliance on xorg.conf to keep using my huge desktops I like to use. For yrs I've used. Subsection Display Depth 24 Modes 1280x1024 #1024x768 800x600 640x480 Virtual 2048 1536 ViewPort 0 0 EndSubsection EndSection in /etc/X11/xorg.conf To get a 2048x1536 desktop to flop around on. I've never seen or heard of a way to get that without using xorg.conf. I think you would use xrandr to set it, or your desktop environment's GUI settings panel (or equivalent). Also, I think if you still need to use an xorg.conf file if you want to use the proprietary NVIDIA or ATI drivers. If you're using the standard xorg drivers then it should all probe and configure automagically. In theory. :)
Re: [gentoo-user] scrapping hal
101027 Harry Putnam wrote: I wondered if there is some kind of guide to scrap hal. From my notes, having done it on 2 desktops machines + 1 netbook : To remove Hal : drop '-hal' flag, add 'udev' flag ; update to Xorg-server = 1.8.0 -drivers = 1.8 Xinit = 1.2.1 + drivers ; re-merge Exo Thunar ; delete refs to 'mouse' 'keyboard' in xorg.conf ; remove 'hald' fr /etc/runlevels/default/ . IIRC Hal is needed to the KDE desktop, but not for most KDE apps; I use Fluxbox + quite a few KDE apps; Exo Thunar belong to Xfce. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] scrapping hal
Philip Webb wrote: 101027 Harry Putnam wrote: I wondered if there is some kind of guide to scrap hal. From my notes, having done it on 2 desktops machines + 1 netbook : To remove Hal : drop '-hal' flag, add 'udev' flag ; update to Xorg-server= 1.8.0 -drivers= 1.8 Xinit= 1.2.1 + drivers ; re-merge Exo Thunar ; delete refs to 'mouse' 'keyboard' in xorg.conf ; remove 'hald' fr /etc/runlevels/default/ . IIRC Hal is needed to the KDE desktop, but not for most KDE apps; I use Fluxbox + quite a few KDE apps; Exo Thunar belong to Xfce. I think KDE is moving away from hal to tho. I read somewhere the switch is coming. I think it is switching to policykit at some point. I notice it is already in the USE flags for kdelibs here, disabled here at the moment tho. That would be if it doesn't change again. Dale :-) :-)
