Planet Slackadelic

I had installed VirtualBox a while ago on my laptop running my Slackware64 test environment, so I could experiment with the program a bit. Then I forgot all about it.

Today, I upgraded to the latest set of slackware64-current packages, including the new 2.6.32.7 kernel and when I rebooted to that new kernel, I saw an error message scrolling by stating that “the vboxdrv kernel modules failed to load”. Of course… a new kernel needs all external modules to be recompiled.

When installing VirtualBox, I had already noticed that the installer is Slackware friendly; it installed a nice “/etc/rc.d/rc.vboxdrv” boot script and updated the “rc.local” script so that it runs “rc.vboxdrv” on boot. Well done!

It is easy to rebuild the missing VirtualBox kernel modules using that rc script: you just need to run it once with the “setup” parameter.

root@alienteepee:~# /etc/rc.d/rc.vboxdrv setup
Stopping VirtualBox kernel module ...done.
Recompiling VirtualBox kernel module ...done.
Starting VirtualBox kernel module ...done.
root@alienteepee:~#

That’s all there is to it!

Cheers, Eric

     I am really impressed with what Opera has managed to do with what they proudly claim “the next generation of mobile browsing” in the form of Opera Mini 5 Beta. It is as good a browser as I have never before used on a mobile device. Any words that I could concoct to describe how [...]

VLMC

In the past week, I have been messing a bit with the VideoLAN Movie Creator (VLMC). This is a new project – not yet released in a stable version – from the VideoLAN developer community. It is meant to become “a free video editing software, offering features to realize semi-professional quality movies, but with the aim to stay simple and user-friendly.”

The VLMC project has not yet released source releases, let alone pre-compiled binaries. The only place to go is the git repository and checkout the source code. Not everybody wants to try and have a go at retrieving source code from a git repository, so I have written a Slackware build script to create a proper package. The VLMC has a single dependency, which is libvlc. This library is part of the VLC multimedia player. Many of you may already have installed VLC on their machine, but there is a complication: VLMC requires bleeding-edge VLC source code, i.e. you will have to use a git snapshot for VLC as well. Building a package from VLC’s git code does not work out-of-the-box using my vlc.SlackBuild which currently produces a package for the stable 1.0.4 release. Several changes to the script were needed to adjust for new and obsoleted features.

I decided not to add my Slackware package for the VLC “snapshot build” to my Slackware package repository because this is unstable code, and I (as well as the VLC developers) can not guarantee that it works at all at any given time. Therefore I have created a place on the internet to share the VLC and VLMC packages that need to be installed together (note that this VLC package necessarily replaces any other version of VLC you may have installed, but that is the price you pay for your desire to be an early tester of VLMC…)

See http://alien.slackbook.org/vlmc_testing/ for the packages. From time to time I may decide to update the snapshot versions.

Translating a Qt applications

One thing I noticed is that VLMC still lacks a dutch translation. I think it will be nice to have a dutch translation of this program once it has been released, because I think it will become popular in the way VLC is already popular.

I have never translated a Qt application, so I had to look up how to approach this. It turns out that Slackware’s Qt package already contains all the tools required for the job! In order to create a language translation for a Qt application, you need the Qt Linguist application, which is a GUI for working with “*.ts” translation files. This program was hidden on my hard disk… it does not show up in my KDE menu. You can start it by running “linguist“. In KDE, you can press <Alt><F2> to open the command run interface.

First of course, I needed to extract all the text strings from the VLMC source code that are in need of translation. And to create this initial “.ts” file, Slackware’s Qt package contains the “lupdate” tool which is a commandline utility. This is how I created the file “vlmc_nl_nl_NL.ts” which is my starting point for the duch translation:

$ cd vlmc-20100111
$ LANG=nl_NL lupdate vlmc.pro -ts ts/vlmc_nl_nl_NL.ts

I then proceeded with starting Qt Linguist and loading this new “.ts” file. Next comes the task of adding dutch translations for the original english strings. Well… here I am, with a nice GUI and no time…

This is something I need to finish some other time I’m afraid. To get this exactly right I need to install the dutch language translation file for KDE and learn about the commonly used dutch phrases in order to make the dutch version of VLMC “blend in” with the rest of KDE. I really hope to work on this soon and send the fruit of my labour to the VLMC developers… time’s up for tonight.

Note: Documentation for Qt Linguist is available online: http://doc.trolltech.com/4.6/linguist-manager.html

Have fun! Eric

A bit of history… I realized that just a year ago, KDE 4.2.rc1 got added to Slackware’s “/testing” area.

With all the recent posts on this blog about KDE4 and me telling people how nice I think this version of KDE is, I realize that “liking” is a very personal expression of feelings. A feeling shared by many, fortunately, but there are still people who rather have the old KDE3 back, and the perceived stability that comes with it.

Those people should not read the next few paragraphs… instead do a fast-forward to the bottom half of this post :-)

One of the reasons for the switch to KDE4 in Slackware 13.0 was that I did not want to build KDE3 packages for slackware64 during the time that I was “secretly” building the package set for it. I had been running KDE4 on my Slackware laptop for more than half a year when I kickstarted the 64-bit port in september 2008. Looking at my options for completing slackware64, I decided that I should jump straight to KDE4. It would probably take until somewhere in 2009 before the 64-bit port would be released to the general public. By that time, KDE 4.2 would be available which I thought would be the right time to replace KDE3 in Slackware.

In january 2009, Pat added KDE 4.2.0 to “/testing“, which was essentially a 32-bit “rebuild” of the KDE 4.2.0 packages the Slackware team members were already running on slackware64. Close inspection of the 32-bit KDE SlackBuild scripts would have revealed that something was cooking. The build scripts contained numerous hints to the non-public 64-bit port. By that time I think most of us were running slackware64 on a daily basis and were used to working with KDE4 (well perhaps this is not tru for Robby, our avid XFCE user ;-). The goal for going public with slackware64-current was set for may 2009. This meant that the package sets for 32-bit and 64-bit had to be synchronized before that time. The SlackBuild scripts for slackware64 were written with the philosophy that they should compile 32-bit packages just as easily, so this synchronization effort was not particularly hard, technically speaking… just a tedious administrative job (Pat might disagree here :-) The only big change of course, was that KDE4 had to move from “/testing” into the core “/slackware/kde” package directory.

KDE 4.2.1 was the actual version to finally replace KDE3 in Slackware. This was in march 2009, and got big publicity, because it was a revolutionary upgrade and therefore not welcomed by all Slackware users (but what major change is, really). The KDE team on the other hand, was quite pleased about this ;-)

Note that I really like KDE4 – it has become so much more powerful a desktop than KDE3 ever was to me. There was just no way that we could keep everybody happy with the switch to KDE4. If Slackware 13.0 had shipped with KDE3, lots of people would have complained about “stale software”, since KDE3 was no longer maintained at that time (3.5.10 was the final release in the series). KDE 4.2.4 which did ship with Slackware 13.0, was good, with rough edges, but the best choice at that time. Since then, Vincent Batts has released a KDE 4.3.1 package set for Slackware 13.0: http://cardinal.lizella.net/~vbatts/kde/kde4-packages/4.3.1/ , slackware-current has moved to KDE 4.3.4 (stable and a joy to use) and my own packages for play-testing the KDE 4.4 prereleases (to be installed on slackware64-current) are mentioned in other blog posts of mine. KDE 4.4 is surrounded by some “political” issues involving the influence of certain big distros, which keep it from being included into Slackware in the near future. Perhaps I should talk about that in more detail, but I will spend another blog post on that.

However, many people have overlooked the fact that Pat actually did create a KDE 3.5.10 package set to accompany the Slackware 13.0 release. Its location is somewhat hidden and there was no publicity on the slackware.com web site. Mainly because KDE 3.5.10 for Slackware was released with status “unsupported“. It was meant as a service to the Slackware users who required more time to make the switch to KDE4.

You can find KDE 3.5.10 for Slackware 13.0 (32-bit as well as 64-bit packages are available) here: http://slackware.osuosl.org/unsupported/kde-3.5.10-for-slack13.0/

Cheers, Eric

For those running the 64-bit version of Slackware, I keep making available multilib versions of Slackware’s 64-bit gcc and glibc packages. Yesterday, gcc in slackware-current was updated to version 4.4.3, so here they are.

You can get them here: http://slackware.com/~alien/multilib/13.1/ (The “13.1″ may or may not be the version of the next Slackware release, I just needed to give that directory a name).

For detailed instructions about what multilib means to the 64-bit Slackware and how you can add it, read this wiki article: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib

Have fun! Eric

The KDE team are getting closer to the 4.4 release of the KDE Software Compilation (“KDE SC” is the new name of what used to be called just “KDE“).

The second release candidate has been released today (the release was delayed for several days). For Slackware Linux I have prepared 32-bit and 64-bit packages with the accompanying SlackBuild scripts. You will find those at http.//alien.slackbook.org/ktown/4.3.95/ (Version “4.3.95″ is the same as “4.4.rc2″).

As before, these packages are built for Slackware-current. You can safely install the KDE 4.4.rc2 packages if you are running a slackware-current from around 20 january 2010 or newer. Do not try to install these packages on Slackware 13.0.

Slackware64:

• Don’t forget to also install the updated or new dependencies! These “deps” packages can be found in the “x86_64/deps” directory.
• The KDE 4.4.rc2 packages themselves can be found in “x86_64/kde“
• And of course, the localization packages (non-english language translations of KDE) are available in “x86_64/kdei“. For the first time, I was able to build all of the non-english language packs without errors.

Slackware:

• Don’t forget to also install the updated or new dependencies! These “deps” packages can be found in the “x86/deps” directory.
• The KDE 4.4.rc2 packages themselves can be found in “x86/kde“
• If you need a language pack, you can grab one from the 64-bit package tree.

Here are the steps on how you download the packages and install them. You can have an older version of KDE installed, but that is not required. You will end up with KDE 4.4.rc2 installed on your system. Instructions are for the 64-bit packages, I think you can figure out how to change them if you want the 32-bit versions:

1. Download everything in the directory http://alien.slackbook.org/ktown/4.3.95/x86_64/ :
   # lftp -c "open http://alien.slackbook.org/ktown/4.3.95/ ; mirror x86_64"
2. Change into the directory “x86_64″ which has just been created in your current directory:
   # cd x86_64
3. Remove the no longer required kdelibs-experimental package if you still have that installed. It is part of KDE 4.3.x (i.e. Slackware 13.0 did not have this package). If you do not have kdelibs-experimental on your system, you will get a harmless error message that you can ignore:
   # removepkg kdelibs-experimental
4. Install/upgrade the KDE 4.4 dependencies:
   # upgradepkg --reinstall --install-new deps/*.t?z
5. Install/upgrade KDE4.4.rc2 packages:
6. # upgradepkg --reinstall --install-new kde/*.t?z
7. Install/upgrade a language package if you prefer to have the KDE interface in your local language (I used “nl” in the example command, you should substitute your own language code there):
   # upgradepkg --reinstall --install-new kdei/kde-l10n-nl-*.t?z

Of course, you should not run those commands while running KDE…!

A big project like KDE needs fast hardware in order to compile in a reasonable time, and I have only one machine (which also happens to be my desktop computer) where I can do this. I strive to have 32-bit packages available as well as 64-bit packages for the final 4.4 release of KDE SC like I did for this release candidate.

If you want to compile the packages from source like I did, that is entirely possible using the provided sources and build scripts.

Have fun, Eric

     By and large, Carbide is the best IDE for Symbian development available today. Working on the shoulders of Eclipse, Nokia has spent considerable time and effort into customizing Carbide to a point where it makes Symbian development convenient for developers. Having said that, I should also point out that Nokia and Carbide both have a [...]

When you are installing Slackware, you have several options of using the network. Your packages can be on a NFS, HTTP, FTP or SaMBa server. But it still requires you do be physically present behind the keyboard of the computer you are installing Slackware on.

Or does it?

There is a way to make the installer launch an embedded SSH server automatically. Once that SSH server is running,  you can do a remote login to this machine and install Slackware.

I hear you say, “why would I want to install Slackware over a ssh session at all”? Well, this feature is particularly important for people who need to install Slackware on a headless server – think of a server in a data center. You still need to boot the Slackware installer of course, but you do not need a DVD for that. If you have a PXE server, you can boot the installer over the network and never have to visit your computer “in the flesh”.

If you are familiar with Slackware’s installation, you know that you have to answer a few questions before you can start with a network installation. At a minimum, you need to

• configure your keyboard layout, and
• the configuration of your network card.

For these to be configured automatically, you must provide the installer with the answers. If both answers are known, then the installer can configure your network card with an IP address and start the embedded SSH server (Slackware uses dropbear as the SSH server). You can then do a remote login as root (no password will be asked! Be sure that your network is secure before you attempt this).

After you have logged on to the dropbear SSH server (you must know what IP address your to-be-installed computer has been configured with of course) you can remotely start Slackware’s “setup” (but first you have to run the command “. /etc/profile” – watch the dot! – which initializes the environment so that the setup utilities become available).

Burning question: how do you tell the installer the answers to the above two questions?

I am assuming you are booting the installer from the network, using a PXE server. Now, let’s assume your keyboard layout is “us“, your network interface is called “eth0” and you have a DHCP server in your network. Then, you need to change the “pxelinux.cfg/default” file like this:  add the following string to the “append” line for your boot kernel:

kbd=us nic=auto:eth0:dhcp

If instead, you want to use a static IP address of “192.168.0.11/255.255.255.0” (i.e. a netmask of 24 bits) the appended string becomes:

kbd=us nic=auto:eth0:static:192.168.0.11:24

Slackware’s installer uses udev for automatic hardware initialization and configuration. If you don’t want to use udev but want to determine yourself what module to load then this would be the appended string (I also added a default gateway of “192.168.0.254” to the mix):

noudev kbd=us nic=e1000:eth0:static:192.168.0.11:24:192.168.0.254

The generic notation for the kbd= and nic= parameters is:

kbd=<keyboard_layout>
nic=<driver>:<interface>:<dhcp|static>[:ipaddr:netmask[:gateway]]

If your installer uses udev (the installer of Slackware 13.0 and later uses udev by default, earlier versions of Slackware did not have udev in the installer) then the “<driver>” string can be “auto”. Without the use of udev, the “<driver>” must be an actual kernel module for your card, like “e1000” in my example above.

I’d like to hear if you ever used or wanted to use this somewhat hidden feature of the installer!

Eric

Note: If you do a “normal” Slackware installation and want to start the dropbear SSH server manually after configuring the network card, you can do this. Just run:

/etc/rc.d/rc.dropbear start

There's two ways of doing this that I use; one is fairly clean:

• Get a wildcard certificate (*.example.com)
• Put all of your sites as subdomains (eg foo.example.com, bar.example.com)

While it "just works", it restricts your choice of domains; an alternative solution, which isn't really suitable for your users, but fine if you just want secure access to an admin panel (your blog, PhpBB, etc) on several different domains, you can hack something together with Apache, mod_proxy, mod_rewrite, and some cookies:

Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Thu, 01 Jan 1970 00:00:00 +0000"

RewriteEngine on

RewriteRule ^unset$ https://example.com/ [L,R=301,CO=site:example.com:example.com]

# foo.example.com
RewriteRule ^foo$ https://example.com/ [L,R=301,CO=site:foo:example.com]

RewriteCond %{HTTP_COOKIE} site=foo
RewriteRule ^(.*)$ http://foo.example.com/$1 [L,P]

# bar.example.com
RewriteRule ^bar$ https://example.com/ [L,R=301,CO=site:bar:example.com]

RewriteCond %{HTTP_COOKIE} site=bar
RewriteRule ^(.*)$ http://bar.example.com/$1 [L,P]

If you install the above as ".htaccess" in the root of https://example.com, then https://example.com/foo will make https://example.com/ act as a proxy for http://foo.example.com, https://example.com/bar will make https://example.com/ act as a proxy for http://bar.example.com, and https://example.com/unset will make it display whatever it normally displays.

I hope someone finds this useful.

I’ve been spending the last few weeks, on and off, trying to figure out the level of Microsoft Exchange support in KDE at the present moment and near future. From lots of digging around various sites, and poking at the source code, it seems that:

1) libmapi (from OpenChange) provides a library that can talk to MS Exchange 2007

2) KDE has an OpenChange resource for Akonadi

3) The Akonadi OpenChange resource is currently not built by default, and based on comments in the make files, not clear what the current status is

4) KMail does not currently use Akonadi anyway, and won’t be ported over to it until at least KDE SC 4.5

Corrections welcome.

One of the things I've had the pleasure of working with for Mendeley is Hooq; Hooq is a GPL/LGPL-licensed system for testing Qt4 GUI applications, on multiple platforms (Linux and Windows being where most of the focus has been at the moment). It's mostly GPL, but an LGPL library is loaded into applications being tested, at runtime.

With apologies in advance for the incredibly unfriendly UI at the moment (patches welcome :p), here's a lots-of-pictures demonstration on using it to test a trivial application.

After building the demo application and Hooq, and running hooq, you'll get a screen like the following:

For organisation, Hooq uses the concept of a 'test set' - this can be one per application, tests for different areas of the same application, or whatever you choose. First, you need to create one - select "New Test Set..." from the file menu, and you'll get another ugly dialog:

After filling it in and clicking OK, you'll be back to the main screen, except that 'Test set' will be filled in (screenshot); type in 'Foo' in the box at the bottom, then click 'Record' (screenshot). The demo application will then start - if you type in "Hello, World" you should see something like this:

Click the close button in the window decorations, and the Hooq window will now have a test entry, with run and edit buttons:

After clicking on the edit button highlighted above, you'll get a script editor (Hooq uses QtScript for test scripts):

If you then click in the margin on the line after "QTextEdit_0.sendText(string0)", there'll then be a breakpoint marker on that line:

If you then click the run button in the toolbar, the script will stop running at that line:

At this point, if you click 'pick property' in the toolbar (new icons welcome), you can then click on any widget in the application being tested, and get a list of its Q_PROPERTYs:

For this example, scroll down to "plainText", and click compare; this will insert a check into the JavaScript code in the editor:

Remove the breakpoint, and run it a few times; it should repeat your input and quit each time, without an error; however, if you change the "string0" variable at the top from "Hello, World" to something else, like "Hello, World!", then click run, the test will error, if you don't also change the compare statement:

This is more useful when the test hasn't changed, but when the application itself has (i.e. a regression). Hooq also has a "Run All" feature, to run all the tests in a set unattended, and show a summary at the end.

As some more detailed information:

Hooq loads a shared library into the application being tested (via gdb under Linux, and a very ugly hack under Windows) which recieves every QEvent in the application, and sends user input events, encoded in XML, to a hooq client (the GUI client is shown above, but there's also a CLI one that just records and plays the XML data). In the GUI client, the XML is converted into a tree of sorts, and then a few modifications are optionally made (selectable via the "Options" menu):

These options are:

Ignore Mouse Movements

Don't create JavaScript code for mouse events, except where they end up creating drag and drop events.

Simplify Mouse Movements

Only available if the above is off; instead of creating code for every single 1-pixel mouse movement made, create simplified code, like "move in a straight line from (x1, y1) to (x2, y2) over 300 milliseconds"

Simplify Strings

Repeated keyPress/keyRelease events are composed into "sendText" events, which take a string parameter. Like the two above options, this greatly decreases the length, and increases the readability of the generated code.

Use Variables For Strings

Any string used by sendText is stored in a JavaScript variable, instead of being hardcoded every time it is used; this makes it easier to modify the script in the future.

Use Variables For Object References

This doesn't change the meaning of the code at all, but generally makes the code shorter.

Include Raw XML as Comment

Mainly useful for debugging; includes the raw XML code received over the socket as a JavaScript comment

Ignore Qt Internal Widgets

Qt in some circumstances (such as drag and drop under X11) automatically creates magic widgets; this option makes Hooq ignore them.

Last week, an upgraded gcc compiler suite (version 4.4.2) was added to slackware-current . The new Gnu C compiler reveals software compilation issues in several programs that did not occur with the previous version of the Gnu C compiler. A nice summary of issues you may encounter when building software using the scripts at SlackBuilds.org can be found on Ponce’s blog, along with the solutions he found that fix these errors.

So far, I only ran into one compilation issue (actually it was reported first on LQ: http://www.linuxquestions.org/questions/slackware-14/alien-bobs-vlc-slackbuild-fails-on-current-781414/), when compiling VLC and to be more specific, compiling the twolame library which I add to my VLC package for Slackware.

The error you will get is this:

psycho_2.c:203: error: array subscript is above array bounds

The fix is simple. One file needs a patch:

--- twolame-0.3.12/libtwolame/psycho_2.c.orig   2008-01-09 12:06:21.000000000 +0100
+++ twolame-0.3.12/libtwolame/psycho_2.c        2010-01-11 15:15:28.000000000 +0100
@@ -121,7 +121,7 @@
        window = mem->window;
        ath = mem->ath;
        numlines = mem->numlines;
-       partition = mem->numlines;
+       partition = mem->partition;
        s = mem->s;
        tmn = mem->tmn;
        fthr = mem->fthr;

I have uploaded this patch as well as a modified vlc.SlackBuild script to my repository: http://slackware.com/~alien/slackbuilds/vlc/build/

Eric

Just a quick update:

I have finished building Slackware packages for KDE 4.4 RC1 (aka version 4.3.90). Compared to the previous Beta2, several of the dependencies have been updated. And just as with Beta2, I was unable to create language packs for ca, da, es, et, it, sr due to docbook errors.

Get KDE 4.4.RC1 packages for Slackware-current (64-bit only) here: http://alien.slackbook.org/ktown/4.3.90/ … Because the sources and SlackBuild scripts are available as well, you should be able to create 32-bit packages quite easily yourself.

Have fun, Eric

     I have been noticing that on the first of every month, the wi-tribe connection that I am using stops working as soon as I receive the invoice email. Browsing stops. Replies to ping requests stop. All Internet activity comes to a halt.      When this happens, I get in touch with a customer support rep and [...]

The new kernels in Slackware (post 13.0) have one important change compared to previous kernels. This change will affect anyone with Slackware installed on an IDE disk (like /dev/hda) who wants to upgrade to the latest state of affairs.

The new kernels exclusively use “libata”. The last bits of the old IDE/ATA subsystem have finally been removed.

This means, that your IDE disk will be recognized as a “SCSI disk”. The device name “/dev/hda” will change to “/dev/sda” when you boot the new kernel. As a result, your computer will refuse to boot because the bootloader (grub or lilo) can not find the root device.

Robby Workman has written a HOWTO for anyone who wants to do this upgrade. The article was published as http://rlworkman.net/howtos/libata-switchover. By following the HOWTO you will not have any issues in upgrading to the new kernel.

I will print Robby’s HOWTO in full below to give it some more coverage:

libata_switchover
20100110
rworkman

/*
Thanks to David Somero, Old_Fogie, gegechris99, and GazL for valuable
feedback and enhancements to this document.
*/

This is written to provide one of several ways to retain a working system after upgrading from Slackware 13.0’s kernel to the newer kernel in -current (which removes support for the “old” ide subsytem, thereby causing all /dev/hd* devices to have /dev/sd* names.

1. Upgrade the kernel and kernel-modules packages normally.

2. Edit /etc/fstab and /etc/lilo.conf to reflect the change from hd* to sd*. Make a note of what the “boot=” line is in /etc/lilo.conf before you do the edit – you’ll need that later.

If you have multiple SATA devices, and especially if you have some of both hd* and sd* devices present already, then you’re basically going to be playing a guessing game right now, and you probably want to consider using /dev/disk/by-uuid/<uuid> instead of raw device nodes.

* If you are using one of the generic kernels (requiring an initrd), then use the sd* name for the root device when creating the image.

* You will almost surely want to remove the udev rules file for cdrom devices (it will be regenerated on the next boot with correct information reflecting the new libata stuff):
# rm -f /etc/udev/rules.d/70-persistent-cd.rules

* Speaking of optical devices, if you have multiple disk drives and an optical drive using the old ide subsystem, then be aware that the optical drive will get a /dev/sr* name instead of /dev/sd* — this is relevant because you might see something like this (if your optical drive is currently /dev/hdb):

Old Name –> New Name
/dev/hda /dev/sda
/dev/hdb /dev/sr0
/dev/hdc /dev/sdb

3. Run lilo with the “-b” flag to reflect the proper boot= parameter (the one you noted in step #2). As an example, if your current boot= line has “boot = /dev/hda”, then you will run this:
# lilo -v -b /dev/hda

4. Reboot

Good luck! Eric

PS: I have refreshed the copy of Robby’s text so that it reflects the updates he made to the original after feedback from several people.

… Ok, ok, it is not so bad actually! Au contraire!

Slackware Linux development made a big leap today, when Pat Volkerding updated the distro’s “vital organs” of kernel, glibc and gcc. The “dull” phase of the slackware-current development cycle is over hopefully, and it’s back to the bleeding edge.

To be fair, gcc 4.4.2 has been sitting in “testing” area for quite a while now, and we think it is time to promote it into the core. With glibc 2.11.1 we are pushing it, as this is the most recent stable release, and the 2.6.32.2 kernel was much-anticipated by those who run -current on their computers.

Note that the new kernel has full support for EFI (the Extensible Firmware Interface which is going to be the replacement for the ageing BIOS on modern computers). This means that there is also support for GPT partitions. GUID Partition Table is a standard for the layout of the partition table on a physical hard disk (part of the EFI specification and meant to overcome the 2 TB size limitation of MBR partitions). We still have to look into updating the Slackware installer for automatic GPT partition recognition, but you will be able to use GPT partitions if you do some footwork yourself before running “setup”.

With this update to Slackware’s vitals, the stage is set for further tweaks of the core, but I think that for now, you will have plenty to play with.

And as promised to those running the 64-bit version of Slackware-current, I have made available multilib versions of the new gcc and glibc packages! Thanks to Pat Volkerding who allowed me sufficient time to build and rebuild these packages on my old computer until they were just perfect (I hope) and could be released along with the Slackware originals.

You can get them here: http://slackware.com/~alien/multilib/13.1/ (I took the liberty of assuming that 13.1 will be the version of the next Slackware release, mainly because I needed to give that directory a name).

For detailed instructions about what multilib means to the 64-bit Slackware and how you can add it, read this wiki article: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib

Have fun! Eric

Just before christmas in 2009, the KDE community released the second beta of the upcoming KDE 4.4 desktop environment (or to use the correct name, KDE Software Compilation 4.4).

In Slackware Linux’s development tree we still have 4.3.4 which works really well, but in KDE 4.4 some major strides are being made towards an even better work environment.

I decided to have a look at these new developments, especially since the Nepomuk search should work a lot better with the new and fast Virtuoso backend, and built the whole of KDE 4.4.beta2 for our 64-bit Slackware Linux.

I was not disappointed. Even though this KDE 4.4 prerelease is labeled “beta”, I have found it to be quite stable, fast, slick and very useable. The improvements which I have seen from 4.1 -> 4.2 -> 4.3 -> 4.4 keep amazing me… let alone the giant leap that lay between 4.0 and 4.0… everybody remembers the heated debates between the early adopters of KDE4 and those who hated it. At the time we added KDE4 to Slackware, that was seen as a milestone release. Now, I can not imagine ever going back to using KDE3 as my default desktop. And yes, Nepomuk search is pretty nifty, lightning fast and it does not feel like it is eating away my computer’s resources.

So, I am making my Slackware packages available to the general public – for all of you to enjoy. There is one caveat though:

You will need to run a development snapshot of 64-bit Slackware (meaning, slackware64-current of around 25-december-2009 or newer).

These packages do not work on the 64-bit release of Slackware 13.0. Neither do I have packages for the 32-bit release of slackware-current, simply because I do not have a computer in the house which is running slackware-current and is powerful enough to build KDE4 and the various dependencies in a reasonable time.

KDE 4.4 has requirements that are a bit different than with KDE 4.3.x which we have in slackware-current, or even 4.2.4 which we have in Slackware 13.0. You will have to upgrade several non-KDE Slackware packages as well as add some new ones.

Now, go and have a look at http://alien.slackbook.org/ktown/4.3.85/ . Version 4.3.85 is the same as 4.4.beta2.

• All of the dependencies that you need are in the “x86_64/deps” directory.
• All KDE packages can be found in “x86_64/kde”.
• KDE localizations (language packs) are available in “x86_64/kdei”.

These are the steps you take to upgrade slackware64-current to KDE 4.4.beta2. It will bring you KDE4 even if you did not have it installed before. As part of the steps you will be downloading the new Slackware packages, but not the source or SlackBuilds. It is easy to modify the download command to also get you the sources if you want this.

1. Download all of the directory http://alien.slackbook.org/ktown/4.3.85/x86_64/ :
   # lftp -c "open http://alien.slackbook.org/ktown/4.3.85/ ; mirror x86_64"
2. Change into the directory “x86_64″ which has been created:
   # cd x86_64
3. Remove the no longer required kdelibs-experimental package:
   # removepkg kdelibs-experimental
4. Install/upgrade the new dependencies:
   # upgradepkg --reinstall --install-new deps/*.t?z
5. Install/upgrade KDE4.4.beta2 packages:
   # upgradepkg --reinstall --install-new kde/*.t?z

Of course, you should not run those commands while running X and certainly not while running KDE… After the upgrade process finishes, you can start a KDE session and you will be greeted by the familiar yet subtly different  user interface of KDE4.

NOTE: Some of the localizations (the KDEI series) had errors while building. Missing from this beta release are the localizations for the following languages:

ca, da, es, et, it, sr.

Here is a screenshot of my desktop with Dolphin showing a Nepomuk-powered search result for the word “slackware” in documents that it indexes, as well as Dolphin’s extremely convenient “terminal mode” (just press F4 to open Dolphin’s terminal if you need the speed of the commandline for some file operation). You’ll also notice that adding widgets to your desktop looks quite different now.

Have fun, Eric