@MPW und andere … da grauts mir aber gleich …
ihr baut eure Toolchain ja , damit könnt ihr dann compilen bis zum sankt nimmerlein.
wenn man ein update macht, dann will man gefälligst auch ein update haben = etwas weniger bugs , etwas besserer code … gerade so wie er aus all den 1000 einzelprojekten kommt!
Wenn man jetzt das update - spiegelt - also statisch macht … dann willkommen in der docker welt.
@fuzzle: Wir bauen 16 verschiedene Domänen mit jeweils allen Targets. Das hat jetzt irgendwie 'ne Woche gedauert, bis das endlich mal alles durchlief.
Genau wie bei uns. Was würde es schaden, direkt vor dem eigentlichen Bauen einen konsistenzüberprüften lokalen Spiegel anzulegen? Mit Meldung wenn was fehlt?
Wie oben geschrieben: Es handelt sich um x-fach kaskadierte Repositories.
Um das Scheitern von Holen/Updaten von Repositories zu vor dem Build zu erkennen fehlt Gluon eine funktionierende Kristallkugel.
Will sagen: Das Fehlen von Repositories wird bemerkt, wenn sie geprüft werden. Und wann werden sie geprüft? Bevor der eigentliche Build startet.
@MPW - dann ist das ja eure design entscheidung, jedesmal eine saubere neue Buildchain zu bauen, obwohl alle Domänen letztendlich vom Softwarestandpunkt gleich sein sollten … (nebst der config)
könntet ihr überlegen das Makefile so anzupassen das die Chain 1* nur gebaut wird und dann für die einzelnen configs durchläuft.
denn die Buildumgebung fertig zu bekommen, dauert - und braucht manchmal auch mehrere anläufe wie @adorfer angemerkt hatte
im extremfall hättet ihr dann anfang der woche andere Kernel und foo tools, refferenz openwrt - gluon refferenz commits als ende der Woche - also sehr inkonsistent. (wenn ihr euch das „neueste“ ziehen solltet)
Ich weiss ja nicht, auf was für Maschinen da gebaut wird aber wenn man nur die site.conf durchtauscht und bei 3 Architekturen bleibt, dann sollte es ein neuzeitliches System selbst auf HDD pro config/site etwa 15-25min brauchen.
Was bringt einem ein neuzeitliches System, wenn ich wie Anno 2005 nur auf einem Kern bauen kann? Wir haben hier eine Amazon-Maschine mit 16 Kernen zum Bauen zur Verfügung. Wenn ich davon nur einen nutzen kann, hilft mir das gar nichts. Wir bauen alle Targets, das sind derzeit fünf. Und natürlich wäre das ganze in wenigen Stunden geritzt, wenn man es nicht x mal anschmeißen müsste.
Ich finde die Kommentare nicht hilfreich. Das muss gefixt werden, es kann ja nicht sein, dass nur 10% der Buildvorgänge erfolgreich sind, weil irgendwelche Netzwerkabhängigkeiten nicht klappen. Da muss ins make-file eine Schleife rein, die das so lange probiert, bis der Download klappt.
Wenn das so wäre, dann würde es nichts bringen, korrekt.
Da musst Du aller Wahrscheinlichkeit nur nur die site.conf/site.mk durchtauschen.
Dein Einwand zählt also nicht. Du kannst dann auch ggf. mit 24 Kernen bauen.
Wenn das denn so einfach wäre. Genau das tun wir, pro Runde gibt es jeweils nur ein ‚make update‘ und trotzdem funktioniert es nicht zuverlässig. Meistens gibt es aber schon in der ersten Runde einen Abbruch bzw. es werden nicht alle oder gar keine Images erzeugt. Das ist einfach frustrierend.
Im Moment helfe ich mir, indem ich die erste Runde mit nur einem Kern baue und im Laufe der weiteren Durchgänge auf das ‚make update‘ verzichte, so dass garantiert die bereits heruntergeladenen Dateien verwendet werden.
Kannst gerne unser Buildscript anschauen, vielleicht haben wir ja auch einen groben Fehler drin.
Ich versehe nicht, warum ihr „make update“ macht, wenn ihr nur die site.conf und i18n-files tauscht.
Meines Wissens ist das überflüssig.
Wenn gerade frisch geklont wurde macht das keinen Sinn, du hast recht. Ich schmeiße es raus.
Wie verhält sich das denn mit verschiedenen Targets? Muss ich, wenn ich das Target wechsle make update machen oder läuft das separat?
Wenn es Änderungen am Source gibt, die mit hinein sollen (nach einem git pull) musst Du das „make update“ für alle Targets laufen lassen.
nice one …
denke es sollte ohne make update bedeutend besser laufen (wobei du das dann später (beim reuse der buildchain in ein paar wochen) am Anfang einmal machen musst um eben update zu machen …)
würde auch noch ein time vor das make schreiben und logs generieren … erleichtert die Fehlersuche ungemein.
time make .... V=99 2>&1 | tee make_$SITE_$(date +%y%m%d_%H%M).log
FEHLER wenn ihr so wollt liegt aber hier :
rm -rf gluon
git clone https://github.com/freifunk-gluon/gluon.git gluon -b $RELEASE
ihr schmeisst das ganze gluon weg und holt es neu, die Lösung hab ich oft schon gesehen , weil es „schwierig“ oder „unintuitiv“ ist - wie das mit den git submodules läuft. So sollte das ja bei euch denk ich auch drinne sein … ein update dessen funktioniert bei uns so
# update gluon to latest master - this may be dangerous, because even with caution by gluon, there may be unforseen bugs
# and also push this into actual repo
git submodule update --remote gluon && git add gluon
git commit -m "update gluon"
git push
das führen wir aus wenn wir uns das neueste gluon holen wollen, dann make update
Besten Dank!
Was bewirkt das ‚time‘ vor dem ‚make‘? Ich habe dazu keine Info gefunden.
Wo würdest du deine Update-Befehle bei uns im Script einbauen, wenn wir das lokale Repo nicht mehr komplett löschen wollen?
Beziehungsweise: wo kann man sich mal euer komplettes Buildscript anschauen?
das make passt du in eurem hauptscript an mit meinen Vorschlägen
das rm gluon schmeisste ganz raus … bzw schreibst dass in ein fresh-gluon.sh miniscript - um dir bequem gluon wirklich fresh and clean zu holen …
dann noch ein script für das make update update-gluon mini script - inkl. dem submodule update.
das wärs schon.
Kucken kannst du Freiburger script hier (wobei wir ja nicht extra für x domänen bauen, aber verschiedene branches …)
die make befehle sind alle in fffrmaker script … was mit
fffrmaker <v2016.1.2.b>
aufgerufen wird
https://cccfr.de/git/viisauksena/firmware/blob/support/fffrmaker
https://cccfr.de/git/viisauksena/firmware/blob/support/Makefile
aber evtl verhaut das euer sign …
Danke, das habe ich schon umsetzen können und teste gerade. Eine Sache fiel mir auf, die doch sehr störend ist.
Durch das Submodule Update wird ein Login mit einem Github Account verlangt.
Nun hat nicht unbedingt jeder, der unsere Firmware nachkompilieren will, unbedingt einen Github Account - und ich möchte meinen ungern öffentlich machen… 
Gibt es einen Weg, das ohne jede Anmeldung zu erledigen?
@collimas verzichte doch einfach auf auf commit und push,
wir machen das damit der code in unseren jeweiligen git auch wirklch der aktuelle bau Code ist.
wer das nur lokal auscheckt zum nachbauen muss ja nur später
make updater
und git submodule update …
machen um wieder aktuell zu sein, oder schlicht alles gaaaanz neu auschecken und von 0 an bauen
Ok, dann also einfach die auskommentierten Zeilen weglassen?