Frustblogging, heute: Kurzsichtige Kerneldespoten

Vorweg: ich habe zeitlebens meines Wissens nicht mal einen Kommentar zum Linux-Kernel beigetragen — vielleicht disqualifiziert mich dies, das Folgende zu schreiben. Wenn es so wäre, so sei es. Kann ich besser mit um jedenfalls als mit so mancher hirnrissigen maximal problematischen Entscheidung der Maintainer des Linux-Kernels …

Und wieder geht ein Abend ins Land. Ob mein Sodbrennen von der unheiligen Idee, UTS_RELEASE aus …/include/linux/version.h nach …/include/linux/utsrelease.h zu verschieben kommt, weiß ich nicht. Vorstellbar wäre es jedenfalls.
Was mein Problem ist? Ach, eigentlich keines, ich wollte nur – packagemanagementkonform – motion 3.2.9 für Debian Etch bauen. Mal eben schnell, geht ja ratz-fatz mit Debian-Bordmitteln … Aber denkste, Puppe: vor den Erfolg haben die Herren Kernel-Matadore den »Errors were encountered« gesetzt:

Setting up cpad-kernel-source (0.10-3) ...
/var/lib/dpkg/info/cpad-kernel-source.postinst: line 49: [: too many arguments
Warning: kernel headers don't match running Linux version.
Building cpad module for Linux _CODE 13262 (this may take a few minutes)...dpkg: error processing cpad-kernel-source (--configure):
subprocess post-installation script returned error exit status 2
Setting up wacom-kernel-source (0.7.4.1-5) ...
/var/lib/dpkg/info/wacom-kernel-source.postinst: line 49: [: too many arguments
Warning: kernel headers don't match running Linux version.
Building wacom modules for Linux _CODE 13262 (this may take a few minutes)...dpkg: error processing wacom-kernel-source (--configure):
subprocess post-installation script returned error exit status 2
Setting up fakeroot (1.5.10) ...
Errors were encountered while processing:
cpad-kernel-source
wacom-kernel-source
E: Sub-process /usr/bin/dpkg returned an error code (1)

So auf Dauer nervt das schon etwas, also fütterte ich die allwissende Müllhalde und bekam auch eine nur bedingt hilfreiche Antwort. Großes Kino also, eine Variable. die Skripte zur Ermitteln der Version der Kernel-Sourcen nutzen, wird mal eben von version.h nach utsrelease.h geschoben. Raider heißt jetzt Twix — und der Build bricht ins Essen:

rescue:/old-raid# more /usr/src/linux-headers-2.6.18-5-k7/include/linux/version.h /usr/src/linux-headers-2.6.18-5-k7/include/linux/utsrelease.h
::::::::::::::
/usr/src/linux-headers-2.6.18-5-k7/include/linux/version.h
::::::::::::::
#define LINUX_VERSION_CODE 132626
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
::::::::::::::
/usr/src/linux-headers-2.6.18-5-k7/include/linux/utsrelease.h
::::::::::::::
#define UTS_RELEASE "2.6.18-5-k7"

Lustigerweise – die Kiste, wo ich grade drauf builde, diente initial als Rekontruktionskiste für ein nach einem Doppel-RAID-Fehler unpäßlichen Devices – findet sich auch noch ein älteres version.h, welches diesen Dünnsinn nicht mitgemacht hat:

rescue:/old-raid# more /old-raid/angua/usr/include/linux/version.h
#define UTS_RELEASE "2.6.18"
#define LINUX_VERSION_CODE 132626
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

Finde ich jedenfalls alles richtig suuuper. Da hat jemand aber wirklich den Bruchteil einer Sekunde nachgedacht, bevor #define UTS_RELEASE aus version.h eliminiert wurde. Höchstens den Bruchteil einer Sekunde …
Danke dafür.