My experiences with KMail2 in Debian

Thanks to the Qt/KDE team, specially to Maxy who has done most of the packaging and uploading, sid users are now enjoying KDE 4.10.5, including the new KDE PIM stuff that we have held out for the Wheezy release.

I started using KMail2 (inside Kontact) a few days after Wheezy's release, getting it from experimental. And I have to admit that I really like it, just like with KMail1.

But my upgrade did have some bumps on the road, so I'm sharing them here so you can now how I solved them.

Mail import worked as we were waiting: it did work. So it was really useful to hold back Kmail1 until this really worked.

Now, I had a problem with my hard disk: whenever KMail started, it would start accessing it without pause. There where two reasons (for what I could test, I haven't looked at the source to really see if there was some other oddity) for this: I had a nepomuk/virtuoso DB created quite some time ago and initial mail indexing.

The initial mail indexing takes lots of time. For 1GB of DIMAP I had to wait like 5 hours (yes, 5 hours) on a 5600 rpm disk to let it fully finish. My desktop machine, with a faster hard drive, took a little less.

As far as people told me, that should have been enough, but my disk kept crawling. So I remembered someone from the team saying something about people with early-created nepomuk/virtuoso databases will have some speed issues. Mine where more than that, buy trying was worth the shot.

I had nepomuk disabled since I tried it the first version due to this exact problem. So I closed my KDE session and removed the nepomuk/virtuoso data:

rm -r ~/.kde/share/apps/nepomuk/

Then I logged back in KDE and waited (again) the 5 hours to let nepomuk re index my mail, this time totally finishing after 5 hours. Starting from that point, I get some one or two minutes of disk trashing some times I log in (not always), but it's actually not that bad. And I heard that in KDE 4.11 this has been improved a lot, so I should see a better behavior from that point on.

Please understand that this was my trial-and-error fix, it may be possible that someone comes with a better solution :-)

Presenting qtchooser

A few days ago we the Qt/KDE team uploaded a new tool in the Qt ecosystem: qtchooser.

This tool is a wrapper tool used to select between different Qt versions. Of course, the first and easiest example is choosing between Qt4 and Qt5. But it doesn't end there: it can also be used to select a user's build of Qt.

To experienced Debian users, at first sight, it might resemble Debian's alternatives system. But it goes much further than that, allowing users (not sysadmins) to decide their defaults, and even adding new ones, user-wide. All this can be done using different methods like command line arguments, environment variables and configuration files.

Apart from all that, this is the recommended upstream way of managing Qt, being picked up by several (if not all) distributions, so it can easily be supported by upstream in their documentation.

My Qt4 package in Debian does not uses qtchooser, do I need to change anything?

No, we have tried to make things as smooth as possible. Your Qt4 packages should be safe. There will be more info on this later.

Debian/Ubuntu packages caching and mobile workstations

Not so long ago I read Dmitrijs' blog post on how to configure apt-cacher-ng to advertise it's service using avahi. As I normally use my laptop in my home and at work, and both networks have apt-cacher-ng running, I decided to give it a try.

I have been administering apt-cacher-ng for three networks so far, and I really find it a useful tool. Then, thanks to the aforementioned blog post, I discovered squid-deb-proxy. I don't use squid, so it's not for my normal use case, but some people will surely find it interesting.

But I found it's client package to be really interesting. It will discover any service providing _apt_proxy._tcp through avahi and let apt use it. But then the package wasn't available in Debian. So, I contacted Michael Vogt to see if he was interested in putting at least the client in Debian's archive. He took the opportunity to upload the full squid-deb-proxy, so thanks a lot Michael :-)

I then filled a wishlist bug against apt-cacher-ng to provide the avahi configuration for publishing the service, which Eduard included in the last version of it. So thanks a lot Eduard too!

tl;dr

You know only need apt-cacher-ng >= 0.7.13-1 and avahi-daemon installed on your server and your mobile users just need squid-deb-proxy-client. Then the proxy autoconfiguration for apt will just work.

One again, thanks a lot to the respective maintainers for allowing this into Jessie :-)

Gotchas

Yes, there are still some rough edges. On one of the networks I'm behind a proxy. While configuring my machine to use apt-cacher-ng's service as a proxy trough apt.conf, apt-listbugs would just work. But now, using the service as discovered by squid-deb-proxy-client, apt-listbugs just times out. Maybe I need to fill some other bug yet...

Qt 4.8.4 in experimental.

Since a few days we have Qt 4.8.4 (4:4.8.4+dfsg-3) in some archs of the experimental Debian archive. This release allows Qt4 to coexist with Qt5 while avoiding FTBFSs of current Qt4 packages in the archive.

So if you maintain a Qt4 app and want to check how it works with 4.8.4, you should be ready to go.

On the road to Qt5: declarative, graphicaleffects and svg in experimental.

Some more Qt 5 packages have entered Debian experimental:

• qtdeclarative
• qtgraphicaleffects
• qtsvg

Enjoy :-)

On the road to Qt 5: Qt 5 base, tools, jsbackend and xmlpatterns in experimental

The first Qt 5 packages have been accepted in Debian experimental.

What's there

• qtbase-opensource-src: lib[concurrent core dbus gui network opengl printsupport sql test widgets xml], examples, development packages and debug symbols.
• qttools-opensource-src: lib[qtlucene designer help], qdbus, development headers and debugging symbols.
• qtjsbackend-opensource-src: libqt5v8-5
• qtxmlpatterns-opensource-src
• qtchooser, which allows to select between Qt4 or Qt5 at build time.

To start building Qt 5 apps you will need to export QT_SELECT=qt5, install the package qt5-defaults or read qtchooser's man page. Note that exporting QT_SELECT has precedence over installing qt5-defaults.

What's not there

Architectures

AMD64 is already there because it's the arch used by maintainers to build the packages. i386 should be following as soon as buildds catch up. Most surely ARM-based archs will be there at some point too.

Other archs will need some love. Not strange, the Qt project supports amd64, i386 and ARM, but we Debian have normally prepared patches to make it build in other archs. And yes, we try to push them upstream for everyone's benefit. So, if you are missing it in your arch, take a look. You may be the one who enables Qt 5 in it :-)

GLES2 and Wayland

We don't have GLES2 or Wayland support yet. Building it will most probably break the desktop for people using proprietary video drivers (or at least I was told so). I'll surely provide non-official packages with GLES2/Wayland enabled to allow people testing it, but not soon.

This also means that we are not currently able to split X11 and framebuffer support. But we have time to work on it :-)

Non DFSGs compliant files

If you get the original source code tarball from Debian you will notice that it has dfsg in it's name. That means that we had to remove some non DFSG compliant stuff from the original tarball, namely:

• Every RFC.
• Three files used for testing the build, which are made of RFCs.
• Some fonts.

What's following

Other parts of Qt 5 are on the way. And remember, this packages would not have been possible if it weren't for the great Debian's pkg-kde team. My kudos to them.

On the road to Qt 5: Qt 4.8.4 and qtchooser uploaded to experimental

I have just uploaded Qt 4.8.4 to experimental. Apart from being the newest upstream release of the 4 series, it adds the basic support for coexisting with Qt 5. Because of this support it will need to go trough the NEW queue though, so we will need to be patient.

Developers will be interested in qtchooser, the tool that allows to switch between Qt 4 and 5 development apps. It has also been uploaded to experimental.

Of course, all this has been possible thanks to the efforts of the wonderful Qt/KDE team =)

Update: our efficacious FTP masters have already made Qt pass the NEW queue. Thanks a lot!