Hinweis/Notice: updatefhem geändert!

[Martin Fischer]

Am Dienstag, 22. Mai 2012, 14:20:09 schrieb PanTau:
> [...]
> updatefhem backup hat ein leeres tar-Archiv bei mir angelegt.
> Ursache:
> Tar folgt keinen symlinks...
>
> Rudi hatte in REV 1277 den Aufruf von tar geändert, um das zu unterstützen

ja, das stimmt. wir waren beim wegfall von "-h" also "symlinks folgen" beide
unsicher. aber nun stehen wir erneut vor einem problem:
fhem auf fritzbox wird immer populärer (auch wenn ich persönlich nichts davon
halte ). und das tar auf der fritzbox kennt "h" als argument nicht. mich
wundert nur, das es vorher mit "h" noch keine rückmeldung gab, das backup auf
der fritzbox nicht funktioniert hat.

welchen tot sollen wir nun sterben? oder welche (mit vertretbaren aufwand für
_beide_ seiten) alternative gibt es?

das einzige was mir spontan einfällt, wäre das "updatefhem backup" erstmal die
verzeichnisse scannt und prüft ob sich dort symlinks befinden. wenn ja dann
tar mit "h", wenn nein dann ohne "h" aufrufen. die frage die ich mir dabei
stelle: welche baustelle reissen wir damit dann auf?

> [...]
> Diese Änderung ist nun leider wieder verloren gegangen...
> (Ich hoffe das gilt jetzt nicht für alle Änderungen seitdem ...)

den letzten satz kann ich gerade nicht nachvollziehen. welche änderungen
sollten "seitdem" _noch_ verloren gegangen sein?

wie bereits geschrieben, hat updatefhem neben der housekeeping geschichte im
kern folgende änderungen/neuerungen erfahren: $modpath/www wird angelegt,
FHEM.backup ist nun backup und bei tar fiel das argument "h" weg, die endung
wurde von .tgz auf tar.gz umgestellt, fhem.cfg wird gesichert und ab morgen
ist der timestamp im archivname dateisystemkonformer
(FHEM-20120524_092616.tar.gz).

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Martin!

Natürlich hatte ich, nachden 'updatefhem housekeeping' auf der SuSE 12.1
Maschine nicht funktionierte, ein normales updatefhem gemacht. Auch die
Versuche an den folgenden Tagen, einschließlich des Löschens der
filetimes.txt haben kein positives Ergebnis bewirkt. So hatte ich mich
schon zu einem Status Quo entschlossen und wollte auf fhem 5.3 warten. Aber
es hat mir keine Ruhe gelassen ud so habe ich das Update heute noch einmal
angeschoben... und siehe da es funktioniert wie von euch geplant. Danke,
wer auch immer das bewirkt hat.


> alles wird gut
>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Donnerstag, 24. Mai 2012, 09:01:23 schrieb ilmtuelp0815:
> Aber
> es hat mir keine Ruhe gelassen ud so habe ich das Update heute noch einmal
> angeschoben... und siehe da es funktioniert wie von euch geplant. Danke,
> wer auch immer das bewirkt hat.

prima, das freut mich zu hören

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> fhem auf fritzbox wird immer populärer (auch wenn ich persönlich nichts
davon
> halte ). und das tar auf der fritzbox kennt "h" als argument nicht.

Bei mir schon:
BusyBox v1.19.4 (2012-04-24 14:54:37 CEST) multi-call binary.

Usage: tar -[cxtzjhvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...

Create, extract, or list files from a tar file

Operation:
        c       Create
        x       Extract
        t       List
        f       Name of TARFILE ('-' for stdin/out)
        C       Change to DIR before operation
        v       Verbose
        z       (De)compress using gzip
        j       (De)compress using bzip2
        O       Extract to stdout
        h       Follow symlinks
        X       File with names to exclude
        T       File with names to include

Zugegeben, daß muß nicht immer so sein (habe ne 7390 mit freetz, was den
Unterschied machen kann), aber auch mein OpenWRT Router hat das "h", mein
Ubuntu sowieso.
Mein Windows hat gar kein tar Wie machen das die Kollegen da
eigentlich? Oder wird so eine Randgruppe einfach ignoriert?
Ich finde Kompatibilität wichtig, aber ich brauche auch das Symlink feature.
Könnte man nicht tar -h "probeweise" aufrufen und je nach Rückgabewert,
dann die Version mit oder ohne "h" nehmen?
Vorausgesetzt irgendjemand hat noch Uralt busybox Versionen ohne "h" auf
embedded Systemen...

>> [...]
>> Diese Änderung ist nun leider wieder verloren gegangen...
>> (Ich hoffe das gilt jetzt nicht für alle Änderungen seitdem ...)
>den letzten satz kann ich gerade nicht nachvollziehen. welche änderungen
>sollten "seitdem" _noch_ verloren gegangen sein?
Ich hatte befürchtet das alle Änderungen seit der Rev 1277 weg sein
könnten, falls Du nämlich das "h" nicht absichtlich
entfernt hättest - was ich mir beim besten Willen nicht vorstellen konnte
, sondern Deine Änderungen auf einem alten Branch
des SVN gemacht hast - was ich jetzt auch nicht mehr verstehe, so eine Idee
gehabt zu haben - macht ja keiner

>wie bereits geschrieben, hat updatefhem neben der housekeeping geschichte
im
>kern folgende änderungen/neuerungen erfahren: $modpath/www wird angelegt,
>FHEM.backup ist nun backup und bei tar fiel das argument "h" weg, die
endung
>wurde von .tgz auf tar.gz umgestellt, fhem.cfg wird gesichert und

Genau das ist die Doku, die ich in meinem anderen Posting vermisst habe.
Meiner Meinung nach gehört in das Kapitel "updatefhem" eine Auflistung der
"inkompatiblen" Änderungen.
Einfach übersichtlicher, schneller zu finden, auch wenn "backup" woanders
beschrieben wird, aber eben nicht als Änderung.
Ich denke an das nächste Release 5.2 => 5.3, für alle die das hier in der
Gruppe eh schon mitbekommen haben, ist das naklar nicht nötig ...

Gruß

Peter


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

>
> bevor tar allerdings loslegt, habe ich dem backup noch die sicherung der
> .cfg
> "spendiert". das war vorher nämlich nicht im backup.

 
PANIK: hatte ich bisher noch nicht gemerkt. Gute Sache!. Ich habe
allerdings einige .cfg im gleichen Verzeichnis, die ich per include in
fhem.cfg
einbinde, könnte man die nicht auch mit backuppen? Warum nicht alles unter
modpath backuppen - ok ohne Inhalt von backuppath...?
 

>
> > Problem:
> > bei  mir ist attr global modpath /usr/local/lib. Darin ist ein symlink
> FHEM
> > => /home/FHZ/fhem/FHEM. /home/FHZ/fhem ist das Hauptverzeichnis und
> enthält
> > die fhem.pl und die fhem.cfg.
> > updatefhem versucht nun unter /usr/local/lib Verzeichnisse anzulegen und
> > hat keine Schreibberechtigung. Ok, aber zumindest nun neu, daß fhem da
> rein
> > schreiben will.
> > Interessanterweise wird das Verzeichnis FHEM.backup unter /home/FHZ/fhem
> > angelegt, da hat fhem auch Schreibberechtigung.
> > Es scheint also in 99_updatefhem verschiedene Weisen zu geben, mit dem
> > modpath umzugehen, bzw. relative Pfade werden nicht bzgl. modpath,
> sondern
> > relativ zum Startverzeichnis von fhem.pl gebildet.....
>
> nein, updatefhem setzt den pfad wie folgt zusammen:
> $modpath = $attr{global}{modpath});
> $moddir = "$modpath/FHEM";
> $wwwdir = "$modpath/www";
>
> es wird also immer auf $attr{global}{modpath}, in deinem fall
> /usr/local/lib
> zurückgegriffen und somit ist eine einheitliche behandlung auf basis des
> globalen attributes modpath gegeben.

 
Einspruch:
wie ich oben geschrieben habe ist bei mir
modpath = /usr/local/lib
und
attr global backupdir FHEM.backup
also kein absoluter Pfad, nur ein Verzeichnisname.
Dieses Verzeichnis wird dann anscheinend nicht unter modpath angelegt,
sondern an dem Ort an dem fhem.pl liegt, bei
mir /home/FHZ/fhem, und das habe ich nirgends als attr global definiert.
99_updatefhem.pl:
 if ($attr{global}{backupdir}) {
      $backupdir = $attr{global}{backupdir};  
    } else {
      $backupdir = "$modpath/backup";
    }
Ich vermute backupdir nicht als absoluten Pfad zu definieren ist halt keine
gute Idee, oder?


> um nun aber auch schlussendlich eine lösung anzubieten, würde ich
> vorschlagen,
> das du in deiner config den modpath wie folgt änderst:
> "attr global modpath /usr/local/lib/fhem" wobei dann fhem in symlink auf
> dein
> "/home/FHZ/fhem/" ist. das sollte meines erachtens nach erstmal ein
> gangbarer
> weg sein.
>
> Meine Lösung ist attr global modpath /home/FHZ/fhem.
Aufruf:
updatefhem
Abbruch mit Hinweis auf Änderung - ok Leute sollen auf Umstieg hingewiesen
werden.
Aber ist es evtl nicht besser "preserve" als default zu nehmen?
Bei updatefhem backup erfolgt ja auch kein Hinweis auf die neuen
Features....

updatefhem housekeeping clean yes
=> HEUREKA!

Gruß

Peter

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Donnerstag, 24. Mai 2012, 13:25:30 schrieb PanTau:
> [...]
> > halte ). und das tar auf der fritzbox kennt "h" als argument nicht.
>
> Bei mir schon:
> BusyBox v1.19.4 (2012-04-24 14:54:37 CEST) multi-call binary.
>
> Usage: tar -[cxtzjhvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...
> [...]
> Zugegeben, daß muß nicht immer so sein (habe ne 7390 mit freetz, was den
> Unterschied machen kann), aber auch mein OpenWRT Router hat das "h", mein
> Ubuntu sowieso.

zitat dazu von Rudi, der getestet hat (@rudi: das ist _keine_ schuldzuweisung ).

Am Samstag, 19. Mai 2012, 10:09:54 schrieben Sie:
>   - tar funktioniert so auf dem FritzBox nicht, tar hat da folgende
> Optionen: Options:
>             c       Create
>             x       Extract
>             t       List
>       Archive format selection:
>       File selection:
>             f       Name of TARFILE or "-" for stdin
>             O       Extract to stdout
>             exclude File to exclude
>             X       File with names to exclude
>             C       Change to DIR before operation
>             v       Verbose
>     p ist beim einpacken eh nutzlos, beim h bin ich unsicher, ob das
> gewuenscht ist. --total wird unter OSX auch nicht angeboten, und sollte
> laut web --totals heissen.

du siehst: wir haben uns darüber gedanken gemacht und auch getestet. hier
haben wir wieder das gleiche problem wie mit dem .tar.gz versus .tgz oder mit
/usr/share/fhem versus /usr/local/lib. es ist halt schwer alles zu
berücksichtigen. und im zweifel nimmt man dann erstmal den kleinsten
gemeinsamen nenner. bei dem fritzbox image von avm bzw. rudi fehlt tar halt
die unterstützung für symlinks.

> Mein Windows hat gar kein tar Wie machen das die Kollegen da
> eigentlich? Oder wird so eine Randgruppe einfach ignoriert?

hierzu verweigere ich jetzt mal die aussage. sonst werde ich noch geterrt und
gefedert

> Ich finde Kompatibilität wichtig, aber ich brauche auch das Symlink feature.
> Könnte man nicht tar -h "probeweise" aufrufen und je nach Rückgabewert,
> dann die Version mit oder ohne "h" nehmen?

ich bin bei dir. nur müssen wir einen weg finden, wie wir das so hinbekommen,
das beide abgedeckt werden. ich werd das mal bei fhem-devel abkippen, ob da
noch die eine oder andere idee vorliegt. denn die zu sichernde verzeichnisse
nach symlinks zu scannen wäre zwar denkbar, was ist aber wenn ein user in
unwissenheit der fehlenden option auf einer fritzbox einfach im $modpath
symlinks anlegt?

> Vorausgesetzt irgendjemand hat noch Uralt busybox Versionen ohne "h" auf
> embedded Systemen...

ja, avm um nur eines zu nennen! und die liefern fhem sogar in ihrer
laborumgebung an leute aus, die diese mailingslist wahrscheinlich niemals
besuchen

> [...]
> Ich hatte befürchtet das alle Änderungen seit der Rev 1277 weg sein
> könnten, falls Du nämlich das "h" nicht absichtlich
> entfernt hättest - was ich mir beim besten Willen nicht vorstellen konnte
>
> , sondern Deine Änderungen auf einem alten Branch
>
> des SVN gemacht hast - was ich jetzt auch nicht mehr verstehe, so eine Idee
> gehabt zu haben - macht ja keiner

sag niemals nie aber ich kann dich beruhigen.. in diesem fall war / ist es
definitiv _nicht_ so gewesen..

>> wie bereits geschrieben, hat updatefhem neben der housekeeping geschichte
>> im kern folgende änderungen/neuerungen erfahren: $modpath/www wird
>> angelegt, FHEM.backup ist nun backup und bei tar fiel das argument "h" weg,
>> die endung wurde von .tgz auf tar.gz umgestellt, fhem.cfg wird gesichert
>> und
>
> Genau das ist die Doku, die ich in meinem anderen Posting vermisst habe.
> Meiner Meinung nach gehört in das Kapitel "updatefhem" eine Auflistung der
> "inkompatiblen" Änderungen.

ok.. dann habe ich das jetzt verstanden. das gilt es zu überdenken.

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Donnerstag, 24. Mai 2012, 14:27:45 schrieb PanTau:
> > bevor tar allerdings loslegt, habe ich dem backup noch die sicherung der
> > .cfg
> > "spendiert". das war vorher nämlich nicht im backup.
>
> PANIK: hatte ich bisher noch nicht gemerkt. Gute Sache!. Ich habe
> allerdings einige .cfg im gleichen Verzeichnis, die ich per include in
> fhem.cfg
> einbinde, könnte man die nicht auch mit backuppen? Warum nicht alles unter
> modpath backuppen - ok ohne Inhalt von backuppath...?

ich habe auch viele includes PANIK ne, spass beseite: klar sollte das mit
rein, ich hatte es nur nicht auf die schnelle umgesetzt. die ganze
housekeeping / backup anpassungen habe ich in - sagen wir mal - einer nacht
und nebel aktion gemacht. was jetzt nicht heisst, das wir / ich nicht getestet
habe, sondern es in zwei nächten umgesetzt wurde. aber so einfach ist das dann
auch wieder nicht, da ja theoretisch der user seine includes über das ganze
system verteilen könnte. dann hilft zwar ein parsen der config nach include,
doch dann muss die struktur auch im backup für den fall eines restores
nachgebildet werden. auch das ist halt noch eine baustelle, die es gilt zu
stopfen.

hier muss ich mal etwas mehr quoten, da sonst der zusammenhang flöten geht..
> [...]
> > nein, updatefhem setzt den pfad wie folgt zusammen:
> > $modpath = $attr{global}{modpath});
> > $moddir = "$modpath/FHEM";
> > $wwwdir = "$modpath/www";
> >
> > es wird also immer auf $attr{global}{modpath}, in deinem fall
> > /usr/local/lib
> > zurückgegriffen und somit ist eine einheitliche behandlung auf basis des
> > globalen attributes modpath gegeben.
>
> Einspruch:
> wie ich oben geschrieben habe ist bei mir
> modpath = /usr/local/lib
> und
> attr global backupdir FHEM.backup
> also kein absoluter Pfad, nur ein Verzeichnisname.
> Dieses Verzeichnis wird dann anscheinend nicht unter modpath angelegt,
> sondern an dem Ort an dem fhem.pl liegt, bei
> mir /home/FHZ/fhem, und das habe ich nirgends als attr global definiert.
> 99_updatefhem.pl:
>  if ($attr{global}{backupdir}) {
>       $backupdir = $attr{global}{backupdir};
>     } else {
>       $backupdir = "$modpath/backup";
>     }
> Ich vermute backupdir nicht als absoluten Pfad zu definieren ist halt keine
> gute Idee, oder?

hier sehe ich tatsächlich eine ungewollte änderung. da ist mir scheinbar ein
fehler unterlaufen! danke für den hinweis!

es muss korrekterweise heissen:
if ($attr{global}{backupdir}) {
  $backupdir = "$modpath/$attr{global}{backupdir}";
} else {
  $backupdir = "$modpath/backup";
}

ich werds gleich mal ändern und einchecken. bitte ab morgen > 08:00 uhr (wegen
svn-mirror für updatefhem) mal eine rückmeldung geben.

ftr:
in 5.2 wird $backupdir wie folgt definiert:
my $backupdir = AttrVal("global", "backupdir", "/tmp/FHEM_Backup");

im svn rev. 1519:
## backup by RueBe, simplified by rudi
my $moddir = (-d "FHEM.X" ? "FHEM.X" : "$attr{global}{modpath}/FHEM");
my $bdir = AttrVal("global", "backupdir", "$moddir.backup");

und nu meiner einer

aber ich denke wir werden das nun auch bald abschliessen

> > um nun aber auch schlussendlich eine lösung anzubieten, würde ich
> > vorschlagen,
> > das du in deiner config den modpath wie folgt änderst:
> > "attr global modpath /usr/local/lib/fhem" wobei dann fhem in symlink auf
> > dein
> > "/home/FHZ/fhem/" ist. das sollte meines erachtens nach erstmal ein
> > gangbarer
> > weg sein.
> >
> > Meine Lösung ist attr global modpath /home/FHZ/fhem.

oder so

> Aufruf:
> updatefhem
> Abbruch mit Hinweis auf Änderung - ok Leute sollen auf Umstieg hingewiesen
> werden.
> Aber ist es evtl nicht besser "preserve" als default zu nehmen?

gilt zu diskutieren -> fhem-devel

> Bei updatefhem backup erfolgt ja auch kein Hinweis auf die neuen
> Features....

das ist aber auch nicht mit dem umfang bzw. der auswirkung von housekeeping
vergleichbar

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Freitag, 25. Mai 2012, 00:17:04 schrieb Martin Fischer:
> Am Donnerstag, 24. Mai 2012, 14:27:45 schrieb PanTau:
> > > bevor tar allerdings loslegt, habe ich dem backup noch die sicherung der
> > > .cfg
> > > "spendiert". das war vorher nämlich nicht im backup.
> >
> > PANIK: hatte ich bisher noch nicht gemerkt. Gute Sache!. Ich habe
> > allerdings einige .cfg im gleichen Verzeichnis, die ich per include in
> > fhem.cfg
> > einbinde, könnte man die nicht auch mit backuppen? Warum nicht alles unter
> > modpath backuppen - ok ohne Inhalt von backuppath...?

nachtrag: per default (Makefile) ist ETCDIR=/etc also würde zwar ein
backup von $modpath bei dir wirkung zeigen aber nicht bei anderen.

daran sieht man deutlich wie komplex _freiheit_ sein kann umso komplexer
die logik die das dann auffangen soll / muss.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Auch auf meiner "normalen" Fritzbox 7390 ist der h parameter bei tar
vorhanden:

BusyBox v1.18.5 (2011-10-27 16:00:43 CEST) multi-call binary.

Usage: tar -[cxtvO] [-X FILE] [-f TARFILE] [-C DIR] [FILE]...

Create, extract, or list files from a tar file

Operation:
        c       Create
        x       Extract
        t       List
Options:
        f       Name of TARFILE ('-' for stdin/out)
        C       Change to DIR before operation
        v       Verbose
        O       Extract to stdout
        h       Follow symlinks
        exclude File to exclude
        X       File with names to exclude
        T       File with names to include

Gruß
René

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

danke rene für die rückmeldung!

Am Freitag, 25. Mai 2012, 02:40:00 schrieb Echo:
> Auch auf meiner "normalen" Fritzbox 7390 ist der h parameter bei tar
> vorhanden:

rudi hat das heute auch noch mal korrigiert. bei der 7390 ist es dabei, bei
der 7270 nicht.

das thema wird gerade auf der fhem-developers liste behandelt.

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guido]

                                                       

Hallo,

habe vorgestern auf meiner FB7390 updatefhem houskeeping clean yes
ausgeführt, ist auch problemlos durchgelaufen.

2012.05.23 10:12:01.815 1: updatefhem Housekeeping finished, 'shutdown restart' is recommended!
2012.05.23 10:12:01.818 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!


2012.05.23 10:19:41.779 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 10305)

Was mich nur wundert ist das ich seitdem kein Update mehr erhalte.

Was ich versucht habe:

1. filetimes.txt gelöscht und updatefhem ausgeführt, es wurden alle Dateien erneut heruntergeladen shutdown restart ausgeführt
   2012.05.24 10:55:39.367 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
    2012.05.24 10:56:09.051 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 4823)

    immer noch alte fhem.pl

2. 2012.05.25 13:00:55.678 1: updatefhem updated FHEM/99_updatefhem.pm
   damit erhalte ich diese Version:  $Id: 99_updatefhem.pm 1569 2012-05-20 15:24:11Z mfr69bs $ ist doch auch schon was älter
   dann nochmal updatefhem fhem.pl ausgeführt
   2012.05.25 13:12:52.813 1: updatefhem updated ./fhem.pl
   2012.05.25 13:12:52.837 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
   2012.05.25 13:13:03.378 0: Server shutdown
   2012.05.25 13:13:15.378 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 8687)
   
   immer noch die vom 12.05

Woran kann das liegen? Ist das nur bei mir so ?

fragende Grüße

Guido



Am Freitag, 25. Mai 2012 13:00:25 UTC+2 schrieb Martin Fischer:
>
> danke rene für die rückmeldung!
>
> Am Freitag, 25. Mai 2012, 02:40:00 schrieb Echo:
> > Auch auf meiner "normalen" Fritzbox 7390 ist der h parameter bei tar
> > vorhanden:
>
> rudi hat das heute auch noch mal korrigiert. bei der 7390 ist es dabei,
> bei
> der 7270 nicht.
>
> das thema wird gerade auf der fhem-developers liste behandelt.
>
> gruss martin
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

Am 25.05.2012 14:05, schrieb Guido:
> habe vorgestern auf meiner FB7390 updatefhem houskeeping clean yes
> ausgeführt, ist auch problemlos durchgelaufen.

Bei mir genau so.

> Was mich nur wundert ist das ich seitdem kein Update mehr erhalte.

Dito.

> 2. 2012.05.25 13:00:55.678 1: updatefhem updated FHEM/99_updatefhem.pm
>    damit erhalte ich diese Version:  $Id: 99_updatefhem.pm 1569 2012-05-20 15:24:11Z mfr69bs $ ist doch auch schon was älter
>    dann nochmal updatefhem fhem.pl ausgeführt
>    2012.05.25 13:12:52.813 1: updatefhem updated ./fhem.pl
>    2012.05.25 13:12:52.837 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
>    2012.05.25 13:13:03.378 0: Server shutdown
>    2012.05.25 13:13:15.378 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 8687)
>    
>    immer noch die vom 12.05
>
> Woran kann das liegen? Ist das nur bei mir so ?

Bei mir haben fhem.pl und alle Dateien im FHEM-Verzeichnis bis auf die
von mir erstellten Dateien als Erstellungsdatum den Zeitpunkt des
Herunterladens plus 1 Stunde (Sommerzeit?). Sollte hier nicht das
Dateidatum des Servers erscheinen? Ich glaube, bisher war das so.

Nach manuellem Update der fhem.pl auf Version 1588 von Heute steht nach
dem Neustart im log:
Server started (version =VERS= from =DATE= ($Id$), pid 8706)

Dann habe ich auch die 99_updatefhem.pm aus dem SVN installiert. Danach
noch einmal "updatefhem 99_updatefhem.pm" lädt wieder die alte Datei
herunter.

Viele Grüße,
Christian

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Puschel74]

                                               

Hallo,

ich lasse bei mir grundsätzlich jeden Samstag abend um 21:00 ein updatefhem
mit anschliessendem
shutdown restart durchlaufen.
Ich hab das updatefhem housekeeping clean yes wie früher schonmal in diesem
fred angesprochen
bereits hinter mir.
Heute listet mir fhem im log folgendes


2012.05.26 21:15:47 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 5534)

nach dem restart auf.
Ok, das war vor fast 3 Stunden aber wir waren auch eingeladen und ich bin gerade eben wieder an mein fhem dran gekommen.

Soll das so sein?
Wenn ja ist ja alles ok.
Achso ja. neue Module wurden laut log nicht installiert - siehe

2012.05.26 21:12:30 2: FS20 set Wasserpumpe off
2012.05.26 21:15:00 3: updatefhem : update finished
2012.05.26 21:15:20 0: Server shutdown
2012.05.26 21:15:25 2: Telnet port 7072 opened
2012.05.26 21:15:26 2: FHEMWEB port 8083 opened
2012.05.26 21:15:26 2: FHEMWEB port 8084 opened
2012.05.26 21:15:26 2: FHEMWEB port 8085 opened
2012.05.26 21:15:26 3: Opening CUL1 device /dev/ttyACM0
2012.05.26 21:15:27 3: Setting CUL1 baudrate to 9600
2012.05.26 21:15:27 3: CUL1 device opened
2012.05.26 21:15:27 3: Opening CUNO1 device 192.168.2.28:2323
2012.05.26 21:15:27 3: CUNO1 device opened
2012.05.26 21:15:27 3: Opening CUNO2 device 192.168.2.24:2323
2012.05.26 21:15:27 3: CUNO2 device opened
2012.05.26 21:15:47 0: Server started (version 5.2+SVN from 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 5534)

Grüße

Am Samstag, 26. Mai 2012 19:39:16 UTC+2 schrieb Christian Herrmann:
>
> Hallo,
>
> Am 25.05.2012 14:05, schrieb Guido:
> > habe vorgestern auf meiner FB7390 updatefhem houskeeping clean yes
> > ausgef�hrt, ist auch problemlos durchgelaufen.
>
> Bei mir genau so.
>
> > Was mich nur wundert ist das ich seitdem kein Update mehr erhalte.
>
> Dito.
>
> > 2. 2012.05.25 13:00:55.678 1: updatefhem updated FHEM/99_updatefhem.pm
> >    damit erhalte ich diese Version:  $Id: 99_updatefhem.pm 1569
> 2012-05-20 15:24:11Z mfr69bs $ ist doch auch schon was �lter
> >    dann nochmal updatefhem fhem.pl ausgef�hrt
> >    2012.05.25 13:12:52.813 1: updatefhem updated ./fhem.pl
> >    2012.05.25 13:12:52.837 1: updatefhem New version of fhem.pl,
> 'shutdown restart' is required!
> >    2012.05.25 13:13:03.378 0: Server shutdown
> >    2012.05.25 13:13:15.378 0: Server started (version 5.2+SVN from
> 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid
> 8687)
> >    
> >    immer noch die vom 12.05
> >
> > Woran kann das liegen? Ist das nur bei mir so ?
>
> Bei mir haben fhem.pl und alle Dateien im FHEM-Verzeichnis bis auf die
> von mir erstellten Dateien als Erstellungsdatum den Zeitpunkt des
> Herunterladens plus 1 Stunde (Sommerzeit?). Sollte hier nicht das
> Dateidatum des Servers erscheinen? Ich glaube, bisher war das so.
>
> Nach manuellem Update der fhem.pl auf Version 1588 von Heute steht nach
> dem Neustart im log:
> Server started (version =VERS= from =DATE= ($Id$), pid 8706)
>
> Dann habe ich auch die 99_updatefhem.pm aus dem SVN installiert. Danach
> noch einmal "updatefhem 99_updatefhem.pm" l�dt wieder die alte Datei
> herunter.
>
> Viele Gr��e,
> Christian
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo zusammen,

ich habe am 21.05. "updatefhem housekeeping clean yes" durchgeführt. Lief
alles ohne Fehlermeldung durch.
Leider habe ich so das Gefühl, dass ich seither mit "updatefhem" keine
Updates mehr bekomme. Im SVN-Repo befinden sich Änderungen von vor zwei
Tagen, die aber irgendwie nie bei mir ankamen.
Kann es sein, dass da was nicht stimmt?

Gruß, Thorsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Achtung: Sammelantwort für Guido, Christian, puschel74 und thebartman

Rudi schrieb heute, das er während unserer Test wohl das Uploaden neuer
Dateien zwecks debugging auskommentiert hatte. Das sollte die Ursache Eurer
fehlenden Updates behoben haben.

Also einfach nochmal probieren.

Gruß Martin

Am Freitag, 25. Mai 2012, 05:05:22 schrieb Guido:
> Hallo,
>
> habe vorgestern auf meiner FB7390 updatefhem houskeeping clean yes
> ausgeführt, ist auch problemlos durchgelaufen.
>
> 2012.05.23 10:12:01.815 1: updatefhem Housekeeping finished, 'shutdown
> restart' is recommended! 2012.05.23 10:12:01.818 1: updatefhem New version
> of fhem.pl, 'shutdown restart' is required!
>
>
> 2012.05.23 10:19:41.779 0: Server started (version 5.2+SVN from 2012-05-13
> ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 10305)
>
> Was mich nur wundert ist das ich seitdem kein Update mehr erhalte.
>
> Was ich versucht habe:
>
> 1. filetimes.txt gelöscht und updatefhem ausgeführt, es wurden alle Dateien
> erneut heruntergeladen shutdown restart ausgeführt 2012.05.24 10:55:39.367
> 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
> 2012.05.24 10:56:09.051 0: Server started (version 5.2+SVN from 2012-05-13
> ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid 4823)
>
>     immer noch alte fhem.pl
>
> 2. 2012.05.25 13:00:55.678 1: updatefhem updated FHEM/99_updatefhem.pm
>    damit erhalte ich diese Version:  $Id: 99_updatefhem.pm 1569 2012-05-20
> 15:24:11Z mfr69bs $ ist doch auch schon was älter dann nochmal updatefhem
> fhem.pl ausgeführt
>    2012.05.25 13:12:52.813 1: updatefhem updated ./fhem.pl
>    2012.05.25 13:12:52.837 1: updatefhem New version of fhem.pl, 'shutdown
> restart' is required! 2012.05.25 13:13:03.378 0: Server shutdown
>    2012.05.25 13:13:15.378 0: Server started (version 5.2+SVN from
> 2012-05-13 ($Id: fhem.pl 1559 2012-05-12 11:36:54Z rudolfkoenig $), pid
> 8687)
>
>    immer noch die vom 12.05
>
> Woran kann das liegen? Ist das nur bei mir so ?
>
> fragende Grüße
>
> Guido
>
> Am Freitag, 25. Mai 2012 13:00:25 UTC+2 schrieb Martin Fischer:
> > danke rene für die rückmeldung!
> >
> > Am Freitag, 25. Mai 2012, 02:40:00 schrieb Echo:
> > > Auch auf meiner "normalen" Fritzbox 7390 ist der h parameter bei tar
> >
> > > vorhanden:
> > rudi hat das heute auch noch mal korrigiert. bei der 7390 ist es dabei,
> > bei
> > der 7270 nicht.
> >
> > das thema wird gerade auf der fhem-developers liste behandelt.
> >
> > gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com