Canonical Voices

What Bjoern Michaelsen talks about

He was born in the summer of his 27th year
Comin' home to a place he'd never been before
He left yesterday behind him, you might say he was born again
You might say he found a key for every door

-- John Denver, Rocky Mountain High

Returning from my vacation -- during which I forced myself to a strict and complete media blackout -- I find myself indeed coming home to a place I had never been before:

And then there was FOSDEM 2012, which is really a culture shock, when you arrive there directly from the dreamy snowy mountains of the Massif de la Lauziere (*).

LibreOffice had both a Dev-Room and a booth (and great crew of vocational booth boys and babes, whose regular occupation is coding and contributing to the best free office suite ever).

The Dev-Room was packed with 18 talks in one day, which I had the pleasure to close with my paced(**) "10 reasons to contribute to LibreOffice today" while in parallel there was the additional LibreOffice keynote by Michael Meeks showing off some of the niftiness of LibreOffice on new form factors.

Next stop: LibreOffice HackFest on 14th April 2012 in Hamburg! Mark your calendars, ladies and gentlemen!

(*) quite an travel experience: digging out the car from the snow, driving to the valley, taking the train to Lyon, taking the tram to the airport, sitting in an unheated terminal at -10 degree celsius after security for two hours (dont fly easyJet), flying to Bruxelles, taking the subway to the city, finding the Hotel from memory. The story of the return from Bruxelles to Hamburg is shorter: the pilot managed to damange the plane during the first 10 meters of taxing so we (including the incidentally four LibreOffice hackers on the same plane) had to change to a difference vehicle.
(**) mostly for we were behind on the schedule

Read more

There have been some uploads of new Ubuntu versions of LibreOffice recently:

LibreOffice 1:3.4.5-0ubuntu1 has just been uploaded to oneiric-proposed too to be SRUed (it is exactly the same as the ppa version, except for the changed version).

If you want to help test any of these versions, you are most welcome!

P.S.: On a sidenote, I am slowly recovering from the "music" from a CD I was requested to listen to as a penalty for the unfortunate LibreOffice 1:3.5.0~beta2-2ubuntu2 upload causing some trouble upon update for many already on Precise. Thank you, Rick!

Read more

Note to self: When building LibreOffice packages in a pbuilder (a chroot with bells and whistles) which bindmounts your ccache, it is not a Good Idea to kill the pbuilder process mercilessly. This is because debugging a heisenbug caused by a corrupted ccache is never fun.

Read more

In many ways you can just see git as a filesystem -
it's content- addressable, and it has a notion of versioning [...]

-- Linus Torvalds

bibisect stands for "binary bisect" and is intended to help QA for LibreOffice 3.5. Regressions are a most annoying artifact that unfortunately comes with software development and QA. However, regressions are a misfeature we want to deal with quick and early as they might get harder and harder to triage and fix as time passes.

Because the way git stores its stuff, this download:


  • 53 complete Linux 64-bit office installs (compiled on Ubuntu 11.10, but should work elsewhere too) between the creation of the core repo and the -3-5 branchoff (that is ~5000 commits)
  • at 450MB each, that would be ~22GB total
  • however, it is only 749MB total download size, that is less than 15MB per installation
And one does not need to install them in parallel as one can switch through all of them with a quick "git checkout source-hash-XXXXXX" -- one switch costs <1 second).

Now how does one use this for cornering a regression? Well, this is where the power of bisecting comes in. First you download the tarball and unpack it:

> wget
> tar --lzma -xf bibisect-3.5.tar.lzma
> cd bibisect-3.5
> # to verify your download was not corrupted do a: git tag -v latest
> # you need my gpg-key from for that

Then you get yourself the newest build included in the download and check if your bug it there:

> git checkout latest
> ./opt/program/soffice.bin

Then get the oldest build included in the download and check that the regression is not there:

> git checkout oldest
> ./opt/program/soffice.bin

If the bug is already present at this point, it is not a regression in the range that is covered by the download, but an even older bug.
If the bug is not there it is a regression in the range covered by the download and we can corner it down very well now. Do:

> git bisect start latest oldest

to start bisecting. Then repeat these commands:

> ./opt/program/soffice.bin
> git bisect good # if the bug is not there
> git bisect bad # if the bug is there

after some ~5 repetitions, git will tell you something like this:

9625329ea5a7e3e8475cd21c07726beec20573bd is the first bad commit
commit 9625329ea5a7e3e8475cd21c07726beec20573bd
Author: Bjoern Michaelsen <>
Date:   Thu Dec 8 12:29:59 2011 +0100

    commit 2d19e9bb07ccff3134f855812dddfda5c07b1fe4
    Author:     Jan Holesovsky <>
    AuthorDate: Wed Nov 16 14:17:03 2011 +0100
    Commit:     Jan Holesovsky <>
    CommitDate: Wed Nov 16 14:21:33 2011 +0100
        Kill one usage of chrel.sed to fix build.

Append that (the source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 line is the important one) and the output of:

> git bisect log

Which should look something like this:

git bisect start 'latest' 'oldest'
# good: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3
git bisect good 2faf4bc12ab490370d2196dedbc8091f9b09d0a5
# bad: [b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4] source-hash-ce60138d339a5eb2a174a5d27063249acf2cac42
git bisect bad b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4
# good: [0a28a62d53e996cf66d86e9bfb63ddc6ade75b7e] source-hash-71cbcb62028295a98ceee60cb4c4ee425bafcd2e
git bisect good 0a28a62d53e996cf66d86e9bfb63ddc6ade75b7e
# bad: [9625329ea5a7e3e8475cd21c07726beec20573bd] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
git bisect bad 9625329ea5a7e3e8475cd21c07726beec20573bd
# good: [89d91bb6074026dc0894bcdc6aaf8f6124102da7] source-hash-fb754a0df859e30255c25af8fa19bfaa75f257e7
git bisect good 89d91bb6074026dc0894bcdc6aaf8f6124102da7

to the bug and the developers will have a very good idea where your bug is -- in this case between the commits fb754a0df859e30255c25af8fa19bfaa75f257e7 (good) and 2d19e9bb07ccff3134f855812dddfda5c07b1fe4 (bad) on master. A:

> git log fb754a0df859e30255c25af8fa19bfaa75f257e7..2d19e9bb07ccff3134f855812dddfda5c07b1fe4

on the source repository will then show the 128 commits including the one that introduced the bug, making it a lot easier for the developer to close in on the culprit.
For more details, see:

Read more

The end of the year coming nearer and traditionally this is the time for donations to charities and for just causes. And while I am not usually a guy caring much about traditions, LibreOffice and the Document Foundation is a just cause that I firmly believe in. So, to put my money where my mouth is, I just donated 220 Euro (or 5 Euro for each week I am on the project) to the Document Foundation. I dont know if that is much or little and honestly I dont care that much really.

Quite a few people are donating 5 or 10 Euro to the Document Foundation and that is not too little or unimportant. I even think these are the contributions that count most, as there is strength in numbers. The Document Foundation was founded on the believe that is not only possible to develop a competing productivity suite as open source, but also to do so independent from any one single vendor or supporter. So huge numbers of small donations as opposed to bigger donations from a selected few support the very idea that the Document Foundation stands for.

And there is even some evidence that the long tail of individuals interested and contributing to the project each for maybe completely different reasons can make the project much stronger than focusing on a single consumer of the product(*). The most impressive evidence of this thesis is the creation of Unix in the way it was able to change the world. It was an accident, as the unusual circumstances of its birth prevented it to be choked by sort sighted commercial interest in the beginning and instead allowed the creation of a hugely successful broader ecosystem:

In 1956, AT&T had agreed to a U.S government consent decree that prevented the company from selling products not directly related to telephones and telecommunications, in return for its legal monopoly status in running the country's long-distance phone service. So Unix could not be sold as a product. Instead, AT&T released the Unix source code under license to anyone who asked, charging only a nominal fee.

And the rest is history.

So, if you think that any or all of the following is true:

  • LibreOffice is a very important open source project that needs your support.
  • LibreOffice can and should get much better still.
  • LibreOffice is important for the success of the open source desktop as a whole.
  • LibreOffice is important for the success of the open source ecosystem as a whole.

please join me and make your contribution today. Dont worry about the amount, every bit counts. And finally: Tell others about it -- it will motivate them to join us!

Note: All of this is my personal opinion and does not have to reflect the position my employer or the Document Foundation.

(*) Who is a figment of the mind anyway given the variety of options that LibreOffice offers.

Read more

Debugging LibreOffice has just been made easier for developers. After you have made a developer installation with

  • make dev-install
you can (on Linux only for now) run:
  • make debugrun
which will start you freshly build LibreOffice, while keeping an eye on it with gdb.

Read more

Just a short note:

I finally created the Easy Hacks by Topic page. If you are for example only interested in UI relevant work, you easily find ~30 related open Easy Hacks on the topic page now. So all our Easy Hacks overviews are now:

To get your Easy Hack sorted in you need to use the whiteboard status.

Read more

I recently bought myself an old IBM x3800. After the 65kg has been moved into my apartment and Oneiric has been installed on it, I tried to have a look at how fast I could get with my hardware. So I cleaned my ccache (this is the "without cheating" from the title) and started a build from my notebook with distccd running on the other machines.
So all in all I had:

  • one Lenovo W520 notebook (4 core i7-2720QM with 16GB RAM)
  • one Sun Ultra 24 workstation (4 core Q9650 with 8GB RAM)
  • one IBM x3800 (8 core Xeon MP 3.16Mhz with 8GB RAM)
and the development build1) chugged in after 32 Minutes. Rebuilding from ccache took ~8 minutes on that machine, so "pure compile time" was ~25 Minutes. Of course, starting the build on one of the other machines would likely have been a bit faster still as:
  • the Sun Ultra is about twice as fast alone as the notebook alone (full build in <1 hour)
  • the notebook did not run on a software RAID-0 (like the others would)
  • the notebook did not mount the build platform with noatime, which would be good for a few additional minutes of saved time
So: When doing a lot of work on Libreoffice, RAID-0 and noatime (together with distcc and ccache) are to be considered. However, If you are new the code, you probably only want to care about:
  • ccache
  • --disable-mozilla
  • --disable-binfilter
all the other stuff is only getting interesting once you are doing very regular work on Libreoffice. And an since it is getting winter again on the northern hemisphere: An IBM x3800 is a nice way to heat your apartment, if it was not for the noise and the electricity bills.

1) 2 jobs per core and:
  ./ \
  --disable-mozilla --disable-binfilter
--disable-zenity \
  --with-junit=${HOME}/.jenkins/junit-4.9b2.jar --with-external-tar=`readlink -f ${WORKSPACE}/../../tarfiles/workspace` \
  --without-help --without-myspell-dicts \
  --with-system-libs \
  --without-system-libvisio --without-system-libcmis --without-system-jars --without-system-graphite --without-system-lpsolve --without-system-libexttextcat --without-system-poppler --enable-librsvg=no \
  --with-num-cpus=35 --with-max-jobs=35

Read more

Here are the presentations I had a part in at the Libreoffice conference 2011 in Paris and their slides.

For more slides by other presenters go to Planet Documentfoundation (also take special note of the Libreoffice Online Demo). More later.

Read more

This is a short note on the state of Libreoffice packages on Ubuntu:

Read more

I just wanted to share this: MinGW cross-compilation: Runs!

And with this I am sending out big kudos to Tor, Kendy and Fridrich for making this possible. Now this is still very a early implementation and not ready for productive use, but being able to cross compile (native) and run (in wine) a huge package like Libreoffice for Windows with a complete open source stack is a major achievement in itself. It shows not only the dynamic in the Libreoffice project, it is also a testament to the power of open source as a whole.

P.S.: This post is intentionally not tagged libreoffice to keep it from showing up on planet documentfoundation -- I leave the glory of that to the main implementers.

Read more

This is a short note that the global menubar which integrated Libreoffice into Unity will not be enabled by default in the Ubuntu Oneiric release. It will still be installable with the package "lo-menubar". The reason is some remaining concern about stability which led to the more conservative decision to leave it opt-in for now.

Read more

is there, which makes a lot of things really nice and nifty, so while we are at it: a big thumbs up to Norbert for that! Hendrik Jensen send patches adjusting the Jenkins setup (Thanks!), which should make it even smoother to use. After that I also updated the Jenkins-Ubuntu setup script because we can now use the git-plugin in Jenkins in a sensible way. Among other things (like automatic triggering builds on new commits), your one click compile now has a list of changes since the last build attached to it. So now you can start your day right:

  • trigger the good-morning build (might be triggered automatically half an hour before you get up)

  • fetch a coffee or tea

  • have a look at what happened on master since your last build:

And yes, the "detail" link show the commit locally and the "gitweb" links go to .

Read more

Since the release of 3.4.2 (which will be included in Ubuntu Oneiric) is around the corner and I will be soon go on vacation I thought it might be a good time to take look at how I am doing contribution wise. Using the totally unscientific method of commit counting, I came up with the following numbers.
Of all the changes to master since February 1st, 2011 (the day I joined Canonical), I commited 561. Their authorship is:

  • 326 by Bjoern Michaelsen (yours truely)
  • 103 by Michael Stahl
  • 59 by Mathias Bauer
  • 31 by Henning Brinkmann
  • 15 by Phillip Lohmann
  • 10 by Ocke Jansen
  • 4 by Ivo Hinkelmann
  • 3 by Daniel Rentz
  • 2 by Matúš Kukan
  • 1 by Alberto Ruiz, Andras Timar, Eric Bachard, Jani Monoses, Matthias Klose, Michael Meeks, Sergey Davidoff and Xisco Fauli each
In addition Michael Meeks and Fridrich Štrba each commited one of my changesets. So in total I had some role in 563 of the 11.756 changes done to master in the given timeframe -- or about 4.8%.
Just counting self-authored and self-commited changesets, my 326 were outperformed by:
  • Fridrich Štrba (330)
  • David Tardon (406)
  • Miklos Vajna (407)
  • Petr Mladek (415)
  • Kohei Yoshida (500)
  • Thomas Arnhold (634)
  • Tor Lillqvist (1014)
  • and our absolute rockstar Caolán McNamara with 1865 commits.
Congratulations and a big thank you to all of you!

Read more

Wouldnt it be nice to have one-click compiles of LibreOffice on Ubuntu? Fret no more, good times are here!

But before we get to that, here are a few general hints on how to build LibreOffice 3.4.X and the LibreOffice master branch on Ubuntu:

And if you are fearless(*), run these commands (which already take care of the Junit and cherrypicking stuff themselves):

sudo apt-get build-dep libreoffice
sudo apt-get install git ccache
wget -O - |sh -
java -jar ~/.jenkins/jenkins.war

and point your browser to: http://localhost:8080 and you will find something like this:
Click on "schedule a build" on the right side for ccache, tarfiles and repo-mirror once to get setup. If those are finished, by "scheduling a build" for libreoffice-3-4 or libreoffice-master you can build and test the current release branch and the master branch as often as you want to with just one click. What are the advantages of this?
Here are some:
  • You have a reproducable build setup.
  • You can completely mess up you checkout without needing a very slow redownload from
  • You can schedule multiple builds in a row.
  • Your new and old build logs are managed automatically -- if something breaks you can be sure which one was the last good build for you.
  • You can trigger builds by various means automatically. For example, you can let Jenkins make a build when you get up and see immediately if somebody broke the master for you in the morning when you start working.
  • Jenkins is very extensible.
A lot more will be possible with one git and this is just a proof-of-concept, but still it might be quite useful to some already. So, comment and ideas (and most of all: patches and commits) on how to improve this are most welcome!

(*) In general, it is not advisable to pipe some random file from the Internet to your shell. Also take care that port 8080 is reasonably secured on you machine before starting Jenkins.Caveat Emptor.

Addendum: For the repository synchronization script you currently need Python 2.7. Sorry about that, I will try to get rid of that dependency soon.

Read more

This has been my first Ubuntu Developer Summit and therefore also my first chance to meet up with the Canonical Desktop Team in person. I had been warned before that UDS is an exciting, exhausting, enlightening and inspiring experience and I was not disappointed on any of these points. The schedule is just mindblowing, the location was great, even though little was seen from the outside world, because there was always something that needed urgent discussion. Luckily I have been in Budapest last year already for the last (in every meaning of the word, it seems) OOoCon.

I drafted two blueprints about LibreOffice which were discussed in sessions on Wednesday:

It was also great to able to have a nice short chat with Alberto Ruiz and Ted Gould about the LibreOffice Unity integration and finally also meet other contributors to the LibreOffice project (for example: Vish, KAMI and Robert Roth) and members of the Ubuntu Documentation and Translation teams with an interest in LibreOffice and its place on the desktop.

On a side note: My flight there was delayed, making me miss my connecting flight, but that allowed me flighting through the dusk, which is always so beautiful, that I would like to share a view of that with you:

Read more

Ubuntu 11.04 'Natty Narwhal'  has been released on April 28th, 2011 and is the first Ubuntu release to contain a LibreOffice in the default install.

A few days after the official release, it indeed seems to be a overall smooth transition. Apart from the move from to LibreOffice, there are some other exciting changes in this Ubuntu release: The LibreOffice icons are not only used in LibreOffice itself, but also on the dash and in the default theme for Nautilus. So the new icons are consistently being used in the whole desktop experience. Congratulations to the LibreOffice Design team for this success!

Also, by installing the lo-menubar package you can already enable the LibreOffice Integration with Unity that was created by Alberto Ruiz. The code for this feature has already been upstreamed to LibreOffice and is also on the 3.4 branch and thus will be part of upcoming releases.

So: Where do we go from here? Work on Ubuntu 11.10 'Oneiric Ocelot' is starting right now. In fact, the first fixes to critical issues related to LibreOffice have already been released. More to come soon!

A great thanks to all who make these awesome developments possible and a special thanks to Rene Engelhard for his hard work on debian packaging.

Read more