D-Bus and Ruby

There isn't a canonical D-Bus library for Ruby. I found four projects, two of which are interesting.

First, the two losers:
* dbus-ruby: It wraps the C bindings. It is dead (last release in January 2005).
* pr-dbus: No releases, last SVN commit in April 2007, entirely in Ruby.

Now for the contenders. Both are packaged as RPMs in the OBS YaST:Web project.
The developers know about each other but in 2007 they did not want to merge the projects. The developers are not active but patches do appear.

* ruby-dbus

• LGPL
• no test suite (but I've started one together with bug fixes: Github clone)
• can export services
• cumbersome API (explicit introspection calls needed, explicit types for variants needed, return value must be an array)

BTW Klaus has two posts about writing a client and a server with ruby-dbus.

* rbus

• GPL
• test suite (RSpec, needs a patch)
• cannot export services

WebYaST is using ruby-dbus so far, but I am looking at rbus too because of the tests and and the nicer API.

Perl DBus Library

If you want camels in your D-Bus, use perl-Net-DBus by Daniel Berrange. I have just fixed the original packaging done by Illuusio. Enjoy.

Cool Features in Automake 1.11

Automake is not dead, and version 1.11 will soon be in openSUSE Factory (thx puzel!) I see two new features to like: parallel execution and terse compilation.

The parallel execution is enabled by the environment variable AUTOMAKE_JOBS=n. It reduced the run time for yast2-core from 18s to 7s for me.

As for compilation, how's this (kernel people may yawn now):

make[4]: Entering directory `/home/mvidner/svn/yast/trunk/core/wfm/testsuite'                                                                         
CXX    runwfm.o                                                                                                                                     
CXX    runc.o                                                                                                                                       
CXXLD  runwfm                                                                                                                                       
runc.cc:54: warning: unused parameter ‘name’                                                                                                          
CXXLD  runc                                                                                                                                         

compared to:
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../libycp/src/include -I../../liby2/src/include -I../../libscr/src/include -I./../src -I../../liby2util-r/src/include -DY2LOG=\"wfm\" -O0 -g3 -W -std=gnu++0x -DHAVE_CXX0X -Wall -Wformat=2 -MT runwfm.o -MD -MP -MF .deps/runwfm.Tpo -c -o runwfm.o runwfm.cc
mv -f .deps/runwfm.Tpo .deps/runwfm.Po
/bin/sh ../../libtool --tag=CXX --mode=link g++ -DY2LOG=\"wfm\" -O0 -g3 -W -std=gnu++0x -DHAVE_CXX0X -Wall -Wformat=2 -o runwfm runwfm.o ../src/libpy2wfm.la ../../scr/src/libpy2scr.la ../../libscr/src/libscr.la ../../libycp/src/libycp.la ../../libycp/src/libycpvalues.la ../../liby2/src/liby2.la ../../liby2util-r/src/liby2util.la

It is enabled by putting this to configure.in:

m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])

(The ifdef makes for graceful degradation with older automake.)

Use Webpin or the Software Portal to find a package built for your release.

A Minimal Build Service OSC Plugin

I am trying to make OBS cooperate with my old release scripts*. So far I have this minimal plugin for osc to share:

$ mkdir ~/.osc-plugins
$ cd $_
$ cat > releasecheck.py <<EOF
def do_releasecheck(self, subcmd):
   print "Release early, release often."
EOF
$ osc releasecheck
Release early, release often.

*) They are not released, bad me; but they rely on the internal directory layout anyway.

Bugzilla Fables: Serving Two Masters

You may know this: spending a few hard days, or even minutes, figuring out a bug and in the end the result is a one line change. What an injustice! So let's expand one such case for the amusement and education of the audience. Fable #501758:

For certain tasks, YaST uses external helpers (agents) communicating via pipes. One of them was causing YaST to hang when cleaning up. Actually no, it was two of them. Either one was not enough, but if two of them had been used, they would both keep on running and YaST would not exit.

It turns out the bug is in YaST not closing unnecessary file descriptors before spawning the agents. So the second child inherits a copy of the pipe that controls the first child. Then YaST closes the first child's commands pipe, expecting it to see EOF and exit. But the pipe is still open in the second child, uselessly. And they all wait. And wait...(*)

Moral: close unnecessary FDs before exec.

If you wonder why we did not see the problem earlier, it is because both agents contained another bug, a banal one of not responding to an explicit Exit message.

*) Actually, only YaST wait(2)s. The other two read(2) ;-)

Reducing Unprioritized Bugs

This Greasemonkey script, Check Priority, will check whether you are modifying a bug assigned to you and leaving its priority at "P5 - None". It will pop up a confirmation box to remind you to set a real priority.
Thanks to Milan Vančura for showing us how b.n.c can be improved (check out also the local time script) and for even implementing this one as I stood behind his back!

Disabling the fetchmsttfonts update

I learned about a new icon of the update applet yesterday, the blue one for optional updates. I wanted to say "I don't want this particular optional update, thank you". But how?
Short: to disable the fetchmsttfonts update, remove pullin-msttf-fonts.

YES # zypper rm pullin-msttf-fonts

Long:
I tried to add a lock on the patch, but it did not seem to have any effect.

NO  # zypper addlock --type=patch fetchmsttfonts     # or al -t patch

After looking in the raw update metadata (updateinfo.xml.gz), I found the solution: remove the package pullin-msttf-fonts, with the first mentioned command.
Curiously enough, also other guesses at adding locks do not work, in a different way:

OK  # zypper al fetchmsttfonts

This adds a lock for the new package that fetches the fonts. The lock actually does what I want, in a different way: it installs the patch but omits the new package. It is also the most obvious command.

NO  # zypper al pullin-msttf-fonts

This is different in that pullin-msttf-fonts is already installed. List-updates still lists the patch as needed but halts on a solver conflict when trying to install it. The locks seem to take effect only when committing the transaction, not when checking for the updates.

But still, I would like to have a clickety way for this. Am I spoiled?