Hi,
Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 0.9 * Gluon-Version: v2016.1.x * Commit ID: 15886fb65b9bcae8770f0bfa1bfc3718f70c9541 * Download: http://firmware.ffnw.de/0.9/
Folgende upstream Änderungen gab es: * https://gluon.readthedocs.io/en/v2016.1.4/releases/v2016.1.4.html#bugfixes
* Fixes #714 https://github.com/freifunk-gluon/gluon/issues/714
* Fixes #721 https://github.com/freifunk-gluon/gluon/issues/721
* Fixes #754 https://github.com/freifunk-gluon/gluon/issues/754
* ar71xx-generic: add support for Ubiquiti Rocket M XW
* Fixes #755 https://github.com/freifunk-gluon/gluon/issues/755
* Fixes #687 https://github.com/freifunk-gluon/gluon/issues/687
Folgende Comunnity speziffischen Änderungen gab es: * Neues Paket ffnw-hoods hinzugefügt. Dieses Paket enthält das hoodfile welches eine json datei ist die, die default hood beschreibt. * Neues Paket ffnw-hoodselector hinzugefügt. Dieses Paket enthält den hoodselector welcher eine halbautomatische Layer 2 Segmentierung anhand des hoodfiles realisiert. * geolacator patch führt zur error meldung wenn die positions Qualität = 0 ist. * nightly autoupdater branch hinzugefügt. liefert Images die täglich aus dem aktuellen master compeliert werden. * firmware signatur key von lethexa(Tim aus WHV) hinzugefügt
Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden: git diff v0.8.2 v0.9
Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: git diff b290ec25eca44cc8bb30a407958a539151a06aab 384427d91babb80756b3e5df75c6c361fd3b3f1a
Viele Grüße Tarek
On 05/18/16 12:22, lrnzo wrote:
ginge das nicht sehr zu lasten des flashspeichers?
Am 18.05.2016 um 11:38 schrieb Jan-Tarek Butt via Dev:
- nightly autoupdater branch hinzugefügt. liefert Images die täglich aus dem aktuellen master compeliert werden.
Korrekt.
testing und nightly sind aber eher für entwicker krams gedacht. Also z.b. ich commite und pusche änderungen in den master. Lege mich schlafen in der zeit sieht der CI oh da sind änderungen ich baue mal ne neuer firmware und stelle die unter nightly zurverfügung am nächsten morgen kann ich schnell auf meinen Router welcher auf nightly steht und schaune ob alle änderunge so tuhe wie sie tuhen sollten.
Das wäre ein anwendungs zenario. ich denke allgemein kann Clemens zu der nightly idee mehr sagen.
Ich plane in 2 Wochen mir mach den CI kram genau anzuschauen. Ich fände z.b. eine ondemand Lösung sinniger. Denn es muss ja nicht ständig neu gebaut werden wenn es keine Änderungen gibt.
vg Tarek
Am Mittwoch, 18. Mai 2016, 12:22:35 CEST schrieb lrnzo via Dev:
ginge das nicht sehr zu lasten des flashspeichers?
Naja ein paar Schreibvorgänge schafft der schon...
Und bevor da Missverständnisse aufkommen: der Nightly Channel ist für uns Entwickler gemacht. Jeder normale Benutzer der diesen Channel einstellt wird von mir persönlich bis an sein Lebensende böse angeguckt :D
Kleine Korrektur am Rande: Updates werden in diesem Channel immer dann ausgeliefert, wenn es eine Änderung im siteconf Repo gab (also nicht unbedingt täglich). Den Verlauf des Buildprozesses kann man hier einsehen: https:// git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds
Viele Grüße Clemens
On 05/18/16 12:45, Clemens John via Dev wrote:
Am Mittwoch, 18. Mai 2016, 12:22:35 CEST schrieb lrnzo via Dev:
ginge das nicht sehr zu lasten des flashspeichers?
Naja ein paar Schreibvorgänge schafft der schon...
Und bevor da Missverständnisse aufkommen: der Nightly Channel ist für uns Entwickler gemacht. Jeder normale Benutzer der diesen Channel einstellt wird von mir persönlich bis an sein Lebensende böse angeguckt :D
Kleine Korrektur am Rande: Updates werden in diesem Channel immer dann ausgeliefert, wenn es eine Änderung im siteconf Repo gab (also nicht unbedingt täglich). Den Verlauf des Buildprozesses kann man hier einsehen: https:// git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds
Ah also doch ondemand. :)
vg Tarek
Hi,
zu diesen Release-Channels habe ich noch eine Frage: wieso wird jetzt nicht zum Beispiel die 0.9 als "Testing" ausgerollt?
lg Malte
On 18.05.2016 12:45, Clemens John via Dev wrote:
Am Mittwoch, 18. Mai 2016, 12:22:35 CEST schrieb lrnzo via Dev:
ginge das nicht sehr zu lasten des flashspeichers?
Naja ein paar Schreibvorgänge schafft der schon...
Und bevor da Missverständnisse aufkommen: der Nightly Channel ist für uns Entwickler gemacht. Jeder normale Benutzer der diesen Channel einstellt wird von mir persönlich bis an sein Lebensende böse angeguckt :D
Kleine Korrektur am Rande: Updates werden in diesem Channel immer dann ausgeliefert, wenn es eine Änderung im siteconf Repo gab (also nicht unbedingt täglich). Den Verlauf des Buildprozesses kann man hier einsehen: https:// git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds
Viele Grüße Clemens
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 05/18/16 12:59, Malte Modler via Dev wrote:
Hi,
zu diesen Release-Channels habe ich noch eine Frage: wieso wird jetzt nicht zum Beispiel die 0.9 als "Testing" ausgerollt?
Baut gerade noch.
das dauert noch ein bisschen da dort 4 zusätzliche Architekturen gebaut werden.
vg Tarek
Achso okay,
ich dachte nur, weil die 0.8.x waren ja auch nie im Testing-Channel.
lg Malte
On 18.05.2016 13:02, Jan-Tarek Butt via Dev wrote:
On 05/18/16 12:59, Malte Modler via Dev wrote:
Hi,
zu diesen Release-Channels habe ich noch eine Frage: wieso wird jetzt nicht zum Beispiel die 0.9 als "Testing" ausgerollt?
Baut gerade noch.
das dauert noch ein bisschen da dort 4 zusätzliche Architekturen gebaut werden.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Mittwoch, 18. Mai 2016, 13:04:13 CEST schrieb Malte Modler via Dev:
ich dachte nur, weil die 0.8.x waren ja auch nie im Testing-Channel.
Hi Malte,
der testing Channel ist, wie der stable Channel, ein manueller Channel. Das heißt dort gibt es nur ein Update, wenn sich vorher jemand ein paar Stunden hingesetzt und extra ein Image gebaut hat. Wenn einer der Entwickler Zeit hat machen wir das, sonst nicht.
Der nightly Channel ist hingegen ein automatisierter Channel. Da baut unser CI-System einfach bei jeder Änderung (egal ob Fehlerhaft oder nicht) ein Image für die Entwickler aus dem master Branch des siteconf Repos. Da gibt es auch weder Sichtkontrolle noch Versionen oder irgendeinen Qualitätscheck.
Viele Grüße Clemens
Moin
der testing Channel ist, wie der stable Channel, ein manueller Channel. Das heißt dort gibt es nur ein Update, wenn sich vorher jemand ein paar Stunden hingesetzt und extra ein Image gebaut hat. Wenn einer der Entwickler Zeit hat machen wir das, sonst nicht.
ich denke über diese Thematik sollten wir nochmal reden. Wenn wir einen "Testing" Channel haben, dann sollten wir diesen auch gewissermassen pflegen. Meine Vorstellung wäre es vor jeder neuen "stable" eine neue Testing version zu bauen. Diese kann dann über den Testing Branch verteilt werden. Nach einiger Zeit im Testing branch und keinen aufgetretenen Fehlern kann man dann die Stable ausrollen.
Wir hätten dadurch eine bessere Testabdeckung, da die Testing Router automatisch immer Updaten auf die nächste Testing. Ich bräuchte dann nicht jedes mal händisch Router zum Testen umflashen sondern würde den bei mir zu Hause auf Testing fahren. Anhand der "neuen" Testing version kann ich die Firmware dann testen und schauen ob alles läuft und im Anschluss das stable manifest signieren.
Ich denke wir können das ja beim "Entwickler Treffen" mal Face To Face ausdiskutieren.
Gruß Johannes
hey,
Zitat von Johannes Rudolph via Dev dev@lists.ffnw.de:
ich denke über diese Thematik sollten wir nochmal reden. Wenn wir einen "Testing" Channel haben, dann sollten wir diesen auch gewissermassen pflegen. Meine Vorstellung wäre es vor jeder neuen "stable" eine neue Testing version zu bauen. Diese kann dann über den Testing Branch verteilt werden. Nach einiger Zeit im Testing branch und keinen aufgetretenen Fehlern kann man dann die Stable ausrollen.
+1 nach einem ähnlichen vorgehen arbeiten einige (Kernel, Debian...)
Wir hätten dadurch eine bessere Testabdeckung, da die Testing Router automatisch immer Updaten auf die nächste Testing. Ich bräuchte dann nicht jedes mal händisch Router zum Testen umflashen sondern würde den bei mir zu Hause auf Testing fahren. Anhand der "neuen" Testing version kann ich die Firmware dann testen und schauen ob alles läuft und im Anschluss das stable manifest signieren.
stelle dann lieber einen weiteren router auf und lasse ihn auf testing laufen dauerhaft, um zu testen! +1
Hallo Tarek,
vielen Dank für das Bereitstellen der 0.9 Test-Firmware, die wirklich toll auf meinem TP-Link Archer C7 v2 läuft :-)
* 2,4 Ghz (Client) - OK * 2,4 Ghz (Mesh) - OK * 5 Ghz (Client) - OK * 5 Ghz (Mesh) - Ungetestet, mangels zweitem 5 Ghz fähigem Gerät
Kann keine genauen Geschwindigkeitsangaben o.ä. machen, dem Augenschein nach funktioniert alles zufriedenstellend. Sollte sich an dem Stand etwas verändern, berichte ich gerne darüber.
Ich drücke allen Freifunkern die Daumen für die Firmware 0.9, den Hoodselector und wünsche weiterhin gutes Gelingen.
Drahtlose Grüße
Robin Matulinski
Hi,
vielen Dank für das Bereitstellen der 0.9 Test-Firmware, die wirklich toll auf meinem TP-Link Archer C7 v2 läuft :-)
* 2,4 Ghz (Client) - OK * 2,4 Ghz (Mesh) - OK * 5 Ghz (Client) - OK * 5 Ghz (Mesh) - Ungetestet, mangels zweitem 5 Ghz fähigem GerätKann keine genauen Geschwindigkeitsangaben o.ä. machen, dem Augenschein nach funktioniert alles zufriedenstellend. Sollte sich an dem Stand etwas verändern, berichte ich gerne darüber.
Ich drücke allen Freifunkern die Daumen für die Firmware 0.9, den Hoodselector und wünsche weiterhin gutes Gelingen.
Danke für die Rückmeldung :)
vg Tarek
Hi,
On 05/18/16 12:59, Malte Modler via Dev wrote:
Hi,
zu diesen Release-Channels habe ich noch eine Frage: wieso wird jetzt nicht zum Beispiel die 0.9 als "Testing" ausgerollt?
Folgende 2 bugs haben die testing images so lage aufgehalten: https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues/38 https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues/39
Vorallem der Kconfig krams hat ca. 2 Tage gedauert diesen zu finden. Hintergrung: Kconfig == Kernelconfig. Kconfig wird von openWRT ein wenig sehr missbraucht und ist zuständig die Packet Abhängigkeiten der openWRT packages aufzulösen. Für solch einen zweck wurde das nie entwickelt.
vg Tarek
Hallo Tarek,
leider musste ich gerade mit bedauern feststellen das fastd bei jedem Durchlauf des Hoodselectors getrennt wird.
Daher habe ich die Milestone[1] wieder aufgemacht und habe eine Issue[2] angelegt
Gruß Johannes
[1] https://git.nordwest.freifunk.net/ffnw-firmware/packages/milestones/3 [2] https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues/41
Am 18.05.2016 um 11:38 schrieb Jan-Tarek Butt via Dev:
Hi,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 0.9
- Gluon-Version: v2016.1.x
- Commit ID: 15886fb65b9bcae8770f0bfa1bfc3718f70c9541
- Download: http://firmware.ffnw.de/0.9/
Folgende upstream Änderungen gab es:
https://gluon.readthedocs.io/en/v2016.1.4/releases/v2016.1.4.html#bugfixes
Fixes #714 https://github.com/freifunk-gluon/gluon/issues/714
Fixes #721 https://github.com/freifunk-gluon/gluon/issues/721
Fixes #754 https://github.com/freifunk-gluon/gluon/issues/754
ar71xx-generic: add support for Ubiquiti Rocket M XW
Fixes #755 https://github.com/freifunk-gluon/gluon/issues/755
Fixes #687 https://github.com/freifunk-gluon/gluon/issues/687
Folgende Comunnity speziffischen Änderungen gab es:
- Neues Paket ffnw-hoods hinzugefügt. Dieses Paket enthält das hoodfile welches eine json datei ist die, die default hood beschreibt.
- Neues Paket ffnw-hoodselector hinzugefügt. Dieses Paket enthält den hoodselector welcher eine halbautomatische Layer 2 Segmentierung anhand des hoodfiles realisiert.
- geolacator patch führt zur error meldung wenn die positions Qualität = 0 ist.
- nightly autoupdater branch hinzugefügt. liefert Images die täglich aus dem aktuellen master compeliert werden.
- firmware signatur key von lethexa(Tim aus WHV) hinzugefügt
Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden: git diff v0.8.2 v0.9
Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: git diff b290ec25eca44cc8bb30a407958a539151a06aab 384427d91babb80756b3e5df75c6c361fd3b3f1a
Viele Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin
hat sich alles geklärt, nach Rücksprache mit Tarek lag der Fehler auf meiner Seite ;)
Für die Hoodtest Firmware hatte ich seinen neuen Hoodselctor genutzt.
In einer anderen Diskussuon hatten wir uns auf ein einheitliches Namesschema der SN geienigt.
In der neuen Server Config kann es mehere fastd Instanzen pro Server geben. Ich habe das mit Stefan nun gelöst und jede fastd instanz bekommt einen eindeutigen DNS Namen.
Der fehler war aufgetreten da im Hoodfile 2 fastd Verbindungen auf dem gleichen Server angegeben waren und der hoodselector nur immer einen eingetragen hat. Der Hoodselector hat daher im festgestellt, das sich die Anzahl der Peers im Hood file von der Anzahl in der config (/etc/config/fastd) unterscheidet. Hat dann fastd beendet die Config neu gechrieben und fastd wieder gestartet.
Alles in Allem Problem gelöst. Grünes Licht von mir für die 0.9 -> ist auch schon signiert von mir
Gruß
Johannes
Am 20.05.2016 um 00:24 schrieb Jan-Tarek Butt via Dev:
Hi Johannes,
leider musste ich gerade mit bedauern feststellen das fastd bei jedem Durchlauf des Hoodselectors getrennt wird.
Ich kann diesen bug nicht bestätigen. Woran genau machts du das fest? Hast du logs bzw. die Ausgabe vom hoodselector?
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
hat sich alles geklärt, nach Rücksprache mit Tarek lag der Fehler auf meiner Seite ;)
Für die Hoodtest Firmware hatte ich seinen neuen Hoodselctor genutzt.
In einer anderen Diskussuon hatten wir uns auf ein einheitliches Namesschema der SN geienigt.
In der neuen Server Config kann es mehere fastd Instanzen pro Server geben. Ich habe das mit Stefan nun gelöst und jede fastd instanz bekommt einen eindeutigen DNS Namen.
Der fehler war aufgetreten da im Hoodfile 2 fastd Verbindungen auf dem gleichen Server angegeben waren und der hoodselector nur immer einen eingetragen hat. Der Hoodselector hat daher im festgestellt, das sich die Anzahl der Peers im Hood file von der Anzahl in der config (/etc/config/fastd) unterscheidet. Hat dann fastd beendet die Config neu gechrieben und fastd wieder gestartet.
Ich formuliere das noch mal ein wenig um. Es sind durchaus mehrere fastd Instanzen pro Server möglich nur eben keine redundanten URLs für die einzelnen fastd Instanzen. Das hat durchaus auch den vorteil das, bei Störungen Router seit sofort gesehen werden kann welche fastd Instanz betroffen ist. Es gibt aber ein Ticket [0] wo dieses durch aus als Optimierung besprochen werden kann.
Alles in Allem Problem gelöst. Grünes Licht von mir für die 0.9 -> ist auch schon signiert von mir
\o/ numero dos
vg Tarek
Am Freitag, den 20.05.2016, 16:56 +0200 schrieb Jan-Tarek Butt via Dev:
Alles in Allem Problem gelöst. Grünes Licht von mir für die 0.9 -> ist auch schon signiert von mir
\o/ numero dos
Stefan hat soeben Signiert \o/
jetzt fehlt nurnoch einer.
Done.
On 05/20/16 20:28, Bjoern Franke via Dev wrote:
Am Freitag, den 20.05.2016, 16:56 +0200 schrieb Jan-Tarek Butt via Dev:
Alles in Allem Problem gelöst. Grünes Licht von mir für die 0.9 -> ist auch schon signiert von mir
\o/ numero dos
Stefan hat soeben Signiert \o/
jetzt fehlt nurnoch einer.
Done.
Sehr gut ich würde dann jetzt den Blog-Artikel Fertig machen und von jemanden Korrektur lesen lassen. Im Anschluss würde ich ihn dann heute noch veröffentlichen.
Morgen Früh würde ich dann den simlink für stable auf 0.9 umbigen.
vg Tarek
Hi,
ich lese das später gegen und veröffentliche ihn Komme leider grade nicht dazu
Am 20. Mai 2016 20:34:17 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 05/20/16 20:28, Bjoern Franke via Dev wrote:
Am Freitag, den 20.05.2016, 16:56 +0200 schrieb Jan-Tarek Butt via
Dev:
Alles in Allem Problem gelöst. Grünes Licht von mir für die 0.9 -> ist auch schon signiert von mir
\o/ numero dos
Stefan hat soeben Signiert \o/
jetzt fehlt nurnoch einer.
Done.
Sehr gut ich würde dann jetzt den Blog-Artikel Fertig machen und von jemanden Korrektur lesen lassen. Im Anschluss würde ich ihn dann heute noch veröffentlichen.
Morgen Früh würde ich dann den simlink für stable auf 0.9 umbigen.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Zur Information!
root@ffnw-Hohenkirchen-Schubertstr17a:~# autoupdater wget: bad address 'autoupdate.ffnw' There seems to have gone something wrong downloading the manifest from http://autoupdate.ffnw/stable/ No usable mirror found.
Mit freundlichen Grüßen
Jens Ellerbrock
--------------------
Freifunk Nordwest e.V. Website
Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten)
Am 20.05.2016 um 21:52 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
ich lese das später gegen und veröffentliche ihn Komme leider grade nicht dazu
Hat bjo bereits getan danke dir :)
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
On 05/20/16 22:04, Jens Ellerbrock - Freifunk Nordwest e.V. wrote:
Zur Information!
root@ffnw-Hohenkirchen-Schubertstr17a:~# autoupdater wget: bad address 'autoupdate.ffnw' There seems to have gone something wrong downloading the manifest from http://autoupdate.ffnw/stable/ No usable mirror found.
Magst du kurz hier logs schreiben damit ich sehen kann an welchen server der router hängt.
vg Tarek
Hi,
das hatte ich auch heute kurzzeitig. Das Ganze ging nach ner halben Stunde wieder.
Das Problem lag wohl daran, dass der v6 Traffic nicht durchgegangen ist.
Am 20. Mai 2016 22:06:46 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
On 05/20/16 22:04, Jens Ellerbrock - Freifunk Nordwest e.V. wrote:
Zur Information!
root@ffnw-Hohenkirchen-Schubertstr17a:~# autoupdater wget: bad address 'autoupdate.ffnw' There seems to have gone something wrong downloading the manifest
from http://autoupdate.ffnw/stable/
No usable mirror found.
Magst du kurz hier logs schreiben damit ich sehen kann an welchen server der router hängt.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Laut log, welches eines völlig falsche Systemzeit hat aber von den Ereignissen passt.
Vpn02
Mit freundlichen Grüßen
Jens Ellerbrock
--------------------
Freifunk Nordwest e.V. Website
Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten)
Am 20.05.2016 um 22:06 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
On 05/20/16 22:04, Jens Ellerbrock - Freifunk Nordwest e.V. wrote: Zur Information!
root@ffnw-Hohenkirchen-Schubertstr17a:~# autoupdater wget: bad address 'autoupdate.ffnw' There seems to have gone something wrong downloading the manifest from http://autoupdate.ffnw/stable/ No usable mirror found.
Magst du kurz hier logs schreiben damit ich sehen kann an welchen server der router hängt.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
Jens Ellerbrock - Freifunk Nordwest e.V -
Jens Ellerbrock - Freifunk Nordwest e.V.
-
Johannes Rudolph -
lrnzo -
Malte Modler -
picard -
Robin Matulinski -
Stefan