Was gibts neues beim ct-vdr

Ich hab gerade mal spaßeshalber das yaVDR-Unstable-Repository mit meinem Squeeze-Repository verglichen. Es gibt eine Überschneidung in 130 Paketen. Davon unterscheiden sich 70 Pakete nur im changelog. In diesem Fall hat das yaVDR-Team einfach nur die Versionsnummer gändert. Leider nach einem etwas unglücklichen und z.T. auch fehlerhaften Versions-Schema, wodurch der Bezug zum "Original-Paket" verloren geht. 19 Pakete haben scheinbar eine neuere Upstream-Version (z.T. scheinbar jüngere VCS-Snapshots). Bei 3 Paketen hinkt yaVDR mit der Upstream-Version hinterher. Bei den restlichen Paketen scheint yaVDR die letzten Änderungen (von meiner Seite) nicht gemerged zu haben oder yaVDR verwendete andere Defaults.

Im großen und ganzen ist yaVDR also noch mehr oder weniger "baugleich" zu meinen Paketen. Die wesentlich Unterschiede sehe ich abgesehen von der Distri derzeit nur im Installer, dem Admin-Tool und der XBMC-Unterstützung. Ich fürchte aber, yaVDR und Debian/e-tobi werden auch bei den VDR und Plugin-Paketen in Zukunft weiter auseinanderdriften, da es derzeit in beiden Richtungen eigentlich nicht viel an aktiver Zusammenarbeit gibt.

Zitat

Original von Tobi
...der XBMC-Unterstützung...

das sollte ja auch kein problem darstellen, werde die tage auch mal zu deinem neuen vdr-experimental squeeze repo die vdr plugins (vnsiserver etc) bauen. die xbmc pvr-testing2 pakete tun so ja schon. nur muss ich mal gucken ob ich dafür neues repo hinzufüge, da ich für squeeze vdr und vdrdevel ja die lenny pakete von dir und tom nutze, da gibts bis auf text2skin keine probleme.
aber wie du schon selber sagtest, für eine person ist das immer bissl viel arbeit, deshalb kanns auch immer bissl dauern bei mir

XBMC hab ich selbe ja auch am laufen, aber ohne pvr-testing2. Wie ist da der Stand der Dinge? Sollte das nicht irgendwann auch mal in den Master gemerged werden?

Zitat

Ich hab gerade mal spaßeshalber...

Grins

@VDRopti
ich denke Du sagst etwas sehr wahres! eine FF-Lösung bzw. eine Atomlösung sollten stromsparend sein. Das zahlt sich doppelt aus (Lärm- und Stromersparnis).
Deswegen würde ich auch so gerne eine FF-HDTV Karte sehen... Es wäre für mich auch die am wenigsten arbeitsintensive Möglichkeit. Ich scheue einfach davor zurück mich in sfxe, xbmc usw. einzuarbeiten.

Zitat

Original von Tobi
da es derzeit in beiden Richtungen eigentlich nicht viel an aktiver Zusammenarbeit gibt.

Das bedaure ich auch, aber da du in der Vergangenheit, als ich noch kein eigenes Repository hatte, Änderungen kommentarlos verworfen hast, oder sie stark verändert hast und auf entsprechende Rückfragen von mir nicht reagiert hast, war mir da etwas die Lust vergangen. Wenn du an aktiver Zusammenarbeit interessiert bist, dann schreib doch mal eine Email mit deinen Vorstellungen.

Gerald

Tobi irgendwie klingt das ziemlich abwertend, das ist schade

Ich hatte es eigentlich so in Erinnerung, dass hotzenplotz5 regelmäßíg in Kontakt steht mit Euch (Tobi und TomG oder nur TomG, weiß jetzt nicht genau) zwecks gegenseitiger Paketbeschau. Auch wenn diese Form der Kooperation vielleicht noch nicht die Wunschform der Kooperation für einige von uns darstellt, ist es doch eigentlich ein guter Anfang zu einem Ausbau der Kooperation? Oder bin ich da zu blauäugig?

Es ist ja nun eigentlich auch wirklich keine Überraschung, dass ein Großteil unserer VDR-Pakete (Core + Plugins) aus Tobis Quellpaketen stammen. Das kann man auf http://www.yavdr.org/download/ nachlesen, dort steht das schon seit mindestens März 2010, dass unserer Arbeit die Arbeit von Tobi und TomG zu Grunde liegt. Letztendlich habe ich ja auch in meinem VDR Package Tracker sowohl die Debian als auch die Ubuntu-Repos indiziert (http://www.henningpingel.de/vdrstuff/vdr_package_tracker/) und es gibt auch ein von mir bereitgestelltes internes Vergleichstool, welches hotzenplotz5 und TomG ab und an verwenden, um oberflächlich einen Überblick zu gewinnen, wie sich die Pakete in unseren Repos von den Versionsnummern her unterscheiden. Das ist vielleicht noch zu wenig Kooperation, aber es ist doch etwas da? Oder nicht?

Gruß
hepi

hotzenplotz5: Sollte jetzt nicht abwertend klingen, weder für yaVDR noch die Debian-Pakete.

gda: Wenn ich auf Rückfragen nicht reagiere ist das keine Absicht. Manche Dinge gehen nur ganz einfach unter oder verschwinden vom Radar, weil ich zu lange keine Zeit hatte mich damit zu beschäftigen.

Lass dich also nicht davon abhalten, mir Änderungen zu schicken - auch wenn ich die nicht 1:1 übernehme ist jede Zuarbeit immer willkommen!

Was mich momentan an yaVDR am meisten stört, sind die Versionsnummern. Für jeden Rebuild wird die Debian-Revision hochgeschraubt. D.h. aus vdr-plugin-foo 1.0-1 wird 1.0-2yavdr1 u.s.w.. Wenn ich jetzt im "Originalpaket" Änderungen mache, wird das vdr-plugin-foo 1.0-2 während yaVDR mit der Versionsnummer davon gerannt ist. Uns fehlt so der Überblick, was sich in yaVDR geändert hat und umgekehrt gehen yaVDR Änderungen durch die Lappen, die wir an den Paketen mache.

Schöner wäre es, wenn yaVDR nur den NMU-Part erhöhen würde, also 1.0-1.0yavdr1, 1.0-1.0yavdr2 u.s.w.

Gewissermaßen ist da das Kind allerdings schon in den Brunnen gefallen, da die Versionen in yaVDR nicht einfach zurückgedreht werden können.

Außerdem haben bei yaVDR ein paar Pakete eine Debian-Revision bekommen, die native Debian-Pakete sind (also ohne Upstream). z.B. vdr-addon-acpiwakeup. Eigentlich sollte da auch Lintian meckern.

Ist jetzt aber hier irgendwie der falsche Platz um sowas zu diskutieren. Wie wäre es, wenn wir Änderungen an den gemeinsamen VDR-Paketen in Zukunft auf der Mailinglist des "VDR and DVB packaging Project" diskutieren?

http://lists.alioth.debian.org…istinfo/pkg-vdr-dvb-devel

(Ich muss da nur mal schauen, wie man sich den Spam besser vom Halse hält)

Ich könnte auch ein Projekt auf projects.vdr-developer.org erstellen und wir könnten dort den Issue-Tracker verwenden.

hepi: Ja, dein Package-Tracker ist schick - hübscher als meiner Wie gesagt sind leider die Versionsnummern nicht mehr allzu aussagekräftig (siehe oben).

Zitat

Original von Tobi
Lass dich also nicht davon abhalten, mir Änderungen zu schicken - auch wenn ich die nicht 1:1 übernehme ist jede Zuarbeit immer willkommen!

Was du übernimmst ist natürlich deine Sache, aber einen Begründung wäre mir dann schon wichtig. Wenn wir allerdings wirklich zusammenarbeiten wollen, dann sollte es eigentlich nicht sein, dass du alleine entscheidest welche Änderungen übernommen werden.

Zitat

Original von Tobi
Schöner wäre es, wenn yaVDR nur den NMU-Part erhöhen würde, also 1.0-1.0yavdr1, 1.0-1.0yavdr2 u.s.w.

Gewissermaßen ist da das Kind allerdings schon in den Brunnen gefallen, da die Versionen in yaVDR nicht einfach zurückgedreht werden können.

Außerdem haben bei yaVDR ein paar Pakete eine Debian-Revision bekommen, die native Debian-Pakete sind (also ohne Upstream). z.B. vdr-addon-acpiwakeup. Eigentlich sollte da auch Lintian meckern.

Das sehe ich ein, das ist ein Problem. Wir werden zumindest für zukünftige Änderungen darauf achten. Bei den Paketen bei denen wir davon geeilt sind können wir ja so was wie 1.0-1.0yavdr0.x machen, um dir eine Chance zu geben aufzuholen.

Gerald

In diesem Zusammenhang möchte ich noch diesen Link loswerden:

Es gibt das uneingelöstes Versprechen der Betreiber der Launchpad-Plattform, dass sie auch das Bauen von Paketen mit der Zieldistribution Debian sid erlauben wollen: https://bugs.launchpad.net/soyuz/+bug/188564 Aber: Ich glaube nicht mehr daran, dass das - in welcher Form auch immer - kommt. Leider.

Nicht zuletzt führt ja die Dockstar-Verliebtheit auch einige yaVDR-Team-Mitglieder wieder zurück vom Ubuntu auf den Debian-Pfad, und ich könnte mir vorstellen (=ich hoffe), dass es in Zukunft immer mal wieder attraktive ARM-basierte Kompakthardware geben wird, die als VDR-Mini-Server oder VDR-Mini-Client attraktiv ist. Insofern wäre mein Wunschtraum, eines Tages mal einen für alle Situationen gespickten Repo-Server zu haben, auf dem man Repos findet für Ubuntu (i386+amd64) + Debian-Pakete für i386, amd64 + die ARM-Plattform(en). Nur ein Tagtraum...

Gruß
hepi

Zitat

Original von gda
Was du übernimmst ist natürlich deine Sache, aber einen Begründung wäre mir dann schon wichtig. Wenn wir allerdings wirklich zusammenarbeiten wollen, dann sollte es eigentlich nicht sein, dass du alleine entscheidest welche Änderungen übernommen werden.

Werd ich beherzigen. Wenn dir irgendwo ein Begründung fehlt, muss du sie einfach einfordern. Fällt dir da spontan was ein, wo ich das versäumt habe?

Zitat

Das sehe ich ein, das ist ein Problem. Wir werden zumindest für zukünftige Änderungen darauf achten. Bei den Paketen bei denen wir davon geeilt sind können wir ja so was wie 1.0-1.0yavdr0.x machen, um dir eine Chance zu geben aufzuholen.
erald

Wenn ihr schon bei 1.0-2yavdr1 seid, klappt das so nicht, da 1.0-1.0yavdr0.x < 1.0-2yavdr1. Theoretisch würde sich das alles erst mit den nächsten Upstream-Releases wieder synchronisieren, die bei manchen Paket aber wohl nie kommen werden.

Zitat

1.0-1.0yavdr0.x

bitte nicht.
ich achte in zukunft einfach besser darauf.
neue versionen mach ich eh schon so : 0yavdr1
aber das spielt jetzt keine rolle mehr ...
das ist leider zu spät.
ist schon richtig. da haben wir gleich falsch angefangen. schwer das wieder zu ändern.

Zitat

Wie wäre es, wenn wir Änderungen an den gemeinsamen VDR-Paketen in Zukunft auf der Mailinglist des "VDR and DVB packaging Project" diskutieren?

eigentlich ein guter platz .... mailinglisten finden ja eh alle immer am übersichtlichsten.

Zitat

Ich könnte auch ein Projekt auf projects.vdr-developer.org erstellen und wir könnten dort den Issue-Tracker verwenden.

sehr gute idee ! (besser als mailinglisten .... ich mag sie nicht ... andere schon )

Zitat

Original von Tobi
XBMC hab ich selbe ja auch am laufen, aber ohne pvr-testing2. Wie ist da der Stand der Dinge? Sollte das nicht irgendwann auch mal in den Master gemerged werden?

sollte ja, erst wars im stable 10.05 angedacht, was ja noch nicht fertig ist, aber pingpong/alwin meinte dann ja mal das es erst nach dem nächsten stable release gemerged wird. wie nun wirklich aussieht, sollte man ihn mal fragen.

Hab einfach mal ein Projekt angelegt:

http://projects.vdr-developer.org/projects/vdrdvbpackaging

@OppTupacShakur: Danke für die Info! Hab den XBMC bei mir bisher immer nur ohne pvr-testing in Verwendung. Kann man in pvr-testing inzwischen eigentlich ohne Umweg über das Streaming VDR-Aufnahmen abspielen? Bisher mache ich das immer über meine selbstgebastelte Fuse-Lösung.

Zitat

Original von Tobi
Hab einfach mal ein Projekt angelegt:

http://projects.vdr-developer.org/projects/vdrdvbpackaging

@OppTupacShakur: Danke für die Info! Hab den XBMC bei mir bisher immer nur ohne pvr-testing in Verwendung. Kann man in pvr-testing inzwischen eigentlich ohne Umweg über das Streaming VDR-Aufnahmen abspielen? Bisher mache ich das immer über meine selbstgebastelte Fuse-Lösung.

also ich habe grad mal, aber auch mit der pvr version, mein rec ordner vom vdr aufen lappy unter videos hinzugefügt, und von da kann ich die .ts aufnahmen abspielen. .vdr müsste ich erstmal was aufnehmen.

Zitat

Original von Tobi
Wenn dir irgendwo ein Begründung fehlt, muss du sie einfach einfordern. Fällt dir da spontan was ein, wo ich das versäumt habe?

Das ist alles schon arg lange her. Was mir gerade noch einfällt ist meine Anpassung für ACPI-Wakeup für neuere Kernels bei der ich die Benutzung von Perl ausgebaut hatte weil date das auch so konnte. Du hast Perl aber einfach wieder eingebaut.

Zitat

Original von Tobi
Wenn ihr schon bei 1.0-2yavdr1 seid, klappt das so nicht, da 1.0-1.0yavdr0.x < 1.0-2yavdr1. Theoretisch würde sich das alles erst mit den nächsten Upstream-Releases wieder synchronisieren, die bei manchen Paket aber wohl nie kommen werden.

Das war doch nur ein Beispiel. Ich bin nicht wirklich doof, auch wenn es vielleicht manchmal so aussieht ;). In dem Fall eben 1.0-2yavdr1.x wenn es bei uns eine Änderung gibt, dann sind wir zwar immer noch höher als du, aber du kannst uns leichter überholen. Aber Hotzenplotz5 mag es ja sowieso nicht. Hoffen wir also auf Upstream-Änderungen.

Gerald

Aber du musst jedesmal erst zur *.ts-Datei browsen? Das nervt! Ich glaube, dann muss ich mein Fuse-Lösung doch mal etwas optimieren und unter die Leute bringen.

Bzgl. Aufnahmen in XBMC abspielen: Aufgrund mangelnder Nutzungspraxis ist mein Wissen hier nicht aktuell, aber ich habe es so in Erinnerung: Wenn man bei der Konfiguration des VNSI-Klienten einen lokalen Pfad zu VDR-Recordings angibt, werden diese nicht gestreamt, sondern lokal gelesen (inkl. Zusammenfassung mehrerer ts-Files einer Aufnahme zu einem einzigen "File"). Ansonsten, wenn Frontend und Backend auf verschiedenen Rechnern liegen, wird halt gestreamt.

EDIT: Im VNSI-Klienten einen lokalen Pfad zu VDR-Recordings angeben und Häkchen bei Option "Read recordings from directory". Dann sind die Aufnahmen im TV-Modul von XBMC anwählbar.

Gruß
hepi

Zitat

Original von Tobi
Aber du musst jedesmal erst zur *.ts-Datei browsen? Das nervt! Ich glaube, dann muss ich mein Fuse-Lösung doch mal etwas optimieren und unter die Leute bringen.

joa, muss man erst durch die paar ordner durch. fände ich persönlich nun aber nicht schlimm 2 ordner zu browsen, da meine anderes video material genauso "eingelagert" ist.