KIPI plugin for screenshots.debian.net

by ⋅ 11 Comments

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.

Hello Planet Debian

by ⋅ Leave a Comment

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.

KSnapshot gets social

by ⋅ 35 Comments

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:

KSnapshot gains free-region capture

by ⋅ 31 Comments

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?

FOSDEM 2010

by ⋅ Leave a Comment

FOSDEM, the Free and Open Source Software Developers' European Meeting

Last year a lot of people were attending FOSDEM. This year, 10th anniversary and everything, it seems that very few people are I’m seeing very few blogs about people visiting Brussels on Febrary 6th and 7th and attending the largest Open Source conference in Europe.

Anyways, I am attending

I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting

I am staying at EC Hotel, very close to Gare du Midi. Cheap, convenient and free Internet.

NB: Comments on this blog do not work due to a hosting issue

KDE for Haiku

by ⋅ Leave a Comment

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

ANN: CModuler 1.0

by ⋅ Leave a Comment

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

Libraries and link interfaces

by ⋅ Leave a Comment

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

ACE in Debian

by ⋅ Leave a Comment

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.