It all started by an innocent (?) question on 28th of November 2013. The inimitable Caolán asked whether anybody considered writing an import filter for AbiWord document format. And the distinguished readership of this blog knows well what makes your servant tick. So, the very evening, a skeleton was written and libabw, a library to read AbiWord file-format, started. It was pretty exciting to write -- after a host of libraries for file-formats that are not documented anywhere -- a filter for a file-format of our cousin. There was a hope that existence of a reference implementation whose source code is widely accessible would make the endavour easy. It is undeniable that grepping for values of different enums made the work a bit easier. Nonetheless, a huge part of the work was still figuring out what is permitted in AbiWord and how a change of one parameter affects the rendering of a document. Other thing to find out was how to map the concepts in the ABW files into the libwpd API that is heavily influenced by ODF concepts.

But the date of the start meant that soon came the Christmas and with it a possibility to spend some free time on the library. Eventually it became very usable and the import filter made it -- as a late feature -- into the LibreOffice 4.2 line and users of the upcoming LibreOffice 4.2.0 release.

The library currently supports both the plain xml ABW files as well as the gzipped ZABW files. The converted features include:

• Tables, including nested tables
• Headers and footers, including different left, right and first page headers/footers
• Footnotes and endnotes
• Multi-column sections
• Embedded images

And since a picture speaks louder then hundred words, here are some screenshots:

	&nbsp
A sample ABW file openedin AbiWord	&nbsp	The same ABW file openedin the upcoming LibreOffice 4.2.0

	&nbsp
A sample (zlib compressed) ZABWfile opened in AbiWord	&nbsp	The same ZABW file openedin the upcoming LibreOffice 4.2.0

As you can see from the screenshots, the world domination that we are actively seeking is having several contenders. But if you believe that we are the closest to its realization, please join the filter-writing fun! Show up on #libreoffice-dev channel at irc.freenode.net. You are also encouraged to follow my twitter and Google+ accounts. And stay tuned for more exciting news in the near future. We can promise you that you will have a lot of fun in the growing community of LibreOffice filter writers.

Scenario: I have a KVM virtualization server with a number of VMs defined. Suddenly, I cannot log in as root to one of the VMs. I will need to reset the root password. The "normal" methods like adding single or init=/bin/bash to the kernel boot line in GRUB do not work. The only option left is to boot from a rescue disc, but this is a virtual machine -- there is no DVD drive. Oh, no -- what to do?

NEWS FLASH: I just learned from a colleague that there is a much easier method. It is possible to chroot directly into the VM from the virtualization host. Will post detailed instructions as soon as I get them. Until then, there is always the "long route" described below.
Read more »

As I wrote in the last blog post, we try try to open YaST development as much as possible. When I thought what is the most annoying thing for me when contributing to an open source project, then it is when my contribution is ignored. So if I send a patch and do not get any response or I get response, but my patch is not merged without any reason, then I do not contribute again as I see it as a waste of time. To prevent such situation in YaST I’ve created an automatic reminder of pending pull requests for the YaST repos at GitHub.

How it is done? I want to have it transparent, reusable and automatic. The core component is a small ruby script I wrote to fetch pending requests for an organization on GitHub. It uses the GitHub API and tries to find any pull request without activity for three working days.

This script is handled by our public Jenkins server where it pulls the latest version of the script every working day and if there is any pending pull request it will send an email with its result to the YaST mailing list.

After a month of sending emails we have handled all longer running pull requests we have for YaST, so none of them have gone without activity longer than a month. I hope it encourages developers to create more pull requests as they will not be forgotten. We plan also to deploy such reminder for the libyui organization.

The NVIDIA drivers for openSUSE 13.1 took a while to appear. Many users have asked why this was and we’d like to explain what happened and what we plan to do to prevent this in the future. This post was written with input from the openSUSE developers who maintain these drivers at SUSE and work with NVIDIA to make them available for our users.

How it should work

Legally, the Linux kernel GPLv2 license leaves proprietary binary drivers in a bit of a tangle. While some claim it should be OK, others say not – and that is what most distributions currently assume: one can not ship a Linux distribution with proprietary, binary drivers. NVIDIA has agreed that our users can grab their drivers from the official NVIDIA servers. They are packaged by SUSE engineers however. They take care of both SLE and openSUSE proprietary driver packaging for NVIDIA hardware, and have contacts at NVIDIA who get the drivers up on their ftp mirrors.

The packages are build on a dedicated system, but the package spec (skeleton for building) is in OBS – for example, G03 is here. Anybody could use these to build the nvidia driver locally (the nvidia binary driver is grabbed from the nvidia driver during building). The command sequence for local building can be found in the README.

Once the packages are build, they are send to NVIDIA, which signs the packages with their key and generates and signs repositories, making them available to the public.

To note is the fact that this is all manual and takes a while on NVIDIA’s side (and ours). This of course is part of the reason why we don’t offer NVIDIA packages for Factory, our fast-rolling development repository.

What happened

What occurred for 13.1 is a typical case of “everything went wrong”.

Up until a few weeks before the release, the driver did not build against the Linux Kernel version 3.11. NVIDIA warned against the use of a patch for this problem created by third parties so the driver team did not have a running build. Due to a holiday, it took a while to get the packages build and pushed to NVIDIA. Unfortunately, by the time this was done, the holiday period at NVIDIA blocked progress for another week. Once the package was signed, it took the webteam at NVIDIA another week to get the repository published. It all added up to almost a month and brought quite some inconvenience for users eager to use their latest NVIDIA cards with the latest openSUSE.

About a week later, the openSUSE 13.1 NVIDIA drivers disappeared again from the nvidia servers for a day or so. We don’t know exactly what happened there, it might have simply been a server issue.

What we will do

The first and most obvious thing to change would be to improve coordination. The developers taking care of the NVIDIA packages should be made aware as early as possible about the release planning and a replacement in case for holidays should be available. We noted this in our 13.1 release report and will make sure that there will be a task in our task tracker for this for the next release. We also need to talk to NVIDIA about this to make sure that there, too, somebody can fill in for SUSE’s contacts.

But there are also thoughts on how to improve further. Some of the current ideas:

• To get drivers for Factory the process needs more automation as the driver may break on kernel or X changes
• We could try to open the process and work with community members to secure the process in case the SUSE folks are unavailalbe
• It would be nice if we could make NVidia to see benefit of working more on the driver in openSUSE, e.g. by doing some testing
• We could write some scripts that check regularly whether repo and packages are still available and in a valid state (meta data matches available RPMs)

We’ll have to see which of these we can implement, when and how. But rest assured that we will do what we can to prevent this in the future!

And the stats!

After a bit of a hiatus, we’re back with the numbers. Development has slowed down around new year and isn’t back to speed yet so the 10th spot is shared by quite a big group of people…

Spot	Name
1	Stephan Kulow
2	Denisart Benjamin
3	Tomáš Chvátal, Dirk Mueller, Michal Vyskocil
4	Hrvoje Senjan
5	Ciaran Farrell
6	Petr Gajdos
7	Lars Vogdt, Pascal Bleser
8	Jan Engelhardt, Charles Arnold
9	Andreas Stieger, Michal Marek, Niels Abspoel, Kyrill Detinov
10	Dinar Valeev, Bjørn Lie, Ulrich Weigand, Tobias Klausmann, Marcus Meissner, Alexander Graf, Robert Schweikert, Martin Vidner

Now that linux.conf.au is over, there has been a bunch of information running around about the status of kdbus and the integration of it with systemd. So, here’s a short summary of what’s going on at the moment.

Lennart Poettering gave a talk about kdbus at linux.conf.au. The talk can be viewed here, and the slides are here. Go read the slides and watch the talk, odds are, most of your questions will be answered there already.

cryptsetup as of 1.6, which shipped in openSUSE 13.1, is able to mount TrueCrypt volumes without the use of TrueCrypt code otherwise, which I previously noted is problematic due to it’s license, at least for inclusion in the openSUSE distribution.

Here, then, is how you mount it:

cryptsetup open --type tcrypt /var/run/media/username/volume_name encrypted_volume
mount /dev/mapper/encrypted_volume /mnt

For read only access, add --readonly and -o ro respectively. When done:

umount /mnt
cyrptsetup close encrypted_volume

See man 8 cryptsetup for all details and options.

Standa Horáček just posted information about a shared effort to translate the LibreOffice Getting Started Guide to Czech and Slovak Language. You can find more information also in the original post by Miloš Šrámek.

Why shared?

The Czech and Slovak languages are close enough for Google translate to do a very good job of translating one to the other. So you as a translator can choose if you work on the Czech or the Slovak version, and the other team will use the automatic translation. After that, they will just fix the parts where the machine translation failed, which will save a lot of work.

If you are interested, please help spreading the word. Or even better - help translating! :-)

Occasionally I may need to pipe STDERR somewhere, e.g. to less, grep, or head. It may not be immediately obvious how to accomplish this.

Read more »