Out of total insanity I promised Adrian a couple of weeks ago to test local installation of the OBS build service and interconnect it with the build.opensuse.org instance. Last night I couldn’t sleep due to the heat, so I finally did. Half an hour later, everything was installed and set up correctly according to the README.SETUP instructions in the obs-server package. I’ve fixed a couple of small issues in the README while doing so.

This morning, Michael Schroeder fixed the remaining bugs in the scheduler so that it actually runs. And now it builds

Source and binary interconnects work fine, so I can e.g. branch a package that is somewhere in the openSUSE buildservice (some KDE:KDE4: package or even openSUSE:Factory) and modify it locally in a test project, and watch the resulting build failures. There are some smaller issues with “osc linkpac” and “osc branch”, but editing the _link  files directly works.This way one can do experimental changes to packaging without actually breaking the repository for all other users, or slow down the build power ressources for everybody else due to unnecessary rebuilds.

As a test case, I’ve imported KDE 4.0.5 packages into a local branch of KDE:KDE4:STABLE:Desktop for testing. More seems possible, like for example doing a daily rebuild of the KDE 4.

Really cool stuff. Buildservice guys, keep rocking!

If you are interested in a short overview about what is Scientific Programming and which are the tools used in general, here is a short but very nice article: A case study on large-scale parallel scientific code development. Just a short summary:

"All codes use the message passing interface (MPI) library to achieve parallelism. In addition, each code uses external libraries for features such as

• I/O (HDF, NetCDF, CGNS, or Panda);
• mesh operations, including adaptive mesh refinement (ParaMesh, Mesquite, Metis, MeshSim, or SAMRAI);
• computational geometry (CGAL);
• linear algebra (BLAS, LAPACK), and tools for solving sparse linear systems and systems modeled by partial differential equations (PETSc, Hypre, or Clawpack).

While these codes use parallel libraries that sit atop MPI, developers still had to write raw MPI code to achieve desired functionality."

Yes, long time has passed since my last post (really strange, isn’t it :D ). It has been a busy period, full of work, dog training and… coding (fortunately!).

During this time I’ve been working on XesamQLib creation. This is a Qt based library for accessing Xesam services. Its API is going to be similar to Xesam-glib one and it will make life easier for developers who want to interact with programs exposing Xesam service (who talked about Strigi? :D )

Right now I’m finishing to clean the code, in order to publish a first version of XesamQLib on KDE repository. I’ll keep you updated.

I just received a phone call. Here's a transcript, translated into English:

"Dad?"

"Who is this?" [I don't have any children, so I assumed it was just another wrong number. I get lots of those.]

"Dad? [crying] Two men kidnapped me. [crying] Dad?"

Realizing that it was a scam, I hung up.

Fake calls like these are common in Mexico, although I'd never received one until today. My wife's uncle received one a few months ago; unfortunately he was taken in.

Quite chilling, even though nothing happened—to me. I hope the people with the adjacent phone numbers weren't duped.

Hello !

One week ago I installed Fedora Core 9 distribution. But (experienced from openSUSE) there was something I missed : YaST and zypper. So I decide to port them to Fedora (and maybe to other distributons later).

I did something similar a long time ago (it was FC5) but now it seems much easier. Our developers makes UI part independent from ycp language. So I just compile libyui, libyui-bindings, qt, ncurses and was able to run example code in both frontends. With GTK there is still problem that is not cleaned from libzypp dependency.

Then I compiled libzypp and zypper. Then I add installation source - local CD-rom:

zypper ar cd:///?devices=/dev/sr0 CD

And it works perfectly!

Compared to yum is zypper much, much faster. Just for an example (I turn autorefresh on, by default is autorefresh disabled):

[root@dhcp24 ~]# time zypper se rpmlint
Reading installed packages...

S | Name    | Summary                                         | Type
--+---------+-------------------------------------------------+--------
| rpmlint | Tool for checking common errors in RPM packages | package

real    0m0.958s
user    0m0.308s
sys     0m0.482s
[root@dhcp24 ~]# time yum search rpmlint
Loaded plugins: refresh-packagekit
======================================== Matched: rpmlint =========================================
rpmlint.noarch : Tool for checking common errors in RPM packages

real    0m2.765s
user    0m1.826s
sys     0m0.788s

With autorefresh disabled search time is even better:

[root@dhcp24 ~]# time zypper se rpmlint
Reading installed packages...

S | Name    | Summary                                         | Type
--+---------+-------------------------------------------------+--------
| rpmlint | Tool for checking common errors in RPM packages | package

real    0m0.717s
user    0m0.289s
sys     0m0.362s

Note: I don't wan't to say which tool is better (everybody knows ;-)). Just that you can use zypper on the same installation source like yum. There are some requests on that porting from RH/Fedora users. And also some other people are thinking about this.

Ok, after that I compiled yast2-core, yast2-devtools, yast2-testsuite, yast2-perl-bindings, yast2-ycp-ui-bindings, yast2, yast2-pkg-bindings (maybe I forgot something, sorry). Finally mine package yast2-iscsi-client. Some patch because of distribution differences ... and the result is:



It works! ;-)
So we definitely can run YaST and its configuration modules on Fedora Core 9!

Ok, some work is needed to be done: create Build Service project and as a first step some distribution based patches. After that we should find some system how to use different backends for different distributions (like NetworkManager does). But this is something for another post ...

Good night,
Michal

Recently, I wanted to show how the buildservice makes packaging easier by creating a specfile template for you (just click the “Create RPM SPEC file templat” checkbox when creating a new package). Unfortunatelly, the template it creates is not really useful for someone not skilled in writing spec files. Also, it’s just a static template, so you have to write the summary and description even though you have just entered both in the web form. Definitely nothing to show off to newbies ;-). But knowing that the buildservice developers have more important stuff to do, and wanting to learn something new, I decided give it a try and fix it myself.

My idea is: The buildservice api asks a set of questions, which are presented by the client (webclient, osc, …) to the user, and creates a specfile based on these questions. Also, the api tries to suggest good defaults where possible. After spending some time learning ruby, rails and the api code, I have an ugly 200 line patch to the api that generates a working specfile for GNU hello ;-).

The user interface part is not yet done, but should be easy. What’s more chalenging is adding heuristics to “do the right thing”: detecting the build system (autotools, cmake, Makefile.PL, etc), detecting build dependencies, and so on. Right now, it only extracts the version number from the tar name.

On 5th of May I asked for a free live cd on their website, and today after about two weeks I received it:

Thanks Sun ...

There has been a lot of buzz lately about the Firefox 3 fsync issue. The work I’m doing these days has me doing a lot of long-running disk-bound activies, so this one hurts me pretty bad. Firefox would stop responding for 30-40s at a time while my job was running in the background, which I think is pretty unacceptable. I have worked around it in the (hopefully) short-term with a LD_PRELOAD hack. I’ve posted it here in case anyone else finds it useful. Just unpack, cd to the directory, and ‘make && make install’ (not as root). A word of warning, though: if it breaks you get to keep both pieces. Kudos to Aaron for adding the ‘make install’ bits to the Makefile :)

Today the Orbit started, with a very nice openSUSE booth. I’m showing Beta3, and so far it’s running quite good. So if you are in Zürich, visit the Novell booth! It’s quite easy to find, it’s the first one if you enter Orbit

Some Pictures from yesterday (setting up the booth):

Grr, i forgot to bring my camera today. The whole booth looks quite different now …

Declaring UI independence

Earlier this year, Stefan announced the availability of the YaST user interface engine separate from YaST itself.
The user interface engine, packaged in yast2-libyui (source code here),provides the abstraction from graphical user interfaces (Qt, Gtk) and text based (ncurses) user interfaces. It now can be used independently of YaST2 for generic (C++) applications.
Now what can you do with it ? First of all, you can use C++ to code YaST-like dialogs which display either in graphical mode (Qt or Gtk style) or text mode. This independence from the output media is a main feature of YaST.
Being separated from YaST, one can use the UI engine for stand-alone programs. A trivial example is a simple window with a text label and an 'Ok' button: HelloWorld.cc Compile with

g++ -I/usr/include/YaST2/yui -lyui HelloWorld.cc -o HelloWorld

and run it via

./HelloWorld

Depending on the DISPLAY environment variable the UI engine automatically determines and loads the right plugin to render the dialog. A simple unset DISPLAY will give you the ncurses look.

Enter SWIG

Coding dialogs in C++ takes away the highly useful edit-run mode of development which is possible with YaSTs YCP language.
With the help of SWIG, a generator for language bindings, one can now use his favorite programming language for coding dialogs. The initial release of the bindings supports Ruby (libyui-ruby), Python (libyui-python) and Perl (perl-libyui).
Swig can directly translate the C++ classes into e.g. Ruby classes making conversion of the above C++ code to Ruby straightforward: hello_world.rb Translation to object-oriented Python gives you hello_world.py Even Perl, although not object-oriented, gives reasonable code. But internals of the Swig-generated bindings are not for the faint-hearted ... hello_world.pl yast2-libyui comes with a couple of more examples.
SelectionBox1.cc shows how to fill a selection list, use buttons and update labels. Here's the Ruby version: selection_box1.rb Enjoy !