Ubuntu Jaunty reached end of support life last October and apparently packages have been removed from Launchpad PPAs too.

Given that it is impossible for me to build binary packages for Jaunty in the Wt PPA due to missing packages, the Wt PPA will no longer provide new packages for Ubuntu Jaunty. The last stable version of Wt for Jaunty is 3.1.6.

On April 2011, Karmic reaches end of support, and Hardy reaches end of support for desktop (support for servers will be available until April 2013). I will provide Wt packages for those distributions while Launchpad supports them.

Packages for 3.1.7a are already available for Ubuntu Maverick, Lucid and Karmic, as usual. Packages for Debian Lenny (in the Wt OBS repository) and Ubuntu Hardy packages will be ready in a few hours. Source packages for Debian Sid are available from mentors.

The screenshots.debian.net site is a public repository of screenshots taken from applications contained in the Debian GNU/Linux distribution and its derivates like Ubuntu.

It was created by Cristoph Haas to help people get an impression of what a certain software will look like on your desktop before you install it. Everybody can take screenshots and upload them through the upload form. So far there are about 3100 screenshots, which is actually a small number if you consider Debian Squeeze contains about 15000 source packages

After I hacked a bit on KSnapshot, the KDE snapshot tool, Sune asked me to add an export to screnshots.debian.net command. I had not thought of it before but that looked like a great idea, it would make the process or taking-screenshot, visit-upload-form, upload-each-screen so much easier!. So I started to develop my first KIPI plugin.

Here is the resulting Debian Screenshots plugin, as you would use it in KSnapshot:

Being a KIPI plugin, it is available not only from KSnapshot but also from Digikam, Gwenview and the other applications which support KIPI plugins:

Which makes me think: what about having a debshots (the software powering screenshots.debian.net) installation over at kde.org and have screenshots for all the KDE applications? What do you think? Promo team? Sysadmins? Setting it up shouldn’t be difficult: I’m no Python or Pylons expert (I’m more of a Ruby and Wt C++ guy 🙂 and got it running in a VM in an afternoon, even solving some SQLAlchemy 0.6 issues.

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

Haiku is a free open source operating system compatible with BeOS. I’d say the BeOS community is the new Amiga community: they love their platform and will endure as many difficulties as necessary as long as they are able to run BeOS/Haiku.

A few months ago, Qt4 was ported to BeOS/Haiku. That’s great news because it means we Qt4 developers can now target a new platform (did I say CMake is also available for Haiku?). Arora quickly followed.

Now, KDE 4 is also available for Haiku. Freezing cool.

By the way, OS/2 is another of those everybody-thought-they-were-dead platforms which are being infused new software thanks to ports of Qt4 (they need money to complete the port, donate!) and CMake

Please note I am not a KDE-on-Haiku or KDE-on-OS/2 developer. I know zero of Haiku/BeOS and I forgot almost all I knew of OS/2 programming.

PS: Comments here do not work due to hosting manfunction

CModuler is a CMake module generator. I was fed up with copy & paste, search & replace over and over again 90% of the time.

Version 1.0 (AKA “CModuler Meta”) provides only very limited functionality: it will create finders (modules of the form FindXXX.cmake) for libraries consisting of only 1 library. CModuler-generated modules support debug/release configurations.

Here is an example of a CModuler-generated module for finding Sqlite3: FindSqlite3.cmake

You can download CModuler from Gitorious

Like CMake, CModuler is licensed under the BSD license

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

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