GIT-Archiv für VDR auf http://git.tvdr.de

  • Unter http://git.tvdr.de gibt es ab sofort ein GIT-Archiv der kompletten VDR-Source, mit allen einzelnen Änderungen seit der ersten Version.


    Ich habe dieses Archiv mittels eines Perl-Scripts aus meinem RCS generiert und werde es bei künftigen Änderungen entsprechend aktualisieren. Ich persönlich werde weiterhin die VDR-Source mit RCS verwalten, das GIT darf aber als "offizieller Stand" betrachtet werden. Natürlich wird es auch weiterhin wie gewohnt bei jeder neuen Version eine Distributionsdatei geben.


    Um beim Generieren des GIT aus dem RCS den Stand in den bisherigen Distributionsdateien möglichst genau abzubilden, waren bei einigen Dateien Modifikationen nötig, damit zusammengehörige Änderungen, die mehrere Dateien betreffen, nicht zu separaten Commits führten. Hier eine Zusammenfassung dieser Modifikationen, damit sich niemand wundert, falls er einen Vergleich des GIT-Standes mit der entsprechenden Distributionsdatei durchführt:


    While generating a GIT repository from my RCS archive, I had to make the following changes to the files in order to make sure the result corresponds as closely as possible to the versions published in the original distribution archives:

    • Consolidated several file dates and revision numbers. You can see these changes in the "$Id:" entries if you run 'diff' on a file's version from an original distribution archive and the GIT.
    • In version 0.06 the line

      while ((k->type != kNone) && strncmp(k->name, Command, strlen(k->name)) != 0) //XXX why 'strncmp()'???

      was changed to

      while ((k->type != kNone) && strncmp(k->name, Command, strlen(k->name)) != 0) // must use 'strncmp()' because LIRC delivers trailing characters!

      in config.h after the distribution archive was generated.

    • The "Tools" subdirectory that was part of the VDR archive from version 0.6 through 0.99pre1 is not contained in this GIT archive.
    • Some files that inadvertently slipped into some distribution archives (like setup.conf, x.txt, epg.data, gmon.out, eit.diff, params.txt, mpatrol.diff, locale or Syd) have not been put into the GIT.
    • The file UPDATE-2.0.0 first appeared in the distribution archive for version 1.7.38, but earlier versions (starting with 1.7.32) have been put into the GIT.
    • Some typos have been fixed after generating the distribution archives, without making that a separate RCS commit.
    • The plugins source directory (introduced in version 1.1.0) was originally named PLUGINS/SRC and renamed to PLUGINS/src in version 1.1.18. To avoid segmentation of the source, the directory was changed to PLUGINS/src for all versions 1.1.0 through 1.1.18 during the conversion to GIT. The Makefile, PLUGINS.html and newplugin have been modified accordingly, so the source code is consistent over all versions.
    • The files channels.conf, timers.conf and keys.conf were never stored in my RCS, but since they appeared in the official VDR distribution archives I have added them to the GIT.
    • The file Make.global was not in the distribution archive for version 1.7.34, because it has been removed in that version. However, since it was reintroduced in version 1.7.35, it also appears in V10734 of the GIT.
    • The 'dvbhddevice' plugin has been removed from the tree.
    • The email address of Patrice Staudt <ipatrice.staudt@@laposte.net> was fixed to read <patrice.staudt@@laposte.net>.
    • In version 1.7.23 an intermediate revision of epg.c has snuck in, which contained a temporary modification that was later revoked.
    • For some odd reason the file osd.c was missing the 'if (Level == 0...' part in the VDR archives from version 1.3.13 through 1.5.8. No idea how that happened...
  • Vielen Dank dafür, Klaus. Ein lang gehegter Wunsch vieler hier ... :tup

    MyVDR: yaVDR-Ansible (Ubuntu 18) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Wow, der feuchte Traum vieler geht in Erfüllung ... 😂👍🏻✔


    Danke Klaus für all Deine Mühen.


    Gruß

    Frank

    HowTo: APT pinning

  • Praktisch! :wow Vielen Dank dafür! Ich warte schon länger gespannt auf das Resultat, denn angekündigt war es ja schon länger ;)


    Hilfreich vor allem wenn mal jemand wieder den Fall "mit VDR-Version X geht es noch" hat. Dann kann jetzt gezielt auf das "fehlerhafte" Commit zurückgeschlossen werden.


    Ich kenne deine Scripte nicht, aber wenn ein "Update" passiert, dann bleiben die bestehenden Commit-IDs doch hoffentlich gleich und neue Commits kommen nur "oben dran"?


    Ich werde die bestehenden Mirrors auf jeden Fall weiter pflegen, jetzt aber regelmäßig dort eine Kopie vom "offiziellen" Repo ablegen.

  • Das dürfte sich automatisch einstellen wenn das Repository nur "fortgeführt" wird und nicht immer komplett neu erstellt werden muss. Aber wie schon geschrieben: Ich kenne deinen Scripte nicht.


    Edit: Oh. Der Server wird wohl gerade geDDOSt :P


    Edit2: Hier der Stand vom "Community GIT" als Archiv. Ich wollte das nicht einfach "wegwerfen": https://github.com/M-Reimer/vdr-tarballs

  • Das dürfte sich automatisch einstellen wenn das Repository nur "fortgeführt" wird und nicht immer komplett neu erstellt werden muss. Aber wie schon geschrieben: Ich kenne deinen Scripte nicht.

    Ich habe vor es so zu machen, dass immer nur "fortgeschrieben" wird.

    Aber in meinen Tests habe ich auch gesehen, dass selbst bei einem kompletten Neu-Generieren alle Ids gleich bleiben, solange sich nichts an den Ausgangsdaten ändert.

    Der Server wird wohl gerade geDDOSt

    Ich sehe hier keine hohe Last.

    Hattest du eine Fehlermeldung?

  • Und der zweite Mirror steht auch: https://projects.vdr-developer.org/git/vdr.git/


    Beide werden von mir manuell angeglichen. Sollte etwas mit den Scripten von Klaus noch nicht passen hat das also keine Auswirkungen auf die Mirrors. Bevor ich manuell abgleiche prüfe ich dann erst ob noch alles passt.


    Aktuell ist also immer nur das offizielle Repository. Gerade der GitHub-Mirror erlaubt es aber ggf. für eigene Entwicklung einen Fork ins eigene Profil zu ziehen.

  • Ich interpretiere den aktuellen Status eher so das 2.4.3 das nächste Release werden wird aber eben noch nicht veröffentlicht wurde.


    Wenn es ganz offiziell eine 2.4.3 gibt, dann wird Klaus die sicher auch wie gewohnt als Paket ablegen und wie gewohnt ankündigen.


    Edit: Sehe gerade das das Tag schon dran ist. Entweder das war ein Versehen oder es fehlt (aktuell) wirklich nur noch das Paket für ein offizielles Release.


    Edit2: Ich glaube ich komme mit den Releases jetzt komplett durcheinander. Ein 2.4.2 wurde ja so auch nie angekündigt. Da ist sowohl tvdr.de wie auch die abgelegten Tarballs nicht auf dem aktuellen Stand.


    Edit3: Man kann sich das hinbasteln. Ich könnte damit leben. Frage ist halt ob Klaus die Webseite und die abgelegten Pakete noch aktualisiert. Wenn nein würde ich das für vdr4arch auf dieses Schema umbauen:

    Version 2.4.2: http://git.tvdr.de/?p=vdr.git;…h=refs/tags/V20402;sf=tgz

    Version 2.4.3: http://git.tvdr.de/?p=vdr.git;…h=refs/tags/V20403;sf=tgz

  • Die Versionsnummern 2.4.2 und 2.4.3 waren notwendig wegen Änderungen an einigen Header-Files (siehe HISTORY), um dafür zu sorgen, dass Plugins neu übersetzt werden. Das offizielle "stable/2.4" Label im GIT werde ich auf die "master" Version setzen, sobald sich der Stand stablisiert hat (sprich: keine schlimmen Fehler mehr auftreten). Dann gibt es natürlich auch wieder ein entsprechendes Archiv auf ftp.tvdr.de.

  • Versuch gerade ein ‘git clone’ aber das fehlt:

    Code
    1. git clone http://git.tvdr.de/vdr.git vdr-git
    2. Cloning into 'vdr-git'...
    3. error: Failed writing body (0 != 2669) (curl_result = 23, http_code = 200, sha1 = 3c9ec9ca9e67925b737c2540174dc938f7719c81)
    4. error: Unable to find 3c9ec9ca9e67925b737c2540174dc938f7719c81 under http://git.tvdr.de/vdr.git
    5. Fetching objects: 2105, done.
    6. Cannot obtain needed blob 3c9ec9ca9e67925b737c2540174dc938f7719c81
    7. while processing commit 968c2ede0d419d1c8ae998d0dac554b688e45a83.
    8. error: fetch failed.