virtuoso

Along with my packages for KDE 4.7.x I added an updated version of virtuoso “data management server” which powers a lot of the functionality in today’s KDE: However there was a regression in this version 6.1.3 which messed up the display of path names containing non-ascii (i..e Unicide) characters. See https://bugs.kde.org/show_bug.cgi?id=271664 for more details about this issue. I applied a fix to my virtuoso-ose package which solves this.

Package available here in the 4.7.1 section: http://alien.slackbook.org/ktown/ as well as all the usual mirrors.

kde-workspace

Martin Graesslin wrote an email to the KDE packagers mailing list with the plea to apply a patch to all binary packages of kde-workspace after he discovered a bug in KWin’s handling of desktop effects which apparently has been present in all versions since 4.0. The bug would cause a performance degradation which becomes worse when more windows are open on the desktop. Martin’s blog article describes how he discovered the bug during his performance analysis of KDE 4.8 code. I have applied the patch he provided in his email to my KDE 4.7.1 kde-workspace package and I will wait for a backport to KDE 4.6.x before attempting to apply the fix to the kdebase-workspace package in there.

Package available here in the 4.7.1 section: http://alien.slackbook.org/ktown/ as well as all the usual mirrors.

vlcgit

This is not a package update per sé. I have been compiling the development version of the VLC media player for a long time (I think I started re-writing the vlc.SlackBuild script for the development snapshots in January 2011). I had varying success with the package, as my build script would “break” from time to time. When someone in the #videolan IRC channel wondered if the development code would work better for high-bandwidth H.264 movies (VLC 1.1.11 drops too many frames) and a VLC developer suggested that the development code has a lot of optimizations in this regard, I decided to release a package based on my SlackBuild script. I called the package directory “vlcgit” and the build script “vlcgit.SlackBuild” but the actual package is named “vlc” so that you can easily update from 1.1.11 to this development snapshot. The vlc program will identity itself as “1.2.0-git” when it starts. I think it is worth your while to try it out because there have been lots of enhancements and additional features in the past year.

VLC 1.2.0 is expected to be released before the end of 2011.

Packages here: http://slackware.com/~alien/slackbuilds/vlcgit/ (which is a US server so these packages do not contain the mp3 and aac encoders because of patent disputes) and at http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlcgit/ (for the version that includes mp3 and aac audio ENcoding capability). Also available on all the other mirrors of course.

flashplayer-plugin

The Adobe people are finally putting good effort into their Linux flash player plugin. One month after the “beta 2″ release we now have the “release candidate 1″ of the upcoming Flash Player 11. It looks like the releases for Linux and Windows platforms go hand in hand now, which is a reassuring sign that we Linux users are taken seriously.

Package available at http://slackware.com/~alien/slackbuilds/flashplayer-plugin/

calibre

The calibre download page states that you should “not use your distribution provided calibre package, as those are often buggy/outdated. Instead use the Binary install described below“. Of course you are free to follow that advice, but if you prefer to know how your packages get built, like me, you can still grab the packages that I provide. There is a new release of Calibre every friday and I have been following that release cycle for the past months, releasing updated packages the same day. I use Calibre every day and am happy with my builds.

Get the package here: http://slackware.com/~alien/slackbuilds/calibre/

sigil

If you are seriously into writing or converting e-books, then Calibre is the perfect management and conversion software for the task. But Calibre does not offer an actual epub editor. Epub is an open specification for electronic books and widely used all over the world except for the US apparently where Amazon dominates with the mobi format used for its Kindle. Both mobi and epub formats are quite similar, basically it is HTML text plus a book’s metadata, bundled together in a ZIP archive. Whether you are writing an ebook yourself, or need to clean up an ebook provided by someone else, there is one application which is best suited for this task: Sigil. Sigil is designed to edit epub format only. It contains an embedded HTML tidy which cleans up the book’s HTML code autimatically and an embedded Flightcrew, which assists you in validating your book to the EPUB specification.

The Sigil homepage offers pre-built binaries, but these are quite big. Since they have to work everywhere the binaries include a lot of libraries which we already have in Slackware. The new Sigil maintainer seems to be very responsive so I asked him if he could put up a page with distro-specific packages and add a link to my Slackware package there. He did that right away, and more distros have been added there since.

Get the package fir Sigil here: http://slackware.com/~alien/slackbuilds/sigil/ .

Good fun with all of this! Eric

Update Sun Sep 11 15:43:06 UTC 2011:

libbluedevil

Willy Sudiarto Raharjo pointed out that there was another package update and I failed to mention it. The 32bit package “libbluedevil” was not tagged with my “alien” tag initially, and I fixed that by renaming the affected files in the repository.

Remember why tagging your packages is useful? If you use slackpkg to keep your Slackware up to date, then you can blacklist all my packages (since I apply the “alien” tag to all my packages) so that slackpkg does not “see” them anymore. Add this single line to the file “/etc/slackpkg/blacklist“:

[0-9]+alien

If you want to know what the view looked like…

From Photostream

Of course there was a lot more to see. We hunt old ruins with our camera! Brittany is full of chapels, monasteries, and the boulders everyone knows from places like Carnac.

When I got back home, the first packages I needed to push out were VLC because 1.1.11 plugs two vulnerabilities, and the new beta of flashplayer 11 because finally Adobe seems to have merged the development of the 64-bit version with the “mainline” 32-bit plugin. They are both essentially the same version now, 11 beta 1 (build date 071311). The plugin itself reports that it has version 11.0.1.60.

Get the packages for vlc and flashplayer-plugin at the usual location: http://slackware.com/~alien/slackbuilds/ (the version of vlc without the patent restrictions that can encode mp3 and aac (instead of just being able to decode these formats) to be found as usual at http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/)

More packages to come, but that needs more preparation before I can start. I need to build a patched KDE 4.6.5 package for kdeutils, and all of the KDEI source tarballs seem to have been re-generated by the KDE release team while I was on holiday.

Have fun! Eric

Yesterday saw an update of my favourite multimedia player, and I had missed it…

VLC player is now at stable release 1.1.10 – apart from bugfixes and codec updates, this is also a security update (no known CVE number yet) so everybody is enccouraged to upgrade his installed version.

Get Slackware packages from my repository or one of its mirrors. And remember, if you need to encode mp3 or aac audio (there is no functional difference in decoding audio between all my packages) you need to grab the package which is inside the “restricted_slackbuilds” directory. Patent trolls prevent me from hosting those packages in the US on slackware.com.

• http://slackware.com/~alien/slackbuilds/vlc/ (master)
• http://taper.alienbase.nl/mirrors/people/alien/slackbuilds/vlc/
• http://slackware.org.uk/people/alien/slackbuilds/vlc/

MP3/AAC patent restricted:

• http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/
• http://slackware.org.uk/people/alien/restricted_slackbuilds/vlc/

Enjoy! Eric

You surely noticed a bit of silence on this blog. Well, there was not much to say – I am not the twittering kind of guy who updates his readers where he’ll go out every night… I think I can lift the lid a little anyway.

I have been working on several larger packaging projects during the past weeks. LibreOffice is the one that took most of my time unfortunately. The new release 3.4.0 has been announced today, and that means I can finally test my revised SlackBuild script when building Slackware packages for you. My old way of compiling LibreOffice no longer works! It has been “deprecated” by the developers, which is a shame because it forces me to do a lot more work. Anyway, expect packages for Slackware 13.37 sometime this weekend.

I will probably not create Slackware 13.1 packages for this new LibreOffice release. What I do consider is to build the upcoming maintenance release for LibreOffice 3.3 (which will be 3.3.3) for Slackware 13.1.

KDE. How to begin? There are some stirrings in the KDE camp.

We are nearing the end of the KDE 4.6 series. Two more updates will see the light: 4.6.4 should be available in a few days and 4.6.5 is the final update, expected in early july. But considering the fact that the previous 4.6.3 experienced delays, it may take a little longer before I can start on packaging 4.6.4.

The new series 4.7.x proves to be a bigger challenge for Slackware. We saw that the 4.6. series moved away from HAL and instead requires udisks/upower (which was the reason for sticking with 4.5.5 in Slackware 13.37). The KDE developers have now finalized their move from CVS to GIT as the source control and version management system. The result is less than optimally arranged for packagers. The old “monolithic” source tarballs are now being split into many additional tarballs for individual applications. This means we have rewrite our scripts and possibly add a lot of packages. While this may be advantageous for some other distros with dedicated packaging teams, for us Slackware people it is a time for decisions.

After talking to Pat Volkerding, I announced on the KDE packager mailing list that we are considering the same solution as was chosen for GNOME in the past: remove KDE from Slackware if it proves to become a maintenance burden. I can not yet say anything final about this. For the time being, I have decided not to create Slackware packages for the KDE Software Compilation 4.7.x.

And then VLC…I have been waiting for a 1.2 release for so long that I almost do not believe it will ever arrive. I have a SlackBuild for it, but I will likely wait a bit longer before releasing a package for ths development version of VLC media player. It appears like there is a 1.1.10 release around the corner which is what I’ll build for Slackware 13.1 as well as 13.37.

Looking ahead, I think that creating VLC versions for Android is going to be considered more important. There is a whole new audience there, and I may very well be one of its users. There is also the fact that the developer team is almost always short of smart and motivated people. This showed last year when it was almost impossible to release a MS Windows version. Jean-Baptiste Kempf feels responsible for this so he made it happen, but I doubt that it is making him very happy.

And finally, Calibre E-book Management. This piece of software is indispensible if you are in the possession of an E-reader. Calibre manages your e-book collection, converts e-books between various formats (interesting for you Kindle users out there!) and allows you to upload books to your E-reader device. Calibre usually works a lot better than the software you get with your E-reader. And  since I am buying a Sony PRS650 for my wife I needed to have a working verison of Calibre for my Slackware box.

I have a Slackware package for Calibre in my repository but I have not been able to update it for a while, because it requires python 2.7. Unfortunately, Slackware 13.37 is still at python version 2.6.6. So I spent a lot of time to find a way around this and decided to take the same approach as with VLC and FFMPEG: that is, to compile all the requirements into the package itself and not depend on Slackware. I think I have succeeded in this, and am currently testing the results. Stay tuned…

Happy hacking! Eric

* VLC 1.1.8 available

Another minor release in the 1.1 series, version 1.1.8 saw the light yesterday. Bugfixes and updates for the translations are its main features, but several small enhancements were made to the codec modules.

New encoders for dirac video (now using the schroedinger implementation) and webm /vp8 were added but to be honest, I have not looked at those since I rarely encode audio or video. Feedback welcome of course!

Noteworthy is the fact that VideoLAN celebrated its 10th birthday of going open source this february – the software was initially developed as a french student project under a closed-source license. Hilarious promotional video there… typical french humour?

Get the Slackware packages here (built on Slackware 13.1, will work on later versions too):

• http://slackware.com/~alien/slackbuilds/vlc/ (US-safe versions, i.e. without MP3 or AAC encoders)
• http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/ (includes MP3 and AAC encoding capabilities)

The “US restrictions” are ludricous crap, but there you go… otherwise I would not be able to host the packages on the slackware.com server. Of course, mp3 and aac decoding is not a problem at all.

And for you KDE 4.6 users, remember having this problem with the “Media > Open” file browser dialog box taking 30 seconds to appear, that issue has been resolved. The fix was applied on the KDE side (it was gone with KDE 4.6.1) but I thought I’d mention it here regardless because it was a nuisance. See https://bugs.kde.org/show_bug.cgi?id=260719 for a nice discussion between KDE and VLC developers. Interesting to read on https://bugs.launchpad.net/kubuntu-ppa/+bug/708527 is, that while we do not have this bug anymore in Slackware’s KDE 4.6.1 (well, my own KDE 4.6.1 for Slackware 13.37 to be precise), it appears that Kubuntu’s KDE 4.6.1 still suffers from it…

* LibreOffice 3.3.2 … wow that was fast!

The LibreOffice development really shows the power of collaboration. Little over a month after their previous “micro release” 3.3.1, here we have 3.3.2 already. It shows plainly that LibreOffice is diverging fast from its origin OpenOffice.org. How is that possible? Well, the most obvious reason is the growth in numbers of developers. What was impossible while SUN and later Oracle held the reigns, is now showing its worth: people are contributing code, and with more people starting to dig at the deeper levels of code, this momentum of development will only accelerate.

Specific highlights for the 3.3.2 release are the code cleanups: german-only comments have been replaced and no longer used code has been removed. If the schedule is not slipping we’ll see the big release 3.4.0 in May. This is supposedly the release that is going to make the large step away from OpenOffice.org.

I created some Slackware packages for you (built on Slackware 13.1, works on Slackware 13.37 too). Using the new LibreOffice menu icons instead of the old OpenOffice seagull logos, its looking prettier even! I added a dictionary to the italian language pack, but other than that I did not diverge from the way I built the previous 3.3.1 packages.

One word about the dictionaries (which I included for en-GB, en-US, es, fr, it, nl language packs): they are installed as “shared dictionaries” i.e. they will show up in your extension manager as locked and unchangeable. You can still install your own dictionary on top of that, if you find one that is more advanced or better suited to your work. This personal version will be installed into your ~/.ooo3 user directory and will have preference over the shared version.

Get packages here:

• http://slackware.com/~alien/slackbuilds/libreoffice/ , or
• http://taper.alienbase.nl/mirrors/people/alien/slackbuilds/libreoffice/ (fast mirror)

Enjoy!  And tell me if you like these packages (or if you see room for improvement).

Eric

VLC 1.1.6 which is now available as a source tarball fixes a security hole that was reported in december 2010 which makes it a recommended upgrade.

A lot of other changes and bugfixes went into the new VLC , you can read all about that on the release notes page. I think that now, the waiting is really for the next revision of VLC (1.2.x) to come out of the git repository and be released as stable. That has been in development for a long time now, and offers a completely re-developed mozilla plugin (the plugin package which accompanies VLC 1.1.x is not really a reliable piece of work) and of course a whole lot of feature enhancements compared to the maturing 1.1.x series.

One of the things that the 1.1.6 version should have fixed is the annoying behaviour in KDE 4.6 where, if you select “Media > Open file” it takes 30 seconds to open a file browser. After that first delay, every subsequent file-open dialog will open instantaneously – strange isn’t it? There is an open bug report for this issue: https://bugs.kde.org/show_bug.cgi?id=260719 and it shows a lot of discussion but no real fix since the KDE and VLC developers basically point to each other to provide a fix. Looks like fixing this in KDE is going to be difficult and VLC would be able to work around the issue. Unfortunately, the code that went into VLC at the last minute (see http://git.videolan.org/?p=vlc/vlc-1.1.git;a=commit;h=ac11f9c0e27905087afdfb46180ece227a4d76e7) does not fix it for me.

Enough said. Before I point you to the download location for my Slackware VLC packages, let me humour you with this VideoLAN promotional video made by Adam Vian: http://images.videolan.org/images/vlc-player.mp4 (download first, then load it in VLC). Very funny, worth watching.

Slackware 13.1 packages for vlc-1.1.6 can be found here (32-bit and 64-bit, they will work on slackware-current too of course):

• http://slackware.com/~alien/slackbuilds/vlc/
• http://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/ (mirror site, this package has mp3 and aac encoding capabilities)

Rsync access: rsync://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/

Have fun, Eric

… 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

As you may know I am using KDE for my daily work. However, I use XFCE from time to time – for example when I have to run a remote X session over XDMCP and want to keep a fluid feel to the desktop.

When I was working in XFCE yesterday I wanted to use VLC to check a video file on my computer, and I was in for a surprise when clicking “Media > Open file” made my VLC hang indefinitely!

I remembered a discussion about this phenomenon on LinuxQuestions.org and indeed the solution as pointed out in that thread works for me.

What happens here?

The core of the issue, is that Qt4 makes an incorrect assumption about which GTK+ theme engine to use. A GTK+ theme engine makes a Qt4 application blend in nicely with a GTK+ based desktop environment such as XFCE, by using GTK+ instead of Qt4 to render all graphical components.

There are a few GTK+ theme engines available – one of them is QGtkStyle which is part of Qt4 in Slackware. However, Qt4 libraries look at the environment variable “GTK2_RC_FILES” in order to find out how to configure the GTK theme engine.

If this environment variable is not (or incorrectly) set, then Qt4 assumes that GTK+ is using GTK-QT-Engine which is not part of Slackware (GTK-QT-Engine is used to give GTK appplications a Qt feel when they are running in KDE) and it will not correctly apply the QGtkStyle engine. It sets QGtkStyle to use the GTK style Clearlooks, and outputs an error message which you will sometimes be able to see if you started a Qt-based application from a terminal:

QGtkStyle cannot be used together with the GTK_Qt engine.

This can be solved by explicitly telling Qt4 where Slackware keeps its GTK+ configuration files, and then making sure a GTK+ theme is configured there.

• Define the environment variable “GTK2_RC_FILES” in one of these files: ${HOME}/.xinitrc (applies to just you) or in /etc/profile.d/qt4.sh (applies system-wide) by adding the follwing two lines to that file (assuming you are using bash as your default shell):

  GTK2_RC_FILES="$HOME/.gtkrc-2.0:/etc/gtk-2.0/gtkrc"

  export GTK2_RC_FILES

• Create a new file (or edit the existing) ${HOME}/.gtkrc-2.0 (so that the GTK theme applies to just you) or /etc/gtk-2.0/gtkrc (so that it applies system-wide) and add the following line to it:

  gtk-theme-name="GTK+"

That should fix VLC’s “Media > File Open” dialog which will now appear instantly.

Note: You can choose a GTK+ theme for all your QT4 based applications if you want by running “qtconfig” and in the tab “Appearance” set the “Select GUI Style” to “GTK+” instead of “Desktop Settings (default)“.

Eric

There is a pending KDE 4.5.0 release, which needs to be built for slackware-current. Then there is also VLC 1.1.2 which was released a few days ago… and those packages need to be built for Slackware 13.1 (so that they can join my main repository). I have only one “build box” which is fairly old and sporting a CPU without hardware virtualization capabilities.

Decisions, decisions… there’s only 24 hours in a day.

So I decided to start with building a test set of KDE 4.5.0 (the sources of which I already have) because that will be a big event for a lot of people, and leave the new VLC for another time. Don’t worry! Linux users will find that the 1.1.2 release of VLC does not offer anything worthwhile, except perhaps for some bugfixes in the DVB (digital video) module. The VLC 1.1.1 packages which I have created for Slackware are still very much OK.

Having to build packages for Slackware 13.1 as well as -current, and for two architectures (32-bit and 64-bit) is proving a bit too much for that old computer (which happens to be my home desktop as well), so I decided to use the donation money that has been accumulating and order an Athlon II X4 640 boxed CPU, along with an Asus M4N68T motherboard and 8 GB of RAM, completed with a 2 TB SATA hard drive. Once all that arrives on my doorstep, I will assemble a full computer using the case I have here (with a motherboard that caught fire last month because of a crappy condensator). That machine will become my new server.

Thanks to all of you who took the trouble to click my PayPal button – you know who you are, even if I did not thank you in person. Your gracious gifts will be spent with the purpose of making Slackware an even better experience.

By the way – I intend to use qemu-kvm to run a load of virtual machines on that computer, so that it will be easier to build in parallel. I have been considering VMware, VirtualBox and Xen as well. I decided against VMware for being closed-source. VirtualBox could still find its way onto the computer at some later stage; I decided against it because of the mixed license model where you get additional functionality only in the closed-source version. And Xen, well I am quite interested in how that works and performs, but unfortunately it requires a patched “xenified” kernel for the host and Linux guest. That was one bridge too far for me.

Nevertheless, there was a recent post from Chris Abela on the slackbuilds.org mailing list about the “The Xenification of Slack” which will most certainly help Slackware users get jumpstarted into the Xen world. Worth checking out, there is a tarball attached to that post with scripts and configuration files. Well done.

Enough of this, time for a beer.

Cheers, Eric

Just a quick message before I hit the bed,

I uploaded some Slackware packages for your consumption.

• vlc – the new stable release 1.1.1 became available for download today and my packages are now ready to be grabbed at http://slackware.org.uk/people/alien/restricted_slackbuilds/vlc/ (this UK mirror hosts the packages with export restrictions – they contain mp3 and aac audio encoders) or http://slackware.com/~alien/slackbuilds/vlc/ . Several bugs got fixed and features added. See the VLC ChangeLog for details.
• wiipresent – this package needed a rebuild (actually the supporting libwiimote needed a rebuild) because of the updated BlueZ stack in Slackware 13.1.
  I use the wiipresent software for presentations (duh)… It allows me to use my son’s Wii controller (the wiimote) as a pointing/navigation device so that I can walk the stage comfortably.
• wine – this was recently released in a stable 1.2 version, after lots and lots of release candidates. Please note that my wine packages will only run 32-bit Windows binaries. Even the package I created for Slackware64 ! If someone convinces me that it is worth the effort to add support for 64-bit Windows to my wine package, I will add that, but not before. Also note that wine on Slackware64 requires multilib. You could build wine on a pure 64-bit Slackware but then it would only run 64-bit Windows binaries. That is not what I chose to offer you.

I hope you enjoy these updates!

Eric