Wie funktioniert Gluons site/patches?

Moin,

ich sehe ich verschiedenen site-Repos von Communities einen Ordner patches, und darin Patches gegen den Gluon-Tree. Das wäre ja eine nette Möglichkeit, vom forken des Gluon-Projekts, um das Statusseiten-CSS zu ändern, wegzukommen. Nur: wie funktioniert das?

Soweit ich in v2019/v2021 sehen kann, guckt make update bzw. das davon aufgerufene scripts/patch.sh nicht nach site/patches, und ein testweise angelegter Patch in meinem site/patches-Verzeichnis wird auch augenscheinlich nicht angewendet?

In der Dokumentation habe ich dazu ebenfalls nichts gefunden — so, what’s the trick?

Danke,
-kai

Gluon selbst unterstützt das nicht, da die Patches nur transitiv mit Gluon in verbindung stehen.

Vermutlich wenden die Communities die Patches mittels eigener Buildskripte automatisiert aus dem Site Repo an, so habe ich das zumindest schon häufiger gesehen.

1 „Gefällt mir“

wäre für mich vielleicht auch langfristig einfacher als wie wusel einen CSS/JS-Patch dauerhaft im fork zu pflegen :smiley:
@wusel hast du schon ein Buildscript gefunden, an dem man sich orientieren kann ohne das Rad neu zu erfinden?

Nee, das ist es ja, weshalb ich fragte :wink:

GitHub - Freifunk-Rhein-Neckar/site-ffrn: Gluon site configuration of the FFRN nutzt es nicht meh und baut seit Admin-Wechsel plain Gluon (:wave: gen @TomH)
GitHub - Freifunk-Nord/nord-site: Gluon site directory schreibt nur „make update“ im README.md — was heute der Stein meines Post war, weil … bei mir reichte das nicht :wink:
GitHub - freifunktrier/site-fftr verzichtet auf ein README.md, hat aber auch patches …
GitHub - ffac/site: Site Config of FFAC sagt auch nicht, wie seine Dateien patches/ im Build beachtet werden.

Wobei: https://github.com/freifunkMUC/site-ffm/blob/stable/scripts/apply_patches.sh scheint ein Kandidat zu sein? Wobei mir noch fehlt, wann und wie ich das in mein Build-Skript vor, oder nach?, make update einbinden muß?

Der Kern des ganzen liegt hier in der Makefile:

die Site-Patches werden vor dem gluon make update eingesetzt.

Das Münchener Makefile ist auch sehr schön und spannend.
Dort wird Gluon in die Site geklont und die site wiederum rein verlinkt.

Somit muss man ledigich make build in der site config ausführen und die Patches werden angewendet.
Dabei kann man auch openwrt patches hinzufügen, indem man ein Patch erzeugt, welcher eine Datei im gluon patches/openwrt ordner anlegt:

in FFAC gab es mal die Anpassung, dass die Statuspage auch keine Kontakt-Info anzeigt (sondern nur Admins und fundige Leute diese sehen können, was bei uns für eine sehr hohe Kontaktaddressenbereitschaft geführt hat).
Dazu nutzen wir nun auch kein custom ffac-status-page paket mehr sondern lediglich einen Patch:

2 „Gefällt mir“

Got it, thanks! Schon recht nice; allerdings wiped jeder Build auch die Toolchain, sodaß ich auf einem AMD Ryzen™ 5 3600 dennoch bei gut 300 Minuten/Build lande. Ein Rebuild geänderter Pakete dauerte in der alten Variante bei v2021.1 auf dem gleichen Blech »nur« gut 60 Minuten …

1 „Gefällt mir“

Kannst du herausfinden wann das passiert?

In der Makefile gibt es auch make clean welches die toolchain weg wirft
Das sollte aber normal nicht aufgerufen werden - wenn man das nicht explizit macht?

Lediglich der output ordner mit den gebauten binaries wird weg geworfen im make build

Sollte also ab dem zweiten bauen auch genauso schnell sein wie direkt mit make build im gluon verzeichnis - wird da ja auch nur aufgerufen

Viele Grüße

Ja, Layer-8-Problem: Das steuernde Shellskript (Berechung der Core-Anzahl für den Build, Mailversand und andere Fancyness) hatte noch das alte Verhalten drin: if [ -e site ] ; then rm -rf site; fi ; git clone ${site-repo} site || exit 1. Da nun aber alles inner- bzw. unterhalb site, in gluon-build, stattfindet, war das … marginal suboptimal.