staging.inyokaproject.org

Moin Liebe Ubuntu-Gemeinschaft,

ich möchte gern für meinen Schrankrechner Python3.2 als Pakete schnürren. Hierzu habe ich mir das Quellpaket aus dem Repository von Debian Wheezy gezogen und in der "control"-Datei die Build-Abhängigkeiten soweit angepasst. Anschließend eine neue *.dsc Datei erzeugen lassen und den Bau mittels pbuilder losgetreten. Soweit so gut. Nur das Schnürren der Pakete klappt nicht so ganz wie ich das gerne haben würde wollen. Genau genommen endet der Bauvorgang mit folgender Fehlermeldung:

patching file Doc/documenting/markup.rst
Hunk #1 FAILED at 177.
Hunk #2 FAILED at 225.
2 out of 2 hunks FAILED -- rejects in file Doc/documenting/markup.rst
Patch revert-r83234.diff does not apply (enforce with -f)
make: *** [stamps/stamp-patch] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Soweit ich das verstehe, kann der oben genannte Patch nicht angewendet werden. Ehrlich gesagt stehe ich aber nun etwas auf dem Schlauch wie ich am besten weiter vorgehen sollte. Würde mich deshalb über die eine oder andere Anregung sehr freuen.

Schöne Grüße
Endi

Hi Endi,

hast du evtl. das Paket normal gebaut und dann anschließend mit pbuilder? Wende die Patches im Rohzustand an, aktualisiere sie und deaktiviere sie wieder:

quilt push -a
quilt refresh
quilt pop -a 

Gruss Lasall

Hallo Lasall,

erst einmal vielen Dank für deine schnelle Antwort. Also was heißt bei dir "normal"? Ich habe folgendes getan: Source-Paket (*.dsc, *.diff.gz, *.orig.tar.gz) aus dem Debian-Repository manuell heruntergeladen. Mittels des *.diffs das Debian-Verzeichnis erstellt und in der control.in die Build-Abhängigkeiten angepasst. Noch kurz einen Changelog-Eintrag vorgenommen und abschließend das Quellpaket mittels debuild -S -uc -us erstellen lassen. Und dann einfach den Bauvorgang mit pbuilder angeworfen. Leider bin ich mit Quilt und Patches noch nicht ganz so warm, sprich eigentlich Null-Wissen über den Umgang mit diesen (Antwort: No patches in series). Wird wohl doch komplizierter als ich dachte. Aber mal schauen, dass muss doch gehen.

Schöne Grüße
Endi

Nachtrag:
Ich weiß jetzt nicht ob ich an der richtigen Stelle schaue, aber wenn ich mir hier (http://patch-tracker.debian.org/package/python3.2/3.2.3-7) die Wirkung des genannten Patches betrachte und im Quellpaket nachschaue gibt es das Verzeichnis "Doc/documentation/" gar nicht.

Hi Endi,

ok, ich habe manuell ein "debian/rules patch" laufen lassen, damit ich mit quilt arbeiten kann (erst damit wird die series-Datei bei diesem Paket angelegt). Die debian/rules ist hier auch ziemlich komplex, wenn der Tipp mit quilt nicht funktioniert, schaue ich nochmal genauer nach. Generell sind solche Hunk-failed-Probleme aber auf (bereits) geänderte Dateien zurückzuführen.

Kleiner Tipp, der nicht zur Problemlösung beiträgt: Hole dir Debianquellpakete mit dget, also: dget -xu URI://foobar.dsc (das entpackt dann schon automatisch)

Gruss Lasall

Moin Lasall,

also ich habe es eben mal mit quilt probiert, aber ohne jeglichen Erfolg. Falls dir noch was einfällt wäre ich dir dankbar, falls nicht auch nicht schlimm. Leider kann ich über die kommenden Feiertage dem Problem auch erst einmal nicht weiter auf die Spur gehen. Werde mich aber wohl Montag Abend der Thematik wieder widmen. Ich wünsche dir (und allen anderen auch) ein paar schöne Osterfeiertage.

Schöne Grüße
Endi

Hi Endi,

danke gleichfalls ☺ . Ab morgen bin ich auch erstmal für einige Tage weg, hier aber die Schritte, wie das Kompilieren in einer sauberen (pbuilder-)Lucid-Umgebung funktioniert:

apt-get install devscripts wget equivs   # root-Rechte nötig (mit APT::Install-Recommends == true weniger Pakete)
dget -xu http://ftp.de.debian.org/debian/pool/main/p/python3.2/python3.2_3.2.3-7.dsc
cd python3.2-3.2.3/
mk-build-deps -i -r  # root-Rechte nötig, Build-Abhängigkeiten müssen nicht angepasst werden
dch -l+local Local build.  # Version mit "+localN" erweitern und Changelog-Eintrag "Local build." setzen
debian/rules patch  # gibt Fehler
quilt push -f
quilt refresh
quilt push -a  # gibt Fehler
quilt delete revert-r83274.diff  # Patch muss nochmal manuell nachgebessert werden
quilt new revert-r83274.diff
quilt add Doc/conf.py
sed -i '/^html_theme_options/d' Doc/conf.py
quilt refresh
sed -ie "127,+2s/^/#/" debian/rules  # lto-Flags deaktivieren (zu neu für Compiler)
debuild -us -uc  # analog erst das Quellpaket erstellen, dann mit pbuilder/sbuild bauen 

Zumindest ein Hello-World in der Python-Konsole funktioniert dann bei mir:

root@debsid0:/build/python3.2-3.2.3# python3.2
Python 3.2.3 (default, Mar 28 2013, 14:18:34) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.linux_distribution()
('Ubuntu', '10.04', 'lucid')
>>>

Gruss Lasall

Hallo Lasall,

vielen Dank für deine Unterstützung. 👍 Mittels pbuilder konnte ich soweit alles kompilieren, allerdings musste ich doch manuell die Build-Dependencies ändern. Was mich jetzt allerdings doch interessiert (und vielleicht kannst du mir eine kurze Lehrminute geben), weshalb ein Patch manuell nach gebessert werden musste? Ich dachte ein Quellpaket in seinem Grundzustand (für das gleiche Release mal vorausgesetzt) sollte man ohne Probleme nachbauen können? Oder ist das doch ein Bug im Quellpaket selbst? Da deine Signatur im Moment hergibt dass du dich im Urlaub befindest, wünsche ich dir aber erst einmal maximale Erholung und Entspannung.

Schöne Grüße
Endi

Hi Endi,

du schriebst:

[...] Mittels pbuilder konnte ich soweit alles kompilieren, allerdings musste ich doch manuell die Build-Dependencies ändern.

Klasse, dass es funktioniert hat! Aus Interesse: Welche Abhängigkeiten musstest du anpassen und wie?

[...W]eshalb [...musste...] ein Patch manuell nach gebessert werden[...]? Ich dachte ein Quellpaket in seinem Grundzustand (für das gleiche Release mal vorausgesetzt) sollte man ohne Probleme nachbauen können? Oder ist das doch ein Bug im Quellpaket selbst?

Ein Bug im Quellpaket an sich kann es nicht geben, da exakt aus diesem Paket das/die Binärpaket/e auf den Buildservern der Distribution in einer sauberen (sbuild-)Umgebung gebaut wird/werden. Die Logs kann man für Debian z.B. hier einsehen: buildd log (sid) 🇬🇧 buildd log der Ports (sid) 🇬🇧 Wenn man mit dem Quellpaket allerdings erst garnicht erfolgreich bauen kann, spricht man von FTBFS (failed to build from source) (und das ist natürlich ein Bug im Quellpaket). Es hätte also ohne Anpassungen funktioniert, wenn du das Quellpaket in einem Debian-Testing-System kompilierst. Ubuntu 10.04 baut auf dem Zwischenstadium Debian Lenny (ehemals oldstable) und Debian Squeeze (noch stable, in ein paar Wochen oldstable) auf. Debian Wheezy (mit "Feature Freeze" seit einem knappen Jahr) ist also um einiges aktueller als Ubuntu Lucid Lynx und deswegen sind die Probleme nicht überraschend. An welcher Version von welchem Paket es allerdings genau liegt, kann ich nicht sagen, es muss allerdings etwas zwischen quilt und patch sein.

Da deine Signatur im Moment hergibt dass du dich im Urlaub befindest, wünsche ich dir aber erst einmal maximale Erholung und Entspannung.

Danke schön ☺ !

Gruss Lasall

Hallo Lasall!

Lasall schrieb:

Welche Abhängigkeiten musstest du anpassen und wie?

Konkret musste ich folgende Änderungen in der control.in vornehmen:

libbluetooth-dev [linux-any] –> libbluetooth-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64]
libgpm2 [linux-any] –> libgpm2 [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64]

Mir ist zwar nicht ganz klar was die Änderung letztlich bedeutet, hatte mich zur Lösung eben bei der in Lucid steckenden Version 3.1 von Python orientiert. Vermute es handelt sind Ausnahmen in der Architekturen, die vermutlich in debian/rules irgendwas beim Bauvorgang ausschließen bzw. von der zu bauenden Architektur spezifisch machen?

Schöne Grüße
Endi

Hi Endanwender,

welche Architektur hast du eigentlich? Die Architekturen in eckigen Klammern geben an, für welche Architekturen diese Build-Abhängigkeit benötigt wird (oder entsprechend nicht mit dem Ausrufezeichen). Das macht deswegen Sinn, da nicht alle Pakete auf allen Architekturen verfügbar sind, aber manche Build-Abhängigkeiten prinzipiell optional sind (beispielsweise um Dokumentation zu erstellen) und deswegen wenn es sein muss auch (auf Kosten von weniger Features) weggelassen werden können.

Gruss Lasall

Lasall schrieb:

welche Architektur hast du eigentlich?

Ich habe mal sowohl für i386, als auch amd64 gebaut. Beides klappte problemlos.

Die Architekturen in eckigen Klammern geben an, für welche Architekturen diese Build-Abhängigkeit benötigt wird (oder entsprechend nicht mit dem Ausrufezeichen).

Okay, dann verstehe ich jetzt aber nicht weshalb es bei mir nur mit den oben genannten Modifikationen geklappt?? ❓

Schöne Grüße und eine gute Nachtruhe gewünscht! ☺
Endi

Hi Endi,

ich verstehe das auch nicht...

Gruß und ebenfalls gute Nacht!
Lasall