Wie funktioniert Gluons site/patches?

wusel · January 18, 2023, 3:47pm

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

blocktrron · January 18, 2023, 4:39pm

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.

rotanid · January 18, 2023, 10:36pm

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?

wusel · January 18, 2023, 11:52pm

Nee, das ist es ja, weshalb ich fragte

GitHub - Freifunk-Rhein-Neckar/site-ffrn: Gluon site configuration of the FFRN nutzt es nicht meh und baut seit Admin-Wechsel plain Gluon ( 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
GitHub - freifunktrier/site-fftr verzichtet auf ein README.md, hat aber auch patches …
GitHub - ffac/site sagt auch nicht, wie seine Dateien patches/ im Build beachtet werden.

Wobei: site-ffm/apply_patches.sh at stable · freifunkMUC/site-ffm · GitHub 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ß?

fmaurer · January 19, 2023, 9:28pm

Der Kern des ganzen liegt hier in der Makefile:

github.com

freifunkMUC/site-ffm/blob/stable/Makefile#L91


      
          # https://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Prerequisite-Types.html
          ${GLUON_BUILD_DIR}/.git: | ${GLUON_BUILD_DIR}
          	git init ${GLUON_BUILD_DIR}
          	cd ${GLUON_BUILD_DIR} && git remote add origin ${GLUON_GIT_URL}
          
          
gluon-update: | ${GLUON_BUILD_DIR}/.git
          	cd ${GLUON_BUILD_DIR} && git fetch --tags origin ${GLUON_GIT_REF}
          	cd ${GLUON_BUILD_DIR} && git reset --hard FETCH_HEAD
          	cd ${GLUON_BUILD_DIR} && git clean -fd
          
          
gluon-prepare: gluon-update
          	make gluon-patch
          	ln -sfT .. ${GLUON_BUILD_DIR}/site
          	${GLUON_MAKE} update
          
          
gluon-patch:
          	scripts/apply_patches.sh ${GLUON_BUILD_DIR} ${PATCH_DIR}
          
          
gluon-clean:
          	rm -rf ${GLUON_BUILD_DIR}

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:

github.com

freifunkMUC/site-ffm/blob/stable/patches/0004-vxlan-fix-performance-issues.patch

From 486d735cb74f3c66ba08747de2b1cefc7e63b8d9 Mon Sep 17 00:00:00 2001
From: CodeFetch <me@bibbl.com>
Date: Tue, 22 Dec 2020 04:44:39 +0100
Subject: [PATCH 1/1] vxlan: fix performance issues

This commit includes the patches for fixing issue #2155.
---
 ...ance-issues-with-VXLAN-encapsulation.patch | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 patches/openwrt/9010-kernel-fix-performance-issues-with-VXLAN-encapsulation.patch

diff --git a/patches/openwrt/9010-kernel-fix-performance-issues-with-VXLAN-encapsulation.patch b/patches/openwrt/9010-kernel-fix-performance-issues-with-VXLAN-encapsulation.patch
new file mode 100644
index 00000000..14b4cc78
--- /dev/null
+++ b/patches/openwrt/9010-kernel-fix-performance-issues-with-VXLAN-encapsulation.patch
@@ -0,0 +1,80 @@
+From: CodeFetch <me@bibbl.com>
+Date: Tue, 22 Dec 2020 04:35:17 +0100
+Subject: kernel: fix performance issues with VXLAN encapsulation

This file has been truncated. show original

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:

github.com

ffac/site/blob/v2022.1.x/patches/status-page-anonymization.patch

From 62c19102406a12ad613cb813acbbce0f4641404f Mon Sep 17 00:00:00 2001
From: Jan Niehusmann <jan@gondor.com>
Date: Sun, 3 Mar 2019 23:36:57 +0100
Subject: [PATCH] remove owner information from status page

---
 .../lib/gluon/status-page/www/cgi-bin/dyn/neighbours-nodeinfo   | 2 +-
 .../luasrc/lib/gluon/status-page/controller/status-page.lua     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/gluon-status-page/files/lib/gluon/status-page/www/cgi-bin/dyn/neighbours-nodeinfo b/package/gluon-status-page/files/lib/gluon/status-page/www/cgi-bin/dyn/neighbours-nodeinfo
index 3f149100..3f3ce8c0 100755
--- a/package/gluon-status-page/files/lib/gluon/status-page/www/cgi-bin/dyn/neighbours-nodeinfo
+++ b/package/gluon-status-page/files/lib/gluon/status-page/www/cgi-bin/dyn/neighbours-nodeinfo
@@ -8,4 +8,4 @@ badrequest() {
 
 ( gluon-list-mesh-interfaces | grep -qxF "$QUERY_STRING" ) 2>/dev/null || badrequest
 
-exec gluon-neighbour-info -s neighbour -i "$QUERY_STRING" -d ff02::2:1001 -p 1001 -r nodeinfo
+exec gluon-neighbour-info -s neighbour -i "$QUERY_STRING" -d ff02::2:1001 -p 1001 -r nodeinfo | sed 's/"owner":{"contact":"[^"]*"},//'

This file has been truncated. show original

wusel · February 4, 2023, 2:43am

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 …

fmaurer · February 4, 2023, 8:45am

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

wusel · February 4, 2023, 12:48pm

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.