TLP für Suse

L

lupinix

New member
Themenstarter
Registriert
22 Feb. 2011
Beiträge
37
Ich kann mal schauen ob sich das Ganze auf openSUSE und Slackware portieren lässt. Ber ich mach erst eine Zusage wenn ich es zum laufen bekommen hab ;)

Viele Grüße
lupinix
 
So mal auf openSUSE probiert, gibt beim make install den Fehler
Code: 
install -m 755 tlp-ifup /etc/network/if-up.d/tlp-ifup
install: reguläre Datei „/etc/network/if-up.d/tlp-ifup“ kann nicht angelegt werden: Datei oder Verzeichnis nicht gefunden
make: *** [install] Fehler 1
Das Verzeichnis /etc/network gibt es bei Suse nicht, mal schauen wie man da am besten vorgeht.

Viele Grüße
lupinix
 
Suse nutzt eben eine andere Art der Netzwerk Konfiguration. Irgendwo legt yast das Zeug ab. Muss nur schauen wo und dementsprechend anpassen.

Edit: Nur noch als Zusatz: openSuse, Fedora etc. funktionieren aufgrund ihrer Vergangenheit etwas anders als Debian/Ubuntu. da ich bisher noch nie tlp genutzt habe bzw. geschaut habe wo wie welche Änderungen eingebracht werden, kann ich nichts weiter dazu sagen.

Da mir momentan der Anreiz fehlt, weil ich alles so am Laufen habe, habe ich mich auch noch nicht damit auseinandergesetzt. Sollte aber keine allzu große Sache sein.
 
Genau das meine ich. Der rest scheint zu gehen, hab die Tage schon mit den Tools rumgespielt.
 
Das ebuild? xD Das wartet darauf, von dir zusammenkopiert zu werden.

Ich mach das bestimmt nicht, ich werde kein TP mehr mit Gentoo quälen.
 
Habe zum Test mal erste rpms gebaut, im Buildservice für openSUSE 11.3, funktionieren auch mit 11.4.
http://download.opensuse.org/repositories/home:/cdersch/openSUSE_11.3/

Was mir dabei aufgefallen ist: Die Pfade zu /usr/lin/tlp-pm/… scheinen in den Skripten eingecodet zu sein, wollte erst wie es laut Suse sein sollte in /usr/lib64 kopieren, geht nicht.

Viele Grüße
lupinix

EDIT: Ihr braucht nur zusätzlich noch tm_smapi passend zum Kernel damit alle Features gehen. Sonst keine weiteren Abhängigkeiten.
 
Ist das überhaupt abhängig von der Architektur? Ich dachte tlp wäre gescripted, d.h. noarch.

Kannst ja einmal sed darüber jagen, damit die Pfade geändert werden. Wenn es aber tatsächlich noarch ist, muss das mWn nicht in /usr/lib64 sondern wirklich in /usr/lib

Braucht man für den Buildservice keine .spec files?
 
Doch spec Files braucht man da, aber die sind ja recht flott geschrieben. Das mit der Architekturabhängigkeit kommt von den 3 Dateien für pm-utils, die müssen bei 64 Bit in /usr/lib64 liegen, die anderen liegen in /usr/lib.

Spec und anderes gibts hier: https://build.opensuse.org/package/files?package=tlp&project=home:cdersch

Wie man da auch sehen kann ist der Build für 11.4 fehlgeschlagen, Spec ist identisch zu der für 11.3, aber die Prüfungen wurden im Buildservice verschärft und ich habe einen kompletten /usr/lib/tlp-pm Dateipfad drin statt eines Makros, da letzteres bei 64 Bit sonst in /usr/lib64/tlp-pm landen würde. Das soll angeblich nicht ganz sauber sein. Falls da wer eine Idee hat, wäre es nett die hier zu posten.

Viele Grüße
lupinix

EDIT: Makefile musste auch gepatcht werden.
 
Hi,

hier wird ja schon mächtig gehobelt :D. Ich hoffe es hat niemand was dagegen, wenn ich den Suse-Teil in einen eigenen Thread "TLP - Paketierung für Suse"" auslagern lasse?

Hier noch ein paar Hinweise für dich, lupinix:
  • TLP besteht rein aus Shellskripten (Posix) und ist daher nicht architekturabhängig -> noarch (oder "all" wie es bei Debian heißt).
  • Außer im Makefile sind in den Skripten Pfade hartcodiert - stehen gleich am Anfang, meist unter "# Definitions". Das betrifft hauptsächlich TLP-Interna und diverse benutzte Systemkommandos, da ich mich nicht auf PATH verlassen wollte: tlp-functions, tlp-ifup, tlp-rf-func, tlp, tlp-rf, tlp-stat
    -> hier mußt Du ggf. patchen.
  • In tlp-nop ist /usr/lib/pm-utils/power.d/ aus dem Paket pm-utils hartcodiert -> ggf. patchen
  • Eine weitere Besonderheit ist unter debian/ zu finden, die Post-Installations- bzw Post-Deinstallations-Skripte des Deb-Package. Ich brauche das um diverse Funktionalitäten von pm-utils auszuschalten, die ich selbst implementiere (die pm-utils-Funktonen sind OK, aber für den Benutzer nicht gescheit parametrierbar). Dazu muß man einfach unter /etc/pm/power.d/ ein Skript mit dem gleichen Namen wie das pm-utils-Skript unter /usr/lib/pm-utils/power.d/ anlegen. Ich verlinke dann einfach tlp-nop. Ich kenne die pm-utils-Version von Suse nicht, denke aber, daß wir es dort auch brauchen:
tlp.postinst
Code: 
# Disable conflicting pm-utils hooks
for i in 95hdparm-apm disable_wol hal-cd-polling intel-audio-powersave laptop-mode \
        journal-commit pcie_aspm sata_alpm sched-powersave wireless \
        xfs_buffer; do
    if [ -x /usr/lib/pm-utils/power.d/$i ]; then
        ln -sf /usr/lib/tlp-pm/tlp-nop /etc/pm/power.d/$i
    fi
done
tlp.postrm
Code: 
# Remove pm-utils hook disablers
for i in 95hdparm-apm disable_wol hal-cd-polling intel-audio-powersave laptop-mode \
        journal-commit pcie_aspm sata_alpm sched-powersave wireless \
        xfs_buffer; do
    if [ "$(readlink /etc/pm/power.d/$i)" = "/usr/lib/tlp-pm/tlp-nop" ]; then
         rm /etc/pm/power.d/$i
    fi
done
  • Aufgrund der Erfahrungen hier, würde ich dann gerne noch den Upstream-Tarball anpassen, um den gemeinsam genutzten Teil besser abzugrenzen, z.B. indem ich die man pages aus debian/ rausnehme.
  • Was ich nicht ganz verstehe: liegen beim Suse pm-utils-Package tatsächlich Skripte unter /usr/lib64/pm-utils/power.d/ ? :confused:
 
Die pm-utils Skripte liegen doch in /usr/lib, da hat mir im IRC einer Mist erzählt als ich meine Spec gepostet hab, das muss noch geändert werden. Ich denke mal dann bleibt alles in /usr/lib, da wie gesagt noarch. Die Besonderheiten in debian/ muss ich mir mal anschauen.

Viele Grüße
lupinix

EDIT: Thread-Auslagerung für Suse waäre wohl sehr sinnvoll.
 
Die Tage werd ich mal die postinst und postrm Sachen integrieren. Bisher läuft TLP auf Suse super, konnte bei mir (X200 und R400) den Verbrauch damit um ein paar Watt senken und funktioniert hat bisher alles.
 
Hi,

hört sich gut an :).

Aus den bisherigen Erfahrungen plane ich, die hartkodierten Pfade zu Systemtools soweit wie möglich auszubauen und noch ein paar Anpassungen vorzunehmen die das Paketieren für andere Distris erleichtern sollen.
 
Ja, ich bin noch an dem Thema dran, hatte die letzten Tage nur zuviel zu tun um hier rumzulungern :P Die Doku sieht fein aus, erleichtert das Paketieren immens. Danke dafür!

Viele Grüße
lupinix
 
Habe die Pakete nun auf Version 0.3.0.201 aktualisiert, außerdem wird der tlp Dienst nun bei der Neuinstallation des Paketes automatisch gestartet und die Symlinks für die Stromsparfunktionen werden bei Installation gesetzt sowie bei Deinstallation wieder automatisch entfernt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben