[wino]

Das Addon wurde nach der Eingabe von svn rm dbus-x11 und svn ci dbus-x11 gelöscht. Der Eintrag in der mudules_list besteht leider weiterhin.

Gruß
wino

[P3f]

HI,

ich habe mir nun mal die gesammelten Avahi-Addons zusammen gebaut, nur kann ich es nicht testen. Kann das jemand von Euch machen und ggf anpassen?

Hier der Download vom SFS-Paket bzw. für die Develumgebung

Zusammengefasst sind nun avahi-daemon,  avahi-dnsconfd, avahi-ui-utils, avahi-discover, avahi-mounter, avahi-utils zu avahi-daemon

Gruß,

Pit

P.S. ins Repository schiebe ich es erst wenn ihr getestet habt!

[clausmuus]

Hi,

wenn Ihr das Addon richtig erstellt habt, also per "make import name=dbus-x11", dann lässt sich das nicht mehr löschen. Grund dafür ist, das Addons nicht Teil des MLD reposetories sind, sondern jedes Addon nen eigenes Reposetory hat. Reposetories lassen sich aber nur direkt auf dem Server löschen, indem das im Filesystem gelöscht wird. Das kann nur ich durchführen, und wahrscheinlich auch MarMic, aber ich hab ihm nie gesagt wie's geht Ansonsten hat nur noch unser Hoster Thilo Schirmuli aus dem VDR Portal vollen zugriff auf den Server.
Wenn Ihr also komplette Addons loswerden wollt, so wendet euch vertrauensvoll an mich. Wenn ein Addon hingegen nur nicht mehr gebaut werden soll, jedoch für eine eventuelle spätere Wiederverwendung (oder aus anderen Gründen) im svn erhalten bleiben soll, so muss dessen Name lediglich aus der modules_list gelöscht und diese

[clausmuus]

Ich hab noch nen Hinweis, der jedoch schon dem einen oder anderem aufgefallen sein dürfte. Beim "make import name=xxx" kommt es des öfteren vor, das nicht alle im template Ordner enthaltene Links importiert werden. Nach einem Import sollte also immer überprüft werden ob anschließend noch alle Dateien im template Ordner enthalten sind, und diese gegebenenfalls manuell hinzugefügt werden.

Claus

[wino]

ich habe mir nun mal die gesammelten Avahi-Addons zusammen gebaut, nur kann ich es nicht testen. Kann das jemand von Euch machen und ggf anpassen?

Zusammengefasst sind nun avahi-daemon,  avahi-dnsconfd, avahi-ui-utils, avahi-discover, avahi-mounter, avahi-utils zu avahi-daemon

Das neue Addon sollte avahi heißen und das Addon avahi-mounter getrennt bleiben. Gelöscht können hingegen avahi-daemon, avahi-dnsconfd, avahi-ui-utils, avahi-discover und avahi-utils werden.  

Gruß
wino  

[wino]

Hallo Claus,

Pit hat sich um die neue VDR Version gekümmert und diese läuft auch. Was ist deine Meinung zu dem Vorschlag, MLD-3.0.1 bei der bisherigen VDR Version zu belassen und nur bei MLD-3.0.2 auf VDR-1.7.36 umzustellen. Ist das überhaupt machbar? Sind wegen dem neuen Makefile Konzept

[MarMic]

hi wino,

ich würde sagen 3.0.1 bleibt 3.0.1 :-)
in 3.0.2 kommt nun 1.7.36
und vdr 2.0 kommt in dem was nun kommt :-) WEIL wegen den gegebenheiten mit nightbuild und co müssen langsam lösungen her :-)

greetz MarMic

[skippy]

ich würde sagen 3.0.1 bleibt 3.0.1 :-)

Hallo zusammen,

würde sich dann bitte bei Gelegenheit jemand um Lirc für serielle Empfänger in der 3.0.2 kümmern, damit ich nicht ganz abgehängt werde ...

Viele Grüße skippy

[P3f]

Hallo zusammen,

würde sich dann bitte bei Gelegenheit jemand um Lirc für serielle Empfänger in der 3.0.2 kümmern, damit ich nicht ganz abgehängt werde ...

Viele Grüße skippy

Hi Skippy,

sobald wir wieder alles in einem aktuellen Zustand haben, sollten wir uns wirklich die Fernbedienungsthematik finalisieren. Im Moment laufen ja bereits viele Fernbedienungen ootb. Aber die seriellen und z.b. eine atiusb mit RC5 nur mit manuellen Eingriff mit der 3.0.2. Da werden bestimmt noch ein paar auftauchen, sobald es auch weitere Tester wieder gibt.

Die udev-Variante der MLD hat wirklich einen gewissen Unterbauumbau mit erlebt, und wir kommen auch wieder dazu das über Webif die gewünschte Fernbedienung auswählbar sein wird. Ein paar sinnvolle Ideen gibt es dazu ja schon, aber umgesetzt sind sie noch nicht.

Ich bin mir auch sicher, das -sobald die Nightlybuild-Problematik wieder in saubere Bahnen kommt- die Entwicklung weiterkommt. Es sind ja nun auch wirklich einige Entwickler mit an Bord, die ein gemeinsames Ziel haben.

Danke, das es die MLD gibt.

Gruß,

Pit

[det]

hi

mal schauen was das ist

Jan 25 22:33:05 (MLD) user.info vdr: connection to LCDd at 127.0.0.1:13666 established.
Jan 25 22:33:05 (MLD) user.info vdr: LCDproc-Plugin started at 127.0.0.1:13666.
Jan 25 22:33:05 (MLD) user.info vdr: LCD output thread started (pid=2356), display size: 2x18
Jan 25 21:33:06 (MLD) user.info kernel: vdr[2356]: segfault at 19 ip 00000019 sp bf968b6c error 4 in vdr[8048000+185000]

mfg det

PS:
lcdproc mit xbmc funktioniert also ligt das man vdr-plugin  

[wino]

Da läuft durch die neuen Makefiles noch etwas nicht rund. Bei einem Versuch das neue cdplayer-1.1.6 Plugin mit neuem Makefile zu kompilieren, ergibt einen Fehler. [code]cp: reguläre Datei »/usr/local/lib/vdr/libvdr-cdplayer.so.1.7.36

[wino]

Bei den Plugins sleeptimer und block gibt es nur noch die neuen Makefiles. Es sollte langsam mal eine Entscheidung für den Umgang mit der neuen Makefile Situation getroffen werden. Sollen alle MLD-Versionen oder nur die MLD-3.0.2 darauf umgestellt werden?

MfG
wino
 

[wino]

Bei mir bringt VDR bei einem Neustart diese Ausgaben.

Code: [Select]

*** glibc detected *** /usr/bin/vdr: free(): corrupted unsorted chunks: 0x0831b6f8 ***
*** glibc detected *** /usr/bin/vdr: malloc(): memory corruption: 0x0831e018 ***Ob das mit einem der Patches bei VDR im Zusammenhang steht kann ich nicht beurteilen.

Gruß
wino

[wino]

Nachdem ich den extpng_mld Patch weggelassen habe, ist auch der obige Fehler verschwunden. Irgend etwas stimmt bei dem Patch nicht. Nur weiß ich nicht was?

Gruß
wino

[P3f]

Hi wino,

ich glaube das etwas mit dem Make.config.template nicht stimmt. Ich habe das gerade mal extrahiert, also ich verstehe den Unterschied zwischen Make.config und Make.config.template nicht.

Bei mir habe ich gerade mal das Make.config komplett entfallen lassen und das Make.config.template mit den MLD-Pfaden angelegt. Es kompiliert gerade bei mir.

Meinst Du das daran liegen kann.?

Gruß,

Pit