Tagged “gentoo”

Schlanker Compiz-Desktop mit xfce4-panel und .xinitrc

Published by cybso on 2008-04-14

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

~~Heute~~ gestern waren mal wieder ein paar Experimente mit diversen Windowmanagern angesagt. Eines vorweg, das geilste wäre die Toolbar von Fluxbox kombiniert mit den grafischen Effekten von Compiz und dem Application-Panel von XFCE. Naja, man kann nicht alles haben, insbesondere Fluxbox und Compiz ist eine Kombination, die nicht funktionieren kann.

Was mich an XFCE bisher störte, waren in erster Linie zwei Kleinigkeiten: Der doch recht behäbige Start, und dass für einige Anwendungen der Eintrag in der Taskbar fehlte (zum Beispiel beim Passwort-Dialog von KWallet und beim HBCI-Homebanking-Programm Moneyplex). Das zweite Problem ist im Entwickler-Repository bereits behoben. Der einfachste Weg, um als Gentoo-User an die neusten Versionen ranzukommen, ist, mit 'layman -a xfce' das XFCE-Development-Overlay einzubinden und dann die diversen xfce4-Pakete in die /etc/portage/package.keywords einzutragen:

(continue reading)

mplayer mit Compiz betreiben

Published by cybso on 2008-07-28

Vor einiger Zeit hatte ich vor, als Fenstermanager konsequent auf Compiz zu setzen. Leider scheiterte dieser Plan bisher vor allem an zwei inkompatiblen Programmen:

OpenOffice.org Impress, die freie PowerPoint-Alternative: im Präsentationsmodus wird das Panel, also die Taskleiste, über der Folie angezeigt.
mplayer, der beliebte Video-Allesfresser: das Bild flackert stark, hin und wieder stürzt der auch einfach ab

Gegen 1) habe ich noch kein Mittel gefunden, außer, für eine Präsentation auf den XFCE-Fenstermanager xfwm4 umzuschalten. Kann ich mit leben, da die wenigsten Beamer mit der von meinem Laptop bevorzugten Auflösung von 1400x1050 Pixeln problemlos zurechtkommen und ich daher sowieso die Einstellungen ändern muss.

Problem 2) ist dagegen sehr ärgerlich. Das Flackern hängt mit der Technik zusammen, die der bevorzugte und (zumindest bei mir) performanteste Video-Ausgabetreiber 'xv' nutzt. Sie verursacht Konflikte mit den Methoden, die Compiz einsetzt, um die Fenster zu rendern. Das Problem ist schon länger bekannt, aber der allgemeine Workaround war bisher, einen alternativen Ausgabetreiber wie 'x11' zu nutzen und den (nicht von 'x11' unterstützten) Vollbildmodus durch die Software rendern zu lassen:

mplayer -vo x11 -zoom -fs video.mpg

Keine schöne Lösung, da die Vergrößerung durch die Software aufwendig ist und das Video daher oftmals ruckelt. Heute bin ich durch Zufall auf einen Artikel in SmSpillaz' Blog gestoßen, welcher den von David Reveman geschriebenen mplayer-xv-Patch mplayrepatch.patch beschreibt. Dieser behebt das Problem, indem es (vereinfacht gesagt) die problematischen Aufrufe nicht an die Grafikkarte, sondern an Compiz übergibt.

Ich war ein bisschen skeptisch, aber tatsächlich, es funktioniert und ich stelle keine fühlbaren Performanzeinbußen fest. Und es klappt auch, wenn Compiz mal nicht aktiv ist. Für Gentoo-User habe ich den Patch in die aktuelleste stabile Version (1.0_rc2_p26753-r1) des mplayer-ebuilds eingebaut. Einfach die Datei mplayer-mplayrepatch-ebuild.zip in das lokale Portage-Overlay entpacken und mplayer neu kompilieren (sorry für die ZIP-Datei, tgz wurde von der Wordpress-Installation hier nicht akzeptiert).

syndaemon endlich mit einstellbarem Polling-Intervall

Published by cybso on 2008-07-31

Nachdem ich im April einen Bug-Report zum Synaptics-Ebuild erstellt habe, ist endlich ein entsprechender Patch von Florian Schäfer auch in das Gentoo-Portage eingeflossen (ab Version 0.14.6-r3, derzeit noch mit Keyword maskiert).

Kurz zusammengefasst: Der im Paket x11-drivers/synaptics enthaltene syndaemon überwacht die Tastatur und schaltet beim Drücken einer Taste das Touchpad vorrübergehend ab. Das soll verhindern, dass man versehentlich mit dem Handballen ein anderes Fenster aktiviert und der Text nicht dort ankommt, wo er hin sollte (im schlimmsten Fall verschickt man so ein Passwort per Instant Messanger). Das Problem ist, dass diese Abfragen in sehr, sehr kurzen Abständen erfolgen - alle 20ms. Das hindert die CPU bei Notebooks daran, in den Schlafmodus zu gehen, mit dem sie normalerweise Energieverbrauch und Abwärme reduziert (hat nichts mit dem Schlafmodus des Betriebssystem oder des Monitors zu tun - bei der CPU bemerkt man diesen Modus in der Regel garnicht, da sie bei Bedarf sehr schnell wieder auf volle Leistung geht). Beobachten kann man dies zum Beispiel mit dem von Intel entwickelten Kommandozeilen-Programm "PowerTop". Im Ergebnis bedeutet das schlicht und einfach eine geringere Akkulaufzeit.

Der neue Patch fügt einen Kommandozeilenparameter hinzu, mit dem das Abfrage-Intervall konfiguriert werden kann. Der Aufruf "syndaemon -m 500" reduziert dieses zum Beispiel auf 500ms, was für den normal schnellen Menschen immer noch ausreichend sein sollte. Wer XFCE benutzt, kann diesen Befehl zum Beispiel in eine ausführbare Datei im Verzeichnis '~/.config/autostart' ablegen, KDE-Benutzer schauen unter '.kde/Autostart' nach und Gnome... naja, weiß ich gerade auch nicht :-) Für diejenigen, welche sich ihren XFCE-Desktop nach meinem Vorbild verschlankt haben, habe ich inzwischen eine bessere .xinitrc geschrieben, die das Verzeichnis '.config/autostart' auswertet und alle ausführbaren Dateien startet.

Übrigens: Ich bin im Portage *g*!

30 Jul 2008; Samuli Suominen +files/synaptics-0.14.6-configurable_polling_interval.patch, +synaptics-0.14.6-r3.ebuild: Apply configurable polling interval patch from Novell so that syndaemon doesn't wake up CPU so often. Bug 216679, thanks to Roland Tapken, Thomas Kirchner and Krister Bäckman.

X.Org, evdev und HAL - Teil 2

Published by cybso on 2008-08-14

Gentoo-Technobabble-Warnung Dieses Problem hat mir natürlich keine Ruhe gelassen, und ich habe (wider aller Vernunft) weiter experimentiert. Die beiden beobachteten Phänomene sind unabhängig voneinander. Das Keyboard-Problem beruht auf einem Konflikt zwischen HAL und X.Org, und lässt sich durch eine kleine Anweisung in der Section "ServerLayout" lösen:

Option "AutoAddDevices" "no"

Nun funktionieren auch die Sondertasten mit lineakd oder keytouch wieder. Die Datei /etc/hal/fdi/policy/10-x11-input.fdi sieht ansonsten genauso aus wie im letzten Beitrag.

Das Mausproblem (mittlere Maustaste wirkt in Opera wie ein Linksklick, funktioniert sonst aber normal) hat mir mehr Kopfzerbrechen bereitet. Erst als ich mir die von der Maus bei einem Klick auf das Scrollrad gesendeten Events mit xev mal etwas genauer angeschaut habe, ist mir etwas aufgefallen:

ButtonRelease event, serial 30, synthetic NO, window 0x4400001,
    root 0x7f, subw 0x0, time 1553709, (136,123), root:(1305,178),
    state 0x200, button 2, same_screen YES

ButtonRelease event, serial 30, synthetic NO, window 0x4400001,
    root 0x7f, subw 0x0, time 1553709, (136,123), root:(1305,178),
    state 0x0, button 8, same_screen YES

(continue reading)

#gentoo

X.Org, evdev und HAL

Published by cybso on 2008-08-14

Gentoo-Technobabble-Warnung

Vor ein paar Tagen habe ich ein Update meines Gentoo-Systems gemacht, und mit einem Mal war nichts mehr so wie vorher (ok, ich übertreibe). Zuerst stürzte der X-Server ab, wenn ich meine USB-Tastatur (Microsoft Comfort Curve Keyboard 2000) angeschlossen habe. Vernünftig, was lasse ich auch Microsoft-Hardware an mein Laptop dran. Dennoch merkwürdig, denn vom X-Server wurde nichts aktualisiert, nur das Paket in der selben Version ( x11-base/xorg-server-1.4.2) neu gebaut. Auch am Kernel wurde nichts geändert. Ich war also schon ziemlich erstaunt an dieser Stelle.

Schnell konnte ich den "evdev"-Treiber als Verursacher ausfindig machen. Ein Update auf x11-drivers/xf86-input-evdev-1.2.0 hat dieses Problem auch wieder behoben, ich konnte die Tastatur wieder anschließen. Nun gab es aber zwei neue Probleme: das Tastatur-Layout war auf einmal 'us' (also amerikanisch) und die mittlere Maustaste funktionierte nicht mehr.

Diese Symptome haben mich auf den richtigen Weg gebracht: Ich hatte bis vor kurzem die Regel ' x11-base/xorg-server -hal' in der Datei /etc/portage/package.use stehen, und diese leichtsinnigerweise entfernt. Deshalb überließ der X-Server nun die Anbindung von Tastatur und Maus dem "Hardware Abstraction Layer" HAL. Gut, das kann ja nicht so falsch sein, dachte ich, und fand auch schnell heraus, wie ich das korrekte Layout einstellen kann. Es genügt, die Datei /etc/hal/fdi/policy/10-x11-input.fdi mit folgendem Inhalt befüllen:

(continue reading)

#gentoo

cpufreqd: select rule depending on external command

Published by cybso on 2008-09-25

Cpu Frequency Daemon is a very configurable program for throttling the cpu's frequency depending on "rules". A rule tests for battery state, cpu temperatur, active processes and so on.

For example, a rule which throttles your cpu when it's to hot might look like this:

[Rule]
name=CPU Too Hot
acpi_temperature=65-100
cpu_interval=50-100
profile=Performance Low
[/Rule]

And if you want full performance when watching movies you might have a rule like this:

[Rule]
name=Movie Watcher
programs=xine,mplayer,gmplayer
battery_interval=0-100
acpi_temperature=0-60
profile=Performance High
[/Rule]

(For more examples, have a look at the manpage)

As a Gentoo user I want full cpu power when emerge is running. But sadly, "programs=emerge" won't work because emerge' process actually is the python interpreter (and surely you don't want to define "programs=python" as it would fire on your processor for all python scripts):

$ ps a | grep emerge
13423 pts/2    SN+    0:02 /usr/bin/python -O /usr/bin/emerge libc

So what we need is a cpufreqd.conf-statement which executes a shell command and scores the rule depending on the process' exit code (0 is good and anything else is bad). There is already a plugin, "exec", which executes a command before and after testing a rule or switching the profile, although this is not exactly what we want. Nevertheless the code of this plugin (cpufreqd_exec.c) only needs a few changes to get a new options called "exec" which does exactly what we need (I've attached patches for cpufreqd-2.2.1 and cpufreqd-2.3.3).

The rule for switching to "Performance High" when emerge is running now looks like this:

[Rule]
name=emerge is running
exec=ps -u root | grep emerge
battery_interval=0-100
acpi_temperature=0-65
cpu_interval=0-100
profile=Performance High
[/Rule]

(If somebody knows an more efficient method to check wether emerge is running or not, please post it into the comments).

X.Org, evdev und HAL - Teil 3

Published by cybso on 2008-10-05

Technobabble-Warnung

Eigentlich dachte ich, das Problem aus dem Zusammenspiel von X11, Multimedia-Tastatur, evdev-Treiber, HAL und LinEAK sei gelöst gewesen - doch hat "roo" mich in den Kommentaren darauf aufmerksam gemacht, dass mit dem xorg.conf-Schalter “AutoAddDevices = no" einfach nur HAL deaktiviert wurde. Das funktioniert zwar, ist aber nicht das, was man gerne haben möchte - nämlich die Verwaltung aller Eingabegeräte an einer zentralen Stelle, im "Hardware Abstraction Layer".

Nun hat "roo" am Dienstag einen weiteren Kommentar geschrieben, den ich jedoch übersehen habe:

Also ich hab herausgefunden, dass das Problem nicht bei HAL, nicht bei evdev und auch nicht bei X liegt. Sondern beim Desktop Environment - sprich Gnome/Xfce/KDE. Habe nämlich mal Fluxbox emerged und damit mal probiert (Fluxbox lässt sich ja fix emergen und starten). Und dort habe ich diese Probleme nicht. Alle Tasten werden von xev perfekt erkannt. Und verursachen keine Probleme.

Tatsächlich hatte ich auch schon eigene Experimente durchgeführt, und bin zu dem gleichen Ergebnis gekommen: Unter Fluxbox kann ich alle Tastencodes der Spezialtasten mit xev beobachten, unter XFCE jedoch nicht die Lautstärketasten - und ausgerechnet die hatte ich in meinem letzten Beitrag meistens zum Testen verwendet.

In der Ausgabe von xev sind mir dann jedoch einige Details aufgefallen (hier als Beispiel für die Taste "Startseite"):

(continue reading)

Quo vadis, Gentoo?

Published by cybso on 2008-10-30

Die meisten, die mich persönlich kennen oder durch das Archiv dieses Blogs stöbern, wissen, das Gentoo meine absolute Lieblingsdistribution ist. Der Grund ist für mich vor allem das Paketsystem "Portage" bzw. das Konzept der Use-Flags, welche eine Anpassung des System auf einem Level erlaubt, zu dem man bei den üblichen Binärdistributionen wie Ubuntu, SuSE, RedHat und co nur mit sehr großem Aufwand gelangen kann - der User "BliZZarD" hat das Anfang des Jahres im Heise-Forum ziemlich gut auf den Punkt gebracht.

Doch seit sich vor einigen Jahren der Gründer Daniel Robbins aus dem Projekt zurückgezogen hat, lässt das System spürbar nach. Zunächst hielt ich das Editorial im aktuellen LinuxUser (11/2008) für übertrieben - doch beim letzten Update stieß ich auf das in Bug #244511 beschriebene Problem.

Offenbar bereits seit drei Tagen sind Pakete als "Stable" markiert, die zur Installation die noch als unstable geltene Portage-Version 2.1.5 benötigen. Im Ergebnis sieht man beim Versuch, ein Update durchzuführen, im Moment folgende Ausgabe:

Calculating world dependencies... done!
[ebuild U ] sys-libs/com_err-1.40.9 USE="nls" 0 kB
[ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 0 kB
[ebuild U ] sys-fs/e2fsprogs-1.41.2 USE="nls" 0 kB
[ebuild U ] sys-libs/ss-1.40.9 USE="nls" 0 kB
[blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9,sys-libs/com_err-1.40.9)

Die übliche Lösung bei solchen "blockings" ist es, das betroffene Paket vor dem Update zu entfernen. In diesem Fall wäre das aber hochgradig fatal, denn das zum Download der Pakete verwendete Programm "wget" hängt von der Systembibliothek "com_err" ab, wie Robert Wolf bereits vor zwei Tagen feststellte. Dieser auch von den Entwicklern empfohlene und normalerweise korrekte Weg würde einem das System also beschädigen und unter Umständen nur mit recht hohem Aufwand wiederherstellbar machen (sprich: die benötigten Pakete an einem anderen Rechner herunterladen und anschließend kopieren).

Die Lösung ist eigentlich einfach und von Daniel Carosone in Beitrag #40 beschrieben: Die Pakete wieder als unstable markieren, bis portage-2.1.5 stabil geworden ist und die Blockings selber Auflösen kann. Doch bis jetzt ist nichts passiert. Für das Projekt ist das wirklich peinlich, mit einer stabilen Version, die sich seit drei Tagen nicht sauber aktualisieren lässt, macht sich das Projekt wirklich keine Freude.

Wer davon betroffen ist, kann entweder (1) Portage in der Version 2.1.5 als stabil markieren und anschließend auf diese Version wechseln:

echo '=sys-apps/portage-2.1.5*' >> /etc/portage/package.keywords
emerge -uav portage

oder (2) die Installation der blockierten Pakete verhindern:

echo '=sys-fs/e2fsprogs-1.41.2' >> /etc/portage/package.mask

Obwohl ich mit beiden Verfahren erfolgreich war, ist (2) meine klare Empfehlung. Zumindest solange, wie es keine saubere Lösung für das Problem gibt und man auf die neuere Version der Programme nicht angewiesen ist.

s/gentoo/ubuntu/

Published by cybso on 2008-11-01

Probier ich es aus? Ich weiß nicht... Eventuell. Aber vielleicht doch nicht. Ich bin so unentschlossen. Hat jemand ne Meinung dazu?

Change

Published by cybso on 2008-11-03

Ich habe habe dem unerschrockenen Steinbock eine Chance gegeben, und mein Gentoo-System auf eine Backup-Festplatte ausgelagert. Aktuell bin ich von KDE 4.1 ziemlich begeistert, aber ob dieser Zustand anhält, werden die nächsten Wochen zeigen müssen. Insbesondere Portage werde ich vermutlich bald vermissen.

Was mir besonders positiv aufgefallen ist, ist die sehr gute Unterstützung für verschlüsselte Systeme. Nicht nur, dass ich ohne großen Aufwand meine gesamte Festplatte verschlüsselt habe - auch im Schlafzustand ist der Rechner nun geschützt. Und das, ohne dass ich irgendwas dafür tun musste. Bisher war es so, dass mein Homeverzeichnis zwar verschlüsselt war, aber nicht der Auslagerungsspeicher. Dadurch ist es theoretisch möglich, den Schlüssel dort zu extrahieren, was natürlich das ganze Konzept über den Haufen wirft.

So, nun muss ich aber erstmal ein paar fehlende Programme nachinstallieren. Wo ist Opera?

Gentoo and me (Update)

Published by cybso on 2010-08-30

Mein Laptop betreibe ich aufgrund der damaligen Arroganz der Entwickler bereits seit fast zwei Jahren nicht mit Gentoo Linux. Und hab es auch ehrlich gesagt auch nicht bereut. Aber der Web- und Mailserver, auf dem zum Beispiel auch tasmiro.de liegt, blieb weiterhin auf diesem OS. Überstand sogar einen Serverumzug und später die Migration in eine KVM. Doch gestern abend passierte ein Unglück. Eigentlich ein harmloses Update mit "emerge -Du world", wie schon duzende Male zuvor gemacht. Keine Fehlermeldung oder so. Doch als der Server auch nach 10 Minuten nicht neu gestartet war, schaute ich nach. Die genaue Todesursache hab ich nicht identifizieren können, vermutlich es hängt irgendwie mit udev und/oder baselayout zusammen. Der Kernel findet noch beide (virtuelle) Festplatten, aber es wird kein Eintrag in /dev erstellt. Dadurch scheitert das Mounten und dem System fehlen /boot, /var und /home.

Nun ja, ich habe einige Stunden lang versucht, das Leben des Patienten zu retten, aber vergeblich. Da er schon sehr alt ist, und auch einige Geschwülste (also nicht vollständig entfernte, aber inzwischen überflüssige Programme) hat, werde ich ihn ziehen lassen. Im Moment erstelle ich das letzte Backup seines Lebens, danach schließe ich die VM wieder an die Herz- grml-Maschine an, und heute abend kümmere ich mich um ein neues System.

RIP, Gentoo.

[Klarstellung: Damit ist nicht gemeint, dass ich Gentoo den Untergang wünsche, im Gegenteil - die Welt braucht solche Distributionen. Aber für mich persönliche war dies das letzte noch im Einsatz befindliche System, welches nun auf eine andere Distribution migriert wird. Entsprechend ist der "Nachtrag" auch als eine persönliche Anmerkung zu betrachten; solche Situationen sind auch bei Gentoo gewiss nicht an der Tagesordnung.]

Nachtrag:

Ich muss es einfach nochmal erwähnen: Dass ein Linux-System nach einem regulären Update nicht wieder startet ist der absolute Worst-Case. Vor allem wenn nicht einmal der Kernel betroffen ist darf das einfach nicht passieren. In diesem Fall hatte ich Glück, dass es sich um eine virtuelle Maschine handelt und ich damit auch ohne SSH an das Ding rankomme, es sogar von einem Rettungssystem booten kann. Wäre es das Hostsystem gewesen, dann hätte ich mir die Nacht um die Ohren schlagen dürfen, weil die provisorische Inbetriebnahme kaum möglich gewesen wäre.

Nachtrag 2:

Nach dem Hinweis von Linux Freund in den Kommentaren habe ich nochmal weiter recherchiert. Es lag an den Kernel-Flags "CONFIG_SYSFS_DEPRECATED" und "CONFIG_SYSFS_DEPRECATED_V2". udev hatte mich zwar darauf hingewiesen, dass es damit ein Problem geben könnte. Da ich nicht viel Zeit hatte, kompilierte ich deshalb einen Standardkernel mit "genkernel". Hätte ich ahnen sollen, dass auch dieser diese Flag enthalten würde? Keine Ahnung... unvernünftigerweise hatte ich mich darauf verlassen, dass da schon ein Kernel herauskommen würde, mit dem jedes normale Gentoo-System funktioniert. Tat es aber nicht. Nun habe ich meinen ursprünglichen Kernel nochmal ohne diese Flags kompiliert, und das System fährt hoch. Leider hat der Up- und Downgrade des "baselayouts" von 1 auf 2 und dann wieder auf 1 wohl doch noch etwas mehr kaputt gemacht.