Posts by Tobi

    Quote

    Original von gda
    Was du übernimmst ist natürlich deine Sache, aber einen Begründung wäre mir dann schon wichtig. Wenn wir allerdings wirklich zusammenarbeiten wollen, dann sollte es eigentlich nicht sein, dass du alleine entscheidest welche Änderungen übernommen werden.


    Werd ich beherzigen. Wenn dir irgendwo ein Begründung fehlt, muss du sie einfach einfordern. Fällt dir da spontan was ein, wo ich das versäumt habe?


    Quote


    Das sehe ich ein, das ist ein Problem. Wir werden zumindest für zukünftige Änderungen darauf achten. Bei den Paketen bei denen wir davon geeilt sind können wir ja so was wie 1.0-1.0yavdr0.x machen, um dir eine Chance zu geben aufzuholen.
    erald


    Wenn ihr schon bei 1.0-2yavdr1 seid, klappt das so nicht, da 1.0-1.0yavdr0.x < 1.0-2yavdr1. Theoretisch würde sich das alles erst mit den nächsten Upstream-Releases wieder synchronisieren, die bei manchen Paket aber wohl nie kommen werden.

    hotzenplotz5 : Sollte jetzt nicht abwertend klingen, weder für yaVDR noch die Debian-Pakete.


    gda : Wenn ich auf Rückfragen nicht reagiere ist das keine Absicht. Manche Dinge gehen nur ganz einfach unter oder verschwinden vom Radar, weil ich zu lange keine Zeit hatte mich damit zu beschäftigen.


    Lass dich also nicht davon abhalten, mir Änderungen zu schicken - auch wenn ich die nicht 1:1 übernehme ist jede Zuarbeit immer willkommen!


    Was mich momentan an yaVDR am meisten stört, sind die Versionsnummern. Für jeden Rebuild wird die Debian-Revision hochgeschraubt. D.h. aus vdr-plugin-foo 1.0-1 wird 1.0-2yavdr1 u.s.w.. Wenn ich jetzt im "Originalpaket" Änderungen mache, wird das vdr-plugin-foo 1.0-2 während yaVDR mit der Versionsnummer davon gerannt ist. Uns fehlt so der Überblick, was sich in yaVDR geändert hat und umgekehrt gehen yaVDR Änderungen durch die Lappen, die wir an den Paketen mache.


    Schöner wäre es, wenn yaVDR nur den NMU-Part erhöhen würde, also 1.0-1.0yavdr1, 1.0-1.0yavdr2 u.s.w.


    Gewissermaßen ist da das Kind allerdings schon in den Brunnen gefallen, da die Versionen in yaVDR nicht einfach zurückgedreht werden können.


    Außerdem haben bei yaVDR ein paar Pakete eine Debian-Revision bekommen, die native Debian-Pakete sind (also ohne Upstream). z.B. vdr-addon-acpiwakeup. Eigentlich sollte da auch Lintian meckern.


    Ist jetzt aber hier irgendwie der falsche Platz um sowas zu diskutieren. Wie wäre es, wenn wir Änderungen an den gemeinsamen VDR-Paketen in Zukunft auf der Mailinglist des "VDR and DVB packaging Project" diskutieren?


    http://lists.alioth.debian.org…istinfo/pkg-vdr-dvb-devel


    (Ich muss da nur mal schauen, wie man sich den Spam besser vom Halse hält)


    Ich könnte auch ein Projekt auf projects.vdr-developer.org erstellen und wir könnten dort den Issue-Tracker verwenden.

    Ich hab gerade mal spaßeshalber das yaVDR-Unstable-Repository mit meinem Squeeze-Repository verglichen. Es gibt eine Überschneidung in 130 Paketen. Davon unterscheiden sich 70 Pakete nur im changelog. In diesem Fall hat das yaVDR-Team einfach nur die Versionsnummer gändert. Leider nach einem etwas unglücklichen und z.T. auch fehlerhaften Versions-Schema, wodurch der Bezug zum "Original-Paket" verloren geht. 19 Pakete haben scheinbar eine neuere Upstream-Version (z.T. scheinbar jüngere VCS-Snapshots). Bei 3 Paketen hinkt yaVDR mit der Upstream-Version hinterher. Bei den restlichen Paketen scheint yaVDR die letzten Änderungen (von meiner Seite) nicht gemerged zu haben oder yaVDR verwendete andere Defaults.


    Im großen und ganzen ist yaVDR also noch mehr oder weniger "baugleich" zu meinen Paketen. Die wesentlich Unterschiede sehe ich abgesehen von der Distri derzeit nur im Installer, dem Admin-Tool und der XBMC-Unterstützung. Ich fürchte aber, yaVDR und Debian/e-tobi werden auch bei den VDR und Plugin-Paketen in Zukunft weiter auseinanderdriften, da es derzeit in beiden Richtungen eigentlich nicht viel an aktiver Zusammenarbeit gibt.

    Hab mir jetzt nichts spezielles dabei gedacht. Wie gesagt - ob es nochmal ein c't-VDR 8 in Form eines ISO-Images geben wird kann ich nicht sagen. Damit sich das lohnt müsste wahrscheinlich einiges gemacht werden um die "Installations- und Administrations-Experience" zu verbessern. Schon allein um "konkurrenzfähig" zu YaVDR & Co. zu sein.


    Die c't-VDR-Pakete (was nichts anders ist als die Debian/e-tobi-Pakete) wird es aber auch weiterhin geben. Das ist schliesslich das was ich selber nutze.

    c't-VDR war im Grunde nie etwas anderes als ein Debian + die VDR Pakete aus meinem privaten Repository - halt nur zusammen auf eine CD gepresst. An den Pakete wird auch weiterhin gearbeitet. Diese sind prinzipiell ja auch wieder die Basis von YaVDR & Co.


    Generell hätte ich schon Lust, c't-VDR als rein Debian-basierte Distribution weiterzuführen (inzwischen kann man sich da sicher vieles von YaVDR abschauen) aber dafür fehlt einfach die Manpower. Ich konzentrieren mich daher lieber darauf, die Debian-Pakete aktuell zu halten.


    Im Grunde genommen ist eine manuelle Installation von VDR & Co. auf einem Debian Squeeze mit den Paketen aus meinem Repository auch nicht wesentlich schwieriger als YaVDR oder easyVDR - denke ich zumindest - als absoluter Noob sieht man das vielleicht anderes.

    @VDRFirtie: Die ACPI-Aufwachfunktion hat mit der im BIOS grundsätzlich erstmal nichts zu tun. Bei einem 10 Jahre alten Board kannst du nach den Tests aber davon ausgehen, dass die ACPI-Variante einfach nicht funktioniert. Von den Board-Herstellern wurde das schon immer Stiefmütterlich behandelt und vor 10 Jahren sicher noch mehr als heute.


    Versuch es einfach mit nvram-wakeup. Das macht nichts anderes, als die von dir manuell vorgenommenen BIOS-Aufwacheinstellungen automatisch zu setzen. Da es dafür aber keine Standard-Schnittstelle wie ACPI gibt, ist es u.U. etwas fummelig erstmal die richtigen Speicheradressen rauszufinden. Mit etwas Glück wird dein Board aber von nvram-wakeup sofort erkannt. Und mit etwas Pech klappt auch nvram-wakeup nicht, dann bleibt dir nur die settimer-Variant, die Daniel schon erwähnt hat.

    Setze doch im BIOS erstmal:


    * Resume On RTC Alarm: Enabled


    Und "RTC Alarm Date" die entsprechende Aufwachzeit (UTC!!!). Dann speicherst du die BIOS-Einstellungen, schaltest die Kiste aus und wartest, dass sie wieder angeht.


    Wenn das klappt versuch's nochmal via ACPI-Wakeup. Vielleicht muss nur die " Resume On RTC Alarm" aktiviert werden.


    Ist die Kiste beim manuellen setzen der Aufwachzeit im BIOS aufgewacht, aber nicht via ACPI, stehen die Chancen gut, dass wenigstens nvram-wakeup funktioniert.


    Tobias

    Das mit alarm_date ist kein Problem. Nicht alle Boards unterstützen das. Bei meinem Board wird z.B. vom Aufwachdatum nur der Tag verwendet.


    Hast du im BIOS mal manuelle eine Aufwachzeit eingestellt? Funktioniert das?


    Neue Boards haben manchmal auch eine Stromsparfunktion, bei der dann z.B. WOL nicht mehr funktioniert und vielleicht auch der Wakeup-Timer - vielleicht wirst du in dieser Richtung im BIOS fündig.
    (Und ggf. gleich die HPET-Einstellung deaktiviern - Guter Hinweis von Gerald!)


    Es kann auch sein, dass der WakeupTimer erst beim nächsten Booten aktiviert wird. Probier mal folgendes:


    Code
    1. echo `date '+%s' -d '- 55 minutes'` > /sys/class/rtc/rtc0/wakealarm
    2. cat /proc/driver/rtc


    Jetzt müsste "alrm_time" gegenüber "rtc_time" erstmal 5 Minuten in der Zukunft liegen.


    Danach machst du:


    Code
    1. reboot


    Und wenn du jetzt wieder im Grub-Boot-Menü landest schaltest du die Kiste übder die PC-Power-Taste aus (i.d.R. 3 Sekunden gedrückt halten) und wartest ob sie sich in 5 Minuten wieder einschaltet.


    Klappt das alles nicht, bin ich auch erstmal am Ende mit meinem Latein.

    Laut deinem Log-Auszug setzt du um 20:21 Uhr die Aufwachzeit auf 20:10. Ich gehe also mal davon aus, der Rechner läuft auf UTC-Zeit und du wolltest 21:10 aufwachen, korrekt?


    Prüfe beim Booten mal im BIOS ob die Zeit dort wirklich UTC ist (also im Moment eine Stunde zurück).


    Außerdem kannst du nach dem Runterfahren mal wieder manuell Einschalten und dann mit:


    Code
    1. cat /proc/driver/rtc


    ...prüfen ob die Aufwachzeit noch gesetzt ist.


    Weiterhin kannst du unter Umgehung des VDR folgendes testen:


    Code
    1. echo `date '+%s' -d '- 55 minutes'` > /sys/class/rtc/rtc0/wakealarm
    2. cat /proc/driver/rtc
    3. poweroff


    Dann sollte der Rechner nach 5 Minuten aufwachen.

    Also ich kann's noch immer nicht nachvollziehen. Bei mir beendet sich de VDR ganz normal - und ja, auch mit einem exit!:


    Code
    1. Oct 30 15:55:05 hdvdr vdr: [4215] stopping plugin: fritzbox
    2. ...
    3. Oct 30 15:55:17 hdvdr vdr: [4215] deleting plugin: epgsearchonly
    4. Oct 30 15:55:17 hdvdr vdr: [4215] max. latency time 9 seconds
    5. Oct 30 15:55:17 hdvdr vdr: [4215] caught signal 15
    6. Oct 30 15:55:17 hdvdr vdr: [4215] exiting, exit code 0


    Tobias

    $ LD_AUDIT="libpcprofile.so" PCPROFILE_OUTPUT="/tmp/testout" ping
    Usage: ping [-LRUbdfnqrvVaAD] [-c count] [-i interval] [-w deadline]
    [-p pattern] [-s packetsize] [-t ttl] [-I interface]
    [-M pmtudisc-hint] [-m mark] [-S sndbuf]
    [-T tstamp-options] [-Q tos] [hop1 ...] destination
    $ ls -l "/tmp/testout"
    ls: Zugriff auf /tmp/testout nicht möglich: Datei oder Verzeichnis nicht gefunden


    Geht's um CVE-2010-3856 / CVE-2010-3847?
    Sollte auch in Lenny gefixt sein:


    http://www.debian.org/security/2010/dsa-2122


    Scheint auch so als würde das nur glibc betreffen - gibt's in Squeeze aber nicht mehr. Das wurde durch eglibc ersetzt.

    Wolltest du nicht nach dem Aufwachen aus pm-suspend einen Reboot machen? Falls nicht, dann solltest du vor dem Einschlafen den VDR beenden und die DVB-Treiber entladen und nach dem Aufwachen die DVB-Treiber neu laden und den VDR starten.