Klipper from KDE has a set of predefined actions triggered by content of the clipboard. So when you have it enabled, it show up the popup menu with all available browsers when you copy the URL. In my job I open many bugs and the bug numbers have the well defined format bnc#number. So why don’t define automatic action triggered by this regular expression?

Because Klipper expects only oneliner as an action, I wrote the short bash script obug.sh which expects one argument with a bugzilla string.

#!/bin/bash

[ -z "${1}" ] && {
  echo "bug number required"
  exit 1
}

regex='^(bnc|bug)?#[0-9]+$'
[[ "${1}" =~ ${regex} ]] || {
  echo "${1} did not match ${regex}"
  exit 2
}

firefox https://bugzilla.novell.com/show_bug.cgi?id=${1#*#}

It’s obvious how it works – it checks if the argument exists and if matches the pattern and then opens a firefox (it’d be a xdg-open, but I use firefox for Novell Bugzilla). There should be only one strange expression – ${1#*#}. It is a Shell Parameter Expansion. This expression removes all characters from the beginning of the string including first #, so it convert bnc#1234 to 1234.

Then I defined a new action in Klipper triggered by ^(bnc|bug)?#[0-9]+$, which calls obug.sh %s, where %s is the content of clipboard.

And after that all I selected the bnc#1234 by mouse and then the following popup appeared.

One disadvantage of this method is that Klipper opens popup window only near its status icon in systemtray. It would be more useful to show it near current mouse position.

After releasing WebYaST 1.0 last week we have had a look to the status module again and have come to the conclusion that we can do it better.

The current version looks more like a medical monitoring system that no one understand:

Technical background

The system data will be collected by a service called collectd (www.collectd.org). This data will be stored in a rrd-database which is located in

/var/lib/collectd/<system-name>/[cpu-0|cpu-1|df|interface|load|memory|….]

An own file/database will for each value will be generated.

The upper screen shot shows that an own graphic will be shown for each value. This is not really user friendly. We would like to show only values which provides “really” interesting information for the sysadmin or user. These values should also be grouped in order to reduce the amount of graphs.

Another lack of information is the labeling of the graphs. There is no description what the values mean and in which period they have been evaluated.

The aim

would be to give the user a nice overview about the system status. Additional, there should be an alarm system available if system values are exceeded. E.g. there should be sent an email to the system administrator if no disk space is available anymore.
The Administrator should also be able to configure “his” needed system values in a nice way.

Suggestion for configuration

There are three parts:

• General
  General setting like period time of shown data, email address in the case of occurred errors and the color of displayed limits.
• Graphics
  Defining graphs with
  • labels
  • scales
  • flag for cumulate values
    This means that the values in the graph are added. E.g. the component df of collectd returns two values of a partition (free, used). These values will be cumulated in the graph like this:
    
• Enable Values/Limits
  • Defining which data of collectd will be shown in the graphics described above. This enable us to group data in one graph, defining color and label of each collectd value:
    
  • Defining limits and send an email if the value is overstepped longer than the defined period (Alarm after (min.))

The Result

should be an amount of view graphs which include interesting data only. These values are checked periodically and an email will be sent if they exceed a defined limit.

I am asking for

your opinion about:

• Do you know a much more fancy way for displaying system status data ?
• Which kind of Data would be interesting for you (CPU, memory, disk-space,….)?
• When and for which kind of data would you like to get an email if limits have been exceeded?

So, before changing this module we would like to ask you what you would like to see.

Thanks in advance.

... or "Waiting for device /dev/disk/by-ID/... to appear." problem

A guess many people have figured this out by now, but i still know a lot who have not, so here it goes.

There are a few caveats in cloning openSUSE or SLE VirtualBox machines. One is that openSUSE uses device ID in /etc/fstab and grub's menu.lst to reference your hard disk partitions. This is cool for physical machines, since no matter what the usual device name of your hard disk is (/dev/sda, sdb, hda, ...), the device ID always stays the same. When cloning the VirtualBox hard disk image, however, the device ID changes. This consequently causes a problem when booting your new machine with cloned image.

Another one concerns the network card's udev rules, which affect the device names. These are set to use MAC address to identify the card, which also changes when creating new virtual machine (new random MAC address is generated). After booting the cloned machine with this new network card, the original one becomes eth1, and the new one is not configured; you need to configure it, e.g. using YaST. Thanx to Mišo Žugec for this tip.

To avoid these problems, after installing a fresh openSUSE or SLE which i want to use for cloning, i change its /etc/fstab and /boot/grub/menu.lst to use the usual device files, and change the network card's udev rules from MAC to BusID. So, in nutshell, the cloning process looks like this:

1. Boot the virtual machine you want to use as base for cloning.
2. Replace the /dev/disk/by-id/...-partY with /dev/sdXY in /etc/fstab and /boot/grub/menu.lst.
3. In YaST Network module, click Edit to edit the network card, open the Hardware tab, click Change in the Udev rules frame and select BusID instead of MAC address.
   
4. Shut the machine down (from within the machine itself, not using VirtualBox's power off).
5. Find the machine's .vdi hard disk file (usually under ~/.VirtualBox/ dir) and use VBoxManage clonevdi command to clone it, for example:
   (~/.VirtualBox/HardDisks)$ VBoxManage clonevdi my-perfect-oS11.2-base.vdi oS11.2-some-experiment.vdi
6. Create new machine in VirtualBox GUI and attach the cloned disk image to it when asked. You can also copy an existing machine's .xml configuration file and change the hard disk UUID, or create a script that will do this for you.

You're ready to boot your clone now. Of course, if you cloned a machine still using the device ID for hard disk, you should still be able to boot it, if you pass the right root=/dev/sdXY and resume=/dev/sdXY parameters to grub. You can also reconfigure the network devices after booting. But preparing the base is more convenient, if you need to clone it often.

For more info see:
http://srackham.wordpress.com/cloning-and-copying-virtualbox-virtual-machines/
http://forgeftp.novell.com/lfl/.html/virtualbox.html

A couple of days ago, Google release a Beta version of Google Chrome for Mac and Linux. After installing the RPM I has been notice that the flash player doesn’t work. For make it work do the following as root:

cd /opt/google/chrome

ln -s /usr/lib/browser-plugins/ plugins

Restart Chrome and you are ready to watch some videos on youtube

The openSUSE team in Nürnberg invites everybody interested in Linux and in particular in openSUSE to join our Christmas party on Wednesday December 16 in the basement of our office building in Nürnberg. We’ll give some presentation about openSUSE 11.2 in action, GIMP and how to participate at our project. Beside of the presentations we have some machines where especially openSUSE  Education and the openSUSE Build Service will be shown but openSUSE 11.2  is available too, of course. More information
We hope to reach out to many local people in the Nürnberg area.

You might want to install multiple kernel versions on your system.
The YaST Qt Package Selector provides a nice user interface that allows to manage multiple package versions now.

yast2-qt-pkg 2.18.19 or later supports this feature. You can find packages in my Build Service repository.

First of all you need to tell libzypp that your kernel is a package which is multiversion-enabled by adding this line to your /etc/zypp/zypp.conf:

multiversion = provides:multiversion(kernel)

Start your YaST Software Management. The versions tab shows check boxes for multiversion packages instead of radio buttons.
This enables you to install multiple versions of the same package.

There is also a package group of multiversion packages that list all packages that can be installed in multiple versions.

ATI graphics and Linux on some computers is real problem. I tried fglrx driver , but it doesn't compile in openSUSE 11.2 .

The most recent development is that even radeon driver is no more good for Radeon Xpress 200 built in my laptop. Not that it doesn't work at all, but you have to use strange methods to boot the laptop to the GUI. To be honest, not strange to me, I used startx very often long time ago, but I can imagine what would happen if openSUSE was just installed to try it out. It would be removed from the box faster then it was installed. With so many options out there it would take time to see that visitor coming back.

Just a quick note: I have just moved QJson source code to this git repository hosted by gitorious.

I’ll keep the code on KDE’s svn synchronized with the git repository.

Some days ago I introduced the possibility to serialize a QObject instance to JSON. Today I’m going to show you the opposite operation: initializing a QObject using a JSON object.

I refactored a bit my latest changes: I created a new class called QObjectHelper that provides the methods required to convert a QObject instance to a QVariantMap and vice-versa.

This class can be used in conjunction with the Serializer and Parser classes to serialize and deserialize QObject instances to and from JSON.

Let me show a quick example, suppose the declaration of Person class looks like this:

{% codeblock [class definition] [lang:cpp ] %} class Person : public QObject { Q_OBJECT Q_PROPERTY(QString name READ name WRITE setName) Q_PROPERTY(int phoneNumber READ phoneNumber WRITE setPhoneNumber) Q_PROPERTY(Gender gender READ gender WRITE setGender) Q_PROPERTY(QDate dob READ dob WRITE setDob) Q_ENUMS(Gender)

public: Person(QObject* parent = 0); ~Person(); QString name() const; void setName(const QString& name); int phoneNumber() const; void setPhoneNumber(const int phoneNumber); enum Gender {Male, Female}; void setGender(Gender gender); Gender gender() const; QDate dob() const; void setDob(const QDate& dob); private: QString m_name; int m_phoneNumber; Gender m_gender; QDate m_dob; }; {% endcodeblock %}

From QObject to JSON

The following code will serialize an instance of Person to JSON :

{% codeblock [From QObject to JSON] [lang:cpp ] %} Person person; person.setName(“Flavio”); person.setPhoneNumber(123456); person.setGender(Person::Male); person.setDob(QDate(1982, 7, 12)); QVariantMap variant = QObjectHelper::qobject2qvariant(&person;); Serializer serializer; qDebug() << serializer.serialize( variant); {% endcodeblock %}

The generated output will be:

{% codeblock [JSON data] [lang:json ] %} { “dob” : “1982-07-12”, “gender” : 0, “name” : “Flavio”, “phoneNumber” : 123456 } {% endcodeblock %}

From JSON to QObject

Suppose you have the following JSON data stored into a QString:

{% codeblock [JSON data] [lang:json ] %} { “dob” : “1982-07-12”, “gender” : 0, “name” : “Flavio”, “phoneNumber” : 123456 } {% endcodeblock %}

The following code will initialize an already allocated instance of Person using the JSON values:

{% codeblock [From JSON to QObject] [lang:cpp ] %} Parser parser; QVariant variant = parser.parse(json);
Person person; QObjectHelper::qvariant2qobject(variant.toMap(), &person;); {% endcodeblock %}

A new release

These changes have been included inside the new release of QJson: 0.7.0.

Packages for openSUSE are building right now.

This week kolab became one small step closer to realize feature request 307846: include Kolab in openSUSE. Although it will take lots and lots of more work to achieve this goal at all. The one step closer was realized in cooperation with the openSUSE cyrus-imapd maintainer R. The openSUSE cyrus-imapd spec file in the repository server:mail spec file has been extended with information about kolab, but the actual execution of the information has been switched off. With the Build Service link functionality the package server:mail/cyrus-imapd has been linked to the package server:kolab:UNSTABLE/cyrus-imapd-kolab, where the kolab functionality gets built. This is achieved by activating the variable with_kolab in the project related configuration file:
# osc meta prjconf server:Kolab:UNSTABLE
%define with_kolab 1
Macros:
%with_kolab 1

See the Build_Service prjconf page in the openSUSE wiki for more information about this awesome functionality. This way the cyrus-imapd-kolab package inherits everything from the openSUSE base cyrus-imapd package.

One drawback for kolab administrators, you have to manually correct the currently installed kolab packages. Start with downgrading cyrus-imapd-kolab (it only downgrades the Build service version and not cyrus-imapd itself):
# zyp in cyrus-imapd-kolab
This will install the dependent package perl-Cyrus-IMAP-kolab instead of perl-Cyrus-IMAP and perl-Cyrus-SIEVE-managesieve-kolab instead of perl-Cyrus-SIEVE-managesieve and it might remove kolab and perl-kolab.

Now reinstall kolab with:
# zyp in kolab
that should be sufficient to be in sync with the repository again. Don’t forget to restart the services, with:
# rckolab restart

This week also showed the power of the build service, as I could install kolab within only some minutes after installing openSUSE-11.2 in Virtualbox, while I never installed openSUSE-11.2 before.

The kolab installation in openSUS-11.2 made some problems visible in kolabconf -n. The latter has been fixed, it was a general problem in kolabconf and did not have anything to do with openSUSE-11.2.

The kolabconf problem however required some debugging, with a resulted spin off that the spamassassin daemon spamd is no longer activated via the startup scripts, but as a library of amavisd instead. That is the way amavisd and spamd have been configured in kolab, but what was not honored in the kolab setup on openSUSE.

Due to the change in the amavisd and spamd deamons, the script kolabsrv has been extended, and can now show a list with services required by kolab and what their current status is (see screenshot):

The main task of kolabsrv is to convert the openpkg service names to the distribution dependent names.

The kolab project is heading towards a new release 2.2.3 with a planned release date in December 2009.

Sascha released a nice Brain Dump of the Week, giving a nice insight in the possible future of Kolab.

In one of the replies of Sasha’s brain dump, a references was made to project-builder, a project similar to the openSUSE build service. Although the OBS and project-builder may be similar, some people are wondering what the differences (1) and (2) are.

That’s quite a lot of information, but lots of things happened since my last blog entry about Kolab.

PS: many thanks that M. from Novell, who made my Lizards blog account working again. For the most part of this week, I’ve not been able to login to my blog account. After logging in with the correct credentials, I was referred back to the Lizards entry page. M. knows the details, so if this happens to you contact M. from Novell