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.

It's in the same directory as all the others (/etc/fonts/conf.avail). Do a ls -l /etc/fonts/conf.d and you'll see how they work.

thanks rworkman,

0. upgrade aaa_elflibs fix it
1. mkdir /lib/udev/devices/shm fix it
2. convert gtk2+ and gdk-pixbuf2 to compat32 package and then upgrade fix it

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.

Any thoughts?

Thanks, bg4.

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.

Well, it turns out Mesa-7.9 was the source of my problems.
Everything else works just fine with Mesa-7.8.1.

Is it OK to run with this older version?

Many Thanks.

Have a look at post #38 in this thread.

Yes, I saw that and Alien Bob said,
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.

3 members found this post helpful.

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

Thanks to everyone in this thread and the information provided. Made my my upgrade today pretty painless

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.

That was about libgdk_pixbuf error - I had the same error reported on properly upgraded system, and the solution here was just to run ld-config.

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.

0 members found this post helpful.