# Wie funktioniert Gluons site/patches? **URL:** \ **Category:** Gluon\ **Created:** [18. Januar 2023 um 15:47 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643 "2023-01-18T15:47:28Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [18. Januar 2023 um 15:47 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643/1 "2023-01-18T15:47:28Z")
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 ---
**Author:** ![blocktrron](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/b/c6cbf5/32.png) [@blocktrron](https://forum.freifunk.net/u/blocktrron)\ **Post date:** [18. Januar 2023 um 16:39 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643/2 "2023-01-18T16:39:56Z")
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. ---
**Author:** ![rotanid](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/r/3ec8ea/32.png) [@rotanid](https://forum.freifunk.net/u/rotanid)\ **Post date:** [18. Januar 2023 um 22:36 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643/3 "2023-01-18T22:36:37Z")
wäre für mich vielleicht auch langfristig einfacher als wie wusel einen CSS/JS-Patch dauerhaft im fork zu pflegen 😃 @wusel hast du schon ein Buildscript gefunden, an dem man sich orientieren kann ohne das Rad neu zu erfinden? ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [18. Januar 2023 um 23:52 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643/4 "2023-01-18T23:52:06Z")
> [@rotanid](#): > > @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 😉 [GitHub - Freifunk-Rhein-Neckar/site-ffrn: Gluon site configuration of the FFRN](https://github.com/Freifunk-Rhein-Neckar/site-ffrn) nutzt es nicht meh und baut seit Admin-Wechsel plain Gluon (👋 gen @TomH) [GitHub - Freifunk-Nord/nord-site: Gluon site directory](https://github.com/Freifunk-Nord/nord-site) schreibt nur „make update“ im README.md — was heute der Stein meines Post war, weil … bei mir reichte das nicht 😉 [GitHub - freifunktrier/site-fftr](https://github.com/freifunktrier/site-fftr) verzichtet auf ein README.md, hat aber auch patches … [GitHub - ffac/site: Site Config of FFAC](https://github.com/ffac/site/) sagt auch nicht, wie seine Dateien patches/ im Build beachtet werden. Wobei: [site-ffm/scripts/apply\_patches.sh at stable · freifunkMUC/site-ffm · GitHub](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ß? ---
**Author:** ![fmaurer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/f/439d5e/32.png) [@fmaurer](https://forum.freifunk.net/u/fmaurer)\ **Post date:** [19. Januar 2023 um 21:28 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643/5 "2023-01-19T21:28:10Z")
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: [https://github.com/freifunkMUC/site-ffm/blob/stable/patches/0004-vxlan-fix-performance-issues.patch](https://github.com/freifunkMUC/site-ffm/blob/stable/patches/0004-vxlan-fix-performance-issues.patch) 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: > ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [4. Februar 2023 um 02:43 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643/6 "2023-02-04T02:43:01Z")
> [@fmaurer](#): > > Somit muss man ledigich `make build` in der site config ausführen und die Patches werden angewendet. 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 … ---
**Author:** ![fmaurer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/f/439d5e/32.png) [@fmaurer](https://forum.freifunk.net/u/fmaurer)\ **Post date:** [4. Februar 2023 um 08:45 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643/7 "2023-02-04T08:45:26Z")
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 ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [4. Februar 2023 um 12:48 UTC](https://forum.freifunk.net/t/wie-funktioniert-gluons-site-patches/23643/8 "2023-02-04T12:48:49Z")
> [@fmaurer](#): > > Kannst du herausfinden wann das passiert? 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.