Bedarf an aktuellen beta / experimentellen Firmware-Images?

Ich hab’ kurz mit @MPW geschnackt und momentan werden die beta / experimental-Firmwares nur bei Bedarf gebaut. Ich möchte mich damit evtl. näher beschäftigen und - sofern Interesse besteht - die entsprechenden Images automatisch bauen lassen, sodass man dann quasi “nightly”-Builds hat, die jeweils die aktuellsten Gluon-Commits enthalten. Einmal für v2016.1.x und evtl. auch für master.

Besteht denn grundsätzlich Interesse / Bedarf an solchen Firmware-Images?

1 „Gefällt mir“

Interesse aus technischer Sicht ja. Den Bedarf habe ich bisher nicht gesehen, aber das wird auf jeden Fall wieder interessant, wenn neue Router-Versionen auf den Markt kommen.

Nur bedenken, wir haben ~65 Domänen, da baut selbst ein Achtkerner mehrere Tage dran. Du solltest dich dann auf einzelne Domänen konzentrieren.

Oder gerne auch mal überlegen, wie man das vereinfacht. Es gibt z. B. den Hoodselector aus Nordwest, der mit einer Firmware verschiedene Konfigurationen fahren kann.

Alles in allem, komm mal vorbei, Unterstützung ist sehr gerne gesehen und würde uns sehr freuen!

1 „Gefällt mir“

Ja, für alle Domänen zu bauen, wenn’s dann nur in einer Hand voll genutzt wird, wäre unsinnig. Für’s erste könnten sich Interessenten hier melden, dann würde ich die Domäne in die „Bauliste“ aufnehmen. Falls das alles irgendwann vernünftig laufen sollte, dann könnte man das Ganze evtl. auf Autoupdates umstellen und dann jeweils für die Domänen bauen, in der Knoten existieren, die den „experimental“-Zweig ausgewählt haben - sofern sich das herausfinden lässt.

Darauf werd’ ich mal einen Blick werfen :slight_smile:

Ich werd’s mal versuchen; ist zwar nicht um die Ecke, aber machbar :slight_smile:

1 „Gefällt mir“

5 Beiträge wurden in ein neues Thema verschoben: Mitfahrgelegenheit aus Lette zum Freifunktreffen nach Münster

Ein Beitrag wurde in ein neues Thema verschoben: Mitfahrgelegenheit aus Lette zum Freifunktreffen nach Münster

Freifunk Hochstift hat auch eine Art auto-select drin, könnte man sich auch mal ansehen: https://firmware.hochstift.freifunk.net/stable/Changelog.html

Das automatische Bauen mit Jenkins läuft jetzt; je Domäne dauert das nach dem ersten Build des jeweiligen Targets 16 min. Für alle Domänen und Targets wäre das somit - wie bereits von dir angedeutet - unrealistisch.
Gibt’s denn eine Möglichkeit, zu sehen, welche Targets in welcher Domäne im Beta / experimental-Zweig genutzt werden?
Die nächste Frage wäre dann, wie man den Beta bzw. experimental-Zweig gestalten könnte. Beta = 2016.1.5 mit aktuellen Commits und experimental = master?

Ich schaue mir bei Gelegenheit mal die Lösungen mit Autoselect an, vielleicht kommt eine davon ja auch für uns in Frage :slight_smile:

Wenn mehrere Computer zur Verfügung stehen, könnte man vieleicht etwas Zeit mit einem Cluster herausbekommen, wie Distcc?

https://wiki.ubuntuusers.de/distcc/

1 „Gefällt mir“

Ich habe die Kompilierung mit distcc letzte Woche mal getestet, die Ergebnisse sind aber ausbaufähig. Leider habe ich den „pump“-Modus noch nicht ans laufen bekommen. Gibt es speziell dazu irgendwo eine Anleitung? pump make ... funktioniert nicht, weil der Befehl pump unbekannt ist. Das Paket pump scheint aber eine andere Aufgabe zu haben, jedenfalls geht’s damit auch nicht. Kann mir da vielleicht jemand helfen? Betriebssystem ist Ubuntu 16.04 LTS.

Das müsste über das Paket distcc-pump gehen:

sudo apt-get update sudo apt-get install distcc-pump

Das ist etwas für Netzwerk-Geraffel:
http://manpages.ubuntu.com/manpages/xenial/man8/pump.8.html

Nachtrag:
Vielleicht hilft Dir noch die man-page?
Da ist auch ein Quickstart:
http://manpages.ubuntu.com/manpages/xenial/en/man1/distcc.1.html

@prototyp vielen Dank, mit distcc-pump hat’s funktioniert :smiley: Komisch, dass das Paket in den Kurzanleitungen, die ich gefunden habe, nicht erwähnt wird.

Resultat: Statt ca. 1h Kompilierungsdauer (von grundauf neu) sind es mit distcc-pump und dem zweiten Rechner ca. 40 min. Der zweite Rechner allein braucht ca. 30 min, da der Prozessor wesentlich leistungsstärker ist (Core i7 4770 statt Opteron 3280). Ich werde mal die Rollen vertauschen, um zu gucken, ob es dann auch einen Vorteil gibt und ich die 30 min unterbieten kann.

@Handle Ich bekomme das nicht mehr auf die Kette, aber ich habe noch im Hinterkopf, das dist-cc sich ja einen Cluster aufbaut und es zu den Optimierungsmöglichkeiten gehört, die schnellesten Rechner oben zu führen…

Des Weiteren läuft distcc gerne Hand in Hand mit ccache, was sich dann beim erneuten Kompilieren bezahl macht. Dazu habe ich mal was kurzes im Internet gesucht…vielleicht Hilft das ein bisschen und so würde ich es mal probieren…

1 „Gefällt mir“