Alien Pastures

My thoughts on Slackware, life and everything

Month: November 2010

Huge update to slackware-current and what it meant to my laptop

November 15, 2010 / / 36 Comments

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

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

Watching out for expiring SSL certificates

November 15, 2010 / / 6 Comments

I guess that, like me, you will be using one or more SSL certificates to encrypt client/server communications.

I use self-signed certificates as well as several which I created at http://CAcert.org/ for encrypting traffic between me and my web server, my IMAP server, my SMTP server and more. Invariably these will eventually expire, because that is part of the blanket of security you apply to your services.

An expired server certificate should at least generate warnings when a client connects to it, some clients will even refuse to connect to an encrypted data stream using an expired certificate.

So, you’ll have to watch out for expiration of your certificates, and replace them with new ones before any of the client programs will be affected.

There is a one-liner command to show you when a SSL certificate (let’s call it “somecert.pem”) expires:

?# openssl x509 -noout -in somecert.pem -enddate | cut -d= -f2-
?
The command returns something like:

Nov 29 12:20:12 2010 GMT 

I use this command in a cron job that checks all SSL certificates in the “/etc/ssl/certs/” directory of my Slackware server for imminent expiration and starts sending me daily emails one month in advance. This is the script’s content, I scheduled it to run every day:

#!/bin/bash
#---------------------------------------------------------------------
# Check SSL certificate expiry. Warn root via email.
# Eric Hameleers, 23may2005
#---------------------------------------------------------------------
CERTDIR="/etc/ssl/certs"
THE_DATE=$(date +%Y%m%d_%H%M)
WARNDAYS=31
#---------------------------------------------------------------------
TODAY=$(( $(date +%s)/86400 ))
for i in ${CERTDIR}/*.pem ; do
EXPDATE=$(openssl x509 -noout -in $i -enddate | cut -d= -f2-)
EXPDAY=$(( $(date -d "${EXPDATE}" +%s)/86400 ))
if [ $(($EXPDAY-$TODAY)) -le $WARNDAYS ] ; then
(cat <<EOT
!!! SSL CERTIFICATE EXPIRY !!!
==============================
The SSL Certificate '$i'
which is located in directory '${CERTDIR}'
will expire in less than $(($EXPDAY-$TODAY)) days!
NOTE:
You can check the contents of this certificate by running
'openssl x509 -text -noout -in $i'
==============================
Your Administrator.
EOT
) | mail -s "SSL Cert '$i' pending expiry on $(hostname)" root
fi
done

Hope it can be of use to some of you.

Eric

Busy spheres

November 7, 2010 / / 6 Comments

Last week, we had visitors at work who had done a Linux related job for us and were ready to demo their product. One of the consultants had a nice screensaver running on his Debian-powered laptop (or was it Ubuntu… I don’t remember). He told me it was called “busy spheres” but it took me a while to find out that that is nowadays part of the GLX port of the “Really Slick Screensavers” collection.

Busy Spheres

I liked it enough that I created a Slackware package for it…. http://slackware.com/~alien/slackbuilds/rss-glx/ After installation, the screensaver collection will be available for selection both in XScreenSaver and KDE screensaver (KDE will show some of them twice, since some of the RSS are already incorporated in the kdeartwork package).

The list of screensavers contained in the package is quite large: biof, busyspheres, colorfire, cyclone, drempels, euphoria, feedback, fieldlines, flocks, flux, helios, hufo_smoke, hufo_tunnel, hyperspace, lattice, lorenz, matrixview, pixelcity, plasma, skyrocket,solarwinds, spirographx and sundancer2 .

By the way, I noticed that Really Slick Screensavers has another recent addition which is not available yet in the Linux port – MicroCosm – which looks really slick (pun intended). Let’s hope rss-glx gets updated soon.

Eric

I posted new KDE 4.5.3 packages

November 4, 2010 / / 22 Comments

KDE 4.5.3

Yesterday, KDE team released version 4.5.3 of the KDE Software Compilation.

I have created Slackware packages for the new release. I am fairly certain that Slackware -current will be updated to this version as well, but at the moment I do not have a time frame for that. Before it gets added, I expect that slackware-current has other updates first.

In the meantime, you can download and install my packages and play around. There are stability and speed improvements so it is strongly advised to update if you were already running my KDE 4.5.2 packages. Just like with the previous set of 4.5.2 packages I created, you do not have to update or install any additional packages. A fully up to date Slackware-current (32-bit or 64-bit) is all you need.

Read the installation/upgrade instructions for my KDE 4.5.3 packages first. Then, get my packages,

here: http://alien.slackbook.org/ktown/4.5.3/

mirror: http://taper.alienbase.nl/mirrors/alien-kde/4.5.3/

Enjoy, Eric

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑