startx as root is ok, but not a normal user.
I usually work as a normal user on KDE. But now I cannot start X as a normal user, when I type "startx" and run for a while, the initialize appear for a while, then the X crash.
It works fine when I run "startx" as root.

Is there anybody know how to catch the result when run startx? I tried "startx > error.txt" but it just contain one line "HANGUP"?

check for the presence of /lib/liblzma.so.0
I was getting the same issue and noted that I had /lib/liblzma.so.5
I just renamed it to /lib/liblzma.so.0 and rebooted and everything came up correctly

You could try to "# chmod 4755 startx", or check /var/log/Xorg.0.log for the output.

I can confirm issue with Bluetooth mouse: it is gone, and blueman-manager is not able to find it; I can only re-attach it if I run 'hidd --search", but after a period of inactivity, or reboot, it is gone again - very inconvenient... Also, fonts in GTK-based applications (I'm running E17 as window manager and desktop environment) looks different: changing fonts in ~/.gtkrc-2.0 works, but the text itself say in Firefox menus etc. looks quite different than before (glyphs are somewhat thin, like that anti-aliasing is not working anymore, even if I have presumably have it set through ~/.fonts.conf). I also have some other issues since upgrading to .35 kernel (am running Slackware64, always keeping it updated to -current): after going to suspend, and then resuming, I'm not back to X, but instead to some console where everything is black, and I have to press Ctrl-Alt-F7 to go back to X (Bluetooth mouse is gone this way too). Maybe the latest has to do with running NVIDIA binary driver, but overall I'd say I really don't like this recent policy with Slackware change log of being quiet for couple weeks, and then coming up with tons of updates - it really makes it hard to debug issues alike to ones described above, and overall I'd say the quality of updates testing is declining (as manifested with this liblzma symlink issue)...

Thanks for sharing the tips. I had no problem after upgrading my Slackware64. I'm using the latest nvidia binary drivers.

It can be a pain in the neck to set up and search for a way to configure the keyboard layout when your keyboard has the wrong layout, so here's a quick tip. Create a file in /etc/X11/xorg.conf.d called keyboard.conf, for example, with the following contents.

Replace the "es" keyword with the proper country code for your keyboard.

aaa_elflibs installs /lib64/liblzma.so.0.0.0. However, most folks follow the given advice not to upgrade that package or risk hosing newer system libraries. xz-5.0.0-x86_64-1 installs /lib64/liblzma.so.5.0.0 with links /lib64/liblzma.so.5 and /usr/lib64/liblzma.so. However, a lot of KDE programs (kdegraphics) are linked against /lib64/liblzma.so.0, which got lost somewhere along the way. If you recreate that link, those problems related to the missing shared system library go away.

`ln -s /lib64/liblzma.so.5.0.0 /lib64/liblzma.so.0`

Hi guy, i back
i have try reinstall my xorg.conf, the same issue still reside.
Then i try change the driver from ati to vesa and seen it start work, but my monitor was without image.
I replace my xorg.conf with xorg.conf-vesa file and i saw X.Org start running again, but when it are near to stop loading it crash again to console.

I have uploaded other log file, http://paste-it.net/public/z026230/

I don't know if the xorg.conf can be used in this new X.Org, or if I need create a file and put inside the xorg.conf.d/ folder.

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!

Eric

I can't (yet) comment on your other issues because I just came home from a days's work, but I have to chime in on the remarks I quoted.

The issue with this large batch of updates is that you can not release them in small subsets. The new X.Org packages are incompatible with the older ones so they have to be replaced as one. The GTK updates were worked on in the same timeframe, and since we do not have multiple teams they were worked on together with the rest. And were released all at once. What's the probiem with that? You are running slackware-current which means you take responsibility for fixing your computer when the updates break it. If you can't agree to that condition, then we always have the stable release of Slackware for you. This is not Gentoo or Arch, rolling releases are fun but if you want stability, stick to an official Slackware release.

As for the liblzma.so issue, if you have asked here you'd have had your answer soon enough: i.e. that exactly at the time when aaa_elflibs gets updated (if you are running slackware-current), you should upgrade that package. If you upgrade between two stable Slackware releases, then you should not upgrade the aaa_elflibs package.

Eric

You did it wrong. Upgrade the aaa_elflibs package properly *after* you "unfix" what you just broke by renaming.

Using the mesa-7.8.2 package brought my laptop back to live. X used to crash after updating to current.

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.

No, no, no. That's NEVER the solution unless you KNOW that the ABI didn't change, in which case, you should fuss at the upstream project for needlessly changing the version of the shared library. In other words, symlinking like this is asking for trouble, and even if it appears to work, it will often fail in subtle ways, and even if it doesn't, it should be a temporary "oh crap" measure that quickly gets solved correctly.

In this case, the correct solution is to upgrade aaa_elflibs. That package should always be upgraded if you're tracking the development tree of Slackware.

Or more importantly, even though its probably temporarily there, the liblzma.so.0 library which isnt provided by other packages.

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.