Hallo zusammen,
weiß jemand wer die Datei FHEM/lib/MP3/Tag.pm pflegt ?
Wegen der Warnung:
2019.09.07 10:34:07.350 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^\??({ <-- HERE ([^{}]+)}|.)/ at FHEM/lib/MP3/Tag.pm line 2944.
2019.09.07 10:34:07.351 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^({ <-- HERE [^{}]+}|\w)/ at FHEM/lib/MP3/Tag.pm line 2956.
hatte ich bereits den (vermeintlichen) Maintainer Reinerlein angesprochen -> https://forum.fhem.de/index.php/topic,103535.0.html , aber keine Reaktion erhalten.
Die Warnung hatte ich bei mir gefixt und auch über das contrib bereitgestellt, aber es sollte mal ins Repo.
Wenn sich sonst niemand dafür verantwortlich fühlt, würde ich die gefixte Version einmalig einchecken. Aber eine Maintainerschaft möchte ich deswegen für diese Datei nicht übernehmen. ;)
Grüße,
Heiko
Hallo,
in FHEM/lib leben Drittanbieter-Bibliotheken. Mir scheint, dass es sich um eine Datei aus CPAN handelt, die hier mit FHEM ausgeliefert wird:
https://metacpan.org/source/ILYAZ/MP3-Tag-1.15 (https://metacpan.org/source/ILYAZ/MP3-Tag-1.15)
Letzte Änderung dort am 22.03.2019.
GGf. ist die Warnung in CPAN schon beseitigt.
Hast Du Reinerlein schon direkt per E-Mail oder Forum-PM angeschrieben? Ich weiß nicht, um welches Modul es geht, vielleicht steht seine Adresse im Modul.
Wenn sich der Maintainer nach angemessener Zeit nicht meldet, checken wir die Datei "von Amts wegen" ein und markieren die Module als verwaist. Wenn sich kein Maintainer findet, geht so ein Modul nach contrib.
Viele Grüße
Boris
Hallo Boris,
eine PM habe ich Reinerlein soeben noch geschrieben. Schauen wir mal ob/was er antwortet.
Die Version aus dem CPAN habe ich mir angeschaut. Dieser Fix ist dort auch schon drin.
Allerdings zeigen die Versionen beider Dateien auch sonst recht deutliche Unterschiede.
Deswegen wäre ich mir unsicher ob man die CPAN-Version übernehmen sollte oder doch lieber nur diesen Fix eincheckt.
Grüße,
Heiko
Hallo Heiko,
es ist m.E. übersichtlicher und nachhaltiger, in FHEM/lib immer die Originale aus CPAN zu halten. Ich würde erwarten, dass das Modul auch mit der aktuellen Version von MP3::Tag (und den anderen benötigten Bibliotheken) läuft. Magst Du das mal ausprobieren und bei Dir in FHEM/lib/MP3 alle Dateien durch die aktuellen austauschen?
Viele Grüße
Boris
Hallo Boris,
habe es gerade mal bei mir ausgetauscht.
Sieht erstmal gut aus.
Ich glaube das Modul wird von Sonos verwendet. Bin mir aber nicht sicher wo noch.
Macht vielleicht Sinn wenn ich es im contrib wieder anbiete und die User im oben angegebenen Thread bitte, diese Version bei sich auch zu testen ?
LG,
Heiko
Ich bin der Meinung, dass FHEM überhaupt keine Drittanbieterpakete ausliefern sollte, für die es fertige Pakete in der Linux Paketverwaltung gibt. In diesem Fall ist es Aufgabe des Anwenders, diese Pakete auf Betriebssystemebene aktuell zu halten. Bei vielen anderen Modul-Abhängigkeiten verfahren wir seit Urzeiten genau so.
Im vorliegenden Fall wäre das Paket für Debian beispielsweise als libmp3-tag-perl in der Paketverwaltung verfügbar.
Gebe Udo völlig recht. Nur wie in dem vorliegenden Fall verfahren ?
Einfach entfernen ist wahrscheinlich nicht das Mittel der Wahl.
Blöd, dass der in Maintainer.txt eingetragene Developer (Reinerlein) sich seit September noch nicht dazu geäußert hat.
Dann könnte er sich darum kümmern.
Grüße,
Heiko
Zitat von: betateilchen am 28 Dezember 2019, 12:02:04
Ich bin der Meinung, dass FHEM überhaupt keine Drittanbieterpakete ausliefern sollte, für die es fertige Pakete in der Linux Paketverwaltung gibt.
Ich würde sogar noch weiter gehen und keine Libs auszuleifern, die via CPAN verfügbar sind.
Jetzt nur eine _kurze_ Erklärung dazu, da mein Browser gerade meine recht ausführliche Antwort gefressen hat: Man könnte z.B. recht einfach IO:SOCKET:INET durch IP:SOCKET:IP austauschen, um einen transparenten Zugriff mit beiden IP Protokollen (v4 und v6) zu erreichen. Gescheitert bin ich damals, bei meinen Versuchen, an den verwendeten Libs common.pm und/oder ControlPoint.pm, die mwn. zu Net::UPnP:: gehöhren. Da Rudi die ::IP Libs (damals?) nicht kannte oder für nicht zuverlässig hielt, habe ich meine Versuche eingestellt und verwende seit dem meine eigene DevIO.pm...
Zitat von: DS_Starter am 28 Dezember 2019, 12:18:39
Nur wie in dem vorliegenden Fall verfahren ?
Einfach entfernen ist wahrscheinlich nicht das Mittel der Wahl.
Doch. Spätestens zu FHEM 6.0 sollte man diese Bereinigung vornehmen.
Man könnte natürlich auch im Vorfeld rausfinden, welche Module überhaupt darauf aufsetzen und die Maintainer dieser Module bitten, eine entsprechende Prüfung auf Verfügbarkeit einzubauen und ggf. den Anwender auf die Nichterfüllung dieser Abhängigkeit hinweisen. So wird das ja in anderen Modulen, die spezielle Anforderungen/Abhängigkeiten haben, auch gemacht.
Auf die Schnelle habe ich eben genau zwei FHEM Module gefunden, die MP3::Tag benutzen:
00_SONOS.pm
98_MediaList.pm
Das ist doch überschaubar...
Hallo zusammen,
jetzt habe ich mit
sudo apt-get install libmp3-tag-perl
die Debian Bibliothek installiert und das Verzeichnis ./FHEM/lib/MP3 gelöscht.
Hat zwar prinzipiell funktioniert, allerdings kommt beim FHEM Neustart wieder die bekannte Warnung:
2019.12.28 20:38:22.079 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^\??({ <-- HERE ([^{}]+)}|.)/ at /usr/share/perl5/MP3/Tag.pm line 2944.
2019.12.28 20:38:22.079 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^({ <-- HERE [^{}]+}|\w)/ at /usr/share/perl5/MP3/Tag.pm line 2956.
Danach habe ich mit Hilfe von Loredos Installer-Modul MP3::Tag mit cpanm installiert.
Ein erneuter Start von FHEM zeigt nun keine Warnung mehr an. Das Sonos Modul läuft bei mir.
Weitere intensivere Tests habe ich nicht durchgeführt, aber sieht m.M. nach soweit gut aus wenn man MP3::Tag installiert.
Vielleicht mag das jemand anderes auch noch verifizieren.
Grüße,
Heiko
Hallo zusammen,
ich bin da etwas anderer Meinung. Sonos kenn und hab ich nicht. Das betroffene Modul nutze ich auch nicht. Aber ich kenne ein wenig aus ähnlicher Geschichte Reinerleins Beweggründe, das eigentliche "Standardmodul" zu modifizieren. Hauptgrund ist, dass "Standards" nicht sauber implementiert wurden. Sei es im Modul oder beim device. Folglich lässt sich ein device nur durch Modifikation betreiben.
Ich stimme Euch grundsätzlich zu den Standard zu nehmen. Modifikationen außerhalb des Standards zu machen. Aber manchmal geht es halt nicht ohne Modulmodifikation. Ich denke daher, dass Modifikationen besser dokumentiert werden müssen, um sie ggfs. wieder nachzuziehen. Auch darf es natürlich nicht passieren, dass der Maintainer quasi nicht erreichbar ist.
Wenn es bei Eurer befürworteten Vorgehensweise bliebe, könnte man z.B. den DLNARenderer für einige Geräte nicht mehr nutzen, da die Modifikation der upnp-Standardlib notwendig ist. Hilft dann wenig die "Schuld" beim Maintainer der Perllib oder dem device-Hersteller zu suchen/finden. :'( Es wird nicht von FHEM unterstützt. Und das ist aber doch unser oberstes Ziel. :-\
Wie wäre es, wenn der FHEM-Maintainer immer einen Patch zur ursprünglichen Standardversion bereithalten muss ? Dann sollte ein Einbau in eine neue Standardversion doch möglich sein.(best case: Modifikation entfällt wegen in der neuen Version bereits enthaltener Korrektur).
@Heiko: apt-get macht Fehler, CPAN nicht, bedeutet, dass die aktuelle CPAN-Version noch nicht in Debian umgesetzt ist ?
Grüße Markus
PS: Mit nur "Test" lässt sich das Problem nicht lösen.
PSS: apt-get sollte jeder User hinbekommen. Cpan-Installationen nicht. Und macht das nicht apt-....-Sytemprobleme ? :-\
Hi Markus,
ZitatAuch darf es natürlich nicht passieren, dass der Maintainer quasi nicht erreichbar ist.
Naja, das war eigentlich meine Motivation meiner Meldung hier. Den Hinweis zu der vorhandenen Warnung hatte ich schon seit September im entsprechenden Unterforum stehen. Und im Developerforum müsste Reinerlein doch sicher auch lesen.
Ursprünglich wollte ich auch nur diese Kleinigkeit beseitigen ... ;)
LG,
Heiko
Hi Heiko,
da sind wir Leidensgenossen. ;) Auch ich wartete leider Monate. :'( Daher mein Vorschlag, Modifikationen strenger(wie genau ?) auf Notwendigkeit zu prüfen und den Maintainer stärker in die Pflicht zu nehmen.(Im Gegensatz zur sonstigen Gepflogenheit sollte der Maintainer aktiv seine Unlust/Zeitmangel kund tun, die maintenance nicht länger übernehmen zu können)
Mein PSS hattest Du gesehen ?
Grüße Markus
ZitatMein PSS hattest Du gesehen ?
Ja hatte ich. Vermutlich hast du recht. Weiß auch nicht inwiefern sich Loredos Installer verbreitet hat. Damit ist/wäre es ja ganz simpel. Die Frage bzgl. Systemprobleme konnte ich jetzt nicht ganz deuten bzw. etwas dazu sagen.
LG
ZitatWeiß auch nicht inwiefern sich Loredos Installer verbreitet hat.
Bei mir schon mal nicht ???
ZitatDie Frage bzgl. Systemprobleme konnte ich jetzt nicht ganz deuten bzw. etwas dazu sagen.
Ich kann mich schwach daran erinnern, dass man sich die apt-update-Systematik zerschießt, wenn man etwas "händisch" installiert. Hab da aber keinerlei tiefergehendes Fachwissen.
Ich kann mich noch dunkel an die Entwicklungszeit des SONOS Moduls erinnern. Damals habe ich irgendwo gelesen, dass die MP3 Lib händische Änderungen benötigte, um unter bestimmten Umständen richtig zu funktionieren. Ich vermute daher, dass es sich um eine gänzlich andere Lib handelt, die leider den selben Namen bekommen hat ...
Zitat von: DS_Starter am 28 Dezember 2019, 23:22:38
Weiß auch nicht inwiefern sich Loredos Installer verbreitet hat. Damit ist/wäre es ja ganz simpel.
Ja. FHEM Meta ermittelt die Abhängigkeit zu MP3::Tag wahrscheinlich bereits zuverlässig (mangels vom Maintainer hinterlegten Metadaten im SONOS Modul), wenn man es aus dem FHEM/lib Unterordner gelöscht hat.
Wer jedoch den Installer nicht verwendet, dem wird diese dann ja neue Abhängigkeit jedoch nicht bekannt sein, so dass die commandref natürlich entsprechend ergänzt werden sollte. Dort stehen ja auch schon andere Voraussetzungen.
Hallo zusammen,
Reinerlein hat auf meine vor rund 14 Tagen geschriebene PM zu diesem Thema nicht geantwortet.
Nach den bisher hier geäußerten Hinweisen zum Werdegang dieses Unterstützungsmoduls wäre ich dafür nur diese kleine
Änderung der Tag.pm, die ich bisher über das contrib den betroffenden Usern bereitgestellt habe, einzuchecken.
Dadurch wäre die Funktionalität weiterhin gesichert.
Wenn es allgemeine Zustimmung geben sollte, würde ich es tun.
Grüße,
Heiko
Ja, finde ich gut so.
Habe die Datei jetzt eingecheckt wird morgen früh dann mit verteilt.
Grüße,
Heiko
Eeeeendlich <3 <3 <3