Index ¦ Archives ¦ RSS > Tag: en

git-review

Estimated read time: 2 minutes

LibreOffice started to use Gerrit for code review, and while occasional contributors can submit patches manually, in case one does many reviews, it’s handy to use a dedicated tool. In core.git, we have logerrit, but that’s not advised for regular reviewers, either, git-review is recommended instead.

So I looked into git-review. The good news is that it’s packaged already for most distributions, e.g. a simple

zypper in python-git-review

on openSUSE installs it.

I wanted to use this tool for two tasks:

  • Submitting changes to Gerrit: git review -R could do that. -R prevents automatic rebase, so a test build won’t fail because your patch is based on an already broken commit. The other good thing is that you don’t have to remember where to submit: both the master and libreoffice-4-0 branches contain a .gitreview file that contains the necessary server / branch information.

  • Cherry-picking changes from Gerrit: I found no option for this. A cherry-pick command is generated on the web interface, but it’s more complicated than a simple <some command> <number of the change>. So I submitted this change to git-review itself, the next release will be able to do git review -x <number of the change>.

Probably the browser interface is still the best to comment (especially inline comment) and approve changes, though David even submitted a proof of concept patch for that as well.

Finally, let me just clear two myths:

  • If you use Google for OpenID login, you can have multiple OpenID accounts associated with your Gerrit login, so it’s not a problem (first I thought it is) if you use one email for Gerrit and an other one for accessing other Google services.

  • Somewhere I read that the stock LibreOffice hooks conflict with git-review: nope, git-review didn’t touch the hooks, you can use the tool without corrupting them in any way.


LibreOffice Writer now supports gradients in text frame backgrounds

Estimated read time: 1 minutes

When you create a rectangle or text frame in Writer, you have two choices. You can use the draw toolbar to create a drawinglayer rectangle, and you can also insert a text frame. The drawinglayer shapes are shared between the LibreOffice applications, and already supported having not only a bitmap or a color but a gradient or a hatch as a background. The benefit of Writer text frames is that they can contain anything a normal Writer document can — think of columns, tables, etc. These features are not supported by drawinglayer rectangles.

So till now you had to decide what to pick, but it wasn’t possible to have both. LibreOffice 4.1 makes this situation better. Now it’s possible to have gradient backgrounds in Writer text frames as well:

The nice thing is that this feature was already supported by ODF, just not by Writer, so no such paperwork was needed this time. Also the OOXML filters are updated. As I already stated in this comment, the binary DOC and RTF filters are not yet touched regarding this feature — though I already looked into the RTF one, and have some idea what rework is needed there first.


FOSDEM 2013

Estimated read time: 1 minutes

We spent the last weekend in Brussels, at FOSDEM 2013. Outside attending great talks, I most enjoyed meeting people I haven’t met in person before, in no particual order:

Also fixed fdo#48440, fdo#58646 and fdo#59419 during less-interesting talks. ;-)

Additionally, during the last day we had time for some site-seeing, some pictures are here. Slides of other LibreOffice talks are also available.


lcov

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.


mdadm upgrade

Estimated read time: 2 minutes

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:

mdadm --manage /dev/md126 --fail /dev/sdd1
mdadm --manage /dev/md126 --remove /dev/sdd1

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

fdisk /dev/sdd
mdadm --create /dev/md125 --metadata=1.0 --level=1 --assume-clean --raid-devices=2 missing /dev/sdd1
mkfs.ext4 /dev/md125

Finally I copied over the live system:

mkdir /mnt/md125
mount /dev/md125 /mnt/md125
rsync --delete -avxP / /mnt/md125
umount /mnt/md125

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.


Recent contributions

Estimated read time: 1 minutes


Zero RTF Regressions?

Estimated read time: 1 minutes

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


Free Software Conference 2012

Estimated read time: 1 minutes

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


LibreOffice Hackfest in Munich, 2012

Estimated read time: 2 minutes

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:

  • Laszlo explained on the train to Munich that single line spacing is 15% of the font size, by definition. That finally explains why it is that the height of a 12pt single-line paragraph in Writer is not 240 but 276 twips.

  • Finally Michael motivated (and also helped!) me to improve the copy&paste in the new RTF filter, so it seems that removing the old filter completely is near.

  • The ability to sign each other’s gpg key was a great idea. I didn’t know too much about this topic, so I read up on this here. (Additionally, the gpg-key2ps command from signing-party — yes, there is such a package! —  is useful.)

  • We set up a nice icecream farm from the laptops, one more aspect that boosted our productivity.

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

  • it required re-configuring your build tree (--enable-icecream)

  • it required shutting down your firewall

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

  • look into the wiki, you only need to open a few ports, even broadcasting/auto-discovery works with a started firewall

  • use CCACHE_PREFIX="icecc" make build-nocheck PARALLELISM=30 to enable icecream for a single make run

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:

zypper -p http://download.opensuse.org/repositories/home:/llunak:/clang/openSUSE_12.2/ in icecream-0.9.7-64.1s.x86_64

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

As usual, some pictures are available.


LibreOffice OOXML improvements in Writer

Estimated read time: 2 minutes

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:

  • document with a checked checkbox (test doc):

  • document with contextual spacing enabled for the numbering (test doc):

  • document with a field that has a custom font size (test doc):

  • document with a SmartArt inside (test doc):

  • document with lots of VML shapes (test doc):

  • document produced by Microsoft Office 2010 (test doc, thanks Fridrich!):

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

  • document with commented text ranges (test doc):

  • document with a floating table (test doc):

  • document with ink annotations (test doc, thanks Eilidh!):

  • document with an OLE object inside a rectangle (test doc):

  • document with an inline image with custom margins (test doc):

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!

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