vdr-vnsiserver-Ebuild für Gentoo?

Hallo,

nachdem das XBMC-Addon-xvdr XBMC direkt und zuverlässig zum Absturz bringt, dachte ich mir, könnte ich ja mal die Fallbackvariante VNSI-Server testen. Das Plugin auf XBMC-Seite ist ja bereits in XBMC integriert. Beim VDR sieht das leider anders aus.

vdr-vnsiserver-9999-r1.ebuild:

pkg_setup() {






        eerror "vdr-vnsiserver is dead on upstream"


        eerror "project has changed to:"


        eerror "https://github.com/pipelka/vdr-plugin-xvdr"


        eerror "See detailed info for this"


        eerror "https://github.com/pipelka/vdr-plugin-vnsiserver/blob/master/README"


        eerror "Please use media-plugins/vdr-xvdr from portage"






        die || "dead on upstream, use media-plugins/vdr-xvdr"


}

Und vdr-vnsiserver-9999.ebuild findet die Git-Repo nicht mehr:

EGIT_REPO_URI="git://github.com/pipelka/vdr-plugin-vnsiserver.git"

Den Fork findet man unter: https://github.com/FernetMenta/xbmc/tree/vnsi

Nur leider hab ich's nicht hinbekommen, das Ebuild so zu ändern, dass ich das Plugin trotzdem irgendwie compiliert bekomm.

/etc/portage/env/media-plugins/vdr-vnsiserver

EGIT_REPO_URI="git://github.com/FernetMenta/xbmc.git"


EGIT_BRANCH="vnsi"


EGIT_PROJECT="vdr-vnsi"

macht bei mir dann folgendes:

emerge -1 =vdr-vnsiserver-9999


Calculating dependencies... done!






>>> Verifying ebuild manifests






>>> Emerging (1 of 1) media-plugins/vdr-vnsiserver-9999 from vdr-devel


 * please use append-cppflags for preprocessor flags


 * Compiling against


 * 	vdr-1.7.27 [API version 1.7.27]


>>> Unpacking source...


Cloning into bare repository '/var/portage/distfiles/egit-src/vdr-vnsi'...


remote: Counting objects: 186414, done.


remote: Compressing objects: 100% (58555/58555), done.


remote: Total 186414 (delta 134887), reused 171016 (delta 124081)


Receiving objects: 100% (186414/186414), 322.50 MiB | 701 KiB/s, done.


Resolving deltas: 100% (134887/134887), done.


GIT NEW clone -->


   repository:               git://github.com/FernetMenta/xbmc.git


   at the commit:            a4920178afeb919e8bc070731f9030892e76594a


   branch:                   vnsi


   storage directory:        "/var/portage/distfiles/egit-src/vdr-vnsi"


   checkout type:            bare repository


Cloning into '/var/tmp/portage/media-plugins/vdr-vnsiserver-9999/work/vnsiserver-9999'...


done.


Checking out files: 100% (14014/14014), done.


Branch branch-vnsi set up to track remote branch vnsi from origin.


Switched to a new branch 'branch-vnsi'


>>> Unpacked to /var/tmp/portage/media-plugins/vdr-vnsiserver-9999/work/vnsiserver-9999


>>> Source unpacked in /var/tmp/portage/media-plugins/vdr-vnsiserver-9999/work


>>> Preparing source in /var/tmp/portage/media-plugins/vdr-vnsiserver-9999/work/vnsiserver-9999 ...


 * Patching Makefile


 * ERROR: media-plugins/vdr-vnsiserver-9999 failed (prepare phase):


 *   Makefile of plugin can not be found!


 * 


 * Call stack:


 *     ebuild.sh, line   85:  Called src_prepare


 *   environment, line 2858:  Called vdr-plugin_src_prepare


 *   environment, line 3607:  Called vdr-plugin_src_util 'prepare'


 *   environment, line 3639:  Called vdr-plugin_src_util 'add_local_patch' 'patchmakefile' 'i18n'


 *   environment, line 3650:  Called vdr_patchmakefile


 *   environment, line 3721:  Called die


 * The specific snippet of code:


 *       [[ -e Makefile ]] || die "Makefile of plugin can not be found!";


 * 


 * If you need support, post the output of `emerge --info '=media-plugins/vdr-vnsiserver-9999'`,


 * the complete build log and the output of `emerge -pqv '=media-plugins/vdr-vnsiserver-9999'`.


 * This ebuild is from a repository named 'vdr-devel'


 * The complete build log is located at '/var/tmp/portage/media-plugins/vdr-vnsiserver-9999/temp/build.log'.


 * The ebuild environment file is located at '/var/tmp/portage/media-plugins/vdr-vnsiserver-9999/temp/environment'.


 * Working directory: '/var/tmp/portage/media-plugins/vdr-vnsiserver-9999/work/vnsiserver-9999'


 * S: '/var/tmp/portage/media-plugins/vdr-vnsiserver-9999/work/vnsiserver-9999'






>>> Failed to emerge media-plugins/vdr-vnsiserver-9999, Log file:






>>>  '/var/tmp/portage/media-plugins/vdr-vnsiserver-9999/temp/build.log'

Scheint so, als ob sich auch irgendwie die Verzeichnisstruktur im Plugin geändert hat. Sehr unschön das Ganze. Wie kriegt man das vnsiserver-Plugin zum Laufen?

Zitat von johns

Vnsi ist Tod, lass die Leichen in ihren Gräbern.

Der Nachfolger ist xvdr.

Installier vdr-xvdr und dies ist sogar im normalen Gentoo Portage.

Wäre schön, wenn das so wäre. Seit ca. 2 Wochen verursacht das Päckchen XBMC-Addon-xvdr einen sofortigen XBMC-Komplettabsturz. Nachzulesen auch hier. Mit anderen Worten: Seit ca. 2 Wochen verwende ich immer Xineliboutput als Notlösung, da XBMC halt für den TV-Betrieb nicht mehr funktioniert.

Hatte da auch schon im XBMC-Forum einen Beitrag geschrieben. FernetMenta scheint wohl der aktuelle Maintainer des VNSI-Plugins zu sein. Nach seiner Auskunft ist halt XVDR noch nicht ganz ausgereift und kann diverse API-Änderungen erfahren, was dann halt genau zu diesen Inkompatibilitäten führt. Deswegen wird VNSI auch noch explizit in XBMC weitergepflegt.

Von daher hätte ich halt gerne eine Fallback-Option, wenn Xvdr gerade mal wieder geändert wird und nichts mehr geht.

PS: Wieso fügt das Forum hier eigentlich immer zusätzliche Leerzeilen ein?

Ok, hab gestern Abend mal den vnsiserver manuell compiliert. Und was soll ich sagen, das Ding läuft schneller und zuverlässiger als das bei Xvdr jemals der Fall war.

Ich bleib jetzt erstmal solange bei VNSI, bis XVDR mal einen gewissen Reifegrad erlangt hat.

Zitat von steffen_b

Wenn das VNSI jetzt gepflegt wird und stabil ist, brauchts xvdr nicht und vice versa. Das ist einfach nur Irrsinn weil ein Developer sich mit (einem?) anderen in den Haaren hatte. VNSI war dann effektiv eine längere Zeit ungepflegt. Wenn FernetMenta das jetzt inklusive vdr plugin pflege übernommen hat bin ich da zuversichtlich.

Jein, so ist das Ganze auch nicht zu sehen.

http://forum.xbmc.org/showthread.php?tid=135164&pid=1143031#pid1143031

Zitat von "FernetMenta"

There is a reason why we keep maintaining VNSI in this branch. It's not that we like the duplicate work or say VNSI is better than XVDR. We have expected exactly those things to happen.
Your crashlog states that it segfaults in XVDR.

So wie ich das verstanden hab, wird schon auf die Weiterentwicklung in XBMC-PVR und damit auf Xvdr gesetzt. Nur solange das noch nicht stabil ist, bleibt eben VNSI erstmal im Hauptbranch vorhanden. Das VNSI-Plugin muss man in XBMC ja auch nicht gesondert installieren, ist ja bei der XBMC-Installation schon dabei im Gegensatz zu Xvdr.

Ist dann halt nur Mist, dass das Ebuild im Gentoo-Overlay nicht mehr funktioniert und VNSI damit als obsolet erklärt wird. Wir haben somit derzeit die folgende Situation:

VDR -> vdr-xvdr (funktioniert) --> XBMC-Addon-xvdr (crasht XBMC) -> XBMC-PVR (unbrauchbar)
VDR -> vdr-vnsiserver (kein Ebuild mehr vorhanden, damit nicht installierbar) ---> VNSI-Addon inXBMC (funktioniert tadellos) -> XBMC-PVR (unbrauchbar)

Ausgangspunkt und Endergebnis sind dasselbe. Damit ist XBMC-PVR wieder konsistent. Toll, oder?

Ich würde das Ebuild ja selbst umschreiben. Nur leider hab ich kaum Ahnung von der Ebuildsyntax und noch weniger Ahnung von Git. Evtl. schreib ich die Typen vom vdr-devel-Overlay mal an.

Zitat von nst

Wichtig:

XBMC-PVR Eden 11.0 -> https://github.com/pipelka/xbmc-addon-xvdr/tree/eden (eden-Branch)
XBMC-PVR Trunk (Frodo) -> https://github.com/pipelka/xbmc-addon-xvdr (master-Branch)

"master" mit Eden funktioniert nicht, umgekehrt auch nicht.

Muss ich dann erstmal nachprüfen, welche Pfade in den Ebuilds stehen. XBMC ist bei mir auf alle Fälle Eden. Mit Frodo hab ich noch nicht rumgespielt.

Zitat von nst

Was ist denn mit dem ebuild unter http://forums.gentoo.org/viewtopic-p-6545338.html#6545338 ? Das hat mit dem VDR 1.7.28 ebuild aus dem vdr-devel Overlay zumindest einfach so kompiliert. ... Wichtig: Im vdr-devel-Overlay liegt bereits ein media-plugins/vdr-vnsiserver, welches nichts anderes macht, als "is dead upstream" per eerror auszuwerfen, das ebuild muss man overriden.

Bei mir hatte er mit dem Overlay-Package den Pfad zum Github-Repository nicht gefunden. Werd auch das bei Gelegenheit noch mal testen, ob ich das hinbekomm. Im Moment läuft's aber erstmal mit dem manuell compilierten vnsi-server.

Btw. teste mal bitte, wohin die vdr-Dateien bei Dir für vdr-1.7.28 installiert wurden.

equery f vdr

Bei mir landeten die komischerweise in /usr/share/locale/. Deswegen bin ich auch noch bei 1.7.27 geblieben.

Zitat von nst

Liste der installierten Dateien siehe http://pastebin.com/gb61a9s8.

Hmm, dann ist wohl irgendwas an meiner Systemkonfiguration kaputt. Komischerweise installiert sich die 1.7.27 in die richtigen Verzeichnisse.

Bei den Sprachen hab ich in der make.conf

LINGUAS="de pt_BR"

Der Rest steht in /etc/env.d/03locale. Da ist bis auf LC_ALL alles auf de_DE.utf8 gesetzt, soweit ich mich erinnere (hab hier von der Arbeit keinen Zugriff).