KDE SC 4.4.1 (first maintenance release for the 4.4 series ) has been made available and the Slackware packages can be found at http://alien.slackbook.org/ktown/4.4.1/

Again, I have made 32-bit as well as 64-bit packages. The “dependencies” have not changed since KDE SC 4.4.0, so there is nothing new or changed in the /deps/ directory. Read the README in the topdirectory for full installation/upgrade instructions, or look for my older http://alien.slackbook.org/blog/its-been-released-kde-sc-4-4-0/ post.

Note that you have to be running Slackware-current (not older than 02-march-2010) or lots of things will break!

Also note that this fixes some issues with  the previous KDE 4.4.0 packages – some of those had not been rebuilt on 02-march-2010 which resulted in a broken keyboard layout configurator and kopete’s Windows Live plugin.

So, the upgrade is warmly recommended if you are running my 4.4.0 packages right now!

Eric

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

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

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

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

Note for self-compiling folk:

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

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

Multilib gcc/glibc packages (64-bit)

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

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

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

Enjoy!

Eric

There are a few easy ways to get rid of the attacks and at the same time prevent your root account from being compromised.

1. move the SSH listen port from TCP port 22 to a non-standard port
2. disallow connections with the older and easily cracked “Protocol 1″
3. disallow remote root logins

These countermeasures are easily taken by editing the ssh daemon’s configuration file “/etc/ssh/sshd_config“. below, I will show you the lines to lookup and the changed line which needs to take its place:

• Move the ssh listen port from 22 to 12345. This will get rid of most break-in attempts right away because these only target the well-known port 22:

#Port 22
Port 12345

• Disallow the use of the old “Protocol 1″

#Protocol 2,1
Protocol 2

• Disallow the root user to logon directly

#PermitRootLogin yes
PermitRootLogin no

After these changes have been made, you will have to restart the SSH server:

# /etc/rc.d/rc.sshd restart

When you disable root logon through SSH, the only possibility to become root on this computer remotely is to logon as a normal user first, and then use “su” or “sudo” to become root.

This has negative implications if you are used to make remote backups from your server and connect to it as root… because that is the only way to be able to access and read every file in the filesystem.

When you need remote root access but still want to disable password logins for root, there is a further change you have to make to one of the lines I showed you earlier. What I will show you next is how to prevent password logins for root while still allowing entrance using a SSH key. You can protect this SSH key with a passphrase so that it is impossible for someone who steals this key to force his way in as root – he will have the SSH key in his possession, but will not know the passphrase to unlock it!

In order for this to work, the SSH server must allow Public Key Authentication for Protocol2. In Slackware this is the default anyway:

#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Now, let’s allow root to use a SSH key for loggin in. Change the following line in “/etc/ssh/sshd_config“:

PermitRootLogin no

to

PermitRootLogin without-password

and then restart the SSH daemon again (see above).

Finally, you will have to generate a SSH key that can be used for remote logins and copy the public keyfile to your SSH server.

ssh-keygen -t rsa

You will have to answer a few questions: under which name should the new keyfile be stored, and what passphrase should be used to protect the keyfile.

Once you have generated this keyfile, copy the public key (which is the keyfile but with the “.pub” extension) to your SSH server and on that server, as user root, append it to root’s “.ssh/authorized_keys” file like this (I am using an example public key filename “your_new_sshkey.pub”):

cat your_new_sshkey.pub >> /root/.ssh/authorized_keys

In case the “authorized_keys” file did not yet exist, you will have to secure other people’s access to the file or else remote logon will still not work:

chmod 600 /root/.ssh/authorized_keys
chmod 700 /root/.ssh

Once this has been done you should now be able to logon to your SSH server as root remotely:

ssh -p 12345 -i ${HOME}/.ssh/your_new_sshkey root@remoteserver

If you want ssh to use this SSH key automatically so that all you need to type is “ssh root@remoteserver“, you should add a few lines to your “~/.ssh/config” file. Perhaps that file does not yet exist in which case you can just create it. Mind the indents, they are required:

Host remoteserver
User root
Port 12345
IdentityFile /home/your_user/.ssh/your_new_sshkey

Good luck with this!

Eric

PS: if you copy your new public key to the server before you have made any of the changes I suggested, then some of the above steps can be combined into one. The following command on your workstation will copy the public key to the SSH server, and add it to root’s “authorized_keys” file, securing that file’s access attributes if needed, all in one go:

ssh-copy-id -i ${HOME}/.ssh/your_new_sshkey root@remoteserver

Eric

I am pretty comfortable working with other products like RCS, CVS and Subversion (SVN). I am not a developer, so my main use for a VCS is a to allow me to keep track of the changes in my SlackBuild scripts or my server’s log book. I use RCS for this, it is simple but effective.

Of course, in order to compile software it is often required to check out the source code for the program. This is how I got familiar with CVS, SVN, mercurial and git. Way back when I was “build manager” for a software company, I have used PVCS, Clearcase and Visual SourceSafe which are all commercial programs. So, I have been around.

Still, git still confused me after all that time as a end-user. Git uses some alien (to me) concepts which I did not grasp because I never took the trouble to dive into its documentation – I knew just enough to checkout source code from a git repository and did not need – did not want to – know more.

This changed recently. Because two of the projects I am involved with are preparing to use git as their Version Control System, I was forced to start learning how to approach the tool as a developer.

I quickly decided it was worth the while to run two parallel tracks: start reading documentation, and at the same time actually using git by setting up a server for hosting git repositories.

I found some places which host very good reading material.

• The Pro Git book at http://progit.org/ . This book is hosted itself in a git repository and the language translations are coordinated using git. Well-written with lots of visual examples.
• The Git Community Book at http://book.git-scm.com/ .

I’m halfway through the “Pro Git” book, retracing my steps a few times after the new concepts found a place in my brain. Indeed, git is starting to make sense now. Surely it has some very strong points which make it interesting not only for large projects with lots of developers who are scattered all over the place (like the Linux kernel developers) but also for small projects like those I am participating in.

Perhaps I will document more about my git activities in a future Wiki article – for instance how I am setting up an online git repository.

This made me think of something else: could it be beneficial to dump the history of my SlackBuild script repository (past and future) into a git repository? What do you think – will it help you if you are able to look at older revisions of my SlackBuild scripts? Some time ago I started copying the SlackBuild script into the documentation directory of every Slackware package I create, but I realize that once I release a newer package, the older scripts disappear from public view.

Leave your opinions in the comments section below please.

Eric

Let me re-assure you: there is a lot of behind-the-scenes work going on. Some of the updates require the recompilation and testing of other packages and this takes time to get it right.

When the time comes to push the next batch to the public, be sure that it contains a lot of goodies. Nope… no PAM in there

And equally no, this is not the runner-up to a new stable release. Due to the size of the changes, I expect that some serious user-testing is required first. Just be patient for a little longer…

Eric

Users of small form-factor laptops will be interested to learn that the new Plasma desktop manager now offers two workspace choices. One is the usual desktop-oriented workspace. The interesting addition is a netbook-oriented workspace, with special consideration for the netbook’s smaller screen and typical mobile usage patterns. I have not yet installed KDE 4.4 on my own Asus EEE netbook but I will most certainly do so, later this week!

In order to fully appreciate the work that went into KDE SC 4.4 and learn what has changed since KDE 4.3, you should definitely take the visual tour. Lots of new functionality and usability improvements are hidden beneath this new desktop workspace and just waiting to be discovered and used to the fullest.

Slackware packages galore!

Like I did with the pre-releases of KDE 4.4, I have prepared new goodies for all you Slackers. Get those 32-bit and 64-bit packages for Slackware Linux and install them on your computers (or build them yourself using the accompanying SlackBuild scripts, patches and sources).

You will find all of those at http://alien.slackbook.org/ktown/4.4.0/ .

Please take good notice of the fact that these packages are built for Slackware-current. You can safely install the KDE 4.4.0 packages if you are running a slackware-current from around 01 february 2010 or newer. Do not try to install these packages on Slackware 13.0.

Slackware 64-bit:

• 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.0 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“.

Slackware 32-bit:

• 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 “x86_64/kdei” since these packages are in fact architecture-independent.

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.0 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.4.0/x86_64/ :
   # lftp -c "open http://alien.slackbook.org/ktown/4.4.0/ ; 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.0 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…!

If you want to compile the packages from source like I did, that is entirely possible using the provided sources and build scripts. It will take quite a while though…

Have fun, Eric

Note for users of any KDE 4.4 pre-releases:

If you never before installed and used one of the Betas or Release Candidates of KDE 4.4 , then you can safely remove one package,  virtuosoconverter. This package is only needed if you were using “nepomuk desktop search” before this final release of KDE 4.4.0.

# removepkg virtuosoconverter

If you ran any Beta or Release Candidate of KDE 4.4.0 prior to upgrading to 4.4.0, then you will notice that your nepomuk database will automatically be converted from virtuoso v5 to v6, the very first time you login to your KDE 4.4 desktop. This process will take a while (not too long) and will temporarily double the size of your nepomuk database (by default, this database consumes a maximum of 50 MB in your homedirectory below ~/.kde).

If this database is not valuable to you, you can also decide to skip this database conversion by just deleting the database before starting KDE:

$ rm -r ~/.kde/share/apps/nepomuk/repository/*

or by following the instructions in Sebastian Trueg’s tutorial: http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/TipsAndTricks#Remove_all_Strigi-indexed_data

If you manually remove the old nepomuk data, you can also remove the virtuosoconverter package of course.

If you do not have any clue about what I am talking about and what you should do, just don’t do anything… and all will be well.

A final remark about nepomuk and strigi – I think that KDE 4.4 finally has a desktop search which is optimized to a level that it no longer eats all your CPU cycles or claim a large chunk of your harddrive. Now I just wish that the strigi developer properly fixes the indexing of my PDF files!

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

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

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