… 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

Some of you may have noticed that source tarballs for KDE 4.5.1 are available now.

I talked to Pat about this last week, to see if this release could end up in Slackware-current. He answered that that would be a possibility. There are several other things brewing for slackware-current, so I have no real good estimate of when that will happen.

If it takes too long, I will just build packages for KDE 4.5.1 myself. There are no new dependencies and slackware-current is fully up to date with regard to support for KDE 4.5.1.

Here’s hoping!

Eric

This time, the packages which I created are for Slackware-current only (32-bit as well as 64-bit). The packages are available in my ktown repository. Slackware 13.1 users who want to move to KDE 4.5 should take this opportunity to upgrade to Slackware-current now. If you want to stick with Slackware 13.1 but still want the latest stable KDE then your best shot will be my version of KDE 4.4.5 packages and dependencies that are good for Slackware 13.1 (I will keep those around for quite a while).

With regard to my new set of KDE 4.5-rc3 packages: there is one dependency which is not yet part of Slackware (libdbusmenu-qt) and a single dependency which got updated (soprano) but other than that, Slackware-current is fully up-to-date for KDE 4.5. You will find the libdbusmenu-qt and updated soprano packages in the “deps” directory.

The 4.5-rc3 packages are accompanied by a README which explains the straight-forward  installation/upgrade steps.

This will be your last chance to influence the quality and stability of this new KDE. Go and find bugs… and get them fixed  by reporting them on http://bugs.kde.org/ .

Cheers, Eric

Today, Pat Volkerding pushed out the work that has been accumulating for slackware-current behind the scenes during the past four weeks (make take a little while to reach the mirrors).
This triggered some updates to the multilib and KDE 4.4 packages which I maintain, so if you run Slackware64-multilib and/or KDE 4.4.0 then be sure to check for instructions further down!

With a ChangeLog entry that runs more than 500 lines, I think this is the largest single update yet. But that was for a very good reason, because there were updates to large subsystems:

• Kernel: woohoo we have 2.6.33 now – the latest & greatest.
• X.Org: this went up to 7.5 (X server version is now 1.7.5) – you can’t get it newer than this. There is no nouveau driver for now, but it should not be so hard to add this yourself because all its dependencies should be met by slackware-current.
• KDE: has been updated to 4.3.5 – the latest “politically correct” version which is available… No PolicyKit for us yet.
• The GTK ecosystem has been overhauled and slackware-current is now at gtk+2 version 2.18.7.
• Because the upgrade of libpng was an incompatible change (I refrain from using bad language about this piece of software, but I invite you to examine the libpng.SlackBuild closely), every single package which depends on this library needed to be recompiled. D’ oh!
• Lots of core packages were updated to their latest version as well – too many to write down here.

To get all of these updates working as a whole, took its time. I know that some of you complained that “the team is having all the fun in secret” but I assure you, you were not left out in the cold. The long silence was something that could not be avoided, as it would have been kind of stupid to write blog posts like “hey! we’re currently adding this new X.Org” in case it turned out that we could not integrate it into Slackware properly. I do think it was worth waiting for, but now is the time for the bigger test – by all of you out there.

Note for self-compiling folk:

Something you may experience when you compiled your own applications: some of them may suddenly refuse to show buttons/bitmaps. This is because the application is linked in an incompatible way with libpng… it means you will have to recompile it. For instance, I will have to update my own VLC package because the control interface is now showing empty grey squares… bummer.

Instructions for people running Slackware64 with my multilib packages and/or KDE 4.4.0 packages:

Multilib gcc/glibc packages (64-bit)

• Due to the addition of a new kernel and the upgrade of the “png” library in slackware-current, the glibc and gcc packages had to be recompiled. My recompiled multilib versions of gcc and glibc for slackware64-current are available at the ususal place – please upgrade to these versions now: http://slackware.com/~alien/multilib/13.1/ – if you forget this and instead upgrade to Slackware’s standard gcc/glibc packages, you will still have a fully functional 64-bit Slackware… just with a non-functional 32-bit subsystem.

KDE 4.4.0 (32-bit as well as 64-bit)

• Due to the upgrade of the “png library” I also had to recompile some of the KDE 4.4.0 packages and their dependencies. I took the opportunity to also add a couple of fixes to the KDE packages. I also removed two dependencies which are now covered by Slackware-current (deps/libv4l and deps/libxklavier).
  Here is the list of my updated packages (for both architectures, 32-bit and 64-bit):
  • deps/libiodbc
    deps/qt
    deps/virtuoso-ose
    kde/kdebase-workspace
    kde/kdelibs
    kde/kdepim
• To upgrade, you can either download only those packages I just mentioned from http://alien.slackbook.org/ktown/4.4.0/ and use “upgradepkg” to upgrade them, or if you already have a local mirror of http://alien.slackbook.org/ktown/4.4.0/ you can refresh this mirror and upgrade according to the article I wrote earlier: http://alien.slackbook.org/blog/its-been-released-kde-sc-4-4-0/ . Please note that I did not create an “update” or “patches” directory – the new packages have just replaced the old ones (with an updated build number).

Enjoy!

Eric

Many of the core packages have received an version upgrade, but those changes may not be immediately visible to the average end user. Some of the absolute highlights mentioned in the ChangeLog are indication of a big step forward for Slackware: a new kernel (2.6.28.7), new gcc (4.3.3), new glibc (still called 2.9 but the snapshot we use is more like 2.10), a new XFCE (4.6.0) and most importantly: KDE 3.5.10 is gone, replaced by KDE 4.2.1 (which had been living in the /testing directory for a long time).

I have been working with KDE4 releases for nearly a year now, running it as my default desktop, and 4.2.1 is stable, fast and beautiful. People who heard or read that the new KDE is bloated and slow, should try it out and decide for themselves; I think it performs better than KDE3. I also ran the new XFCE for a while and it looks sweet. Note that when you upgrade from XFCE 4.4 you may experience missing icons in the panel. This happens because the Rodent icon theme was removed from XFCE in the new release. The file CHANGES_AND_HINTS.TXT (located in the toplevel directory of slackware-current) explains this issue and what you can do about it.

One neat feature addition which did not make the ChangeLog, but is definitely worth mentioning: the initrd.img and usbboot.img files which contain the Slackware installer,  have also been updated for the new 2.6.28.7 kernel. As a result, you can now install Slackware to an ext4 filesystem!

If anyone out there with a Netbook (one of those Intel Atom powered, 9 or 10 inch sized laptops with long battery life) is going to install Slackware-current on it, I would like to hear your impressions. Leave a comment to this blog post.

Have fun, Eric