Plugins patchen: Zusammengefasste Änderungen durch mehrfache Anrwendung von dpatch-edit-patch ?

Auf einem Ubuntu 8.04 Hardy Heron versuche ich beim Paketbauen durchzublicken:

Ich hole mir z.B. in ein neues Verzeichnis
cd /usr/local/src/vdr; apt-get source vdr-plugin-burn
Das hatte Zuwendung besonders nötig:
wget http://launchpadlibrarian.net/23999811/99_ten.tar.gz; cd vdr-plugin-burn-0.1.0~pre21;tar xvfz ../99_ten.tar.gz
Am Ende von debian/patches/00list steht nun also 99_ten für meinen debian/patches/99_ten.dpatch

Und nun das Problem:
Rufe ich nun dpatch-edit-patch -a 99_ten auf (mit -c habe ich auch nicht mehr Erfolg), meldet dieses:

Zitat

[...]
applying patch 92_requantfactor to ./ ... ok.
applying patch 99_ten to ./ ... ok.
dpatch-edit-patch: * Copying reference directory /tmp/dpep-ref.k10292/vdr-plugin-burn-0.1.0~pre21 to work directory.
dpatch-edit-patch: * Applying current 99_ten.dpatch for editing.
99_ten already applied to ./ .

dpatch-edit-patch:

Now launching an interactive shell in your work directory. Edit your files.
When you are done, exit the shell. When you exit the shell, your patch will be
automatically updated based on the changes in your work directory.

If you wish to abort the process, exit the shell such that it returns an exit
code of "230". This is typically done by exiting the shell with the command
'exit 230'.

Alles anzeigen

Editiere ich in dessen fakeroot-Umgebung z.B. mit gedit gdwrapper.c weitere Quellen und gehe mit exit aus dem fakeroot, erhalte ich die Meldungen:

Zitat

dpatch-edit-patch: Updating patch /usr/local/src/vdr/vdr-plugin-burn-0.1.0~pre21/debian/patches/99_ten.dpatch
dpatch-edit-patch: @DPATCH@ tag found, preserving dpatch header.
dpatch-edit-patch: /usr/local/src/vdr/vdr-plugin-burn-0.1.0~pre21/debian/patches/99_ten.dpatch updated.

Danach liegen aber nur die neuen Änderungen in der ÿdebian/patches/99_ten.dpatch
Versuche ich nun mit dpkg-buildpackage -tc das ../vdr-plugin-burn_0.1.0~pre21-20ubuntu3_i386.deb zu bauen, enthält dieses naturgemäß auch nur die neuen Änderungen.
Es erfolgt also kein ergänzendes Update, sondern eine Ersetzung der debian/patches/99_ten.dpatch.

Natürlich kann man nach jeder Änderung die jeweils neueste debian/patches/99_ten.dpatch "in Sicherheit kopieren" und die verschiedenen Änderungsgenerationen dann manuell in eine Datei zusammenführen - aber an schrittweise Entwicklung ist so kaum zu denken und diese Aufgabe verspricht ja eigentlich dpatch-edit-patch zu übernehmen.

Was entstehen soll, ist ganz einfach: Eine debian/patches/99_ten.dpatch, die alle meine Änderungen zusammenfasst, auch wenn zwischendurch mehrfach dpkg-buildpackage ausgeführt wurde, um das Debian-Paket testweise zu installieren.

Ich habe gelesen, was erreichbar war, neben den man-Pages natürlich u.a. http://www.e-tobi.net/blog/art…ebian-vdr-plug-in-paketes und http://matrixhasu.altervista.org/index.php?view=use_dpatch, aber woran die Aktualisierung des Patches scheitert, konnte ich noch nicht herausfinden.

Wer kann mir sagen, woran es liegt und wie das richtig funktioniert?

Vielen Dank!

Für die nächsten :sucheden: So muß das dann also aussehen:

Zitat

applying patch 90_i18n-fix to ./ ... ok.
applying patch 91_trim-fix to ./ ... ok.
applying patch 92_requantfactor to ./ ... ok.
dpatch-edit-patch: * Copying reference directory /tmp/dpep-ref.J12555/vdr-plugin-burn-0.1.0~pre21 to work directory.
dpatch-edit-patch: * Applying current 99_ten.dpatch for editing.
applying patch 99_ten to ./ ... ok.[/b]

dpatch-edit-patch:

Now launching an interactive shell in your work directory. Edit your files.
When you are done, exit the shell. When you exit the shell, your patch will be
automatically updated based on the changes in your work directory.

If you wish to abort the process, exit the shell such that it returns an exit
code of "230". This is typically done by exiting the shell with the command
'exit 230'.

Alles anzeigen

D.h. nur wenn er auskommentiert ist, wird der bestehende Teil des Patches erst nach dem Anlegen der fakeroot-Umgebung eingespielt und damit auch in das neue Diff übernommen.

Muß der Aufruf mit dpatch-edit-patch -a -c 99_ten erfolgen, weil dpkg-buildpackage -tc (während dem der Patch ja aktiv sein muß) mit folgendem Fehler endet?

Zitat

[...]
dh_clean
dpatch deapply-all
reverting patch 99_ten from ./ ... failed.
make: *** [unpatch] Error 1
dpkg-buildpackage: failure: debian/rules clean gave error exit status 2

Ist es wirklich vorgesehen, daß zwischen jedem Editieren und Compilerlauf jeweils manuell der in Arbeit befindliche Patch ein- und auskommentiert werden muß? Das erscheint doch sehr fehlerträchtig...

Hier mal in einem Rutsch, wie es trotz Verrenkungen noch nicht richtig geht (aber IMHO eigentlich funktionieren müsste):

Zitat

apt-get source vdr-plugin-burn;wget http://launchpadlibrarian.net/23999811/99_ten.tar.gz;cd vdr-plugin-burn-0.1.0~pre21;tar xzvf ../99_ten.tar.gz
sed -i s/99/\#99/ debian/patches/00list;dpatch-edit-patch -a 99_ten;sed -i s/\#99/99/ debian/patches/00list;dpkg-buildpackage -tc
dpkg -i ../vdr-plugin-burn_0.1.0~pre21-20ubuntu3_i386.deb;/etc/init.d/vdr stop;/etc/init.d/vdr start

Damit bleiben die Fehlermeldungen beim Ein- oder Ausbauen des eigenen Patches aus, aber leider werden weitere im fakeroot (z.B. mit nano -w gdwrapper.c;exit) vorgenommene Änderungen trotz entsprechender Meldungen von dpatch-edit-patch und dpkg-buildpackage offenbar nicht der debian/patches/99_ten hinzugefügt und damit auch nicht einkompiliert - müsste es aber.

Gehe ich mit exit 230 aus dem fakeroot, werden zumindest die ersten aus 99_ten.tar.gz stammenden Patches einkompiliert.

Als Test für eine Erweiterung meines 99_ten.dpatch habe ich mal folgendes in Zeile 114 von gdwrapper.c eingefügt (um dem Problem laut Attachment -möglicherweise ein Fehler in draw_image- auf die Spur zu kommen):

Zitat

logger::error( format( "sample: {0}" ) % sample, false );

Ist mir schleierhaft, warum es nur eher zufällig und erst nach mehreren Versuchen in der Binary landet (regelmäßig enthält sie danach weder die ursprünglichen noch die ergänzten Änderungen, obwohl beide in der 99_ten.dpatch landen), wo man sich doch schon die Mühe machen muß, das wie oben zu skripten, weil die umständlichen Aufrufe manuell kaum beherrschbar sind...

Schon wenn ich lediglich gedit statt nano verwende, wirft mir dpkg-buildpackage -tc am Ende außerdem bereits wieder den Fehler aus, 99_ten.dpatch nicht zurückdrehen zu können:

Zitat

dh_clean
dpatch deapply-all
reverting patch 99_ten from ./ ... failed.
make: *** [unpatch] Error 1

Um es zusammenzufassen, es soll ein ganz einfacher Workflow für die Entwicklung herauskommen:
[list="1"][*]Editieren
[*]Inkl. Änderungen kompilieren & debianisieren
[*]Debian-Binärpaket installieren
[*]"if !zufrieden" weiter bei oben 1.
[*]An dieser Stelle geschieht ein Wunder
[*]Release[/list]Hatte in jugendlichem Leichtsinn doch glatt gedacht, dpatch-edit-patch sei dafür die (vollständige) Lösung, nicht Teil des Problems...:]

Sobald man irgendwo einen vom Compiler bemerkten Fehler in den Sourcecode baut, bricht dpkg-buildpackage auch ab, ohne -tc durchzuführen:

Zitat

/usr/include/c++/4.2/bits/ostream.tcc:120: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_streambuf<_CharT, _Traits>*) [with _CharT = char, _Traits = std::char_traits<char>]
make[1]: *** [gdwrapper.o] Error 1
make[1]: Leaving directory `/usr/local/src/burn/vdr-plugin-burn-0.1.0~pre21'
make: *** [build-stamp] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
root@ubi:/usr/local/src/burn/vdr-plugin-burn-0.1.0~pre21# sed -i s/99/\#99/ debian/patches/00list;dpatch-edit-patch -a 99_ten;sed -i s/\#99/99/ debian/patches/00list;dpkg-buildpackage -tc
dpatch-edit-patch: * /usr/local/src/burn/vdr-plugin-burn-0.1.0~pre21/debian/patches/99_ten.dpatch exists, this patch will be updated.
dpatch-edit-patch: Error: Patch 99_ten.dpatch is applied on working directory, use --clean option
dpkg-buildpackage: set CPPFLAGS to default value:

Alles anzeigen

dpatch-edit-patch -c -a 99_ten kann die Patches auch nicht wieder abräumen, daher muß der o.g. Aufruf wohl weiter verändert werden:

Zitat

sed -i s/99/\#99/ debian/patches/00list;dpatch-edit-patch -a 99_ten;sed -i s/\#99/99/ debian/patches/00list;dpkg-buildpackage;dpatch deapply-all

Nein, den fakeroot von dpatch-edit-patch verlasse ich natürlich zum Kompilieren - ohne ein exit würde es in der nachstehenden 2. Zeile ja gar nicht weitergehen. Das Ende ist neu gefasst, weil dpkg-buildpackage -tc im Gegensatz zu dpatch deapply-all (das wiederum auf debian/rules clean unpatch zurückgreift) nicht zuverlässig funktionierte.

Zitat

apt-get source vdr-plugin-burn;wget http://launchpadlibrarian.net/23999811/99_ten.tar.gz;cd vdr-plugin-burn-0.1.0~pre21;tar xzvf ../99_ten.tar.gz
sed -i s/99/\#99/ debian/patches/00list;dpatch-edit-patch -a 99_ten;sed -i s/\#99/99/ debian/patches/00list;dpkg-buildpackage;dpatch deapply-all
dpkg -i ../vdr-plugin-burn_0.1.0~pre21-20ubuntu3_i386.deb;/etc/init.d/vdr stop;/etc/init.d/vdr start

Es scheint so, daß man die ersten Aufrufe von z.B. dpatch-edit-patch -a 99_ten zunächst ohne Änderungen mit exit 230 und exit verlassen sollte - ein Grund dafür ist nicht wirklich erkennbar, aber danach scheint der Ein- und Ausbau der eigentlichen Änderungen zuverlässiger zu funktionieren.

Jedenfalls erscheint das ganze Verfahren hinreichend kopfschmerzgefährlich und alles andere als mit dem Blick in die man-page verständlich oder gar intuitiv bedienbar, denn darauf, sich obige Zeilen zusammenzubauen und die verschiedenen anderen Varianten auszuschließen, muß man ja auch erst einmal kommen...

Zitat

Originally posted by gda

Ich habe meine Patches immer in der 00list stehen, aber dafür benutze ich auch nicht die option -a sondern:

Code

dpatch-edit-patch patch 99_ten

Ich habe die beschriebenen Probleme noch nicht gehabt.

Der Unterschied zumindest bei dem fraglichen Ubuntu-Paket könnte darin liegen, daß es schon distributionsseitig nicht weniger als 7 Patches gegenüber Upstream enthält (und trotzdem lange nicht benutzbar war).

Leider war nun schon einige Zeit darauf zu verwenden, herauszubekommen (und hier für weitere :suchede zu dokumentieren), wie so ein Plugin unter Ubuntu überhaupt mit mehrfach ergänzbaren eigenen Patches kompiliert werden kann - so daß ich die wahrscheinlich in draw_image von gdwrapper.c liegende Ursache für die letzten beiden Bugs (überschießende Textlängen in Überschrift und Beschreibung) noch gar nicht finden konnte:
[Blockierte Grafik: http://vdr-portal.de/board/attachment.php?attachmentid=21579]
Um diese Fehler zu provozieren, hänge ich eine info.vdr an, die mit gunzip in ein Verzeichnis mit langem Namen auszupacken ist, z.B.

Desperate_Housewives_-_Season_5_-_Episode_3extralang/2009-01-28.20.12.50.99.rec

Natürlich darf das auch eine Kopie weniger WAF-kompatibler Aufnahmen enthalten - es geht nur um den Teil der Menüerstellung, den ich noch nicht korrigieren konnte.

nedit statt gedit scheint dpatch-edit-patch zu verkraften (aber kann mir jemand erklären, warum das überhaupt einen Unterschied macht?).

Zum Bug im burn-Plugin weiter unter http://vdr-portal.de/board/thread.php?threadid=85412, damit das hier nicht off-topic wird...

Zitat

Originally posted by gda

Totale Verblüffung! Wie bitte?

Dachte auch das gibt's doch garnicht. Habe noch gesucht, ob dpatch-edit-patch vielleicht über irgendeine von diesem Editor abgelegte Backup-Kopie o.ä. stolpert, aber es bleibt unerklärlich. Demnächst bei Aiman Abdallah oder Ranga Yogeshwar...

Zitat

Na ja, was soll's ich benutze sowieso nur vi.

Das hat mir der Igel im IRC auch schon gesagt.
Aber dafür bin ich nicht Guru genug, wenn's anders geht (vor allem weil ich bei vielem in C++ auch erst mal durchsteigen muß), also nicht gerade im Textmodus über schmalbandige Leitung o.ä., heißt's im Alltag dann für diesen Editor doch eher Esc !q:

BTW, fällt Dir eine einfache Abhilfe für den burn-Bug ein, der mich überhaupt erst in diese Untiefen gelockt hat?

Zitat

Originally posted by wilderigel
backup kopie kannst im patch rauslesen.

Eben, alles Mögliche hätte man sowohl dort sehen sollen als auch bei ls -artl nach Verlassen von gedit.
Habe aber nichts gefunden, außer hinterher einem abschmierenden "unpatch".

Habe mir leider schon ein paar Hirnwindungen daran verknotet, die jetzt nicht mehr für das eigentlich Problem in der gdwrapper.c fit sind...:whatever

Dazu eine Idee? Würde versuchen, jeweils das Ergebnis des vorherigen Schleifendurchlaufs in eine zusätzliche Variable zwischenzuspeichern und darauf zurückzufallen, wenn beim nächsten Durchlauf lineWidth>width (über)läuft.