SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I started deprecating HAL on my system (upgrading glib2, then udev, then installing udisk and upower, than patching X), but I am running GNOME, and I'm very curious how KDE does with the deprecation of HAL.
HAL is still used in Slackware. It will be upgraded to the latest release soon. HAL is deprecated in favour of devicekit/polkit and its friends, but for a while to come software such as X.Org will keep supporting it.
KDE mainly interacts with DBUS so if you have ripped out HAL, that should not make much of a difference.
In fact, the presence of polkit will enable the compilation of some additional KDE components - such as the font installer - that require extra privileges (in KDE4.4 GUI applications preferably no longer run as root and kauth/polkit are supposed to be used as the authentication framework).
While kde 4.4.0 seems fine, the latest batches of updates in current broke dri with my radeon 9550 card(opensource drivers) and interacting with qt4 apps are very slow now - changing tabs takes about 1-2 seconds.
I have this error in /var/log/Xorg.0.log:
Code:
drmOpenDevice: node name is /dev/dri/card0
[drm] failed to load kernel module "radeon"
(EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
[dri] Disabling DRI.
Edit: Sorry, this lag is gone, probably some service was slowing kde down after login, but i thought it's the same lag i encountered in kde 4.3.4 without dri.
You may want to start a separate thread for this problem as it's not really about KDE 4.4.0 but about your direct rendering issues (which seems to be a result of not having the 'radeon' kernel module built on your machine, as far as I can tell).
You will need to run a *development* snapshot of Slackware (meaning,
slackware-current of around 01-feb-2010 or newer). These packages do
*not* work on Slackware 13.0.
KDE 4.4 has different requirements from KDE 4.3 or 4.2. You will have to upgrade
several non-KDE Slackware packages as well as add some new packages.
'-current' is still on 'Sun Jan 31 19:28:54 UTC 2010'.
Just a heads up! Probably not a major but I'm sure someone will know.
'-current' is still on 'Sun Jan 31 19:28:54 UTC 2010'.
Just a heads up! Probably not a major but I'm sure someone will know.
There is nothing being hinted at. Merely, I am building on a Slackware-current that has all those published updates up to and including 31-jan-2010.
Whatever is cooking in Pat's non-public tree has not been used to create my KDE 4.4 packages.
In your other post regarding this piece of text you stated "I smell a RC" but that is really not the case here. In fact, I expect that lots of updates still need to go into -current so a RC is miles and miles away.
Just upgraded from 4.3.95 to 4.4.0 and found that the virtuosoconverter did not work for me, so I just logged out, manually deleted everything under the ~/.kde/share/apps/nepomuk/repository directory and restarted, as mentioned.
This eye-candy stuff is becoming addictive as more features with real productivity benefits are added. So far this rocks!
@Alien Bob
Thanks also from me for building the packages and making them available. Your efforts are much appreciated.
[...]
In your other post regarding this piece of text you stated "I smell a RC" but that is really not the case here. In fact, I expect that lots of updates still need to go into -current so a RC is miles and miles away.
Eric
First of all, big THANKS from my side, too! I haven't upgraded to KDE 4.4, but I am using your *totally* stable KDE 4.3.4 and multilib packages --- excellent, really!
Regarding the smell of an RC: IMHO it would make sense, if -current, as it is now, would be released as Slackware 13.1, with the multilib stuff in /extra. Because of the many improvements of mainly KDE since Slackware 13.0 was released, such a release would be well justified, I think. Also, AFAIK, KDE 4.3.4 will be maintained for some time to come.
A release of 13.1 with KDE 4.3.4 now or around Easter would also allow you, the developers of Slackware, and the KDE folks to get the KDE 4.4 stuff including the *kit stuff right. There have been so many statements about the inferior stability of policykit, that I am not really keen to have it soon on my desktop. My understanding is, that the architecture of the *kit stuff is ok, but that the implementation needs some more time to mature.
If this is true, the question is, how long we would have to wait for another release. A 13.1 release with KDE 4.3.4 therefore would make sense to me.
Or are these problems all solved, now?
But: I have developed a lot of faith regarding the decisions of Pat V. and the Slackware crew. So YOU decide, if the next Slackware comes with KDE 4.4 (or even 4.5?) and when it is going to be released.
If this is true, the question is, how long we would have to wait for another release. A 13.1 release with KDE 4.3.4 therefore would make sense to me.
I don't believe Slackware is that close to a release. Perhaps a service pack, sure.
We should wait until at least the GTK and Xfce updates are pushed through. I'm personally glad there isn't a new release of Slackware every 6 months or so just because a few packages had version bumps. Slackware, as always, should be released when ready. Historically this is ~once every 8-10 months, along with the big packages, Xorg, Xfce, GCC, and KDE updates. Currently there's 2 out of 4 (50% done). I'd rather wait until June for Xfce 4.8. If released now, 3-4 months later everyone will demand the new Xfce.
Besides that, the AOLS Fun and Games haven't started yet, so it's still at least 2 months away
The fact that KDE4.2 in Slackware 13.0 was pretty much a "It's not quite ready, but we'll make do" release is going to be the main reason people are impatient for the next release. Somehow I suspect that at the moment there are far more people running current than ever before, and purely because of the KDE4 updates. In contrast, anyone using XFCE or Fluxbox are most likely more than happy to sit on 13.0 for as long as it takes.
I don't envy Pat trying to decide when the best time will be. It can't be easy to plan around the rapid rate of change going on with KDE at the moment.
[...] Somehow I suspect that at the moment there are far more people running current than ever before, and purely because of the KDE4 updates. In contrast, anyone using XFCE or Fluxbox are most likely more than happy to sit on 13.0 for as long as it takes.
This is *exactly* my point. In fact, I am one of these users. Usually I stick to stable releases, but at the moment I am using -current. And it's totally stable and consistent, so IMHO it could be a valid RC, already
Quote:
Originally Posted by GazL
I don't envy Pat trying to decide when the best time will be. It can't be easy to plan around the rapid rate of change going on with KDE at the moment.
I couldn't agree more! But Pat V. seems to have an extra sense for the right time and will do it right, like always --- I have no doubt!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
