Maintainer von FHEM/lib/MP3/Tag.pm

[DS_Starter]

Hallo zusammen,

weiß jemand wer die Datei FHEM/lib/MP3/Tag.pm pflegt ?
Wegen der Warnung:

Code Auswählen Erweitern


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

[Dr. Boris Neubert]

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

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

[DS_Starter]

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

[Dr. Boris Neubert]

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

[DS_Starter]

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

[betateilchen]

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.

[DS_Starter]

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

[dev0]

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...

[betateilchen]

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...

[DS_Starter]

Hallo zusammen,

jetzt habe ich mit

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[KölnSolar]

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 ?

[DS_Starter]

Hi Markus,

Auch 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

[KölnSolar]

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

[DS_Starter]

Mein 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

[KölnSolar]

Weiß auch nicht inwiefern sich Loredos Installer verbreitet hat.

Bei mir schon mal nicht

Die 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.