One of the outstanding features of openSUSE is the Sat solver for package dependency resolution.

Somewhat unknown to most developers, Satsolver provides bindings for the three major scripting languages: Perl, Python and Ruby. The bindings provide an easy way to learn about the Satsolver API, to explore package metadata and play what-if scenarios installing, updating and deleting packages.

The bindings are created using SWIG together with an application layer on top of the raw libsatsolver. The focus is on usability and support of the scripting language, while hiding internals of the Satsolver implementation.

The bindings documentation are hosted at http://www.suse.de/~kkaempf/satsolver-bindings-ruby for now. I hope to find a permanent place at opensuse.org in the future.

The documentation is created using rdoc with a SWIG specific parser. rdoc comes with Ruby, just install the ruby package for the rdoc framework. The swig parser is currently hosted inside the Satsolver git repo.

Although based on a Ruby specific tool, the use of SWIG ensures portability across languages. Example uses of the bindings are available for Perl, Python and Ruby If you need Satsolver bindings for other languages, drop the ZYpp developers a mail.

Today i've listen for the first time the new Chris Cornell album called Scream. Right after listening to a few songs i put my hands on the top of my head and said "WTF is this !?". I didn't like the album but the man still has his voice. He was one of the best Rock/Metal voices ever.

Chris i'm sure your fans miss your Soundgarden, Audioslave and Temple of the Dog past. His first two solo albums were ok but still different from the past. I loved his screams on songs like: Beyond the Wheel, My Wave, Hands all over, Jesus Christ Pose, Nothing to say, Cochise, Show me how to live, Mission,  Can't Change Me, Say Hello to Heaven and Hunger Strike.

Why this change ? Because you're feeling old ? Because you're in love ? Because you want to try reaching to new markets ?

Most of the flash devices assume that fat is the only file-system. And there are plenty of electronic devices that run linux on fat. So just to know what it is to run linux on vfat, I tried it myself.

The openSUSE 11.1 installer wont allow you to partition the root as vfat. So I made 2 partitions, one ext3 and one vfat. Installed on ext3. Copied the whole partition to fat. I copied original files in place of symbolic links. Added vfat filesystem module to initrd . Modified grub boot from the fat partition with init=/bin/bash.

FAT's lack of support for posix file-permissions. was easy to overcome by mounting with all permissions to everyone, without users or noexec. It doesn't support symlinks, and special files. mknod will fail. But /dev is a tmpfs and it just copies the persistent files from /dev to the tmpfs on boot, instead of copying I created fresh device files in tmpfs. `mount` failed trying lock the file /etc/mtab. Mounting with -n worked. I guess plenty of things would fail if I try to run a proper desktop on FAT as it is.

I booted only to /bin/bash. When I tried doing a "exec init 1", it complained something like cannot remove /var/run/do_confirm. I didn't proceed further. This was a fun way to kill time while getting some insight of the booting process.

Here is the last part of my mini-series about D-Bus, this time on D-Bus activation

In my last blog entry I talked about implementing a D-Bus service in Ruby. Running the service was done as a background daemon, started by root (or with other credentials).

D-Bus also provides an on-demand service creation, named activation. Here the D-Bus daemon creates the service as soon as a client is requesting it. Shutdown of the service is at the discretion of the implementation, the D-Bus deamon does not automatically deactivate a running service.

About D-Bus activation

For D-Bus actication, you have to create a .service file. This is an INI-style format file containing

• the name of the service
• the file to run, implementing the service
• the user name to run the service as

Since the D-Bus daemon runs as user 'messagebus' and thus is unprivileged. It cannot directly run the service or assume the correct user credentials.

Instead, it uses a service helper which is setuid root to start the service. This helper is configured within /etc/dbus-1/system.conf as <servicehelper> and typically resides below /lib/dbus-1/dbus-daemon-launch-helper (/lib64/dbus-1/dbus-daemon-launch-helper on 64bit systems).

dbus-daemon-launch-helper is extra-picky when it comes to security and checks its own configuration at startup. If your D-Bus service fails to get activated, maybe dbus-daemon-launch-helper is not correctly installed.

Writing the .service file

The name of the service file must be equal to the service name with a .service extension.

A typical service file for my.awesome.Service would be named my.awesome.Service.service and contain

# DBus service activation config
[D-BUS Service]
Name=my.awesome.Service
Exec=/usr/bin/awesome
User=the_dude

Name is the name of the service, Exec the path to the executable implementing the service and User the user name to run the service. Be careful when using User=root, only very few services actually need root rights.

The Exec line can also contain arguments to be passed to the executable. This can be used to e.g. implement multiple services in a single binary and pass the actual service name as a parameter.

Installing the .service file

Just copy the service file to either /usr/share/dbus-1/system-services (for a system bus service) or to /usr/share/dbus-1/services (for a session bus service).

Your service is now ready to run. The D-Bus daemon will automatically pick up changes in the service directories and find the new file.

Hi all!

Well ,  beginning from this week i will start to work on one small project  (one week).

Probably it would be a YaST or QT application,  so if you had a really good idea,  give me simple  feedback.

With 35 I am usually not going out that often to late night venues, but last night we went to Club Koma, a local gothic club/disco for a medieval music age event. (Met und Miezen - Met and chicks ;) Strange people, but fun and dancing happened. (And the taxi drive was around 13 euros back to my flat, twice as much as the entrance fee)

I also bought some new / old cameras from ebay, a Kodak DC 240, Kodak DC 210, HP Photosmart C200 and (from the NORMA supermarket around the corner) a Disney Micropix. All below 20 Euro, and I even had to fix the DC240 driver to make it work.

Nothing much interesting to speak about at work, except I am writing an OVAL description emitter for our updates. Long planned, still not done.

Today I tried a new way to do a live upgrade with one of my machines from 11.0 to 11.1. In the end, it takes nearly 1 day, because I had to download nearly 3,2 GB software (puh!) – but for me it was just a 3 minute work

It turns out that the most problematic part was the new RPM-“Distribution” string for openSUSE since 11.1. As openSUSE is now completely build in the openSUSE Build Service, the Distribution string of each package switched from “SUSE LINUX Products GmbH” to “openSUSE 11.1” – and zypper complains about this vendor switch during a live upgrade.

My Solution: Just create a new file “/etc/zypp/vendors.d/openSUSE” as root and insert the following content:

[main]
vendors=openSUSE,SUSE LINUX Products GmbH

Now, zypper identifies packages from Vendor “openSUSE” as the same as packages from vendor “SUSE LINUX…”
Whats left is the adaption of the repositories (they should point to 11.1 now):

localhost:~ # cd /etc/zypp/repos.d/
localhost:~ # sed -i “s|11.0|11.1|g” *

…and right afterwards, the show can go on…

localhost:~ # zypper ref

Retrieving repository ‘OBS-Edu’ metadata [done]
Retrieving repository ‘Packman Repository’ metadata [done]
…

localhost:~ # zypper dup

Loading repository data…
Reading installed packages…
Computing distribution upgrade…

The following packages are going to be upgraded:
…

Press “y” and Enter – and go to bed or something else – next day, reboot your machine and welcome your new 11.1!

We received some complains that the redesigned partitioner on openSUSE 11.1 is
tedious to use. To remedy these shortcomings I’m adding context menus to the
tables so that it is no longer required to select the correct view using the
navigation tree to perform some operation. Almost all operation should be
available via context menus in the main view listing all devices.

As usual comments are welcome.

This has been in my plans for a long time, but i had trouble learning how to do colored output in terminals correctly. I asked people, i googled, looked at terminfo, ncurses, but still could not find a satisfactory answer. So i started to look at other non-curses terminal apps, and i stopped already at the first one: git.

#include <unistd.h>
#include <stdlib.h>
#include <string.h>

bool has_colors()
{
  if (::isatty(STDOUT_FILENO))
  {
    char *term = ::getenv("TERM");
    if (term && ::strcmp(term, "dumb"))
      return true;
  }
  return false;
}

This (translated to a C/C++ hybrid) is all that git (and now also zypper :O) does to detect the color capability of the stdout. stout must be a terminal, and the TERM environment variable must not be "dumb". The idea is that most color-capable terminals understand the ISO 6429 (former ANSI) color control sequences, and if the above check fails for your terminal, you can configure git (and soon zypper :O) to never or always use colors (or set the TERM to "dumb").

Regarding terminfo, i found it hard to learn and an overkill for just printing colored text (of course, once learned it can be used in other ways, too, e.g. to move the cursor, turn off input echoing when writing passwords, etc.). Maybe some other time.

On the other hand, ncurses are nothing for an existing terminal application which already does lots of output the usual way - you would have to rewrite all the output handling using ncurses. With ncurses it is that you write your app either with or without it from the start. But you cannot switch to it later, nor mix it with standard C I/O (printf() or C++ streams (cout <<). At least that's my impression from what i've learned...

So, zypper is now (since 1.1.0) a bit less boring, with colors :O) The idea is to print normal messages and progress in darker color, highlight important messages like results, warnings, errors, and color some special stuff, e.g. in install summary, default options in prompts, and so on. And it should be configurable, so that anybody can adapt it to his or her terminal background and text color. I'll write more about that once it's done.