hjslfs-1.3.49.3 ist offline

  • Moin,


    hab wieder was zu meckern :versteck


    1. Locate hätte gerne ein Verzeichnis /var/lib/locate um seine Datenbank anzulegen, dieses muss im Moment manuell erstellt werden.


    2. Installiert man von Binaries muss man die richtige Kernelversion angeben, weil Grub sonst nicht mag. Wenn man die Binaries von Dir lädt muss man also entweder raten oder nach dem ersten fehlgeschlagenen Boot nachsehen.


    3. Eine Sache mit den customscripts versteh ich nicht. Hab jetzt alles in prescripts gepackt, scheint aber auch wieder nicht richtig zu sein. Er sucht irgendwann in buildscripts und findet da nix.
    Warum denn überhaupt die verschiedenen Ordner und wie hängen die zusammen?


    Achja, soll ich die neuen Features mal irgendwie im Wiki howto'n? So langsam wird der Thread ja unübersichtlich...


    Achja2, soll ich die Addonscripte einfach gleich mal rüberschicken, oder warten bis customscript fehlerfrei durchläuft? Sind bestimmt noch einige Kinken drin.


    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.

  • Quote

    Original von kanotixer
    Moin,


    hab wieder was zu meckern :versteck


    Wer meckert , sollte sich verstecken , wer konstruktive Kritik übt , darf sichtbar bleiben ;)



    Quote


    1. Locate hätte gerne ein Verzeichnis /var/lib/locate um seine Datenbank anzulegen, dieses muss im Moment manuell erstellt werden.


    Huch - sowohl beim Build wie auch beim Binary Install werden die [ in presystem ] erstellt ...


    Quote


    2. Installiert man von Binaries muss man die richtige Kernelversion angeben, weil Grub sonst nicht mag. Wenn man die Binaries von Dir lädt muss man also entweder raten oder nach dem ersten fehlgeschlagenen Boot nachsehen.


    Ups - ist natürlich irgendwie doof - werd ich in Kürze "umgehen" :gap


    Quote


    3. Eine Sache mit den customscripts versteh ich nicht. Hab jetzt alles in prescripts gepackt, scheint aber auch wieder nicht richtig zu sein. Er sucht irgendwann in buildscripts und findet da nix.
    Warum denn überhaupt die verschiedenen Ordner und wie hängen die zusammen?


    Die verschiedenen Ordner gibts , weil fürs loggen und check-enable/disable die Orignal Scripte verändert werden müssen .


    Damit ich das Original stets noch habe , wenn der unentschlossene User sagt "Einstellungen zurücksetzen" , kopiere ich das Original aus prescripts nach buildscripts - dort werden die Scripte dann bearbeitet .


    Da der komplette /prescripts nach /buildscripts kopiert wird , wundert es mich , daß deine Scripte da nicht ankommen ... ?!? :schiel


    Quote


    Achja, soll ich die neuen Features mal irgendwie im Wiki howto'n? So langsam wird der Thread ja unübersichtlich...


    Gern , aber ist noch n Tick zu früh .
    Ein oder zwei Features werde ich noch ändern und für die sinnvolle Auswertung der BIN-DEPs auch die Build-DEPs des Systems mit reinwerfen .


    Dann ist eh n Readme dran :)


    Quote


    Achja2, soll ich die Addonscripte einfach gleich mal rüberschicken, oder warten bis customscript fehlerfrei durchläuft? Sind bestimmt noch einige Kinken drin.


    Wie du willst .


    Ich würde sie einfach zu den Buildscripts packen und online stellen .
    Vielleicht gibts noch einen , der Fehler sucht .


    Verspürst du den Wunsch zu einer bestimmten Zeit ( vor Addonbuild oder vor Reboot oder wann auch immer ) ein komplett eigenes Script zu fahren ohne dich an meine "Regeln" halten zu müssen ?


    Ich könnte die customscript auch in ein komplett eigenes Verzeichnis schubsen ( /prescripts/custom selbstverfreilich ) und die Kontrolle dann an ein "customscript" übergeben [lassen] .


    HJS

  • Quote

    Original von kanotixer
    [...]
    2. Installiert man von Binaries muss man die richtige Kernelversion angeben, weil Grub sonst nicht mag. Wenn man die Binaries von Dir lädt muss man also entweder raten oder nach dem ersten fehlgeschlagenen Boot nachsehen.
    [...]


    fixed :)


    HJS

  • Mal wieder was Neues .


    Nu kann man unter "Sonstige Einstellungen" die Optionen fürs Sourcenziehen - wie immer/nie überschreiben - Anzahl der Versuche - Timeout und favorisiertem Server einstellen .


    Bleibt noch eine Baustelle bis zur ersten Pre ... :)


    HJS

  • huhu hjs,


    was für glibc + gcc Versionen hast du denn aktuell verbastelt?
    Hast du stack-smashing protection dabei wie z.B. in den letzten fedora Versionen?


    -> http://en.wikipedia.org/wiki/B…Protector_.28ProPolice.29

  • Quote

    Original von kanotixer
    Sie haben Post...


    Vielen Dank - mal schauen , daß ich die meinem System "anpasse" ;)


    Die neue Version der Scripte berücksichtigt beim "Sourcen Finetuning" , ob man Bininstall oder build gewählt hat und zeigt entsprechend auch nur die verfügbaren Binaries bzw Buildscripte an .


    HJS

  • Sodele .


    Der Dependency Check des System beim Binaryinstall ist drin .


    Derzeit ist das Ergebnis bei Fehlschlag , daß die Scripte einen nicht aus dem Hauptmenü lassen ...


    Man muß den Grund noch auf ner zweiten Console in /hjslfs/DEPFAULT suchen ... :gap


    HJS

  • Quote

    Original von wirbel
    huhu hjs,


    was für glibc + gcc Versionen hast du denn aktuell verbastelt?
    Hast du stack-smashing protection dabei wie z.B. in den letzten fedora Versionen?


    Tach der Herr :)


    Aktuell isses noch glibc-2.8 und gcc-4.2.3


    Wenn ich die Aussage des Links richtig interpretiere , hab ich das wohl :)


    HJS

  • Das wär ja schick..

  • Hmm, ich will mein Produktivsystem nicht gleich riskieren; aber testen ist machbar.


    Wenn der Complier die switches


    -Wp,-D_FORTIFY_SOURCE=2
    -fstack-protector
    --param=ssp-buffer-size=4


    kennt, dann isses drin. :-)))


  • Äh - und wie testet man das auf die Schnelle ?


    Ich laß meine Kiste zwar einiges compilieren , aber von C oder Makefiles hab ich nicht wirklich Ahnung :gap


    HJS

  • Wenn ein configure script bzw. Makefile die auf dem gesetzten Flags benutzt, dann sollte das hier funzen.



    Dann sollte man ja sehn, ob der gcc über unbekannte flags meckert oder nicht.

  • Quote

    Original von wirbel
    [...]Dann sollte man ja sehn, ob der gcc über unbekannte flags meckert oder nicht.



    Am Beispiel von eject mal auf meinem "working-LFS [1.1.13 , libc-2.5 , gcc-4.1.2]" gecheckt


    War wohl sogar schon da implementiert :]


    HJS

  • Genau so soll das aussehen. :]