Das sieht nach einem Problem mit den DisplayLink-Scripten aus. Kopiere ich sie weg, startet das System sauber.
Ich teste jetzt mal mit Scripten und vdr-dbg.
Verkauf das Teil und hole dir ein Tablet für 50 EUR.
Gerald
Das sieht nach einem Problem mit den DisplayLink-Scripten aus. Kopiere ich sie weg, startet das System sauber.
Ich teste jetzt mal mit Scripten und vdr-dbg.
Verkauf das Teil und hole dir ein Tablet für 50 EUR.
Gerald
hole dir ein Tablet für 50 EUR.
Ist bereits vorhanden und läuft mit GrafDroid auch richtig gut, allerdings klauen mir meine Kinder das Teil
immer zum Spielen vom Tisch und dann ist's mit der WAF-fördernden Anzeige etwas schwierig.
Cheers,
Ole
Fein, dann sollte ja jetzt mit softhddevice 0.5.2 auch der stable in den Genuss des PIPs kommen. zumindest sind unstable und stable nun gleich.
Ich freue mich aber schon darauf, irgendwann mal skinopacityhd 0.6 testen zu können. Das aber erstwenn der aktuellere vdr im testing landet.
...da lauere ich auch schon drauf!
Moin!
Mit dem vdr 1.7.39 und dynamite hab ich noch ein Problem, aber ich hoffe, dass es nicht mehr lange dauert...
Aber das Anpassen der ganzen Plugins auf neue Makefiles (und neue Debian-Pakete) zieht noch so einiges an Arbeit nach sich.
Lars.
Das glaube ich gerne. Alleine schon die ständigen VDR Änderungen in der jüngeren Vergangenheit. Klaus war fleissig und der 2.0 steht ja schon praktisch in den Startlochern. Insofern rechne ich auch nicht vorher damit, und wenn doch umso mehr haben wir etwas zum freuen.
Hallo,
ich bekomme:
dpkg --configure -a
vdr-plugin-burn (0.2.0~final-8yavdr0~precise) wird eingerichtet ...
/usr/lib/vdr/vdr-groups.sh: 20: local: pulse-access: bad variable name
dpkg: Fehler beim Bearbeiten von vdr-plugin-burn (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 2 zurück
Fehler traten auf beim Bearbeiten von:
vdr-plugin-burn
- Markus
Moin!
Codedpkg --configure -a vdr-plugin-burn (0.2.0~final-8yavdr0~precise) wird eingerichtet ... /usr/lib/vdr/vdr-groups.sh: 20: local: pulse-access: bad variable name dpkg: Fehler beim Bearbeiten von vdr-plugin-burn (--configure): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 2 zurück Fehler traten auf beim Bearbeiten von: vdr-plugin-burn
Welches vdr/vdr-dev-Paket benutzt du?
Das Script versucht, den vdr-User ein paar Gruppen zuzuordnen, keine Ahnung, was da schief geht...
Kannst du da sonst ein paar Debug-Ausgaben einbauen, damit man sieht, mit welchen Parametern es aufgerufen wird?
Was sagt "groups vdr"?
Lars.
Moin!
Nur zur Info: mein vdr2 mit yaVDR 0.5 hat nun auch sein Update bekommen, alles ohne Probleme. Ich benutze aber auch nur wenige Plugins...
Lars.
Danke, Ich glaube das ist ein Problem, das wir aus einem älteren e-Tobi Paket übernommen haben.
vorsicht beim unstable-vdr nun mit 1.7.40:
Die folgenden Pakete werden ENTFERNT:
vdr-plugin-dynamite vdr-plugin-femon vdr-plugin-iptv vdr-plugin-pvr350
vdr-plugin-skinnopacity vdr-plugin-skinpearlhd vdr-plugin-softhddevice
vdr-plugin-streamdev-server yavdr-essential
Die folgenden Pakete werden aktualisiert (Upgrade):
acpi-support alsa-base aptdaemon aptdaemon-data dvb-driver-sundtek-mediaclient firefox
firefox-globalmenu firefox-locale-de graphtft-fe libpciaccess0 libxine1-xvdr libxine2
linux-sound-base python-aptdaemon python-aptdaemon.gtk3widgets vdr vdr-dev vdr-markad
vdr-plugin-channellists vdr-plugin-dbus2vdr vdr-plugin-dummydevice vdr-plugin-dvbhddevice
vdr-plugin-dvbsddevice vdr-plugin-epgsearch vdr-plugin-extrecmenu vdr-plugin-graphtft
vdr-plugin-live vdr-plugin-markad vdr-plugin-menuorg vdr-plugin-radio vdr-plugin-restfulapi
vdr-plugin-systeminfo vdr-plugin-text2skin vdr-plugin-wirbelscan vdr-plugin-xine
vdr-plugin-xineliboutput vdr-plugin-xvdr xine-ui xineliboutput-sxfe xserver-common
xserver-xorg-core
Alles anzeigen
oder baut der noch ?
oder baut der noch ?
unstable heißt unstable, weil da Baustelle ist
Und ja, er baut noch und es wird noch dauern, bis sich alle wichtigen Plugins zum Bauen überreden lassen...
Ich habe immer noch nicht raus, wie man bei launchpad sehen kann, ob der Durchlauf komplett ist.(damit meine ich nicht die "failed" Anzeige) . Gibt es da nirgends eine Warteschlange ?
Das nicht alle Plugins wollen ist logisch. Mein Gott ist ja auch erst der erste Tag
Ich wollte auch nur den Hinweis für die anderen geben. Sollen ja doch einige mit dem unstable-vdr unterwegs sein. Ich dachte auch zuerst nicht, dass nun doch schon der VDR wechselt. Gut das ich nachgesehen habe. (was man bei unstable eigentlich immer machen sollte)
Also das steht eigentlich immer schön auf der Status-Seite: https://launchpad.net/~yavdr/+archive/unstable-vdr
z.B.
Zitat
Currently 4 packages building and 0 packages waiting to build.
Was man als außenstehender nicht weiß ist, ob gerade jemand ein Paket zum Bauen hochgeladen hat...
peinlich das habe ich noch nie bemerkt, Danke.
Vielleicht habe ich immer erst drauf gesehen, als nichts mehr am bauen war. Oder Blindfisch
Ich wollte auch nur den Hinweis für die anderen geben. Sollen ja doch einige mit dem unstable-vdr unterwegs sein.
Könnt ihr nicht einfach mal die Finger davon lassen? Und dann dieses, Herr Lehrer, Herr Lehrer ich weiß was hier immer ...
Wenn ihr unbedingt daran lutschen wollt, müßt ihr Euch bei Fehlern selber helfen. Und ja, kann sein das es jetzt einige Zeit benötigt bis da was geht.
Wenn's nach mir ginge würde ich den Zugriff darauf einschränken ... wenn Ihr nur mal unseren Aufrufen Pakete aus testing-vdr für stable-vdr zu testen so vehement nachkommen würdet ...
Regards
fnu
Ruhig Blut Ich oder andere habe weder gemeckert, noch gefordert.
Mein Hinweis war auch nichts anderes als ein Hinweis, dass es demnächst den 1.7.40 zum testen gibt, und er noch nicht fertig ist. Das einzige was ich mir vorwerfen lassen kann ist, dass es hier nicht um unstable-vdr geht und es nicht gerne gesehen wird hier darüber zu sprechen. Wir wissen dass es darin keinen Support gibt und Probleme jederzeit möglich sind.
Und so wie ich es sehe, die Reihenfolge unstable -> testing -> stable ist in der Vergangenheit kaum genutzt worden. Unstable ist lange Zeit besser gelaufen als stable. Deshalb haben wohl viele den stable-vdr gegen unstable-vdr getauscht.
Also lassen wir es besser, bevor es ausufert.
Vergnügliche Woche
Und so wie ich es sehe, die Reihenfolge unstable -> testing -> stable ist in der Vergangenheit kaum genutzt worden. Unstable ist lange Zeit besser gelaufen als stable. Deshalb haben wohl viele den stable-vdr gegen unstable-vdr getauscht.
Das laß mal unsere Sorge sein und für 0.3/0.4 muß ich dem vehement widersprechen, wobei es da sinnvollerweise kein eigenes unstable gab.
Bloß weil es in unstable eine neuere VDR Version gab, heißt es nicht das dieses PPA besser läuft. Ihr habt vermutlich wie immer zu wenig testing-Pakete auf Stabilität geprüft und nur wieder am unstable Zipfel gelutscht Das ist der Langzeit-stabile Ausblick und diese Woche eben nach stable-vdr gewandert. Ich denke wir werden das Prinzip staging areas wieder fokusierter verfolgen, vorallem bei Plugins, aber im Rahmen des bevorstehenden 2.0 Release wird es zu ein paar interessanten Konstellationen kommen.
Ja genau, bitte keine Posts oder Threads zu unstable-vdr, ich sags mal deutlicher, "fresst oder sterbt". Evtl. sollten wir unstable ab und an nur zum Spaß kaputt machen ...
Solltet ihr Fragen, Anregungen, Meldungen zu stable-vdr oder auch testing-vdr haben, bitte her damit.
Regards
fnu
Moin!
Und so wie ich es sehe, die Reihenfolge unstable -> testing -> stable ist in der Vergangenheit kaum genutzt worden.
Nicht so intensiv, wie ich es gerne gehabt hätte, und wie immer ist die Ursache sicherlich die (fehlende) Freizeit.
Geplant ist aber, sobald der vdr 2.0 raus ist, den auf alle Fälle auch nach testing zu bringen. Dann habt ihr wieder was zum Spielen.
"kaputtes unstable" wird wenn überhaupt, dann nur auf der internen Mailingliste angekündigt.
Lars.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!