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
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 kümmer mich. Als pre-commit-"Beauftragter" :D
Hab noch alles da um den pre-commit einfach zu testen.
Zitat von: rudolfkoenig am 14 Januar 2016, 09:16:43
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?
Zitat von: Markus Bloch am 14 Januar 2016, 09:27:33
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.
Zitat von: rudolfkoenig am 14 Januar 2016, 09:16:43
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
Zitat von: betateilchen am 14 Januar 2016, 12:55:08
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
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.
ZitatIch 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.
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).
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?
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.
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.
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.
Bei mir passen die Rechte nach einem Löschen und anschließendem svn update:
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.
Hallo Markus,
Zitat von: Markus Bloch am 14 Januar 2016, 13:10:06
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
Hallo Boris,
das wäre toll.
Gruß
Markus
Zitat von: Dr. Boris Neubert am 16 Januar 2016, 10:43:55
Thema geöffnet.
Fertig.
Habe unter http://www.fhemwiki.de/wiki/SVN_Nutzungsregeln einen Beitrag mit Gerüst erstellt. Da werde ich in den nächsten Tagen das nochmal niederschreiben, sowie die allgemeinen organisatorischen Regeln zum Thema SVN/Modulpflege. Ich freu mich natürlich immer über Hilfe.
Thema "Hinweise für Entwickler" geschlossen
@Markus: sehr gut beschrieben :) Danke!
Das heutige Update der 10_KOPP_FC.pm scheint funktioniert zu haben, es gab zumindest bisher keine neuen Problemmeldungen im Forum.
Zitat von: betateilchen am 16 Januar 2016, 13:28:53
@Markus: sehr gut beschrieben :) Danke!
Vielen Dank. Bringt nur leider nichts, wenn es niemand liest, daher der selbe Inhalt nochmal mit Beispielen und Ausgaben versehen fürs Wiki, damit es dann eigentlich keine Fragen mehr geben sollte.
Hi,
sorry, dass mein Modul so viel Ärger verursacht.
Mein Problem ist wohl, dass ich das Update erst testen kann wenn das Modul online ist, oder geht das auch anders?
Ich hatte das Property "Needs lock" gesetzt, evt. Ist das die Ursache für das Problem.
Noch eine Anmerkung:
Die Anleitung für Programmierer hab ich schon gelesen, für einen Anfänger wie mich sind das einfach zu viel Info's.
Vielleicht sollte ich das Programmieren doch lieber lassen.
Eine andere Möglichkeit wäre, jemand stellt sich als Pate/Coach zur Verfügung und macht z.B. einen Code Review bevor ich was offiziell einstelle.
Rudolf, ich halt mich da an Deine Empfehlung
Gruß
RaspII
Zitat von: RaspII am 16 Januar 2016, 14:10:19
Noch eine Anmerkung:
Die Anleitung für Programmierer hab ich schon gelesen, für einen Anfänger wie mich sind das einfach zu viel Info's.
Vielleicht sollte ich das Programmieren doch lieber lassen.
Eine andere Möglichkeit wäre, jemand stellt sich als Pate/Coach zur Verfügung und macht z.B. einen Code Review bevor ich was offiziell einstelle.
Hallo RaspII,
es will dich hier niemand vom programmieren abbringen, um Gottes Willen. Genau davon lebt doch dieses Projekt ;) Es ist das erste mal (meiner Meinung nach), dass ein solches Problem beim Update aufgetreten ist. Die "Hinweise für Entwickler" die ich heute erweitert habe, sind ja während der Diskussion der Ursache entstanden und nicht, weil du ein Fehler gemacht hast. Es gab in letzter Zeit aus verschiedenen Gründen einige Straffungen der Regeln beim Umgang mit SVN. Es wurde daher nur diskuttiert, ob die Dateirechte da evtl. mit aufgenommen werden sollten, um sowas zu vermeiden. So ganz sicher ist die Ursache ja noch nicht identifiziert. Könnte ein Problem mit den Locks sein oder evtl. im fhem-Update-Prozess.
Daher bitte nicht persönlich nehmen. Dein Code stand nie zur Debatte.
Gruß
Markus
ZitatIch hatte das Property "Needs lock" gesetzt, evt. Ist das die Ursache für das Problem.
Aah. Ja, ich bin auch ueberzeugt, dass das die Ursache war. Habe auch was dazugelernt :)
Sonst: bitte nicht abschrecken lassen.
Niemand will hier irgendjemanden abschrecken.
Zitat von: RaspII am 16 Januar 2016, 14:10:19
Eine andere Möglichkeit wäre, jemand stellt sich als Pate/Coach zur Verfügung und macht z.B. einen Code Review bevor ich was offiziell einstelle.
Für den organisatorischen Teil Deiner Modulentwicklung kann ich die Patenschaft gerne übernehmen, ich habe das in der Vergangenheit schon mit dem einen oder anderen "neuen" Entwickler gemacht, bis die Module dann flügge waren :) Also wenn Du mal wieder eine Frage oder ein Problem bei der Verwaltung Deines Moduls hast, schick mir einfach eine email hier über das Forum
Inhaltlich kann ich Dir bei Deinem Modul allerdings nicht viel helfen, da ich weder Kopp- noch andere SlowRF Komponenten im Einsatz habe.
Super,
Betateilchen, danke für Dein Angebot, ich werde es annehmen.
Bin bis Sonntag Abend nicht Zuhause, aber wenn ich Euch richtig verstanden habe wurde das Property "Needs lock" (was ja dazu führt, dass beim auschecken aus SVN der Schreibschutz gesetzt wird) wieder gelöscht.
Noch Danke für Eure Hilfe
RaspII
Gesendet von meinem SM-G900F mit Tapatalk
Hallo betateilchen,
Du hattest Dich netter Weise bereit erklärt die "Patenschaft" für mein Modul zu übernehmen.
Ich habe jetzt den nächsten großen Schritt implementiert (Zusätzliche Aktoren wie "Rolladen, Schalter, Timer/Schalter".
Zudem habe ich die Funktion "KOPP_FC_Undef" implementiert.
Hier habe ich auch Bedenken, da ich nicht weiss wie man diese Funktion testen soll.
(Habe mir das vom FS20 Modul abgeschaut, allerdings schaffe ich es nicht, dass die Routine auch angesprochen wird (Ausgaben in die Log Datei habe ich eingebaut).
Das geänderte Modul habe ich erstmal ins "Contrib" Verzeichnis gestellt:
https://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/10_KOPP_FC.pm (https://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/10_KOPP_FC.pm)
Bei mir läuft das seit ca. 1 Tag stabil. Im Modul sind noch viele Kommentare und "auskommentierte" Log Anweisungen, diese benötige ich evt. noch zum Debuggen.
RaspII
Die UndefFn wird aufgerufen, wenn ein device gelöscht wird. Wie hast Du denn versucht, die Funktion zu erreichen / zu testen?
Und was willst Du eigentlich in der UndefFn tun? Hast Du mal geschaut, ob nach dem Löschen eines device die ganzen Werte, die Du in Deinem Modul versuchst zu löschen, überhaupt noch vorhanden sind?
Vorsicht, es gibt einen feinen unterschied zwischen UndefFn und DeleteFn:
UndefFn: aufruf beim löschen eines Gerätes (via delete-Befehl) ODER bei rereadcfg
DeleteFn: aufruf beim löschen eines Gerätes (via delete-Befehl). Erfolgt NACH DEM Aufruf von UndefFn.
ShutdownFn: aufruf vor dem beenden von FHEM durch den Befehl "shutdown"
Gruß
Markus
Zitat von: Markus Bloch am 31 Januar 2016, 17:10:55
Vorsicht, es gibt einen feinen unterschied zwischen UndefFn und DeleteFn:
ja, aber so kompliziert wollte ich es jetzt (noch) nicht machen :)
Danke (bzgl. einfach machen) :)
Testen wollte ich via "Shutdown Restart", jetzt weiss ich auch warums nicht geklappt hat (ShutdownFn).
Ausserdem hätte ich gedacht, dass beim Speichern der fhem.cfg auch eine Art "rereadcfg" gemacht wird (passiert wohl nich).
Ich werde mich dann die nächsten Tage ans Testen machen, sollte mit Euren Tipps jetzt klappen.
Zitat von: RaspII am 31 Januar 2016, 19:40:06
Ausserdem hätte ich gedacht, dass beim Speichern der fhem.cfg auch eine Art "rereadcfg" gemacht wird (passiert wohl nich).
Das würde doch keinen Sinn machen. Denn das, was beim Speichern in die fhem.cfg geschrieben wird, ist doch genau die aktuell laufende Konfiguration. Warum sollte man nach dem Speichern genau das neu lesen, was man ohnehin schon laufen hat?
Ein automatisches Neulesen nach dem Abspeichern gibt es aber durchaus an einigen Stellen in fhem, wo es auch Sinn macht. Beispiele:
- 99_.* Dateien, die man mit dem internen Editor bearbeitet und abspeichert
- Layouts von RSS und InfoPanel, wenn man die Layoutdateien im internen Editor bearbeitet und abspeichert
Das verstehe ich jetzt nicht.
Wenn ich die fhem.cfg manuell ändere kann ich doch durchaus Devices löschen und neue eingeben.
D.h. es steht eben nicht das selbe in der Datei wie vorher.
Hatte aber nicht erwähnt, dass ich die Datei manuell geändert habe, danach gespeichert.
ja, Du hast recht. Hab ich vorhin verwexelt, weil ich gedanklich grade an einer anderen Baustelle war.
Aber wer hat auch heutzutage noch eine fhem.cfg ;)
Hallo Betateilchen,
ich habe es jetzt geschafft, dass die Undef Funktion durchlaufen wird.
Prinzipiell scheint es zu klappen, ich wunderte mich aber anfangs darüber, dass manche Devices (Hashes) mehrfach gelöscht werden.
Ich weisse jedem Device zwischen 2 und 4 Tastencodes zu.
Gelöscht wird ein Device so of wie ich Tastencodes zugeordnet hatte.
Da der delete Befehl Key+value löscht, sollte das passen.
Meine Logfileeinträge sehen wie folgt aus:
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: SenderNeuTaste2, Device: HASH(0x1bd87f0) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: SenderNeuTaste2, Device: HASH(0x1bd87f0) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: SenderNeuTaste1, Device: HASH(0x1bd82f8) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: SenderNeuTaste1, Device: HASH(0x1bd82f8) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: Taste2Rad4, Device: HASH(0x1bd7c80) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: Taste2Rad4, Device: HASH(0x1bd7c80) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: Switch, Device: HASH(0x1bd5778) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: Switch, Device: HASH(0x1bd5778) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: 2Switch, Device: HASH(0x1bd5370) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: 2Switch, Device: HASH(0x1bd5370) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: 2Switch, Device: HASH(0x1bd5370) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: TasteUp, Device: HASH(0x1bd48c0) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: TasteUp, Device: HASH(0x1bd48c0) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: TasteUp, Device: HASH(0x1bd48c0) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: DimmerDevice_OnOff, Device: HASH(0x1bd4000) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: DimmerDevice_OnOff, Device: HASH(0x1bd4000) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: DimmerDevice_OnOff, Device: HASH(0x1bd4000) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: DimmerDevice_OnOff, Device: HASH(0x1bd4000) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: Dimmer, Device: HASH(0x1bd3a78) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: Dimmer, Device: HASH(0x1bd3a78) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: Taste1Rad5, Device: HASH(0x196a1c0) deleted
2016.02.01 20:37:45 3: KOPP_FC_Undef: Name: Taste1Rad5, Device: HASH(0x196a1c0) deleted
Die KOPP_FC_Undef sieht wie folgt aus:
sub KOPP_FC_Undef($$)
{
my ($hash, $name) = @_;
foreach my $c (keys %{ $hash->{CODE} } )
{
$c = $hash->{CODE}{$c};
# As after a rename the $name my be different from the $defptr{$c}{$n}
# we look for the hash.
foreach my $dname (keys %{ $modules{KOPP_FC}{defptr}{$c} })
{
if($modules{KOPP_FC}{defptr}{$c}{$dname} == $hash)
{
my $m=$modules{KOPP_FC}{defptr}{$c}{$dname};
Log3 $name, 3, "KOPP_FC_Undef: Name: $name, Device: $m deleted";
}
delete($modules{KOPP_FC}{defptr}{$c}{$dname}) if($modules{KOPP_FC}{defptr}{$c}{$dname} == $hash);
}
}
return undef;
}
Nicht über die If Bedingung für den Logfile eintrag wundern, dieser soll final wieder entfernt werden.
Wenn aus Deiner Sicht nicht's dagegen spricht werde ich noch die Logfileeinträge entfernen und das Modul danach einstellen.
Gruß
RaspII
ja, mach nur :)
Falls es beim Einchecken Probleme gibt, melde Dich einfach nochmal hier.