View posts for Tag: "Linux"

Upgrading Debian Etch to Lenny

On last Saturday Debian 5.0 “Lenny” has been released as stable. This probably means a lot of updating work for many administrators. I was updating a couple of servers during the last days. Due to Debian’s APT system it’s a pretty easy process.

Step 1: Edit your /etc/apt/sources.list. Replace every occurrence of “etch” (I assume you’re updating from Debian “Etch”) with “lenny”. Your sources.list should now be looking roughly like that:

deb stable main
deb-src stable main

deb stable/updates main contrib
deb-src stable/updates main contrib

Step 2: Simply run apt-get updateand you should probably get something like this:

srv:~# apt-get update
Get:1 stable Release.gpg [386B]
Hit stable Release                                    
Get:2 stable/updates Release.gpg [189B]
Hit stable/updates Release
Hit stable/updates/main Sources
Hit stable/updates/contrib Sources
Fetched 2B in 0s (15B/s)
Reading package lists... Done
W: There is no public key available for the following key IDs:
W: You may want to run apt-get update to correct these problems

Apparently, this means you need to get the public key for 4D270D06F42584E6. 😉 This can easily be done with the following commands.

srv:~# gpg --keyserver --recv-keys 4D270D06F42584E6
gpg: directory `/root/.gnupg' created
gpg: can't open `/gnupg/options.skel': No such file or directory
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: requesting key F42584E6 from hkp server
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key F42584E6: public key "Lenny Stable Release Key <>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
srv:~# apt-key add /root/.gnupg/pubring.gpg

Please note that the key ID and though the public key needed on your system can differ from this one.

Step 3 Finally, you can rerun the package-list update and run the actual upgrade.

srv:~# apt-get update
srv:~# apt-get dist-upgrade

Depending on your machine’s capacity and your internet connection speed the upgrade can take from about 15 minutes to some hours. The avarege time my updates took was 30 minutes. After that you can reboot your freshly upgraded system with the new kernel and you’re done.

1 Comment

After three months of KDE 4

I’m quite happy with the new KDE release. It’s well structured, the applications are redisigned and simplified and the unsability has done a big step up the ladder.
BUT I still miss some basic functions from the old 3.5 version, some applications crash unexpectedly and the probably most annoying thing for me: the lack real desktop icons. The “Folder View” desklet which is intended to replace teh classical desktop icons is not a really good replacement. I’m looking forward to the next major release of KDE, namely 4.2, which is announced for January 2009. I will bring a lot of new and old features back to KDE. Most notably it will bring back the good old desktop icons!

Sorry, comments are closed for this post.

Qt4.4 for beginners

Quite some time ago I have worked with Qt3 and C++ to do some Linux projects. I had taken a look on GTK and wxWidgets too, but I felt most comfortable with Qt.

Now I had to build small program that was able to play a list of audio files and to give the user an option to rate these files. It’s a quite simple little program which for some reasons is needed to be written in C++.

So I installed Qt4.4 and started Qt’s Designer. I spent half an hour searching the source code editor in Designer. After five minutes with Google I found out that one “feature” of Qt4 was the complete separation of GUI code and logic code, so I had to work a slightly different way from what I was familiar with. Though I never used Qt’s Designer that way (usually I coded the whole GUI stuff by hand or used Designer’s built-in source code editor), I started “designing” my GUI. After I was finished I saved the file as “MainWindow.ui” (I know it’s not a smart name but I don’t care). So, what now? There were no other files and the Designer wasn’t able to produce any other files. The answer: qmake! qmake is some kind of Qt’s own make, which is not intended to replace make, but to give you a smart ability to handle *.ui and other Qt related files. One just needs to create a file named and add something like the following code to it:

HEADERS += MainWindow.h #as my ui file is MainWindow.ui
FORMS += MainWindow.ui # my ui file created by Qt Designer
SOURCES  += main.cpp MainWindow.cpp

This should be enough for a valid and working .pro file. Now there are three new file mentioned in the .pro file which are not existing yet. So where do we get these files from? We just create them ourselves. Let’s start with the main.cpp. It’s intended to be – guess what… So, what does it look like:

#include "MainWindow.h" // to integrate my MainWindow class from created by the Designer.
int main(int argc, char *argv[])
  QApplication app(argc, argv);
  MainWindow *window = new MainWindow;  //create an instance of our window
  window->show();                       // show our window
  return app.exec();

Curious about what the MainWindow.h file is needed and used for?

#include "ui_MainWindow.h"
class MainWindow : public QMainWindow, private Ui::MainWindow
  MainWindow(QWidget *parent = 0);

First of all one has to understand where the “ui_mainWindow.h” comes from. It’s automatically generated by qmake when you call it. qmake simply generates C++ code out of the XML-ui file. Your can call qmake right now it should generate an “ui_MainWindow.h” file and a Makefile which will be called later. Another alternative to generating “ui_MainWindow.h” is to call the command

uic -o ui_MainWindow.h MainWindow.ui

qmake itself calls uic to get the “ui_MainWindow.h”. Now if you take a look at the “ui_MainWindow.h” you’ll see that it contains pure C++ code calling the different Qt classes to draw the GUI. With “class MainWindow : public QMainWindow, private Ui::MainWindow” in MainWindow.h we inherit the Ui::MainWindow class produced by uic and are able to define our methods, attributes an so on… Now it’s time to create our MainWindow.cpp. This file is also pretty simple but important.

#include "MainWindow.h"
MainWindow::MainWindow(QWidget *parent) {

By calling setupUi in the constructor, the GUI elements, which were added to the interface with the Designer, are painted the first time. You can comment the setupUi line out and see what’s happening. After all of these steps we’re finally finished… or let’s say nearly finished. If you have followed all these steps carefully you should call


to process the Makefile previously created by qmake. Note: If you use Qt/Aqua on MacOS X, the qmake will produce a something.xcodeproj file/directory instead of a Makefile. To build your you’ll need to call xcodebuild instead of make.

If you get some errors while building your app, you’re on your own. I’m done for now ;-). If you need more information on Qt then take a look at . But you’re also free to comment or ask to me ;-).

1 Comment