Qt in Debian: using Qt4 and/or Qt5 in your packages

Hi everyone! We now have both Qt4 and Qt5 in the archive. Those using Qt4 should not need to make any changes in their packages, although you can be extra-safe with a few steps. Don't rush, just read below.

Note 2014-12-12: the current official doc is available here.

Some background

Sune took the time some months ago to consult upstream for a sane way to allow both SDKs to coexist without us distros having to reinvent the wheel choosing which tools have to be in use in each case.

After a long discussion, upstream decided to write qtchooser (already in the archive) to be able to select between Qt4, Qt5 and even special user's cases like cross-platform builds.

So instead of going trough Debian's alternatives as we did with Qt3/Qt4, we will make use of this new tool.

My package uses Qt, how should I proceed?

There are many ways of choosing either of the versions of Qt:

- Using any qtchooser method (preferred):

  * Exporting QT_SELECT with 4, qt4, 5 or qt5 as a value in debian/rules.
  * Call the tool using the '-qtx' parameter, where x can be replaced with any of the options above.

- Build-depending on qt4-default or qt5-default. You can't B-D on both of them, as they can't coexist. Don't build depend nor depend on qt4-default and/or qt5-default.

It is good to notice that:

- any qtchooser method will take precedence over build depending on qtX-default.
- If you export XDG_CONFIG_DIRS it will ignore the default paths to qtchooser's configs we setted up in the packages.

We have also provided qt4-[arch-triplet] and qt5-[arch-triplet] options for special cases.

Once again, if you are already using Qt4, there is no need to rush. See below.

Can is use both Qt4 and Qt5 in my package?

You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries compiled against one or the other. For example, your source package foo could provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules and/or build system accordingly to achieve this. At the time of this writing I don't know of any examples yet.

So are you going to break the archive with a big transition?

No, we have done our best to avoid having to make any changes to existing Qt4 packages. Qt tools should default to Qt4 except if overriden by any method described above.

My package uses Qt4, can I leave it as it is?

While there is no need to apply the changes in this case, explicitly setting the Qt version will surely not hurt at all. But don't rush ;-) See note 2014-11-06

Note 2014-05-07: exporting XDG_CONFIG_DIRS is now safe.
Note 2014-07-26: We decided it's not good to build depend or even depend on qt4-default or qt5-default.
Note 2014-11-06: Qt4 will get removed in Jessie+1.
Note 2016-02-08: fixed doc URL.

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.