Alien Pastures

My thoughts on Slackware, life and everything

Month: January 2010 (Page 1 of 3)

Compiling a new kernel module for VirtualBox

January 31, 2010 / / 11 Comments

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, and translating a Qt application

January 26, 2010 / / 1 Comment

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

KDE3, KDE4 and Slackware 13.0

January 26, 2010 / / 28 Comments

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

Updated multilib gcc packages for -current

January 25, 2010 / / 2 Comments

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

KDE Software Compilation 4.4 RC2

January 25, 2010 / / 7 Comments

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

« Older posts

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑