hjslfs-1.3.49.3 ist offline

Quote

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 .

Quote

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

HJS

Quote

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

HJS

War ja klar , daß das Logging ersma für Zickereien sorgt ....

Neuer Versuch ...

HJS

Quote

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

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 ...

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

Quote

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

Am Rande sei vermerkt , daß die .17 brauchbar leif und daher mittlerweile ne .18 da ist - mit Wiederaufnahmepunkt [ Wer hatte noch gleich danah gefragt ?? ] 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

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

HJS

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

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 ...

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

Quote

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

So langsam wirds was - schätze die 1.3.100 werd ich nich mehr erreichen

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

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

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 ...

HJS

Quote

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

Sieht gut aus

Quote

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

Noch in Arbeit ...

Quote

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 ...

Sieht auch gut aus

Hatte vorübergehend das Finetuning ausgehebelt - fixed .

HJS

Mittlerweile wird in den Addons wieder der DEP Check gefahren .

Kinken in getsrc der Addons eliminiert .

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 ... ... 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

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