updatefhem - dokumentation von änderungen (allgemein)
66 views
Skip to first unread message
Martin Fischer
May 24, 2012, 7:45:55 PM5/24/12
to fhem-de...@googlegroups.com
==> dokumentation von änderungen (allgemein, nicht nur updatefhem):
es kam der hinweis, das die änderungen von updatefhem im commandref.html nicht
ausreichend dokumentiert seien. beispiel der wegfall von "follow symlinks" bei
tar, änderung vom default backupdir FHEM.backup auf backup (steht zwar so
drin, aber wohl nicht deutlich genug), sowie änderung im namen des archivs
(tgz nach tar.gz). als ich updatefhem anpasste kam mir kurz die idee, erst das
changelog anzuzeigen und dann das updatefhem erst zu starten. wird nur
schwierig mit der umsetzung ala "are you sure to update to version x.x?"
alternativ könnte man das changelog anstatt der "updapted xxx" anzeigen
anzeigen. allerdings wäre dann das update schon durchlaufen :-(
kurzum: wie bekommen wir den hinweis auf die änderungen an den nutzer _bevor_
das update startet? auch wieder über argumente?
anregungen / ideen?
es kam der hinweis, das die änderungen von updatefhem im commandref.html nicht
ausreichend dokumentiert seien. beispiel der wegfall von "follow symlinks" bei
tar, änderung vom default backupdir FHEM.backup auf backup (steht zwar so
drin, aber wohl nicht deutlich genug), sowie änderung im namen des archivs
(tgz nach tar.gz). als ich updatefhem anpasste kam mir kurz die idee, erst das
changelog anzuzeigen und dann das updatefhem erst zu starten. wird nur
schwierig mit der umsetzung ala "are you sure to update to version x.x?"
alternativ könnte man das changelog anstatt der "updapted xxx" anzeigen
anzeigen. allerdings wäre dann das update schon durchlaufen :-(
kurzum: wie bekommen wir den hinweis auf die änderungen an den nutzer _bevor_
das update startet? auch wieder über argumente?
anregungen / ideen?
Rudolf Koenig
May 25, 2012, 3:15:10 AM5/25/12
to fhem-de...@googlegroups.com
> kurzum: wie bekommen wir den hinweis auf die �nderungen an den nutzer _bevor_
> das update startet? auch wieder �ber argumente?
Ein "update chek" koennte alles durchfuehren, aber keine Dateien
schreiben/umbenennen. Dann wuerde man sehen, wass passiert.
Wer Details sehen moechte, der kann dann die SVN Logs anschauen.
In meinem Augen ist updatefhem fuer Experimentierfreudige, die gerne die
Entwicklerversion haben, und beim testen mithelfen wollen. Wenn man kein Risiko
eingehen will, dann macht man den Upgrade auf einem zweiten fhem Server, man
testet alles durch, und spielt die Aenderungen erst danach auf die Produktion
ein.
> das update startet? auch wieder �ber argumente?
Ein "update chek" koennte alles durchfuehren, aber keine Dateien
schreiben/umbenennen. Dann wuerde man sehen, wass passiert.
Wer Details sehen moechte, der kann dann die SVN Logs anschauen.
In meinem Augen ist updatefhem fuer Experimentierfreudige, die gerne die
Entwicklerversion haben, und beim testen mithelfen wollen. Wenn man kein Risiko
eingehen will, dann macht man den Upgrade auf einem zweiten fhem Server, man
testet alles durch, und spielt die Aenderungen erst danach auf die Produktion
ein.
Martin Fischer
May 25, 2012, 6:41:32 AM5/25/12
to fhem-de...@googlegroups.com
Am Freitag, 25. Mai 2012, 09:15:10 schrieb Rudolf Koenig:
> > kurzum: wie bekommen wir den hinweis auf die änderungen an den nutzer
> > _bevor_ das update startet? auch wieder über argumente?
> > kurzum: wie bekommen wir den hinweis auf die änderungen an den nutzer
> > _bevor_ das update startet? auch wieder über argumente?
Martin Fischer
May 25, 2012, 6:56:49 AM5/25/12
to fhem-de...@googlegroups.com
plong... diesmal mit meiner antwort ;-)
Am Freitag, 25. Mai 2012, 09:15:10 schrieb Rudolf Koenig:
> > kurzum: wie bekommen wir den hinweis auf die änderungen an den nutzer
> > _bevor_ das update startet? auch wieder über argumente?
gut, wenn das changelog auch irgendwie angezeigt werden würde. ein "update
check" wird von der ausgabe her vielleicht den versierten anwendern was sagen
aber im changelog stünden halt noch konkrete informationen. ist dann halt
erforderlich, dass das auch gepflegt wird.
> In meinem Augen ist updatefhem fuer Experimentierfreudige, die gerne die
> Entwicklerversion haben, und beim testen mithelfen wollen. Wenn man kein
> Risiko eingehen will, dann macht man den Upgrade auf einem zweiten fhem
> Server, man testet alles durch, und spielt die Aenderungen erst danach auf
> die Produktion ein.
dazu habe ich mir gestern auch noch gedanken gemacht:
was hälst du davon, wenn wir update noch die optionen oder attribute <stable>
und <unstable> spendieren? dazu müsste dann auf fhem.de einmal die letzte
stable version bereitstehen, also akutell 5.2 und der svn mirror.
link könnte ja z.b. so aussehen: fhem.de/update/stable und
fhem.de/update/unstable oder svn
das würde halt auch den nutzern das updaten auf eine neuere stable version
ermöglichen. und die experementierfreudigen können dann mittels flag die svn
version einspielen.
Am Freitag, 25. Mai 2012, 09:15:10 schrieb Rudolf Koenig:
> > _bevor_ das update startet? auch wieder über argumente?
>
> Ein "update chek" koennte alles durchfuehren, aber keine Dateien
> schreiben/umbenennen. Dann wuerde man sehen, wass passiert.
> Wer Details sehen moechte, der kann dann die SVN Logs anschauen.
ja, auch eine möglichkeit die wir ins auge fassen sollten. ich fände aber auch
> Ein "update chek" koennte alles durchfuehren, aber keine Dateien
> schreiben/umbenennen. Dann wuerde man sehen, wass passiert.
> Wer Details sehen moechte, der kann dann die SVN Logs anschauen.
gut, wenn das changelog auch irgendwie angezeigt werden würde. ein "update
check" wird von der ausgabe her vielleicht den versierten anwendern was sagen
aber im changelog stünden halt noch konkrete informationen. ist dann halt
erforderlich, dass das auch gepflegt wird.
> In meinem Augen ist updatefhem fuer Experimentierfreudige, die gerne die
> Entwicklerversion haben, und beim testen mithelfen wollen. Wenn man kein
> Risiko eingehen will, dann macht man den Upgrade auf einem zweiten fhem
> Server, man testet alles durch, und spielt die Aenderungen erst danach auf
> die Produktion ein.
was hälst du davon, wenn wir update noch die optionen oder attribute <stable>
und <unstable> spendieren? dazu müsste dann auf fhem.de einmal die letzte
stable version bereitstehen, also akutell 5.2 und der svn mirror.
link könnte ja z.b. so aussehen: fhem.de/update/stable und
fhem.de/update/unstable oder svn
das würde halt auch den nutzern das updaten auf eine neuere stable version
ermöglichen. und die experementierfreudigen können dann mittels flag die svn
version einspielen.
Rudolf Koenig
May 25, 2012, 7:25:56 AM5/25/12
to fhem-de...@googlegroups.com
> link k�nnte ja z.b. so aussehen: fhem.de/update/stable und
> fhem.de/update/unstable oder svn
Einverstanden, ich werde es am WoE via fhemupdate bereitstellen.
Es gibt also demnaechst 4 Versionen:
- fhemupdate
- fhemupdate2
- fhemupdate3/stable
- fhemupdate3/svn
davon 3 taeglich aktualisiert. Irgendeine Idee, wie man das optimieren bzw.
vereinfachen koennte?
Weiterhin werde ich CHANGED auch ins fhemupdate packen. Ich finde man sollte
die Liste der geaenderten Dateien trotzdem anzeigen, fuer den Fall, dass
CHANGED vergessen wurde.
> fhem.de/update/unstable oder svn
Einverstanden, ich werde es am WoE via fhemupdate bereitstellen.
Es gibt also demnaechst 4 Versionen:
- fhemupdate
- fhemupdate2
- fhemupdate3/stable
- fhemupdate3/svn
davon 3 taeglich aktualisiert. Irgendeine Idee, wie man das optimieren bzw.
vereinfachen koennte?
Weiterhin werde ich CHANGED auch ins fhemupdate packen. Ich finde man sollte
die Liste der geaenderten Dateien trotzdem anzeigen, fuer den Fall, dass
CHANGED vergessen wurde.
Martin Fischer
May 25, 2012, 4:29:19 PM5/25/12
to fhem-de...@googlegroups.com
Am Freitag, 25. Mai 2012, 13:25:56 schrieb Rudolf Koenig:
> > link könnte ja z.b. so aussehen: fhem.de/update/stable und
fhemupdate2 ja dann verschwinden können. ich würde das fhemupdate nur noch bis
z.b. max ende september laufen lassen. bzw. fällr mir gerade ein, das es dann
jau auch erstma ein redirekt auf stable oder svn sein kann. genauso mit
fhemupdate2 auf svn. dann musst du halt nur das svn wie gewohnt spiegeln und
halt immer wenn ein neues release kommt, per script ein spiegel davon ins
stable.
und dann könnte evtl. der pfad für fhemupdate3 noch anders lauten. vielleicht
nur "update" oder gar als pfad um vielleicht noch culfw von fhem zu trennen?
beispiel:
update/fhem/stable
update/fhem/svn
update/culfw/ oder nur cul
zuviel des guten? wäre aber aus meiner sicht sauber und abgegrenzt. vorallem
wäre es ausbaufähig. z.b. könnte man später pgm2 vollkommen losgelöst
betrachten und ihm ein update/pgm2 oder update/www/pgm2 spendieren... sind
halt alles nur ideen die mir gerade so spontan einfallen ;-)
> Weiterhin werde ich CHANGED auch ins fhemupdate packen. Ich finde man sollte
> die Liste der geaenderten Dateien trotzdem anzeigen, fuer den Fall, dass
> CHANGED vergessen wurde.
ja, beides sehe ich genau so!
bleibt noch ein punkt:
wie soll sich updatefhem (den man dann im zuge der obigen struktur dann
vielleicht auch gleich in update umbenennen könnte?) per default verhalten?
ich wäre ja dafür, wenn ein scharfer durchlauf nur mit einem zusatzparameter
möglich ist. das ist zwar am anfang gewöhnungsbedürftig, würde aber
verhindern, das ein unbedarfter mal eben "updatefhem" ausprobiert und alles
übergebügelt wird.
also so als beispiel:
updatefhem
gibt rückmeldung, das zu wenig argumente angegeben wurden.
updatefhem <stable|svn>
holt filetimes.txt aus <stable> oder <svn>, prüft ob sich was verändert hat:
=> nein, dann rückmeldung, das es nichts neues gibt.
=> ja, kurzer hinweis am anfang, das lediglich in der folgenden ausgabe ein
auszug (ersten 50 zeilen?) aus dem changelog folgt und im anschluss eine liste
der geänderten files sowie das über "updatefhem <stable|svn> <install>" die
installation gestartet werden kann.
updatefhem <stable|svn> <install>
holt filetimes.txt aus <stable> oder <svn>, prüft ob sich was verändert hat:
=> nein, siehe oben
=> ja, files werden installiert, dabei erfolgt zum ende die ausgabe der neuen
/ verändertem files
und zu guter letzt nur noch den housekeeping kram dann etwas vereinfacht über
updatefhem <stable|svn> <housekeeping> [clean]
also wird <install> durch <housekeeping> ersetzt, dann wird es auch gleich
durchgeführt (weil man sich ja vorher über updatefhem <svn|stable> informieren
kann) und verhält sich wie ein <install> nur halt mit dem aufräumen von pgm2.
optional dann noch clean, wenn gleich "gesäubert" werden soll. backup dann
komplett ausgelagert, wird aber automatisch bei <install|housekeeping> [clean]
angestossen.
demnach würde updatefhem wie folgt aussehen:
updatefhem <stable|svn> [install|housekeeping [clean]]
> > link könnte ja z.b. so aussehen: fhem.de/update/stable und
> > fhem.de/update/unstable oder svn
>
> Einverstanden, ich werde es am WoE via fhemupdate bereitstellen.
>
> Es gibt also demnaechst 4 Versionen:
> - fhemupdate
> - fhemupdate2
> - fhemupdate3/stable
> - fhemupdate3/svn
>
> davon 3 taeglich aktualisiert. Irgendeine Idee, wie man das optimieren bzw.
> vereinfachen koennte?
ne, im moment nicht. ausser das ja dann über kurz oder lang fhemupdate und
>
> Einverstanden, ich werde es am WoE via fhemupdate bereitstellen.
>
> Es gibt also demnaechst 4 Versionen:
> - fhemupdate
> - fhemupdate2
> - fhemupdate3/stable
> - fhemupdate3/svn
>
> davon 3 taeglich aktualisiert. Irgendeine Idee, wie man das optimieren bzw.
> vereinfachen koennte?
fhemupdate2 ja dann verschwinden können. ich würde das fhemupdate nur noch bis
z.b. max ende september laufen lassen. bzw. fällr mir gerade ein, das es dann
jau auch erstma ein redirekt auf stable oder svn sein kann. genauso mit
fhemupdate2 auf svn. dann musst du halt nur das svn wie gewohnt spiegeln und
halt immer wenn ein neues release kommt, per script ein spiegel davon ins
stable.
und dann könnte evtl. der pfad für fhemupdate3 noch anders lauten. vielleicht
nur "update" oder gar als pfad um vielleicht noch culfw von fhem zu trennen?
beispiel:
update/fhem/stable
update/fhem/svn
update/culfw/ oder nur cul
zuviel des guten? wäre aber aus meiner sicht sauber und abgegrenzt. vorallem
wäre es ausbaufähig. z.b. könnte man später pgm2 vollkommen losgelöst
betrachten und ihm ein update/pgm2 oder update/www/pgm2 spendieren... sind
halt alles nur ideen die mir gerade so spontan einfallen ;-)
> Weiterhin werde ich CHANGED auch ins fhemupdate packen. Ich finde man sollte
> die Liste der geaenderten Dateien trotzdem anzeigen, fuer den Fall, dass
> CHANGED vergessen wurde.
bleibt noch ein punkt:
wie soll sich updatefhem (den man dann im zuge der obigen struktur dann
vielleicht auch gleich in update umbenennen könnte?) per default verhalten?
ich wäre ja dafür, wenn ein scharfer durchlauf nur mit einem zusatzparameter
möglich ist. das ist zwar am anfang gewöhnungsbedürftig, würde aber
verhindern, das ein unbedarfter mal eben "updatefhem" ausprobiert und alles
übergebügelt wird.
also so als beispiel:
updatefhem
gibt rückmeldung, das zu wenig argumente angegeben wurden.
updatefhem <stable|svn>
holt filetimes.txt aus <stable> oder <svn>, prüft ob sich was verändert hat:
=> nein, dann rückmeldung, das es nichts neues gibt.
=> ja, kurzer hinweis am anfang, das lediglich in der folgenden ausgabe ein
auszug (ersten 50 zeilen?) aus dem changelog folgt und im anschluss eine liste
der geänderten files sowie das über "updatefhem <stable|svn> <install>" die
installation gestartet werden kann.
updatefhem <stable|svn> <install>
holt filetimes.txt aus <stable> oder <svn>, prüft ob sich was verändert hat:
=> nein, siehe oben
=> ja, files werden installiert, dabei erfolgt zum ende die ausgabe der neuen
/ verändertem files
und zu guter letzt nur noch den housekeeping kram dann etwas vereinfacht über
updatefhem <stable|svn> <housekeeping> [clean]
also wird <install> durch <housekeeping> ersetzt, dann wird es auch gleich
durchgeführt (weil man sich ja vorher über updatefhem <svn|stable> informieren
kann) und verhält sich wie ein <install> nur halt mit dem aufräumen von pgm2.
optional dann noch clean, wenn gleich "gesäubert" werden soll. backup dann
komplett ausgelagert, wird aber automatisch bei <install|housekeeping> [clean]
angestossen.
demnach würde updatefhem wie folgt aussehen:
updatefhem <stable|svn> [install|housekeeping [clean]]
Rudolf Koenig
May 26, 2012, 4:50:11 AM5/26/12
to fhem-de...@googlegroups.com
> updatefhem <stable|svn> [install|housekeeping [clean]]
Ich finde die "housekeeping" Option ueberfluessig (oder ich verstehe es nicht
:), bzw. ich haette es lieber als default. Wenn man es nicht durchfuehrt, dann
werden wahrscheinlich entweder "nur" Leichen herumliegen, die verwirren, im
schlimmsten Fall funktioniert was nicht, weil die notwendige Datei dazu an der
falschen Stelle liegt. Ich kann mir im Momant nicht vorstellen, was dabei
zusaetzlich zum alten Verfahren geloescht waere.
Rudolf Koenig
May 28, 2012, 5:07:29 AM5/28/12
to fhem-de...@googlegroups.com
> Einverstanden, ich werde es am WoE via fhemupdate bereitstellen.
>
> Es gibt also demnaechst 4 Versionen:
> - fhemupdate
> - fhemupdate2
> - fhemupdate3/stable
> - fhemupdate3/svn
Ich habe fhem-5.2 ausgepackt, alles "noetige" zusammmenkopiert, ein
>
> Es gibt also demnaechst 4 Versionen:
> - fhemupdate
> - fhemupdate2
> - fhemupdate3/stable
> - fhemupdate3/svn
filetimes.txt zusammengepastelt :), und es unter fhemupdate3/stable
hochgeladen. fhemupdate3/svn habe ich als symlink zu fhemupdate2 angelegt, es
scheint aber zu funktionieren.
Wenn mit dieser Loesung Probleme gibt, bitte melden.
Martin Fischer
May 31, 2012, 1:49:14 PM5/31/12
to fhem-de...@googlegroups.com
Am Samstag, 26. Mai 2012, 10:50:11 schrieb Rudolf Koenig:
> > updatefhem <stable|svn> [install|housekeeping [clean]]
>
> Ich finde die "housekeeping" Option ueberfluessig (oder ich verstehe es
> nicht
naja.. mein gedanke dabei war die "abwärtskompatibilität". falls jemand noch
> > updatefhem <stable|svn> [install|housekeeping [clean]]
>
> Ich finde die "housekeeping" Option ueberfluessig (oder ich verstehe es
> nicht
die alte / eine abweichende struktur installiert hat, sollte aus meiner sicht
nicht ein 'updatefhem svn install' sofort alles "überbügeln" sondern erstmal
so funktionieren wie aktuell: erst eine warnung, das sich der befehl geändert
hat, usw. erst wenn _einmalig_ das housekeeping ausgeführt wurde, unterstützt
updatefhem nur noch
'updatefhem <stable|svn> [install]'
vorher jedoch wie gerade beschrieben
'updatefhem <stable|svn> [install|housekeeping [clean]]'
jetzt klarer?
Martin Fischer
May 31, 2012, 1:50:06 PM5/31/12
to fhem-de...@googlegroups.com
Rudolf Koenig
Jun 1, 2012, 3:49:42 AM6/1/12
to fhem-de...@googlegroups.com
> falls jemand noch die alte / eine abweichende struktur installiert hat,
> sollte aus meiner sicht nicht ein 'updatefhem svn install' sofort alles
> "�berb�geln" sondern erstmal so funktionieren wie aktuell
> sollte aus meiner sicht nicht ein 'updatefhem svn install' sofort alles
Ich bin da nach etwas nachdenken anderer Meinung: wer updatefhem macht, dem ist
bewusst (bzw. sollte sein), dass an seinem System Aenderungen durchgefuehrt
werden, die das System evtl. unbrauchbar machen. Wer keine Ueberraschungen
haben will, der soll es vorher testen oder per Hand machen, oder updatefhem
nicht aufrufen.
Wer update gemacht hat, der ist auf dem neuesten Stand, ohne wenn und aber.
Darauf sollte sich der Entwickler und der Anwender verlassen koennen.
Martin Fischer
Jun 1, 2012, 8:35:08 AM6/1/12
to fhem-de...@googlegroups.com
Am Freitag, 1. Juni 2012, 09:49:42 schrieb Rudolf Koenig:
> [...]
dann werde ich das berücksichtigen.
> [...]
> Ich bin da nach etwas nachdenken anderer Meinung: wer updatefhem macht, dem
> ist bewusst (bzw. sollte sein), dass an seinem System Aenderungen
> durchgefuehrt werden, die das System evtl. unbrauchbar machen. Wer keine
> Ueberraschungen haben will, der soll es vorher testen oder per Hand machen,
> oder updatefhem nicht aufrufen.
ok.. da hast du ja inzwischen wirklich die meinung geändert ;-)
> ist bewusst (bzw. sollte sein), dass an seinem System Aenderungen
> durchgefuehrt werden, die das System evtl. unbrauchbar machen. Wer keine
> Ueberraschungen haben will, der soll es vorher testen oder per Hand machen,
> oder updatefhem nicht aufrufen.
dann werde ich das berücksichtigen.
Martin Fischer
Jun 1, 2012, 5:26:24 PM6/1/12
to fhem-de...@googlegroups.com
Am Montag, 28. Mai 2012, 11:07:29 schrieb Rudolf Koenig:
bei mir gibt es _heute_ probleme:
ein frisch installiertes 5.2 und dann updatefhem:
2012.06.01 23:13:36 0: Server started (version 5.2 from 2011-12-31 ($Id:
fhem.pl 1159 2011-12-31 13:31:58Z rudolfkoenig $), pid 21178)
2012.06.01 23:13:46 1: Got http://fhem.de/fhemupdate/filetimes.txt, length:
8610
2012.06.01 23:13:46 1: Got http://fhem.de/fhemupdate/00_CM11.pm, length: 19833
2012.06.01 23:13:46 1: Got http://fhem.de/fhemupdate/00_CUL.pm, length: 26521
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/00_FHZ.pm, length: 19358
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/00_HMLAN.pm, length: 9565
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/00_KM271.pm, length:
14151
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/00_LIRC.pm, length: 2405
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/00_TCM.pm, length: 18319
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/00_TUL.pm, length: 25521
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/01_FHEMWEB.pm, length:
60633
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/02_RSS.pm, length: 9712
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/09_BS.pm, length: 3059
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/09_CUL_FHTTK.pm, length:
9000
2012.06.01 23:13:47 1: Got http://fhem.de/fhemupdate/09_USF1000.pm, length:
4432
2012.06.01 23:13:48 1: Got http://fhem.de/fhemupdate/10_CUL_HM.pm, length:
64198
bricht dann ab mit:
File size for 10_CUL_HM.pm (64198) does not correspond to filetimes.txt entry
(64312)
sind hatte dann mal in 99_updatefhem die 10_CUL_HM.pm überspringen lassen,
dann kamen weitere abbrüche, wie z.b. mit
File size for 46_TRX_LIGHT.pm (14130) does not correspond to filetimes.txt
entry (14041)
File size for 99_backup.pm (640) does not correspond to filetimes.txt entry
(4917)
File size for 99_updatefhem.pm (13924) does not correspond to filetimes.txt
entry (13964)
dann habe ich 5.2 erneut frisch installiert und in 99_updatefhem.pl das
$sdir = "/fhemupdate";
auf
$sdir = "/fhemupdate3/stable";
gesetzt.. dann wieder abbruch:
File size for commandref.html (278937) does not correspond to filetimes.txt
entry (78937)
da scheint was mit den filetimes.txt nicht zu stimmen.
auch mit dem 99_updatefhem.pm aus dem svn im frisch installiertem 5.2 kommt
der abbruch bei 10_CUL_HM.pm
allerdings kann ich auf einer frischen 5.2 mit aktuellem updatefhem aus dem
svn ein updatefhem housekeeping machen!
Andreas Schaller
Jun 1, 2012, 6:01:42 PM6/1/12
to fhem-de...@googlegroups.com
Hallo Martin ich habe heute die gleiche Fehlermeldung nach updatefhem bekommen.
Martin Fischer
Jun 1, 2012, 6:31:23 PM6/1/12
to fhem-de...@googlegroups.com
Am Freitag, 1. Juni 2012, 15:01:42 schrieb Andreas Schaller:
> Hallo Martin ich habe heute die gleiche Fehlermeldung nach updatefhem
> bekommen.
danke andreas!
> Hallo Martin ich habe heute die gleiche Fehlermeldung nach updatefhem
> bekommen.
da muss rudi mal auf dem server nachsehen. da scheint irgendwas mit der
erzeugung der filetimes.txt nicht in ordnung zu sein. wir sind da zur zeit
etwas heftig am basteln ;-)
Rudolf Koenig
Jun 2, 2012, 3:31:59 AM6/2/12
to fhem-de...@googlegroups.com
> File size for 10_CUL_HM.pm (64198) does not correspond to filetimes.txt entry
> (64312)
Stimmt, das hochgeladene filetimes.txt war nicht im Sync mit der Datei und ich
> (64312)
verstehe noch nicht wieso. Hab alles neu generiert, jetzt stimmt es, jedenfalls
klappt update bei mir. Wuesste gerne, woran das lag, will nicht jeden Tag alles
neu generieren/hochladen.
Achtung: ein wiederholtes update dauert laenger und erzeugt die neue
Verzeichnisstruktur automatisch (das ist so gewollt), und bei "update ?"
stuerzt fhem ab (das ist ein Bug :).
Martin Fischer
Jun 2, 2012, 1:31:39 PM6/2/12
to fhem-de...@googlegroups.com
Am Samstag, 2. Juni 2012, 09:31:59 schrieb Rudolf Koenig:
> [...]
updatefhem raus; es wird auf den befehl 'backup' zurückgegriffen.
backups werden _immer_ und auch _nur_ _dann_ ausgeführt, wenn auch was zu
updaten ist. wenn nichts zu aktualisieren ist, kommt nun die meldung "nothing
to do.." die backups kann man komplett unterbinden, indem man das neue globale
attribut <backup_before_update> auf 0 setzt.
eingecheckt und community informiert...
damit ist erstmal der "normale" betrieb von fhem gewährleistet ohne
redundanzen in den befehlen. nun gilt es den neuen / geänderten befehl
'update' ins auge zu fassen. dazu gehts aber in dem thread
https://groups.google.com/d/topic/fhem-developers/tRrx4SLMliI/discussion
weiter.
> [...]
> Achtung: ein wiederholtes update dauert laenger und erzeugt die neue
> Verzeichnisstruktur automatisch (das ist so gewollt), und bei "update ?"
> stuerzt fhem ab (das ist ein Bug :).
das mit dem 'updatefhem ?' ist gefixed. die backup-routine ist nun aus
> Verzeichnisstruktur automatisch (das ist so gewollt), und bei "update ?"
> stuerzt fhem ab (das ist ein Bug :).
updatefhem raus; es wird auf den befehl 'backup' zurückgegriffen.
backups werden _immer_ und auch _nur_ _dann_ ausgeführt, wenn auch was zu
updaten ist. wenn nichts zu aktualisieren ist, kommt nun die meldung "nothing
to do.." die backups kann man komplett unterbinden, indem man das neue globale
attribut <backup_before_update> auf 0 setzt.
eingecheckt und community informiert...
damit ist erstmal der "normale" betrieb von fhem gewährleistet ohne
redundanzen in den befehlen. nun gilt es den neuen / geänderten befehl
'update' ins auge zu fassen. dazu gehts aber in dem thread
https://groups.google.com/d/topic/fhem-developers/tRrx4SLMliI/discussion
weiter.
Reply all
Reply to author
Forward
0 new messages