Probier es einfach aus, wir arbeiten gerade an einem vdradmin der ebenfalls ne Menge patches haben muss. Also mach einfach einen Eintrag in 00list: 50_meinpatch (Zahl ist die Reihenfolge) und lege deinen patch unter diesem Namen in das patches verzeichniss.
Dann lass es knallen mit debian/rules clean && debian/rules binary 
ZitatOriginal von xpix
Probier es einfach aus, wir arbeiten gerade an einem vdradmin der ebenfalls ne Menge patches haben muss.
Hey, heisst das, es wird demnächst ein VDRadmin mit Timeline-Patch etc. geben? 
ZitatOriginal von xpix
Also mach einfach einen Eintrag in 00list: 50_meinpatch (Zahl ist die Reihenfolge) und lege deinen patch unter diesem Namen in das patches verzeichniss.
Dann lass es knallen mit debian/rules clean && debian/rules binary
Wie, so einfach soll das sein? Dann werd' ich das mal probieren.
ByE...
ZitatOriginal von xpix
Probier es einfach aus, wir arbeiten gerade an einem vdradmin der ebenfalls ne Menge patches haben muss. Also mach einfach einen Eintrag in 00list: 50_meinpatch (Zahl ist die Reihenfolge) und lege deinen patch unter diesem Namen in das patches verzeichniss.
Dann lass es knallen mit debian/rules clean && debian/rules binary
Nabend..
Passt überhaupt nicht zum thread, sorry, Aber da ich ja scheinbar die vdradmin-entwickler hier habe:) möchte ich euch auf eine andere Frage von mir lenken, die euer Projekt betrifft. und zwar HIER
Nochmals sorry, aber ich finde die idee zu gut, um sie wieder zu vergessen. Gruss und schönen Abend noch..
Cat
ZitatNochmals sorry, aber ich finde die idee zu gut, um sie wieder zu vergessen. Gruss und schönen Abend noch..
Lieber catweazel, ja ich bau den bigpatch aber .... ich hab keine Ahnung von c und weiss auch nicht wie man ein plugin baut. Die Idee ist gut, ich denke mal die Idee solltest du in das Forum reinstellen.
atl:
Bei Einbinden eines neuen Patches gehe ich immer so vor:
a) Eine vorhanden *.dpatch-Datei nach xx_meinpatch.dpatch kopieren
b) das alte diff darin rauschmeissen und das neue einfügen (hinter @DPATCH@)
c) Die Angaben im Kopf des dpatch-Files anpassen (Autor u.s.w.)
d) In debian/patches/patches den neuen patch z.B. in multipatch vor dem ersten Patch eintragen
e) debian/patches/patchtest --quick aufrufen
f) Schlägt ein Patch fehl, dann veschiebe den neuen Patch hinter den fehlgeschlagenen Patch und rufe debian/patches/patchtest --solve auf. Jetzt wird der neue Patch fehlschlagen und du hast in /tmp die Verzeichnisse vdr und vdr.orig. In vdr kannst du dann die Rejects auflösen und dann mit diff -Nur vdr.orig vdr einen neuen Patch erzeugen, mit dem du dann im Originalpaket den alten neuen Patch ersetzt.
Dann weiter mit Punkt e) solange, bis es läuft.
g) debian/patches/patchtest aufrufen um zu sehen, ob sich alles noch patchen und compilieren lässt
h) Den Patch an mich schicken
Gruß,
Tobias
ZitatOriginal von Tobi
Bei Einbinden eines neuen Patches gehe ich immer so vor:
...
Na das ist doch mal 'ne Anleitung. Danke!
ZitatOriginal von Tobi
d) In debian/patches/patches den neuen patch z.B. in multipatch vor dem ersten Patch eintragen
Du meinst sicherlich /debian/patches/patchtest - welche mittels chmod +x /debian/patches/patchtest noch ausführbar gemacht werden muss, denn die Datei /debian/patches/patches gibt es gar nicht.
ZitatOriginal von Tobi
g) debian/patches/patchtest aufrufen um zu sehen, ob sich alles noch patchen und compilieren lässt
Okay, soweit so gut. /debian/patches/patchtest --quick läuft durch. Aber das reine /debian/patches/patchtest schlägt dann fehl:
OK ct
OK ct_ac3
OK ct_elchi
OK ct_elchiac3
OK ct_elchiosdpip
OK ct_elchiosdpipac3
OK multipatch
OK multi_cam1
FAILED multi_cam2 - Build Error
Gibt es irgendwelche Möglichkeiten, nach zu sehen, was da schief geht?
ZitatOriginal von Tobi
h) Den Patch an mich schicken
Lieber nicht!
ByE...
ZitatOriginal von atl
CodeOK ct OK ct_ac3 OK ct_elchi OK ct_elchiac3 OK ct_elchiosdpip OK ct_elchiosdpipac3 OK multipatch OK multi_cam1 FAILED multi_cam2 - Build Error
Gibt es irgendwelche Möglichkeiten, nach zu sehen, was da schief geht?
Es klappt. Irgendwie scheint das ganze Gepatchteste die Sourcen etwas durcheinander zu wirbeln. Nach dem ich das VDR-Source-Package noch einmal neu heruntergeladen habe und dann inkl. dem neuen Patch mal kompiliert habe, zeigte der Compiler den Fehler (ungültige gcc-Option) auf. Nach der Korrekur lief dann alles. Also hier noch mal ein Danke für die kurze und gute Anleitung. Die wäre vielleicht auch was für Doku auf deiner (Tobi's) Seite.
ByE...
Ich speichere in dem Fall leider keine log-files weg. Du müsstest es ganz einfach von Hand ausprobieren, indem du die patches aus dem multi_cam2 TestCase in 00list freischaltest. Hast du deinen patch denn dem multi_cam2 TestCase hinzugefügt? Falls nicht, dürfte es da eigentlich keine Probleme geben.
Hallo
Also, ich mache es etwas anders - und zwar mit den Standardwerkzeugen von dpatch.
[list=1]
[*]Den letzten Patch feststellen mit:
dpatch-list-patch
Der letzte Patch ist z.B. 47_osdpip-0.0.3-apid.
[*]Den neuen Patch, z.B. 91_UPT, erzeugen mit:
dpatch-edit-patch 91_UPT 47_osdpip-0.0.3-apid
Dies eröffnet eine neue Shell in einem temporären Verzeichnis. Hier liegen die mit allen Patches bis 47_osdpip-0.0.3-apid gepatchten Quellen. Jetzt kann man Dateien editieren oder den Original-Patch einspielen und alle Rejects auflösen (danach *.rej und *.orig löschen). Mit exit kommt man zurück und der Dpatch wird automatisch erzeugt.
[*]Neuen Patch in 00list am Ende eintragen.
[*]Patchtest ist nicht unbedingt nötig, da der neue Patch am Ende angehängt wird und somit die anderen nicht stört. Kann aber auch nicht schaden
[/list=1]
Punkt 2 kann auch ersetzt werden durch
dpatch-convert-diffgz
wenn man nur einen vorhandenen Patch in einen Dpatch umwandeln will.
Tom
patchtest ist in erster Linie dafür da, z.B. bei einem neuen Elchi-Patch zu testen, ob alle patch-kombinationen noch laufen.
Das mit dpatch-edit-patch hatte ich auch schon probiert, nur hat in der neuen Shell das cut and paste nie funktioniert und ich bin noch nicht dahinter gestiegen, warum.
ZitatOriginal von Tobi
Ich speichere in dem Fall leider keine log-files weg. Du müsstest es ganz einfach von Hand ausprobieren, indem du die patches aus dem multi_cam2 TestCase in 00list freischaltest.
Naja, so ähnlich hab ich's dann auch gemacht. Ich hab den in 00list eingetragen und ein dpkg-buildpackage -tc angeworfen. Der Compiler hat dann an der entsprechenden Stelle gemeckert. Es war in dem Fall auch kein Problem beim Patchen sondern das durch das Patchen eine unbekannte Compiler-option ins Makefile eingefügt wurde.
ZitatOriginal von Tobi
Hast du deinen patch denn dem multi_cam2 TestCase hinzugefügt? Falls nicht, dürfte es da eigentlich keine Probleme geben.
Yepp, genau. Mein Patch war in multi_cam2 aktiv.
ByE...
ZitatOriginal von TomG
Punkt 2 kann auch ersetzt werden durch
dpatch-convert-diffgz
wenn man nur einen vorhandenen Patch in einen Dpatch umwandeln will.
Das hatte ich auch schon probiert und heraus kam ein .dpatch-File, in dem keine brauchbaren Infos drin waren. Die Methode von Tobi hingegen hat wunderbar funktioniert und ist - zumindest für mich - auch nachvollziehbar. So weiss ich, was da geschieht und kann mir die ganze Vorgehensweise besser merken.
ByE...
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!