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

I’ve been invited to the first LibreOffice conference in Paris to give a short talk about this year’s GSoC work of mine: the RTF import rewrite in Writer. (Here are the slides.)

It also allowed me to allocate some time on hacking, including:

Thank you for the invitation, it was great fun!

I did not care about boot speed for a long time, since servers usually restarted only for kernel upgrades, laptops suspend to ram all the time, and I have no desktop machine at home for years now. Though one use case started to motivate me recently: I use virtual machines a lot, and waiting for them to boot up is boring.

So I looked at the systemd-analyze blame output, and it turned out that for a base-only install the only service that takes a lot of time is netconfig. It’s because it was a oneshot service, so the whole boot process waited for dhcpcd to get an IP. A much better solution is to just start netconfig in the background and move on — and that’s exactly frugalwareutils in git does now.

Before:

After:

When we got back from Munich, Andras had an idea what is the current bottleneck with the build when there are a lot of languages enabled, and it was the po2oo script, which is part of translate-toolkit.

First I tried to optimize that script, but then I tried to do the same gettext-to-SDF conversion from scratch, without using that framework at all, and it seems that caused a drastic speedup.

There were a few iterations, but now the two patches are in master, along with a fix in fast_merge.pl, which was there since at least commit 654810b (2009-06-17). ;)

We were in Munich during this weekend, and I think all of us had great fun, kudos go to the organizers! If you are curious, there is a growing list of features implemented during the event.

Update: Oh, and I forgot to mention that we (Andras and me) especially thank the FSF.hu foundation for funding our travel!

Tonight I worked on fdo#39337, and while the writerfilter-based RTF import filter almost handled the document in question correctly, the fonts were not correct.

It turned out that this was caused by the fact that RTF’s font table (a table where each row has an ID and it contains the font name, charset and other properties) does not require continuous ID’s (for example positions 0, 2, 3 are allowed, even if 1 is not set), but dmapper (the glue layer between the RTF tokenizer and the Writer UNO API) does.

I already sent the position of the entry to dmapper, but the position turned out to be ignored, so now I fixed the RTF tokenizer to send continuous ID’s.

A related improvement is that I just discovered the writerfilter::TagLogger::unoPropertySet() method, which can dump the properties of an UNO object, and now I’ve enabled dumping of shape properties, which can help a lot when something goes wrong there.

Back in April I had the idea to merge my bitlbee-skype plugin to the main BitlBee project. The reason is simple: BitlBee does not really have plugins (basically my Skype plugin was the only one) and because of this, ABI compatibility was not guaranteed, so I usually had to rebuild or even fix it after each BitlBee release (though Wilmer was helpful in case I was in doubt). Today this is all past, the plugin is part of the main BitlBee repo I won’t make separate bitlbee-skype releases anymore. (Latest version of the code is here, bzr info here.)

I’m quite happy this little piece of software did not get lost, but now is in the hands of an active maintainer again. :) If you need help with BitlBee, ask on #bitlbee, at irc.oftc.net.

The next major LibreOffice version, 3.4, means some work for (Linux distribution, and other) packagers, as the build repo is now deprecated and packagers are suggested to use the bootstrap repo directly, which is a different build system.

On one hand, this is a nice cleanup - there is now a single configure script. OTOH this needs major rework of distro build scripts.

The interesting part here is that the official binary installers are not using the make DESTDIR=/some/path install method to install the compiled binaries, so it was discovered quite late that it wasn’t working properly. First Hanno and Petr worked on this, then I fixed a minor, but blocking glitch.

As a result 3.4 beta4 will be something packagers (even the ones not using the split build) can offer to distro users for testing without patching. Binaries for Frugalware users here (i686-only at the moment).

I just got the mail about my LibreOffice proposal got accepted to Google Summer of Code 2011. I’m looking forward to an exciting summer. :)

LibreOffice 3.4 will have a new feature, if you edit styles in Writer, then you can test your style changes without manually closing and opening the style edit dialog again.

Do you like this feature? There are still similar remaining dialogs to improve like this, send in a patch!