Michael Schröders hackweek project is based on using well-known mathematical models for describing and solving package dependencies: Satisfiability - SAT
Apparently, some research on this topic was done before. The oldest mentioning of SAT for packaging dependencies I found is a paper from Daniel Burrows dating ca. mid-2005. Daniel is the author of the aptitude package manager and certainly knows the topic of dependency hell inside out.

However, the most interesting link Google revealed, was the one to the EDOS project.
EDOS is short for Environment for the development and Distribution of Open Source software and is funded by the European Commission with 2.2 million euros. The project aims to study and solve problems associated with the production, management and distribution of open source software packages.
Its four main topics of research are:

• Dependencies With a formal approach to management of software dependencies, it should be possible to manage the complexity of large free and open source package-based software distributions. The project already produced a couple of publications and tools, but I couldn't find links to source code yet.
• Downloading The problem of huge and frequently changing software repositories might be solvable with P2P distribution of code and binaries.
• Quality assurance All software projects face the dilemma between release often - release early and system quality. One can either
  • reduce system quality
  • or reduce the number of packages
  • or accept long delays before final release of high quality system
  EDOS wants to develop a testing framework and quality assurance portal to make distribution quality better and measurable.
• Metrics and Evaluation The decision between old, less features, more stable vs. new, more features, more bugs should be better reasoned by defining parameters to characterize distributions, distribution edition and distribution customization.

Interesting stuff for a lot of distributions out there ...

"The first casualty of War is Truth"
Reading some blogs about the ODF/OOXML file format war the famous quote "The first casualty of War is Truth" (from Rudyard Kipling --- I guess) comes into my mind.

I was out of town for part of hack week, so I didn’t participate fully like my colleagues. I did get a couple evenings to mess around with something, though. I wrote an installer for KIWI-generated LiveCDs.

It’s still in early development and has lots of hacks to make things work, but it does manage to install a working system onto your machine. The installation itself is really pretty simple. The LiveCD data is in a compressed squashfs image on the CD, and the installer just copies all of that to the disk. Then it just writes out an fstab, installs grub, etc.

As usual, however, the devil is in the details. Things like sound and video card detection are normally done by the YaST installer, so other methods must be used. It might be possible to invoke the relevant bits of YaST from the LiveCD installer to achieve the same effect, but I haven’t looked into it yet. I have everything checked into svn (svn://snorp.net/trunk/opensuse-live), so if you want to try and build a CD everything is there. I will also upload an ISO soonish.

Update: You can download a full ISO based on openSUSE Alpha 5 here.

Some days ago I committed lots of changes regarding inotify support. Goodies and improvements have been introduced… I had this code laying on my laptop for several weeks because I wasn’t able to fully test it. An annoying bug afflicting the update index operations was blocking me. But some days ago Jos fixed it, so I didn’t have any excuse :)

These are the major changes introduced:

1. event caching: using a small cache it’s now possible to simplify multiple events and prevent high cpu usage when lot of changes occur on the same files
2. interruption handling during the re-index operations: changing the directories to watch during an indexing operation will break the previous job and start a new one
3. other small changes for improving cpu utilization
   

Actually I’m very happy of the first point, but I think the second one can still be improved…

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..

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 ;)

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.

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

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…

After five days of hacking last week, a final itch was left which needed scratching. The YaST openwsman plugin only passed strings back and forth, losing all the type information present in the YCP result value. So I added some code to convert basic YCP types to XML (in the plugin) and from XML to Ruby (on the client side). Now the result of a web service call to YaST can be processed directly in Ruby. Here's a code example showing the contents of /proc/modules on a remote machine.

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