Christoph's last Weblog entries

While other people are squashing RC bugs I was using this week to fix (or investigationg) some more kFreeBSD issues -- mostly looking at failed build logs and trying to fix the problems and after some nice fish for dinner writing things up.

• First issue this week was #639178 a build failure in tar I had reported earlier and didn't manage to process the response. After sending some findings to the bug I noticed Petr was faster and did actually find out a lot more detail. Short story: success in that test suite requires linux behavior and the failure on kfreebsd is covered by what POSIX allows
• #640156 multiarch related changes resulting in a nonfunctional ldd breaking clutter-gst build
• #640012 postfix is hard-coding kFreeBSD versions … up to 7 and therefore won't build on a 8.2 kernel. It also doesn't handle absence of NIS on Hurd and kFreeBSD #545970
• #640159 iozone3 just needed a bit of massaging to combine the FreeBSD backend with the linker flags needed for kFreeBSD
• Installing the build depends for openjdk-* resulted in a installation failure for some time. Looking closer it turned out a minimal testcase was installing menu and python2.6 together. Turned out dash's test builtin wasn't working #640334 because it was relying on the intuitive but not POSIX mandated behavior of the faccessat syscall #640325
• #640341 ed decided not to build on kfreebsd-i386 in the 40 minutes between -2 and -3 upload. Without any actual source changes. Just trying agan tricked it to build again but probably someone should look what went wrong actually
• #640378 leveldb needed enabling the FREEBSD_OS kind of build with the linux style of linker flags (additional -lrt)
• #640385 owfs was failing to some symbol difference (but otherwise building although being a *fs ;))
• the gcc family of packages still has some heisenbug repeatedly failing when doing regular builds on the buildds. Independent which one. Multiple times in a row. Building on my test VM or my notebook doesn't show that problem (but takes ~10h). Building on the same buildd in the same chroot with the same sbuild flags and it's still building fine.

Imagine you have a old postgresql database. Further imagine it has it's encoding set to something like LATIN-1 but some PHP web application has put in UTF-8 strings. Now what would you do if you have some python application actually respecting the encoding and recoding the db content from latin-1 to UTF-8 giving you garbage. Seems you can easily trick postgresql to now believe it is UTF-8:

UPDATE pg_database SET encoding = 6 WHERE datname = 'foo';

For a summary of these magic numbers the PostgreSQL Manual is usefull.

So when I was travveling to my parent's for christmas it looked like I'd have limited computer access. My Netbook is quite OK for reading mail but not really useable for any real hacking. And my trusty Thinkpad (Z61m) was oopsing when X was running so not much useable either. But as some Live CDs placed here were working well I decided that this would be fixed by an reinstall. And as I was reinstalling anyway I decided I could just choose kfreebsd-amd64. Turned out to be a quite entertaining decision with lots of stuff to hack away with

wireless

Bad news: there's no wireless support on Debian GNU/kFreeBSD at the moment. This problem is tracked as Bug #601803 so for wireless internet you will need a (plain) Freebsd chroot. Haven't tried this myself yet -- busy figuring other stuff out.

SBCL

Having a FreeBSD chroot I decided to give SBCL on GNU/kFreeBSD another try after having failed to get it working in a VM some time ago. With quite some help on SBCL's IRC channel I managed to build a patch that enables building (you need to force a :os-provides-dlopen to the feature list additionally).

There's currently no multi-threading working so I hae a project for the rest of the hoidays (well lots of other stuff to do as well ;))

Audio

Some more user-related stuff now. As it is this time of the year I wanted to listen to some 27c3 streams so I needed working audio. However there's no OSS device available. Turned out you just need to kldload the right module (here snd_hda) to get sound working.

Volume was rather low although hardware controls of the soundcard where at max. As that's all OSS there's no point looking for alsamixer. Turns out aumix can do that here.

IPv6 aiccu stuff

Installing aiccu, copying the config in and starting did not work out as well. I already tried to do that from within the FreeBSD chroot already (which doesn't work for some reason) until I discovered just loading the if_tun kernel module solves the aiccu on Debian issue quite well. To get a default route up the last step was finding /lib/freebsd/route again -- /sbin/route is a wrapper around that abstracting differences in BSD route but not supporting IPv6.

This week I had to write a little tool that would collect input on different channels, via socket / netcat, via a http server, .... Calls for a parralel Design -- Maybe a good place to write something real in Erlang. While erlang itself was really nice to write -- I do like Prolog as well as the bunch of functional languages -- doing networking in erlang seems a bit special, the interfaces just aren't thin wrappers around the libc stuff.

Getting a Socket Text interface

What sounds like a easy challenge to accomplish was actually harder than expected. All I found was some way to pass binaries representing erlang code over a socket and evaluating it remotle. While it's nice that such things are as easy to do as they are it doesn't help me with my task of moving simple strings.

start() ->
    {ok, Listen} = gen_tcp:listen(51622, [binary, {packet, 0},
                                         {reuseaddr, true},
                                         {active, true}]),
    spawn(fun () -> accept_loop(Listen) end).

accept_loop(Listen) ->
    {ok, Socket} = gen_tcp:accept(Listen),
    accept_loop(Listen),
    handle(Socket)

handle(Socket) ->
    receive
        {tcp, Socket, Bin} ->
            io:format("~p~n", binary_to_list(Bin));
        {tcp_closed, Socket} ->
            Buffer
    end.

So the socket is now up and receives text as wanted. However, as we are already runnign a parralel program it would be nice to be hable to handle multiple socket connections in parralel right? For that we just need to add a spawn() at the right place. The right place is not the handle(Socket) but the accept_loop(Listen) because the process that called accept will receive all the tcp messages.

This last part was quite obvious after finding the documentation of the {active, _} properties for the socket. always here means that you'll receive all data from the socket as erlang Messages, once delivers one package and waits until it is activated again and false requires calling a method -- this would have been possible as well when forking handle(Socket).

The web server

Ok we also want a webserver. We do not want to run some webapplication inside appache or so, just do some post/get and simple pages. Erlang here provides a built-in httpd with some mod_esi that calls some function depending on the URL used. It doesn't do anything fancy like templating or DB backends or stuff, just taking strings and building the http answers.

Unfortunately there are no examples around and basically noone seems to be using this combination (apart from some hacks like mine probably). So as I needed to get some additional information into the handler function (a Pid to connect to some service), I, as a novice, just couldn't find a way. Asking on IRC the solution was rather simple: Just using erlang's process registry. For more complex stuf gproc might prove usefull here.

Result

I guess I've got a huge step farther in programming erlang now. The manpages are easily found by your search engine -- for python I have to either walk through the (well structured) online documentation or search for the right link in the search results, for erlang they're typically first. Also Joe Armstrong's Books as proven usefull. The most dificult part probably is getting around all the nice extras you can do (transfering functions over sockets et al) and find out how to do the thing you need.

I'm all for security and really like encryption (my Notebook's harddrive is encrypted, I've recently got a GPG Smartcard, ...) but sometimes you see big failes where security is atemted but doesn't actually secure anything but only hinders the legitimate user.

Today one of these candidates ate way to much of my time again. I'm currently getting more and more used to GNU Emacs and currently experimenting with emacs-jabber. Therefore copying my jabber accounts over from psi. As with these passwords you never type in I couldn't remember some of my jabber passwords -- no problem psi has to store them so it should be easy to get them, right?

Well actually not. The configuration file (XML) had a password entry but all that was in it was just obviously hex-encoded numbers. These numbers turned out to be be 16bit packages of characters that are XOR-ed against the JID So now you have to read them in in junks of 16bit, XOR them against the JID and get the password.

Time to recapitulate what this security helped. I've written a hacky 10 lines C Program that can reliably retrieve passwords from any config file I might come across. Seems you can do the same in 2 lines of perl. Ergo no security at all was added.

Next question: What did it cost? Needed an hour or so of researching the encryption and trial&error out the right program fragment. For nothing gained at all. Fail.

As I really liked saying why I think Open Game Art is a good project I decided to start a small serie of well done free (well not only software) projects. This time SFML got to be the one.

SFML is, as the name already tells, a Simple and Fast Multimedia Library written in C++ but providing bindings for a whole bunch of other languages like Python, Ruby, C, D and others. Debian currently provides the original library as well as the C and Python bindings maintained by the Games Team and myself. On a side remark, SFML also uses my favourite License, zlib.

What I really like about SFML is the readable code all through the project. Every time I was unsure what some function does having a look at the actual implementation (and some OpenGL and X11) knowledge turned out to be quite satisfactory. This is, of course, aided by the fact that SFML's development is driven by a single Developer, Laurent Gomila.

On the rather weak points I'm still hoping the to-be-released 2.0 Version of SFML will introduce something like a stable API which it currently lacks (although the API has settled and there are no such huge changes as from 1.2 to 1.3 in recent updates any more). SFML also uses hand-made Makefiles for building (now supporting DESTDIR at least -- in some non-standard way) and has the usual load of embedded libraries which results in it's current load of patches.

For a nice time burner make sure you take a look at the python binding's snake-like clone. It clearly misses some important aspects to form a full game but it's nice nontheless. I have a (not-quite) small SFML based Project myself, a forward ported game from my old DirectX days, however it's unfortunately not yet playable again und rather stalled at the moment due to lack of time.

So much for SFML. If you feel like it feel free to join me on writing about well done pieces of software or just about pieces on how you think it should™ be done and tell us where you found it happening.

Gute Nachrichten vorneweg: Debian GNU/kFreeBSD funktioniert bereits halbwegs und ist mehr oder weniger verwendbar. Zumindest für meine Zwecke. Und trotzdem wird mein Notebook vorerst weiter mit Debian GNU/linux betrieben. Ist einfach die stabilere Variante.

Das heißt jetzt natürlich nicht, kFreeBSD einfach zu ignorieren und daher habe ich eine Installation in QEMU laufen. Im folgenden ersteinmal ein paar Screenshots:

Während der X Server weitgehen funktioniert -- neueste Kernel Version vorausgesetzt und mitunter etwas nachhelfen an den HAL fdi Dateien -- ist das mit den Desktops etwas schwieriger. Fluxbox, wie oben zu sehen, funktioniert dabei einwandfre und auch awesome scheint zu funktionieren:

Während ich persönlich mit Fluxbox bisher immer ganz gut zurecht gekommen bin und mir awesome in der QEMU ziemlich gut gefällt (muss ich wohl nochmal auf dem Notebook direkt ausprobieren), ist meine erste Empfehlung an Linux Neulinge normalerweise LXDE. Und da fangen die Probleme an.

Zuerst schon lässt sich lxde, und sogar lxde-core nicht direkt installieren, nicht erfüllbare Abhängigkeiten. Glücklicherweise lässt sich das für lxde-core relativ einfach beheben: für pcmanfm ist der hal build auf nicht-Linux Architekturen (Hurd, BSD) deaktiviert. Schaltet man ihn an, baut das ganze frühlich das pcmanfm Packet.

lxpanel ist etwas komplizierter, lässt sich aber auch beheben. Das Packet hängt zwar für den Bau von libasound2-dev und libiw-dev ab, die (noch) nicht auf kFreeBSD portiert wurden, allerdings erkennt der configure script das automatisch und baut dann halt ohne. Nur das erkennen der BSD Kernels funktioniert nicht ganz, auf GlibC BSDs definiert GCC nämlich __FreeBSD_kernel__ statt __FreeBSD__. Passt man die entsprechende Zeile im Quellcode an funktioniert zumindest der Build. lxmusic müsste ich mir 'mal ansehen, auch hier gibt es unerfüllte Build-Abhängigkeiten.

Auf dem Screenshot ist schon ganz gut eines der Probleme zu sehen: Der Dekorator will irgendwie nicht so recht. Und in Live oder auf einem Video könnte man auch das zweite Phenomen erkenne: Das halbdekorierte Fenster wandert langsam immer weiter den Bildschirm hinunter.

GNOME und/oder KDE konnte ich nicht so einfach testen. Sowohl gnome-core, als auch kde4-minimal wollten sich wegen nicht erfüllter Abhängigkeiten nicht installieren lassen und für GNOME/KDE fehlt mir auch ersteinmal die Motivation etwas tiefer zu graben.

Zu guter letzt bleibt noch zsh. Hier hängt der Build auf den Debian Autobuildern im test Status. Abhilfe schafft ein lokaler Build, für den die Tests auskommentiert sind (leider unterstützt das Packet kein DEB_BUILD_OPTIONS="notest".

Jetzt steht eigentlich die Installation auf echter Hardware an, allerdings braucht der PC, den mir der Lukas freundlicherweise überlassen hat, wohl ersteinmal noch ein BIOS update um mit Linux und/oder BSD Kernels zurechtzukommen.

Für alle, die neugierig geworden sind, gibt es eine Mailing Liste und einen IRC Channel sowie (leider nicht ganz aktuelle Informationen auf Alioth.

Um Unknown Horizons weiter zu verbreiten habe ich jetzt ein ohloh.net Projekt angelegt und gleich noch einen Account für mich angelegt.

Ohloh lobt dann auch gleich das Projekt für ein aktives, großes Entwicklerteam und gute Dokumentation, kann also gar nicht so schlecht sein.

Ganz überrascht bin ich auch, wie weit ich es mit meinen bisherigen Projekten bereits geschafft habe ...

TODO: Einträge über NM und Debconf

Nachdem der Unknopwn Horizons Server in letzter Zeit immer wieder Probleme gezeigt hat, ist das Projekt wenigstens vorübergehend hier einquartiert worden.

Das heißt natürlich, dass dieser Server deutlich höhere Lasten bewältigen muss (Unknown Horizons hat ungefär so viele Besucher, wie die andere Ladung Domains hier). Sieht aber aktuell so aus, als ob wir das bewältigen können.

Markdown ist eine wunderbare Möglichkeit, gedanken, technische Vorschläge oder ähnliches schnell in ein halbwegs ordentlich darstellbares Format zu bringen. Das ganze lässt sich statisch in XHTML umwandeln oder per PanDOC in eine vielzahl anderer Formate. Wenn man will, kann man das auch dynamisch den Webserver erledigen lassen.

Genau das geschieht schon seit einiger Zeit auf meinem Scratchboard http://mdn.christoph-egger.org/. Das schöne daran ist die Verwaltung über Versionskontrolle (die Markdown Files werden einfach per hg push auf den Server übertragen und sind dann dort abrufbar.

Aus lauter Langeweile habe ich jetzt den Verwendeten Python Script von mod_python auf mod_wsgi portiert und aufgeräumt, sodass das ganze jetzt veröffentlicht werden kann: WSGI Script, Beispieltemplate

Viel Spass!

Unbestätigten Insiderinformationen (/me ist Teil des Teams) zufolge steht die Veröffentlichung von Unknown Horizons 2009.0 in wenigen Minuten an.

Nach über 5 Monaten Entwicklung hat das Unknown Horizons Projekt jetzt ein neues Snapshot Release in der Version 2009.0 herausgebracht. Nachdem wir heute Nachmittag Pakete gebaut und den letzten Feinschliff vollendet haben, durfte ich das neue Release im SVN tree des Projekts taggen.

Neben der Namensänderung sind jetzt auch erstmals Graphiken in einer ordentlichen Auflösung dabei, sowie eine deutlich ansprechendere Spielwelt -- keine quadratischen Inseln mehr! -- so dass die Hoffnung bleibt, dass möglichst viele Nutzer Gefallen an dem Spiel finden werden.

Eine weitere, wichtige Neuerung ist der Free Trader. Somit ist es jetzt möglich im Singleplayer Modus (Multiplayer müsste irgendwann implementiert werden) Waren zu kaufen/verkaufen.

Was hat es dann nicht in die neue Version geschafft? Leider eine ganze Menge -- das Release ist nunmal nicht zu Unrecht als Alpha gekennzeichnet. Meine Ziele für die nächste Zeit sind allerdings dann i18n/l10n, was leider von PyChans Fähigkeit abhängt Unicode Zeichen darzustellen, und saubere Installierbarkeit, sodass ich offizielle Debian Pakete bauen kann.

Wer sich für Details interessiert, der sei auf das Changelog verwiesen.

Wie euch sicher noch bekannt ist, bin ich seit einiger Zeit im OpenAnno Team aktiv. OpenAnno wird wohl bald eine weitere Ergänzung zu der mitunter noch umfangsschwachen Kategorie der freien Strategiespiele darstellen.

Allerdings erwieß sich der Name «Open Anno» in mehrerlei Hinsicht als eher problematisch. Zum einen weil Open Anno zwar durch Sunflowers Anno Serie inspiriert ist, aber keinen Clon erstellen will, sondern ein eigenständiges, unabhängiges Spielkonzept verfolgt. Durch den Namen «Open Anno» wurde somit ein falscher Eindruck des Projektziels verbreitet. Weiterhin wollte das Projekt Markenrechtlichen Problemen aus dem Weg gehen, die durch die Verwendung des Names «Open Anno» entstehen könnten.

Nach einiger Diskusion konnte sich das Projekt auf den Namen «Unknown Horizons» einigen, die Website ist dann acuh gleich auf die neue Domain http://www.unknown-horizons.org/ umgezogen, die Strings im Spiel selbst sind mittlerwile auch weitgehen ausgetauscht.

Bleibt nur noch dem Projekt alles gute zu Wünschen und auf das nächste «Demo Release» Anfang März (Insider Info!) zu warten.

Nachdem ich bereits über TopGIT geschrieben habe wurde diese Seite ziel einiger Google-Suchen nach dem String 'topgit'.

Da dieses Thema scheinbar eine Menge Menschen interessiert und mein Weblog unter dem Top Hits in Google erscheint habe ich dann beschlossen mein Mini-Review aus dem Debian Games Team hierher zu übernehmen. Alle Angaben beruhen auf meinen Vermutungen und erheben weder den Anspruch komplett noch richtig zu sein.

Das Original war in Englisch verfasst daher gibt es hier jetzt eine Übersetzte und überarbeitete Version davon. Wer die Debian Spezifischen Teile lesen will sei auf das Original verwiesen.

Das erste Mini-Review entstand, da ich TopGIT beim Paketieren von XWelltris ausprobiert habe und dann von einigen Menschen im Debian Games Team darum gebeten wurde.

XWelltris selbst ist kein besonders komplexes Paket und hat in Debian aktuell nur 2 Patches die mit TopGIT verwendet werden sollten. Das mitlerweile ebenfalls umgestellte SFML ist da um einiges komplexer.

Wozu wird TopGIT dabei eingesetzt? TopGIT generell kann verwendet werden um verschiedene Modifikationen zu einem Originalen Source-Tree zu verwalten und dabei den vollen Funktionsumfang zur Verfügung zu haben. Dabei übernimmt die TopGIT Branch in etwa die Rolle eines traditionellen Patches wobei TopGIT in der Lage ist, abhängigkeiten zwischen den Patches darzustellen.

Funktionsweise

Während für git selbst die TopGIT Branches wie normale Branches aussehen «weiß» TopGIT für welche Branches es verantwortlich ist. Diese Branches kann TopGIT dann auch z.B. in eine QUILT Patchserie exportieren

Die Reihenfolge der Patches in der QUILT Serie wird dabei durch die in jeder TopGIT Branch vorhandenen .topdeps Datei festgelegt, während der Kommentar für den Patch aus der Datei .topmsg stammt. Damit es keine Probleme gibt sollte die in .topdeps angegebene Branch in die jeweilige aktive Branch gemerged sein, da der Patch aus einem diff zwischen der aktiven Branch und der in .topdeps angegebenen Branch entsteht.

Eine neue TopGIT Branch wird mit dem Befehl tg create $NAME erstellt. Als Grundlage für die neue TopGIT Branch dient dabei die gerade aktive Branch.

Wird in der Master Branch -- und natürlich jeder anderen Branch, von der tg Branches abhängen -- eine Änderung vollzogen, so werden in tg summary alle veralteten Branches mit einem 'D' markiert. Dies ist der Aufruf in dieser Branch ein tg update auszuführen, das die Branch dann auf den neuesten Stand bringt.

tg create erstellt die TopGIT Informationen nur lokal. Andere Benutzer des Git Repos werden nur «seltsame» Branches feststellen ohne weitere Verwendungsmöglichkeiten. Daher sollte möglichst Zeitig ein tg remote $ORIGIN aufgerufen werden, sodass der online Git Repos die TopGIT Branches ordentlich verfolgt.

Fazit

TopGIT ist der alternative von z.B. QUILT+Patches weit überlegen. Allein die Möglichkeit Patches direkt zu modifizieren ohne jedes Mal an quilt add denken zu müssen ist einiges Wert. Dazu kommt die Tatsache, dass TopGIT die Entwicklung der Patches verfolgen lässt.

Ganz besonders praktisch ist, dass der Wechsel von z.B. QUILT+Patches keine unidirektionale Aktion ist sondern sich problemlos wieder umkehren lässt, da TopGIT eine Patch Serie exportiert die dann ohne TopGIT verwendet werden kann.

Freite Texturen finden kann ja nicht so schwer sein oder? Blender Nation hat ja regelmäßig neue Blogeinträge mit neuen Quellen für freie Texturen, es gibt hunderte Seiten online, ...

Wirklich freie Texturen (frei wie in DFSG zu finden ist aber in wirklichkeit viel schwerer. Denn: Was mache ich mit Texturen, die frei für kommerzielle und nicht-kommerzielle Verwendung sind (ohne weitere Erklärung)? Viele texturseiten bieten die Textur an, schließen aber Weitergabe (mit außnahme von Druckwerken) aus.

Sollte tatsächlich ein OpenSource Künstler auf diese Seite stoßen, bitte gebt uns eure Links ;)

Mein eigenes, kleines OpenSource Projekt, ein Spaceshooter, der -- unter Verwendung von SFML -- in C++ geschrieben ist, hat gestern eine neue Alpha Version veröffentlicht.

Wichtigstes Feature der neuen Version ist die Möglichkeit, das Spiel per Autotools ordnungsgemäß zu installieren. Bisher war leider nur ein Spielen im Source-Tree möglich. Dadurch wird es jetzt auch sinnvoll möglich ein Debian Paket zu bauen -- sollte dies Erfolg haben gibt es dieses demnächst als Download.

Mit diesem Release sind wir dann auch schon in einem Bereich an ein Final Release zu denken. Blockiert wird das ganze noch primär durch ein paar Timing Ungereimtheiten: Der ursprüngliche Code verließ sich zum Teil auf Frames, zum Teil auf normale Timer für die Zeitmessung. Die von der Framerate abhängigen Elemnte sind zwar mittlerweile umgestellt, aber alles läuft noch nicht korrekt.

Ist dies dann geklärt braucht der Content etwas Pflege -- danach ist ein Release auf jeden Fall denkbar.

Wohin geht die Zukunft?

• Der Content ist bisher einsprachig / deutsch. Um das zu ändern muss ein Konzept entworfen werden, die primär in XML Dateien lokalisierten Strings zu übersetzen.
• Aktuell wird ein selbst geschriebener «XML»-Parser verwendet. Das macht mehr Probleme als dass es hilft und sollte ersetzt werden.

Und es ward Zeit, etwas neues zu lernen. Diesmal LISP. Auf LISP kommt man zum Beispiel, wenn man in Python programmiert, die mächtigkeit der Python Listen erkennt und erfährt, dass es sich dabei um ein Feature handelt, das aus LISP stammt. Auf LISP kommt man auch unweigerlich, wenn man sich für Künstliche Intelligenzen interessiert.

Sogesehen hat LISP jedenfalls das Potentiel meine nächste Programmiersprache zu werden, nachdem Python schon immer mehr mein C++ verdrängt (nicht dass ich letzteres nicht mehr verwende ...). Und mit einem guten Buch kann's dann auch gleich losgehen.

Die installation der entsprechenden Umgebung ist natürlich auf Debian-Weg zügig erledigt. schwieriger ist dann schon der Umstieg von VIM auf EMACS, aber auch das ist machbar, gerade wenn man nicht gerade quasireligiös an einem der Editoren hängt. Setup: Emacs mit SLIME, cmucl.

Die ersten paar Kapitel habe ich jetzt ohne größere Schäden hinter mir, mal sehen was da noch kommt. LISP Makros scheinen mir trotz C(++) Geschichte jedenfalls keine besonderen Schwierigkeiten zu machen.

Seit gestern Abend habe ich jetzt einen SVN Zugang beim OpenANNO Projekt. OpenANNO ist (wenig verwunderlich) ein OpenSource Strategiespiel, das durch die ANNO Serie inspiriert wurde. Aktuell ist es Teil der vom Debian Games Team, in dem ich mitarbeite, beobachteten Spiele.

Während das Spiel noch in einem Zustand ist, in dem ein Upload ins Debian Archiv nur schwer denkbar ist habe ich mich bereit erklärt erste Pakete zu bauen (Bitte keine Kommentare über die Qualität, es ist mir durchaus bewusst, dass das noch weit von Debian-Standard entfernt ist).

Nachdem ich über die oben erwähnte Wikiseite auf das Projekt gestoßen bin bemühe ich mich auch innerhalb des Projektes die Paketierbarkeit zu fördern. Zusammen mit meinen -- zugegebenermaßen kleinen -- Beiträgen hat mir das jetzt SVN Zugang beschehrt, ich werde wohl jetzt so schnell nicht mehr von diesem Projekt loskommen

Wie man meinem privaten Launchpad PPA ansieht verwende ich selbiges doch recht ausgiebig. Der Nutzen liegt, in meinen Augen, unter anderem darin, bereits vor dem offiziellen Release mit den aktiven Benutzern der Software auf Fehlerzuche gehen zu können.

Solchige Software könnte sonst lediglich in Debians «experimental» landen, würde das ganze aber für mich ausbremsen da mit einfach die Upload-Rechte (noch) fehlen und gerade für kleinere Projekte kann man in einem solchigen experimental-Updload auch Resourcenverschwendung sehen.

Außerdem geben die PPAs eine gute Möglichkeit backports zu veröffentlichen. Aufgefallen ist mir das, als ich festgestellt habe, dass, obwohl ich primär ein Debian-Mensch bin, meine neuen SFML-Pakete zuerst für Ubuntu verfügbar sind und in Debian wohl erst irgendwann nach dem Release erhältlich sein werden und auch dann nur für sid und squeeze.

Schade eigentlich, dass es so etwas für Debian nicht gibt.

Der normale Weg, neue Änderungen einer Website auf den Production-Server zu übertragen führt wohl über (S)FTP oder SCP. Jedenfalls war das bei mir bis vor kurzem so.

Mit der Zeit habe ich dann angefangen, meine Arbeiten am Website Code per Versionsverwaltung zu dokumentieren. Und als dann plötzlich eine Website nicht nur von mir erstellt wurde gibg das Repos natürlich auf den Server. Da lag es dann natürlich nahe, die Serverversion einfach zu «hg clone»n.

Tja, das hat sich irgendwie verselbstständigt und eine der ersten Aktionen bei einem neuen Webprojekt ist ein HG Repos auf dem Server. Und ich muss sagen, das Ergebniss ist sehr angenehm. Geändertes wird automatisch übertragen, gleiches nicht ohne dass man sich darum kümmert

Nachdem auf der Team-ML der Debian Games Gruppe, in der ich zufällig mitarbeite, die Verwendung von topgit für alle git-verwalteten Pakete vorgeschlagen wurde um quilt-patches zu erzeugen habe ich mich spontan entschlossen mein Paket «xwelltris» zu konvertieren.

Quilt wird bei Debian Paketen dazu verwendet, Änderungen am Quellcode der Originalprogramme zu separieren, allerdings gestalltet sich die alleinige Verwendung in zusammenarbeit mit GIT etwas mühsam

Mit TOPgit kann man dann allerdings Änderungen direkt in einer git-branch erstellen und muss nicht mit patches und einem weiteren Level an (pseudo)Versionskontrolle -- quilt -- arbeiten. TOPGit erstellt dann aus diesem branches automatisch die entsprechende Patch-Serie.

Auch wenn ich gleich bei den ersten Versuchen das Setup erfolgreich lahmgelegt hatte werde ich wohl im laufe der nächsten Zeit auch meine anderen pakete auf diese Weise der Arbeit convertieren!