Tag Archives: OpenSource

Building multiple inter-dependent autotools based projects

One of the main reasons for this blog is documenting things for my future self. This post is one of these.

Building a HTTP REST API with C++ is a quite unique type of challenge, but doing it with libhttpserver takes a lot of the lower level protocol (read: HTTP and below) burden away from you, and lets you focus on the content part of your problem. This is what we did for a new project at work lately. But sometimes when working with external dependencies you hit some bugs and corner cases and have to dig into those projects.

Building libhttpserver is almost straight forward, if you had already built autotools based projects before. You’ll notice however it depends on a quite recent version of libmicrohttpd. So the task for hacking on libhttpserver is to build both libraries from source, without interfering with the rest of your system.

The usual way to build autotools based projects is like this:

% ./configure
% make

(It works exactly like this if building from an extracted source tarball. There’s another step in front of those, if you build from a Git working copy.)

Now after the naïve way to build libmicrohttpd, how can we tell libhttpserver to pick that up as a dependency? What I do is “installing” them both to the same place in a tree just for this purpose, and I use the --prefix option of ./configure for that with a directory I created before. So for libmicrohttpd from Git it would look like this:

% ./bootstrap
% mkdir -p build && cd build
% ../configure --prefix=/home/adahl/build/sysroot/http
% make
% make install

After that I have the following file tree:

% tree ~/build/sysroot/http
/home/adahl/build/sysroot/http
├── include
│   └── microhttpd.h
├── lib
│   ├── libmicrohttpd.a
│   ├── libmicrohttpd.la
│   ├── libmicrohttpd.so -> libmicrohttpd.so.12.60.0
│   ├── libmicrohttpd.so.12 -> libmicrohttpd.so.12.60.0
│   ├── libmicrohttpd.so.12.60.0
│   └── pkgconfig
│       └── libmicrohttpd.pc
└── share
    ├── info
    │   ├── dir
    │   ├── libmicrohttpd.info
    │   ├── libmicrohttpd_performance_data.png
    │   └── libmicrohttpd-tutorial.info
    └── man
        └── man3
            └── libmicrohttpd.3

7 directories, 12 files

So let’s try to build libhttpserver from Git master now:

% ./bootstrap
% mkdir -p build && cd build
% ../configure --prefix=/home/adahl/build/sysroot/http

But that gives:

checking for microhttpd.h... no
configure: error: "microhttpd.h not found"

So just giving the prefix is not enough. We need to pass some directories to preprocessor (for finding header files) and linker (to link against the other shared lib). You can do it like this:

% CPPFLAGS=-I/home/adahl/build/sysroot/http/include LDFLAGS=-L/home/adahl/build/sysroot/http/lib ../configure --prefix=/home/adahl/build/sysroot/http

Looking complicated? I bet. In our case we have only two projects, but what if there are even more? Gnu autotools has a nice feature which can help here though: Overriding Default Configuration Setting with config.site. In short: Put those preprocessor, compiler, and linker flags into a special file in your install tree, and ./configure will pick it up automatically and use the settings. In my case, I create a file /home/adahl/build/sysroot/http/share/config.site and put in the following:

test -z "$LDFLAGS" && LDFLAGS=-L/home/adahl/build/sysroot/http/lib
test -z "$CPPFLAGS" && CPPFLAGS=-I/home/adahl/build/sysroot/http/include

We can omit that stuff when calling ./configure now and everything is found and compiled and linked together. We can tell it’s picked up by the very first line of ./configure output:

% ../configure --prefix=/home/adahl/build/sysroot/http  
configure: loading site script /home/adahl/build/sysroot/http/share/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
…

So that’s all for today, I hope it will help my future self to look up what that magic file is called, where it must be placed, and where the documentation for that can be found.

Update: I make use of this mechanism in some of my CMake superbuild projects, e.g. in glowing-tribble-build.

An Instant Messenger Emoticon Theme Generator

For the regular readers of this blog this post is a little different, because it’s in English instead of German as usual. The reason is, this is an announcement of a tool I put together over the last months, which I consider interesting not only for German speaking users. So I hereby announce a smiley theme generator software for different instant messenger programs, but let’s start at the beginning.

In 2007 I took the smiley graphic files from a local internet community1 to build my own emoticon theme for the Jabber client Psi. This was basically putting together a description file and installing it and I described and announced it in this blog.2 Last year I started using Perl Template Toolkit 2 for building my personal homepage and thought this would be a great tool to build this smiley stuff in a more automatic way and for more than one instant messenger. Although I barely remember, it seems I also wrote about it in this blog.3

This year now I made some new friends with different messengers and started reworking the whole thing, especially to add some more messengers and to be able to use it for more graphic themes and here it is: a possibility to put your smiley graphics in a folder, write one description file for the mapping from smiley codes in the text (like :-) or :’-( and so on) to your graphic files, run the build script and have ready to install smiley theme packages for a bunch of different instant messenger programs. Let me quote the README file:

The purpose of this software is to create installable smiley iconset files for various instant messenger programs with a templating mechanism (using Perl Template Toolkit). This means smiley theme authors only have to provide the graphics and write one simple template file with the definitions which texts are related to which graphics, e.g. ‘:-)’ to the smiling graphics file. Add a little metadata, call the build script and you’re done. With help of the templates the definition file formats of the different messengers are created and a packing script does the rest of the magic. You don’t have to worry about a dozen different formats for definition files and packing conventions.

To use this software you need Subversion to check out the sources, an operating system running Perl and the Perl Template Toolkit 2, you must be able to execute shell scripts like from Bash or Zsh and have tar, gzip and zip ready. So every Unix or Linux like OS should work, on Microsoft Windows you could try your luck with cygwin, however I didn’t test this because I run Debian/GNU Linux. ;-)

Check out the tool with your preferred subversion client from https://www.antiblau.de/svn/penguineering_tools/trunk/im_emoticons/ and see the file README inside which contains all the necessary descriptions how to use the software. It is licensed under a BSD style license so you are free to use and change it to your needs. We also have a wiki page for it in our bugtracking system. You can also view the sourcecode and create tickets there.

For demonstrating the power of the templating approach I took the very nice (and free) smileys from simplesmileys.org and let the software build smiley themes for all the already supported instant messengers. You can download pre-build theme files for Adium, Kopete, Miranda, Pidgin and Psi from tools.penguineering.com.

Of course these five messengers are not all. If you have a template file for another one, don’t hesitate to contact me. Also if you have free smiley graphics and build a description file we could integrate in the subversion repository, I would be delighted if you just send it in.

In the hope this is useful for anybody else, have fun with it! :-)

  1. WebUni []
  2. WebUni Iconset für Psi []
  3. Mit Kanonen auf Smileys []

Farbige Nicknames in irssi

Als Fan von Programmen für die Konsole benutze ich natürlich irssi als IRC-Client. Für viele Funktionen, die im Standard-Umfang nicht vorhanden sind, gibt es Scripte, Tux hatte da ja auch selbst mal eins geschrieben und hier im Blog vorgestellt. Um den Chatverlauf einfacher verfolgen zu können, existiert beispielsweise das Skript nickcolor.pl, das die Nicknames der Nutzer einfärbt. Die Beschreibung in der Übersicht der Skripte ist kurz und knapp:

assign a different color for each nick

Das Skript bildet per Default einen simplen Hashwert über den Nickname, wählt anhand dessen eine Farbe aus und behält diese dann bei. Bei gleichen Nicks ist das dann immer die gleiche Farbe, was ja auch ganz sinnvoll ist.

Das Skript kann darüber hinaus noch mehr, um das rauszufinden, muss man aber einen Blick in den Quelltext werfen, entscheidend ist folgende Subroutine:

sub cmd_color {
  my ($data, $server, $witem) = @_;
  my ($op, $nick, $color) = split " ", $data;

  $op = lc $op;

  if (!$op) {
    Irssi::print ("No operation given");
  } elsif ($op eq "save") {
    save_colors;
  } elsif ($op eq "set") {
    if (!$nick) {
      Irssi::print ("Nick not given");
    } elsif (!$color) {
      Irssi::print ("Color not given");
    } elsif ($color < 2 || $color > 14) {
      Irssi::print ("Color must be between 2 and 14 inclusive");
    } else {
      $saved_colors{$nick} = $color;
    }
  } elsif ($op eq "clear") {
    if (!$nick) {
      Irssi::print ("Nick not given");
    } else {
      delete ($saved_colors{$nick});
    }
  } elsif ($op eq "list") {
    Irssi::print ("nSaved Colors:");
    foreach my $nick (keys %saved_colors) {
      Irssi::print (chr (3) . "$saved_colors{$nick}$nick" .
		    chr (3) . "1 ($saved_colors{$nick})");
    }
  } elsif ($op eq "preview") {
    Irssi::print ("nAvailable colors:");
    foreach my $i (2..14) {
      Irssi::print (chr (3) . "$i" . "Color #$i");
    }
  }
}

Hier wird für irssi ein Befehl /color definiert, den man mit folgendem ersten Argumenten bzw. weiteren Befehlen aufrufen kann:

  • save
  • set
  • clear
  • list
  • preview

Was kann man nun mit den einzelnen Befehlen anstellen? Ich gebe mal jeweils ein Beispiel mit der dazugehörigen Ausgabe, allerdings ohne Farben.

/color save gibt nichts weiter aus, speichert aber die mit set festgelegten Farben in der Datei ~/.irssi/saved_colors. Diese gespeicherten Farbzuordnungen werden beim Neustart von irssi bzw. Neuladen des Skripts wieder eingelesen.

/color set foo 7 gibt ebenfalls nichts aus, legt aber eine Zuordnung der Farbe 7 zum Nickname foo fest. 7 ist in dem Fall das, was in PuTTY gelb und auf der Konsole braun, in anderen Terminals eher orange aussieht. (Mehr zu diesem verwirrenden Thema in der englischen Wikipedia.)

/color clear foo löscht die gesetzte Farbe für foo wieder, gibt aber ebenfalls keine Statusausgabe zurück. Interessant werden dann die letzten beiden Funktionen.

/color list zeigt die aktuell gesetzten Zuordnungen in einer Liste an, bei mir sieht das derzeit so aus, die Namen sind in den Farben, wie sie auch im Chat auftauchen, die Zahlen dahinter sind erst bei dem Kopieren aus der Konsole zum Vorschein gekommen, geben aber die Farben wieder:

Mo|23:06:25 -!- Irssi: Saved Colors:
Mo|23:06:25 -!- Irssi: An-Tet (9)
Mo|23:06:25 -!- Irssi: Fabian (7)
Mo|23:06:25 -!- Irssi: Ge0rG (12)
Mo|23:06:25 -!- Irssi: IseeU (13)
Mo|23:06:25 -!- Irssi: Mupfy (3)
Mo|23:06:25 -!- Irssi: priority (3)
Mo|23:06:25 -!- Irssi: schlotze (4)
Mo|23:06:25 -!- Irssi: StarWarsFan (12)
Mo|23:06:25 -!- Irssi: StefanG (3)
Mo|23:06:25 -!- Irssi: SvenG (13)
Mo|23:06:25 -!- Irssi: thndr (12)
Mo|23:06:25 -!- Irssi: thunder (12)
Mo|23:06:25 -!- Irssi: zozi (6)
Mo|23:06:25 -!- Irssi: _MrTux_ (7)
Mo|23:06:25 -!- Irssi: _Tux_ (7)

Last not least kann man sich mit /color preview auch noch eine Liste der verfügbaren Farben ausgeben lassen:

Mo|23:19:39 -!- Irssi: Available colors:
Mo|23:19:39 -!- Irssi: Color #2
Mo|23:19:39 -!- Irssi: Color #3
Mo|23:19:39 -!- Irssi: Color #4
Mo|23:19:39 -!- Irssi: Color #5
Mo|23:19:39 -!- Irssi: Color #6
Mo|23:19:39 -!- Irssi: Color #7
Mo|23:19:39 -!- Irssi: Color #8
Mo|23:19:39 -!- Irssi: Color #9
Mo|23:19:39 -!- Irssi: Color #10
Mo|23:19:39 -!- Irssi: Color #11
Mo|23:19:39 -!- Irssi: Color #12
Mo|23:19:39 -!- Irssi: Color #13
Mo|23:19:39 -!- Irssi: Color #14

Alles in allem eine sehr praktische Erweiterung für irssi, wenn man weiß, wie man sie bedienen muss. ;-)

Freie Paketentwicklung für eisfair

eisfair ist grundsätzlich ein tolles Projekt. Die Idee ist toll, die Software ist toll und die Leute, die für das Projekt arbeiten auch. Neben reinem Eigenbedarf sind das alles Gründe, Zeit in das Projekt zu investieren. Aber es gibt immer zwei Seiten der Medaille und in solchen Projekten auch immer Sachen, die besser laufen könnten.

Ein Punkt, den ich persönlich bedauere ist die Offenheit des Projekts. Es hat sich historisch so entwickelt, dass es ein Kernteam von offiziellen Entwicklern gibt, diejenigen, die das Basis-System betreuen, das Kernel-Paket und diverse große Pakete wie Mail, Samba, MySQL, Apache usw. Das ist grundsätzlich erstmal nichts verkehrtes, man kann z.B. einfach nicht der ganzen Welt Schreibzugriff auf das zentrale Entwicklungs-Repository geben – Lesezugriff hingegen schon. Leider ist nicht nur dieses Repo der Öffentlichkeit verborgen, sondern es läuft auch viel Kommunikation an den öffentlichen Newsgroups vorbei. Dafür gibt es Gründe und die meisten Entwickler und Anwender sind mit der Situation so auch zufrieden.

Ich persönlich denke, dass ein öffentliches Repository (read-only ;-) ) und ein öffentlicher Bugtracker die Entwicklung und Popularität eines Projektes fördern, auch wenn die Entwickler dann möglicherweise mehr Zeit für Support aufbringen müssen und sie diese Zeit nicht für die Entwicklung zur Verfügung haben. Weil ich das so sehe und weil ich mit meinen eigenen Paketen natürlich machen kann, was ich will, gib es eben diese ab sofort frei – so frei wie in Freiheit und so frei wie in Freibier: http://www.lespocky.de/eisfair/

Jeder eisfair-Entwickler und -Nutzer kann also ab sofort meine Pakete nicht nur installieren, sondern den Quellcode auch abseits der Paketdateien direkt im Repository anschauen, auschecken, ändern, mir Patches schicken, Tickets anlegen usw. – wie man das von vielen anderen OpenSource-Projekten kennt. Ich weiß, dass ich keinen Ansturm erwarten darf und genau genommen erwarte ich eher, dass alles genauso ruhig abläuft wie vorher – aber es besteht die Möglichkeit und ich habe die leise Hoffnung, dass sich andere eisfair-Paketentwickler ein Beispiel nehmen und dem Projekt durch mehr Offenheit zu mehr Popularität und dadurch mehr Verbreitung, neuen Entwicklern und letztendlich mehr Qualität verhelfen werden.

:-)

Keysigning auf dem ersten Magdeburger Open-Source-Tag

Das sind ja gleich zwei Themen auf einmal… nun ich fang mit dem kürzeren an. Auf dem Magdeburger Open-Source-Tag 2008 wird es ein Keysigning-Event geben, leider ist die Ankündigung sehr versteckt ganz unten im Programm. Das ganze wird von Jens Kubieziel organisiert und der gute Mann bittet um Anmeldung für den Spaß bis zum 8.10. – also bis Mittwoch. Einfach eine (signierte ;-) ) Mail mit dem eigenen Fingerprint an Jens schicken, schon ist man angemeldet. Alles weitere auf der zuvor genannten Seite.

Der Open-Source-Tag selbst findet zum ersten Mal statt und wird von Stefan Schumacher organisiert. Unterschrieben ist das mit »Entwicklung trifft Anwendung«, die Themenschwerpunkte gehen in Richtung Erziehung, Bildung, Publishing. Natürlich sind auch ein paar thematisch anders gelagerte Vorträge im Programm. Jenes liest sich übrigens sehr interessant, man kann sich kaum zwischen den vier Tracks entscheiden.

Ich persönlich werde mir wohl die Vorträge anhören, die in Richtung LaTeX gehen und ich werde natürlich selbst auch auf der Keysigningparty zugegen sein. Dort sind übrigens auch ein paar Leute anwesend, die Punkte für CAcert vergeben können und wollen. ;-)

eisfair-Nostalgie

Angeregt durch eine Diskussion im IRC-Channel von eisfair, ist mir gerade klar geworden, dass ich mich jetzt schon etwa 5 (in Worten: fünf) Jahre lang mit dem System auseinandersetze. Wie hat das also damals angefangen?

Es muss irgendwann im Jahr 2003 gewesen sein, dass ich eisfair zum ersten Mal installiert und ausprobiert habe. Das Projekt selbst lief da schon einige Zeit, das Archiv der Newsgroup wurde jedenfalls im November 2001 eingerichtet. Ich hatte zu Beginn des Studiums ja noch den alten Pentium 233 MMX von meinen Eltern als Rechner benutzt, 2003 erstand ich bei eBay dann das ASUS TUSL2-C mit Celeron 1400, über das ich hier bereits schrieb. Das wurde dann Arbeitsrechner und aus den Teilen vom Basteln mit dem Fli4l-Router waren so einige Teile übrig, woraus dann ein Zweitsystem zusammengesteckt wurde. Irgendwann fand dann eisfair den Weg auf dieses Testsystem, zunächst wohl für Webentwicklung oder Spielerei oder ähnliches. Damals war noch Kernel 2.2.x Stand der Dinge (für eisfair) und es gab auch keine Install-CD. Meinen Promise Ultra 66 bekam ich erst mit dem ersten Testkernel 2.4.23 und manuellem Anlegen von /dev/hde? zum Laufen, das base-Paket war glaube ich noch bei 1.0.3 oder so.

Anfang 2004 waren ein paar Freunde für eine kleine private LAN-Party zu Besuch. Ich spielte immernoch unter Windows 98 und der eine oder andere wird sich erinnern, dass es da mit vernünftigem Multitasking, noch dazu aus nem Spiel raus, nicht soweit her war. Mal eben zum ICQ-Client wechseln und zurück gefährdete massiv die Stabilität des Spiels, warum also nicht den ICQ-Client auf dem zweiten Rechner laufen lassen? Da eisfair nun ein Serversystem ohne grafische Oberfläche ist, kamen da nicht viele Clients in Frage, genau genommen nur einer: micq.

Die damals verfügbare Version hatte Probleme mit der damals aktuellen Version vom ICQ-Protokoll und so fragte ich den damaligen Maintainer vom micq-Paket, Roman Schließmeyer, nach einem Update:

ich habe im Moment leider keine Zeit um die Pakete zu pflegen, deswegen werde ich auch kein Update des micq Paketes durchführen. Wenn du magst kannst du das gerne übernehmen,

So kam dann eins zum anderen und am 12.04.2004 veröffentlichte ich mein micq-Paket in Version 1.0.1. Warum? Eigenbedarf! Genau darum ging es nämlich im eingangs erwähnten Chat. Eine der größten Antriebskräfte im Open-Source-Bereich ist Eigenbedarf. Das gilt für meine eisfair-Pakete ebenso wie für IMPULS und es gilt nicht nur für mich selbst. Viele Open-Source-Entwickler arbeiten an »ihrer« Software, weil sie sie selbst einsetzen und benutzen wollen. Natürlich ist das nicht der einzige Grund, aber ein sehr wichtiger, das sehe ich bei eisfair im Prinzip täglich. Das Zitat zeigt aber auch noch etwas anderes: eisfair ist ein reines Freizeitprojekt und Zeitmangel ist bei den Entwicklern praktisch obligatorisch – damals wie heute.

Ende 2005 bekam ich dann die Einladung dem frisch gegründeten Test-Team beizutreten, im letzten Jahr war ich zum ersten Mal auf dem Entwicklertreffen. Seit 2003 ist viel passiert in der Entwicklung, ich hatte ja schon an der einen oder anderen Stelle mal was angedeutet. Da ließe sich auch noch viel mehr schreiben, aber das hebe ich mir mal für einen späteren Beitrag auf. ;-)

Songbird: Music Player für Windows

Meine Suche nach einem Amarok-Äquivalent für Windows hat ein Ende gefunden!

Ich bin heute zufällig über einen Mozilla-basierten Music-Player für Windows gestolpert: Songbird.

Die Playlist sieht ähnlich aus wie beim Amarok (oder iTunes, das sich auf meinem Rechner aber nicht gut benimmt), ich bekomme die für mich interessanten Meta-Informationen angezeigt und es gibt – wie man es von Mozilla gewohnt ist – eine Menge addons. Zum Beispiel, um bei last.fm zu scrobbeln.

Einziges Manko: Das Programm lässt sich nicht in die Traybar minimieren – aber da finde ich sicherlich auch noch etwas.

Browser-basiertes "Getting Things Done" mit MonkeyGTD

Weil sich bei mir im Job immer mehr Aufgaben und Verantwortungsbereiche anhaeufen und das Jonglieren damit zur zunehmenden Qual wird, hab ich mich im Internet auf Softwarehilfen zur Implementierung von David Allens “Getting Things Done”-Methode umgesehen. Mein Favorit war schnell gefunden: MonkeyGTD, ein browser-basiertes Tool auf Basis von TiddlyWiki.

Die Vorteile:

  • browser-basiert (funktioniert prima mit Firefox) und damit plattformunabhaengig
  • Nur eine einzelne (zugegeben grosse) HTML-Datei, brauch lediglich einen Javascript-faehigen Browser
  • Datei kann lokal gehalten werden oder auch auf tiddlyspot.com oder eigenem Webserver online verfuegbar gemacht werden
  • fuer mich sehr angenehme Verwaltung der einzelnen Arbeitseinheiten von GTD (Actions, Projects, Areas)
  • einfache Bedienung durch Tiddlers (Miniseiten innerhalb des TiddlyWikis)
  • MonkeyGTD erstell beim Speichern selbst ein Backup von sich, dass nur noch manuelle archiviert werden muss
  • Backups und Upgrades koennen scheinbar ueber einen vorhandenes Plugin jeweils ohne viel Aufwand mit der aktuellen Version zusammengefuehrt werden (habe ich noch nicht probiert)

Einziger Nachteil, den ich bisher gefunden habe, ist, dass die Backupdateien mit der Zeit sehr viel Platz beanspruchen (bei knapp 500 KB pro einzelnem Backup).

Mein MonkeyGTD befindet auf einem USB-Stick, ich setze es seit knapp drei Wochen taeglich sowohl im Buero als auch daheim ein  (jeweils mit Firefox) und ich bin sehr gluecklich damit. Mein Arbeitstag mit seinen vielen Aufgaben und auch Ablenkungen wird zunehmend ueberschaubarer und handhabbarer, weil ich nichts mehr im Kopf behalten muss, ich deswegen mehr schaffe und ich trotzdem nichts vergesse.