FirmwareEntwicklung: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
Keine Bearbeitungszusammenfassung
K (→‎Erste Schritte: Hinweis zu node vs. layer3 eingefügt.)
(33 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
= Neue Firmware =
= Aktuelle Firmware =
 
== Prerequisites ==
apt-get install zlib1g-dev lua5.2 build-essential unzip libncurses-dev gawk subversion git manpages-pl libssl-dev wget python2


Es wird momentan an einer neuen Firmware gearbeitet: https://github.com/ffff-next/ffff-next


= Aktuelle Firmware =
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


== Prerequisites ==
git clone https://github.com/FreifunkFranken/firmware.git
* apt-get install zlib1g-dev lua5.2 build-essential unzip libncurses-dev gawk subversion git
cd firmware
* 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
* cd firmware


== Erste Schritte ==
== Erste Schritte ==
Zeile 15: Zeile 14:
Mit Hilfe der Community-Files werden Parameter, wie die ESSID, der Kanal sowie z.B. die Netmon-IP gesetzt. Diese Einstellungen sind Community weit einheitlich und müssen i.d.R. nicht geändert werden.
Mit Hilfe der Community-Files werden Parameter, wie die ESSID, der Kanal sowie z.B. die Netmon-IP gesetzt. Diese Einstellungen sind Community weit einheitlich und müssen i.d.R. nicht geändert werden.


* ./buildscript selectcommunity community/franken.cfg
./buildscript selectcommunity community/franken.cfg
 


Je nach dem, für welche Hardware die Firmware gebaut werden soll muss das BSP gewählt werden:
Je nach dem, für welche Hardware die Firmware gebaut werden soll muss das BSP gewählt werden:
* ./buildscript selectbsp bsp/board wr1043nd.bsp
 
* ./buildscript
./buildscript selectbsp bsp/board_ar71xx.bsp
./buildscript selectvariant node
 
Statt node kann hier auch layer3 stehen. Eine Erklärung zu den Unterschieden findet sich [[Firmware_installieren#Die_richtige_Firmware_Variante_ausw.C3.A4hlen|hier]].


= Was ist ein BSP? =
= Was ist ein BSP? =
Zeile 85: Zeile 88:


== Erstes Images erzeugen ==
== Erstes Images erzeugen ==
Du fügst im board_postbuild ein, dass auch die Images für den wr1043v2 kopiert werden:
Du fügst im images array ein, dass auch die Images für den wr1043v2 kopiert werden. Dazu musst du den standard Image Namen von OpenWrt einfügen:
  vim bsp/board_wr1043nd.bsp
  vim bsp/board_ar71xx.bsp
  board_postbuild() {
  images=("openwrt-ar71xx-generic-ubnt-nano-m-squashfs-sysupgrade.bin"
    cp $target/bin/ar71xx/openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-factory.bin ./bin/
        "openwrt-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin"
    cp $target/bin/ar71xx/openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-sysupgrade.bin ./bin/
        "openwrt-ar71xx-generic-tl-wr740n-v4-squashfs-sysupgrade.bin"
    cp $target/bin/ar71xx/openwrt-ar71xx-generic-tl-wr1043nd-v2-squashfs-factory.bin ./bin/
        "openwrt-ar71xx-generic-tl-wr741nd-v2-squashfs-sysupgrade.bin"
    cp $target/bin/ar71xx/openwrt-ar71xx-generic-tl-wr1043nd-v2-squashfs-sysupgrade.bin ./bin/
        "openwrt-ar71xx-generic-tl-wr741nd-v4-squashfs-sysupgrade.bin"
}
        "openwrt-ar71xx-generic-tl-wr841nd-v7-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wr841n-v9-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wr841n-v10-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wr842n-v2-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wr1043nd-v2-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wr1043nd-v3-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wa860re-v1-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-wa850re-v1-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-tl-mr3020-v1-squashfs-sysupgrade.bin"
        "openwrt-ar71xx-generic-ubnt-bullet-m-squashfs-sysupgrade.bin"
        )


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:
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:
  cp bsp/wr1043nd/root_file_system/etc/network.tl-wr1043nd-v1 bsp/wr1043nd/root_file_system/etc/network.tl-wr1043nd-v2
  cp bsp/ar71xx/root_file_system/etc/network.tl-wr1043nd-v1 bsp/ar71xx/root_file_system/etc/network.tl-wr1043nd-v2


Anschließend kann ein erstes Image erzeugt werden:
Anschließend kann ein erstes Image erzeugt werden:
  ./buildscript selectbsp bsp/board_wr1043nd.bsp
  ./buildscript selectbsp bsp/board_ar71xx.bsp
  ./buildscript selectcommunity community/franken.cfg
  ./buildscript selectcommunity community/franken.cfg
./buildscript selectvariant node
   
   
  ./buildscript prepare
  ./buildscript prepare
  ./buildscript build
  ./buildscript build


Jetzt gehst du n Kaffee trinken.
Jetzt gehst du n Kaffee trinken. Während des Bauens (auch während "buildscript build") braucht man übrigens eine Internetverbindung, weil auch während des Bauens Dinge nachgeladen werden.
 
Wenn nach dem Kaffe eine Meldung erscheint, dass alles ausser Deinem Router gebaut werden konnte:
  ./buildscript config
 
Dort dann Deinen Router zusätzlich auswählen und nochmal:
./buildscript prepare
./buildscript build
 
== Image auf ein Test-Gerät installieren ==
 
z.B. mit Hilfe von scp kann man das neu erzeuge Image auf das testgerät kopieren um es dann dort zu installieren:
  scp -6 <FIRMWARE>-sysupgrade.bin root@\[<IPv6LinkLocalDesRouters>%eth1\]:/tmp


== Netzwerkeinstellungen korrekt setzen ==
== Netzwerkeinstellungen korrekt setzen ==
Zeile 130: Zeile 159:
== BSP commiten und Patch erzeugen ==
== BSP commiten und Patch erzeugen ==


Nun kann man mit "git status" die Änderungen sehen. Mit "git add" staged man diese und mit "git commit" checkt man sie ein. "git format-patch origin/HEAD" erzeugt dann aus deinen Commits ein (oder mehr) Patches. Diese schickst du dann mit "git send-email --to franken-dev@freifunk.net *.patch" an unsere Liste. Dort nimmt sich jemand die Zeit und schaut kurz drüber und wenn alles passt finden deine Änderungen in den Hauptentwicklungszweig und sind ab dann Teil der Freifunk-Franken-Firmware.
=== ~/.gitconfig anpassen ===
<pre>
[sendemail]
        email = eigene_Email@adresse.example.com
        name = Vorname Nachname
        smtpserver = smtp.server.der.mail.adresse.example.com
        smtpuser = smtpusername
        smtpencryption = tls
        smtp-server-port = 587
</pre>
 
 
Per Konsolenkommando setzen:
<pre>
git config --global user.name "Max Mustermann"
git config --global user.email eigene_email@adresse.example.com
git config --global sendemail.smtpuser eigene_email@adresse.example.com
git config --global sendemail.smtpserver smtp.example.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.chainreplyto false
git config --global sendemail.smtpencryption tls
</pre>
 
 
Im firmware GIT checkout Verzeichnis:
<pre>
git config sendemail.to franken-dev@freifunk.net
</pre>
 
=== Patch erstellen und senden ===
 
Nun kann man mit "'''git status'''" die Änderungen sehen. Mit "'''git add'''" fügt man die entsprechenden Dateien zu einem commit hinzu und mit "'''git commit --signoff'''" checkt man sie ein (bei Änderungen '''git commit --amend --signoff''' verwenden). "'''git format-patch origin/HEAD'''" erzeugt dann aus deinen Commits ein (oder mehr) Patches. Diese schickst du dann mit "'''git send-email --to franken-dev@freifunk.net FILENAME.patch'''" an unsere Liste. Dort nimmt sich jemand die Zeit und schaut kurz drüber und wenn alles passt finden deine Änderungen in den Hauptentwicklungszweig und sind ab dann Teil der Freifunk-Franken-Firmware.
 
<pre>
# Nur ein Commit/Patch
git send-email origin/master
 
# Mehrere Commits/Patches (mit Cover Letter)
git send-email -n --annotate --cover-letter origin/master
# Die einzelnen Patches werden in VIM mit :xn bzw der letzte mit :x gespeichert


== Patch schicken ==
# 2. Version eines Patches
git send-email -v2 origin/master
</pre>
 
um einen Mantis Bug als gefixt zu markieren in der Commit Message
<pre>
Fixes #1234
</pre>
dazu schreiben.
 
= Weitere Informationen =
Auf der Mailingliste franken-dev@freifunk.net kannst du natürlich jederzeit Fragen stellen, falls etwas nicht klar sein sollte.
Auf der Mailingliste franken-dev@freifunk.net kannst du natürlich jederzeit Fragen stellen, falls etwas nicht klar sein sollte.
== Versionierung ==
Beim Techniktreffen vom [[Protokolle/20160206|06.02.2016]] wurde ein neues Versionierungsschema beschlossen. Am [[Protokolle/20160210|10.02.2016]] wurden noch einige Details geklärt.
=== Begründung ===
Wir haben leider nicht die Men-Power um immer sicherzustellen, dass die Kompatibilität nach einem Release noch oder eben nicht mehr vorhanden ist.
Dadurch ist der Interpretationsspielraum bei regulären Versionsnummern sehr hoch.
Um diesen Spielraum abzuschaffen, steigen wir auf das Datumsschema um.
=== Schema ===
Die Versionsnummer orientiert sich grundsätzlich am Commit-Datum des letzten Commits. Auf diesen Commit wird dann entsprechend das Git-Tag gesetzt.
Daraus ergibt sich folgendes Schema:
Build ohne release Tag: YYYYMMDD-[Anzahl commits seit vorherigem Release]-[Commit-ID]<br>
Alpha: YYYYMMDD-alpha <br>
Beta: YYYYMMDD-beta <br>
Release: YYYYMMDD<br>
=== Sonderfall ===
Für den seltenen Fall, dass es mehrere Tags an einem Tag geben muss, wird der Präfix entsprechend angepasst. Daraus ergibt sich folgendes Schema:
Build ohne release Tag: YYYYMMDD.[1-n]-[Anzahl commits seit vorherigem Release]-[Commit-ID]<br>
Alpha: YYYYMMDD.[1-n]-alpha<br>
Beta: YYYYMMDD.[1-n]-beta <br>
Release: YYYYMMDD.[1-n] <br>
=== Beispiele ===
Folgendes Beispiel geht davon aus, dass es eine Alpha und eine Beta Version auf dem selben Commit gegeben hat.
In der Beta wurde am selben Tag ein massives Problem festgestellt, deshalb gab es eine neue Beta. Diese basiert auf einem neueren Commit und wird später auch so released.
20160130-alpha<br>
20160130-beta<br>
20160130.1-beta<br>
20160130.1<br>
Das nächste Beispiel geht davon aus, dass es auf dem selben Commit eine Alpha, Beta und Stable gibt:
20160130-alpha<br>
20160130-beta<br>
20160130<br>
== Patchwork ==
https://pw.freifunk-franken.de
=== Patch aus dem Patchwork ins eigene Git laden ===
<pre>
curl -s https://pw.freifunk-franken.de/patch/797/mbox/ | git am -
</pre>
Die Zahl in der URL durch die Patchnummer ersetzen aus dem Patchwork
== Mantis ==
https://mantis.freifunk-franken.de


[[Kategorie:Technik]]
[[Kategorie:Technik]]

Version vom 30. Dezember 2020, 11:51 Uhr

Aktuelle Firmware

Prerequisites

apt-get install zlib1g-dev lua5.2 build-essential unzip libncurses-dev gawk subversion git manpages-pl libssl-dev wget python2


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
cd firmware

Erste Schritte

Mit Hilfe der Community-Files werden Parameter, wie die ESSID, der Kanal sowie z.B. die Netmon-IP gesetzt. Diese Einstellungen sind Community weit einheitlich und müssen i.d.R. nicht geändert werden.

./buildscript selectcommunity community/franken.cfg


Je nach dem, für welche Hardware die Firmware gebaut werden soll muss das BSP gewählt werden:

./buildscript selectbsp bsp/board_ar71xx.bsp
./buildscript selectvariant node

Statt node kann hier auch layer3 stehen. Eine Erklärung zu den Unterschieden findet sich hier.

Was ist ein BSP?

Ein BSP (Board-Support-Package) beschreibt, was zu tun ist, damit ein Firmware Image für eine spezielle Hardware gebaut werden kann.

Typischerweise ist eine folgene Ordner-Struktur vorhanden:

  • .config
  • root_file_system/
    • etc/
      • rc.local.board
      • config/
        • board
        • network
        • system
      • crontabs/
        • root

Die Daten des BSP werden nie alleine verwendet. Zu erst werden immer die Daten aus dem "default"-BSP zum Ziel kopiert, erst danach werden die Daten des eigentlichen BSPs dazu kopiert. Durch diesen Effekt kann ein BSP die "default" Daten überschreiben.

Der Verwendung des Buildscripts

  • Das BSP file durch das Buildscript automatisch als dot-Script geladen, somit stehen dort alle Funktionen zur Verfügung.
  • Das Buildscript lädt ebenfalls automatisch das Community file und generiert ein dynamisches sed-Script, dies geschieht, damit die Templates mit den richtigen Werten gefüllt werden können.

./buildscript prepare

  • Sourcen werden in einen separaten src-Folder geladen, sofern diese noch schont da sind. Zu den Sourcen zählen folgende Komponenten:
    • OpenWRT
    • Sämtliche Packages (ggfs werden Patches angewandt)
  • Ein ggfs altes Target wird gelöscht
  • OpenWRT wird ins Target exportiert (kopiert)
  • Eine OpenWRT Feed-Config wird mit dem lokalen Source Verzeichnis als Quelle angelegt
  • Die Feeds werden geladen
  • Spezielle Auswahl an Paketen wird geladen
  • Patches werden angewandt
  • board_prepare() aus dem BSP wird aufgerufen (wird. z.B. fur Patches für eine bestimmte HW verwendet)

./buildscript build

  • prebuild
    • $target/files aufräumen
      • (In $target/files liegen Dateien, die später direkt im Ziel-Image landen)
    • Files aus default-bsp und bsp kopieren
    • OpenWRT- und Kernel-Config kopieren
    • board_prebuild() aus dem BSP wird aufgerufen
  • Templates transformieren
  • GIT Versionen speichern: $target/files/etc/firmware_release
  • OpenWRT: make
  • postbuild
    • 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.

  • prebuild
  • OpenWRT: make menuconfig ; make kernel_menuconfig
  • Speichern, y/n?
  • Config-Format vereinfachen
  • Config ins BSP zurück speichern

Erweiterung eines BSPs

Beispielhaftes Vorgehen um den WR1043V2 zu unterstützen.

Repository auschecken

git clone https://github.com/FreifunkFranken/firmware.git
cd firmware

Erstes Images erzeugen

Du fügst im images array ein, dass auch die Images für den wr1043v2 kopiert werden. Dazu musst du den standard Image Namen von OpenWrt einfügen:

vim bsp/board_ar71xx.bsp
images=("openwrt-ar71xx-generic-ubnt-nano-m-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr740n-v4-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr741nd-v2-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr741nd-v4-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr841nd-v7-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr841n-v9-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr841n-v10-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr842n-v2-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr1043nd-v2-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wr1043nd-v3-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wa860re-v1-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-wa850re-v1-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-tl-mr3020-v1-squashfs-sysupgrade.bin"
       "openwrt-ar71xx-generic-ubnt-bullet-m-squashfs-sysupgrade.bin"
       )

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:

cp bsp/ar71xx/root_file_system/etc/network.tl-wr1043nd-v1 bsp/ar71xx/root_file_system/etc/network.tl-wr1043nd-v2

Anschließend kann ein erstes Image erzeugt werden:

./buildscript selectbsp bsp/board_ar71xx.bsp
./buildscript selectcommunity community/franken.cfg
./buildscript selectvariant node

./buildscript prepare
./buildscript build

Jetzt gehst du n Kaffee trinken. Während des Bauens (auch während "buildscript build") braucht man übrigens eine Internetverbindung, weil auch während des Bauens Dinge nachgeladen werden.

Wenn nach dem Kaffe eine Meldung erscheint, dass alles ausser Deinem Router gebaut werden konnte:

 ./buildscript config

Dort dann Deinen Router zusätzlich auswählen und nochmal:

./buildscript prepare
./buildscript build

Image auf ein Test-Gerät installieren

z.B. mit Hilfe von scp kann man das neu erzeuge Image auf das testgerät kopieren um es dann dort zu installieren:

 scp -6 <FIRMWARE>-sysupgrade.bin root@\[<IPv6LinkLocalDesRouters>%eth1\]:/tmp

Netzwerkeinstellungen korrekt setzen

Am Ende sollte im bin/ Verzeichnis das Image für v1 und v2 liegen. Das v2 Image wird auf den Router geflasht. Achtung: Eventuell ist das Netzwerk jetzt so falsch eingestellt, dass man nicht mehr über Netzwerk auf den Router zugreifen kann. Am einfachsten ist es den Router dann über eine serielle Konsole zu verwenden. Theoretisch kann man an den unterschiedlichen LAN-Ports mit der IPv6 Link-Local aus der MAC Adresse des Geräts versuchen drauf zu kommen. Es kann auch sein, dass die IPv6 +/- 1 am Ende hat. Letztlich kann das funktionieren, ist aber aufwändig und da am LAN Einstellungen verändert werden sollen, ist die serielle Konsole das Mittel der Wahl!

Wenn man dann auf dem Router drauf ist, muss als erstes festgestellt werden, welches Ethernet-Device für den WAN Port zuständig ist. Mir sind da folgende Möglichkeiten bekannt. a) WAN ist eth0, b) WAN ist eth1, c) WAN ist teil vom Switch eth0. Dementsprechend wird das WANDEV auf dem Router in der /etc/network.tl-wr1043nd-v2 konfiguriert. Wenn WAN ein eigenes ethX hat, dann muss WAN_PORTS="" sein. Dann muss eingestellt werden welches Ethernet-Device an dem internen Switch angeschlossen ist (swconfig list). Dieses wird als SWITCHDEV konfiguriert. Ich glaub CLIENTIF musst nicht angepasst werden. Aber es muss noch eingestellt werden, welches Ethernet oder Wifi Device die MAC Adresse hat, die auch unter dem Gerät steht. Dieses Device wird als ROUTERMAC eingetragen. Nun ist es an der Zeit die Einstellungen zu testen, dafür muss die falsche Netzwerk-Config zurück gesetzt werden:

cp /rom/etc/config/network /etc/config/network
reboot

Switch konfigurieren

Wenn der Router wieder hochgefahren ist, sollten die Einstellungen sein, so wie sie konfiguriert wurden. Ggfs muss man hier noch mal eine Runde drehen, wenn etwas nicht richtig war. Ansonsten ist es jetzt an der Zeit den Switch einzustellen. Das geht am einfachsten, wenn man die Einstellungen nun direkt in der /etc/config/network vornimmt. Dabei ist eth0_2 der WAN Port (sofern er über den Switch läuft). eth0_1 sind die Client-Ports und eth0_3 sind die Ports um Batman Knoten zu verbinden. Am Anfang weiß man meist noch nicht welcher Switch Port wirklich am Router wo rausgeführt ist. Manchmal kann es helfen einen Port nach dem anderen aktiv zu schalten (Rechner anstecken) und die Ausgabe von swconfig anzugucken (z.B. swconfig dev switch0 show). Das ganze ist manchmal ein wenig try-and-error. :( Aber wenn man denkt es passt, prüft man alles durch. Tauchen BATMAN Nachbarn in "batctl o" auf und aktualisiert sich die Anzeige, wenn ein anderer Knoten an dem Batman-Port angeschlossen wird? Funktioniert das mit beiden Ports? Taucht ein PC in "/etc/showmacs.sh br-mesh" auf, den man an die Client-Ports angeschlossen hat? Wenn am Ende alles passt, übernimmt man die Switch-Config in die /etc/network.tl-wr1043nd-v2 und probiert das ganze nochmal aus:

cp /rom/etc/config/network /etc/config/network
reboot

Einstellungen testen und ins BSP übernehmen

Wenn jetzt die Ports immer noch alle korrekt funktionieren kann man die datei auf den eigenen PC kopieren:

scp root@[ipv6ll%scope]:/etc/network.tl-wr1043nd-v2 /path/to/git/firmware/bsp/wr1043nd/root_file_system/etc/network.tl-wr1043nd-v2

BSP commiten und Patch erzeugen

~/.gitconfig anpassen

[sendemail]
        email = eigene_Email@adresse.example.com
        name = Vorname Nachname
        smtpserver = smtp.server.der.mail.adresse.example.com
        smtpuser = smtpusername
        smtpencryption = tls
        smtp-server-port = 587


Per Konsolenkommando setzen:

git config --global user.name "Max Mustermann"
git config --global user.email eigene_email@adresse.example.com
git config --global sendemail.smtpuser eigene_email@adresse.example.com
git config --global sendemail.smtpserver smtp.example.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.chainreplyto false
git config --global sendemail.smtpencryption tls


Im firmware GIT checkout Verzeichnis:

git config sendemail.to franken-dev@freifunk.net

Patch erstellen und senden

Nun kann man mit "git status" die Änderungen sehen. Mit "git add" fügt man die entsprechenden Dateien zu einem commit hinzu und mit "git commit --signoff" checkt man sie ein (bei Änderungen git commit --amend --signoff verwenden). "git format-patch origin/HEAD" erzeugt dann aus deinen Commits ein (oder mehr) Patches. Diese schickst du dann mit "git send-email --to franken-dev@freifunk.net FILENAME.patch" an unsere Liste. Dort nimmt sich jemand die Zeit und schaut kurz drüber und wenn alles passt finden deine Änderungen in den Hauptentwicklungszweig und sind ab dann Teil der Freifunk-Franken-Firmware.

# Nur ein Commit/Patch
git send-email origin/master

# Mehrere Commits/Patches (mit Cover Letter)
git send-email -n --annotate --cover-letter origin/master
# Die einzelnen Patches werden in VIM mit :xn bzw der letzte mit :x gespeichert

# 2. Version eines Patches
git send-email -v2 origin/master

um einen Mantis Bug als gefixt zu markieren in der Commit Message

Fixes #1234

dazu schreiben.

Weitere Informationen

Auf der Mailingliste franken-dev@freifunk.net kannst du natürlich jederzeit Fragen stellen, falls etwas nicht klar sein sollte.

Versionierung

Beim Techniktreffen vom 06.02.2016 wurde ein neues Versionierungsschema beschlossen. Am 10.02.2016 wurden noch einige Details geklärt.

Begründung

Wir haben leider nicht die Men-Power um immer sicherzustellen, dass die Kompatibilität nach einem Release noch oder eben nicht mehr vorhanden ist. Dadurch ist der Interpretationsspielraum bei regulären Versionsnummern sehr hoch. Um diesen Spielraum abzuschaffen, steigen wir auf das Datumsschema um.

Schema

Die Versionsnummer orientiert sich grundsätzlich am Commit-Datum des letzten Commits. Auf diesen Commit wird dann entsprechend das Git-Tag gesetzt. Daraus ergibt sich folgendes Schema:

Build ohne release Tag: YYYYMMDD-[Anzahl commits seit vorherigem Release]-[Commit-ID]
Alpha: YYYYMMDD-alpha
Beta: YYYYMMDD-beta
Release: YYYYMMDD

Sonderfall

Für den seltenen Fall, dass es mehrere Tags an einem Tag geben muss, wird der Präfix entsprechend angepasst. Daraus ergibt sich folgendes Schema:

Build ohne release Tag: YYYYMMDD.[1-n]-[Anzahl commits seit vorherigem Release]-[Commit-ID]
Alpha: YYYYMMDD.[1-n]-alpha
Beta: YYYYMMDD.[1-n]-beta
Release: YYYYMMDD.[1-n]

Beispiele

Folgendes Beispiel geht davon aus, dass es eine Alpha und eine Beta Version auf dem selben Commit gegeben hat. In der Beta wurde am selben Tag ein massives Problem festgestellt, deshalb gab es eine neue Beta. Diese basiert auf einem neueren Commit und wird später auch so released.

20160130-alpha
20160130-beta
20160130.1-beta
20160130.1

Das nächste Beispiel geht davon aus, dass es auf dem selben Commit eine Alpha, Beta und Stable gibt:

20160130-alpha
20160130-beta
20160130


Patchwork

https://pw.freifunk-franken.de

Patch aus dem Patchwork ins eigene Git laden

curl -s https://pw.freifunk-franken.de/patch/797/mbox/ | git am -

Die Zahl in der URL durch die Patchnummer ersetzen aus dem Patchwork

Mantis

https://mantis.freifunk-franken.de