[Fli4l_dev] Neue fli4l-Testversionen

Tobias Becker fli4l at becker.link
So Aug 4 23:06:34 CEST 2024


Hallo Harvey,

Harvey <hw234 at gmx.de> wrote:
> Der tatsächliche build findet allerdings mittels fbr-make in diesem svn 
> statt, und zwar unter src/packages/src/src/fbr
> 
> Ich habe mir dazu ein eigenes Script(e) geklöppelt, das die Arbeit 
> automatisiert. Vielleicht willst Du ja mal einen Blick drauf werfen.

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

ich habe mich mal wieder unpräzise ausgedrückt - sorry:
- mit build meinte ich ein fli4l - Verzeichnis, welches mkfli4l.sh
verwenden kann, um die Dateien zu erzeugen, welche nachher auf den
fli4l-router kopiert werden.

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
… cd ./fli4l/src/
… dort solltest Du dann _mkfli4lsvn.sh finden

… wenn Du dann _mkfli4lsvn.sh verwendest, bekommst du ein fli4l-Verzeichnis
in deinem Home
… dann kannst Du mkfli4l.sh in deinem Home aufrufen und bekommst die
router-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

>> als nächsten Step würde ich die Änderungen bis zur aktuellen r60808
>> nachverfolgen und dokumentieren
> Gibt es keine Möglichkeit die gesamt svn-Historie in einem Rutsch aus 
> svn in git zu kopieren? Was macht svn2git in so einem Fall? Der 
> Rückgriff auf diese Infos wäre schon hilfreich. Es gibt ein (nicht 
> öffentliches) git-Repo das bis r60808 reicht. Der Umstieg auf git war 
> kurz vor dem Crash schon ein Thema im Team. Vielleicht kann ich das ja 
> auslesen und Du kannst es dir ansehen. Vielleicht kannst Du dir da eine 
> Menge Arbeit sparen.

- 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

- leider muss ich bis Ende August einen laufenden fli4l-router wg. Defekt
ersetzen und wollte ein paar zusätzliche Funktionen einbauen und muss auch
den aktuellen trunk patchen / dafür nehme ich erstmal die r60808 und
dokumentiere das Aufsetzen

- wenn die neue Hardware läuft, ist der nächste step der fli4l build - also
buildroot

> Ich habe einen eigenen Buildserver auf dem das alles laufen könnte. Man 
> müsste sich nur Gedanken machen, wie der von außen abgegriffen werden 
> könnte.

Harvey, vielleicht muss der auch nicht von aussen abgegriffen werden,
eventuell geht ja auch der Weg über die gmx cloud oder anders.

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. 

Eine kleine Gruppe hatte damals entschieden wie es läuft und dann auch als
Resultat viele User verloren, die nicht Informatik studiert haben und in
der Freizeit nicht die Lernkurve vollbringen können, wie Profis, die das
jeden Tag auch beruflich beschäftigt / viele Ehemalige (Profis) haben hier
Grossartiges in deren Freizeit geleistet

Ich habe mich damals nach dem ifrename Paket zurückgezogen, da die Freizeit
für das Einarbeiten in die build-Tools einfach nicht gereicht hat und mir
auch nicht gefallen hat, das der Öffentlichkeit Wissen vorenthalten wird
und der Komplexitätsgrad enorm gestiegen ist / für mich war damals der
Aufwand nicht mehr zu leisten.

Ich hatte damals beschlossen, als normaler User mit fli4l weiter zu
arbeiten.

Mein Wunsch wäre es heute, dieses Wissen zu konservieren - denn das
öffentliche Schweigen des Vorstandes des Vereins wirkt auf mich befremdlich
- wie gesagt, auch diese NG ist wie ein Bauen auf fremdem Land / wenn der
Verein beschliesst, fli4l sterben zu lassen - dann ist auch diese NG
Geschichte

> Wir sind im Moment zu dritt aktiv an der Weiterentwicklung beteiligt. 
> Die Schnittstellen müssen noch sauberer definiert werden um 
> Reibungsverluste zu verhindern, aber es geht weiter. Stay tuned ;)

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

Es gibt meines Erachtens nur 2 mögliche Wege:

1.) ein Statement des Vorstandes - es geht weiter incl. Nachhaltigkeit /
Nachvollziehbarkeit - jeder kann nachvollziehen, wie die Ergebnisse des
buildroot zustande kommen / es wird ein Entwickler, Usertreffen online oder
offline geben
2.) ein Fork auf Basis des bisherigen unter Hilfe von GitHub oder
ähnlichem, wo jeder dann weitermachen kann, wie er möchte / aber dann auf
Gemeinschaftsgrund, solange der Account nicht gelöscht wird - die Software
ist dann aber weiter verfügbar, es kann kopiert werden und potentiell
weitergehen, auch wenn fli4l.de schon Geschichte und alles abgeschaltet
oder gecrashed ist.

Euch allen alles Gute und viele Grüsse
Tobias







Mehr Informationen über die Mailingliste Fli4l_dev