[Berlin-wireless] Falter-Firmware: Testphase

[Sven Roederer]

Am 28.09.20 um 21:44 schrieb Martin Hübner:
> 
> Die Idee von Falter ist es, einen Package-Feed mit maximaler
> Portabilität zu haben. Falter kann man auch gegen den aktuellen
> OpenWrt-Snapshot bauen. Dafür war er ursprünglich auch von Nick gedacht
> gewesen.
> 

Da ein OpenWrt-Release unabhängiger Feed seit einigen Jahren quasi nicht
wirklich machbar ist, haben die meisten Feeds inzwischen OpenWrt-release
spezifische branche. Alles andere ist meiner Meinung nach, dauerhaft nur
schwer handhabbar.

>> Soweit ich das im Überblick habe, sind doch schon aller "Freifunk-Berlin-Kram"
>> als einzelnes Package vorhanden. Und auf den ersten Blick habt das neue Repo
>> die Pakete aus den verschiedenen Original-quellen nur zusammen kopiert. Wie
>> hilft das bei der Anpassung an Upstream-changes?
>>
> 
> Falter setzt das Konzept "alles ist ein Paket" sehr konsequent um. Muss
> es ja auch, da es streng genommen nur ein Package-Feed ist. Ein Beispiel:
> Baut man Falter gegen die aktuelle OpenWrt-stable, tritt ein LuCI-bug
> auf, bei dem die Reiter in der Kopf-Leiste verschwinden. Der Fix ist ein
> uci-defaults-script, dass in einem Paket bereitgestellt wird.
> 

Du meinst das hier: https://github.com/Freifunk-Spalter/packages/blob/9bebff79e66a7ecdf14ee32291761a7f590ddab3/packages/falter-berlin-fix-luci/files/999-fix_luci_buttons.sh ?
Patchen des LuCI-quellcodes zur Laufzeit des Images ... ist 'ne
interessante Idee. Aber da bekomme ich es lieber zur Beuzeit mit, dass
der Patch nicht angewendet werden kann, weil Upstream etwas geändert wurde.
Das dann auch dem Router zu finden, nach ggf. anwenden von LuCI-srcDiet
klingt nicht entspannend.
Aber auch das ist nur eine Meinung.

> Da der Bug in Snapshot-Images nicht auftritt, kann man das Paket danach
> getrost weglassen.
> 

Das wirft gleich folgende Frage bei mir auf: Wie macht ihr die Packetauswahl?
"Freifunk Berlin" hat da ja die Packagelists/

> Das kopieren aus den Originalquellen trifft nur bedingt zu. Nick hat da
> eine ganze Menge angepasst, damit die Pakete u.A. mit neuem LuCI laufen.

Beim kurzen Überfliegen der Pakete kam mir halt sehr vieles bekannt vor.
Durch eure geänderte Dateistruktur, ist der Austausch direkt über git
commits oder patches jedenfalls sehr umständlich.

> 
> Eine Randnotiz: Aktuelles LuCI unterstützt wohl Javascript. Dadurch kann
> das Timeout-Problem im OLSR-Plugin recht elegant gelöst werden.

Falls du https://github.com/freifunk-berlin/firmware/issues/832 meinst,
das wurde ja upstream gefixt.

> Ansonsten:
> Falter verfolgt konsequent, dass Entwickeln zu vereinfachen. Es
> verwendet kein überdimensioniertes Build-System mit Patches für fremden
> Code, sondern enthält nur das absolut nötigste, um
> Freifunk-Funktionalität zu bieten. Dadurch minimieren wir den
> (Code-Wartungs-)Aufwand deutlich.

Siehe "runtime-patching von Upstream-Code auf dem Router" ...

> Da der Unterbau ein ungepatchtes OpenWrt ist, kann Falter grundsätzlich
> für jedes OpenWrt-fähige Gerät gebaut werden. Das man rund ein Jahr
> warten muss, bis ein OpenWrt-Gerät durch Freifunk unterstützt wird,
> sollte damit der Vergangenheit angehören.
> 
Die langen Entwicklungszyklen von "Freifunk Berlin" liegen nicht an
patchen von OpenWrt, LuCI oder anderen Feeds, sondern eher am Wizard,
den UpstreamÄnderungen, die auch "Spalter Firmware" treffen, dem
Anspruch welche Fehler für ein release gelösßt sein sollten und
Entwicklern und Testern.


Sven