SVN Umzug

Begonnen von rudolfkoenig, 05 März 2023, 17:48:51

Vorheriges Thema - Nächstes Thema

DeeSPe

Tschuldigung! Wollte Dir keinen Schrecken einjagen. ;)
War mir nur beim Überfliegen aufgefallen und ich habe auch keine anderen Module gegengeprüft.
Ist natürlich möglich das die Datei vom Ersteller/Bearbeiter mit falschem Encoding gespeichert wurde.
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

xenos1984

Ich kann mich irren, aber gab es vorher im Trac nicht eine (zumindest rudimentäre) Syntax-Hervorherbung? Ich meine mich zumindest daran zu erinnern, dass Schlüsselwörter wie "sub" in dunkelrot waren...

rudolfkoenig

ZitatIch kann mich irren, aber gab es vorher im Trac nicht eine (zumindest rudimentäre) Syntax-Hervorherbung?
Du irrst dich nicht, siehe Anhang.

Syntax-Highlighting wurde von einem python library Namens pygments implementiert, die ich auf dem neuen Server auch installiert habe, nachdem ich die zwei Konfigurationszeilen vom alten trac.ini uebernommen habe.
Trac Doku fuer syntax Hihlighting gibts nur bis Trac Version 1.2 (wir haben 1.5), und da steht nur, dass, wenn pygments vorhanden ist, sie automatisch verwendet wird.
Wenn ich Trac-Logging auf DEBUG setze dann steht im Log nur folgende "pygments" Zeile:
Loading plugin "trac.mimeview.pygments" from "/usr/local/lib/python3.10/dist-packages"
sonst nichts. Ich habe jetzt 'ne Weile gesucht und probiert, ohne Ergebnis. Wenn jemand eine Idee hat, bitte melden.

xenos1984

Ich konnte nur diesen (alten) Beitrag finden:

http://stackoverflow.com/questions/2564732/source-code-syntax-highlighting-for-trac

Per Kommandozeile sollte
mimetype fhem.pl
und
svn proplist -v fhem.pl
dazu Info liefern, ob da irgendetwas falsch ist.

betateilchen

Ist es eigentlich tatsächlich so, dass seit ca. 1 Woche keine Änderungen eingecheckt wurden?
Irgendwie kann ich mir das nur schwer vorstellen.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

TomLee

Laut Änderungshistorie unter https://svn.fhem.de/trac/browser/trunk/fhem ist das wirklich so.

rudolfkoenig

Einchecken funktioniert, gerade mit CHANGED getestet.

betateilchen

Zitat von: TomLee am 13 März 2023, 12:11:03
Laut Änderungshistorie

Das sagt für mich erstmal gar nix aus, da vermutlich beides aus der gleichen Quelle stammt.

Was mich darüber hinaus irritiert, sind die unterschiedlichen Zeiten, zu denen die controls-Dateien in den vergangenen Tagen erstellt wurden.
"Normalerweise" war das immer um ca. 07:45 / 07:46 Uhr, aber in den letzten Tagen sind da Ausreißer mit 08:30 und 08:01 Uhr dabei.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: rudolfkoenig am 13 März 2023, 12:15:24
Einchecken funktioniert, gerade mit CHANGED getestet.

Ja, das habe ich auch gerade getestet.
Hast Du noch eine Erklärung für die unterschiedlichen Uhrzeiten des morgendlichen Update-Laufs?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Otto123

@Rudi Was ich die ganze Zeit schon mit leichter Sorge betrachte: Die neuen Zeiten im testweise migrierten Forum sind noch mal kolossal anders. Sieht man jetzt nur am letzten Eintrag aber mit zunehmender Anzahl wird die große Differenz sichtbarer.
Beeinflussen sich hier die beiden Prozesse (die ja identisch eingerichtet sind)?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

ZitatHast Du noch eine Erklärung für die unterschiedlichen Uhrzeiten des morgendlichen Update-Laufs?
Kurz: nein.

Lang:
Die Eintraege werden vom SMF Plugin RSS FeedPoster geholt, auf beiden Forums-Installationen, alle 15 Minuten, jeweils von der Seite
https://svn.fhem.de/trac/log/trunk?format=rss&rev=HEAD&limit=200&mode=stop_on_copy
Das automatische Einchecken heute ist im RSS mit 06:45:15 GMT gestempelt.
svn.fhem.de ist seit kurzem auf dem anderen Server, mit einem neuen Trac Version.
Trac kriegt das Eingecheckte per SVN post-commit Hook mit.
Auch im Trac HTML-Frontend wird das Ereignis mit 06:45 angegeben.
Keine Ahnung, wie der Feed Poster auf diese Zeiten kommt.

Es waere auch nett, wenn der Feed Poster andere Felder (z.Bsp. creator) aus dem RSS extrahieren koennte, ich habe aber in der Konfiguration keine Moeglichkeit dafuer gesehen.

Otto123

Um einen Einfluss auszuschließen stoppe ich mal die zweite Instanz, brauchen wir bis zum nächsten Umzug Test ja nicht.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Seit neuestem will update auf meinem Testsystem nicht mehr, es beschwert sich wie folgt:
ZitatDownloading http://fhem.de/fhemupdate/controls_fhem.txt
https://fhem.de:443: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 280) line 1.
BEGIN failed--compilation aborted at (eval 280) line 1.
Bisher war das updaten dieses Systems kein Problem, aber selbst die Installation von IO/Socket/SSL via cpan hat nicht geholfen, und auch das Aufrufen mit der -noSSL-Option liefert obige Meldung (aus der ich wegen des eval in update.pm#L29 aber auch nicht schlau werde).

Eine mögliche Erklärung, die ich dazu gefunden habe, wäre in https://metacpan.org/pod/IO::Socket::SSL#BUGS zu finden - es handelt sich um ein Win32-strawberry-Perl...

Kann das mit dem aktuellen Server-Update zusammenhängen?
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatEine mögliche Erklärung, die ich dazu gefunden habe, wäre in https://metacpan.org/pod/IO::Socket::SSL#BUGS zu finden - es handelt sich um ein Win32-strawberry-Perl...
Unter Windows wird fork mit threads realisiert, insofern kann das schon die Ursache beschreiben.
Gibt es auch Probleme, wenn du "attr global updateInBackground 0" setzt?

ZitatKann das mit dem aktuellen Server-Update zusammenhängen?
Indirekt schon. Wir verwenden da eine deutlich aktuellere Version der SSL Bibliothek (1.0.2g  1 Mar 2016 vs. 3.0.2 15 Mar 2022).

Beta-User

Das global-Attribut sollte ja sofort wirksam werden, oder? Na ja, so oder so: es hilft nicht....

Hatte schon vermutet, dass es an einem update der SSL-Version liegt, allerdings ist mir nicht so recht klar, warum das dazu führt, dass 98_update.pm anscheinend nicht mehr geladen werden kann.
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files