hjslfs-1.3.49.3 ist offline

  • Zitat

    Original von kanotixer


    Schade, grade das fand ich immer so praktisch!


    Ein wesentlicher Grund ist , daß diese Form des Dialogs ziemlich fehleranfällig ist .


    Und irgendwie hätte ich da gern mehr Ordnung drin gehabt .


    Zitat

    Aber Du bist der Chef.


    Yep :)


    Allerdings sollte man den Bedürfnissen der User natürlich nachkommen .


    Leider bin ich von meinem Ideal - eine Config ähnlich der des Kernels - meilenweit entfernt .
    Abba kommen soll das mal - aber vermutlich erst bei ner 2er Version :gap


    HJS

  • Zitat

    Original von hjs


    Änderungen gegenüber den 1.2.x Versionen :


    - Buildscripte sind ( zumindest während der dev ) Teil des Mainscripts - werden nicht nachgeladen
    - Trap Logging ist aus den Scripten genommen ... demnächst wählbar bash/Traplogging
    - getsrc und find für packaging ausgelagert
    - neue experimental baselist .


    Tja , da hat sich ja einige Revisionen später doch was getan ...


    [1] is immer noch so
    [2] versucht die .16 durch "Commandlogging" zu ersetzen
    Oder anders formuliert : Das Ergebnis jeder Scriptanweisung wird protokolliert .
    Hab ich mal geändert , weil ich nicht automatisch aus den fertigen "Rohscripten" Loggingscripte erstellen konnte - und sowohl das editieren der "verloggten" Scripte als auch das manuelle "verloggen" Selbiger ist schlicht mühsam und fehlerträchtig .


    [3] passt noch zum Teil , da das Packaging sich mittlerweile auf aufs stützt .
    [4] Jo - hammer nochmal was Neues :)


    Bootscripts und udev aktualisiert - mal sehen obs auch rennt :gap


    HJS

  • Zitat

    Original von hjs
    War ja klar , daß das Logging ersma für Zickereien sorgt .... :(


    Neuer Versuch ...


    Ohh Mann :§$%


    Da hat man den Ehrgeiz , beim Loggen die Originale Zeile mit zu liefern - und was passiert ?? :§$%


    Dann gibts halt doch nur n echo - tut der Funktion keinen Abbruch aber erhält sie :gap


    HJS

  • Da ichs bisher nicht geschafft habe , die Scripte durch ne Automatik zum loggen zu bringen , hab ich ersma die Option defaultmäßig disabled .
    Kann in Menüpunkt c aktiviert werden .


    Bin mal gespannt , ob dieser Versuch zeigt , daß ich alle Stolpersteine umschifft habe oder ... :schiel


    Neu ist die [Debug]Möglichkeit , nach jedem Package n Stop ein zu legen .
    So kann man auf ner anderen Console schauen , was passiert ist , wos evtl. hängt und das Script ggf manuell korrigeren und erneut ausführen lassen ...


    Erwartet man keine weiteren Steine mehr , in /hjslfs/var ne Datei namens WEITER anlegen und er rennt durch ...


    Die Wiederaufnahme ist zwar bereits generell möglich , allerdings noch nicht per Menü , sondern manuell .


    In /hjslfs/var sind die Dateien hostlist2use und systemlist2use .
    Wenn man erst bei gcc-pass2 wieder einsetzen will ( vorrausgesetzt man hat nicht formatiert und der Build ist nicht komplett durchgelaufen , sonst /tools eh wech ) , löscht man einfach die Namen davor und gut is .


    HJS

  • Ich hätt da mal ne Frage...


    Defaultmäßig wird ja ein System mit /etc/init.d und /etc/rc.d/init.d angelegt.
    Warum beide Verzeichnisse? Kann man da nicht eins wegoptimieren?


    Grüße
    Marc

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

  • Zitat

    Original von kanotixer
    Defaultmäßig wird ja ein System mit /etc/init.d und /etc/rc.d/init.d angelegt.
    Warum beide Verzeichnisse? Kann man da nicht eins wegoptimieren?


    Streng genommen : ja


    Das ist nur ein Attribut an ältere oder "andere" Packages .


    Hotplug schreibt sich z.B. in /etc/init.d .


    Aber nichts hindert dich , was auch immer da drin ist rüber zu schubsen und ggf für den Fall der Fälle /etc/init.d auf /etc/rc.d/init.d zu verlinken .
    Es sei denn auch der Link würde dich stören :unsch


    Am Rande sei vermerkt , daß die .17 brauchbar leif und daher mittlerweile ne .18 da ist - mit Wiederaufnahmepunkt [ Wer hatte noch gleich danah gefragt ?? :unsch ] per Menü wählbar - sollte sogar klappen , da /tools nicht mehr gekickt wird :)


    Nu hats ja reichlich DEBUG Varianten .
    Die Solange-bis-das-Script-erfolgreich-lief Variante bewährt sich grad auf meiner Maschine :gap


    HJS

  • Da das "Commandlogging" nich so will , wie ich wohl will , nehmen wir halt doch Bash/Trap Logging .


    Wählbar ist bashx bashxv ( die logging Funktion der Bash mit -x oder -xv ) oder trap .


    Ich favorisiere trap - das ist das Ergebnis , was ich eigentlich mit dem "Commandlogging" erzeilen wollte .


    Leider ergibt das mit Trap nur in Scripts ohne Funktionsaufruf - da hats sich doch schon gelohnt , die Scripte um zu schreiben :whatever


    HJS

  • Türlich hab ich mir ersma wieder n Kinken eingebaut ... und hiermit auch wieder "ausgebaut" :gap


    Mittlerweile kann man auch entscheiden , ob die make [-k] check der jeweiligen Packages gefahren werden sollen ... oder auch nicht - spart so um die 3 Stunden - allerdings weiß man auch nicht genau , wo s denn nu geklatscht hat , wenns denn den Bach runter ging ...


    HJS

  • Mittlerweile läßt sich das Packaging - was aufs erfordert also CD012 - ausschalten ( Sonstige Einstellungen ) .


    Irgendwie scheint die 12er n Problem zu haben - da werden mir Segfaults um die Ohren gehauen - heieiei ...


    Hab schon verzweifelt nach den möglichen Ursachen in meinen Scripts gesucht - ziemlich vergeblich .
    Ne neue Host Scheibe gebrutzelt - nix wars .
    Mal die 10b ohne Packaging angeworfen - siehe da - nu gibt er Ruhe .


    Um die nervigen Fehlermeldungen und sonstiges merkwürdiges Verhalten zu vermeiden also Packaging abwählbar .


    HJS

  • Mittlerweile sind sage und schreibe 3 ( in Worten DREI ) :) addons in der [ neuen und einzigen ] Liste ... :gap


    Das Trap-Logging gibt jetzt auch tatsächlich den Exit-Code des zu prüfenden Commands aus und nicht den des ersten Trap Commands ( also immer 0 ) .


    In /hjslfs/var/installed_packages werden die erfolgreich installierten Packages eingetragen ( wenn make [...] install erfolgreich war ) .
    Die DEPs werden darüber auf Erfüllung gecheckt bzw , ob ein Package bereits installiert ist ...


    HJS

  • Sodele


    Nach diversen Arbeitseinheiten für meine DEV Maschine ist es mir tatsächlich gelungen , mal wieder was Laufendes zu fabrizieren .


    Wie`s ausschaut , bringt tatsächlich das trapping einige unangenehme Nebenwirkungen mit sich .
    Bei einigen Testläufen blieb die Kiste beim libc builden einfach stehen - nicht daß er sich wechgehängt hätte - ein <CTRL><C> , der den aktuellen Prozeß beendete und schon gings weiter - nur ohne libc nicht sonderlich erfolgreich .


    Um jede Chance auszuschließen , daß womöglich auch die 10b nicht ganz sauber ist zum testen ne Originale LFS-LifeCD gezogen - die sich mit trapping auch aufn Bauch legt .


    Ohne das löppt dann die Kombination libc-2.8/gcc-4.2.3/binutils-2.18 sauber durch so ganz ohne SegFaults oder sonstige unangenehme Erscheinungen - wie nett :)


    Diese Liste ist als 290309 zu finden .



    Der Teil

    Zitat

    In /hjslfs/var/installed_packages werden die erfolgreich installierten Packages eingetragen ( wenn make [...] install erfolgreich war ) .
    Die DEPs werden darüber auf Erfüllung gecheckt bzw , ob ein Package bereits installiert ist ...


    klappt daher ( ! trapping ) ersma nich mehr :(


    HJS

    Working VDR : VDR-1.4.6 - ACPI/NVRAM Wakeup - working on hjslfs

    Einmal editiert, zuletzt von hjs ()

  • Da das trapping scheinbar Haken und Ösen hat , die einen sinnvollen Einsatz in den Scripten verhindern , hab ich doch noch mal n Versuch mit "meiner" Variante gestartet .


    Obs klappt , weiß ich in n paar Stunden :gap


    Der angenehme Nebeneffekt ist , daß auf die Art - fürs reine Loggen etwas aufwendig - auch dirket die Infos für den Buildcheck zur Verfügung stehen .
    Die Scripte werden dann demnächst in der Lage sein , einen Fehlschlag zu erkennen und entsprechend Anweisung ( nochmal / andere Version / nimm Binary ) zu verfahren ... wenn alles klappt :whatever


    Zeitgleich löppt denn auch der Test , ob aufs mir bringt , was ich mir davon erhoffe oder auch nur sinnlosen Aufwand für noch mehr Kinken eingebracht hat ... :whatever


    HJS

  • Zitat

    Original von hjs
    Da das trapping scheinbar Haken und Ösen hat , die einen sinnvollen Einsatz in den Scripten verhindern , hab ich doch noch mal n Versuch mit "meiner" Variante gestartet .


    Obs klappt , weiß ich in n paar Stunden :gap


    Sieht gut aus :]


    Zitat


    Der angenehme Nebeneffekt ist , daß auf die Art - fürs reine Loggen etwas aufwendig - auch dirket die Infos für den Buildcheck zur Verfügung stehen .
    Die Scripte werden dann demnächst in der Lage sein , einen Fehlschlag zu erkennen und entsprechend Anweisung ( nochmal / andere Version / nimm Binary ) zu verfahren ... wenn alles klappt :whatever


    Noch in Arbeit ...


    Zitat


    Zeitgleich löppt denn auch der Test , ob aufs mir bringt , was ich mir davon erhoffe oder auch nur sinnlosen Aufwand für noch mehr Kinken eingebracht hat ... :whatever


    Sieht auch gut aus :]


    Hatte vorübergehend das Finetuning ausgehebelt - fixed .


    HJS

  • Da manch Check sinnvoller ist als Andere , kann man jetzt für jedes Package mit Testsuite einzeln einstellen , ob der check/test gefahren werden soll - oder auch nicht .


    HJS


    PS Gibts noch jemanden ausser mir , der die 1.3er Scripte anwirft ?

  • Oups - da hatte ich doch noch n Kinken in der Wiederaufnahme ab System eingebaut ... :gap ... fixed


    Auf dem Weg zum automatischen Rebuild gings etwas weiter .
    Wenn make install fehlerfrei war , gibts n Eintrag in /.system/install/{host,system} - nur die verarbeitung im steuerscript nebst Regelabfrage in der config fehlt noch ...


    Da durch die Umstrukturierung der Scripte auch die Quasi-Integritätsprüfung der Sourcen entfallen ist , hab ich die mal wieder an geeigneter Stelle hinzu gefügt .


    Ist unter Punkt c gelandet .
    Da passts nich so ganz , aber die Struktur wird erst gebügelt , wenn alle Funktionen drin sind ...


    Der Tarball wird halt schlicht nach /tmp entpackt , wenns geht , ist er wohl OK , gehts nich , wid das Package gelöscht und neu gezogen ( maximal 3 Versuche - könnt ja sonst ewig gehen ... ) .


    Ist zwar n seltener Fehler , aber kann auftreten , wenn der Download mal abknickt .
    Die unvollständige Datei wird von wget mit der Option -nc nicht erneut geholt - würde sie ( ohne -nc ) , hätte sie auch die falsche Endung .


    Der Einzige , der damit mal Ärger hatte glänzt zwar durch dauerhafte Abwesenheit ....
    abba nu isses halt wieder drin .


    HJS

  • Sodele - noch n Schrittsche :)


    DieZahl der addons ist mittlerweile auf sagenhafte 8 angewachsen :gap


    Wählt man keinen einzigen Check aus ( die Default Einstellung ) , werden expect , tcl und dejagnu im Host nicht gebuildet - die sind dann nicht erforderlich .


    Fürs Packaging kann man wählen , ob vorher bereits ein Stripping gefahren werden soll - macht die tarballs kleiner .


    HJS

  • Nu is das Ganze recht ordentlich durchgelaufen , allerdings gabs noch zwei kleine Kinken , die nu beseitigt sind :


    Da der make headers_check aus der Kernelheader Installation als "check" erkannt wurde , wars nur meinem manuellen Eingreifen auf ner anderen Console zu verdanken , daß das Triplet tcl/expect/dejagnu nicht gebaut wurde ... fixed


    Dieser Check wird nicht mehr als solcher erkannt und ist der einzige Check der defaultmäßig ausgeführt wird ( in host und sys ) .


    Alle anderen sind geknickt , da ich scheinbar meine 12er HostCD zu unrecht als Verursacher der SegFaults verdächtigt habe .


    Das hüpfende Komma liegt hier eindeutig bei expect .


    Egal auf welcher Maschine , mit wieviel Speicher , mit welcher HostCD oder vorhandener , einwandfrei laufender Installation ich die Scripte angestoßen habe - die Bauchlandung kam in Abhängigkeit , welche Test/Checks aktiviert waren reproduzierbar immer an der gleichen Stelle , der Stelle an der expect einfach stumpf hängenbleibt und sich nichtmal mehr killen läßt .


    Da unter allen Umständen bereits der check von expect selbst im Buildprozeß bereits 3 oder 7 Nieten von 25 Möglichen zog , und sich expect dann wie erwähnt wechhängte , hab ich grade mal auf dem frischen Build ohne jeden Check tcl und expect für /usr statt für /tools im host gebaut ... und der Check lief ohne Niete durch .


    Da mir nicht wirklich klar ist , wieso expect so dermaßen rumzickt - empfehle ich ersma , an der Defaulteinstellung für die checks nix zu ändern bzw einmal durch die Check Konfiguration zu klicken - dann erkennt das Basisscript , daß besagtes triplet nicht erforderlich ist - und bauts auch nicht .


    In Kürze werd ich meine verdächtigte 12er mal mit nem Build beauftragen - wenn se ( wie ich nu erwarte ) durchrennt , stell ich die wieder online ...


    HJS

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!