Sounds like an easy question, but I learned over the past few years that for software projects, the answer is typically not a yes or no question.

Technically — for example — Virtualbox OSE is considered opensource, even the OSE abbreviation suggests that it’s a stripped down version of the real codebase, that is kept as a secret. At first thought I wouldn’t even imagine it’s possible to contribute back a patch from someone not working on the original — closed — codebase, but of course I may be wrong in case of Virtualbox.

There is also the question of what is open. Only tarballs of releases, or also the SCM repo used for development? Think of Amazon’s custom kernels where the code is open, but it’s obviously only a code dump, one is not supposed to contribute to it, and the individual changesets are not public.

Finally, even if the software itself is developed in a truly free manner, some enterprise version (which is based on the free version) may not be publicly developed, e.g. only the resulting tarball is public. I’m happy to see that at $dayjob even this last detail is quite public, think of LibreOffice or the Linux kernel.

Even though I spend little of my free time with sysadmin stuff these days, this came up recently. A few years ago I hit an issue about mdadm creating too new metadata that wasn’t handled by the installed kernel, so I remembered to use --metadata 0.90 when creating a new array. Additionally, I preferred using cfdisk for partitioning.

It turns out this caused quite some grief when it came to grub2, I wrote about this earlier — that was about the theory, in a VM. This is about the practice. In practice, gparted turned out to be too risky, and I choose the following approach to repartition the hard drives (so there is enough space for grub2) and upgrade the mdadm metadata.

First, I broke the mirror by removing one leg of the RAID1 array:

Then I created a new array (with a single leg) with the new metadata and formatted it:

Finally I copied over the live system:

The rest was easy: I booted a livecd to do the rsync once again (taking a few minutes only), and once the system was running from the new array, added the leg of the old array to the new one as well — and that’s it.

Here are a few contributions I made recently:

I think the first attempt to track LibreOffice RTF Writer regressions (bugs not presenting in some earlier versions) was in this mail. That started with 14 bugs, and of course while I fixed a few, new ones were added as well. I guess this is mostly due to testing work, since new fixes are usually covered by unit tests, so re-introducing the same problems nowadays is a bit more work.

I remember I was down to one regression a few months ago, but we still had performance problems, which got solved a few weeks ago, so I had the idea that I want to go down to zero during the holidays. It seems today I finally managed to do so — bugs tagged as rtf_filter and regression are gone, thanks everyone who helped! :-)

For the reference here are the queries: RTF regressions, fixed RTF regressions, Writer regressions.

Now that the list is empty, feel free to tag more bugs as rtf_filter from the long Writer list when needed.

Update: the list is now empty again, as of 2014-11-24, for the 4.4 release. ;-)

The Free Software Conference 2012 — orginized by FSF.hu — was held today @ Budapest. I gave a talk about hacking on new Writer features (slides).

We (with Andras) also ran the LibreOffice booth, and in idle cycles I also had time to kill this annoying bug. This year speakers got a t-shirt and a fine lunch, thanks for the organizers! :)

Valamelyik hétvégén átnéztem a pólóimat, a rég nem hordottakat eljuttatandó a Máltai Szeretetszolgálatnak. Persze a többség valamilyen szabad szoftveres eseményről származott, így biztos ami biztos lefotóztam őket. Itt van például egy 5 elemű GSoC sorozat:

További fótók erre.

During the weekend I was in Munich to visit our second LibreOffice hackfest this year. The archivements are detailed here. Here are a few interestings details I learned during this event:

Speaking about icecream — there were two reasons why I didn’t really use it:

It turns out none of this is really needed, so let me share the way to avoid these problems:

Additionally, if you run openSUSE 12.2, by default the daemon reports that the box can’t compile x86_64 binaries (probably it hasn’t been updated to deal with the 3.0 kernel or something), a quick workaround is to install Lubos' updated package:

Thanks for the organizers, once again this hackfest turned out to be really useful! :)

As usual, some pictures are available.

It’s possible you noticed that in each LibreOffice release notes, we have a line saying something like "improved DOCX support", but is rarely explained in detail. I’m posting here a few screenshots to correct this. The first series is a list of import fixes which are already available in our shipping 3.6 release. In each case I provide a test document, and a screenshot how it looked like with LibreOffice 3.3 and how it looks like with LibreOffice 3.6 today. Click on the images to get a larger image:

Now let’s also have a look at some OOXML features which will be imported correctly in our upcoming 4.0 release:

If you want to try these out yourself, get a daily build and play with it! :) If something goes wrong, report it to us in the Bugzilla, so we can try fix it before 4.0 is released. And remember, there are lots more improvements coming in LibreOffice 4.0, stay tuned!

It all started with this bugreport about a year ago. RTF has two different markups to describe shapes. The old one (used till Word 6.0) is called Drawing Objects, the new one talks about Shapes. The first picture shows the "support" for this syntax in LibreOffice 3.4, and the situation did not change with my RTF import rework, as I wasn’t aware of any document still using this old syntax. So when I got this bugreport, I knew it’ll take some time to produce the correct layout, but now during the LibreOffice conference I spent quite some time on this, and at the end even the Hebrew text is imported correctly. ;-)

Thanks to Lior who politely nagged me from time to time, this is now available on master (see the second picture), which will become LibreOffice 4.0.

I spent the last two weeks on two conferences:

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

A few fun facts I discovered during the conference:

A few pictures here.