Build Anleitung angepasst #1
No reviewers
Labels
No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
No Milestone
No Assignees
5 Participants
Notifications
Total Time Spent: 2 hours 41 minutes
Due Date
Felix
2 hours 41 minutes
No due date set.
Dependencies
No dependencies set.
Reference: freifunk-franken/firmware#1
Loading…
Reference in New Issue
No description provided.
Delete Branch "(deleted):master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Angepasst auf das neue Freifunk Franken Git
Fehlerhaftes Packet getauscht gegen aktuelles
Build Anleitung angepasst
Adapted to the new Freifunk Franken Git
Faulty packages are exchanged for the current one
Build building instructions
@Felix jetzt haben wir leider 3 commits. Falls möglich einmal squashen.
Vielen Dank für die Anpassung des Readmes!
Bitte die Kommentare im Code ansehen.
Außerdem noch eine kleine Anmerkung zur Commit Message:
@ -10,3 +10,2 @@
## Voraussetzungen
* `apt-get install zlib1g-dev lua5.2 build-essential unzip libncurses-dev gawk git subversion realpath libssl-dev` (Sicherlich müssen noch mehr Abhängigkeiten installiert werden, diese Liste wird sich hoffentlich nach und nach füllen. Ein erster Ansatzpunkt sind die Abhängigkeiten von OpenWrt selbst)
* `git clone https://github.com/FreifunkFranken/firmware.git`
* `apt-get install zlib1g-dev lua5.2 build-essential unzip libncurses-dev gawk git subversion manpages-pl libssl-dev` (Sicherlich müssen noch mehr Abhängigkeiten installiert werden, diese Liste wird sich hoffentlich nach und nach füllen. Ein erster Ansatzpunkt sind die Abhängigkeiten von OpenWrt selbst)
Ist manpages-pl tatsächlich zum Bauen den Firmware nötig?
Ja, hat er bei mir als Fehler geworfen gehabt das es "realpath" nichtmehr gibt ist das der ersatz dafür laut Debian apt.
Änderungen der Dependencies gehören meines Erachtens ohnehin in einen separaten Patch. Hat mit den anderen Änderungen nichts zu tun ...
@ -18,6 +18,7 @@ Je nachdem, für welche Hardware die Firmware gebaut werden soll, muss das BSP g
* `./buildscript selectbsp bsp/ath79-generic.bsp`
* Um die vorhandenen BSPs zu sehen, kann `./buildscript selectbsp help` ausgeführt werden.
Sind diese neuen Leerzeilen absicht?
Nein waren versehen, können raus.
@ -31,2 +33,4 @@
Das Buildscript generiert ein dynamisches sed-Script. Dies geschieht, damit die Templates mit den richtigen Werten gefüllt werden können.
## Zweiter Schritt
Hier ist irgendwas mit den Überschriftenleveln kaputt gegangen. Das gehört doch alles noch zu "Verwendung des Buildscripts", oder? Die Überschrift gehört hier glaube ich einfach gar nicht hin.
Jaein ich fand es Persönlich übersichtlicher, aber vermutlich könnte man es weglassen.
@ -34,3 +43,1 @@
* Sourcen werden in einen separaten src-Folder geladen, sofern diese nicht schon da sind. Zu den Sourcen zählen folgende Komponenten:
* OpenWrt
* Sämtliche Packages (ggf. werden Patches angewandt)
* Sourcen werden in einen separaten src-Folder geladen, sofern diese noch schont da sind. Zu den Sourcen zählen folgende Komponenten:
"den Bau"
Auch hier sehe ich den Gewinn der Überschrift nicht (siehe unten), auf jeden Fall passt der Level aber nicht.
Wie hast du es denn hier geschafft, einen Tippfehler ("schont") einzuführen, obwohl der Satz gar nicht verändert wurde?
@ -53,1 +64,4 @@
Updated OpenWrt feed und Prüft auf neuerungen im Git und lädt diese ggf. runter.
### `./buildscript build`
Sollte man am besten immer in einem screen oder ähnliches laufen lassen um einen Abbruch des Builds bei Verbindungsproblemen oder ähnlichem zu verhindern.
Dieser Satz ist ziemlich kaputt. Hier wäre mein Vorschlag:
"Aktualisiert die OpenWrt Feeds, prüft auf Neuerungen im OpenWrt Git und lädt diese gegebenenfalls herunter".
Allerdings ist das gar nicht, was das updatefeeds tut, daher mein Alternativvorschlag:
"Aktualisiert die OpenWrt Feeds, die in die Firmware eingebaut werden. Dabei werden alle Pakete, die für bestimmte Feeds angegeben sind, ins OpenWrt Buildsystem eingebunden bzw. aktualisiert. Dieser Schritt wird bereits von
./buildscript prepapre
übernommen, daher ist dies nur bei manuellen Änderungen der Feeds nötig"@ -64,2 +66,4 @@
* board_postbuild() wird aufgerufen
### `./buildscript config`
Um das Arbeiten mit den OpenWRT .config's zu vereinfachen bietet das Buildscript die Möglichkeit die OpenWRT menuconfig und die OpenWRT kernel_menuconfig aufzurufen. Im Anschluss hat man die Möglichkeit die frisch editierten Configs in das BSP zu übernehmen.
Überschriftenlevel passt nicht, siehe oben.
Ich verstehe auch nicht, was du mit dieser Überschrift sagen willst.
@ -77,2 +85,3 @@
### Erstes Images erzeugen
Du fügst im board_postbuild ein, dass auch die Images für den wr1043v2 kopiert werden:
```
Überschrift passt nicht, siehe oben.
Ich habe jetzt keinen Überblick, aber in den beiden anderen gehighlighteten Stellen sagen wir "man", deshalb sollte man hier dann nicht plötzlich "Du" verwenden. Ggf. kann man das aber auch mal in einer separaten Aktion angleichen.
@ -85,0 +88,4 @@
vim bsp/board_wr1043nd.bsp
board_postbuild() {
cp $target/bin/ar71xx/openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-factory.bin ./bin/
cp $target/bin/ar71xx/openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-sysupgrade.bin ./bin/
"Baut die Firmware für alle vorhandenen BSPs."
Den Kommentar zu screen/tmux hier und oben würde ich weglassen, das hat ja nichts mit unserer Firmware zu tun.
@ -87,3 +98,2 @@
Dann muss auf jeden Fall noch das Netzwerk richtig konfiguriert werden. Dazu muss man den Router sehr gut kennen, i.d.R. lernt man den erst beim Verwenden kennen, daher ist ein guter Startpunkt die Config vom v1 zu kopieren und erstmal zu gucken was passiert.
Wichtig: Zur Laufzeit wird (wenn keine Anpassung in fff-boardname vorgenommen wurde) die Datei `network.$(cat /var/sysinfo/board_name)` geladen. Um den richtigen Dateinamen zu bestimmen kann zunächst ein normales OpenWrt in der gleichen Version auf den Router installiert werden; dort kan man sich dann diese Datei ansehen.
Dann muss auf jeden Fall noch das Netzwerk richtig konfiguriert werden. Dazu muss man den Router sehr gut kennen, i.d.R. lernt man den erst beim Verwenden kennen, daher ist ein guter Startpunkt die Config vom v1 zu kopieren und erstmal zu gucken was passiert:
```
Guter Fund, danke!
@fbl @lemmi @adschm Oben genannte Fehler ausgebessert. Hoffe das passt jetzt so.
Neues Pull-Request #5
das ist nur ein handy Test
Pull request closed