netatalk Version ermitteln

Bei der Installation von „netatalk“ über den Paketmanager von Debian kam die Frage auf welche Version genau installiert wurde. Leider ist das aus den Konfigurationsdateien von „netatalk“ nicht ersichtlich, so das der Paketmanager zur Hilfe eilen musste. Mittels:

apt-cache show netatalk

bekommt man dabei heraus, welches Paket sich in den Paketquellen befindet und kann somit auf die installierte Version schließen. Die Ausgabe sollte dabei in etwa so aussehen:

Package: netatalk
Version: 2.2.2-1
Architecture: armhf
Maintainer: Jonas Smedegaard <>
Installed-Size: 3329
Depends: libacl1 (>= 2.2.51-5), libattr1 (>= 1:2.4.46-5), libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libc6 (>= 2.13-28), libcomerr2 (>= 1.01), libcrack2 (>= 2.8.12), libcups2 (>= 1.4.0), libdb5.1, libgcc1 (>= 1:4.4.0), libgcrypt11 (>= 1.4.5), libgnutls26 (>= 2.12.17-0), libgssapi-krb5-2 (>= 1.10+dfsg~), libk5crypto3 (>= 1.6.dfsg.2), libkrb5-3 (>= 1.6.dfsg.2), libldap-2.4-2 (>= 2.4.7), libpam0g (>= 0.99.7.1), libwrap0 (>= 7.6-4~), zlib1g (>= 1:1.1.4), perl, netbase, libpam-modules
Recommends: lsof, rc, db-util, procps, cracklib-runtime, libpam-cracklib, avahi-daemon
Suggests: texlive-base-bin, groff, quota, db4.2-util
Homepage: http://netatalk.sourceforge.net/
Priority: extra
Section: net
Filename: pool/main/n/netatalk/netatalk_2.2.2-1_armhf.deb
Size: 1612042
SHA256: 1ff45497e7262353c8021b16d1a2e05942cb54b92d3ffd4525af1da01b2b6b2a
SHA1: 5282e61b063f3bdc7d16ee184cf91c8acb6b764d
MD5sum: 07574355726c9f1a65629dcdb89f086d
Description: AppleTalk user binaries
 Netatalk is an implementation of the AppleTalk Protocol Suite for
 BSD-derived systems.  The current release contains support for
 EtherTalk Phase I and II, DDP, RTMP, NBP, ZIP, AEP, ATP, PAP, ASP, and
 AFP.
 .
 This package contains all daemon and utility programs as well as Netatalk's
 static libraries.

Gleich in der zweiten Zeile ist der entsprechende Eintrag für die Version zu finden, in diesem Fall ist es die Version 2.2.2-1.

Linux Nutzer ohne Shell anlegen

Manchmal benötigt man unter Linux einen Nutzer, möchte aber das dieser keine Shell zugewiesen bekommt und sich somit nicht anmelden kann. Dies kann unter anderem mit dem Befehl „adduser“ bewerkstelligt werden:

adduser seeseekey --no-create-home --shell /bin/false

Damit legt man einen Nutzer an, welcher sich nicht anmelden kann, aber durchaus für die Authentifizierung über das Nutzersystem z.B. bei bestimmten Netzwerkdiensten taugt. Daneben wird auch gleich verhindert, dass der Nutzer einen „home“-Ordner bekommt.

Unity und Android und das aktuelle SDK

Seit ein paar Tagen ist es möglich mit den frei verfügbaren Unity Versionen auch Android und iOS Builds zu bauen. Wenn man nun also anfängt und das aktuelle Android SDK herunterlädt und anschließend versucht in Unity einen Android Build zu erzeugen wird man feststellen, das dass ganze nicht funktioniert. Stattdessen bekommt man für einen kurzen Moment die Meldung:

Error building Player: Exception: android (invokation failed)

zu sehen. Der Grund für diesen Fehler ist dabei recht simpel. Unity arbeitet im Moment noch nicht mit der aktuellen SDK Version (r22) von Android zusammen. Hier muss auf die ältere r21 Version umgestiegen werden, damit Unity funktioniert. Diese gibt es für Linux, Mac OS X und Windows.

Git Workflow

Einer der Vorteile von Git ist die große Freiheit welche einem das System gibt. Einer der Nachteile widerum ist die große Freiheit welche Git bietet. Deshalb sollte man sich für die Entwicklung in einem Git Repository einen Workflow zurechtlegen. Hier sei ein exemplarischer Workflow vorgestellt.

Der Git Standardbranch trägt den Namen „master“. In diesem Branch wird per Definition nichts entwickelt. Soll nun ein Feature implementiert oder ein Bug behoben werden, so wird dafür ein Branch eröffnet. Wenn das Feature im Branch implementiert und getestet ist, so kann es wieder in den „master“-Branch gemergt werden. Branches welche gemergt wurden und nicht mehr benötigt werden können dabei wieder entfernt werden. Das gleiche gilt für alte Tagbranches.

Der Vorteil der sich aus dieser Vorgehensweise ergibt, ist das der „master“ immer relativ stabil bleibt, da nur getestete Änderungen in ihn wandern. Außerdem kann man so mehrere Features parallel entwickeln. Bei der Benennung könnte man sich z.B. an folgendes Schema halten:

Featurebranch: feature-supportTiff
Bugfixbranch: bugfix-invalidFormatHandler
Tagbranch: tag-13.04

Interessant wird es wenn ein Release einer Software ansteht. Hier sollte man von der entsprechenden Software welche in einem Git Repository liegt einen Branch erstellen und diesen entsprechend benennen: z.B. als „tag-13.04“. In diesem Branch wird die Software auf Herz und Nieren getestet und auftretende Fehler behoben. Neue Features werden dabei nicht mehr entwickelt.

Wenn nun ein Fehler auftritt hat man drei Möglichkeiten damit umzugehen. Wenn der Fehler nur in dem Tagbranch auftaucht, wird er dort behoben, indem ein Bugfixbranch erzeugt wird, der Fehler behoben und der Bugfix getestet wird. Anschließend wird er wieder in den Tagbranch gemergt.

Ist der Fehler im „master“-Branch und im Tagbranch des aktuelles Releases enthalten, so wird ein Bugfixbranch vom „master“-Branch erstellt, der Fehler dort behoben und anschließend in den „master“ und in den Tagbranch zurückgemergt.

Dies funktioniert natürlich nur, wenn sich der „master“ und der Tagbranch nicht zu weit auseinander entwickelt haben. Ist der Fehler noch in beiden Branches vorhanden, die Unterschiede zwischen den selbigen aber zu gravierend, muss für jeden der beiden Branches ein Bugfixbranch erstellt werden und der Fehler in diesen Branches separat behoben werden. Anschließend wird das ganze in die entsprechenden Branches zurückgemergt.

Wenn alle gefundenen Fehler im Tagbranch behoben wurden bekommt der entsprechende Commit einen Tag in der Form „13.04“. Sollten später weitere Fehler beseitigt werden so werden diese im entsprechenden Tagbranch behoben und anschließend ein neuer Tag vergeben (z.B. „13.04.1“), welches das Bugfixrelease kennzeichnet.

Das ist natürlich nur ein Vorschlag für einen Workflow, der den eigenen Anforderungen unter Umständen angepasst werden muss. So könnte man für sich entscheiden das kleinere Fehler direkt im „master“-Branch behoben werden. Das liegt dann aber in der Verantwortung des Nutzers, der nach diesem Workflow arbeitet.

Scrivener und Probleme beim eBook Export

Wenn man unter Scrivener in ein eBook Format wie Mobi oder EPUB exportieren will, so bekommt man das Problem das bestimmte Formatierungen, wie z.B. die Einrückungen beim „Blockquote“ nicht berücksichtigt werden.

Die "Compile" Optionen

Die „Compile“ Optionen

Für das Problem gibt es eine Lösung, allerdings ist diese relativ gut versteckt. Im „Compile“ Fenster wählt man dabei den Tab „Formating“ und betätigt dort den Button „Options…“ in der oberen rechten Ecke. Dort aktiviert man dann den Punkt „Preserve tabs and indents“ und schon werden die Einrückungen richtig exportiert.