Index ¦ Archives ¦ RSS > Category: opensuse ¦ RSS


Estimated read time: 2 minutes

There are multiple strategies how to add testcases for code that sort of works, but has no or too few tests. One approach (that works quite well in LibreOffice, for example) is to just add tests for new code, and there the test is "good", if it passes, but it fails if you revert the corresponding real change.

An other approach to avoid duplicated tests is to use a tool like lcov, that can perform line or function coverage analysis for you, so a test is "good" if it increases the coverage. I wanted to look into this later approach for LibreOffice, but I decided it’s more fun to try this out for a smaller project first. That’s when adding testcases for BitlBee’s Skype plugin came into my mind.

The problem there is that manual testing typically includes multiple online Skype clients and an IRC client as well, and such tests are extremely unreliable. So I thought: if I’m able to mock both the interactive IRC and Skype clients, then it’ll be easy to test the C Skype plugin itself, even for very special scenarios (like changing a groupchat topic in the middle of inviting somebody to a groupchat or similar).

So here is the result looks like:

 skyped mock file   +--------+         +---------+   pyexpect mock file
------------------> | skyped | <-----> | bitlbee | <--------------------
                    +--------+   TCP   +---------+

For skyped, the exact traffic is recorded and played back later; for BitlBee, only the outgoing traffic is exact, for the incoming traffic pyexpect allows just patterns (to allow tolerance for not interesting changes). Once the framework was available, it was quite easy to add testcases: I already have 70%+ coverage, and I think approaching the 100% function coverage is realistic. :-)

What was also interesting is that it turned out the latest upstream lcov release is not compatible with gcc-4.7, but the necessary patches are now integrated, and the next upstream release will work out of the box.

The BitlBee mock files can be found here. Given that there are now instructions to do similar analysis for LibreOffice as well, I hope to look into increasing test coverage for the classes I maintain as well.

LibreOffice / openSUSE Conference 2012 in Berlin / Prague

Estimated read time: 1 minutes

I spent the last two weeks on two conferences:

  • LibreOffice Conference in Berlin, where I gave a talk

  • openSUSE conference in Prague, where I just attended.

In general, thanks for the organizers for these fantastic events!

A few fun facts I discovered during the conference:

  • Armin is referred in the source tree as AW due to… well, it’s easy to find out once you heard about OD’s ORW reincarnation. :-)

  • solver stands for "solar version", it does not solve anything (read Michael Stahl’s talk for details)

  • I just discovered this presentation of Thorsten, slide 15 mentions a bug on x86, which is still the case on Android, 6 years later.. (even mentioned in Tor’s talk)

  • "Java? I hope that language dies" (Jan Engelhardt, openSUSE Sparc guy)

  • "Browser: we’re there; Office: with LibreOffice — even if it’s not perfect, we’re getting there. Groupware: we’re weak here" (Georg Greve, Kolab guy)

  • Don’t try to change EUR to CZK in the Prague main station, they have ridiculously bad rates

A few pictures here.

First openSUSE contribution

Estimated read time: 1 minutes

More than 3 years ago I gave a talk on Frugalware, and part of that was a comparison to various other distributions, including SUSE. My argument against SUSE was its closed development process.

Times change, earlier this year they even renamed their build system to signal its open nature.

I wanted to try it out how open they are so I made an experiment.

First, I created a cpm package in OBS to get familiar with the packaging process a bit. (Note that anyone can just register and use the build system to share their binaries-- sadly we don’t have resources in Frugalware to provide something similar.) Then I happily noticed that their mutt package already contains my favorite sidebar patch, though the edge of the sidebar looked awful. So on Monday I mailed the maintainer of the mutt pkg if he would take a patch, fixing this issue. I got a positive reply today, submitted a patch and in minutes it got accepted.

So it looks like they are really open, which is just cool. :)

© Miklos Vajna. Built using Pelican. Theme by Giulio Fidente on github.