My name is Pau and I am a software developer at Arisnova, a Spanish company specialized in Linux and Windows software development for the supervision and control (SCADA) of industrial environments.

In Debian, I am the maintainer of:

  • witty, AKA Wt, a widget-centric C++ library for developing interactive web applications, with an API much like Qt‘s
  • libmsn, a library for connecting to Microsoft’s MSN Messenger service
  • (co-maintainer) ACE, the Adaptative Communication Environment, an object-oriented framework that implements many core patterns for concurrent communication software

I also happen to be a KDE developer. How’s this related to Debian? You’ll find very soon.

When I blogged about the freehand region capture feature I added to KSnapshot a couple of weeks ago, it caught me by surprise that post quickly turned into a wishlist for KSnapshot. I didn’t expect people missed anything in our good old KSnapshot after so many years of development.

Some of the feature requests were very difficult to implement (antialiasing in freehand capture; drop me an e-mail if you know how to do without redrawing the whole selection polygon)[DONE thanks to kdepepo, will be in 4.6] but most of them are pretty reasonable, in my opinion: include mouse pointer, annotations, send to mail, send to Facebook, print, etc.

I quickly started looking into how to e-mail the picture, how to print it, how to send to Facebook, etc, which seemed quite some work. And then Aleix pointed me to a very easy and quick way of getting all those and more in KSnapshot: the KIPI plugins Gwenview, Digikam and others are using.

This is the result:

Now you can send you ksnapshots to Facebook:

Or print your screenshot:

From time to time I need to take a screenshot of some application or a part of my desktop. The obvious solution in KDE is KSnapshot, which is perfect if you want a rectangularly-shaped picture.

Unfortunately, sometimes I want to capture something not rectangular, something which looks more like an ellipse, or even some odd shape. That means I have to take the snapshot, go to Krita, edit and save. Four steps. Ugh.

No more!

I have just committed free-region capture to KSnapshot, which makes possible to capture arbitrary shaps:

Now you can capture only the nice logo from our friends over at the Libre Software World Conference, no need to take a rectangle with a lot of background color:

And this would be the result:

Isn’t it nice?

Wt (pronounced ‘witty’) is a C++ library and application server for developing and deploying web applications. The API is widget-centric and offers complete abstraction of any web-specific application details. You could say it’s like Qt but for the web.

I have been packaging Wt for Debian and Ubuntu, and providing backports for Ubuntu, for years now.

So far, Wt packages were just one more citizen amongst the many other packages in my PPA. Invariably, I received complaints and suggestions pointing in the direction of chaos and havoc: installing Wt from my PPA and running apt-get full-upgrade meant many packages were updated (just try and do that on a Hardy: half the distribution is upgraded :-)). Some of the updated packages were as essential as g++, Boost, Qt, Samba, ALSA and GStreamer. While I seldomly broke anything, I understand people would be worried for their systems, especially people running servers.

From today on, Wt packages will no longer be available from my PPA but from a new, dedicated repository: the Wt PPA.

The Wt PPA contains only the essential packages required to install Wt on a basic system. You do not need to enable backports, proposed or anything: just add the Wt PPA repository to your out-of-the-box Ubuntu and install the libwt* packages. Currently, packages for Hardy, Jaunty, Karmic and Lucid are available. Packages for Maverick will be available as soon as bug 647597 is fixed.

Click here to go to the Wt PPA

I hope you enjoy it.

PS If you need packages for Debian Lenny, check my OpenSuse Build Service repository. Read more at the Wt wiki

Today I received an e-mail from Vincent about some strange warnings dpkg-shlibdeps was showing when building from source the Wt packages on Debian:

dpkg-shlibdeps: warning: symbol pthread_join used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_key_delete used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_init used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_setspecific used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_settype used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_detach used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_destroy used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_getspecific used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_key_create used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_settype used by debian/witty/usr/lib/libwt.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_init used by debian/witty/usr/lib/libwt.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_destroy used by debian/witty/usr/lib/libwt.so.2.2.4 found in none of the libraries.

He asked if I knew what was that (a dpkg-shlibdeps bug?) and what did it mean, it case it was correct.

That error means pthread_join, pthread_mutexattr_destroy, etc are used by libwt.so and libwthttp.so but those libraries are not linked to libpthread.so by Wt’s buildsystem. I. e. the linker command line when putting libwt.so and libwthttp.so together does not have a “-lpthread“.

Is dpkg-shlibdeps right about that? Yes, it is:

  • libwt.so uses libpthread.so in the XML library (Wt bundles the sources ot MiniXML and compiles them as part of libwt.so)
  • libwthttp.so uses libpthread.so in WServer.C

So, if the buildsystem is not linking libwt.so and libwthttp.so to libpthread.so, why doesn’t linking fail with “unresolved reference” errors? It’s because of the link interface in Boost is wrong.

Link interface? What’s that?

If you are reading me via Planet KDE, you probably know what I’m talking about because Alex has written about this. If you don’t know what I’m talking about, keep reading.

Say you have libA.so, libB.so and libC.so.

  • libA.so does not link to any external library, save for glibc
  • libB.so links only to libA.so and glibc
  • libC.so links only libB.so and glibc

When you run ldd libC.so, what will you get? This?

$ ldd libC.so

linux-gate.so.1 => (0xb7f66000)
libB.so => /usr/lib/libB.so
libc.so.6 => /lib/tls/i686/cmov/libc.so.6
/lib/ld-linux.so.2 (0xb7f67000)

or this?

$ ldd libC.so

linux-gate.so.1 => (0xb7f66000)
libB.so => /usr/lib/libB.so
libA.so => /usr/lib/libA.so < ======= libc.so.6 => /lib/tls/i686/cmov/libc.so.6
/lib/ld-linux.so.2 (0xb7f67000)

The answer is you’ll see the second output: libC.so is linking to libA.so, although when you linked it you only did gcc -o libC.so libC.c -lB (no -lA, so no explicit linking to libA.so):

libC -> libB -> libA

Why is that? Why is libA.so being dragged to libC.so? It’s because of what we call “link interface”

As libC.so links to libB.so, by default, libC.so‘s ELF header will have every library libB.so links to as NEEDED: libB.so‘s dependencies have been transitively passed into libC.so! Usually that’s not what you want, therefore it is possible to specify a “reduced link interface”: given that libA.so is only used internally in libB.so (users of libB.so do not need to use any type or function defined in libA), there is no need to link libC.so to libA.so.

Therefore:

  • As libwt.so and libwthttp.so link to libboost_thread-mt.so from Boost
  • In Debian, Boost is compiled with threads (i. e. it links to libpthread.so)
  • Boost does not publish a reduced link interface but the full link interface (i. e. every dependency of Boost is transitively passed into applications/libraries using Boost)

… even though libwt.so and libwthttp.so were not linking to libpthread.so explicitly, they were picking libpthread.so from libboost_thread-mt.so and no linkage error happened. If libboost_thread-mt.so would not export libpthread.so (it should not!), linkage of libwt.so and libwthttp.so would have failed and the authors of Wt would have noticed the bug in their build system.

While this is not a critical issue, it makes your application/library load slower, because it needs to resolve and load the NEEDED libraries.

Please note this discussion is valid for any operating system, including Windows and Mac OS X.

If you use CMake as your build system and you want to adopt a reduced link interface, take a look at the CMake docs for TARGET_LINK_LIBRARIES, particularly the LINK_INTERFACE_LIBRARIES section:

Library dependencies are transitive by default. When this target is linked into another target then the libraries linked to this target will appear on the link line for the other target too. See the LINK_INTERFACE_LIBRARIES target property to override the set of transitive link dependencies for a target.

target_link_libraries( LINK_INTERFACE_LIBRARIES
[[debug|optimized|general] ] …)

The LINK_INTERFACE_LIBRARIES mode appends the libraries to the LINK_INTERFACE_LIBRARIES and its per-configuration equivalent target properties instead of using them for linking. Libraries specified as “debug” are appended to the the LINK_INTERFACE_LIBRARIES_DEBUG property (or to the properties corresponding to configurations listed in the DEBUG_CONFIGURATIONS global property if it is set). Libraries specified as “optimized” are appended to the the LINK_INTERFACE_LIBRARIES property. Libraries specified as “general” (or without any keyword) are treated as if specified for both “debug” and “optimized”.

NB: The comments in this blog do not work due to a hosting issue

Are you a developer and use ACE, TAO, CIAO? Do you use and/or deploy to Debian, Ubuntu or any other Debian-based distribution?

If you answered affirmatively to those two questions, you have probably noticed Debian still ships ACE 5.6.3, which is 18 months old. The reason is twofold:

  • ACE is a complex beast. The source tarball generates 59 binary packages for 5.6.3, and that’s only to increase in the latest version (5.7.4).
  • The only Debian developer working on ACE, Thomas Girard, is too busy at the moment. He did a great job maintaing ACE for years but now it’s time for others to help him.

Therefore, if you use ACE and Debian directly or indirectly, please step in and help me get the latest ACE in Debian. I’m half done but I’m having trouble with autotools (the autotools build system in ACE seems to need some love, I’m probably moving to the traditional build system) and I do not know where to put some of the new libraries (DAnCE, etc).

NB: The comments in this blog do not work due to a hosting issue, please contact me directly by e-mail: or subscribe to the pkg-ace-devel mailing list.

A couple of weeks ago, I said I would not be backporting the latest versions of Glib2, Gtk+, GStreamer, etc to Hardy.

Today I decided I needed a newer GStreamer on my Hardy machine (where I build and use KDE from trunk almost daily) because I wanted to use libQtGstreamer.

As I expected, this requires major surgery to Hardy. Two prominent components of Hardy, ffmpeg and PulseAudio, require relatively recent versions. I don’t even know if it’s possible to build them due to limitations in Hardy’s kernel V4L2 support. In addition to that, I’m leaving on holidays to London and I won’t be able to work on this until next Wednesday.

Summary: IF YOU USE MY PPA AT THIS MOMENT, IT WILL BREAK YOUR HARDY INSTALLATION! BE VERY CAREFUL IF YOU RUN APTITUDE FULL-UPGRADE! I don’t like having the PPA broken for so long but I have to wake up in 4 hours and I really need to get some sleep.

E-mail arrived a couple of days ago from Will E. from School District #33 in British Columbia, Canada:

Also thank you for all of the work you have put into your package archive. (we use your archive here in our school district on almost 1000 Kubuntu workstations and servers)

Wow, thank you! These e-mails are really motivational and encouraging!