[Berlin-wireless] Firmware-binaries allgemein verfügbar machen

[Sven Roederer]

Am Dienstag, 24. November 2020, 12:22:51 CET schrieb Martin Hübner:
> Hallo Sven,
> 
> >> Die letzten dev-builds von Hedy datieren auf den 08.Juni 2020.[0] Soweit
> >> ich das bis jetzt überblicken konnte, liegt der Fehler alleine an einer
> >> disfunktionalen Verbindung mit Github, weshalb die wöchentlichen builds
> >> nicht mehr ausgeführt wurden. Also nichts, was sich nicht lösen ließe.
> > 
> > Zwischen den immer auffälligeren Problemen mit dem Buildbot, bis zu seinem
> > völligen Ausfall verging einige Zeit. Und da sich offensichtlich niemand
> > um
> > den Betrieb kümmert, war eine alternative sinnvoll. Und kostenlose
> > ausgelagerte Infrastruktur hat auch den Vorteil, dass sich niemand um die
> > Administration so eines systems kümmern muss, die knappen Adminressourcen
> > für wichtigere Systeme (Config, Monitor, OWM-alternative, ...) genutzt
> > werden können.
> 
> Dass der Buildbot komplett ausgefallen sei stimmt nicht. Der Buildbot
> war die ganze Zeit über funktionstüchtig. Die Integration mit Github ist
> kaputtgegangen. Ob das im Zuge der diversen Änderungen am Build-System
> passierte, oder wegen der API-Änderungen bei Github, ist hinfällig. Ich
> habe gestern viele Falter-Targets testweise bauen können. Funktioniert
> großartig. :)
> 

Ich sag's mal so: Ein Auto mit Kupplungsschaden funktioniert auch noch (Moto 
läuft, Radio spielt und es kann sich bewegen (muss man halt schieben)), aber 
funktionieren würde auch niemand sagen. 
Beim Buildbot war min. das SSL-setup defekt, was Github am Ausliefern der 
Build-requests gehindert hat. Aus Anwendersicht also nicht nutzbares System --
> kaputt...

> >> Wir haben darüber tatsächlich diskutiert. Momentan denken die meisten
> >> der vier aktiven Falter-Entwickler so:
> >> Patches sollen, wie auch im README des hedy-buildsystems zu lesen ist,
> >> Upstream eingebracht werden. Tatsächlich passiert das kaum noch. Wir
> >> sehen die "Einschränkungen", die der Imagebuilder mit sich bringt, als
> >> Ansporn, die Sachen auch wirklich Upstream zu fixen und somit OpenWrt
> >> voran zu bringen. Selbst in der relativ kurzen Zeit, die wir Falter
> >> schon entwickeln, ist diese Taktik mehrmals aufgegangen.
> > 
> > "Push upstream what upstream belongs" ist eine bekannte Prämisse, aber
> > nicht alles gehört upstream und wird auch nicht immer akzeptiert. Und
> > hier war es immer praktisch, einen Change für OpenWrt erstmal exakt
> > genauso im Freifunk zu testen. (Ich glaube 95% meiner commits für OpenWrt
> > sind so entstanden.) Grad an dieser Stelle sehe ich das Konzept "wir
> > kopieren uns die Upstream- sourcen zusammen" kritisch. Denn so muss man
> > jeden Change zweimal schrieben (einmal für das eigene repo, ein zweites
> > mal für Upstream).
> 
> Kannst du bitte nochmal ausführen, was du in diesem Fall mit Upstream
> meinst? Wir haben in Falter keinen Upstream-Code in deinem Sinn. Wir
> holen uns vorkompiliertes OpenWrt. Falls du die Falter-Pakete als
> "Downstream" zu den Freifunk-berlin-packages siehst, kann ich dir
> versichern, dass ich falter-packages als deren vollständigen Ersatz
> sehe. Inzwischen gibt es da auch schon einige Unterschiede. :)
> 

Upstream: Wenn ich das richtig gesehen hab, ist der falter-Feed ein 
zusammenkopierter Haufen von vorhandenen Paketen des Freifunk, Freifunk-Berlin 
und ggf. LuCI und OpenWrt-routin, ergänzt um ein paar eigene Pakete.
Diese kopierten und umbenannten Pakete bezeichne ich als Upstream.

> >> Des weiteren denken die meisten von uns, dass Kompatibilität mit OpenWrt
> >> wichtig ist. Mit jedem abgefahren Patch entfernen wir uns weiter von
> >> OpenWrt und erhöhen unseren eigenen Wartungsaufwand. Das finden wir
> >> nicht so cool.
> > 
> > Wie Holger mal sagte: Wir bauen Freifunk-Firmware, OpenWrt bau generisch
> > Accesspoints und Router. Da wird es immer Änderungen geben, die Upstream
> > nicht ankommen werden, für Freifunk aber wichtig oder mindestens
> > hilfreich sind.
> Genau dafür haben wir unseren eigenen Packagefeed. Kernel-Patches
> sollten aber für eine Freifunk-Firmware definitiv nicht nötig sein.
> 
Kernel-patches und geänderte Build-optionen können das Leben (für User) aber 
deutlich einfacher machen [1], [2], [3]. Natürlich sollte man hier überlegt 
vorgehen.

1 - https://github.com/freifunk-berlin/firmware/pull/546
2 - https://github.com/freifunk-berlin/firmware/commit/
3dd9eaf575cd15d276dea56ad9e54cebf722d4a2
3 - https://github.com/freifunk-berlin/firmware/commit/
109b43e0e9dfeda4ea31106da49769803122df71

> >> >> Desweiteren kann man Falter dadurch nicht nur mit "mehr Routern",
> >> >> sondern mit allen (!) Routern nutzen, die OpenWrt von Haus aus
> >> >> unterstützt. (und die entsprechend Flash-speicher mitbringen...)
> >> > 
> >> > Die Ausrichtung der Freifunk-Berlin Firmware ist halt Router zu
> >> > unterstützen, die auch durch die Userbasis / Entwicklerbasis getestet
> >> > und
> >> > supported werden. Denn was nutzt es am Ende, wenn ein neuer Freifunker
> >> > mit einem "EnGenius EPG5000" kommt, bei dem sich dann doch ein
> >> > unerwarteter Fehler herausstellt. Aber eine andere Definition der
> >> > Ziele,
> >> > führt meist auch zu einem anderen Weg, diese zu erreichen.
> >> 
> >> Unbestritten ein sehr guter Punkt. :) Ich persönlich denke darüber
> >> folgendermaßen:
> >> 
> >> Für Freifunk-Einsteiger*innen sollten wir die Hürden niedrig halten.
> >> Natürlich ist es da ungünstig, wenn jemand™ mit einem seltenen Gerät
> >> ankommt (btw, EnGenius EPG5000 ist mit 185€ als Einstieg eher
> >> unwahrscheinlich...). Aber dafür kann man Kaufempfehlungen abgeben. Und
> > 
> >> das ist für mich der Casus cnactus:
> > War nur ein x beliebiges Beispiel aus der Geräteliste, Du kannst dir auch
> > einen anderen 30€ Router raussuchen.
> 
> Womit wir wieder beim Thema wären, dass der 30€-Router überhaupt von
> OpenWrt unterstützt werden muss.
> 
> >> > Über ASU (https://github.com/aparcar/asu) und download direkt aus dem
> >> > Router hab ich auch schon immer mal "geträumt".
> >> 
> >> Soweit ich weiß, unterstützt das Moritz' großartiger Firmware-Selector
> >> auch. :)
> > 
> > Dann ist es schade, dass wir das bisher noch nicht implementiert hatten,
> > als wir vor 2+ Jahren? vom damaligen System auf's Wiki umgestellt haben.
> Den Firmware-Selector gibt es seit diesem Frühjahr. AFAICT wird er auch
> Firmware-Selector für OpenWrt werden.
> 
> >> TL;DR: Ich habe nichts dagegen, zwei Firmwares zu haben. Jeder nach
> >> seiner Façon und so... Aber ich sehe auch, dass der Großteil der aktiven
> >> Community halt hinter Falter steht.
> > 
> > User-Communityteil: Ich denke, denen ist es recht egal was die Firmware
> > angeht, solanges es Click+Run ist. Und sobald es als offizielles Release
> > verfügbar ist, rollt sich das dann halt langsam aus ...
> > Entwickler-Communityteil: ist eine ziemlich keine Gruppe, da sehe ich vom
> > bisherigen Team eigentlich nur Perry, der jetzt auf der Spalter-Schiene
> > wieder eingestiegen ist.
> 
> Ich musste bei "klein" ziemlich Schmunzeln. :) Eigentlich entwickelt
> doch nur noch einer an Hedy, du selbst. Vor einem Jahr hast du das
> anderen Menschen vorgehalten. Es ist müßig darüber zu diskutieren, warum
> Menschen keinen Bock mehr hatten, an hedy weiterzuentwickeln. Das ist
> Vergangenheit.
> 
> Aber an Falter entwickeln gerade 4 Leute aktiv mit. "ziemlich kleine
> Gruppe" ist im Vergleich zum aktuellen Hedy-Entwickler-Kreis also ein
> bisschen, nunja, ich finde es amüsant. :D
> 
> Fakt ist, dass Viele die Prinzipien, die im Hedy-Projekt vertreten
> werden, so nicht mehr teilen. Hedy krankt daran, dass Entscheidungen,
> aufgrund von Unterschiedlichen Sichtweisen, nicht mehr möglich waren.*
> Ein eigener Fork war die einzig logische Konsequenz. Übrigens eine
> Wunderbare Anwendung des "jeder nach seiner Façon"-Prinzips. :)
> 
> 
in der Tat waren / sind Entscheidungen schwierig, insb. bei gegenteiligen 
Ansichten zu einem Vorschlag. Was bei 2 aktiven Entwicklern auf 
Überzeugungsarbeit hinausläuft oder im Unentschieden endet.

> 
> * Beispiel: Anstatt ein favicon mit Freifunk-Logo einfach in die Images
> einzubetten, ein komplett neues LuCI-Theme schreiben.
> Und solcher Dinge mehr.
> 
Das klingt nach https://github.com/freifunk-berlin/firmware/pull/792. Da ein 
Update des Themes eh nötig ist, war der Vorschlag mehrere Sachen dort 
gleichzeitig "Upstream" zu lösen, was der gesamten FreifunkCommunity zu gute 
kommt, als einen Freifunk-Berlin "hack" zu nutzen. Finde ich einen 
bestrechungswürdigen Vorschlag, aber dadurch keinen "muss so dein Weg".


GRuss Sven