Modul 10_KOPP_FC.pm fehlerhaft - legt heutige Updates lahm!

[betateilchen]

Leider habe ich in der MAINTAINER.txt keinen Eintrag eines Modulverantwortlichen gefunden.

Die heute im update enthaltene Moduldatei 10_KOPP_FC.pm scheint fehlerhaft zu sein und führt dazu, dass das Update abbricht.
Erste Meldung von Anwendern bereits hier: http://forum.fhem.de/index.php/topic,47395.0.html

[rudolfkoenig]

Danke fuer den Hinweis, habs gefixt, update muesste wieder durchlaufen.

Ursache war, dass 10_KOPP_FC.pm "readonly" (mode 444) eingecheckt war, und beim zweiten mal ging rsync in fhemupdate schief. Ich habe jetzt ein "svn propset mode 664 10_KOPP_FC.pm" durchgefuehrt, damit das morgen nicht wieder kaputt geht, das muessten wir im pre-commit auch pruefen. Freiwillige?

[Markus Bloch]

Ich kümmer mich. Als pre-commit-"Beauftragter"

Hab noch alles da um den pre-commit einfach zu testen.

[betateilchen]

Danke fuer den Hinweis, habs gefixt, update muesste wieder durchlaufen.

In der Installation, mit der ich das heute morgen getestet habe, waren nach dem fehlgeschlagenen Update die Rechte auf readonly gesetzt.
Erst nachdem ich das manuell wieder korrigiert habe, konnte ich das korrigierte update jetzt durchführen.

Auf einer zweiten Testinstallation, die ich heute früh noch keinem Update unterzogen hatte, war das Update eben fehlerfrei möglich.

Wäre es möglich, dass 98_update.pm die Rechte der Zieldatei selbst dann ändert, wenn es einen Fehler gibt?

[betateilchen]

Ich kümmer mich. Als pre-commit-"Beauftragter"

Man könnte vielleicht hier im Unterforum einen angepinnten Beitrag erstellen, in dem aufgelistet wird, welche Bedingungen im pre-commit geprüft werden, bevor eine Datei eingecheckt werden kann. Da sind ja in den vergangenen (gefühlt) zwei Jahren doch einige neue Prüfungen dazugekommen.

[Markus Bloch]

Danke fuer den Hinweis, habs gefixt, update muesste wieder durchlaufen.

Ursache war, dass 10_KOPP_FC.pm "readonly" (mode 444) eingecheckt war, und beim zweiten mal ging rsync in fhemupdate schief. Ich habe jetzt ein "svn propset mode 664 10_KOPP_FC.pm" durchgefuehrt, damit das morgen nicht wieder kaputt geht, das muessten wir im pre-commit auch pruefen. Freiwillige?

Ich hab gerade mal ein wenig nachgeschaut, wie es bei anderen Modulen steht. Fakt ist, 10_KOPP_FC.pm ist momentan das einzige, welche die svn property "mode" gesetzt hat. Ich würde daher keinen pre-commit bauen, weil dann geht garnix mehr.

Ich habe mal durchgeschaut, welche properties in allen Modulen gesetzt sind und das sind nur "svn:keywords", sowie vereinzelt "svn:executable".

Daher würde ich deinen Vorschlag überdenken dies mit einem pre-commit Hook zu lösen. Ich würde betateilchen's Vorschlag unterstützen und das Problem in 98_update lösen.

Gruß
Markus

[Markus Bloch]

Man könnte vielleicht hier im Unterforum einen angepinnten Beitrag erstellen, in dem aufgelistet wird, welche Bedingungen im pre-commit geprüft werden, bevor eine Datei eingecheckt werden kann. Da sind ja in den vergangenen (gefühlt) zwei Jahren doch einige neue Prüfungen dazugekommen.

Eigentlich gehört das genau hierhin: http://forum.fhem.de/index.php/topic,18962.0.html

[betateilchen]

Eigentlich schon. Aber wenn ich mir die Fragen von Entwicklern anschaue, die hier immer wieder auftauchen, muss man leider davon ausgehen, dass diese Hinweise ohnehin so gut wie nie gelesen wurden.

Ob das bei einer Liste der pre-commit hooks anders wäre? Vermutlich nicht, aber es wäre zumindest mal zentral dokumentiert.

Aber wir sind hier im falschen Thread um das weiter zu diskutieren.

[rudolfkoenig]

Ich würde betateilchen's Vorschlag unterstützen und das Problem in 98_update lösen.

Das Problem war nicht, dass "update" beim Benutzer die Datei nicht speichern konnte, sondern dass die update Vorbereitung die aktuelle 10_KOPP_FC.pm nicht auf fhem.de kopieren konnte, weil die Datei auf fhem.de nicht schreibbar war. Damit passte die von fhem.de heruntergeladen Datei nicht zu der Laengenbeschreibung in controls_fhem.txt.
Ein Workaround waere in contrib/fhemupdate.pl an korrekter Stelle ein "chmod" einzufuegen.

[Markus Bloch]

Das wird wohl die einzige Möglichkeit sein, da man mit svnlook nicht ermitteln kann, mit welchen Dateirechten eine neue Datei eingecheckt wird. Die generellen Dateisystemrechte werden durch SVN nicht verwaltet und abgeglichen (bis auf das, was in der Property "mode" gesetzt ist).

[rudolfkoenig]

Offensichtlich war mein propset mode wirkungslos, wenn man die Datei erneut auscheckt, dann wird sie mit 444 angelegt. Hat jemand eine Idee, wie man das aendern kann?

[betateilchen]

Das Problem dürfte sein, dass in Deinem lokalen Verzeichnis, aus dem Du das update vorbereitest, die Datei immer noch als readonly steht. Du wirst erst dort die Rechte anpassen müssen, bevor das wieder funktioniert.

Code Auswählen Erweitern


root@fhem-dev:/opt/fhem.svn/fhem/FHEM> chmod 644 10_KOPP_FC.pm
root@fhem-dev:/opt/fhem.svn/fhem/FHEM> ls -al 10_KOPP_FC.pm
-rw-r--r-- 1 root root 28502 Jan 15 06:50 10_KOPP_FC.pm
root@fhem-dev:/opt/fhem.svn/fhem/FHEM> svn update 10_KOPP_FC.pm
Aktualisiere »10_KOPP_FC.pm«:
UU   10_KOPP_FC.pm
Aktualisiert zu Revision 10511.
root@fhem-dev:/opt/fhem.svn/fhem/FHEM> ls -al 10_KOPP_FC.pm
-rw-r--r-- 1 root root 28504 Jan 15 10:11 10_KOPP_FC.pm
root@fhem-dev:/opt/fhem.svn/fhem/FHEM>


Nebenbei habe ich eben das Lock-Bit der Moduldatei entfernt.

[rudolfkoenig]

Wenn das stimmt, dann habe ich das Problem bei mir (bzw. auf dem fhemupdate Server) gefixt. Was mir Sorge bereitet ist, dass "rm 10_KOPP_FC.pm; svn update 10_KOPP_FC.pm" die Datei wieder mit 444 erzeugte. Ein svn+ssh://rudolfkoenig@svn.code.sf.net/p/fhem/code/trunk/fhem/FHEM holt die Datei dagegen mit 664.

[betateilchen]

Bei mir passen die Rechte nach einem Löschen und anschließendem svn update:

Code Auswählen Erweitern


root@fhem-dev:/opt/fhem.svn/fhem/FHEM> rm 10_KOPP_FC.pm
root@fhem-dev:/opt/fhem.svn/fhem/FHEM> svn update 10_KOPP_FC.pm
Aktualisiere »10_KOPP_FC.pm«:
Wieder hergestellt »10_KOPP_FC.pm«
Revision 10511.
root@fhem-dev:/opt/fhem.svn/fhem/FHEM> ls -al 10_KOPP_FC.pm
-rw-r--r-- 1 root root 28504 Jan 15 12:18 10_KOPP_FC.pm
root@fhem-dev:/opt/fhem.svn/fhem/FHEM>


Vielleicht hängt Dein Problem mit dem "Wieder hergestellt..." zusammen, bei mir hatte die Datei ja bereits vor dem Löschen die (manuell gesetzten) korrekten Rechte.

Bei einem vollständigen neuen Auschecken des gesamten repository stehen bei mir die Rechte für 10_KOPP_FC.pm korrekt auf 644.

[Dr. Boris Neubert]

Hallo Markus,

Eigentlich gehört das genau hierhin: http://forum.fhem.de/index.php/topic,18962.0.html

magst Du einen Beitrag zu den pre-commit-Checks erstellen? Ich würde dann das besagte Thema öffnen, damit Du Deinen Beitrag dort posten kannst.

Grüße
Boris