[Fli4l_dev] Neue fli4l-Testversionen

[Harvey]

Tobias,

> - sehr gerne - kannst / willst Du es hier einstellen, bzw. teilen, dann
> können auch andere User einen Blick drauf werfen

Später, lass uns erst mal die Grundlagen klären.Heißt nicht, dass ich es 
nicht zeigen will, ich glaube nur das es derzeit eher Verwirrung schafft 
weil es den Bau der FLi4l-Distribution ab den Sources bis zum fertigen 
Verzeichnis aus dem man mkfli4l.sh aufrufen kann um den Router 'zu 
füttern' in einem Rutsch macht. Teilschritte wären wohl erst mal besser, 
so habe ich mich auch an das Ganze heran gearbeitet.


> Es geht also folgendes:
> 
> … mkdir <ein-Verzeichnis-deiner-Wahl>
> … cd <ein-Verzeichnis-deiner-Wahl>
> 
> git svn clone -r60808 -T branches/4.0/trunk
> https://repo.nettworks.org/svn/fli4l
> 
> … dann hast Du unter <ein-Verzeichnis-deiner-Wahl>/fli4l eine Kopie des
> trunk der svn Revision 60808 als git repository

Ist in diesem Repo auch die Historie enthalten? Was ist mit den 
einzelnen branches? Uns interessiert hier nur der aus ffl-506 
resultierende Teil, da der zu fli4l 4.0 führt.

> … cd ./fli4l/src/
> … dort solltest Du dann _mkfli4lsvn.sh finden

Hier sollte noch ein _mkfli4lsvn.conf erzeugt werden, dass die Pakete 
und die Pfade enthält. Ein Muster liegt im dir.

> … wenn Du dann _mkfli4lsvn.sh verwendest, bekommst du ein fli4l-Verzeichnis
> in deinem Home

...oder wo die _mkfli4lsvn.conf hinzeigt.

> … dann kannst Du mkfli4l.sh in deinem Home aufrufen und bekommst die
> router-Dateien

Natürlich fehlen noch die zu den Paketen gehörenden config-Dateien ;)


> - die Info, das Du den build (nicht mkfli4l.sh) im svn - checkout auslösen
> kannst, ohne den Umweg über ein auspacken des src.tarballs gehen zu müssen,
> war eine hilfreiche Info, die ich vorher noch nicht hatte - ich danke dir
> sehr

hier kommt mein script:

--- das hier wegen der Zeilenumbrüche unlesbar wird :p
Ich versuche es anzuhängen, mal sehen. Pfade sind natürlich die aus 
meiner Installation und nur als Platzhalter zu sehen...

Das Ganze ist nur eine Quick-and-dirty Lösung um mir die Arbeit zu 
erleichtern und ist bestimmt nicht der Weisheit letzter Schluss...

> - das ganze svn in ein git zu ziehen, ist an sich kein Problem / es ist nur
> die Frage, macht das Sinn? Eventuell aus historischem Interesse schon
> 
> Ich würde (Dich/Euch) gerne wie folgt unterstützen:
> 
> - die r60785 ist die letzte offizielle Testversion / ich würde die Historie
> bis zur r60808 in der NG dokumentieren, dann hat jeder linux / macOS /
> windows User auf Intel die Möglichkeit, sich zu entscheiden ob dieser
> letzte Stand den Anforderungen genügt - es fehlt halt nur die kompilierte
> tex Doku
> 
> - weiterhin ergibt sich daraus auch der Nachweis, was geändert wurde -
> somit kann jeder für sich entscheiden, ob direkt auf die r60808 oder Deine
> Version gesprungen werden kann

Klingt gut. Die Historie wäre interessant, wenn sie sich auf einem 
leichten Wege nachvollziehen ließe. Früher gab es dafür Fisheye, wobe 
das immer wieder hing und grottenlangsam war. Ansonsten wäre es wohl 
auch machbar, die alten Zöpfe abzuschneiden.

> Um es mal ganz offen auszudrücken, es gibt den nettworks e.V. / niemand von
> denen äussert sich hier, es gibt Insiderwissen / ich war vor Jahren oder
> Jahrzehnten auch mal im fli4l-Team.

Dazu weiter im anderen Post

> Bitte nicht falsch verstehen / wollt Ihr 3 unter Euch bleiben, wollt Ihr
> Euer Wissen rausgeben / teilen? Sollen die Anwender nur testen?

Ich sage das mal, ohne die anderen zu fragen: Hilfe jederzeit gerne 
willkommen. Man muss zwar eine Linie behalten, so dass nicht jeder wild 
'herumpfuschen' kann aber das kann man ja mit Pull requests in den Griff 
kriegen oder?

Gruß
Harvey
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : update_builds.sh
Dateityp    : application/x-shellscript
Dateigröße  : 2865 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.spline.inf.fu-berlin.de/pipermail/fli4l_dev/attachments/20240805/36024150/attachment.bin>