Wenn ich versucht den master Branch zu bauen, bekomme ich diesen Fehler:
`error: Your local changes to the following files would be overwritten by checkout:` ` package/firmware/ipq-wifi/board-qxwlan-e2600ac.bin` `Please commit your changes or stash them before you switch branches.` `Aborting`
Woran kann das liegen?
Hat sich beim build Vorgang was grundlegendes geändert, was ich berücksichtigen muss?
was ich daraus lese und ich habe von git eigentlich wenig Ahnung ist das es lokale Änderungen an dieser Datei gibt und diese bei einem neuen Checkout überschrieben werden.
Du sollst deine Änderungen dazu sichern.
stackoverflow liefert dazu How do I resolve git saying "Commit your changes or stash them before you can merge"? - Stack Overflow
viel Erfolg
danke, ja das sehe ich auch, aber das passiert ja in unserer CI, die das automatisch macht, also auschecken und 2 patches einspielen, dann bauen. Im anderen branch funktioniert das ja auch mit dem selben script und in einer älteren gluon version hat es auch noch un dem master branch funktioniert, daher die frage, ob Gluon neuerdings irgendwie einmal mehr checkt ob sich im git verzeichnis was geaendert hat als vorher?
Was macht denn die CI da genau? Sieht so aus als würde da ein sehr alter OpenWrt source tree zum Einsatz kommen. Die Datei gibt es an der Stelle seit Juli 2020 nicht mehr. Findet ein make update statt? Wird am Ende des Builds das OpenWrt Verzeichnis weggeräumt damit der nächste Build sauber starten kann?
Nochmal zum Verständnis: Du willst den Gluon master Branch mit dem make-release.sh Script in dem von dir verlinkten Repo bauen?
Auf den ersten Blick: das wird nicht hinhauen, da du da eine ganze Reihe Targets drin hast, die im Gluon master nicht mehr existieren. GLUON_BRANCH und GLUON_DEPRECATED gibt’s so auch nicht mehr.
Edit: Der Build Container den ihr benutzt ist auch ein bisschen oll. Gluon master braucht dieser Tage Python 3. Ein Debian Buster darf es da schon sein, Bullseye sollte auch problemlos klappen.
ja, allerdings nicht mit dem make-release.sh sondern dem build.sh im .gitlab-ci/ Ordner, wie man in der .gitlab-ci.yml sieht.
Das sind ja schon mal ein paar tipps, danke