Hallo zusammen,
nachdem ich jetzt die nötigen Umstellungen bei den Configs vorgenommen habe, komme ich nun nicht mehr weiter.
Beim Bauen werden keine Images erzeugt, im Buildlog finde ich keinen konkreten Hinweis.
Hat hier vielleicht jemand den Durchblick?
Hier der Inhalt des gluon/site Ordners plus dem aktuellen Buildlog: HiDrive
package/Makefile:101: recipe for target '/home/michael/fflip-fw/gluon/lede/staging_dir/target-mipsel_24kc_musl-1.1.16/stamp/.package_compile' failed
make[2]: *** [/home/michael/fflip-fw/gluon/lede/staging_dir/target-mipsel_24kc_musl-1.1.16/stamp/.package_compile] Error 2
Das ist schon mal ein konkreter Hinweis.
Hast du den Build mit dem -j1 Parameter schon ausprobiert?
Habe nun noch einmal mit dem Schalter -j1 gestartet, damit man die einzelnen Threads besser unterscheiden kann, allerdings ohne Änderung. Der Fehler tritt immer noch auf.
bauen mit:
--output-sync=recurse BUILD_LOG=1 V=s
der sync sorgt dafür, dass man mit mehreren Kernen bauen ohne dass der Log schwer lesbar ist.
Zudem gibt es mit BUILD_LOG=1 dann für jeden einzelteil separate Log-Dateien.
V=s macht den Log verbose.
Besten Dank, es hat funktioniert.
und was war der Fehler? meine Parameter beheben ja keinen Fehler, zeigen nur mehr Debug-Output an…
DANKE! Ich bin gestern abend fast wahnsinnig geworden, mit -j30 sah’ man nix und -j1 brauchte ewig (MULTIDOMAIN ist … ein wenig sehr engstirnig; mit -j1 dauerte es jeweils 5 Minuten, bis die nächsten Korinthen bereit lagen).
Die falsche Fährte mit »musl« hatte ich mit >1 Kern übrigens auch, ist das zufällig eines der letzten gebauten/hinzugefügten Pakete?
Diverse Fehlkonfigurationen meinerseits was die Multidomain-Settings angeht. Da hat hat sich doch so einiges geändert. Ohne deine Parameter hätte ich das nie gelöst. Immer nur eine „Build failed“-Meldung ohne Hinweis auf den Grund ist nicht wirklich hilfreich.
Falls jemand eine Referenz braucht, um sein eigenes Setup zum Laufen zu bekommen:
Hast du die Release notes und die Multidomain Doku gelesen?
Falls ja, fehlt dort etwas?
bei den Darmstädtern gibts auch schon eine Weile eine Referenz:
https://git.darmstadt.ccc.de/ffda/site/tree/multidomain/
Sicher, aber auf jeden Fall hatte ich einiges überlesen. Der Bereich in der domain.conf, wo die Domäne und Subdomänen konfiguriert werden, war für mich nicht wirklich eindeutig zu verstehen. Dass Label explizit nur einmal verwendet werden dürfen, war mir anfangs nicht klar.
Ja und ja. Mein, vielleicht optimistischer Ansatz war, die site.conf nach domains/foo.conf zu kopieren. (Weil, so lief unser bisheriger Ansatz: locode ermitteln, $locode.conf als neue site.conf installieren, Cleanup && reboot.)
Warum das System derart kastriert wird, daß viele sinnvolle Optionen auf der Strecke bleiben, erschließt sich mit nicht. Ebensowenig, warum extensive Tests zum compilation fail führen; schmeißt mit Warnungen um Euch, aber ignoriert die Fehler doch erstmal!
Dies …
mesh_vpn.bandwidth_limit
mesh_vpn.bandwidth_limit.enabled
mesh_vpn.bandwidth_limit.ingress
mesh_vpn.bandwidth_limit.egress
… würde ich schon als per-site-Werte nehmen wollen. Und …
regdom
… sehe ich in jedem grenznahen Mesh als Herausforderung, jedenfalls nicht überflüssig.
man hätte seine Vorschläge ja auch schon während der lange währenden Entwicklung - oder in den letzten Monaten seit dem merge des Features - einbringen können 
Änderungswunsch → issue anlegen
Ich verfolge die Gluon-Entwicklung nur sehr, sehr peripher; ich gucke mir das Endprodukt an und halte es entweder für verfolgenswert (2018.1) oder nicht (2017.x). Für eine aktivere Partizipation fehlt mindestens Zeit.
Das endet in »RTFM« und »works-as-designed«. Das Problem hat ja kein Entwickler, denn der weiß ja, wie es funktioniert. Die Schmerzen haben nur die Nutzer, die nach n Minuten sinnlosen Bauens vor der nächsten Fehlermeldung stehen.
Es wiederum so zu lösen, statt die Fehler zu sammeln und zu ignorieren, ist eine bewußte design decision gewesen, aus der ein deutliches Fehlen eines Problembewußtseins spricht; meine Don-Quichotte-Zeit ist abgeschlossene Vergangenheit.
Schön wär’s gewesen. Vor lauter Not habe ich zwischendurch mal die Config der Darmstädter nachbauen wollen - mit dem Ergebnis, dass das auch nicht lief. Ich vermute, dass nach dem Erstellen der Config noch etwas am Master geändert wurde, so dass der Release nicht mit der Config klar kam. Nach einem Versuch habe ich aber aifgegeben, dort nach einem Fehler zu suchen und mich lieber ans Debugging meiner eigenen Config gemacht.
Full ACK. Wenn man nicht aktiv am Entwicklungsprozess beteiligt ist (aus welchen Gründen auch immer), ist es schwierig, gewisse Entscheidungen der Entwickler nachzuvollziehen oder gar verstehen zu können. Da kann man sich dann nur durchbeißen. Es ist leider frustrierend, auf solch große Hürden beim Nachbauen eines Releases zu stoßen. In den Configs blieben bei v2018.1 wenige Steine auf den anderen, es wurde wirklich sehr viel umgeworfen. Und wenn man die Gründe nicht nachvollziehen kann, kann sowas schon mal etwas willkürlich wirken. Ich finde es eine gute Idee, die Änderungen dokumentieren zu wollen, aber dann sollten alle Änderungen dokumentiert, nachvollziehbar und mit Beispielen versehen sein. Ich hätte mir einen Satz Konfigurationsdateien gewünscht, der vollständig, dokumentiert ujnd getestet ist - den man notfalls ohne jede Änderung bauen könnte. Mit Hilfe einer solchen funktionierenden Konfiguration käme ich trotz vorhandender (aber meiner Meinung nach von Entwicklern für Entwickler geschriebenen) Dokumentation viel schneller zum Ziel.
Ich glaube, es gäbe viel mehr Freifunk-Communties mit eigener Gluon-Firmware, wenn diese leichter zu bauen wäre bzw. weniger Kenntnisse zum Bauen vorausgesetzt würden.
Hallo,
ich maintaine die Site von Freifunk Darmstadt, welche Probleme hattest du denn beim bauen? Wenn du Fehlermeldungen postest kann ich dir weiterhelfen.
Grüße, hexa
In deinem ersten Buildlog findest du übrigens einen Hinweis auf deinen ursprünglichen Fehler:
ln: failed to create symbolic link '/home/michael/fflip-fw/gluon/lede/build_dir/target-mipsel_24kc_musl-1.1.16/gluon-site/domains/fflip_d1_ff.json': File exists
Das kann ich jetzt prinzipbedingt nicht (mehr) beurteilen, da ich Gluon seit 2014 als FW-Basis nutze und insofern zumindest der „weniger Kenntnisse“-Teil nicht greift. IMHO hat das Team hinter Gluon mit v2018.1 sich wirklich Mühe gegeben, gefühlt wurde mehr dokumentiert, wie was zusammenspielt als vorher (wobei ich v2017.x nicht bewußt verfolgte; mit 2016.2er Basis tut unser Netz hinreichend stabil, die Probleme Anderer mit 2017.x wollten wir uns nicht anlachen).
Allerdings ist das Multidomain-Zeug zu einem Bürokratiemonster geworden; wir hatten uns sowas ja schon vor Längerem gebaut, auf Basis von „site-select“ (gibt/gab mal ein solches Package), wo stumpf die site.conf ausgetauscht und dann rekonfiguriert wurde. Simpel, aber tat soweit.
Ich gehe davon aus, daß hinter dem gewählten Ansatz, die site.conf genau so zu zerstückeln, praktische Überlegungen stehen; dazu hätte etwas mehr stehen dürfen, denn rein programmtechnisch müßte auch ein Overloading funktionieren, ein Überschreiben der Werte aus der site.conf mit denen aus der domain.conf (was lt. readthedocs auch der gewählte Weg ist).
(Solche Entscheidungen ändert man aber nicht mehr per Feature Request, der Zug ist abgefahren. Schon weil jede Änderung bestehende Setups wieder inkompatibel machen würde. Einzig der Build-Prozeß kann den Frust noch minimieren — Fehler sammeln und kollektiv ausgeben anstatt beim ersten abzubrechen.)
Anway, die technisch-kognitive Hürde, ein 0815-Gluon zu bauen, ist imho dennoch mittlerweile gering. Und wer sich aufmacht, Gluon mit eigenen Paketen oder denen Dritter aufzumöbeln, wird sich zwangsweise einarbeiten müssen. Und so, wie es implementiert wurde, wird zumindest der Zentralisierung wirksam begegnet 
Ja, das ist durchaus lobenswert.
Die Situation, dass viele Communities die 2017.x nicht ausgerollt haben, hatte viele Ursachen.
Die Notwendige „Sprunghöhe“ beim Anpassen lokaler Packages war eine davon.
Was die site.conf anbelangt: Ein „halbwegs intelligenter“ Converter von 2016->2017->2018 sollte für eine begabte Scriptgelehrte Person durchaus machbar sein.
(Von einem apt release-upgrade erwartet man doch auch irgendwie, dass zumindest elemntare mit Herübergeholt werden. Ja, bei den Plasteroutern selbst klappt das ja auch.
Aber hilfreich wäre es vermutlich für viele kleinere Communities, wenn es so etwas auch für die site.conf geben würde.
Die ist bei 2018.1 ja leider wieder erneut vorhanden. Im Falle von Config-Mode-Dingen ist mir derzeit nicht klar, wie 2016s function M.handle(data) in 2018.1 abgebildet werden kann; derlei scheint extern abzulaufen?
Steinigt mich, aber das erwarte ich innerhalb des Gluon-Projekts; you broke it, you fix it. Inklusive eines „(legacy) site.conf to domain.conf“-Converters.