Posts by kanotixer

    Hab mich jetzt mal dran gemacht, die xinelib in der Version 1.1.16.2 zu kompilieren. Natürlich sollte die ffmpeg die neuste sein, wobei ich aber auf ein Problem stieß. Es wurde ein Patch fürs hg veröffentlicht, den hab ich auf die 1.1.16 angepasst.


    Grüße
    Marc

    Quote

    Menüpunkt 8 "Gesamte Einstellungen ansehen" zeigt jetzt wirklich nur noch die Einstellungen . Änderungen sind an der Stelle nicht mehr möglich .


    Schade, grade das fand ich immer so praktisch! Aber Du bist der Chef.

    Und da isses schon!


    Sämtliche Fehler, die vorher da waren (fonts & vor allem xkb) sind weg.


    build_X11.txt enthält ein Script, welches allerdings mehr als Pseudocode zu verstehen ist. Kommentare enthalten extern benötigte Libs und ggf. Anpassungen der configure-Anweisung.
    Die beiden anderen Dateien enthalten jeweils die Schleifen für die sections.


    Vielleicht kannste damit was anfangen. Das Einpflegen in Dein Schema erledigst Du am besten selbst, da blicke ich nicht durch.


    Grüße
    Marc

    Moin HJS,


    bist Du eigentlich schon an X7.4 mit xserver 1.5 dran?
    Wenn nicht lass Dir Zeit, ich acker grad das BLFS-Kapitel dazu durch und protokollier das in einem Skript mit. Dann lass ich Dir das zukommen, wenns läuft.
    Irgendwie will das mit dem xkbcomp nicht, ich dachte der beste Weg ist, das einmal "from Scratch" durchzuarbeiten, dann hab versteh ich es wenigstens.


    Grüße
    Marc

    Hallo zusammen,


    erst einmal ein herzliches "Dankeschön" an sparkie, der die Links gepostet hat.
    Hab die Ideen und teilweise die Skripte auf mein LFS (in dem Zuge auch ein riesiges Danke an HJS!) losgelassen und siehe da:
    von 25 auf 14 Sekunden runter. In der Gesamtheit macht das 35 Sekunden vom Drücken des Powerknopfes bis zum Bild mit xineliboutput.


    Habe mir die Skripte vom 15-Sekunden-Debian und von Moblin angeschaut, die es beide so machen, wie hier bereits skizziert:


    Zuerst werden die statischen Devices nach /dev kopiert (beim Debianskript sogar entpackt, sollte sich die Hardware ändern, wird das Archiv aktualisiert), irgendwann später dann ein post_udev-Skript gestartet, dass sich um neu hinzukommene Devices (Usb-Sticks, etc.) kümmert.


    Läuft alles noch nicht rund, scheint aber zu funktionieren.


    Scheinbar gibt es ja hier ein gewisses Interesse, an der Bootzeit zu arbeiten? Vielleicht kann man an dieser Stelle oder in einem neuen Thread noch weiter Ideen zusammentragen.


    Vor allem asynchrone Inits im Kernel und teilstatische Devs, aber auch die Art Programme zu starten (X in der runvdr oder vorher) wären sicher interessante Themen.


    Und wenn man es dann noch schafft, Skripte zu entwickeln, die ein fertiges System "auf Knopfdruck" optimieren, wäre das Breitentauglich (wäre selbst für LFS interessant)


    Grüße
    Marc

    Hallo zusammen,


    entgegen der Signatur geht es hier um ein LFS mit 2.6.23.13-Kernel und vdr-1.6.0 (mittlerweile vdr-1.6.0-2).


    Um Yaepg zum Rennen zu kriegen ist ja ein Patchen des VDR nötig. Aus diesen und anderen Gründen wollte ich direkt den kompletten Extension-Patch von Zulu installieren.


    Dabei ist mir aufgefallen, dass die Configpfad-Angaben ignoriert werden und yaepg sich immer noch über einen ungepatchten VDR beklagt.


    Verifiziert habe ich das dann über DISABLE_ANIMATED_TEXT = 1 von Skinenigmang.
    Direkt im Makefile geändert bleibt der Text stehen, in der Make.conf im VDR-Verzeichnis animiert er fröhlich weiter.


    Wie kann ich weiter verifizieren, ob er das Make.conf wirklich nicht einliest? Im Makefile steht auf jedenfall ein -include drin. Und wichtiger: Wie behebe ich das?


    Viele Grüße
    Marc

    Und da warn sie wieder, die Probleme...


    Ich will nicht zu weit ausholen, nur soviel:
    Für yaepg, und das will ich unbedingt, brauchts Patches. Da andere Plugins das wohl ähnlich sehen wollte ich gleich das ext-Patch-zulu-Gesamtpaket einbinden. Soweit alles kein Problem, allerdings ist mir in dem Zuge aufgefallen, dass die Make.conf gar nicht abgearbeitet wird!


    Verifiziert habe ich das über SkinenigmaNg, respektive die Option SKINENIGMA_DISABLE_ANIMATED_TEXT.


    Direkt im Makefile eingetragen rührt sich nichts, keine Animation. Aber nur in der Make.conf eingetragen scrollt der Text fröhlich weiter. Hab auch spaßeshalber mal die Include-Direktive umgelenkt, nischt.


    Hast Du da ne Idee? Sonst poste ich das an anderer Stelle nochmal mit eigenem Thread.


    Das Problem ist schlussendlich, dass Eintragungen in der Make.conf Patches aus der Sammlung aktivieren, ohne Make.conf also keine Patches, ergo auch kein yaepg. Da schließt sich der Kreis.

    Mal wieder was erfrischendes Zwischendurch:


    ImageMagick-6.3.6-3 kompiliert nicht, weil das entpackte Verzeichnis nur ...-6.3.6 heißt, ohne -3. Mit geändertem Feldnamen rennts durch.


    Grüße
    Marc

    Und wenn Du mir jetzt noch verrätst, an welcher Stelle alle locale-Variablen auf POSIX gesetzt werden, gibt's ein Sternchen ins Heft ;)


    Ansonsten läuft das alles schon ganz schön (mit xine-lib 1.1.14, dachte Du meinst die Listen der 1.3...), auf meiner TODO-Liste steht noch:


    - Bootzeit auf 20 Sekunden
    - Direkt beim Start deutsches OSD (geht bisher nur, wenn der vdr manuell gestartet wird, s.o.)
    - yaepg ans Laufen kriegen

    EDIT: ?( Habs rausgefunden. In der xinitrc war alles auskommentiert, deshalb sah xinit keinen Grund mehr, den xserver am Leben zu erhalten und hat ihn gleich nach dem Start wieder geschlossen.
    Jetzt löppts.


    Ne, mit startx gibts den gleichen Fehler wie mit xinit.
    Ich denke ich werde das Skript mal Zeile für Zeile durchgehen und schauen wo's hängt. Bäh.


    Nur noch das, dann läuft der VDR! Alles auf dem letzten Meter...

    Alles klar, ich kann warten...


    In der Zwischenzeit noch was zum Knobeln, vielleicht hast Du eine Idee?


    mit X startet der Server, mit xinit erscheint kurz der graugerasterte Schirm mit Mauskreuz, um sich danach direkt wieder zu schließen.



    Mit X als Befehl sieht die Ausgabe nach dem Schließen mit Strg+Alt+Backspace genauso aus. Versteh ich nicht.

    Files

    • Xorg.0.log.txt

      (36.96 kB, downloaded 157 times, last: )


    Ich dachte ja nur:


    Bei mir ist grad die xine-lib-1.1.14 fehlerfrei durchgerannt.
    Bringt das irgendwelche Nachteile? Dann probier ichs nochmal mit der 1.1.8.


    Eine Sache die mir auffiel: Sollte man die Lib nicht besser mit externer ffmpeg bauen? Die wird ja auch für andere Sachen gebraucht und so hat mans direkt einheitlich.

    Und was ist das nu schon wieder, das hatte ich ja noch nie!



    Die Entwickler hatten da einen Bugfix veröffentlicht, habe ich auch ausprobiert, ändert aber nix.
    Hat ja auch schon mal geklappt?!

    Quote

    Original von hjs


    Hm - als du manuell hochgefahren hast , hat er da noch Host&Hilfsverzeichnisse gelöscht oder waren die schon weg ?


    Auf was man alles achten muss, ne...
    Hab den Rechner leider zwischenzeitlich schon ein/zwei mal rebootet, z.B. um ein Backup mit partimage zu ziehen


    Quote


    Nee - in der 1.2.8er gibts ne Liste in /hjslfs/tmp mit dem hübschen Namen "doit"
    Darin stehen die zu bildenden Packages und exe_doit in /hjslfs/lfs ist das abarbeitende Script , was nach dem Reboot gestartet wird .
    Das kannste manuell anwerfen oder nochmal /hjslfs/addon_setup , falls doit nich deinen Wünschen entspricht ...


    Hab addon_setup natürlich voreilig wie ich bin schonmal ausgeführt, jetzt ist das ursprüngliche doit natürlich weg...


    Damit dialog funktioniert musste ich allerdings einen
    ln -s /lib/libncursesw.so.5 /usr/lib/libncurses.so.5
    setzen.


    Desweiteren hilft es wohl, vor dem Ausführen ein paar Verzeichnisse anzulegen (/.system/install/log, etc)


    Jetzt rennt er, meckert aber hin und wieder mal über nicht gefundene Verzeichnisse. Ich bin gespannt.

    Hallo HJS,


    ich mach mal hier weiter, dann gibts keine Verwechslung, welche Version grade bei mir rennt.


    Hab letzte Nacht nochmal die 1.2.8 durchlaufen lassen, soweit erstmal alles ohne Fehler.


    Allerdings hat er scheinbar keine Addons gebaut, obwohl der Modus auf reboot stand, hätte also von alleine durchlaufen müssen.


    In /hjslfs/var/ gibt es auch keine choosen_addons obwohl ich bei der Konfiguration was ausgewählt habe!


    An welcher Stelle könnte ich nachschauen, was schiefgelaufen ist? Und wie hole ich das manuell nach?


    Grüße
    Marc

    Anstrengend, son Betatester, gelle ;)


    Nach dem Aufstehen heute morgen lief der Rechner immer noch, mir schwante böses.


    Warum er keinen Poweroff gemacht hat weiß ich noch nicht, was aber etwas stört, dass die Tastaturbelegung völlig durcheinander ist.
    Ich habe sie fest in den Kernel einkompilieren lassen (ja, falsch, ich weiß. Aber dialog hatte an der Stelle einen Grafikbug und ich hätte schwören können, dass da sonst immer "j" stand...).
    Krieg ich das Kind jetzt irgendwie wieder aus dem Brunnen raus?


    EDIT: Konnte das Problem ein wenig einkreisen. Nach dem Booten läuft alles wie es soll (außer einigen Fehlern beim Build, z.B. sshd), sobald man aber einmal die Shift-Taste betätigt hat, ist die keymap völlig durcheinander. Selbst der Ausschalter ist danach ein Buchstabe ("N")... Das Drücken der Strg-Taste scheint diese "einzurasten", kriegt man dann auch nicht mehr raus.
    Und die fstab-Geschichte taucht immer noch in der presystem.log auf.


    Einen Wunsch für die nächste Version: Option, SSHD in den Autostart zu nehmen.