[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

antonvm

Mitglied
Mitglied seit
10 Jan 2016
Beiträge
316
Punkte für Reaktionen
3
Punkte
18
So werden reproduzierbare, nachhaltige Projekte, hier jetzt Freetz aufgestellt.

Die anderen Forks, soweit sie es noch nicht haben, sollten auch darüber nachdenken.

Danke

MfG
antonvm
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,646
Punkte für Reaktionen
1,209
Punkte
113
Beim Aufräumen auf lokalen Rechnern sind mir einige ältere Änderungen noch untergekommen, die sich mit "run_modscripts" und der Auswertung von Return-Codes beim "postcheck"-Schritt befassen:


- ein "precheck" halte ich immer noch nicht für notwendig ... die Lösung, das Verzeichnis mit den entsprechenden "modscripts" angeben zu können beim Aufruf (darin können sich ja auch nur die Symlinks auf die "echten" Skript-Dateien befinden), erleichtert einem auch das Zusammenstellen unterschiedlicher Modifikationen für jedes Modell und jede Firmware-Version; ja, man könnte sogar pro Gerät einen eigenen Ordner dafür verwenden, wenn man das wollte.

Da auch bisher keine zusätzlichen Verzeichnisse durchsucht wurden, wie das in "modfs" beim "contrib"-Verzeichnis der Fall war, sollte das jetzt auch nicht notwendig werden und wenn man tatsächlich die Modifikationen für einzelne Geräte/Modelle in getrennten Verzeichnissen verwaltet (die Dateien hinter den Symlinks kann man ja trotzdem aktualisieren lassen, falls doch mal eines der Skripte geändert wurde), kann man da auch gleich alle Files (inkl. irgendwelcher aus "custom" oder "contrib" oder ähnlichem) verlinken - nur muß man beim Schreiben eigener Modifikationen, die sich auf mehr als eine Datei in unterschiedlichen Ordnern verteilen (mein Boot-Manager wäre so ein Beispiel), dann ein wenig aufpassen, wenn man mit Pfaden hantiert.

Gestartet werden die Skript-Dateien immer aus dem Verzeichnis heraus, in das man "run_modscripts" (und den Rest der Dateien) entpackt hat - zumindest wenn man meinen Empfehlungen zum Aufruf folgt. Alle weiteren Pfadangaben sollten also immer relativ dazu erfolgen und am besten noch mit "readlink -f" in die absoluten Pfade übersetzt werden (wenn man neue Skripte schreibt zumindest). Und um da ganz sicher zu gehen, daß es so etwas wie ein "Stammverzeichnis" für die entpackten "modfs"-Dateien gibt, wird jetzt eine Umgebungsvariable "MODFS_DIR" mit an die aufgerufenen Skript-Dateien übergeben, die auf den Wert des aktuellen Verzeichnisses (CWD - current working directory) beim Aufruf von "modfs" (und auch von "run_modscripts") gesetzt wird. Braucht ein Skript zum Modifizieren weitere Dateien (die sollten ja nicht im "modscripts"-Ordner liegen), kann es diesen Wert benutzen, um die zu lokalisieren, wenn sie unterhalb des "modfs"-Verzeichnisses (dessen Namen ja jeder Benutzer frei wählen kann, daher geht das nur mit relativen Pfaden) liegen.

Weitere Folge: neuer Timestamp, neues Archiv auf yourfritz.de

Ich habe die letzten Änderungen auch nicht direkt durch den Aufruf von "modfs" getestet (ich hoffe trotzdem, daß sich da keine Probleme ergeben, weil die Änderungen an diesen Dateien dann doch eher gering waren, im Gegensatz zum "run_modscripts"), sondern dafür das folgende Skript verwendet, was eine etwas erweiterte Form der Statements ist, die ich in diesem Thread: https://www.ip-phone-forum.de/threa...h-meine-eigene-dann-auf-der-fritz-box.307161/ mal zum Besten gegeben habe.

Diese Version kann einfach mit dem Modellnamen und der Versionsnummer der AVM-Firmware aufgerufen werden (für Release-Versionen und solange die URL bei AVM dann denselben, einfachen Regeln folgt wie im Skript - Standard wäre, wie ersichtlich, 7590 und 07.21), paßt sich beim Benutzernamen automatisch an den verwendeten Account an (alles nur als "root" zu machen, ist mir zu unsicher - ein "sudo" wird bei mir nur da genutzt, wo es sein muß und so werden z.B. auch die "modscripts" nicht als "root" abgearbeitet), detektiert die passende Version (byte order) für das Entpacken und Packen selbst und verwendet die "postcheck"-Aufrufe samt Auswertung der Return-Codes.

Bash:
# /bin/sh
set -x
MODEL=${1:-7590}
VERSION=${2:-07.21}
MYDIR="${TMPDIR:-/tmp}/$(id | sed -n -e "s|uid=[0-9]*(\([^)]*\)).*|\1|p" | sed -e "s|[ \t]|_|g")/yf_sample"
[ -d "$MYDIR" ] && printf "Error creating working directory (already exists).\n\a" && exit 1
! mkdir -p "$MYDIR" && printf "Error creating working directory.\n\a" && exit 1
cd "$MYDIR"
URL="http://ftp.avm.de/fritzbox/fritzbox-$MODEL/deutschland/fritz.os/FRITZ.Box_$MODEL-$VERSION.image"
wget -q -O avm.tar $URL
tar -x -f avm.tar -O ./var/tmp/kernel.image >kernel
dd of=kernel.bin if=kernel bs=8 count=$(( ( $(stat -c %s kernel) / 8 ) - 1 )) 2>/dev/null
rm kernel
tar -x -f avm.tar -O ./var/tmp/filesystem.image >fs.sqfs
git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
MAGIC=$(dd if=fs.sqfs count=4 bs=1 2>/dev/null)
[ "$MAGIC" = "sqsh" ] && ENDIAN=be || ENDIAN=le
sudo YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-$ENDIAN -no-progress fs.sqfs
sudo chown -R $(id | sed -n -e "s|uid=\([0-9]*\).*|\1|p"):$(id | sed -n -e "s|.*gid=\([0-9]*\).*|\1|p") squashfs-root/
rm fs.sqfs
mkdir modfs/$MODEL
cd modfs/
for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh; do
        ln -s ../modscripts/$modscript $MODEL/
done
./run_modscripts ../squashfs-root/ $MODEL
modrc=$?
cd ..
if [ "$modrc" -eq 0 ]; then
        YourFritz/bin/squashfs/$(uname -m)/mksquashfs4-$ENDIAN squashfs-root/ fs.sqfs -all-root -no-progress
        cat kernel.bin fs.sqfs >new.image
        ls -l
else
        printf "At least one 'modscript' reported an error, packing skipped.\n\a"
fi
exit $modrc
... und ehe mir wieder "Klagen" kommen, daß das jemand nicht aus der Seite hier so einfach herauskopieren kann, hänge ich es (trotz "Wer immer strebend sich bemüht, den können wir erlösen." - um mal wieder eine Textstelle aus einem Werk von J.W.v.Goethe zu zitieren, nämlich "Faust II") noch einmal als Datei hier an. Kommt jetzt allerdings der Nächste und empört sich darüber, daß die Datei aber die Endung ".txt" hat (weil die Board-Software das so will), dann möge er das bitte gleich für sich behalten ... wenn jemand eine Datei (beim oder nach dem Download) nicht alleine umbenennen kann, interessiert mich das (in meinem Elfenbeinturm) nicht die Bohne.

Und auch hier betone ich noch einmal (schon um erneute Mißverständnisse zu vermeiden, auch wenn der gewählte Verzeichnisname "yf_sample" für sich selbst sprechen sollte), daß es sich meinerseits nur um ein Beispiel handelt, wie man die Firmware für andere Boxen (bei VR9 funktioniert das so gar nicht, weil das Entpacken auch dann anders aussehen muß, wenn nicht länger "ext2", sondern auch wieder SquashFS verwendet wird für die "wrapper"-Partition) modifizieren KÖNNTE, wenn man "modfs" dafür nehmen wollte.
 

Anhänge

Zuletzt bearbeitet:
  • Like
Reaktionen: Insti

Insti

Mitglied
Mitglied seit
19 Aug 2016
Beiträge
651
Punkte für Reaktionen
61
Punkte
28
Diese Version kann einfach mit dem Modellnamen und der Versionsnummer der AVM-Firmware aufgerufen werden (für Release-Versionen und solange die URL bei AVM dann denselben
Funktioniert einwandfrei. Gerade auf dem Raspberry Pi für die 7530 getestet
Code:
[email protected]:/opt# ./fritzbuild7530.sh
++ MODEL=7530
++ VERSION=07.21
+++ id
+++ sed -n -e 's|uid=[0-9]*(\([^)]*\)).*|\1|p'
+++ sed -e 's|[ \t]|_|g'
++ MYDIR=/tmp/root/yf_sample
++ '[' -d /tmp/root/yf_sample ']'
++ mkdir -p /tmp/root/yf_sample
++ cd /tmp/root/yf_sample
++ URL=http://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.21.image
++ wget -q -O avm.tar http://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.21.image
++ tar -x -f avm.tar -O ./var/tmp/kernel.image
+++ stat -c %s kernel
++ dd of=kernel.bin if=kernel bs=8 count=388064
++ rm kernel
++ tar -x -f avm.tar -O ./var/tmp/filesystem.image
++ git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
Cloning into 'YourFritz'...
remote: Enumerating objects: 122, done.
remote: Counting objects: 100% (122/122), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 3487 (delta 75), reused 88 (delta 47), pack-reused 3365
Receiving objects: 100% (3487/3487), 4.03 MiB | 2.85 MiB/s, done.
Resolving deltas: 100% (2229/2229), done.
Submodule 'bin' (https://github.com/PeterPawn/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/tmp/root/yf_sample/YourFritz/bin'...
remote: Enumerating objects: 99, done.
remote: Counting objects: 100% (99/99), done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 926 (delta 22), reused 90 (delta 19), pack-reused 827
Receiving objects: 100% (926/926), 75.25 MiB | 5.68 MiB/s, done.
Resolving deltas: 100% (180/180), done.
Cloning into '/tmp/root/yf_sample/YourFritz/first_aid'...
remote: Enumerating objects: 42, done.
remote: Total 42 (delta 0), reused 0 (delta 0), pack-reused 42
Submodule path 'bin': checked out '761344186579a26a7f60791f76f0f938b19b3a44'
Submodule path 'first_aid': checked out '0359a4db07ffb555b5714184f16a2ffd7348955b'
++ git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
Cloning into 'modfs'...
remote: Enumerating objects: 130, done.
remote: Counting objects: 100% (130/130), done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 1735 (delta 75), reused 89 (delta 41), pack-reused 1605
Receiving objects: 100% (1735/1735), 17.22 MiB | 3.87 MiB/s, done.
Resolving deltas: 100% (1166/1166), done.
+++ dd if=fs.sqfs count=4 bs=1
++ MAGIC=hsqs
++ '[' hsqs = sqsh ']'
++ ENDIAN=le
+++ uname -m
++ sudo YourFritz/bin/squashfs/armv7l/unsquashfs4-le -no-progress fs.sqfs
sudo: unable to resolve host ubuntu: Name or service not known
Found TI checksum (0xED68084B) at the end of the image.
Filesystem on fs.sqfs is xz compressed (4:0)
Parallel unsquashfs: Using 4 processors
8325 inodes (9284 blocks) to write


created 7631 files
created 516 directories
created 693 symlinks
created 1 devices
created 0 fifos
+++ id
+++ sed -n -e 's|uid=\([0-9]*\).*|\1|p'
+++ id
+++ sed -n -e 's|.*gid=\([0-9]*\).*|\1|p'
++ sudo chown -R 0:0 squashfs-root/
sudo: unable to resolve host ubuntu: Name or service not known
++ rm fs.sqfs
++ mkdir modfs/7530
++ cd modfs/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/gui_boot_manager_v0.6 7530/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/mod_enable_calllog 7530/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/mod_fixed_branding 7530/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/mod_telnet_enable 7530/
++ for modscript in gui_boot_manager_v0.6 mod_enable_calllog mod_fixed_branding mod_telnet_enable mod_rc_tail_sh
++ ln -s ../modscripts/mod_rc_tail_sh 7530/
++ ./run_modscripts ../squashfs-root/ 7530
Running script 'gui_boot_manager_v0.6' ...
      Patching file 'usr/www/1und1/system/reboot.js' ...
      Patching file 'usr/www/1und1/system/reboot.lua' ...
      Patching file 'usr/www/avm/system/reboot.js' ...
      Patching file 'usr/www/avm/system/reboot.lua' ...
      Patching file 'usr/www/avme/system/reboot.js' ...
      Patching file 'usr/www/avme/system/reboot.lua' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_fixed_branding' ...
Das Branding für das neue System wurde fest auf 'avm' eingestellt.
Finished script 'mod_fixed_branding', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0
++ modrc=0
++ cd ..
++ '[' 0 -eq 0 ']'
+++ uname -m
++ YourFritz/bin/squashfs/armv7l/mksquashfs4-le squashfs-root/ fs.sqfs -all-root -no-progress
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on fs.sqfs, block size 65536.

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 25160.05 Kbytes (24.57 Mbytes)
        21.72% of uncompressed filesystem size (115822.59 Kbytes)
Inode table size 65690 bytes (64.15 Kbytes)
        22.11% of uncompressed inode table size (297074 bytes)
Directory table size 83592 bytes (81.63 Kbytes)
        37.49% of uncompressed directory table size (222986 bytes)
Number of duplicate files found 5052
Number of inodes 8848
Number of files 7637
Number of fragments 383
Number of symbolic links  694
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 516
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
++ cat kernel.bin fs.sqfs
++ ls -l
total 86424
drwxr-xr-x 28 root root     4096 Jan 27 22:32 YourFritz
-rw-r--r--  1 root root 30740480 Oct 27 14:50 avm.tar
-rw-r--r--  1 root root 25767936 Jan 27 22:34 fs.sqfs
-rw-r--r--  1 root root  3104512 Jan 27 22:32 kernel.bin
drwxr-xr-x  9 root root     4096 Jan 27 22:33 modfs
-rw-r--r--  1 root root 28872448 Jan 27 22:34 new.image
drwxr-xr-x 13 root root     4096 Oct 19 18:31 squashfs-root
++ exit 0
[email protected]:/opt#
Tolle Arbeit! Vielen Dank!
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,646
Punkte für Reaktionen
1,209
Punkte
113
Neue Beta-Version 0.6.4

Download über http://yourfritz.de/modfs-0.6.4-beta.tgz

Wer das Repo klont, muß dann halt den Branch beta auschecken (git switch beta nach dem Klonen oder gleich ein -b beta beim git clone mit angeben).

Einzige relevante Änderung:


Die Aktivierung des "Inhouse-Mode" für den telefon-Daemon erfolgt jetzt (dynamisch) in Abhängigkeit von der vorliegenden Version, wobei für den alten und neuen Weg (siehe https://www.ip-phone-forum.de/threads/busybox-mit-telnet-in-fritz-os-7-2x.307385/page-5#post-2416096 und Beiträge davor) derselbe Code verwendet wird, weil die reine Versionsnummer der Firmware wohl kein zuverlässiges Unterscheidungsmerkmal ist, welche Variable von AVM tatsächlich genutzt wird. Ich habe mich auch zur Nutzung von 998 (das, was bei AVM als "private" läuft) entschieden - bisher war dieses private auch der Wert von config.gu_type, der aus dem CONFIG_RELEASE=0 resultierte - solange das also keinen Unterschied zum Wert 2 macht, nehme ich lieber die 998.

Die Änderungen sind für die neuen Versionen von mir auf einer 113.07.24-86493 (also einer 7490) getestet (für den alten Weg habe ich nur geprüft, daß die richtigen Änderungen ausgeführt werden) ... daher kann ich auch bestätigen (siehe die Frage im verlinkten Thread), daß die calllog auch weiterhin abgearbeitet wird, mithin der Name mod_enable_calllog immer noch seine Berechtigung hat.

Nach den ersten zwei, drei positiven Rückmeldungen (oder nach dem Fehlen negativer Erfahrungen in den nächsten drei Tagen) würde ich das in die "reguläre" Version (also den master-Branch) überführen, dann paßt es auch wieder mit dem Symlink unter modfs.tgz ohne die Versionsangabe beim Download.
 

eisbaerin

IPPF-Urgestein
Mitglied seit
29 Sep 2009
Beiträge
10,396
Punkte für Reaktionen
787
Punkte
113
Warum hast du dich für 998 entschieden und nicht für 2?

Noch ein Hinweis zur mod_rc_trail_sh.
Ich mußte beim FR1200 und FW 7.14 die "insertline" ändern auf den Start mit nohup, so wie du es bei der /etc/boot.d/core/rcuser machst.
Sonst wurde die /var/tmp/rc.user nicht abgearbeitet.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,646
Punkte für Reaktionen
1,209
Punkte
113
Warum hast du dich für 998 entschieden und nicht für 2?
Steht doch oben ... der wird als config.gu_type=private gesehen in der /usr/lua/config.lua (die 2 dagegen als beta) und das ist derselbe Wert, der sich bis zur 07.24 aus dem CONFIG_RELEASE=0 ableitete.

Damit bliebe auch config.gu_type im Lua-Code stabil, wenn man das config-Objekt von AVM "nachnutzen" wollte und den Wert systemweit setzt (auch dafür enthält telnetd_by_avm ja die Abfrage/Vorbereitung (https://github.com/PeterPawn/modfs/...9f80e998dd29d74bd9c2/files/telnetd_by_avm#L35 - die zweite Bedingung) und nicht nur für die Änderung, die durch mod_enable_calllog in der rc.voip vorgenommen wird) - das ist ggü. der bisherigen Implementierung die kleinere Änderung im Verhalten eines gepatchten Systems.

==========================================================

Noch ein Hinweis zur mod_rc_trail_sh.
Das verstehe ich (so lapidar) nicht - mal abgesehen von der Frage, ob das auch für einen Repeater gedacht ist/war oder nicht.

Die Unterscheidung, ob es sich um ein älteres System (mit serieller Abarbeitung bei der Initialisierung) handelt oder nicht, wird anhand der Existenz einer /etc/init.d/rc.tail.sh getroffen (https://github.com/PeterPawn/modfs/...98dd29d74bd9c2/modscripts/mod_rc_tail_sh#L130) - bisher war bei den Systemen, die supervisor zum Start verwenden, diese Datei nicht mehr vorhanden.

Wenn das beim FR1200 anders sein sollte und der über supervisor startet, aber trotzdem diese Datei noch hat, dann müßte man tatsächlich den Test etwas anders gestalten. Aber das kann man nun beim besten Willen aus #1845 nicht erkennen ... da wäre es hilfreich, wenn Du ein paar genauere Infos bereitstellen könntest; z.B. eben, welche "Startart" da nun tatsächlich verwendet wird und ob (ggf. sogar, warum) da nun noch eine rc.tail.sh von AVM rumsteht und was die im Original enthält.

Wenn da aber tatsächlich noch seriell abgearbeitet wird beim Start (durch die Schleife in der /etc/init.d/rc.S), dann stellt sich eher die Frage, warum die Zeile (die ja keinen asynchronen Aufruf enthält) nicht korrekt abgearbeitet wird ... ich hätte hier eher den Verdacht (wobei mich auch die Frage quält, warum da eine 07.1x noch über die rc.S gestartet wird), daß der Repeater gar keinen eigenen multid enthält (den bräuchte er ja auch nur für die eigene Uhrzeit über chrony, denn DHCP und DNS und den ganzen anderen Kram des multid hat ein Repeater nicht) und damit generell auf diesem Gerät die Verwendung von delay nicht möglich ist, weil das nur ein verkapptes msgsend an den multid ist.

DAS wären jedenfalls Infos, wie man sie für eine halbwegs kompetente Einschätzung der Ursache(n) bräuchte ... so wie jetzt, ist das zwar als Hinweis "nett", aber es bringt nur wenig - ich kann (und will) nicht selbst durch jede einzelne Firmware von AVM latschen.

Dafür sind das nun mittlerweile deutlich zu viele und vor allem gilt für die meisten sogar, daß die mich selbst gar nicht tangieren - mein AVM-Gerätepark ist begrenzt und mein Interesse mittlerweile auch; man merkt's sicherlich auch daran, daß ich nicht mehr jedem Sche** von AVM bei jeder Labor-Version hinterher renne, sondern immer schön auf die erste Release-Version warte, bevor ich mir selbst Arbeit mache und sei es nur die, mich in die AVM-Dateien einzulesen, um Probleme wie das nunmehr gelöste (und die Hinwendung zu CONFIG_BUILDTYPE) zu lokalisieren. Da spielt die Tatsache, daß der FR1200 ja auch per se kein von "modfs" unterstütztes Modell ist und ich nie den Anspruch erhoben habe, daß man irgendeines der vorbereiteten Skripte auch bei einem Repeater erfolgreich verwenden könnte, nur noch eine untergeordnete Rolle und auch wenn ich das durchaus nur als "Hinweis" gelesen und verstanden habe, verbindet sich ja damit wohl trotzdem eine gewisse "Erwartungshaltung".

Vermutlich jedenfalls - zumindest bisher war es häufig so und dann wurde mir später auch gerne mal geschrieben, daß man mir das ja schon vor sehr, sehr langer Zeit (wenn auch eher "am Rande", wie hier wohl auch) mitgeteilt hätte. Und da ist es mir dann auch ein Bedürfnis, noch einmal darauf hinzuweisen, was ich am Beginn des Jahres schrieb: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2403580 - da ging es zwar auch (primär) um die neue Funktion mit den "Diskussionen", aber die Meldung von Fehlern im Projekt (egal in welchem), sollte ja schon länger als "Issue" im GitHub-Repo erfolgen (da kann man das dann nämlich auch viel besser verfolgen und verwalten, bis hin zur Behebung durch einen Patch/eine neue Version) und nicht mehr hier in irgendwelchen IPPF-Threads im "Volltext".

Wenn ich dann (bei deutlich weniger Zeit, die ich mit dem Lesen von IPPF-Threads verbringe und auch die Zahl meiner eigenen Beiträge ist ja deutlich rückläufig) irgendeine dieser "Meldungen" überlesen sollte (oder sie einfach auch nur vergesse, weil ich nicht sofort darauf einsteigen kann und es nun mal keinen "reminder" hier im Board gibt, den man komplikationslos nutzen könnte), darf man sich darüber auch nicht beschweren. Daher ist es einfach besser, das gleich selbst so zu machen, daß ich es nicht überlesen kann und es sogar (im GitHub-Dashboard) explizit "abhaken" muß - dann wird so etwas auch nicht (zumindest nicht versehentlich) übersehen/ignoriert/liegen gelassen.