yf_patchkernel & kernel v4

[fda77]

Kannst du das yf_patchkernel (ist das der offizielle Name?) für kernel 4.9 der 7590 und die verschiedenen 4.4 der anderen Geräte anpassen? Die Docsis Geräte mit 4.9 am besten ignorieren, da gibts nichts den neuestens Source von AVM. Wie compiliert man kernelmodule für 4.9? Nicht mit dem master, da dort keine Kernelmodule freigeschaltete sind Replace kernel (not available, needs AVM sources) , also erst gar nicht compiliert wird - ausser man fummelt herum und verschweigt das im Forum... Sondern man nimmt den entsprechenden branch den es seit heut morgen gibt. Davor könntest du noch dein geflame von wegen keine Branches, Versuchskanninchen usw von heut Mittag korrigieren ;-)

[PeterPawn]

Denke gar nicht dran ... den Commit, den ich im Beitrag verlinkt habe, habe ich im "master"-Branch gefunden und wenn Du das als "Flame" interpretierst, ist ohnehin jede weitere Diskussion sinnlos - auf der Ebene läuft da gar nichts.

Ich habe ganz vernünftig versucht Dir zu erklären, warum Feature-Branches Sinn ergeben und wenn Du tatsächlich mal einen gemacht hast, stellt man sich halt automatisch auch die Frage, warum dann https://github.com/Freetz-NG/freetz-ng/commit/23b5254fcec2f99598ee289581280202cc72153a im "master" gelandet ist und nicht in diesem Feature-Branch. Das Ergebnis kannst Du im betreffenden IPPF-Thread nachlesen ... wenn Du es mittlerweile geändert/gefixt haben solltest, um so besser.

Aber in dem Ton bzw. mit dem Vokabular geht's garantiert nicht weiter ... entweder Du schaltest einen Gang zurück oder das war's dann mal wieder mit der "friedlichen" Kommunikation.

Ich erwarte mit Spannung Deine Entscheidung ... erst mal ist hier zu,

Begründung: Mangel an Klarheit, was "yf_patchkernel" (und ja, das ist der Name, den ich dem Ganzen gegeben habe, damit auch durch das "yf" klar auf "YourFritz" verwiesen wird, wenn das künftig von jemand anderem übernommen werden sollte) genau davon abhalten sollte, bei passender Toolchain und passendem Kernel-Build auch sauber zu übersetzen.

Das "Drumherum" (Toolchain, Kernel-Build-Environment) hat wieder nichts mit dem Inhalt von yf_patchkernel zu tun - die Diskussion hatten wir hinsichtlich "avm_kernel_config" doch schon einmal.

Sollte es tatsächlich (in einer funktionierenden Umgebung) Probleme beim Build dieses LKM geben, die bei anderen nicht auftreten, hätte ich gerne das entsprechende Fehlerprotokoll, damit ich das nachstellen kann. Das gilt natürlich ebenso wieder für die verwendete Umgebung, sofern diese eine Rolle spielen sollte (wenn das also mit Ubuntu 20.04 LTS läuft, aber mit Deinem System wieder nicht).

[fda77]

Eben? Ton? Was? Drück mal reset. Natürlich hast du im IPPF herumgeflamt. Zu meine Glück nachdem ich den Branch machte

Der Commit https://github.com/Freetz-NG/freetz-ng/commit/23b5254fcec2f99598ee289581280202cc72153a ist irrelevant. Man kann in die .config der Kernels in diesem Fall was beliebiges hineinschreiben, zb aus /dev/random Wie im OP schon steht wird der Kernel nämlich gar nicht compiliert sondern nur Header benutzt, weil weder Module noch Kernel für 4.9 freigeschaltet sind, wie im OP steht sieht man das im menuconfig

Was für ein Fehlerprotokoll? yf_patchkernel gibt es schlicht nicht für kernel 4

[fda77]

Wie ist das nun mit yf_patchkernel updates? Weil es in freetz* ist updatest du es nicht mehr? Scheint jedenfalls noch benötigt zu werden als vpn-Server laut https://www.ip-phone-forum.de/threads/307471/post-2379603 Meldung: BUG() at function 'esp_init_authenc' line: 771 file: /GU/KERNEL_grx5_build/linux/net/ipv4/esp4.c Zeile im Quellcode, falls der von AVM zum Kernal passt: BUG_ON(!aalg_desc);

[PeterPawn]

Das hat gar nichts mit "yf_patchkernel" zu tun ... das wurde dafür entwickelt, zwei "fehlerhafte" Statements in den Quellen, die bei AVM im originalen Kernel vorhanden waren, wieder zu neutralisieren.

Da war aber schon klar, daß diese Statements die Ursache für die entsprechenden Fehler waren (weil sie zuvor schon bei der Verwendung eines eigenen Kernels entfernt wurden und dann alles funktionierte) und es ging nur noch um die Suche nach einer Lösung, die auf das Ersetzen des AVM-Kernels verzichten kann, weil das auch nicht (immer) problemlos möglich ist.

Aber selbst dann wurde das nicht gleich in Form dieses LKM von mir umgesetzt ... vorher gab es noch Shell-Skripte für die verschiedenen Modelle (weil sich die Kernel marginal unterschieden) und erst als diese ebenfalls ihre Tauglichkeit unter Beweis gestellt hatten und damit klar war, daß man den (AVM-)Kernel auf diesem Weg patchen kann, kam dann "yf_patchkernel".

Wo siehst Du hier irgendwelche Parallelen zu dem Fall im IPPF? Da ist weder ein TUN/TAP-Device involviert, noch erfolgt der Absturz in einer der bekannten Funktionen.

Einfach so "auf Verdacht" alle Traps aus den Kernel-Funktionen herauszupatchen, ohne Sinn und Verstand und ohne jede Ahnung, ob das Problem damit auch behoben wäre, kann ja wohl nicht der Sinn der Sache sein.

Das hat jedenfalls mit diesem Projekt Nullkommanichts zu tun ... sollte sich tatsächlich irgendwann mal herausstellen, daß nicht vollkommen andere Änderungen zu diesem Problem führen und es wirklich diese Trap im Source-Code ist, reden wir weiter.

Und eins noch ... ich habe noch nie die "Verantwortung" abgelehnt, wenn etwas, das ich (auch) für Freetz erstellt habe und das dann auch in der von mir erschaffenen Form Einzug in das Projekt hielt, von einem Problem betroffen war.

Wenn das aber gar nicht mehr "meine Software" ist (was bei "yf_patchkernel" aber bisher durchaus der Fall ist, denn das ist genau das, was ich da "angeboten" habe für die Integration in Freetz: https://github.com/Freetz/freetz/pull/148), dann sehe ich mich logischerweise auch nicht mehr in der Verantwortung dafür (falls Du da Anspielungen auf "avm_kernel_config" machen wolltest).

Es wäre also nett, wenn Du auf derartige Sprüche künftig verzichtest:

Wie ist das nun mit yf_patchkernel updates? Weil es in freetz* ist updatest du es nicht mehr?

Erstens fehlt es den dort getroffenen Annahmen deutlich am Wahrheitsgehalt und zweitens motivieren mich derartige "Fragen" auch definitiv nicht dazu, meine Zeitplanung über den Haufen zu werfen und mich jetzt unbedingt damit zu befassen. Eher noch wird mein Widerspruch angefacht und das wird - aller bisherigen Erfahrung nach - dann eher zu weiteren Verzögerungen (mal abgesehen davon, daß hier erst mal nichts zu tun ist) führen.

[fda77]

Wieso wieder "Sprüche"?? Ich wollte einfach nur wissen wie du dazu stehst. Bei der config-area ists klar, da der Code viel geändert wurde. Kann ich auch verstehen. Ob die "BUG" Fehler beim Verbindungsaufbau mit yf-pk zu beheben sind musst du wissen, ich kenn mich da nicht aus. Damit du nachschauen kannst hab ich dir oben den Link gepostet mit den Zeilen die mich vermuten lassen dass es hiermit zu tun hat

[PeterPawn]

OK, dann noch mal die Feststellung: Ohne genaue Analyse, was da wirklich das Problem ist und ohne (vorherigen) Test durch Patchen des Kernels per Shell-Skript, macht es keinen Sinn, irgendetwas per yf_patchkernel ändern zu wollen.

Ich habe das Tool zwar absichtlich so weit gefaßt, daß es nicht nur die zwei Traps wegpatchen kann, die bisher das Verwenden von TUN/TAP-Devices verhindern, aber ohne genaue Ideen, was da wie zu ändern ist, kann man das Tool auch nicht anpassen.

Und so weit ist die Suche nach der Ursache des Problems (ich weiß auch nicht, wie weit die heute vorwärts gegangen ist, denn ich hatte noch anderes zu tun) garantiert noch nicht ...

Und "Sprüche" deshalb, weil das bei weitem nicht so "neutral" formuliert war, wie Du jetzt tust ... aber solange Du meine Bitte respektierst, ist ja alles gut.

[fda77]

Geh nicht so oft davon aus dass ich irgendwas negativ meine, das ist selten ;-)

[PeterPawn]

Nun lies Dir mal das noch einmal durch:

Wie ist das nun mit yf_patchkernel updates? Weil es in freetz* ist updatest du es nicht mehr?

und dann sage mir, wie man das mißverstehen sollte. Wenn Du nach dem ersten Fragezeichen geendet hättest, wäre es auch gut gewesen ... oder willst Du mir noch erklären, wie Du auf die Vermutung/Annahme im zweiten Satz gekommen bist?

Bei einer "ganz normalen Frage" legt man dem Gegenüber nun mal die Antwort nicht in den Mund - zumal das hier auch noch vorwegnimmt (entgegen dem, was ich weiter oben schon ausdrücklich schrieb), daß ich mich nicht länger darum kümmern bzw. mich weigern würde. Oder wo habe ich da Verständnisprobleme beim Umgang mit der deutschen Sprache?

Ich bin ja auch bereit, das Mißtrauen/die Vorsicht wieder zurückzufahren ... aber "Dackelblick" und unschuldiges Getue, während unterm Tisch mit Stahlkappen getreten wurde, hatte ich im IPPF genug und da gibt's eine Ignore-Liste, auf der sich auch so mancher tummelt.

Wenn das hier also etwas werden soll, muß es wirklich "gesittet" zugehen und dazu gehört auch nicht die Verdächtigung/Bezichtigung des "Flamens" - die steht dann sogar hier im Thread, weshalb ich dabei dann doppelt hellhörig bin.

Ich habe da garantiert auch keinen Alu-Hut auf, bin aber eben aufgrund schlechter Erfahrungen - auch mit Dir, selbst wenn wir das wohl beide vergessen wollen - schon etwas aufmerksamer und es ist ja nun kein Kunststück, solche "Anfragen" wirklich neutral zu formulieren.

Wenn Du Dir das beim nächsten Mal vor dem Drücken auf den "Comment"-Button verdeutlichst, daß Du es nicht negativ meinst, obwohl es so klingt, kannst Du das ja dann noch korrigieren. 😉

[fda77]

Wenn man was liest, versteht man es oft so wie man es vorher schon erwartet hat

Dass du dich Tagelang über das flamen aufregen kannst. Also nochmal die Fakten

• du schriebst Mittags im ippf dass ich keeen branches mache und alle zu Testobjekten machem würde
• ich hatte an diesem Morgen aber genau zu dem Problem zu dem du gepostet hast einen Branch erstellt (sieht man hier auf dem mirror noch https://gitlab.com/Freetz-NG/freetz-ng/activity)

Ist zwar selten, war aber so. Das war dann einfach dumm gelaufen für dich, und dann musst du halt damit leben wenn ich dazu was schreibe (herumflamen). Da gibts ja nicht wirklich was zum diskutieren!

Hab übrigens meine Mailadresse im ippf zurückgesetzt bekommen und ein neues Passwort. War also nicht gelöscht. Der Account ist aber aktuell gesperrt -.-

[PeterPawn]

Weißt Du, was da an Deiner Vorstellung schon nicht stimmt ... die Annahme, daß ich (oder irgendjemand anderes) alles das, was Du so machst, so genau verfolge, daß mir eine (wie Du selbst schreibst) "Ausnahme" vom Morgen (in einem ganz anderen Medium) schon aufgefallen sein müsse, wenn ich mittags im IPPF schreibe.

Und nur aus dieser Haltung heraus, kann man dann überhaupt halbwegs plausibel davon ausgehen, daß es "Flamen" wäre, wenn man Dir - ganz sachlich - die Konsequenzen des Fehlens von Feature-Branches versucht zu erklären: https://www.ip-phone-forum.de/threads/freetz-ng-compile-error-cannot-use-config_cc_stackprotector_regular-fstack-protector-not-supported-by-compiler.307413/post-2378910

Noch dazu, nachdem Du sogar explizit danach gefragt hattest, was denn aus meiner Sicht noch an Problemen im Freetz-NG bestünde: https://github.com/PeterPawn/YourFritz/commit/385457d88a0c34df15634db108c39c987d15d2bf#commitcomment-40535555 - und das an einer Stelle, wo ich Dir klar und deutlich erklärt hatte, daß ich an dieser "abseitigen" (fast bin ich versucht "abartig" zu schreiben) Stelle keine weiteren Antworten mehr geben würde, weil das dahingehend brotlos ist, daß es dort niemand findet.

Und es ist jetzt auch keineswegs so, daß es Dir irgendwie unmöglich gewesen wäre, den Zusammenhang zwischen meinem Text im IPPF und Deiner Frage an mich hier (Link s.o.) herzustellen ... denn schließlich beginnt mein an Dich gerichteter Text sogar ausdrücklich mit den Worten:

Das ist z.B. einer der Kritikpunkte, von denen ich (Du weißt wo) geschrieben habe

Wenn das für Dich "Flamen" ist - und das nur auf der Basis Deiner eigenen Feststellung, daß Du an diesem Tag tatsächlich ausnahmsweise mal einen solchen Feature-Branch eingerichtet hattest -, dann leben wir in so verschiedenen Welten, daß es dazwischen ohnehin keine Kommunikationswege gibt.

Es mag ja sein, daß Du bei Deiner Frage nur "inhaltliche Probleme" im Freetz-NG-Fork im Sinn hattest ... es ging aber bei meiner Aussage, auf die sich Deine Frage dann bezog (https://github.com/PeterPawn/YourFritz/commit/385457d88a0c34df15634db108c39c987d15d2bf#commitcomment-40533220) sogar explizit um "den einen oder anderen Kritikpunkt aus dem Januar 2019", der mittlerweile erledigt wäre - und damals ging es ja sogar in allererster Linie um die "organisatorischen Fragen".

Der mittlerweile nicht mehr präsente Rückschritt zum SVN war da z.B. einer der "Kritikpunkte", die inzwischen behoben sind oder auch das "Löschen" der Abstammung des ersten GitHub-Repos für Freetz-NG, etc. ... aber das waren ja auch nicht die einzigen Punkte und ich denke nicht, daß ich Dir erst noch die Links zu meinen Beiträgen dazu irgendwo hinlegen muß - Deine Beiträge dazwischen hast Du ja entsorgt.

Ich kann auch heute selbst bei mehrmaligem Lesen an dem von mir im IPPF Geschriebenen (https://www.ip-phone-forum.de/threads/freetz-ng-compile-error-cannot-use-config_cc_stackprotector_regular-fstack-protector-not-supported-by-compiler.307413/#post-2378910) gar nichts finden, was irgendwie der gängigen Bedeutung von "Flamen" (ich hatte Dir irgendwo sogar die Wikipedia dazu verlinkt) entspricht und das setzt ja zumindest voraus, daß da irgendeine Provokation enthalten ist.

Wenn diese Provokation für Dich jetzt schon darin besteht (so klingt der zweite Anstrich hier: https://github.com/PeterPawn/YourFritz/issues/34#issuecomment-663907735), daß ich mich traue, etwas im IPPF zu schreiben, ohne zuvor Deine Aktivitäten in der Zeit, die ich zum Schlafen nutzte, genau untersucht zu haben oder gar darin, daß ich eine eigene und von Deiner offenbar abweichende Meinung habe und damit nicht hinterm Berg halte, reden wir so weit aneinander vorbei, daß ich auch keine Lust mehr habe.

Ich habe es mir mittlerweile gespart, die Benutzer im IPPF immer wieder auf die Schwächen von Freetz-NG hinzuweisen (das sind sicherlich andere als bei Freetz/freetz, aber es sind trotzdem welche vorhanden) - auch der Verzicht auf das DEB als "Support-Forum" hat dazu beigetragen. Ich habe also (meiner Ansicht nach jedenfalls) auch den guten Willen gezeigt, Freetz-NG als eine "dauerhafte Alternative" zum Freetz/freetz für einige/mehrere/meinetwegen sogar viele (auch wenn ich den "Statistiken" der Zugriffe auf den SVN da nicht so richtig traue) Benutzer zu akzeptieren und auch diesen Benutzern dann - im Rahmen meiner Möglichkeiten und unter Beachtung meiner eigenen Prioritäten - zu helfen.

Der sicherste Weg, das wieder kaputtzumachen, ist es dann, mir irgendwo (absichtlich) auf die Füße zu treten - das kann zwar ein oder zwei Male auch versehentlich sein (und so eine Mimose bin ich dann doch nicht), aber wenn mir jemand absichtlich auf die Nerven gehen will, dann schaffe ich es mittlerweile auch, ihn komplett zu ignorieren - das war für mich (ich bin da noch alte Schule) auch ein ziemlicher "Lernprozess", aber auch ein alter Hund lernt eben noch neue Tricks.

Früher waren "ignore lists" in meinen Augen etwas für Weicheier, die sich nicht wehren können oder wollen, wenn sie jemand vollpflaumt. Inzwischen weiß ich aber, daß mittlerweile praktisch jeder Idiot (bis hin zum POTUS) "im Internet" schreiben kann/darf - was wünsche ich mir manchmal die "gute alte Zeit", wo es noch ein Minimum an Kenntnissen dafür brauchte, zurück. Aber es ist, wie es ist ... und ich kann mittlerweile mit diesen Techniken umgehen.

Und so ganz unbekannt sind Dir diese Möglichkeiten ja auch nicht ... ich erinnere Dich nur ungerne an die Anstrengungen beim "Blockieren" auch im GitHub, die Du Deinerseits im Frühjahr/Sommer 2019 unternommen hast (oder dachtest Du ernsthaft, das wäre mir entgangen?).

Auch das macht natürlich ein "Ich meine es nur selten negativ." dann zu einer Aussage, die erst noch ihren Wahrheitsgehalt unter Beweis stellen muß und so ärgern mich dann Ansichten, ich würde mit einem Beitrag im IPPF provozieren (wir waren uns hoffentlich schon einig, daß das der Kern von "Flamen" wäre), durchaus und das - wie Du merkst - auch auf deutlich längere Zeit, als Du es ggf. vermutest. Das raubt mir dann zwar auch nicht den Schlaf, beeinflußt aber logischerweise auch meine Reaktionen und sogar die Art zu antworten.

[fda77]

Ich mag da wirklich nicht nochmal darauf eingehen. Zu svn: Git ist kein Fortschritt, da es noch zu buggy ist. Es gibt mindestens 5 Punkte in denen Svn überlegen ist. Ich geh mal davon aus dass die irgendwann für Git nachgereicht werden. Boxmatrix war für mich unbenutzbar da mein Account nicht mehr ging und der Server eh viel zu lahm ist. Git-Server bekommt man überall kostenlos nachgeschmissen Es ist kein Geheimnis dass ich gerne Leute ignoriere die mir meine Zeit mit ihrem sinnlosen vor sich hingeposte stehlen. Genau deshalb bin ich nicht mehr im DEB, dort gab es davon nur sehr wenige Ausnahmen

[PeterPawn]

Hier zählt für mich das Ergebnis (bis hin zur "Abstammung" des Forks) und da ist es mir vollkommen gleichgültig, ob das wegen einer Einsicht in die Notwendigkeit oder mangels Alternativen zustande gekommen ist.

Auch hinsichtlich des "Nachreichens" teile ich Deinen Optimismus nicht wirklich - Generationen von Programmierern (und allen möglichen anderen Leuten, die Versionierung für Dateien brauchen) arbeiten jetzt seit 15 Jahren mit Git und auch wenn es immer wieder Verbesserungen gibt (nichts ist wirklich vollkommen), wäre das "generelle Fehlen" von fünf wichtigen Punkten, wo SVN nach Deiner Ansicht Git überlegen sein soll, bestimmt schon dem einen oder anderen aufgefallen und wenn das dann die notwendige (positive) Resonanz gefunden hätte bei denjenigen, die damit arbeiten sollen/müssen/wollen, dann wäre das vermutlich "auf der Agenda" (und das nicht erst für die weiter entfernte Zukunft).

Aber mir ist's auch egal, warum jemand Git nutzt - meine Präferenz dürfte auch deutlich sein, denn ich habe schon lange vor der (finalen) Abschaltung des (originalen) SVN-Servers für Freetz auch nur noch mit Git/GitHub und einem Freetz-Fork hier "gearbeitet" und das auch, obwohl ich davor lange mit CVS (und später auch SVN) unterwegs war. Das Bessere ist nun mal der Feind des Guten ...

[fda77]

Das würde hier den Rahmen sprengen...

[fda77]

Habs mir doch anders überlegt da mit ein schöner Commit dafür eingefallen ist: Wer ist der Author dieser Datei?

• https://github.com/Freetz-NG/freetz-ng/blob/master/make/linux/patches/2.6.32.61/4020_06.50/011-perl_5.22_invalid_syntax.patch
• https://github.com/Freetz-NG/freetz-ng/commit/b7335973dc4ebc5bf58ab4114cb84dced930351b

Falls du es nicht herausfindest darfst du das Trac vom svn verwenden:

• https://trac.boxmatrix.info/freetz-ng/changeset/16933/freetz-ng
• https://trac.boxmatrix.info/freetz-ng/log/freetz-ng/trunk/make/linux/patches/2.6.32.61/4020_06.50/011-perl_5.22_invalid_syntax.patch

[PeterPawn]

Keine Ahnung, worauf Du hinauswillst ... aber wenn Du das "Original" suchst, wirst Du hier: https://github.com/Freetz/freetz/commit/27dbf7484286a49d6b0553da576f2f615d946fd8 fündig.

peh@vidar:~> cd /tmp
peh@vidar:/tmp> git clone https://github.com/Freetz-NG/freetz-ng.git fng
Cloning into 'fng'...
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 166736 (delta 1), reused 4 (delta 1), pack-reused 166729
Receiving objects: 100% (166736/166736), 61.63 MiB | 5.58 MiB/s, done.
Resolving deltas: 100% (113970/113970), done.
Updating files: 100% (7326/7326), done.
peh@vidar:/tmp> cd fng
peh@vidar:/tmp/fng> git whatchanged b733597 | head -n 20
commit b7335973dc4ebc5bf58ab4114cb84dced930351b
Author: fda77 <fda77@users.noreply.github.com>
Date:   Wed Jul 15 15:48:34 2020 +0200

    kernel: split 011-perl_5.22_invalid_syntax.patch.patch

:100644 100644 2ba0fc9f5 2ba0fc9f5 R100 make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch make/linux/patches/2.6.32.61/3490_06.31/011-perl_5.22_invalid_syntax.patch
:000000 100644 000000000 2ba0fc9f5 A    make/linux/patches/2.6.32.61/4020_06.50/011-perl_5.22_invalid_syntax.patch
:000000 100644 000000000 2ba0fc9f5 A    make/linux/patches/2.6.32.61/6810_06.21/011-perl_5.22_invalid_syntax.patch
:000000 100644 000000000 2ba0fc9f5 A    make/linux/patches/2.6.32.61/7272_06.20/011-perl_5.22_invalid_syntax.patch
:000000 100644 000000000 2ba0fc9f5 A    make/linux/patches/2.6.32.61/7320_06.30/011-perl_5.22_invalid_syntax.patch
:000000 100644 000000000 2ba0fc9f5 A    make/linux/patches/2.6.32.61/7330_06.50/011-perl_5.22_invalid_syntax.patch
:000000 100644 000000000 2ba0fc9f5 A    make/linux/patches/2.6.32.61/7360_06.20/011-perl_5.22_invalid_syntax.patch
:000000 100644 000000000 2ba0fc9f5 A    make/linux/patches/2.6.32.61/7490_06.30/011-perl_5.22_invalid_syntax.patch

commit a99eb01f845071a87cd549a528185ba293b8620e
Author: fda77 <fda77@users.noreply.github.com>
Date:   Wed Jul 15 15:47:48 2020 +0200

    add 1750 src
peh@vidar:/tmp/fng> git log --follow -p -- make/linux/patches/2.6.32.61/3490_06.31/011-perl_5.22_invalid_syntax.patch | cat
commit b7335973dc4ebc5bf58ab4114cb84dced930351b
Author: fda77 <fda77@users.noreply.github.com>
Date:   Wed Jul 15 15:48:34 2020 +0200

    kernel: split 011-perl_5.22_invalid_syntax.patch.patch

diff --git a/make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/3490_06.31/011-perl_5.22_invalid_syntax.patch
similarity index 100%
rename from make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch
rename to make/linux/patches/2.6.32.61/3490_06.31/011-perl_5.22_invalid_syntax.patch

commit 27dbf7484286a49d6b0553da576f2f615d946fd8
Author: Gene Rudoy <gene@freetz.org>
Date:   Sat Aug 15 17:59:36 2015 +0000

    kernel-2.6.28/2.6.32:
     * fix build problems with perl versions >= 5.22
     * fixes #2759

    git-svn-id: http://svn.freetz.org/trunk@13360 f5190166-0702-4917-9039-51ec32eddaf5

diff --git a/make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch
new file mode 100644
index 000000000..2ba0fc9f5
--- /dev/null
+++ b/make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch
@@ -0,0 +1,11 @@
+--- linux-2.6.32/kernel/timeconst.pl
++++ linux-2.6.32/kernel/timeconst.pl
+@@ -370,7 +370,7 @@
+       }
+
+       @val = @{$canned_values{$hz}};
+-      if (!defined(@val)) {
++      if (!@val) {
+               @val = compute_values($hz);
+       }
+       output($hz, @val);
peh@vidar:/tmp/fng>

Wie man sehen kann, gibt es eine ganz saubere Historie für die Datei, die bereits vor diesem Commit existierte und die kann man sogar über das Umbenennen hinweg (ausgehend von ihrem aktuellen Namen) problemlos verfolgen.

Daß die von Dir neu hinzugefügten Dateien ihrerseits keine Historie haben, versteht sich von selbst. Normalerweise würde man die auch nur per Symlink "duplizieren" und nicht jeweils eine neue Datei einchecken. Selbst das kann "git" inzwischen sauber erkennen ... siehe weiter unten.

Was wolltest Du mir damit also "beweisen"?

[PeterPawn]

BTW ... wenn man's dem "git" sagt, erkennt es sogar die Tatsache, daß die anderen Dateien in diesem Commit alles nur Kopien von derselben Quelle sind und auch deren ursprüngliche Historie läßt sich (man beachte das b733597~1 an dieser Stelle für den "Vorgänger" des Commits mit dem angegebenen Hash) problemlos auslesen - auch ohne den HEAD erst dahin zu verschieben o.ä.:

peh@vidar:/tmp/fng> git show --find-copies-harder b733597 | cat
commit b7335973dc4ebc5bf58ab4114cb84dced930351b
Author: fda77 <fda77@users.noreply.github.com>
Date:   Wed Jul 15 15:48:34 2020 +0200

    kernel: split 011-perl_5.22_invalid_syntax.patch.patch

diff --git a/make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/3490_06.31/011-perl_5.22_invalid_syntax.patch
similarity index 100%
rename from make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch
rename to make/linux/patches/2.6.32.61/3490_06.31/011-perl_5.22_invalid_syntax.patch
diff --git a/make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/4020_06.50/011-perl_5.22_invalid_syntax.patch
similarity index 100%
copy from make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch
copy to make/linux/patches/2.6.32.61/4020_06.50/011-perl_5.22_invalid_syntax.patch
diff --git a/make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/6810_06.21/011-perl_5.22_invalid_syntax.patch
similarity index 100%
copy from make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch
copy to make/linux/patches/2.6.32.61/6810_06.21/011-perl_5.22_invalid_syntax.patch
diff --git a/make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/7272_06.20/011-perl_5.22_invalid_syntax.patch
similarity index 100%
copy from make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch
copy to make/linux/patches/2.6.32.61/7272_06.20/011-perl_5.22_invalid_syntax.patch
diff --git a/make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/7320_06.30/011-perl_5.22_invalid_syntax.patch
similarity index 100%
copy from make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch
copy to make/linux/patches/2.6.32.61/7320_06.30/011-perl_5.22_invalid_syntax.patch
diff --git a/make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/7330_06.50/011-perl_5.22_invalid_syntax.patch
similarity index 100%
copy from make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch
copy to make/linux/patches/2.6.32.61/7330_06.50/011-perl_5.22_invalid_syntax.patch
diff --git a/make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/7360_06.20/011-perl_5.22_invalid_syntax.patch
similarity index 100%
copy from make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch
copy to make/linux/patches/2.6.32.61/7360_06.20/011-perl_5.22_invalid_syntax.patch
diff --git a/make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch b/make/linux/patches/2.6.32.61/7490_06.30/011-perl_5.22_invalid_syntax.patch
similarity index 100%
copy from make/linux/patches/2.6.32.41/011-perl_5.22_invalid_syntax.patch
copy to make/linux/patches/2.6.32.61/7490_06.30/011-perl_5.22_invalid_syntax.patch
peh@vidar:/tmp/fng> git log --full-diff b733597~1 -- make/linux/patches/2.6.32.61/011-perl_5.22_invalid_syntax.patch | cat
commit 27dbf7484286a49d6b0553da576f2f615d946fd8
Author: Gene Rudoy <gene@freetz.org>
Date:   Sat Aug 15 17:59:36 2015 +0000

    kernel-2.6.28/2.6.32:
     * fix build problems with perl versions >= 5.22
     * fixes #2759

    git-svn-id: http://svn.freetz.org/trunk@13360 f5190166-0702-4917-9039-51ec32eddaf5
peh@vidar:/tmp/fng>

Da hat die Historie dann halt Deine Änderung noch nicht - es ist ja vor Deinem Commit.

[PeterPawn]

Auch ich habe noch etwas über "git" gelernt ... mir war nämlich nicht bewußt, daß "git" die Tatsache, daß die anderen Dateien nur Kopien sind, sogar sauber erkennt und wiedergibt - hier sogar für eine der Dateien, die Du dupliziert hast:

peh@vidar:/tmp/fng> git log --follow -- make/linux/patches/2.6.32.61/7490_06.30/011-perl_5.22_invalid_syntax.patch | cat
commit b7335973dc4ebc5bf58ab4114cb84dced930351b
Author: fda77 <fda77@users.noreply.github.com>
Date:   Wed Jul 15 15:48:34 2020 +0200

    kernel: split 011-perl_5.22_invalid_syntax.patch.patch

commit 27dbf7484286a49d6b0553da576f2f615d946fd8
Author: Gene Rudoy <gene@freetz.org>
Date:   Sat Aug 15 17:59:36 2015 +0000

    kernel-2.6.28/2.6.32:
     * fix build problems with perl versions >= 5.22
     * fixes #2759

    git-svn-id: http://svn.freetz.org/trunk@13360 f5190166-0702-4917-9039-51ec32eddaf5
peh@vidar:/tmp/fng>

[fda77]

Wie du siehst, ist es überflüssig kompliziert bei git was der "Vorgänger" svn schon mit drin hat und einfach anzeigen kann. Das wird dann wohl noch irgend wann bei git angebaut, hat scheinbar ausser mir noch niemand vermisst, wie du schriebst. Bei svn nimmt man für eine Kopie mit History "svn cp" und eine Neue oder Kopie ohne History "cp ; svn add". Fertig

Zum Vergleich die entsprechende Ausgabe des svn, wie ich sie vom git erwarten würde

svn log https://svn.boxmatrix.info/freetz-ng/trunk/make/linux/patches/2.6.32.61/4020_06.50/011-perl_5.22_invalid_syntax.patch
------------------------------------------------------------------------
r16933 | fda77 | 2020-07-15 15:48:34 +0200 (Mi, 15. Jul 2020) | 3 Zeilen

kernel: split 011-perl_5.22_invalid_syntax.patch.patch
                                                                     ​
commit b7335973dc4ebc5bf58ab4114cb84dced930351b -- https://github.com/freetz-ng/freetz-ng/commit/b7335973d
------------------------------------------------------------------------
r13360 | er13 | 2015-08-15 19:59:36 +0200 (Sa, 15. Aug 2015) | 4 Zeilen

kernel-2.6.28/2.6.32:
 * fix build problems with perl versions >= 5.22
 * fixes #2759

------------------------------------------------------------------------

Ist zwar schön dass git AI hat, man müsste die aber steuern können und sollte nicht machen was sie will. Interessant ist übrigens dass die svn und git Commits je eine andere Datei als "verschoben" erkennen und markierten Wobei verschieben/umbenennen noch so ein Schwachpunkt von git ist. Änderst du zuviel, ist die History auch futsch. Jaja, wenn man es weiss, kann man das in 2 commits machen... aber das ist nicht Sinn der Sache. Bei svn ist das durch "svn mv" keine Frage. Kommt bei git bestimmt auch noch irgendwann :)

[PeterPawn]

Wie du siehst, ist es überflüssig kompliziert bei git

Ne, sehe ich irgendwie gar nicht. Ein einzelnes Kommando (wenn ich es mir nicht - als "erlernte Aktion" vor längerer Zeit - selbst unnötig schwer gemacht hätte) war ausreichend, um die von Dir gewünschte Information zu finden - das steht dann hier: https://github.com/PeterPawn/YourFritz/issues/34#issuecomment-664726957

Was daran dann - in Deinen Augen - "kompliziert" ist, braucht schon eine Begründung und nicht nur die Behauptung.

Irgendwie habe ich beim Lesen von diesem hier: https://github.com/PeterPawn/YourFritz/issues/34#issuecomment-664629201 auch nicht den Eindruck, daß Du überhaupt erwartet hast, daß das so leicht machbar wäre (womit ich mal annehme, daß Du auch genau das ausdrücken wolltest) - ansonsten ist ja der Hinweis auf Trac nur sehr schwer zu erklären (jedenfalls plausibel), ebenso wie der Text:

Falls du es nicht herausfindest darfst du

---

Du bist halt immer noch im "alten Denken" beim Umgang mit VCS verhaftet ... man sieht es nun mal auch (sieh das meinetwegen auch als "Flamen" oder nicht) an Deinen Commits. Das ist immer noch so, als wenn Du das ausschließlich für Dich selbst machst oder bei Änderungen (genauso wie andere auch) davon ausgehst, daß Du irgendwie "unfehlbar" wärst und sich das niemand außer Dir ansehen müßte oder sollte und wenn sich doch jemand erdreistet, machst Du es ihm so schwer wie es nur geht.

Nimm nur mal diesen Commit als Beispiel: https://github.com/Freetz-NG/freetz-ng/commit/fc94d9b5a49656fabedd77b4408c01ac9c20b3ca - da kann sich jetzt jemand, der die Änderungen in Deinem Fork tatsächlich überprüfen will (denn auch Vertrauen muß man sich erst mal verdienen), ein Ei auf diesen Commit braten und ihm bleibt gar nichts weiter als zu raten, warum jetzt auf einmal noch das "static" erforderlich ist, obwohl das bei ihm doch bisher auch ganz ordentlich übersetzt wurde.

Und da es hier ja um das Tool für's Target geht, sollte es sogar egal sein, welche GCC-Version man auf seinem Build-Host einsetzt (womit das auch keine Folge Deines neuen Debian-Systems sein sollte - selbst das sollte man aber im Commit vermerken, wenn es so wäre).

Wenn Du also zu der Feststellung gelangt sein solltest, daß mit irgendeinem Compiler ein Problem besteht, wenn man diese Funktion nicht explizit als "static" kennzeichnet, dann sollte das auch mindestens im Kommentar des Commits irgendwie ersichtlich sein, DAMIT man da nicht erst raten oder sogar selbst suchen muß - zumindest dann, wenn so ein Commit tatsächlich "Lösung" und nicht "Problem" sein will.

Wenn ich erst alle Änderungen in einem Commit ansehen und verstehen muß, um zu entscheiden, WELCHES Problem er konkret löst (und ein "fix something" ist eben KEINE Beschreibung, nicht mal, wenn die geänderten Dateien noch benannt werden), dann bin ich nun mal schneller, wenn ich das gleich selbst in Angriff nehme, sofern ich auf dieses Problem gestoßen bin (nachdem dieser Patch in einem anderen Fork schon vorhanden war).

---

Das ist ein weiterer Grund, warum ich keinesfalls auf Freetz-NG wechseln kann oder werde - es ist einfach zu anstrengend, da den Überblick zu behalten und "blindes Vertrauen" bringe ich da niemandem entgegen (auch nicht Freetz/freetz). Nur kann man beim Upstream i.d.R. deutlich einfacher nachvollziehen, was, wann und warum geändert wurde.

Bei Freetz-NG habe ich das auch mal über einige Tage (bzw. bei den ganzen Commits am Beginn) versucht und sehr schnell aufgegeben - was eigentlich nicht meine Art ist. Aber wenn ich mir die "Qualität" der Commits (gerade auch direkt in den "master"-Branch) so ansehe, hat sich an dieser Stelle nur sehr wenig verbessert. Inhaltlich mag das häufig OK sein, aber von den Informationen im Commit her ist das nichts.

Wobei Du ja mal spaßeshalber die "revert"-Kommentare in Freetz-NG zählen lassen kannst: git log --author=fda77 --grep="[Rr]evert" - das ist es, was ich irgendwoanders als die "Kehrseite" Deiner vielen Änderungen bezeichnet habe - nicht direkt ein Vorwurf, weil nur der nichts falsch machen kann, der gar nichts tut. Aber schon ein Merkmal für "sorgfältiges Arbeiten" - und wenn man solche Dinge erst in einem Feature-Branch "reifen" läßt, kann man die Commits in den Master-Branch auch auf das tatsächlich notwendige Maß beschränken. Das reduziert dann auch gleich wieder die Anzahl der Commits, die andere lesen müssen, wenn sie auf dem Laufenden bleiben wollen. Man muß nicht jede Flatulenz gleich in einen Commit im Haupt-Branch (den andere auch nutzen können sollen) verwandeln.

So, wie in Freetz/freetz das irgendwann auf eine Autokratie hinausgelaufen ist, so gewinnt man bei Deinen Commits mit jedem weiteren, den man liest, den Eindruck, daß es Dir herzlich egal ist, ob andere diese Änderungen (leicht) nachvollziehen können oder nicht. Das mag dann zwar für diejenigen, die da ohnehin nicht durchsteigen können und/oder wollen, eine akzeptable Alternative sein - für jemanden, der da den Durchblick erlangen oder behalten möchte, ist das nur anstrengend.

[fda77]

Wegen solcher Mängel ist git halt für mich noch kein richtiger Nachfolger, sondern erst auf dem Weg dorthin. Es fehlen einfach Dinge die man mit anderen VCSs möglich sind. Ich geh davon aus dass das aber irgendwann noch wird. Bis dahin soll jeder nutzen was er will.

Und da es hier ja um das Tool für's Target geht, sollte es sogar egal sein, welche GCC-Version man auf seinem Build-Host einsetzt

Evtl hat sich die gcc Version fürs Target geändert? Es gab da doch vor kurzem einen Branch .. ah, an dem Tag als du herumflamtest dass es nie Branches gäbe :-D

Da ich mir nicht so ganz sicher bin ob die Kommentar überhaupt von jemandem gelesen werden steck ich da nicht viel Zeit rein. So Sachen wie das überflüssige & revertete "true" hätten auch sonst jemandem schon früher auffallen können. Ermittel doch mal die Reverts pro Commit, und definier dann ne Kennzahl und zugehörige Warnschwelle . Evtl noch Mittelwerte pro Woche/Monat etc.

Ich find es manchmal besser wenn 1 Problem mehreren Commits hat, zb https://github.com/Freetz-NG/freetz-ng/commit/b1324c403fa478734fd648f39754d6ec2b77dab7 und https://github.com/Freetz-NG/freetz-ng/commit/0147f14989f46b128d797c871b9e4843d26f1236

[PeterPawn]

Wegen solcher Mängel ist git halt für mich noch kein richtiger Nachfolger, sondern erst auf dem Weg dorthin.

Welche Mängel denn? Welchen Mangel denkst Du denn aufgezeigt zu haben? Die einzige "Frage", die hier von Dir gestellt wurde, war die nach dem originalen Autoren des Perl-Patches, nachdem Du den mehrfach dupliziert hast - und die läßt sich mit einem Kommando klären, wie ich Dir (wenn auch erst im zweiten Anlauf) gezeigt habe.

Ist es da nicht eher "mein Mangel", wenn ich es im ersten Anlauf noch viel zu kompliziert gemacht habe, weil ich das bisher so kannte? Was kann das "git" dafür?

steck ich da nicht viel Zeit rein.

Dann darfst Du Dich halt auch nicht wundern, wenn niemand Lust hat, sich diese Änderungen anzusehen und daher dann auch mal ein paar sinnvolle Anpassungen der Aufmerksamkeit von anderen entgehen.

Du kannst jedenfalls nicht erwarten, daß sich irgendwer mit Deinem Fork befaßt und ggf. sogar dessen Benutzern im IPPF (oder anderswo) hilft (so Du es nicht selbst machst), wenn der Aufwand, um da auf dem Laufenden zu bleiben, überproportional hoch ist und das sogar noch ohne jede Notwendigkeit.

Wie schon geschrieben - wer sich für die Änderungen gar nicht interessiert, der kann sicherlich auch mit dieser Form der Commits leben ... nur hast Du dann eben mit Deinem Fork auch genau diese Gruppe von Benutzern, für die das nur "irgendwie funktionieren" soll und dann mußt Du Dich auch nicht wundern, wenn von denen im Falle eines Fehlers nur sehr unpräzise Beschreibungen und wenig Unterstützung bei der Beseitigung eines Problems "angeboten" werden.

Wer eher wissen will, was da tatsächlich geändert wurde, der muß entweder so viel Zeit da hineinstecken, wie Du das offenbar selbst machst oder er kann gar nicht wirklich über den jeweils aktuellen Stand informiert sein ... und irgendwann will man es auch einfach nicht mehr, weil das, was Du da Deinerseits vielleicht an "Zeit" sparst, dann eben bei anderen (und da ja dann deutlich auch mehrfach) anfällt.

Wer da tatsächlich dieselbe Zeit investieren kann oder auch nur will, der kann das dann auch gleich noch alles selbst machen ... und hat dabei dann auch noch den Vorteil, daß das alles im Ergebnis auch so aussieht, wie er selbst sich das vorstellt (denn er wird sicherlich nicht gegen seine eigenen "Vorlieben" arbeiten).

Wenn so viel Arbeit dann tatsächlich noch zu nachnutzbaren Ergebnissen jenseits der oben skizzierten Gruppe der "Hauptsache, es funktioniert"-Benutzer führen soll (wenn nicht, hat man/hast Du ja Dein Publikum schon gefunden), dann macht das eben nur Sinn, wenn diese Leser und/oder Nachnutzer weniger Aufwand betreiben müssen und Dein vorheriger Einsatz bei ihnen zu einer Einsparung (an Zeit) führt.

---

Wie man's auch dreht und wendet ... mit einem "Community-Projekt", in dem Leute tatsächlich zusammenarbeiten und sich Aufgaben und Verantwortung teilen, hat das - zumindest in meinen Augen - nichts zu tun.

Evtl hat sich die gcc Version fürs Target geändert?

Und das muß der "Leser" dieses Commits dann erraten, für welche GCC-Version das am Ende wichtig war?

Zumal ich nirgends ein Anzeichen dafür entdecken kann, daß das tatsächlich aus dem erwähnten Branch irgendwie nach "master" gemischt wurde (wenn das eine Änderung war, die durch den neuen Kernel und den dafür zu verwendenden neuen GCC erforderlich wurde) - ja, ich kann im ganzen Commit-Log nicht einen Hinweis darauf finden, daß es JEMALS einen Branch "kernel49" gegeben hat, geschweige denn, was da enthalten war und (natürlich nach gründlichen Tests, die man eben auch anhand so eines Feature-Branches schon problemlos machen kann, wenn man sich (als Nutzer) darauf einlassen will) dann irgendwann mal in den "master" gemischt wurde.

---

Da solltest Du vielleicht noch einmal nacharbeiten, was man unter einem Feature-Branch versteht, warum man den macht oder machen sollte und wann man den dann tatsächlich in den "Hauptentwicklungszweig" integriert. Da gibt es viele Quellen im Internet und wenn man nicht einfach davon ausgeht, daß die alle ohnehin keine Ahnung haben (wo ihnen ja die fehlenden Funktionen von SVN in Git nicht mal auffallen), dann kann man da auch mal einen Blick riskieren.

So, wie man bei einem neuen Gerät oder Werkzeug auch erst mal erkunden sollte, wie das genau funktioniert, so sollte man auch mit seinem VCS/SCM (oder wie auch immer man es nennen will) umgehen und die Annahme, man könne das alles schon irgendwie "on the job" erlernen und würde die Funktionen dabei schon automatisch erkennen, hat sich (so macht es zumindest den Anschein) bei Dir ja schon im Hinblick auf die Möglichkeiten des git log-Unterkommandos nicht erfüllt.

Ich will Dir auch nicht zu nahe treten (will ich wirklich nicht), aber beim Betrachten der Commits in Freetz-NG gewinnt man den Eindruck, daß die einzige Strategie im Umgang mit "fremden Forks" und deren Branches, die Du kennst/verwendest/beherrschst, das "cherry-pick" ist - da gibt es aber noch so viele andere Möglichkeiten, daß manch gestandener Git-Benutzer die nicht alle kennt.

Hier lag dann auch die Quelle meines Irrtums bei den SquashFS-Tools ... denn nach diesem Commit: https://github.com/Freetz-NG/freetz-ng/commit/86c23d96d76585825fa81b5cb29105e9d2ad6654 mußte ich erst mal annehmen (angesichts des Kommentars und angesichts der "Author"-Angabe), daß Du die Änderungen tatsächlich von meinem Fork genommen hättest und nicht vom Freetz/freetz-Master.

Und das Prinzip dabei ist auch bei allen "Anbietern" (von GitHub über Gitlabs bis hin zu Atlassian mit Bitbucket) dasselbe, weil es sich hier um "Arbeitsweisen" handelt und nicht um Fragen einer bestimmten Plattform. Sogar bei der Betrachtung der "best practices" bei SVN (https://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html) wird ausdrücklich festgehalten, daß dieses "never-branch system" (was bisher in Freetz-NG zu sehen war und ist und die eine Ausnahme mit dem "kernel49"-Branch darf man da problemlos in den Skat drücken, weil das offensichtlich gar kein "echter Branch" war, wenn es nicht mal ein "merge" für die dort enthaltenen Commits im Log gibt) zwar auch Vorteile hat, aber eben auch deutliche Nachteile (das sind zufälligerweise auch noch die, die ich meinerseits in meinem angeblichen "flame" angesprochen hatte):

Pros: Very easy policy to follow. New developers have low barrier to entry. Nobody needs to learn how to branch or merge. Cons: Chaotic development, code could be unstable at any time.

Die "pros" sind bei Git praktisch ohne jegliche Bedeutung ... es hat ohnehin jeder sein eigenes Repo mit eigenen Schreibrechten und es gibt praktisch keine "policy", die irgendwie zu befolgen wäre, wenn es um Commits geht. Bei Git ist das "branch and merge" bereits in der DNA angelegt - es ist also auch nicht schwierig "zu erlernen" (man muß den Sinn nur verstehen).

Die "cons" kann man aber auch unter Git dann problemlos weiter besichtigen - und hier kann man sich eben nicht länger darauf herausreden, daß die Werkzeuge für die Arbeit mit Branches fehlen oder nur schwer zu nutzen sind.

[PeterPawn]

Weil ich tatsächlich gerade den letzten Commit in Deinem Freetz-NG gesehen habe ... den als "fix typo" zu kommentieren, ist ja irgendwo auch witzig (weil ich nach Deinem Vorschlag ja die "reverts" zählen sollte - zu der von mir gemeinten Kategorie von Problemen gehören solche Fehler wie dieser aber auch dazu).

Denn das ist nun mal kein einfacher "Tippfehler", wo vielleicht mal ein Kommentar oder eine ausgegebene Nachricht nicht stimmt - das ist ein kapitaler Syntax-Error im "test"-Kommando (die eckigen Klammern sind ja nur ein Synonym). Ob man einen C&P-Fehler (denn das wird eher ein solcher gewesen sein, weil es nur schwer nachvollziehbar ist, warum da jemand ein zusätzliches "oder" für eine weitere Bedingung eintippen sollte, wenn es nicht benötigt wird, während das Kopieren von den vorhergehenden Bedingungen mit Änderung der geprüften Datei ja logisch erschiene) jetzt als "typo" wertet oder nicht, ist vielleicht aber auch nur eine Frage des Standpunkts.

Aber da stellt man sich eben unwillkürlich die Frage, ob das bei den Änderungen am 24.02.2020 (https://github.com/Freetz-NG/freetz-ng/commit/30f57ed82f1d366cd438158db73c958634488647) überhaupt irgendwie getestet war, was da für die Puma7-Modelle geändert wurde - dafür würde man die Box ja noch gar nicht benötigen.

Es gibt/gab jedenfalls (soweit ich das sehe) gar keinen Weg bei einem Image für ein solches Gerät, auf dem man nicht an diesem Test vorbeigekommen wäre und damit die Fehlermeldung der "bash" hinsichtlich Zeile 329 an dieser Stelle auch hätte sehen müssen:

peh@vidar:/tmp/fng> tools/push_firmware images/6591_07.19.ger-rev75516_labor_freetz-ng-16995-1c7883517_20200729-190525.image

 * Analyzing 'images/6591_07.19.ger-rev75516_labor_freetz-ng-16995-1c7883517_20200729-190525.image' ...
tools/push_firmware: line 329: [: argument expected

 * Using command: ftp
 * Target host: 192.168.178.1
 * Outgoing IP: 192.168.178.2
 * Flash mode: uimg-boot
 * Designated linux_fs_start: 1

 !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!
 !!!  THERE IS NO WARRANTY AT ALL !!! USE AT YOUR OWN RISK   !!!

 * Are you sure, that you want to flash this file to the device?
   images/6591_07.19.ger-rev75516_labor_freetz-ng-16995-1c7883517_20200729-190525.image
   Proceed? (y/[n]) n

aborted

peh@vidar:/tmp/fng>

Und damit illustriert das am Ende eben auch eines der "cons", die ich oben für "never-branch" ja auch nur zitiert habe (daher greife ich das hier auch nur noch einmal auf) - es ist bei dieser Arbeitsweise sehr leicht möglich, einen nicht-funktionierenden Stand im "master"-Branch zu haben und wenn das hier nur dazu führte, daß der Test nicht erfolgt und damit die Fehlerbedingung nicht erkannt wird, ist das auch eher in die Kategorie "Glück" einzuordnen.

Jedenfalls kann ich das Tool (für die Zeit vom 24.02.2020 bis heute) auch problemlos "überlisten":

peh@vidar:/tmp/fng> touch ./firmware-update.uimg; tar cf images/test.image ./firmware-update.uimg
peh@vidar:/tmp/fng> tar tvf images/test.image
-rw-r--r-- peh/users         0 2020-07-29 19:16 ./firmware-update.uimg
peh@vidar:/tmp/fng> tools/push_firmware images/test.image

 * Analyzing 'images/test.image' ...
tools/push_firmware: line 329: [: argument expected

 * Using command: ftp
 * Target host: 192.168.178.1
 * Outgoing IP: 192.168.178.2
 * Flash mode: uimg-boot
 * Designated linux_fs_start: 1

 !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!
 !!!  THERE IS NO WARRANTY AT ALL !!! USE AT YOUR OWN RISK   !!!

 * Are you sure, that you want to flash this file to the device?
   images/test.image
   Proceed? (y/[n]) n

aborted

peh@vidar:/tmp/fng>

und wenn man so etwas "ungetestet" eincheckt, dann sollte man das dem Benutzer m.E. auch mitteilen. Die Tatsache, daß die gesamte Unterstützung für Puma7 auf "experimentell" steht, entlastet nicht hinsichtlich des "push_firmware" - außer man wollte unterstellen, daß ansonsten tatsächlich nach solchen Änderungen alle bisher vorhandenen Funktionen noch einmal einem Regressionstest unterzogen wurden oder zumindest bei irgendwelchen Benutzern ihre Tauglichkeit unter Beweis gestellt haben.

[fda77]

Leute die nur "clone" von git verwendet und zum updaten das Verzeichnis löschen und nochmal neu auschecken werden diese Problem nicht auffallen. Ich suche manchmal nach älterne Dingen, da braucht man halt ne richtige Historie. Da ist das svn mit Trac besser. Kannst du drehen und wenden wie du willst.

Dass github keine Infos über Branches anzeigt ist nicht meine Schuld. Oben steht ein Link zu einer anderen git-Platform die das macht. Für einen merge ist kein (zusätzlicher) merge-commit nötig. Wie du dich bestimmt erinnerst konnte der 7590kernel eh nicht mehr mit dem trunk gebaut werden, da eine config-Änderung dem Compiler nicht gefiel - war also eh kaputt

Da sich in den letzten 1,5 Jahren an der Beteiligung bei ng noch nicht so viel getan hat, finde ich es so wie es ist okay. Kann man ja Ändern sobald es dafür einen Anlass gibt. Auch die Art des committens. Aber selbst du schriebst ja die ganze Zeit dass du dich damit nicht wirklich beschäftigst

typo kommt von Typographie, also nicht Tippfehler sondern Satzfehler. Zum vereinfachen wurden nicht nur einzelne Buchstaben genommen, sondern öfter vorkommende Zeichenfolgen als Blöcke zusammengefasst ("sch"), und so einen Block hatte ich zuviel kopiert. Das wurde auch schon von jemandem im DEB getestet (es gab anfangs ne extra Warnmeldung davor). Dass irgendwelche Warnmeldungen/Fehler übersehen werden ist da gut möglich. Ich kann mich da nur auf Aussagen anderer verlassen

[PeterPawn]

typo kommt von Typographie, also nicht Tippfehler sondern Satzfehler.

Gut, da hast Du also Deine eigene Definition und/oder Übersetzung (denn das soll ja sicherlich Englisch sein im Kommentar).

Andere sehen das anders:

https://de.wikipedia.org/wiki/Typo https://www.dict.cc/?s=typo

Ich finde da die Definition "Satzfehler" nicht wirklich - und auch "Druckfehler" dürfte außerhalb der Druckbranche (Buch- oder anderer Druck) eher ungebräuchlich sein.

Aber selbst du schriebst ja die ganze Zeit dass du dich damit nicht wirklich beschäftigst

Das ist richtig ... aber ich begründe eben auch, warum das so ist/war. Mag ja sein, daß ich immer noch in der Frage von hier: https://github.com/PeterPawn/YourFritz/commit/385457d88a0c34df15634db108c39c987d15d2bf#commitcomment-40535555 gefangen bin - immerhin wolltest Du ja wissen, woran ich meine Kritik und meine Bedenken festmache.

Da ist das svn mit Trac besser. Kannst du drehen und wenden wie du willst.

Schon da vermischst Du ja Äpfel mit Birnen. Das VCS ist SVN und die Oberfläche darüber (wenn man denn eine braucht - die haben logischerweise immer ihre Beschränkungen ggü. der Kommandozeile - oder wie machst Du in Trac das von Dir gewünschte "svn cp"?) ist dann Trac (wo es auch Alternativen gäbe). Obendrein kann man sogar ein Trac über ein Git-Repository aufsetzen.

Da mußt Du Dich also mal entscheiden, was Du eigentlich als "mangelhaft" ansiehst ... es mag ja sogar richtig sein, daß die Oberfläche von GitHub andere Funktionen anbietet, als Du es von Trac oder anderen Plattformen gewohnt bist.

Nur hat das per se auch wieder mit der Frage "Git vs. SVN" nichts zu tun ... es gibt dafür in GitHub wieder Funktionen, die im "git" nicht realisiert sind (und in SVN auch nicht, bevor Du das wieder als Bestätigung empfindest) - so gibt es die "Pull Request" eben in derart "organisierter Form" in "git-scm" nicht; da kann man dann höchstens noch eine E-Mail mit den Änderungen generieren, wenn man die an jemand anderen weitergeben will, der nicht seinerseits einfach ein "git pull " für einen "fremden" Branch machen kann (oder wiill).

Und wieder andere Funktionen (und fehlende GUI-Möglichkeiten) gibt es bei Bitbucket und noch einmal andere Schwerpunkte setzt GitLab. Allen gemeinsam ist aber das "git" als Basis, auch wenn es manchmal Konnektoren zu anderen VCS gibt oder auch Tools zum Umstieg von anderen VCS auf Git.

Und mich interessiert auch überhaupt nicht, ob GitHub mir einen (früher existierenden) Branch anzeigt oder nicht ... wenn ich Dein Repo ganz normal auschecke und dort einen Blick ins Log werfe (mit "git log" und "grep"), finde ich keinen Hinweis auf den (mittlerweile nicht mehr existenten) Branch "kernel49" und das ist (wenn man tatsächlich mit Feature-Branches arbeitet und sich mehr als ein Einzelner damit auch "auskennen" soll) nun mal ein "no-go" - und wenn das irgendeine Plattform bei Deinem Repo noch darstellen kann, ist das zwar auch wieder "praktisch", hat aber mit der Idee von den verteilten Repos (wo die Kopie dann eben denselben Stand wie ihre Quelle haben soll) absolut nichts mehr zu tun.

Denn auch Deiner Feststellung:

Für einen merge ist kein (zusätzlicher) merge-commit nötig.

würde wohl jeder, der tatsächlich mit Feature-Branches arbeitet, heftig widersprechen. Zwar stimmt diese Aussage hinsichtlich der Tatsache, daß es auch ohne möglich ist - aber das ist eindeutig "bad practice", denn genau so ein "merge commit" dient dann im Log zur Markierung der Stelle, an der ein Feature-Branch in den Entwicklerzweig Einzug gehalten hat.

Außerdem gibt es - für die, die solche Commits nicht sehen wollen im Log - dann auch wieder die Optionen, sie auszublenden oder sogar, nur diese anzuzeigen (eben damit man die leichter findet) - mit den Optionen --no-merges bzw. --merges.

Ohne solche Commits kann bei mehreren Leuten niemand mehr erkennen, woher irgendwelche Änderungen überhaupt kamen (auch Entwickler B kann ja Commits von Entwickler A in seinem Feature-Branch haben und wenn B jetzt seinen Branch mit dem Entwickler-Zweig mischt, fließen da genauso die Commits von A ein) und wer da wann irgendwelche Feature-Branches zusammengemischt hat.

Bestes Beispiel für "irreführende Commits" ist wieder der oben schon verlinkte https://github.com/Freetz-NG/freetz-ng/commit/86c23d96d76585825fa81b5cb29105e9d2ad6654 - nur kann für dieses Manko weder Git noch GitHub. Da wurden eben die Tools falsch verwendet.

Wobei Du Dich auch nicht immer so richtig entscheiden kannst, ob es nun einen Commit für das "merge" gibt oder nicht (auch ein "cherry-pick" ist am Ende ja ein "merge") - hier gibt es entsprechende Commits nach dem Merge von Freetz (https://github.com/Freetz-NG/freetz-ng/commit/12547f8cdb2a36eb65334490cd77edad3b69cf18) oder auch YourFreetz (https://github.com/Freetz-NG/freetz-ng/commit/677e76f74d786a3649c9c1efd8ef8ca9232f3007).

Welchen Unterschied macht es denn in Deinen Augen, ob das ein "externer" Branch war oder einer aus dem eigenen Repository? Funktionell (in einem "Workflow") sind die eigentlich gleichwertig - nur kriegt man sie für einen fremden Branch tatsächlich nur dann "weg", wenn man extra mit "rebase" (bzw. der entsprechenden Option beim "pull") arbeitet.

Nur braucht es eben auch genau diesen "merge commit", wenn man für einen Commit sowohl den Autoren (aus dem Commit selbst), als auch denjenigen, der ihn "merged" hat, ermitteln will ... dann braucht es nämlich den "merge commit" mit mehr als einem "parent", wo der fragliche Commit in einem der Pfad enthalten ist.

Eigentlich sollte es (bei richtiger Anwendung der Kommandos) gar nicht erforderlich sein, den Kommentar des originalen Autoren in einem Commit zu ändern - so wie man das hier (https://github.com/Freetz-NG/freetz-ng/commit/761e1923f9d410b639c1535278f188c698b3653a) oder auch hier (https://github.com/Freetz-NG/freetz-ng/commit/86c23d96d76585825fa81b5cb29105e9d2ad6654) sehen kann. In diesen Fällen wäre es sogar sehr unangebracht, auf den Merge-Commit zu verzichten (oder ihn später zu entfernen bei einem "rebase"), weil dann gar nicht mehr zu erkennen wäre, wer diese Änderung (am Kommentar) überhaupt vorgenommen hat.

Der richtige Platz für solche "Feststellungen" durch denjenigen, der fremde Commits irgendwo mischt, wäre eben genau der "merge commit" (der Witz an diesem ist ja nicht der enthaltene Kommentar, sondern die Tatsache, daß es (mind.) zwei "parents" gibt) - denn dieser stammt vom ihm selbst und den kann er sogar wieder selbst signieren, etc. ... so eine Änderung am Kommentar macht jedenfalls auch jede Signatur durch den Autoren kaputt, wie man deutlich am Unterschied in der Darstellung der Commits zwischen Freetz-NG und Freetz feststellen kann, z.B. für diesen Commit: https://github.com/Freetz/freetz/commit/d63572ab6a96b5884774166352979c7feec563fb vs. https://github.com/Freetz-NG/freetz-ng/commit/e311bb1257ee180c90579b3947f9200f11d62a1f (ich hätte ja gerne Commits von jemand anderem genommen, finde aber auf den ersten zwei Seiten keinen passenden bei Freetz-NG).

Es ist natürlich Deine Entscheidung, wenn Du auf ewig "Einzelkämpfer" bleiben willst - ich will/wollte Dir nur aufzeigen, wo Du - absichtlich oder auch unabsichtlich, ich kann das nicht wirklich einschätzen - potentiellen Mitstreitern vollkommen unnötige Steine (oder fast Felsen) in den Weg legst.

[fda77]

Nun, ich nutze nunmal templates für IFs, in dem Fall halt 4x, wo dann jedes mit "-o" endet. Beim letzten hab ichs halt vergessen zu löschen. Ist jetzt nichts worüber es sich viel zu schreiben lohnt. Das trifft auf git vs svn auch zu. Ich hab im Trac übrigens auch diverse Git repos, so kann ich mit 1 Oberfläche vieles anzeigenlassen. Die Github Oberfläche find ich nicht so prima, allein weil Quelltext auf 30% der Bildschirmbreite begrenz wird und man sinnlos herumscrollen (mit nicht vorhandenem Scrollbalken) muss.

Wenn du dich auskennen willst lies doch mal auf https://freetz-ng.github.io mindestens NEWS. Das hab ich dir ja schon öfter nahegelegt. Da findest du auch was zu Branches...

Das mit https://github.com/Freetz-NG/freetz-ng/commit/86c23d96d76585825fa81b5cb29105e9d2ad6654 versteh ich nicht, wenn der irreführend ist, ist das den Problem. Du bist der Author :D

Dass ein pick einen neuen hash bekommt und damit die Signatur verliert ist doch normal, oder kennst du einen Weg?

Die merge-commits nach picks finde ich praktisch für die Übersichtlichkeit, sind aber überflüssig. Kann man bestimmt ausblenden. Oder nimm das svn, dort sind die nicht zu sehen ;-)

Wäre übrigens ganz gut wenn du Kommentar zu gewissen Commits zu den Commits schriebst, zb das mit "ldd" oder "true"

[PeterPawn]

Wenn du dich auskennen willst [...] findest du auch was zu Branches...

Das mache ich tatsächlich ab und an ... aber welchen Wert haben diese "NEWS" denn, wenn - wie gerade jetzt - die letzte dort vom 20.07.2020 ist (also mittlerweile zehn Tage alt), während es seitdem doch trotzdem jede Menge Commits gab:

peh@vidar:~> cd /tmp/
peh@vidar:/tmp> rm -rf fng
peh@vidar:/tmp> git clone https://github.com/Freetz-NG/freetz-ng.git fng
Cloning into 'fng'...
remote: Enumerating objects: 40, done.
remote: Counting objects: 100% (40/40), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 166769 (delta 16), reused 24 (delta 9), pack-reused 166729
Receiving objects: 100% (166769/166769), 61.67 MiB | 5.72 MiB/s, done.
Resolving deltas: 100% (113985/113985), done.
Updating files: 100% (7326/7326), done.
peh@vidar:/tmp> cd fng
peh@vidar:/tmp/fng> git log --since=2020-07-19 --oneline --no-merges | wc -l
42
peh@vidar:/tmp/fng>

Es gab also seitdem 42 Commits, die nicht nur "merges" waren - diese Datei KANN offensichtlich also den Blick in die Commits nicht ersetzen, wenn man wissen will, was sich geändert hat. Und selbst wenn man in den letzten 10 Tagen diese Datei auf seinem "täglichen Rundgang" angesehen hätte - man wäre so schlau wie zuvor, was die Änderungen in Freetz-NG anbelangt.

Das mit [...] versteh ich nicht

So, wie Du den übernommen hast, wird (a) YourFreetz als Quelle angezeigt und (b) "erzählt", es handele sich um einen "cherry-pick" (in Deiner Hinzufügung zum Kommentar, weil Du offenbar die Option -x beim git cherry-pick verwendest).

Sieh Dir einfach mal an, was man gemeinhin mit einem "cherry pick" macht: https://www.google.com/search?q=what+is+cherry-pick+in+git und dann verstehst Du sicherlich auch, warum ich anhand dieses Commits zu der Ansicht gekommen war, Du hättest diese Änderungen direkt per "cherry-pick" aus meinem Fork und dem Branch dort übernommen.

Das war dann auch der Anlaß für mich, Dich auf die "neue Version" als bessere Alternative hinzuweisen (was Dich so verwunderte und wie sich jetzt herausgestellt hat, zu Recht), weil ich gar nicht erkennen konnte, daß Du diese Änderungen tatsächlich aus Freetz übernommen hast, wie Du dann hier: https://github.com/Freetz-NG/freetz-ng/commit/761e1923f9d410b639c1535278f188c698b3653a#commitcomment-40942661 geschrieben hast.

Dass ein pick einen neuen hash bekommt und damit die Signatur verliert ist doch normal, oder kennst du einen Weg?

Natürlich geht das auch anders ...

peh@vidar:/tmp> git clone https://github.com/Freetz-NG/freetz-ng.git fng
Cloning into 'fng'...
remote: Enumerating objects: 40, done.
remote: Counting objects: 100% (40/40), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 166769 (delta 16), reused 24 (delta 9), pack-reused 166729
Receiving objects: 100% (166769/166769), 61.67 MiB | 11.27 MiB/s, done.
Resolving deltas: 100% (113985/113985), done.
Updating files: 100% (7326/7326), done.
peh@vidar:/tmp> cd fng
peh@vidar:/tmp/fng> git config --local --add user.name somebody
peh@vidar:/tmp/fng> git config --local --add user.email somebody@nowhere.info
peh@vidar:/tmp/fng> git remote add -f freetz https://github.com/Freetz/freetz.git
Updating freetz
remote: Enumerating objects: 2162, done.
remote: Counting objects: 100% (2162/2162), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 4009 (delta 2156), reused 2157 (delta 2156), pack-reused 1847
Receiving objects: 100% (4009/4009), 3.23 MiB | 4.92 MiB/s, done.
Resolving deltas: 100% (2833/2833), completed with 999 local objects.
From https://github.com/Freetz/freetz
 * [new branch]          ds24              -> freetz/ds24
 * [new branch]          ds26-stable-14    -> freetz/ds26-stable-14
 * [new branch]          ds26-stable-15    -> freetz/ds26-stable-15
 * [new branch]          freetz-stable-1.0 -> freetz/freetz-stable-1.0
 * [new branch]          freetz-stable-1.1 -> freetz/freetz-stable-1.1
 * [new branch]          freetz-stable-1.2 -> freetz/freetz-stable-1.2
 * [new branch]          freetz-stable-1.3 -> freetz/freetz-stable-1.3
 * [new branch]          freetz-stable-2.0 -> freetz/freetz-stable-2.0
 * [new branch]          master            -> freetz/master
 * [new tag]             freetz-1.0        -> freetz-1.0
peh@vidar:/tmp/fng> git config --local --list | cat
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.com/Freetz-NG/freetz-ng.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
user.name=somebody
user.email=somebody@nowhere.info
remote.freetz.url=https://github.com/Freetz/freetz.git
remote.freetz.fetch=+refs/heads/*:refs/remotes/freetz/*
peh@vidar:/tmp/fng> # Alles bis hier muß man nur ein einziges Mal vorbereiten für eine "Kopie" des eigenen Repos.

Hier muß ich jetzt aber tatsächlich auf ein anderes Repo als Quelle ausweichen, weil es bei Freetz praktisch nichts Signiertes gibt, was nicht entweder schon integriert wurde in Freetz-NG oder wo es zu viele Konflikte aufgrund vorheriger Änderungen gibt, als daß ich das jetzt zeigen wollte, Also nehme ich mein Repo (als zusätzliches "remote") und darin auch nur einen einzelnen Commit aus einem bestimmten Branch (das könnte auch "master" sein, das Prinzip bleibt dasselbe):

peh@vidar:/tmp/fng> git remote add -f yf https://github.com/PeterPawn/YourFreetz.git
Updating yf
remote: Enumerating objects: 644, done.
remote: Counting objects: 100% (644/644), done.
remote: Total 1012 (delta 644), reused 644 (delta 644), pack-reused 368
Receiving objects: 100% (1012/1012), 261.06 KiB | 777.00 KiB/s, done.
Resolving deltas: 100% (741/741), completed with 202 local objects.
From https://github.com/PeterPawn/YourFreetz
 * [new branch]          YourFritz                   -> yf/YourFritz
 * [new branch]          YourFritz_History           -> yf/YourFritz_History
 * [new branch]          bb_mount                    -> yf/bb_mount
 * [new branch]          collected_diffs_to_upstream -> yf/collected_diffs_to_upstream
 * [new branch]          description                 -> yf/description
 * [new branch]          dropbear                    -> yf/dropbear
 * [new branch]          master                      -> yf/master
 * [new branch]          mc                          -> yf/mc
 * [new branch]          ncurses                     -> yf/ncurses
 * [new branch]          squashfs-avm-strict         -> yf/squashfs-avm-strict
 * [new branch]          swapping_maybe_disabled     -> yf/swapping_maybe_disabled
peh@vidar:/tmp/fng> git log -n 1 --oneline yf/squashfs-avm-strict | cat
f40098998 magic.local: add libmagic definitions
peh@vidar:/tmp/fng> git cherry-pick f40098998
[master a7dc560be] magic.local: add libmagic definitions
 Author: YourFritz <git@yourfritz.de>
 Date: Sat Jul 25 00:34:04 2020 +0200
 1 file changed, 71 insertions(+)
 create mode 100644 tools/magic.local
peh@vidar:/tmp/fng> git commit --allow-empty -m "libmagic: cherry-picked from YourFreetz/squashfs-avm-strict"
[master d0bcb1626] libmagic: cherry-picked from YourFreetz/squashfs-avm-strict
peh@vidar:/tmp/fng> git log origin/master..  | cat
commit d0bcb1626c41715b1fca8f6d8bd18ae4a40edf19
Author: somebody <somebody@nowhere.info>
Date:   Fri Jul 31 00:46:57 2020 +0200

    libmagic: cherry-picked from YourFreetz/squashfs-avm-strict

commit a7dc560bed6376125b57aca10ec5537dcf62d4f7
Author: YourFritz <git@yourfritz.de>
Date:   Sat Jul 25 00:34:04 2020 +0200

    magic.local: add libmagic definitions

    for AVM's SquashFS images and for ext2 wrapper FS
peh@vidar:/tmp/fng>

Den eigenen Commit kann man jetzt auch problemlos noch signieren (wenn man die Infrastruktur dazu (auch einmalig) angelegt hat) und die Signatur des übernommenen Commits bleibt auch erhalten (die umfaßt ja nur den Kommentar und die Änderungen und nicht den Hash, der sich mit der Position in der Chain ja wieder ändert).

Im Moment kann man gerade in Freetz/freetz wieder ein schönes Beispiel für einen "unzureichenden" Commit sehen - offenbar wurde der wohl unter Verwendung des GitHub-GUI gemacht (vor zwei Tagen: https://github.com/Freetz/freetz/pull/302#event-3595506921) - aber eben ohne passenden "merge commit". Damit kann man in einem "normalen" Log jetzt auch nicht mehr sehen, wer diesen Commit veranlaßt hat:

peh@vidar:/tmp> git clone https://github.com/Freetz/freetz.git fup
Cloning into 'fup'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 144251 (delta 0), reused 0 (delta 0), pack-reused 144246
Receiving objects: 100% (144251/144251), 34.15 MiB | 9.89 MiB/s, done.
Resolving deltas: 100% (95913/95913), done.
peh@vidar:/tmp> cd fup
peh@vidar:/tmp/fup> git log -n 5 --pretty=short | cat
commit f4147ce9fefd12297a5c740f93ca1b15914122b1
Author: leggewie <leggewie@users.noreply.github.com>

    replace AWOL wehavemorefun.de links with archive.org backups (#302)

commit b300c32eaf89f8c7c3088e8982d79bddfb90c2a0
Author: Eugene Rudoy <gene.devel@gmail.com>

    davfs2: do not assume ftpuser always exists in AVM firmware, do explicitly create it

commit 1ec6822baf4dd2eebd6d2e4fd820f927a0677642
Author: Eugene Rudoy <gene.devel@gmail.com>

    rsync: do not assume ftpuser always exists in AVM firmware, do explicitly create it

commit 8d7ba9d0b9a44f737fd4408cef9fe67d8860270e
Author: Eugene Rudoy <gene.devel@gmail.com>

    Mbed TLS: bump version to 2.7.16

commit b949032562fa10ec7493d7a073b22369bacad406
Author: Eugene Rudoy <gene.devel@gmail.com>

    Avoid globally caching dl*-func related values
peh@vidar:/tmp/fup>

Ohne die Info in GitHub (die auch nur dort dann "recorded" ist) könnte man also (wg. des fehlenden "merge commits") gar nicht mehr feststellen, wer das nun eigentlich in den Freetz-Master übernommen hat.

Ich habe zwar bisher mit dem GUI nur ein paar wenige Merges (eher sehr wenige) gemacht - aber ich bin mir fast sicher, daß es dabei auch die Möglichkeit gibt, sich für einen "merge commit" zu entscheiden und wenn man erst mal verstanden hat, wofür der gut (und sogar "wichtig") ist, benutzt man den auch. Denn in einem Klon des Freetz-Repos fehlt diese Info dann komplett (siehe oben als "Demo") - weil sie eben nur in der zusätzlichen Infrastruktur von GitHub (bei der Verwaltung von Pull-Requests) aufgezeichnet wurde.

Aber ich werde das einfach noch mal bei mir ausprobieren, ob es das "Angebot" für den "merge commit" auch im GitHub-GUI gibt - damit ich da nicht doch noch falsch liege. EDIT: Gerade geprüft - auch mit dem GUI von GitHub kann man beim Merge einen passenden Commit erzeugen - und dann sollte man das auch tun, selbst wenn man "Einzelkämpfer" ist, weil es anderen die Aufgabe erleichtert, wenn sie feststellen wollen, wann irgendwelche "externen" Änderungen (aus einem Branch oder aus einem anderen Repo) Einzug gehalten haben.

[fda77]

Also das Unterdrücken des ursprünglichen Hashes beim pick erhält nicht die Signatur. Wobei ich einen Link zum alten Commit ganz gut finde! Ich hab hier gestestet: https://github.com/fda77/freetz-ng/commits/master Ein zusätzlicher leerer Commit je pick finde ich nicht so gut, die komplette url könnte man auch in den merge schreiben (hinter "Merge $branch" ist eh ne Variable) An meinen unterschiednlichen GPG ids erkennt man dass das wenigst über die Weboberfläche gemacht wurde

[PeterPawn]

Ein zusätzlicher leerer Commit je pick finde ich nicht so gut

Ist ja auch nicht notwendig ... beim git pick kann man (a) mehrere Commits angeben (nur beim Spezifizieren einer "Serie" muß man dann genauer hinsehen) und (b) den eigenen Merge-Commit ja auch erst dann machen, wenn alle "picks" abgehakt sind - die Rechnung "ein (gepickter) Commit == ein Merge-Commit" ist also gar nicht erforderlich.

Beim git cherry-pick funktioniert das Übernehmen der Signatur dann tatsächlich nicht - aber das liegt an der Art und Weise, wie das git cherry-pick arbeitet:

Given one or more existing commits, apply the change each one introduces, recording a new commit for each.

und nicht an den Signaturen per se, deren Format nebenbei bemerkt dann hier: https://github.com/git/git/blob/master/Documentation/technical/signature-format.txt beschrieben wäre.

Ich weiß jetzt tatsächlich nicht, ob die von mir signierten Commits, die dann "unversehrt" im Freetz-Log gelandet sind und dort weiterhin meine gültige Signatur tragen (und die gibt es ja zweifellos, wie man im Log leicht überprüfen kann), am Ende alle per GitHub-GUI übernommen wurden - andererseits landen von anderen signierte Commits ja auch in meinem Fork mit einer gültigen Signatur (vom originalen Autoren bzw. vom Mischen), wenn ich den mit dem Upstream synchronisiere ... und ich arbeite praktisch nur mit der Kommandozeilenversion von Git.

Theoretisch sollte es keinen Unterschied machen, ob ich jetzt den Upstream per git pull mit meinem Stand mische (außer daß beim "fast-forward" kein Merge-Commit erzeugt wird, wenn ich den nicht ausdrücklich anfordere) oder irgendeinen anderen Branch/Commit aus irgendeinem anderen Repo.

Ja, selbst beim Merge aus einem Branch im eigenen Repo wird eigentlich nur der Merge-Commit jeweils hinzugefügt - die Commits, die da beim Merge einbezogen wurden, bleiben ja unverändert, wie man in meinem "Hauptzweig" immer nachlesen kann, weil der aus dem Freetz-Master mit anschließendem Merge all meiner Branches besteht und da sind sowohl die Commits in den Branches, als auch die Merge-Commits signiert, weil ich das bei mir ohnehin als systemweiten Standard konfiguriert habe und es gesondert ansagen muß, wenn ich mal nicht signieren (lassen) will.

Eigentlich kann die Signatur ja auch den eigenen Hash nicht enthalten (wenn ich hinsichtlich der Abläufe jetzt nicht komplett daneben liege), denn der Hash ergibt sich ja erst, nachdem der Commit integriert wurde. Nach dem hier: https://github.com/git/git/blob/master/Documentation/technical/signature-format.txt#L6 wird der Payload "extrahiert", GPG zum Signieren vorgesetzt und diese Signatur dann in das Commit-Objekt mit eingebaut.

Zu diesem Zeitpunkt ist der Hash, der sich NACH dem Commit ergibt, noch nicht bekannt - durch das Einbetten der Signatur in das Objekt haben dann aber auch zwei identische signierte Commits, die zu unterschiedlichen Zeitpunkten erstellt wurden (selbst wenn man das Datum im Header mit --date setzt und ansonsten auch alles identisch wäre), am Ende unterschiedliche Hashes, weil die Signaturen unterschiedlich sind, denn diese enthalten ihrerseits den Zeitstempel vom Signieren.

Da die Arbeit mit git cherry-pick eben tatsächlich eher ungewöhnlich ist, wenn es um Zusammenarbeit an einem gemeinsamen Projekt geht (dann paßt meist etwas mit dem Rest der Arbeitsorganisation nicht, wenn das nur auf diese Weise möglich ist, Änderungen von anderer Stelle zu übernehmen), müßte ich auch erst mal nachdenken und auch nachlesen, was man da wohl besser verwendet.

Da aber beim Kirschen-Picken tatsächlich (siehe Zitat oben) immer ein neuer Commit erzeugt wird (deshalb wohl auch die Optionen dort, die Kommentare zu standardisieren), KANN das bei der Arbeit mit Signaturen (https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) nicht der einzige Weg sein. Ob allerdings die Organisation Deines Repos bzw. auch die des Freetz-Masters (auch da gibt es ja nur den einen Branch) am Ende alle anderen denkbaren Arbeitsweisen blockieren, weiß ich im Moment nicht so genau - denn ich bin ja nun auch kein Spezialist für Git, sondern nur ein Leser entsprechender Manuals (das aber i.d.R. sehr intensiv).

Nur sind bisher andere Repos von demselben Ursprung (also Freetz/freetz), die auch tatsächlich mit signierten Commits arbeiten und wo ich mal einen oder auch mehrere solcher Commits in meinen Fork als Test (in einem gesonderten Branch natürlich) übernehmen könnte, eher rar gesät - und um das jetzt alles erst mal "vorzubereiten" für einen vernünftigen Test, fehlt mir im Moment die Zeit.

Am Ende steht aber ohnehin wieder das Ergebnis, wie sowohl das Freetz- als auch Dein Freetz-NG-Repo aussieht und wie damit gearbeitet wird bzw. was die Benutzer (jenseits der "muß nur klappen nach dem Auschecken"-Gruppe) damit anfangen können.

Das macht Freetz/freetz ja nicht wirklich anders oder besser als Du - auch da wurde ja beim endgültigen Umstieg auf Git/GitHub eine Chance für eine "vernünftige Organisation", bei der mehrere Leute auch wirklich miteinander arbeiten, nicht wirklich ergriffen.

Aber wie gesagt ... im Moment fehlt mir einfach auch die Zeit, um die Git-Optionen für andere Forks genauer zu erkunden (jenseits dessen, was ich selbst kenne) und daß es auch anders geht bzw. wofür "merge commits" eigentlich gebraucht werden, haben wir m.E. mittlerweile ausreichend geklärt. Das ist hier immer noch ein eher abgeschiedenes Plätzchen im Internet, an dem ich solche Diskussionen eigentlich gar nicht führen möchte - ich verweise also wieder einmal auf das IPPF.

Ich hatte mittendrin ohnehin nicht verstanden, wie Du nicht an Dein Konto dort gelangen kannst (ich habe schon wieder vergessen, ob das Kennwort oder die E-Mail-Adresse nicht stimmte), aber gleichzeitig mit IPPF-Nutzern per "Unterhaltung" Kontakt aufnehmen kannst (ich finde jedenfalls seit Xenforo keine andere Option mehr), um sie - außerhalb der Threads, aber offenbar immer noch als "opto" (https://www.ip-phone-forum.de/threads/fb-6890-kein-lte-mehr-nach-freetz.307287/post-2376986 - das EDIT am Ende) - auf eine mögliche Lösung und/oder Freetz-NG aufmerksam zu machen ... und das alles noch innerhalb von ca. 5 1/2 Stunden, was jetzt auch keine anderen langwierigen Kommunikationswege wahrscheinlich erscheinen läßt.

Ich denke, hier im (geschlossenen) PR ist alles gesagt/geschrieben - ich würde das nur an einer Stelle fortführen wollen, wo auch andere wirklich etwas davon haben ... zumindest als Option und da ist so ein PR in GitHub dann eben auch nicht wirklich eine geeignete Stelle (hatte ich ja schon einmal festgestellt, auch wenn's da noch abwegiger war in den Kommentaren zu einem Commit).

[fda77]

Dann müssen die picks wohl so bleiben wie sie sind - unsigniert Wenn du dir die Signaturen auf bitbucket/gitlab anschaust, wird den Signaturen dort nicht vertraut, da diese alle auf Github hinterlegt sind

Wie das mit den Signaturen bei Mergen in Forks ist ... keine Ahnung...

Ich mach ja nur 1 merge pro pick-serie

$ glf|head -n33
* 3a4c2e55b (HEAD -> master, origin/master, origin/HEAD) bump some labors
* 274cd2124 7390 kernel: enable some modules
* 291afb171 7330 kernel: enable some modules
* 1d30bff81 push firmware: fix/exchange arm/x86 mtds for uimg, thx aussua
* 1c7883517 push firmware: fix typo
* 24a760a41 uimg tool: use new repo
* 4f1d11938 revert debug code of https://github.com/Freetz-NG/freetz-ng/commit/a34135fcc88303373986232d9c97a5dc289b46ec
*   ac7639b37 Merge Freetz
|\
| * bfc639327 davfs2: do not assume ftpuser always exists in AVM firmware, do explicitly create it
|/
* a34135fcc busybox: show if a binary is replaced & allow to skip it  - refs https://github.com/Freetz-NG/freetz-ng/issues/34
* e571c2d60 props: use def_bool
*   12547f8cd Merge Freetz
|\
| * 0c40ac84a Mbed TLS: bump version to 2.7.16
| * ff890d777 Avoid globally caching dl*-func related values
| * fff38399e hp-utils: avoid segfault by not freeing memory (workaround)
| * 3965601bf hp-utils: fix hp-utils fails to link with "ld: cannot find -lusb"
|/
* b0c0b74a6 push firmware: add help link
* 4c82abd67 docs: fix alphabetical order
* 2e19b2984 busybox: fix sed in makefile
* 0147f1498 busybox: dont overwrite ip-binary  - thx cnbr  - closes https://github.com/Freetz-NG/freetz-ng/issues/34
* b1324c403 props: add HAS_IP_BINARY  - refs https://github.com/Freetz-NG/freetz-ng/issues/34
* 0c4fdfb46 Tagging: add new tag Pimped & improve tag cuma & freetz-ng - closes https://github.com/Freetz-NG/freetz-ng/pull/35
*   a5b69369d Merge pull request #33 from berndy2001/master
|\
| * 0f430a564 Graphics optimized
|/
* e1d5da0f2 fix tagging for FOS 7.1+  - feel free to improve/add new tags!  - disable priskrat as there is no svg  - closes https://github.com/Freetz-NG/freetz-ng/issues/32
* 7b1b988f9 bump dnsmasq
* d119776f8 revert last corrupted merge

Und die merges sind um diese so einfacher unterscheiden zu können

Mit normalen Merges zwischen Freetz/ und NG funktioniert nicht, da ich ja nicht alles übernehmen will/kann. In manchen Bereichen gibt es große Unterschiede, zb ng hat avm's pub-keys und Freetz/ die md5-hashes eines jeden einzelnen Images

IPPF: hab ich meine eMail zurückgesetzt bekommen und wieder eine Passwort setzen können. Des Konto ist aber noch deaktiviert. Ich hab vorhin erst darauf geantwortet. Keine Ahnung ob das wieder aktiviert wird

[PeterPawn]

Als wirklich letzte Antwort hier (gerne weiter im IPPF):

Die Signatur gilt tatsächlich auch für den Hash des "parent" - der ist Bestandteil des Payloads, der GPG vorgesetzt wird, wie ich noch kurz gecheckt hatte:

tree b9bdaad37c85fe57b1bbd3a0ab211a1b3508347a
parent fd319b30684744c8fa09afdeb862ab482f62a690
author YourFritz <git@yourfritz.de> 1596227761 +0200
committer YourFritz <git@yourfritz.de> 1596227761 +0200

Check signature payload

Damit kann eine Signatur ja auch nur dann gültig sein/bleiben, wenn der Commit bzw. die Commits innerhalb der Kette nicht so verschoben werden, daß der "parent" nicht mehr paßt - d.h. der Punkt, wo diese Commit "abzweigen" vom Master-Branch in den eigenen und die weitere Abfolge von Commits bis hin zu dem, wo die Signatur angebracht wurde, darf sich nicht ändern ... denn dann ändert sich auch der Hash für die Commits und am Ende stimmt der "parent" für folgende Signaturen nicht mehr.

Teilweise kann ich das auch wieder nachvollziehen ... der Autor bescheinigt dem Patch halt Authentizität und "Wirksamkeit" (aka getestetes Verhalten) und das setzt natürlich voraus, daß auch der Ausgangsstand, auf den die Änderungen angewandt werden sollen, der richtige ist - damit macht "parent" da drin auch wieder Sinn.

Also bringen diese Signaturen tatsächlich nur dann etwas, wenn man sauber mit Branches arbeitet und diese dann am Ende auch so mischen kann, daß ihr Ausgangspunkt vorhanden ist und bleibt und sie mit einem "merge commit" (der dann sowohl die "Spitze" des Branches (also den letzten Commit dort) als auch die Spitzes des Masters (der eigentlich auch nur ein Branch ist - halt mit einer besonderen Aufgabe) als "parent" enthält) wieder zusammengeführt werden können. Das ist halt die "normale Arbeitsweise" bei Git und dann funktionieren die Signaturen auch ganz gut (und natürlich auch alle anderen damit verknüpften Funktionen) - was für mich am Ende auch nur ein weiterer Pluspunkt bei den "pros" auf der "always branch"-Seite der Diskussion wäre,

---

Und wenn GitLab/Bitbucket die Signaturen nicht verifizieren können, kann da "git" auch wieder nichts für ... das verläßt sich beim Signieren/Prüfen ja auch auf die lokale Installation von GPG und wenn da keine automatische Suche auf Key-Servern erfolgt (bei GitLab/Bitbucket - und vermutlich bei GitHub auch nicht) und auch kein öffentlicher Schlüssel/kein Zertifikat in den lokalen Key-Store importiert wurde (oder eben in den der Plattform, wenn die Überprüfung dort stattfinden soll), dann kann man logischerweise solche Signaturen auch nicht prüfen.

Nur würde bei einem einzelnen Projekt mit einer Gruppe an Mitstreitern vermutlich auch nur eine Plattform (zumindest als die "führende", denn read-only-Kopien auf anderen Plattformen verwenden ja durchaus einige OpenSource-Projekte im Netz) verwendet und daß da dann die jeweiligen Keys zur Verifikation vorliegen müssen, liegt wieder in der Natur der Sache (beim Signieren/Verifizieren).

Ohne den GPG-Key für die "GUI-Commits" per GitHub im eigenen GPG-Key-Store zu installieren, kann man auch mit "git" auf der Kommandozeile keine Signaturen für diese Commits prüfen (zumindest nicht erfolgreich):

peh@vidar:/tmp/fup> git log -n 1 --show-signature | cat
commit f4147ce9fefd12297a5c740f93ca1b15914122b1
gpg: Signature made Tue 28 Jul 2020 07:49:41 PM CEST
gpg:                using RSA key 4AEE18F83AFDEB23
gpg: Can't check signature: No public key
Author: leggewie <leggewie@users.noreply.github.com>
Date:   Tue Jul 28 19:49:40 2020 +0200

    replace AWOL wehavemorefun.de links with archive.org backups (#302)
peh@vidar:/tmp/fup> wget -q -O - https://github.com/web-flow.gpg | gpg --import
gpg: key 4AEE18F83AFDEB23: public key "GitHub (web-flow commit signing) <noreply@github.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
peh@vidar:/tmp/fup> git log -n 1 --show-signature | cat
commit f4147ce9fefd12297a5c740f93ca1b15914122b1
gpg: Signature made Tue 28 Jul 2020 07:49:41 PM CEST
gpg:                using RSA key 4AEE18F83AFDEB23
gpg: Good signature from "GitHub (web-flow commit signing) <noreply@github.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 5DE3 E050 9C47 EA3C F04A  42D3 4AEE 18F8 3AFD EB23
Author: leggewie <leggewie@users.noreply.github.com>
Date:   Tue Jul 28 19:49:40 2020 +0200

    replace AWOL wehavemorefun.de links with archive.org backups (#302)
peh@vidar:/tmp/fup>

[fda77]

Ja, wenn/falls mein Account wieder freigeschaltet wird Die anderen beiden sind doch ro-mirrors! (steht auch so in der README.md <- lesen) Bei gitlab obendrüber: "This project is mirrored from https://github.com/Freetz-NG/freetz-ng.git. Pull mirroring updated 8 minutes ago.", glaube das refresht alle 30min