Cave mouse
It was supposed to be a 10 km walk... well, some people can read maps, others can't..
It was more than obvious were we had to go..but they just don't listen to me.
At least I got some beer and Obazder after the hell of a walk.
And now there's this frog who accompanied them to the pub. The guy who brought the beer wanted to throw him away. But somehow in the very last second he figured out that this paper thingy was a frog.. they say he can jump.. the truth is he always lands with his feet sticking out and someone has to rescue him..what a nuisance..
Remember to commit
I have to admit that lately I have a really bad habit: I forget to commit my
changes to Strigi. In this way I end-up performing multiple commits with
different changes inside: from stupid to interesting one. This is a really
bad behavior, so today I decided to perform some svn status and svn diff
and I made some commits on Strigi trunk. Most of all are just code readability
improvement == don’t exceed the 80 chars per line.
I think that Jos will be really happy to see them ;)
Ton für OSS-Programme
Auf meine OpenSUSE 10.2 Systeme hatte ich zunächst in Anwendungen wie X2, welche beim Ton noch auf OSS setzen, keinen Ton. Zum Glück lies sich das Problem am Ende durch ein einfaches Löschen der Konfiguration von KDesktop lösen. Statt Ton bekam ich bei allen Anwendungen die OSS verwenden eine Fehlermeldung, obwohl der Ton bei anderen Anwendungen ging.
/dev/dsp: Das Gerät oder die Ressource ist belegt
Jegliche suche nach eventuell noch laufenden Programmen welche die Tonausgabe blockieren könnten brachte zunächst keinen Erfolg. Amarok, Arts etc. waren alle gegen Alsa konfiguriert. Es war auch ohne Probleme möglich mehrere Anwendungen gleichzeitig Ton ausgeben zu lassen. Auch waren die Treiber für die OSS-Emulation unter Alsa geladen.
marix@eddie:~> lsmod | grep oss
snd_pcm_oss 71680 0
snd_mixer_oss 35840 1 snd_pcm_oss
snd_pcm 115464 4 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd 89384 14 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer
Einen entscheidenden Hinweis lieferte ein mutiges Durchstarten von Alsa.
sudo /usr/sbin/rcalsasound restart
Danach hatte ich zwar Ton in X2, allerdings war mein Desktop auf einmal schwarz. Ein Neustarten von KDesktop bestätigte meinen Verdacht. Anschließend war die Tonausgabe wieder blockiert. Beim Neustarten von Alsa beendete KDestkop kommentarlos. Offensichtlich war es für die blockade der Tonausgabe, was sich auch leicht prüfen lies.
marix@eddie:~> lsof /dev/dsp* /dev/snd/**
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
kdesktop 19572 marix mem CHR 116,4 255811 /dev/snd/pcmC0D0p
kdesktop 19572 marix 11r CHR 116,2 255551 /dev/snd/timer
kdesktop 19572 marix 12u CHR 116,4 255811 /dev/snd/pcmC0D0p
kdesktop 19572 marix 13u CHR 116,6 255819 /dev/snd/controlC0
Blieb die Frage, wie man das Problem löst. Ein kurze Suche mit meiner Leiblingssuchmaschine (nicht die mit den zwei O, dafür bin ich schon zu lange im Netz) lieferte mir dann den entscheidenden Hinweis. Auf http://www.linux-club.de/ftopic60033.html ist zu lesen, dass diese Problem wohl durch die Konfiguration von KDesktop verursacht ist. Löschen der Konfiguration löst das Problem.
mv ~/.kde/share/config/kdesktoprc ~/.kde/share/config/kdesktoprc.bak
Leider habe ich nicht herausgefunden welcher Teil der Konfiguration das Problem verursacht, da diese eigentlich keine Informationen zur Tonausgabe enthält. Allerdings hat ein Löschen auch nur zur Folge, dass man den Bildschirmhintergrund und den Bildschirmschoner neu setzen muss, der Aufwand hält sich also in Grenzen.
Das beste daran ist, dass jetzt auch Descent 3 wieder richtig funktioniert. Das hatte sich bis jetzt nämlich immer kommentarlos gleich wieder beendet.
Kleines Update: Nach diesen Änderungen ist es jetzt auch möglich OSS-Programme mit aoss zu verwenden. Dies hat den Vorteil, dass man den Amarok im Hintergrund weiterlaufen kann und somit Musik und Anwendungston hat.
Arts Startprobleme schnell gelöst
Seitdem ich mein KDE mithilfe der Quelle http://software.opensuse.org/KDE:/KDE3/opensuse_10.2/ aus dem SuSE-Build-Service auf 3.5.7 aktualisiert habe stürzte Arts immer beim Start ab. Ein Start des artsd in der Konsole erzeugte anschließend diese Ausgabe.
marix@eddie:/opt/kde3/lib64> artsd
unix_connect: can't connect to server (unix:/tmp/ksocket-marix/eddie.site-5e24-468ca6d0)
loading extension from '/opt/kde3/lib64/libartsmidi.so' failed: /opt/kde3/lib64/libartsmidi.so: cannot open shared object file: No such file or directory
MCOP ObjectManager: Could not load extension libartsmidi.la.
MCOP ObjectManager: can't find implementation for Arts::MidiManager.
loading extension from '/opt/kde3/lib64/libartsbuilder.so' failed: /opt/kde3/lib64/libartsbuilder.so: cannot open shared object file: No such file or directory
MCOP ObjectManager: Could not load extension libartsbuilder.la.
MCOP ObjectManager: can't find implementation for Arts::ArtsBuilderLoader.
Speicherzugriffsfehler
Das ist dann auch schon der entscheidende Hinweis zur Lösung des Problems. Anscheinend wurden bei der Erstellung der Pakete ein paar Links vergessen. Ein hinzufügen der Links löst das Problem.
sudo ln -s libartsmidi.so.0 libartsmidi.so
sudo ln -s libartsbuilder.so.0 libartsbuilder.so
sudo ln -s libartsakode.so.0 libartsakode.so
sudo ln -s libarts_akode.so.0 libarts_akode.so
Work, work, work and... new house!
In my last message I promised to write some more contents on this site, in order to keep it more updated. As usual I disappointed this promise :) So, what I have been doing in these day? Just a simple answer: I’ve worked a lot. “Work” can be divided in the following categories:
- office work
- KDE & Strigi coding
- Physical work
The most important of all is the last one. I’ve spent all my week-ends working in my new house. I’ve been fixing and improving it (wow… it seems I’m talking about a piece of software ;) ) and now it’s quite finished.
I’ve to say a great “thank you” to my dad. He’s able to do everything (he’s something better than Mac Gyver) and helped me a lot (in fact he has done all the dirty jobs).
Prepare yourself, I’ll put some photos of the house really soon…
openwsman-yast now returns proper datatypes
require 'rwsman'
require 'yast'
client = WsMan::Client.new( 'http', 'client.internet.org', 8889, '/wsman', 'user', 'password')
options = WsMan::ClientOption.new
schema = YaST::SCHEMA
uri = schema + "/YCP"
options.property_add( "ycp", "{ return SCR::Read( .proc.modules ); }" )
result = client.invoke( uri, "eval", options )
modhash = YaST.decode_result( result ) # hash of { modulename => { size=>1234, used=>3 } }
Supported are void, bool, integer, float, string, symbol, path, term, list, and map -- should be sufficient for most of YaST. The YaST class is here.
You need at least version 1.1.0 of openwsman and openwsman-yast, both available on the openSUSE build service.
And, btw, source code for openwsman-yast is now hosted on svn.opensuse.org
Hack week
UOF Import Filter for OpenOffice.Org
This week is a hackfest week at Novell. I am hacking a UOF( Chinese Office File Format) import filter for OpenOffice.org. This filter is an external component based on ODF-UOF Converter.
An extension is developed so that OpenOffice.Org is able to open UOF text document. Here is some screenshots.
Although some features such as paragraph style, table are supported yet, there are a lot of work need to do. I will continue to work on them when I get time.
XEMBED, Mono and OpenOffice.
In my last post I talked about the hack I did to get some Java applets running in an OpenOffice.org docking window.
I played a little more with the code and managed to get a XEMBED socket running in an OpenOffice.org docking window. The picture below shows an OpenOffice.org running with a XEMBED ready docking window:

The title bar of the docking window shows the socket id to which XEMBED applications can connect.
I used the following Mono code to connect to the XEMBED socket:
using System;
using Gtk;
// Compile with:
// mcs -pkg:gtk-sharp SamplePlug.cs
public class SamplePlug
{
public static void Main(string[] args) {
if (args.Length != 1) {
Console.WriteLine("Need socket id as an argument.");
return;
}
uint socket_id = UInt32.Parse(args[0]);
Console.WriteLine("using socket "+socket_id);
Application.Init();
Plug plug= new Plug(socket_id);
// plug.Add(new Label("HELLO"));
plug.Add(new Entry("HELLO"));
plug.ShowAll();
Console.WriteLine("running..");
Application.Run();
}
}
The picture below shows it all running:

In theory this'll work not only with Mono but with any application which can talk the XEMBED protocol like e.g. GTK- and QT-based applications.
Remote management with Rails
Just follow the install and configure instructions. In short you need
- openwsman
An open source implementation of the ws-management standard. - rwsman
Ruby bindings for openwsman client operations. - Ruby On Rails
Web development that doesn't hurt - Railsapp
Rails demo application for rwsman
Discovery page
will appear.
Look closely at the Actions line for each host and you'll notice the YaST action for the openSUSE client. This client has my openwsman-yast plugin installed.
The demo application allows to start and stop the desktop (the xdm service to be precise) and to switch the desktop environment between KDE and GNOME.
YaST operations
Doc has videotaped a demo, you can find it in the idea.opensuse.org blog.
