Christoph's last Weblog entries

Entries tagged "debian".

Looking for a mail program + desktop environment
3rd October 2017

Seems it is now almost a decade since I migrated from Thunderbird to GNUS. And GNUS is an awesome mail program that I still rather like. However GNUS is also heavily quirky. It's essentially single-threaded and synchronous which means you either have to wait for the "IMAP check for new mails" to finish or you have to C-g abort it if you want the user interface to work; You have to wait for the "Move mail" to complete (which can take a while -- especially with dovecot-antispam training the filter) before you can continue working. It has it's funny way around TLS and certificate validation. And it seems to hang from time to time until it is C-g interrupted.

So when I set up my new desktop machine I decided to try something else. My first try was claws-mail which seems OK but totally fails in the asynchronous area. While the GUI stays reactive, all actions that require IMAP interactions become incredibly slow when a background IMAP refresh is running. I do have quite some mailboxes and waiting the 5+ minutes after opening claws or whenever it decides to do a refresh is just to much.

Now my last try has been Kmail -- also driven by the idea of having a more integrated setup with CalDAV and CardDAV around and similar goodies. And Kmail really compares nicely to claws in many ways. After all, I can use it while it's doing its things in the background. However the KDE folks seem to have dropped all support for the \recent IMAP flag which I heavily rely on. I do -- after all -- keep a GNUS like workflow where all unread mail (ref \seen) needs to still be acted upon which means there can easily be quite a few unread messages when I'm busy at the moment and just having a quick look at the new (ref \recent) mail to see if there's something super-urgent is essential.

So I'm now looking for useful suggestions for a mail program (ideally with desktop integration) with the following essential features:

Tags: debian, linux, mail.
Running Debian on the ClearFog
22nd October 2016

Back in August, I was looking for a Homeserver replacement. During FrOSCon I was then reminded of the Turris Omnia project by The basic SoC (Marvel Armada 38x) seemed to be nice hand have decent mainline support (and, with the turris, users interested in keeping it working). Only I don't want any WIFI and I wasn't sure the standard case would be all that usefully. Fortunately, there's also a simple board available with the same SoC called ClearFog and so I got one of these (the Base version). With shipping and the SSD (the only 2242 M.2 SSD with 250 GiB I could find, a ADATA SP600) it slightly exceeds the budget but well.

ClearFog with SSD

When installing the machine, the obvious goal was to use mainline FOSS components only if possible. Fortunately there's mainline kernel support for the device as well as mainline U-Boot. First attempts to boot from a micro SD card did not work out at all, both with mainline U-Boot and the vendor version though. Turns out the eMMC version of the board does not support any micro SD cards at all, a fact that is documented but others failed to notice as well.


As the board does not come with any loader on eMMC and booting directly from M.2 requires removing some resistors from the board, the easiest way is using UART for booting. The vendor wiki has some shell script wrapping an included C fragment to feed U-Boot to the device but all that is really needed is U-Boot's kwboot utility. For some reason the SPL didn't properly detect UART booting on my device (wrong magic number) but patching the if (in arch-mvebu's spl.c) and always assume UART boot is an easy way around.

The plan then was to boot a Debian armhf rootfs with a defconfig kernel from USB stick. and install U-Boot and the rootfs to eMMC from within that system. Unfortunately U-Boot seems to be unable to talk to the USB3 port so no kernel loading from there. One could probably make UART loading work but switching between screen for serial console and xmodem seemed somewhat fragile and I never got it working. However ethernet can be made to work, though you need to set eth1addr to eth3addr (or just the right one of these) in U-Boot, saveenv and reboot. After that TFTP works (but is somewhat slow).


There's one last step required to allow U-Boot and Linux to access the eMMC. eMMC is wired to the same PINs as the SD card would be. However the SD card has an additional indicator pin showing whether a card is present. You might be lucky inserting a dummy card into the slot or go the clean route and remove the pin specification from the device tree.

--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -306,7 +307,6 @@

                        sdhci@d8000 {
                                bus-width = <4>;
-                               cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
                                pinctrl-0 = <&clearfog_sdhci_pins

Next Up is flashing the U-Boot to eMMC. This seems to work with the vendor U-Boot but proves to be tricky with mainline. The fun part boils down to the fact that the boot firmware reads the first block from eMMC, but the second from SD card. If you write the mainline U-Boot, which was written and tested for SD card, to eMMC the SPL will try to load the main U-Boot starting from it's second sector from flash -- obviously resulting in garbage. This one took me several tries to figure out and made me read most of the SPL code for the device. The fix however is trivial (apart from the question on how to support all different variants from one codebase, which I'll leave to the U-Boot developers):

--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -143,8 +143,7 @@
 #define CONFIG_SYS_MMC_U_BOOT_OFFS             (160 << 10)
-                                                + 1)
 #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS     ((512 << 10) / 512) /* 512KiB */
 #define CONFIG_FIXED_SDHCI_ALIGNED_BUFFER      0x00180000      /* in SDRAM */


Now we have a System booting from eMMC with mainline U-Boot (which is a most welcome speedup compared to the UART and TFTP combination from the beginning). Getting to fine-tune linux on the device -- we want to install the armmp Debian kernel and have it work. As all the drivers are build as modules for that kernel this also means initrd support. Funnily U-Boots bootz allows booting a plain vmlinux kernel but I couldn't get it to boot a plain initrd. Passing a uImage initrd and a normal kernel however works pretty well. Back when I first tried there were some modules missing and ethernet didn't work with the PHY driver built as a module. In the meantime the PHY problem was fixed in the Debian kernel and almost all modules already added. Ben then only added the USB3 module on my suggestion and as a result, unstable's armhf armmp kernel should work perfectly well on the device (you still need to patch the device tree similar to the patch above). Still missing is an updated flash-kernel to automatically generate the initrd uImage which is work in progress but got stalled until I fixed the U-Boot on eMMC problem and everything should be fine -- maybe get debian u-boot builds for that board.

Pro versus Base

The main difference so far between the Pro and the Base version of the ClearFog is the switch chip which is included on the Pro. The Base instead "just" has two gigabit ethernet ports and a SFP. Both, linux' and U-Boot's device tree are intended for the Pro version which makes on of the ethernet ports unusable (it tries to find the switch behind the ethernet port which isn't there). To get both ports working (or the one you settled on earlier) there's a second patch to the device tree (my version might be sub-optimal but works), U-Boot -- the linux-kernel version is a trivial adaption:

--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -89,13 +89,10 @@
                internal-regs {
                        ethernet@30000 {
                                mac-address = [00 50 43 02 02 02];
+                               managed = "in-band-status";
+                               phy = <&phy1>;
                                phy-mode = "sgmii";
                                status = "okay";
-                               fixed-link {
-                                       speed = <1000>;
-                                       full-duplex;
-                               };

                        ethernet@34000 {
@@ -227,6 +224,10 @@
                                pinctrl-0 = <&mdio_pins>;
                                pinctrl-names = "default";

+                               phy1: ethernet-phy@1 { /* Marvell 88E1512 */
+                                    reg = <1>;
+                               };
                                phy_dedicated: ethernet-phy@0 {
                                         * Annoyingly, the marvell phy driver
@@ -386,62 +386,6 @@
                tx-fault-gpio = <&expander0 13 GPIO_ACTIVE_HIGH>;

-       dsa@0 {
-               compatible = "marvell,dsa";
-               dsa,ethernet = <&eth1>;
-               dsa,mii-bus = <&mdio>;
-               pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
-               pinctrl-names = "default";
-               #address-cells = <2>;
-               #size-cells = <0>;
-               switch@0 {
-                       #address-cells = <1>;
-                       #size-cells = <0>;
-                       reg = <4 0>;
-                       port@0 {
-                               reg = <0>;
-                               label = "lan1";
-                       };
-                       port@1 {
-                               reg = <1>;
-                               label = "lan2";
-                       };
-                       port@2 {
-                               reg = <2>;
-                               label = "lan3";
-                       };
-                       port@3 {
-                               reg = <3>;
-                               label = "lan4";
-                       };
-                       port@4 {
-                               reg = <4>;
-                               label = "lan5";
-                       };
-                       port@5 {
-                               reg = <5>;
-                               label = "cpu";
-                       };
-                       port@6 {
-                               /* 88E1512 external phy */
-                               reg = <6>;
-                               label = "lan6";
-                               fixed-link {
-                                       speed = <1000>;
-                                       full-duplex;
-                               };
-                       };
-               };
-       };
        gpio-keys {
                compatible = "gpio-keys";
                pinctrl-0 = <&rear_button_pins>;


Apart from the mess with eMMC this seems to be a pretty nice device. It's now happily running with a M.2 SSD providing enough storage for now and still has a mSATA/mPCIe plug left for future journeys. It seems to be drawing around 5.5 Watts with SSD and one Ethernet connected while mostly idle and can feed around 500 Mb/s from disk over an encrypted ethernet connection which is, I guess, not too bad. My plans now include helping to finish flash-kernel support, creating a nice case and probably get it deployed. I might bring it to FOSDEM first though.

Working on it was really quite some fun (apart from the frustrating parts finding the one-block-offset ..) and people were really helpful. Big thanks here to Debian's arm folks, Ben Hutchings the kernel maintainer and U-Boot upstream (especially Tom Rini and Stefan Roese)

Tags: arm, debian, linux.
Looking for a replacement Homeserver
11th August 2016

Almost exactly six years ago I bought one of these Fuloong 6064 mini PCs. The machine has been working great ever since both collecting my mail and acting as an IMAP server as well as providing public services -- it's also However jessie is supposed to be the last Debian release supporting the hardware and the system's rather slow and lacks memory. This is especially noticeable with IMAP spam filter training and mail indexing. Therefore I'm looking for some nice replacement -- preferably non-x86 again (no technical reasons). My requirements are pretty simple:

Now I'd consider one of these ARM boards and get it a nice case but they seem all to either fail in terms of SATA or not being faster at all (and one needs to go for outdated hardware to stand a chance of mainline kernel support). If anyone knows something nice and non-x86 I'll happily take suggestions.

Tags: debian, linux.
Systemd pitfalls
7th August 2015

logind hangs

If you just updated systemd and ssh to that host seems to hang, that's just a known Bug (Debian Bug #770135). Don't panic. Wait for the logind timeout and restart logind.

restart and stop;start

One thing that confused me several times and still confuses people is systemctl restart doing more than systemctl stop ; systemctl start. You will notice the difference once you have a failed service. A restart will try to start the service again. Both stop and start however will just ignore it. Rumors have it this has changed post jessie however.

sysvinit-wrapped services and stop

While there are certainly bugs with sysvinit services in general (I found myself several times without a local resolver as unbound failed to be started, haven't managed to debug further), the stop behavior of wrapped services is just broken. systemctl stop will block until the sysv initscript finished. It will even note the result of the action in its state. However systemctl will return with exitcode 0 and not output anything on stdout/stderr. This has been reported as Debian Bug #792045.

zsh helper

I found the following zshrc snipped quite helpful in dealing with non-reported systemctl failures. On root shells it will display a list of failed services as part of the prompt. This will give proper feedback whether your systemctl stop failed, it will give feedback if you still have type=simple services and if the sysv-init script or wrapper is broken.

precmd () {
    if [[ $UID == 0 && $+commands[systemctl] != 0 ]]
      systemd_failed="`systemctl --state=failed | grep failed | cut -d \  -f 2 | tr '\n' ' '`"

if [[ $UID == 0 && $+commands[systemctl] != 0 ]]
  PROMPT=$'%{$fg[red]>>  $systemd_failed$reset_color%}\n'


zsh completion

Speaking of zsh, there's one problem that bothers me a lot and I don't have any solution for. Tab-completing the service name for service is blazing fast. Tab-completing the service name for systemctl restart takes ages. People traced down to truckloads of dbus communication for the completion but no further fix is known (to me).

type=simple services

As described in length by Lucas Nussbaum type=simple services are actively harmful. Proper type=forking daemons are strictly superior (they provide feedback of finished initialization and success thereof) and type=notify services are so simple there's no excuse for not using them even for private one-off hacks. Even if you're language doesn't provide libsystemd-daemon bindings:

(defun sd-notify (event-string)
  (let ((socket (make-instance 'sb-bsd-sockets:local-socket :type :datagram))
        (name (posix-getenv "NOTIFY_SOCKET"))
        (bufferlen (length event-string)))
    (when name
      (sb-bsd-sockets:socket-connect socket name)
      (sb-bsd-sockets:socket-send socket event-string bufferlen))))

This is a stable API guaranteed to not break in the future and implemented in less than ten lines of code with just basic socket functions. And if your language has support it becomes actually trivial:

        import systemd
    except ImportError:

Note that in both cases there is no drawback at all on systemd-free setups. It has the overhead of checking the process' environment for NOTIFY_SOCKET or for the systemd package and behaves like a simple service otherwise.

Actually the idea of separating the technical aspect (daemonizing) from the semantic aspect of signalizing "initialization finished, everything's fine" is a pretty good idea and hopefully has the potential to reduce the number of services signalizing the "everything's fine" too early. It could even be ported to non-systemd init systems easily given the API.

Tags: debian, foss, linux.
A week of Debian GNU/kFreeBSD
4th September 2011

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.

Tags: debian, foss, kfreebsd, programmieren.
29th June 2011

debconf banner I'm coming as well! Really looking forward to meet the people from Debconf9 again. Also people from the Games Team and the buildd and kfreebsd folks. And ideally there will be some more people interested in (Common) Lisp as well, we'll see

Tags: debian, foss, kfreebsd, linux.
Marking all closed bug reports "read" in a Maildir
12th June 2011
Tags: debian, foss, howto.
Maintaining kFreeBSD buildds since one month
30th May 2011

At April 30, I took over maintenance of of Debian's kFreeBSD autobuilders. Means getting something like 4,5k e-Mails this month (gladly no need to sign all those 4k successful builds any more!), filling nearly 30 RC Bugs (quite a lot of which got fixed just within hours after filling, wow!), investigating some of the more strange build failures and such stuff. In general it turned out to be quite some fun.

Quite interesting which libraries turn out to be rather central to the Archive. I wouldn't have guessed that a uninstallable libmtp would prevent a reasonable fraction of the builds to fail -- including packages like subversion.

Packages builds failing because the disk space is exhausted may be something most of us have already witnessed, especially those here that use one of these small notebook hard drives. Build failures caused by a lack of RAM might certainly be imaginable as well, especially on highly parallel builds. But have you ever seen gcc fail because the virtual address space was exhausted on 32 bit architectures?

Also there's a interesting lot of packages with misspelled build dependencies which sbuild can't find and therefore can't build the package. Maybe having a lintian check for some of these problems would be a good idea?

I'm also regularly seeing build failures that look easy enough to fix -- like some glob in a *.install for some python package matching lib.linux*. I try to fix some of these as I see them but my time is unfortunately limited as well. Someone interested in quick&easy noticed about these kind of issues? I could put URLs to build-logs on or somewhere on IRC.

There are also some really strange failures like llvm, which builds flawlessly on my local kFreeBSD boxes all the time, inside and outside schroot but hangs all the time in the same testcase when building on any of the autobuilders (any hints welcome!) or perl failing on kfreebsd-amd64 selectively but all the time.

Tags: debian, foss, kfreebsd, porting.
Thouhts on secure software archives
12th May 2011

From the java point of view

Recently I had to get some Scala Tool working correctly. Unfortunately there are basically no packages in the Debian Archive at all so I had to use maven to install these (or download + install manually). Being a highly paranoid person downloading and executing code from the internet without any cryptographic verification at all one after the other practically drove me nuts. Looking a bit deeper I noticed that some of the software in maven's repository have some signatures next to them -- signed by the author or release manager of this specific project.

Why secure sources matters

With my experience in mind I got some Input from other people. One of the things I was told is that some scala tools just aren't security critical -- they're only installed and used as the current user. In my opinion this is, for my desktop system, totally wrong. The important things on my private Computers are my GPG and SSH keys as well as my private data. For messing with these no super user access is needed at all.

Comparing to the Common Lisp situation

Being a Common Lisp fan of course I noticed basically the same problem for installing Common Lisp libraries. Here the situation in Debian is quite a bit better -- and I'm working in the pkg-common-lisp Team to improve this even more. Common Lisp has some maven-alike tool for downloading and installing dependency trees called quicklisp -- without any cryptographic verification as well. However there's light at the end of this tunnel: There are plans to add GPG verification of the package lists really soon.

Comparing the maven and the quicklisp model

So there are basically two different approaches to be seen here. In maven the software author confirms with his signature the integrity of his software while in quicklisp the distributor confirms all users get the same software that he downloaded. Now the quicklisp author can't and won't check all the software that is downloadable using quicklisp. This won't be doable anyway as there's way to much software or a single person to check.

Now in some kind of perfect World the maven way would be vastly superior as there's a End-To-End verification and verification of the full way the software takes. However there's a big problem: I don't know any of these Authors personally and there's no reason I should just trust any of them.

Now comparing this to the Distribution / quicklisp model. Here I would just have to trust one person or group -- here the quicklisp team -- to benefit from the crypto which might be possible based on karma inside the using community. However here I don't gain the possibility that the software is integer.

However idealized if some of these pieces of software was forged between upstream and the quicklisp team and attacker would also intercept me downloading the software from the same address so I get the source from upstream matching the checksum from quicklisp -- assuming the quicklisp team does indeed know the correct website. Additionally I get the confirmation that all other quicklisp users get the same source (if the quicklisp guys are fine of course) so no-one inside the community complaining is a good indication the software is fine. For this to work there's of course a relevant user-base of the distributor (quicklisp) necessary.

Relevance for Debian

So how do conventional Linux Distributions like Debian fit in here. Ideally we would have maintainers understanding and checking the software and confirming the integrity using their private key or at least know their upstreams and having at least a secured way getting the software from upstream and a trust relationship with them. Of course that's just illusionary thinking of complex and important software (think libreoffice, gcc or firefox for example). Maintainers won't fully understand a lot simpler pieces of software. And loads of upstream projects don't provide a verified way of getting the correct source code though that's a bit better on the real high-impact projects where checksums signed by the Release Manager are more common than in small projects.

A misguided thought at the end

As I'm a heavy emacs user I like to have snapshots from current emacs development available. Fortunately binary packages with this are available from a Debian guy I tend to trust who is also involved upstream so adding the key from his repository to the keyring apt trusts. Now my first thoughts were along the lines "It would be really nice if I could pin that key to only the emacs snapshot packages" so this guy can't just put libc packages in his repository and my apt would trust them. Now thinking of it again a bogus upload of the emacs snapshot package could just as well put some binary or library on the system at some place in front of the real on in the system path which would be rather similar bad.

Tags: debian, foss, linux, security, web.
Trying GNU/Hurd
6th May 2011

So this is a collection of things I came about when trying to get a Debian GNU/Hurd virtual machine running with kvm. Most of it is properly documented if you manage to find that particular piece of information.

Kernel Version

Due to a bug in linux 2.6.37 and .38 hurd will only boot if you supply -no-kvm-irqchip which is not that easy if you are using libvirt. A wrapper `kvm` script in the PATH will do, as will using a 2.6.39 kernel.


sudo will hang before returning from executing some command. I'm now using screen and sudo -i which keeps you a working tty gets you root and hasn't caused mayor trouble yet


openssh-server won't come up complaining about missing PRNG – and indeed there's no /dev/{u,}random in the default install. fix is to install random-egd from ports.

Tags: debian, howto, hurd, porting.
CSSH but without X
20th February 2011

There are many ways to run some commands simultaneously on multiple hosts like cssh or dsh. They come handy for example when you are installing software updates on a set of hosts.

dsh is a rather simple comandline tool allowing to execute a command over ssh on multiple hosts. However it doesn't allow any interactive input -- so you can't look at the potentially upgrading packages and press y to accept and you can't go through debconf promts or similar.

This is solved by cssh which opens a XTerm for every host and a input area that is broadcastet to all of them. this is working really well -- you can execute your update on all hosts and still do individual adjustments just as needed: switch focus from the broadcasted input to one of the terminal windows and anything you type just goes there.

Now cssh has a big disadvantage: it requires a running X server (and doesn't do too well with a fullscreen windowmanager). Requiring X is quite a blocker if you need to run that ssh multiplexer on a remote host, for example if the firewalling doesn't allow direct connections. Fortunately you can make tmux behave as we want -- in a simple terminal:

First you need a script spawning the ssh sessions in separate tmux panes and direct input to all of them -- here called (you could also write a tmux config I guess):

for i in $HOSTS
  tmux splitw "ssh $i"
  tmux select-layout tiled
tmux set-window-option synchronize-panes on

Now start the whole thing:

tmux new 'exec sh'

And be done.


If you want to type in just one pane (on one host) you can do that as well: C-b : set-window-option synchronize-panes off and moving to the right pane (C-b + Arrow keys)

Tags: debian, foss, howto, linux.
Debian GNU/kFreeBSD
29th December 2010

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


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.


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 ;))


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.

Tags: debian, foss, kfreebsd, programmieren.
[Review] AI Touchbook
26th April 2010

Having my primary working Computer, a Lenovo Thinkpad, going into repair at the end of December I finally got up to ordering on of those TouchBook ARM based netbooks I was looking at for some time. After some processing time it finally got shipped in April and arrived here last Monday, time to write up my first impressions.

Some words about the Hardware. The TouchBook ships with a so called "Beagle Board" featuring a OMAP3 Processor, ARM Cortex A8 running at 600MHz, 512MiB of RAM and a 8GiB SD Card for storage. It has a 8.9" touch screen and comes with USB and Bluetooth Sticks for wireless connectivity. The Display part contains all the needed Hardware and is detachable from the bottom that is just a keyboard sitting on the secondary Battery. You can open the Top to get at 4 intern USBs (3 USB-A and one Mini-USB) where 2 of these spots are occupied already for wireless networking and Bluetooth.

First experience

The TouchBook comes with an US Power Adaptor only so when I got the device I was running for some tiny Adaptor to get the plug into a normal EU Power Outlet (it's incredibly hard to get one for this Direction while it's easy to get some travelling stuff to plug EU Hardware into various different Outlets!).

When I finally booted it the first thing you'll notice is the touch interface for the bootloader. That's quite a difference to all-text-based old grub! The shipped SD Card offers 3 Operating Systems, one custom Linux that might well be interesting to the average User, a Ubuntu Karmic that really OK for a Debianoid Hacker- both running a XFCE Desktop - and a Android that is really slow and doesn't seem to be good at anything. Needless to say I sticked with the Ubuntu for now.

What to not expect

Well this is a 600MHz CPU with half a Gig of RAM running of a SD Card. So don't expect it to be good at anything that can profit from today's High-End Hardware.

The good Points

First of all, I have to admit that the touch screen is a neat interface, way superior to the Touchpad Area you'll normally find on a Notebook - at least if you use the stylus. It's quite different from the inside-the-keyboard trackball the thinkpads have of course.

The Website claims 10h of Battery life and while I've emptied the battery much faster under certain workloads (e.g. Playing cards) it does hold that promise with emacs fired up in org-mode, IRCing on a server over SSH and the mandatory wireless working. Same for a always-on on campus day which just works.

Again putting the screen on the keyboard the wrong way 'round will give you a touchscreen tablet with the keyboard out of your way, an ideal configuration for playing. And I have to admit playing games like gtkballs or aisle riot real fun. So much fun actually I'm currently thinking on whether it would be feasible to get openpandora working on it.

What I'm really missing

There are two Properties that are really lacking from the device which would make it (in my personal opinion at least) a whole lot better: A simple Ethernet controller I could use to go online when sitting in the server room doing some maintenance without taking my WRT with me and some slot to store the stylus when not using it where it's easy to get out (currently I'm having it in my wallet).

Then there's something (maybe a Kernel Bug): The Wireless is unable to find any new Access Point after disconnecting from some and walking out of reach from that. Force-unloading the kernel module and waiting 30 minutes worked for me multiple times but that's purely inacceptable.

Finally there are some minor glitches. The shiny red cover just gets dirty every time you touch the thing and the Keyboard is really small (what a surprise on a 9" device) and has some of the special Keys (like the Home key) located at unusual spots (Page-Up/Down only available through the FN modifier). Shift and End at the right side are also labeled opposite from their actual function (at least on Ubuntu).

The last ugliness is the top part battery only charging when the device is running, which means you"ll have the TouchBook running all night to get the battery charged and the Battery Monitor not working at all (at least in the current version of the operating systems).

Where to go now

I've not yet come around to really play with the operating system (apart from installing wicd, urxvt-unicode and awesome getting the most needed of my working environment). As I'm a Debian Developer I'll definitely need a Debian running on it (although I was told it'll be slow with software compiled for armv4te) and, as it needs to be running all night anyway, I'll try out gentoo pending another SD Card for experiments.

Secondly there's currently no useable conforming Common Lisp Implementation in Debian for armel as far as I can tell. As arm was already working it shouldn't be that hard, let's see if I can change that but feel free to join me!

Final Notes

I was thinking of some mobile-ish note-taking device and remote ssh terminal for University which the device clearly can do even for 10h away from any power plug while being some non-standard non-x86 device to toy on (It's actually my second armel next to the sheeva plug mounted on my window board.

As a final Remark: This blogpost was written on the TouchBook hacking some markdown into emacs while traveling by train to Erlangen where I study on Sunday Night after having read some chapters of Cory Doctorow's Little Brother on my E-Slick E-Book reader and finished later in my Room.

Maybe I'll find some time to write a review for this device as well one day!

Tags: debian, foss, linux, uni.
Another piece of well done software
31st March 2010

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.

Tags: debian, foss, programmieren, spaceshooter.
Open Game Art did it right
19th March 2010

Open Game Art is a newly started site for exchanging free Artwork. While one can easily get the impression that there are loads of such sites around, Open Game Art is one of the very few that actually is done right.

As a Member of the Debian Games Team and the Unknown Horizons Project I was way too often in the need for good artwork searching around the web. I've also already reported once about my trouble.

There are quite some sites like Free Sounds around offering free artwork -- but only free as in beer as the saying goes, not as in speech which of course is really unhelpfull for FOSS projects. And even most of the sites that have free content often only tell you the license on some special pice of arts details page.

Open Game Art is quite different from that. All the license you may choose as a contributor are free (both in Debian and in FSF terms) and the license is available through a search filter so you can find stuff that fits you project's licensing policy. This list, and that's another thing I really like about that site, is the availability of choice among common licenses including, next to the copyleft class of licenses a fair share of more liberal licenses like my personal favourite, the zlib License.

And because such a site is just as good as it's amount and quality of data I've started sharing some recordings. I'm currently really new to audio recording so I guess it'll take some time for me to become really good. I'm considering putting some of my experiences and stuff I've learned here.

Tags: debian, foss, unknown-horizons, web.
Introducing Debian GNU/kFreeBSD
1st September 2009

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:

Debian kFreeBSD mit Iceweasel und urxvt auf fluxbox Desktop

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:

Debian kFreeBSD mit Iceweasel auf awesome Desktop

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.

Versuch, lxterminal in LXDE auf Debian GNU/kFreeBSD zu öffnen

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.

Tags: debian, foss, kfreebsd, programmieren.
17th April 2009

Um Unknown Horizons weiter zu verbreiten habe ich jetzt ein 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 ... Ohloh profile for Christoph Egger

TODO: Einträge über NM und Debconf

Tags: debian, foss, programmieren, spaceshooter, unknown-horizons, vcs, web.
Erledigt: RC Bug
9th February 2009

#514416 erledigt -- unfreeze vorhanden. Heißt aber auch, dass ich jetzt erstmal genug davon habe, freie Bilder, Sounds zu suchen.

Nebenbei habe ich dann auch die ein oder andere Quelle zur Freedesktop Games Team Resourcen Liste hinzugefügt. Was wohl hier noch eine gute Möglichkeit wäre, ist die Zusammenarbeit/Zusammenlegung mit Freegamedev.

Tags: debian, foss.
Nocheinmal TopGIT
31st January 2009

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.


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.


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.

Tags: debian, programmieren, vcs.
Auf der Suche nach freien Texturen
30th January 2009

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 ;)

Tags: debian, foss, programmieren, web.
28th December 2008

LVM ist eine großartige Sache. Dynamische Volumes lassen sich jederzeit nach Bedarf vergrößern. Nie mehr raten, wie viel Platz für was nötig ist, einfach die Partitionen mitwachsen lassen.

Klingt alles nach einer netten Angelegenheit, warum also nicht für die neue USB-Festplatte verwenden? An sich eine Gute Idee. Falsch gemacht steht man allerdings schnell ratlos da.

z.B. wenn man die Volume Group nicht offline nimmt bevor die Festplatte vom USB-Port verschwindet. Nach eingehenden Experimenten kann ich bestätigen, dass das mitunter unerwartete Ergebnisse liefert.

  /dev/dm-3: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  /dev/dm-4: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  /dev/dm-5: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  LV     VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert                                 
  backup extern -wi-a-  50,00G                                      
  oggs   extern -wi-a-  50,00G                                      
  photos extern -wi-a- 100,00G 
$ mount /dev/extern/backup /media/extern/backup/
mount: /dev/mapper/extern-backup: can't read superblock

Was ist passiert? Ich bin kein LVM Experte. Die Erklärung sollte allerdings sein, dass durch das Entfernen und wieder Anstecken der Festplatte die Mappers nicht angepasst werden. LVM versucht jetzt von der bereits entfernten Festplatte zu lesen und nicht von der neuen.

Und jetzt? Das Problem selbst behebt sich relativ einfach:

$ vgchange -a n extern
  /dev/dm-3: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  /dev/dm-4: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  /dev/dm-5: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  0 logical volume(s) in volume group "extern" now active
$ vgchange -a y extern
  3 logical volume(s) in volume group "extern" now active

Was macht dise Befehlsfolge? Ersteinmal wied die nicht mehr funktionierende Volume Group offline genommen, danach wieder angeschaltet. Dadurch wreden auch die Verweise im Mapper angepasst. Danach sollte die Wechselfestplatte wieder normal ansprechbar sein. Und in Zukunft wird die Volume Group auf der Festplatte erst deaktiviert (vgchange -a n extern) und danach abgesteckt

Tags: debian.
26th December 2008

Server konfigurieren ist keine einfache Angelegenheit. Soweit klar. Allerdings kann es doch immer wieder überraschend sein wie schwer es manchmal sein kann.

Dieser Server lief lange Zeit mit SuSE 10.2 -- verhältnismäßig alt, es ist schwer irgendetwas neues zu installieren und die alte Administrationssoftware für unsere Webkunden war auch nicht das wahre. Ein Update kam nicht in Frage, niemand im Team hat die Erfahrung mit SuSE im generellen und die Konfiguration war vom Anbieter voreingestellt.

Da bald Debian Lenny released wird und immerhin ich einige Erfahrung mit Debian gesammelt habe stand dann fest, dass dieser Server mit eben jenem System betrieben werden wird.

Am 22.12. war es dann soweit. Ich mobil mit meinem Notebook beim zweiten Admin eingetroffen, die letzten Backups abgeschlossen, reset beantragt. Um 10 Uhr der Server dann mit etch einsatzbereit (Lenny gibt's nicht im Angebot aber ein update eines frischen Etch ist ja kein Problem).

Natürlich läuft nincht alles so, wie es soll. In diesem Fall der MTA, exim4. Wärend die Grundlegende Konfiguration auf den Einstellungen von SysCP eigentlich ganz gut funktionieren, ist beim MTA nacharbeit angesagt.

Für einen neuen Anlauf ein rm -rf /etc/exim4 + neuinstallation des Paketes war dann irgendwie keine gute Idee, sodass nach 14 Stunden Arbeit der Mailserver immer noch nicht lief.

Immerhin läuft jetzt alles, wie es soll, und das neue System war die Arbeit sicherlich wert!

Tags: debian, hier, web.
16th December 2008

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.

Tags: debian, programmieren.
24th November 2008

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!

Tags: debian, programmieren, vcs.

RSS Feed

Created by Chronicle v4.6