Alien Pastures

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

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

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

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

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