SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Reverting isn't the ideal solution. Reconfiguring to get a good result is a better way forward. I've just symlinked "10-no-sub-pixel.conf" into /etc/fonts/conf.d and things already look a little bit more like they used to and closer to my tastes, but it still doesn't look quite as clear as it did before (unless I'm imagining it - hard to say without a side by side comparison).
Not knowing exactly what's changed doesn't help, but I daresay I'll get to something I can live with after some experimentation.
Well, it wasn't a security patch per say, so it is still safe to run. I'm sure that "workarounds" will come out as time goes by on how to get fonts to look the way they used to.
Where did you symlinked 10-no-sub-pixel.conf from? I need to give that a try.
Click here to see the post LQ members have rated as the most helpful post in this thread.
After upgrading -current I have found the desktop effects have been "temporarily disabled". Looking under the "all effects" tab of "configure desktop effects" shows an empty box. It appears the effects are not installed. They were working before the upgrade and this has occurred on two machines - a laptop and a desktop. Otherwise all went well.
Upgrade proceeded flawlessly here. Of course, mutt still doesn't work properly which is probably due to changes in configuration options during compilation. I know. Mutt wasn't upgraded in this last upgrade, but the problem still needs fixing. Otherwise, great work! TIA
@bg4 - I have found that KDE 4.5.1 has an entry "OpenGLIsUnsafe=false" (in ~/.kde/share/config/kwinrc under [Compositing] ). If this is set to "true" then the Desktop effects tab under System Settings -> Display is empty of entries.
By design, KDE checks for support for compositing and after two attempts it will give up and mark the lack of support.
Distribution: Slackware64-current with "True Multilib."
Originally Posted by allend
Have a look at post #38 in this thread.
Yes, I saw that and Alien Bob said,
Try without xorg.conf first. Slackware's X.Org does not need one.
What you should also try is to replace the mesa-7.9 package from slackware-current with the mesa-7.8.2 package which was uploaded here today by Pat Volkerding: http://slackware.osuosl.org/unsupported/mesa-7.8.2/
For some Ati and Nvidia cards (using the opensource drivers) the slightly older version mesa package may just work.
If that package works for you, please report it here!
It would seem, but maybe I'm wrong, that he was talking about the 7.8.2 version, not 7.8.1.
Regardless, consider it "reported" that the 7.8.1 version of Mesa works fine.
I usually don't install "current" but KDE has been a problem for me. I could have installed KDE 3.5.1 on top of Slackware 13.1 but I'd rather take my chances with "current". I have a lot more confidence in the Slackware maintainers than KDE or myself. I also ran into the problem with "liblzma" but I consider it a minor problem. I will say that Slackware is looking very good. Considering the rate that KDE changes that speaks of a lot of care and effort.
Of course everyone would like another release of Slackware soon. I prefer to encourage rather than complain. I wish I had more to contribute besides my encouragement and helping an occasional Slackware user with a question that I can answer.
I think that Slackware 13.1 was a good release that suffered from being done at a time when many packages were still undergoing some growing pains. That makes it even more important for 13.2 to be released when it is ready, and not before. I will be perfectly happy if 13.2 uses KDE 4.5 instead of 4.6. I use Slackware because I want stability, not bleeding edge software.
It's nice that Slackware "current" is available and from what I've seen people get plenty of help with problems even if they have "current". Expecting "current" to always install and run with no effort is unreasonable. The obvious solution to difficult problems is to wait a while and then update again with the current "current". Someone who needs an always working system is probably better off to stick to official releases, fix whatever problems are there and then leave it alone. That's what I have done in the past and will probably do most of the time in the future.
Maybe I'm misunderstanding what you wrote, but aaa_elflibs should *always* be upgraded when one goes from e.g. Slackware 13.0 to 13.1. The "never upgrade or reinstall this package" is intended for those tracking a stable release (e.g. 13.1) in /patches -- it should never be reinstalled in those circumstances.
When 13.2 (assuming it is 13.2) is released, everyone should certainly upgrade the aaa_elflibs package along with the rest, because if they don't, they will be missing libtalloc.so (for example) if they try to run without installing the samba package.
Yes, I'm agree with RW. Now I have a better understanding of aaa_elflibs pkg. Maybe we should state that clearly in slack-desc and CHANGES_AND_HINTS.TXT?
Because you expect -current trackers to "fix bugs by their own", I think it's up to ourself to un-blacklist aaa_elflibs in slackpkg
I upgraded to -current (32-bit) today and everything went smoothly with the tips from this thread. Had to download and rebuild a new version of the nvidia drivers and finally create a new symbolic link for liblzma.so.0 and everything works great now. I've noticed some subtle performance improvements in the new version of X already. Thanks everyone.
Last edited by smoooth103; 11-16-2010 at 02:28 AM.
Wait, you're upset that we didn't "release early and release often", but you're also whining about the remaining bugs? Please, make up your mind.
I'm not whining about the bugs. Most of the stuff mentioned above, and obviously all of the stuff mentioned in my post, are issues with upstream: BlueZ is known to be crap, breaking things with each new release, and also I really cannot understand how it could be possible, after so many years, to have FreeType to completely change text rendering all of a sudden. But unfortunately we don't have an alternative Bluetooth stack or an alternative FreeType rendering library, so we'll have to live with this... However that doesn't change my complaints about Slackware update policy in recent times: for example, Slackware 13.1 came with FreeType 2.3.12, and there were 2.4.0, 2.4.1 and 2.4.2 releases in the meantime, and you just decided to come up now with 2.4.3 updated, buried in this huge pile of other updates. And now there are suggestions to go back to 2.3.12 for those who don't like new rendering of fonts, implying that nothing in -current actually depends on FreeType 2.4.x. So I really can't understand why it was not possible then for example to release updated FreeType in some small batch of updates previously - this way, I would be probably able to find what caused the issue much quicker, as I'd have to check change logs of dozen of packages, instead of thousands in this case.