Beiträge von jasminj

  • Empfehlung für GIT-Server

    Hi!


    Zitat von kls

    Ich bin gerade dabei, ein Script zu schreiben, welches mein RCS in ein GIT verwandelt.

    Ich habe selbst schon von SVN nach Git importiert, was sehr gut funktioniert, aber du hast ja RCS und das müsste man erst mal nach CVS/SVN konvertieren.
    Also direkt geht das ziemlich sicher nur mit einem selbst gebauten Script.


    Zitat von kls

    Das Ergebnis möchte ich dann auf meinem Server (tvdr.de) mit einem eigenen GIT-Server zur Verfügung stellen, damit es künftig keine "Beschwerden" mehr wegen eines fehlenden "offiziellen" GIT-Archivs oder "Patch-Orgien" gibt ;-).

    Also wenn das das Ziel sein soll, dann verstehe ich wirklich nicht warum es nicht GitHub sein kann?
    Da hast du absolut keinen Aufwand bez. Server Wartung und zuverlässiger sollte es auch sein, weil die sicher eine große Server Farm im Hintergrund haben, die Weltweit gut angebunden ist.


    Zitat von kls

    Ich selber werde weiterhin mit meinem guten alten RCS arbeiten

    Ich editiere auch noch immer mit vi und verwende grep, aber Git möchte ich nicht mehr missen.
    Gewohnheiten sind schwer abzulegen ... ;)

  • Empfehlung für GIT-Server

    Ich weiß, du wolltest einen eigenen Server betreiben, aber was spricht dagegen das auszulagern und GitHub zu verwenden?
    Die haben auch die Möglichkeit gegen Entgeld Private Repos zu betreiben.


    In der Firma nutzen wir die Atlassian Tools wie Jira, Confluence und Bitbucket. Mein Sohn verwendet diese Tools auch auf seinem Server. Da gibt es eine User Beschränkung für die kleinste Lizenz (10 User), aber du hast ja nicht genau beschrieben was du damit machen willst also wollte ich auch diese Toolchain erwähnen.


    Falls es für den VDR sein soll, dann würde ich tatsächlich für GitHub plädieren.

  • media-build-dkms

    Hi!

    Zitat von Dr. Seltsam

    Von daher könnte es vielleicht zielführender sein, den Treiber außerhalb des Kernels zu lassen.

    Schauen wir mal was S:oren schafft auf der Kernel Mailingliste.

    Vielleicht schafft es der Treiber ja doch nach Staging. Das wäre zumindest mal ein erster Schritt.


    Um deinen Gedanken aufzugreifen, dann könnte doch die Integration in mein media-build-dkms Sinn machen. Oder jemand findet sich der ein eigenes DKMS schreibt. So kompliziert ist das nicht, wenn man mein media-build-dkms als Muster nimmt, um auch für ältere Kernels einen Support zu haben. Media Build hat hierzu ein eigenes Build System.

    Der Vorteil wäre, man könnte das TT6400-dkms einfach zusätzlich installieren, wenn man auch diese Karte verwenden möchte.


    LG,

    Jasmin

  • media-build-dkms

    Hi!


    Hinter der Aussage stehe ich immer noch. Das Define war schon bei Kernel 2.6.36 depreciated.

    Manchmal fliegen ganze Treiber aus dem Kernel und manchmal passieren API Änderungen ganz absichtlich und dann brechen eben Treiber oder Applikationen: https://www.golem.de/news/kern…leme-1901-138698.amp.html Da steht die Nummer zwei der Kernel Entwickler dahinter.


    Ich kann mich erinnern, beim DD Treiber haben neben mir doch einige andere Daniel unterstützt und der Treiber ist jetzt drinnen.

    Beim TT 6400 Treiber kann ich auch was schreiben wenn du willst. Nur kann ich da technisch nicht viel beitragen, weil ich eben das verwendete API nicht kenne. Und ich denke mal da draußen gibt es auch nur sehr wenige die das verstehen. S:oeren, du hast dich da eben eingearbeitet und du bist der Meinung das gehört so, also können wir anderen außer "Ja, wir brauchen den Treiber" nicht viel beitragen.

    Und ich bin sicher die User der TT 6400 Karte würden den Treiber gerne im Kernel sehen. Auf der anderen Seite kann man diese HW ja kaum noch kaufen, soweit ich mich an die Diskussion erinnere.


    Was auch immer, in dem Thread hier geht es um das media-build-dkms und nicht die TT 6400 Treiber Integration in den Kernel.

    Das die Erweiterung des DKMS um den TT 6400 Treiber betrifft, so warte ich auf einen Pull Request oder ich finde irgendwann doch mal Zeit dazu. Aus Anwendersicht ist die Integration in das DKMS zumindest sinnvoll solange der Treiber nicht im Kernel ist.


    LG,

    Jasmin

  • media-build-dkms

    Hallo!

    Zitat von S:oren

    Aber weil die Situation noch nicht frustrierend genug ist, kann die liebe Jasmin es nicht lassen, bei jeder sich bietenden Gelegenheit diesen Unsinn zu unterstützen, in dem sie jedem erzählt, dass dieses API ja deprecated ist und man halt damit leben muss, dass es nicht mehr funktioniert. Wenn Du Dich so gut mit diesem API auskennst, wie stellst Du Dir denn so eine Konversion vor?

    Ich habe keine Ahnung von dem API, ich habe nur auf der Media Liste einige Zeit mitgelesen und dabei den Eindruck bekommen, dass Mauro etwas verlangt was nicht zur TT 6400 Hardware passt. Er will das aber auch nicht so akzeptieren wie es jetzt ist. Ob Mauro die älteren APIs nicht versteht oder recht hat kann ich nicht beurteilen und ist mir im Grunde auch egal.

    Was ich schade finde ist, dass die Kommunikation mit ihm so mühsam ist, dass man nicht sinnvolle technische Diskussionen führen kann. Zumindest waren die Response Zeiten von Mauro sowohl beim DD Treiber, als auch beim TT 6400 Treiber sehr lange. So lange, dass Daniel ausgestiegen ist und somit die DD Treiber keinen Maintainer mehr haben. Und dich S:oren hat er eben auch schon sehr verärgert, soweit ich das mitbekommen habe.

    Warum du einen Pick auf mich hast weiß ich zwar nicht, wird wohl ein Missverständnis sein.


    Zitat von S:oren
    Nun, ich habe für 4.20 alle Aufräumarbeiten erledigt, die irgendwie sinnvoll sind. Ich werde diesen Stand auch nochmal bei linux-media einreichen (nachdem er noch etwas getestet ist). Wenn ich aber keine Unterstützung von anderen Anwendern bekomme, und andere Entwickler zu frustriert sind, hierzu noch etwas zu sagen, oder mir gar noch in den Rücken fallen, dann sind die Aussichten vielleicht nicht allzu rosig...

    Mein Steckenpferd ist die CI Schnittstelle und da habe ich seit 6 Monaten noch etwas zu fixen. Bei den Treibern kann ich absolut nichts beitragen, weil ich mich schlicht mit den APIs nicht beschäftigt habe. Wenn ich da jemals etwas tun werde, dann höchstens versuchen die DD Treiber weiter zu bringen, weil diese HW hab eich selbst. Aber Daniel hatte da so viel Wissen angesammelt, dass er nicht zu ersetzen ist.


    Zitat von S:oren

    Es gibt Treiber-Versionen für alle Kernel seit 4.12, diese Version funktioniert auch für ältere Kernel, zumindest seit den letzten 3.x. Jeder mit etwas git-Erfahrung kann sich daraus diffs zwischen den verschiedenen Kernel-Version erzeugen.


    Ich selbst bin ausschließlich an einer endgültigen Lösung für diesen Treiber interessiert (kernel-merge). Ich wünsche mir, die "Community" würde mich darin unterstützen und nicht so viel Zeit mit ärgerlichem Gefrickel verschwenden (müssen).

    Also ich verstehe das so.

    Du willst die TT 6400 Treiber im Kernel sehen. Wäre tatsächlich die beste Lösung. Ob das gelingt werden wir sehen. Kann also bis Kernel 5.4 auch dauern oder nie passieren.

    Bis dahin müssen alle nicht so versierten Anwender den TT 6400 Treiber selber bauen (wie bisher auch), oder ich setzte mich hin und investiere die Arbeit den Treiber in mein DKMS einzubauen. Dazu werde ich aber weder kurz, noch mittelfristig Zeit finden.

    Aber vielleicht hat ja irgendein TT 6400 User Zeit das mal zu machen und mir einem Pull Request zu schicken.


    LG,

    Jasmin

  • media-build-dkms

    Hi!

    Zitat von SurfaceCleanerZ

    wäre evtl. eine Integration der FF HD Treiber möglich, wie im alten media-build-dkms?

    https://github.com/s-moch/linux-saa716x/branches

    S:oren hat vor einiger Zeit versucht den Treiber in den Kernel zu bekommen, aber der media-tree Maintainer ist leider etwas mühsam. Vor allem hat dieser Anpassungen gefordert die doch aufwändig zu implementieren wären und somit hat S:oren es aufgegeben, denke ich.


    Im Grunde ist mein DKMS nur exakt der Stand von media-tree zum Zeitpunkt des Erstellens des Paketes. Wenn ich jetzt anfange andere Treiber einzupflegen, dann halse ich mir doch einiges an Arbeit auf. Speziell dann, wenn verschiedene Treiber nicht an die allerletzten Sourcen von media-tree angepasst sind.

    S:oren scheint aber sehr fleißig mit den Treiber Anpassungen zu sein. In seinem Repo gibt es schon eine Version für Kernel 4.20. Ich habe jedoch noch nicht versucht die Patches rein zu nehmen. Die Problematik wird eher sein die Backport Patches für ältere Kernel Versionen zu machen. Wenn S:oren das nirgendwo gemacht hat, dann müsste ich das alles erstellen. Das kann in wenigen Minuten erledigt sein oder Tage benötigen. S:oren hat zwar ältere Versionen im Repo, aber um media-build für alle älteren Kernels zum Compilieren zu bewegen bedarf es einer anderen Struktur.

    Wenn S:oren daran interessiert ist den Treiber in mein DKMS zu integrieren, dann wäre es eine große Hilfe wenn er einen "backports" Folder mit den notwendigen Patches anlegen würde und mal für alle Kernel Versionen zurück bis x.y die Patches zu testen. S:oren weiß sicher wie media-build funktioniert. Um das dann in das DKMS zu integrieren müsste es aber auch einen großen Basis Patch geben, den ich integrieren kann. Den müsste ich aber auch automatisch erstellen können, wenn ich einen Diff in seinem GitHub Repo beim DKMS erstellen mache.


    Wenn sich media-build-dkms als Ablöse von media-build-experimental etablieren soll, dann werde ich langfristig den Treiber wohl integrieren müssen. Ich bin aber derzeit auf Urlaub und habe kaum Zeit dafür hier in der iNet Wüste auf der Insel. Aber es gibt ja einige Vorbereitungen von S:oren zu machen, wenn er das möchte. Im Grunde kann er es auch in mein DKMS selbst einbauen. Es ist genau dokumentiert wie das DKMS funktioniert und wie man es erstellen muss. Wenn ich einen Pull Request bekomme, dann pflege ich den gerne ein.


    LG,

    Jasmin

  • Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

    Hi!


    Erstens macht den Linux Treiber nicht DD, sondern die Firma Metzler Brothers, Marcus und Ralph Metzler Systementwicklung GbR. Diese ist von DD beauftragt und meines Wissens nach hatten/haben der Windows und der Linux Treiber eine gemeinsame Code Basis, was eine Integration in den Kernel nicht leichter macht.

    Und ja Ralph hat DVB mit ins Leben gerufen vor vielen Jahren. Ich bastle heute noch an Korrekturen in seinem Code, der im Grunde sehr gut ist.


    Allerdings ist da dieser Kernel Maintainer Mauro Carvalho Chehab, der schon einige Entwickler vergrault hat. Oliver E., der Media-Build-Experimental, den Vorgänger meines Media-Build DKMS Paketes, gemacht hat, hat die Arbeit an den Treibern genau wg. Mauro aufgegeben. Und Mauro ist jetzt auch der Grund für das Aufgeben von Daniel.

    Auf der anderen Seite verstehe ich Mauro auch, weil media-tree in der Zwischenzeit ca. 2780 Files enthält und das kann niemand mehr überblicken. Da bleibt dann schon mal was liegen. Was ich aber nicht verstehe ist, dass sich Mauro keine Hilfskräfte zulegt. Ich maintaine derzeit media-build, weil man mich gefragt hat ob ich das tun will. Genauso gibt es sicher viele Entwickler die Teile übernehmen könnten. Und ja, er hat schon Helfer, aber zu wenige. Vielleicht sollte ich da mal versuchen was auf der media-tree Liste anzufachen. Im Grunde ist das eine Sache des Vertrauens und wenn man Prozesse definiert dann könnten auch mehr Leute Schreibrechte in das Repo haben. ich darf jetzt auch meda-build beliebig verändern, tu das aber nur sehr gewissenhaft.


    Und um noch eine andere Seite zu beleuchten, DD hat sicher eher weniger Kunden im Privaten Bereich, sondern mehr bei Hotel Systemen und Kopfstationen. Dort gibt es aber 100% DD Lösungen, deshalb ist die Interaktion mit anderen Karten für die Firma nicht so wichtig. Ein Schelm könnte meinen, dass eine Kombination mit anderen Karten unerwünscht ist. Sprich man könnte eine billige Tuner Karte von xyz mit einer CI Hardware von DD kombinieren und somit zu einer günstigeren Lösung kommen. Geht bei Treibern aus dem DD Repo schlicht nicht. Also könnte man davon auch ableiten, dass man Kunden verlieren würde, wenn man die Integration in den Kernel auch noch bezahlt und das würde keine Firma machen.

    Ich sehe das zwar anders, aber die haben bei DD schon eine eigene Ansicht über Open Source und wie man damit umgeht, wie man an der neuesten Hardware auch sieht, wo die Steuerung der verschiedenen Komponenten vom FPGA aus gemacht wird und der Treiber nicht direkt den Demod oder Tuner oder was auch immer für einen Chip kontrollieren kann. Sprich man muss jetzt dann öfter FPGA Firmware tauschen. Treiber dieser Entwicklung war meiner Meinung nach eine Falsche Sichtweise auf Open Source und angebliche Lizenzbedingungen.


    Andere Hersteller und auch ich sehen da eher die Vorteile von Open Source und einige Fehler in den DD Treibern wurden von Daniel währen der Portierung gefunden. Immer wieder finden andere jetzt noch Dinge in dem Code. Davon profitiert die Qualität der Linux Treiber und das ist eine der Stärken von Open Source. Diese Sichtweise ist aber in der Möwestrasse in München noch nicht angekommen. Schade, weil die Hardware von DD ist wirklich gut und modular und kann mittlerweile auch schon DVB S2X. Und die Firma ist in Deutschland und nicht in Fernost, also ist die Kommunikation besser und auch die Wertschöpfung bleibt in Europa. Alles gute Gründe Karten von DD zu verwenden, aber das Drumherum macht es eben nicht einfach.


    Um nochmals auf die Entscheidung von Daniel zurück zu kommen, ich habe das so verstanden, dass er das ev. dann wieder machen würde, wenn nicht immer so viel Zeit bei Antworten des Maintainers vergehen würden, weil er diese Tätigkeit auch gerne gemacht hat. In dem Sinne könnte man mit Sub-Maintainern eben kürzere Antwortzeiten erreichen. Vielleicht kommt es ja in den nächsten Wochen zu einer sinnvollen Diskussion auf der Mailingliste.


    LG,

    Jasmin

  • Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

    Hallo nst!


    Schade, Schade, Schade!


    Du hast das echt spitze gemacht!

    Dank deines grandiosen Einsatzes die letzten 16 Monate (ja, so lange hat das gedauert!), haben wir die Treiber für alle verfügbaren DD Empfangskarten im Kernel integriert bekommen und wir brauchen keine inkompatiblen Spezialtreiber von DD selbst compilieren. Die DD Karten funktionieren zusammen mit allen im Kernel unterstützten Karten, was die original DD Treiber nicht hergeben. Das haben schon einige Versucht, aber du hast es tatsächlich geschafft!


    Nachdem DD deine Arbeit nicht fortsetzten wird, weil das hätten sie ja schon bisher tun können, wird es wohl beim jetzigen Stand bleiben, es sei denn es findet sich wieder jemand. Ich kann ein wenig beurteilen wie schwierig es ist so etwas zu stemmen, wenn man keine Datenblätter bekommt und sich alles aus dem Code und mit der Lupe auf den Karten selbst raus suchen muss. Ich behaupte mal, dein Wissen über diese Karten ist außerhalb von DD einzigartig, weshalb es auch schwierig wird einen Nachfolger zu finden.


    Ich möchte noch erwähnen, dass der Grund für das Aufgeben der bisherigen Maintainer und da schließe ich DD jetzt mit ein, der schwierige media-tree Maintainer Mauro ist. Ich persönlich habe mit ihm zwar keine Probleme, aber sehr viele schon. Und dieser Maintainer, oder besser seine Art zu managen und Forderungen zu stellen, ist der eigentliche Grund für dieses Desaster.


    Zitat von nst

    @Moderatoren - Bitte am besten bei Gelegenheit den Thread zu machen.

    Ich würde das nicht tun, weil vielleicht geht es ja weiter.


    LG,

    Jasmin

  • media-build-dkms

    Hi!


    Ich habe gerade eine Version 0006 ins Launchpad geschoben.

    Darin ist der heutige Stand von media_build und media_tree enthalten. Der Nightly-Build hat für alle Kernel Versionen fehlerfrei mit gcc 8.x gebaut.

    Ich habe wie immer den "mediatree/master-ddbridge" Branch von nst ins DKMS gepackt.


    Es ist auch der Fix für die Unresolved Symbols drinnen (das waren diese hier).


    Es gibt aber immer noch unresolved Symbols, diese sollten aber für eine Benutzung mit VDR oder TVH kein Problem darstellen. Wenn doch, bitte melden, dann muss ich das doch früher als ich wollte fixen. Hier die Liste


    Bitte mach vor der Installation eine Sicherheitskopie. Alte Versionen des DKMS Paketes findet man hier. Version 0004 hatte bis jetzt am Besten funktioniert, falls es Probleme mit 0006 geben sollte.


    Ich habe das Paket NICHT getestet, weil ich noch immer keine Zeit habe. Ich würde mich über Rückmeldungen freuen und hoffe es klappt alles.

    Und nicht vergessen, der DKMS Speed Patch sollte vor der Installation angewendet werden, sonst dauert das Builden extrem lange.


    LG,

    Jasmin

  • media-build-dkms

    Hi!


    Ich habe bereits einen Fix für das Problem in meinem Git, aber den muss ich mir vom Chef Maintainer von media_build bestätigen lassen, bevor ich den einchecke.


    Derzeit haben wir keine Möglichkeit unresolved externals beim Build zu finden, aber ich habe dem Chef Maintainer auch diesbezüglich einen Vorschlag gesendet um das im Nightly Build bereits zu erkennen. Es ist nur generell nicht so einfach solche Probleme zu fixen, da man ja rückwirkend keine Symbole in alte Kernel einbringen kann, die erst in späteren Versionen eingebaut wurden. Sprich ich muss mir eine neue Möglichkeit das doch zu tun mit ihm überlegen. Die derzeit in media_build vorhanden Möglichkeiten mit "compat.h" sind nicht immer ausreichend.


    LG,

    Jasmin

  • media-build-dkms

    Die besagten Funktionen sind erst mit Kernel 4.3 verfügbar.

    Also alle die einen älteren Kernel haben sollten nicht von 0004 auf 0005 upgraden!

    Ich versuche einen Fix zu machen.


    LG,

    Jasmin

  • media-build-dkms

    Danke fürs testen!

    Zitat von holymoly

    [ 1866.479534] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
    [ 1866.479562] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
    [ 1866.479586] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
    [ 1866.479628] videobuf2_memops: Unknown symbol frame_vector_create (err 0)

    Das ist jetzt aber wieder mal saublöd!

    Ich muss das in medial_build fixen. Ich kann das nicht so leicht vorab testen, weil man einen Maschine mit jedem Kernel benötigen würde und dann alle Module mit modprobe testen müsste. Deshalb brauch ich immer Tester und kann erst im Nachhinein die Probleme fixen.


    Das hier wird leider ein wenig Zeit brauchen, weil ich gerade keine Zeit neben Firma und Familie habe. Wenn ich am WE Luft haben sollte, dann versuche ich es zu lösen.


    Sorry für die Unannehmlichkeiten!


    LG,

    Jasmin

  • media-build-dkms

    Zitat von wmautner

    Diese Treiber sind doch in den neueren Kernels "extra" und müssen nicht geladen werden. Einfach linux-midules-extra-*kernel*-generic deinstallieren oder nicht installieren, sollte auch helfen?

    Also das Paket linux-modules-extra-****-generic enthält viel mehr Treiber als nur die media Treiber. Das Paket zu de-installieren halte ich für keine gute Idee.

    Außerdem sind in 4.15 die DD Treiber bereits enthalten (ein wenig älterer Stand) und das DKMS ist nicht unbedingt nötig, außer man hat ein Problem.


    Das DKMS existiert primär für ältere Kernel Versionen, wo die DD Treiber noch nicht enthalten sind.

    Im Grunde hab ich es für yaVDR 0.6.x gemacht (Ubuntu 14.04/Kernel 3.13).


    Wenn jemand andere als DD Karten besitzt, kann das wieder anders aussehen und das DKMS bringt den Treiber Stand von voriger Woche mit.


    LG,

    Jasmin

  • media-build-dkms

    Zitat von Dr. Seltsam

    Nach einem reboot funktioniert es!

    Na da fällt mir aber ein Steinderl vom Herzen. Danke fürs testen!


    Zitat von Dr. Seltsam

    Jasmin, kannst Du zu dem dkms-speed-patch nochmal etwas mehr sagen? Worauf wird der angewandt?

    Kurze Antwort:

    GuckstDU im ersten Post, da hab ich erklärt wie man den "dkms.patch" installiert. Genauso machst du das mit dem dkms_speed.patch.


    Zum Verstehen:

    In dem Patch steht

    Diff
    --- a/dkms      2016-09-24 04:42:25.000000000 +0200
+++ b/dkms      2017-09-10 16:46:35.658472976 +0200

    Das bedeutet er sucht die Datei "a/dkms" um sie zu verändern.

    Mit "which dkms" erfahren wir, dass die "dkms" Datei in "/usr/sbin" zu finden ist (das geht nur mit Executables so, sonst müsste man "locate" bemühen).

    Dann mit "cd /usr/sbin" dorhin wechseln und dann den Patch anwenden. Dazu ist der Parameter "p1" notwendig, weil wir nicht "a/dkms" patchen wollen, sondern "dkms". Und man muss patch mit sudo aufrufen, weil "/usr/sbin/dkms" nur von root verändert werden darf.


    LG,

    Jasmin