Today, you may be watching the slackware-current ChangeLog.txt slack-faced, with a feeling of horror…
… because the update is HUGE. There are well over 300 lines of updates! That amounts to one-third of the full length of ChangeLog for the current development cycle. Those of you who thought Slackware was calmly drifting toward another stable release, will have to brace themselves for a round of fun and thorough testing.
I think the most obvious intrusive change is that Slackware-current moved to using the “new” X.Org which no longer depends on HAL for hardware detection and initialization. Instead, the new X.Org talks directly to udev.
Robby Workman has put a lot of work in assembling a coherent set of X.Org sources as well as getting this stuff tested widely before it got added to Slackware (see http://www.linuxquestions.org/questions/slackware-14/call-for-testing-xorg-updates-20100830-a-829336/).
There is also a newer GTK+2 (version 2.22). The new GTK proves to be a difficult bugger with apparent incompatibilities with previous releases. We have to see what the extent of these incompatibilities is; for instance I came across software does not compile anymore and needs patching or updating (gtk-chtheme).
When upgrading your slackware-current please note that several packages have been added, and others have been removed! If you are using slackpkg to do the upgrades for you, you can use the command “slackpkg clean-system” to remove the deprecated (mostly X.Org related) packages. In the package overview that presents itself, make sure to first deselect those you installed yourself before hitting the “OK” button! Likewise, running “slackpkg install-new” will install the newly added packages for you.
What were the bumps when I upgraded my Lenovo T400 laptop?
Well, several… but they were easy to fix.
X.Org configuration of the hardware:
Since the new X.Org no longer uses HAL, my old method of configuring the TrackPoint in a file “/etc/hal/fdi/policy/11-x11-trackpoint.fdi” no longer works. Instead, the new X.Org uses a configuration directory “/etc/X11/xorg.conf.d/” where you can add configuration files for your hardware. You’ll see the similarities; my old HAL file looks like this:
<match key="info.product" string_outof="TPPS/2 IBM TrackPoint;PS/2 Generic Mouse">
<merge key="input.x11_options.EmulateWheel" type="string">true</merge>
<merge key="input.x11_options.EmulateWheelButton" type="string">2</merge>
<merge key="input.x11_options.YAxisMapping" type="string">4 5</merge>
<merge key="input.x11_options.XAxisMapping" type="string">6 7</merge>
<merge key="input.x11_options.Emulate3Buttons" type="string">true</merge>
<merge key="input.x11_options.EmulateWheelTimeout" type="string">200</merge>
</match>
While the new way of configuring requires a file (I aptly named it “/etc/X11/xorg.conf.d/20-thinkpad.conf” but any name that ends on “conf” will do) in which I wrote:
Section "InputClass"
Identifier "Trackpoint Wheel Emulation"
MatchProduct "TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device|Composite TouchPad / TrackPoint"
MatchDevicePath "/dev/input/event*"
Option "EmulateWheel" "true"
Option "EmulateWheelButton" "2"
Option "EmulateWheelTimeout" "200"
Option "XAxisMapping" "6 7"
Option "YAxisMapping" "4 5"
Option "Emulate3Buttons" "true"
EndSection
You will have perform a similar exercise if you previously had configured a non-US keyboard in a HAL “fdi” file. I will leave it up to you to figure out how to repeat this for the new X.Org.
Hardware accelerated graphics:
Actually, this is where the updated packages shine! The combination of mesa, Intel graphics and KDE 4.5 proved to be quite disastrous a month ago when the kernel was updated in slackware-current. My KDE 4.5 packages froze the computer solid, the very moment when “desktop effects” (compositing) was enabled. This graphics hard lock is not caused by X.Org. Rather, it is the kernel’s DRI (direct rendering interface) and the way mesa interacts with it where all the trouble started. However,the real cause was not apparent at first (and some people were pointing at the open source graphics drivers). I had reported about this problem before – my Asus Eeepc 1000H which has an Intel graphics chip started having these compositing problems after the upgrade of the slackware-current kernel to 2.6.35.7 (i.e. before the upgrade of X.Org or mesa). As long as you were not using compositing in KDE 4.5, you would not see this problem at all.
The issue has been addressed in mesa (the library used by X.Org to enable software and hardware accelerated graphics). Slackware’s mesa was updated to 7.9 today and KDE’s compositing desktop is working now! My T400 with Intel graphics is happy again, as will be my EeePC after I upgrade that!
VLC and fullscreen video:
I had not expected this one, and I have not been able to find out what caused it. When resizing the VLC window, the dimensions of the embedded video would not grow beyond the actual pixel size of the video stream (i.e. there was no video scaling). I tried downgrading to an earlier version of VLC, I tried running XFCE instead of KDE, but the problem remained painfully visible as a big black border surrounding a tiny video. In the end, I ruthlessly removed the VLC configuration directories “~/.local/share/vlc/” and “~/.config/vlc/”. That helped! But it left behind a feeling of dissatisfaction.
xz (liblzma.so.0):
The xz package (used as the compression tool for the .txz package format) was updated too. The new dynamic library has another version number. I first noticed that I must have forgotten something when KDE refused to start after I finished upgrading. Several applications were spitting out errors about a missing “liblzma.so.0” library. This old library file was added to the “aaa_elflibs” package for compatibility reasons (along with a version of libtalloc.so), but this package is blacklisted in the “slackpkg” program so “aaa_elflibs” was not getting upgraded. Usually (upgrading between two stable releases) this is the correct approach, because aaa_elflibs should contain redundant libraries. However, right after an update to this package you should run “upgradepkg” on it. I did that, and KDE started up normally again.
And thus starts a period of new play-testing, folks. Have fun, and give us good feedback!
Eric
Identifier “Trackpoint Wheel Emulation”
MatchProduct “TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device|Composite TouchPad / TrackPoint”
MatchDevicePath “/dev/input/event*”
Option “EmulateWheel” “true”
Option “EmulateWheelButton” “2”
Option “EmulateWheelTimeout” “200”
Option “XAxisMapping” “6 7”
Option “YAxisMapping” “4 5”
Option “Emulate3Buttons” “true”
EndSection
For those of you needing a different keymap, see the default files in /usr/share/X11/xorg.conf.d/ for commented examples and directions. I’ve got to get the CHANGES_AND_HINTS.TXT file up to date 🙂
thanks for the massive updates. I will likely spend this week to make sure everything works just before the upgrade 🙂
I also forgot to mention that the updated “xz” package may give you issues if you forgot to upgrade the aaa_elflibs package (slackpkg has it blacklisted). My KDE refused to start for instance.
I updated the main article with this fact.
Eric
Another “great” update: my Bluetooth mouse is not recognized any more and blueman-manager is not able to find it at all, fonts in GTK-based applications I’m using (emacs, Firefox, etc.) are fsck-ed up, and no changes in ~/.gtkrc-2.0 or ~/.fonts.conf are helping to get them nice…
It doesn’t took me a week, just half a day to upgrade all of my laptop and two desktop to the -Current and everything works like charm. Thanks for the efforts 🙂
I upgraded to current, I face this error whenever I try running few programs
error while loading shared libraries: libgdk_pixbuf-2.0.so.0: cannot open shared object file: No such file or directory
This happens when I try running firefox / xchat or other programs which call the gtk libs (my guess). Tried installing the gtk+2 again, in vain.
@Rahul: Try running “ld-config” (or just restart your machine).
@Rahul: install the new package gdk-pixbuf
I did this upgrade and have some problems with locales (pl_PL.utf8). With LC_ALL=pl_PL.utf8 I can’t run twm. xfontsel gives me the warning:
Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset. I have got slackware-current with kde-4.5.3. Could You confirm twm running with pl_PL.utf8 locales?
Thanks for help
I upgraded aaa_elflibs, but can’t start X yet, because of the errors:
SIGTERM to children
/home/user/.kde/socket-user/kdeinit4_0: No such file or directory
FAILED to connect to socket /tmp/dbus-62mVzAerCW
any ideas, please?
gdk-pixbuf did the trick
@George, i got kind of the same error, reinstalling nvidia drivers worked for me
I don’t have installed 3D drivers and don’t use 3d functions. Xfce starts, but kde – not.
Thanks for adding the bit about xz – was scratching my head, returned to this article for some links or comments, and found what i needed added to the article. Awesome 🙂
After upgrade my fonts look much different – smaller I think. Is that normal or I did something wrong?
Also, I see number 13.2 in aaa_elflibs – is that number for new version?
One more thing – I asked Pat some time ago what is strategy for virtualization (both in server and client role). I see some x packages are for VMware. Will Slackware include drivers for major VM platforms (VMware and Hyper-V)?
Best regards,
Aleksandar
@Aleksandar –
Several people have commented the the fonts seem smaller. I guess I am too insensitive to font changes to have noticed.
There are several discussions about font display and font quality on http://linuxquestions.org/ (due to the fact that freetype now has the bytecode interpreter enabled by default after its patent expired) – some people like the quality of fonts better than before, and the other half thinks exactly the opposite.
How you perceive fonts is largely a matter of personal taste.
The updated version number of aaa_elflibs _may_ give an indication of a new Slackware version, but don’t hold yur breath about that one.
Regarding virtualization – just use the free and Open Source virtualization which is part of the linux kernel : kvm plus qemu. There is no Slackware strategy toward virtualization that I am aware of. I see no reason why any virtualization solution would not work on Slackware (as a host) or with Slackware (as a guest. Well for Xen you _will_ have to recompile the Slackware kernel.
Eric
Thanks for this blog post. I’ve updated with no problems at all. I also seem insensitive to the font changes.
Just to be clear – is it ok to leave aaaelflibs unblacklisted whilst tracking -current?
Hey, after the upgrade I just made a symlink from liblzma.so to liblzma.so.0. Everything seems to work fine. Do I still have to update aaa_elflibs? 🙂 thx for you great work btw
Nevermind. I only had the first part of the big update. Upgraded aaa_elflibs now 🙂
Is this possible that maintainer of xorg package forget add some package.
In my acer one /intel/ with latest mesa don’t work AIGLX with error missing “libtallock…..”????
Reverting to R.Workman’s compiled mesa 7.8.2 – OK no errors.
Wonderful!
Dunno why it took me so long to dig up this post. I actually cringed at the size of the changelog and didn’t want to Slackpkg anything until I was comfortable with the fixes I was sure to affect 🙂
@BratPit –
Your error about the missing libtallock is caused by the fact that in slackware-current, the libtalloc.so.2 library file was moved into the aaa_elflibs package.
Try upgrading that one (or extract the libtalloc.* files from the latest package).
Eric
Thanks
BP
“(due to the fact that freetype now has the bytecode interpreter enabled by default after its patent expired)”
Good pointer, thanks Eric.
That was the reason for my font becoming suddenly ugly after the big update (might just depend on how the bytecode interpreter acts along with DPI sizing and the tiny LCD screen of my netbook).
Just by recompiling freetype 2.4.3 with TT_CONFIG_OPTION_BYTECODE_INTERPRETER commented and TT_CONFIG_OPTION_UNPATENTED_HINTING defined again, I had my nice fonts back in their shape.
@Giacomo
You can achieve the same without recompiling.
Just force the use of the old auto-hinter by creating a symbolic link, like this:
# cd /etc/fonts/conf.d ; ln -sf ../conf.avail/10-autohint.conf .
Eric
Even better, thanks again.
Guess I should refrain from my hack&recompile habits sometimes 🙂
I also had problems with fonts after update.
After creating link all fonts look nice again.
Thank you, Eric!
I remove the /etc/udev/rules.d/70-persistent-cd.rules and reboot with kernel-huge. This work.
With my custom kernel did not work yet.
Sorry, I mean the cd/dvdrw
Even if the command “cd /etc/fonts/conf.d ; ln -sf ../conf.avail/10-autohint.conf .” do the trick with restoring the fonts look for the kde and qt apps, the gtk and sdl fonts are stuck with the different view compared with 13.1
So i installed freetype-2.3.12-i486-1.txz from 13.1 and voila – now it looks like before 13.37