Benutzer:Tijuca

Thunderbird/Icedove für Git und Mailinglisten anpassen

Thunderbird bzw. Icedove sind in der default Einstellung nicht wirklich dazu geeignet um Mails an Mailinglisten zu versenden. Dies hat seinen Grund darin wie der Textinhalt der Mail gestaltet wird.

Auf OSS Mailinglisten werden Mails wegen der besseren Lesbarkeit im Textformat mit einem Umbruch am 72. Zeichen erwartet. Nur wenige MLs wandeln die Mails vor dem Versand um. In der Grundeinstellung versendet TB/ID aber Mails im HTML Format. Diese und die anderen Eigenschaften kann man aber anpassen.

Umstellen auf "nur Text"

Dies lässt sich Erreichen in dem geprüft wird ob in den Konteneinstellungen unter "Verfassen & Adressieren" kein Haken bei "Nachricht im HTML-Format verfassen" gesetzt ist.

Umstellen des Textflusses

Ebenfalls benutzt per default TB/ID "fliesenden Text". Dies lässt sich in den erweiterten Eigenschaften verändern.
Dazu muss in den Einstellungen vom Program (Unter Windows unter "Extras - Einstellungen", unter Linux unter "Bearbeiten - Einstellungen" zu finden) im Fenster "Erweitert" Reiter "Allgemein" der Button "Konfiguration" geöffnet werden.

In den erweiterten Einstellungen muss der Eintrag "mailnews.send_plaintext_flowed" gesucht und auf "false" gestellt werden. Dies geschiet durch einen Doppelklick auf diese Zeile.

optionales Installieren Plugin "Toggle Word Wrap"

Wenn man zwischen dem Fließtext und umgebrochenen Text wechseln muss oder will kann man sich das Plugin "Toggle Word Wrap" von Mozilla Plugins installieren. Damit kann man dann bequem zwischen beiden Textflussarten umschalten.

optionales Installieren Plugin "Colored Diffs"

Um Diffs bzw. Patches für das menschliche Auge lesbarer darzustellen kann man sich das Plugin "Colored Diffs" von Google Code nach installieren. Damit werden Diffs auf Wunsch ähnlich dargestellt wie man das vom Git Webfrontend, Trac, ViewCS oder WebSVN kennt.

Codeblocks Installation

der bequeme Weg (bevorzugt!)

Jens Lody ist Developer bei C::B und stellt Debianpakete als 'stable releases' als auch als 'nightly build' zur Verfügung. Zum Installieren der 'stable releases' per apt-get geht man wie folgt vor.

• Superuser werden

$ sudo su

• Apt Eintrag erstellen, Quellen updaten, es erscheint eine Fehlermeldung die man nach dem Update der Quellen durch das Importieren des angemahnten Keys beseitigen kann

# für die stable Releases
# echo -e "deb http://apt.jenslody.de/stable squeeze main\ndeb-src http://apt.jenslody.de/stable squeeze main" > /etc/apt/sources.list.d/codeblocks.list
# apt-get update
...
# für testing und experimental, Achtung! hier muss manuell nach gearbeitet werden
# echo -e "deb http://apt.jenslody.de/testing wheezy main\ndeb-src http://apt.jenslody.de/testing wheezy main" > /etc/apt/sources.list.d/codeblocks.list
# apt-get update
...
W: GPG-Fehler: http://apt.jenslody.de any Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY C96E627C6EEB25C9

• Importieren des Keyrings von Jens Lody

# apt-get install jens-lody-debian-keyring

• Optional (im Beispiel für 64bit!)!!! wenn man die nightly builds verwenden will müssen zwei Pakete von Hand installiert werden da selbst in Squeeze nur die älteren Varianten sind (im Beispiel für 64bit)

# cd /tmp
# wget http://apt.wxwidgets.org/dists/squeeze-wx/main/binary-amd64/libwxbase2.8-0_2.8.12.1-0_amd64.deb && dpkg -i libwxbase2.8-0_2.8.12.1-0_amd64.deb
# wget http://apt.wxwidgets.org/dists/squeeze-wx/main/binary-amd64/libwxgtk2.8-0_2.8.12.1-0_amd64.deb && dpkg -i libwxgtk2.8-0_2.8.12.1-0_amd64.deb

• Quellen erneut updaten

# apt-get update

• nun Codeblocks (und die deutsche Dokumentation installieren)

# apt-get install codeblocks codeblocks-doc-de

Die hervorragende Dokumentation ist nun unter file:///usr/share/doc/codeblocks-doc-de/html/main_codeblocks_de.html zu finden.

• Installation von Plugins wie z.B. DoxyBlocks, Valgrind, ..., gibt es aber nur vollständig in den nightly builds! (und wieder User werden gfs.)

# apt-get install codeblocks-additional codeblocks-additional-common codeblocks-contrib codeblocks-contrib-common
...
# exit

der manuelle Weg mit dpkg

http://www.codeblocks.org/downloads/26

wget http://download.berlios.de/codeblocks/codeblocks-10.05-1-debian-amd64.tar.bz2
tar xvjf codeblocks-10.05-1-debian-amd64.tar.bz2

$ dpkg -s codeblocks
Package: codeblocks
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 5792
Maintainer: Jens Lody <jens@codeblocks.org>
Architecture: amd64
Version: 10.05-1
Depends: libatk1.0-0 (>= 1.20.0), libc6 (>= 2.7-1), libcairo2 (>= 1.2.4), libcodeblocks0 (= 10.05-1), libgcc1 (>= 1:4.1.1), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.12.0), libpango1.0-0 (>= 1.20.3), libstdc++6 (>= 4.1.1), libwxbase2.8-0 (>= 2.8.10.1), libwxgtk2.8-0 (>= 2.8.10.1), codeblocks-common (= 10.05-1)
Recommends: gcc | g++, gdb, codeblocks-contrib (= 10.05-1)
Suggests: libwxgtk2.8-dev, wx-common, xterm
Description: cross-platform integrated development environment (IDE)
 Code::Blocks is the open-source, cross-platform Integrated Development
 Environment (IDE).
 It is based on a self-developed plugin framework allowing unlimited
 extensibility. Most of its functionality is already provided by plugins.
 Plugins included in the base package are:
    * Compiler frontend to many free compilers
    * Debugger frontend for GDB (and CDB for windows platforms)
    * Source formatter (based on AStyle)
    * Wizard to create new C++ classes
    * Code-completion / symbols-browser (work in progress)
    * Default MIME handler
    * Wizard to create new Code::Blocks plugins
    * To-do list
    * Extensible wizard based on scripts (for creating new projects/targets/etc)
    * Autosave (saves your work in the unfortunate case of a crash)
 It\'s a svn-download and may contain bugs.
Homepage: http://www.codeblocks.org

sudo apt-get install libwxgtk2.8-0
sudo dpkg -i libcodeblocks0_10.05-1_amd64.deb codeblocks-common_10.05-1_all.deb
sudo dpkg -i codeblocks_10.05-1_amd64.deb

Lokalisierung von Codeblocks

HINWEIS:

Die Lokalisierung von Codeblocks ist unvollständig und wird es auch immer sein! Wer diese oder auch eine andere IDE einsetzen sollte wirklich prüfen ob er eine deutsche Oberfläche der GUI benötigt. Viele Begriffe aus dem Developer und Softwarebereich sind englisch und lassen sich nur bedingt übersetzen. International üblich ist eine englische GUI. Dies hilft Missverständnisse zu vermeiden.

Die Standardinstallation von Codeblocks (C::B) ist wie für eine IDE üblich mit einer englischen GUI. Codeblocks bietet aber auch Lokalisierungen an. Diese kann man auf der Launchpad Projektseite herunterladen bzw. anfordern. Dazu benötigt man allerdings einen Account bei Launchpad denn nur angemeldete User können den Downloadhinweis sehen.

Wenn man sich eingeloggt hat kann man entweder die .po oder die fertig Übersetzte .mo Datei von der Lauchpad Webseite anfordern. Die .po Dateien sind die eigentliche Lokalisierungen in die die passenden Übersetzungen eingetragen werden. Damit kann aber Codeblocks nichts anfangen, da es die Lokalisierungen im Binärformat, also als Datei .mo erwartet. Wer also die .mo Datei herunterladen will kann folgende Schritte überspringen.

Egal welchen Dateityp man auf der Launchpad Webseite anfordert, man erhält einen Downloadlink in dem ein Archiv launchpad-export.tar.gz liegt. Dieses kann man mit

$ tar xvf launchpad-export.tar.gz

in einem temporären Ordner entpacken kann. In diesem findet Ihr, wenn Ihr .po angefordert habt nun die entsprechenden Quelldateien mit den jeweiligen Übersetzungen. Für die deutschen Übersetzungen entsprechend codeblocks-de.po. Diese Datei kann man mit POEdit oder auch mit jedem anderen Editor bearbeiten.

Damit man das Binärformat .mo erhält muss man allerdings die .po Datei noch mit msgfmt übersetzen. Das Zielformat muss allerdings so aussehen: de_codeblocks.mo Der Aufruf ist daher folgender:

$ msgfmt codeblocks-de.po -o de_codeblocks.mo

Diese Datei muss nun in den Ordner /usr/share/codeblocks/locale/de_DE. Da dieser nicht vorhanden ist muss dieser erst erstellt werden.

$ sudo mkdir -p /usr/share/codeblocks/locale/de_DE

In diesen Ordner nun die eben erstellte de_codeblocks.mo kopieren.

$ sudo cp de_codeblocks.mo /usr/share/codeblocks/locale/de_DE

Nach dem nächsten Neustart sollte C::B nun mit deutschen locales starten.

Wer auf der Launchpad entsprechend die .mo Dateien angefordert hat muss sich die codeblocks-de.mo entpacken, umbenennen und in den benannten Ordner kopieren.
Wer sich das selber Übersetzen und gfls. das Anmelden auf Launchpad ersparen will findet hier eine fertige de_codeblocks.mo. Oder folgendes mit root Berechtigungen aufrufen.

mkdir -p /usr/share/codeblocks/locale/de_DE && cd /usr/share/codeblocks/locale/de_DE && wget http://62.75.162.37/misc/cs/de_codeblocks.mo

post-receive Hook auf einem Git Server

Für ein post-receive Hook Script gibt es zahlreiche Varianten. Es gibt zahlreiche Scripte in Form von einen oder mehreren Shell oder Perl Scripten bis hin zu Ruby Scripten.

Ich habe mich für http://www.icir.org/robin/git-notifier/ entschieden, welches ein Python Script ist. Gerade aus diesem Grund. Es ist nur ein Script und dazu aus Python, so das ich es bei Bedarf anpassen kann.

Das Python Script kommt nach /usr/local/bin. Der Hook post-receive im Hooks Verzeichnis des Repositorys ist mehr oder weniger ein einfacher Aufruf von git-notifier.

#!/bin/bash

/usr/local/bin/git-notifier --mailinglist=projekt-foo@projekt-foo.org \
                            --emailprefix="[git] projekt-foo.git" \
                            --repouri="https://git.projekt-foo.org/?p=projekt-foo.git;a=summary" \
                            --sender=git@projekt-foo.org

Zum Debuggen beim Einrichten des Hooks kann man noch die Option --debug anhängen. Achtung! Die Option --debug ist eher ein "try-run", es wird dann keine Mail versendet! Praktisch zum Prüfen ob die generierte Mail korrekt ist. Das Hook Script kann dann direkt als User git bzw. gitolite im Hook Verzeichnis des Repos aufrufen.

#!/bin/bash

/usr/local/bin/git-notifier --mailinglist=projekt-foo@projekt-foo.org \
                            --emailprefix="[git] projekt-foo.git" \
                            --repouri="https://git.projekt-foo.org/?p=projekt-foo.git;a=summary" \
                            --sender=git@projekt-foo.org \
                            --debug

Will man die Commitmail an mehrere Empfänger versenden lassen muss man die Angabe für die Option --mailinglist anpassen. Dazu kann man sich eine Variable im post-receive Script setzen. In späteren Versionen wird es vermutlich eine Option im Pythonscript direkt geben.

#!/bin/bash

REPO=projekt-foo
HOST=projekt-foo.org
# an option for testing surpose
#OPTION="--diff=[SHA_ID1]..[SHA_ID2] --debug"

# if you use gitolite ...
if [ "$GL_ADMINDIR"=="" ]; then
        echo "\$GL_ADMINDIR set by $0"
        GL_ADMINDIR="$HOME/.gitolite"
fi

# sourcing external mail recipients
if [ -f $GL_ADMINDIR/conf/"$REPO"_recipient.cfg ]; then
    . $GL_ADMINDIR/conf/"$REPO"_recipient.cfg
else
    # setting local recipients
    MAILINGLIST="Mister X <emailuser1@nowhere.com>,Errol Flinn <horray@plateau.it>"

/usr/local/bin/git-notifier --mailinglist="$MAILINGLIST" \
                            --emailprefix="[git@$HOST] $REPO.git" \
                            --repouri="https://git.$HOST/?p=$REPO.git;a=summary" \
                            --sender=git@$HOST \
                            $OPTION

Seifes Buildsystem für SH4 STBs mit eigenem SH4 Crosscompiler

(Da ich mir das immer nicht merken kann verewige ich das mal hier.)
Nachdem Debian im kommenden Stable Release auf Multilibs (32bit/64bit) setzt und ich noch nicht die benötigten Pakete entwuselt habe und man eventuell auch einen aktuelleren Crosscompiler wie den von STLinux benutzen will kann man kann man sich mit Crosstool-NG und Patches von STLinux seinen eigenen Crosscompiler für das Buildsystem bauen und natürlich auch benutzen.

Crosscompiler bauen

fehlt noch :-)

Buildsystem benutzen

Dazu wie üblich sich das Buildsystem lokal clonen und das Downloadverzeichniss anlegen oder verlinken sofern die Archive schon an anderer Stelle vorhanden sind. Dann die üblichen Schritte zum Vorbereiten ausführen, make preqs, make crosstool überspringen da man ja den extern liegenden Crosscompiler benutzen will, make bootstrap muss nun mit Angabe des erweiterten Pfades aufgerufen werden.

PATH=~/x-tools/sh4-stlinux-linux-gnu/bin/:$PATH make bootstrap

Nun kann man wie gewohnt das Buildsystem benutzen, einzigster Unterschied ist immer die Erweiterung von PATH.

PATH=~/x-tools/sh4-stlinux-linux-gnu/bin/:$PATH make neutrino-pkg system-tools

Quellen

• Documentation/email-clients.txt
• Plaintext EMail mit TB
• Mozilla Plugin "Toggle Wrap Words" für TB ID SM
• Mozilla Plugin "Colored Diffs" für TB ID SM