Wie funktioniert Gluons site/patches?

wusel · 18. Januar 2023 um 15:47

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 · 18. Januar 2023 um 16:39

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 · 18. Januar 2023 um 22:36

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 · 18. Januar 2023 um 23:52

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: Site Config of FFAC sagt auch nicht, wie seine Dateien patches/ im Build beachtet werden.

Wobei: site-ffm/scripts/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 · 19. Januar 2023 um 21:28

Der Kern des ganzen liegt hier in der Makefile:

github.com

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


      
          GLUON_BUILD_DIR := gluon-build
          GLUON_GIT_URL := https://github.com/freifunk-gluon/gluon.git
          GLUON_GIT_REF := v2023.1.2
          
          PATCH_DIR := ./patches
          SECRET_KEY_FILE ?= ${HOME}/.gluon-secret-key
          
          GLUON_TARGETS ?= $(shell cat targets | tr '\n' ' ')
          GLUON_AUTOUPDATER_BRANCH := stable
          
          ifneq (,$(shell git describe --exact-match --tags 2>/dev/null))
          	GLUON_AUTOUPDATER_ENABLED := 1
          	GLUON_RELEASE := $(shell git describe --tags 2>/dev/null)
          else
          	GLUON_AUTOUPDATER_ENABLED := 0
          	EXP_FALLBACK = $(shell date '+%Y%m%d')
          	BUILD_NUMBER ?= $(EXP_FALLBACK)
          	GLUON_RELEASE := $(shell git describe --tags)~exp$(BUILD_NUMBER)
          endif
          
          JOBS ?= $(shell cat /proc/cpuinfo | grep processor | wc -l)
          
          GLUON_MAKE := ${MAKE} -j ${JOBS} -C ${GLUON_BUILD_DIR} \
          	GLUON_RELEASE=${GLUON_RELEASE} \
          	GLUON_AUTOUPDATER_BRANCH=${GLUON_AUTOUPDATER_BRANCH} \
          	GLUON_AUTOUPDATER_ENABLED=${GLUON_AUTOUPDATER_ENABLED}
          
          all: info
          	${MAKE} manifest
          
          info:
          	@echo
          	@echo '#########################'
          	@echo '# FFMUC Firmware build'
          	@echo '# Building release ${GLUON_RELEASE} for branch ${GLUON_AUTOUPDATER_BRANCH}'
          	@echo
          
          build: gluon-prepare output-clean
          ifeq ($(origin GLUON_DEVICES), undefined)
          	for target in ${GLUON_TARGETS}; do \
          		echo ""Building target $$target""; \
          		${GLUON_MAKE} download all GLUON_TARGET="$$target"; \
          	done
          else # only run for specific gluon devices (works only for a single GLUON_TARGET)
          	echo ""Building target ${GLUON_TARGETS} for devices ${GLUON_DEVICES}""; \
          	${GLUON_MAKE} download all GLUON_DEVICES="${GLUON_DEVICES}" GLUON_TARGET="${GLUON_TARGETS}"
          endif
          
          manifest: build
          	for branch in next experimental testing stable; do \
          		${GLUON_MAKE} manifest GLUON_AUTOUPDATER_BRANCH=$$branch;\
          	done
          	mv -f ${GLUON_BUILD_DIR}/output/* ./output/
          
          sign: manifest
          	${GLUON_BUILD_DIR}/contrib/sign.sh ${SECRET_KEY_FILE} output/images/sysupgrade/${GLUON_AUTOUPDATER_BRANCH}.manifest
          
          ${GLUON_BUILD_DIR}:
          	mkdir -p ${GLUON_BUILD_DIR}
          
          # Note: "|" means "order only", e.g. "do not care about folder timestamps"
          # 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}
          
          output-clean:
          	mkdir -p output/
          	rm -rf output/*
          
          clean: gluon-clean output-clean

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

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

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":"[^"]*"},//'
diff --git a/package/gluon-status-page/luasrc/lib/gluon/status-page/controller/status-page.lua b/package/gluon-status-page/luasrc/lib/gluon/status-page/controller/status-page.lua
index 80c5e50a..55fbb86b 100644
--- a/package/gluon-status-page/luasrc/lib/gluon/status-page/controller/status-page.lua
+++ b/package/gluon-status-page/luasrc/lib/gluon/status-page/controller/status-page.lua
@@ -61,7 +61,7 @@ local function match(a, b, n)
 end
 
 entry({}, call(function(http, renderer)
-	local nodeinfo = json.parse(util.exec('exec gluon-neighbour-info -d ::1 -p 1001 -t 3 -c 1 -r nodeinfo'))
+	local nodeinfo = json.parse(util.exec('exec gluon-neighbour-info -d ::1 -p 1001 -t 3 -c 1 -r nodeinfo | sed \'s/"owner":{"contact":"[^"]*"},//\''))

Diese Datei wurde abgeschnitten. Original zeigen

wusel · 4. Februar 2023 um 02:43

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 · 4. Februar 2023 um 08:45

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 · 4. Februar 2023 um 12:48

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.