Offizielles Paket ändern und paketieren

[marting]

Hallo zusammen,

ich habe einige eigene Pakete (primär Perl Applications) mittels dh_make/debconf aus dem Boden gestampft und gebaut. Ich gehe wahrscheinlich nicht immer zu 100% den offiziellen Weg, aber ich bin mittlerweile einigermaßen drin und die Paketierung inklusive eigenem Repository funktioniert recht gut.

Nun möchte ich aber zum ersten Mal ein offizielles Debian Paket hernehmen, ändern, neu bauen und in mein Repo bringen. Konkret geht es um das Paket ppp: http://packages.debian.org/wheezy/ppp (aktuell 2.4.5-5.1)
rp-pppoe ist in diesem Paket in Version 3.8 enthalten, aktuell wäre 3.11 und ich brauche zwingend 3.9 (auf mehreren Maschinen, auf denen ich nicht von Hand bauen möchte)

Ob ich es schaffe, den Austausch komplett durchzuführen, steht noch auf einem anderen Blatt. Aber ich wäre schonmal zufrieden, wenn ich das Source Paket runterladen, eine Stelle an der Versionsnummer ändern, und das Paket neu bauen könnte. Das kann doch eigentlich nicht so schwer sein.
Trotz oberflächlicher Lektüre des New Maintainer Guide und einiger anderer Seiten fehlt mir jedoch noch etwas der Ansatzpunkt für mein Vorhaben. Ich habe das orig.tar.gz und ich habe das diff.gz. Komme ich irgendwie an die build Umgebung? Oder ist das ein Geheimnis des Maintainers? Würde ich das diff korrekt auf das orig anwenden (was ist der Standardweg?), dann hätte ich die korrekte Verzeichnisstruktur zum bauen. Wie geht es dann weiter?

Könnte mir hier bitte noch jemand einen Wink geben?

[marting]

War doch gar nicht so schwer, wenn man einen Ansatz hat: http://ftp.debian.org/debian/doc/source-unpack.txt

Code: Alles auswählen

wget http://ftp.de.debian.org/debian/pool/main/p/ppp/ppp_2.4.5.orig.tar.gz
wget http://ftp.de.debian.org/debian/pool/main/p/ppp/ppp_2.4.5-5.1.diff.gz
wget http://ftp.de.debian.org/debian/pool/main/p/ppp/ppp_2.4.5-5.1.dsc
dpkg-source -x ppp_2.4.5-5.1.dsc

Scheinbar wird an diesem Paket aber nicht mehr viel gemacht, selbst das Original ist zuletzt 2009 aktualisiert worden
http://ppp.samba.org/
Es führt also wohl kein Weg daran, selbst Hand anzulegen...

Ich werde nun mal testen, ob mein bisheriges Build Script out-of-the-box mit ppp funktioniert.

[catdog2]

Würde ich das diff korrekt auf das orig anwenden (was ist der Standardweg?), dann hätte ich die korrekte Verzeichnisstruktur zum bauen.

Für Pakete für die du ein deb-src in der sources.list hast ist natürlich am einfachsten:

Code: Alles auswählen

apt-get source ppp

Das macht eigentlich soweit alles für dich.

Ansonsten brauchst du am besten erst mal 3 Dateien, das orig, den patch, und das dsc file. Du musst die auch nicht manuell laden sondern einfach die URL zum dsc an dget (Paket: devscripts) übergeben. Hast du jetzt die 3 Dateien kannst du die mit

Code: Alles auswählen

dpkg-source -x <filename>.dsc

entpacken.

Wie geht es dann weiter?

Naja dann machst du deine Änderungen, baust dir einen neuen Changelog Eintrag (mit dch oder manuell) und baust das Paket mit dpkg-buildpackage und hoffst, dass es tut.

Ansonsten würde ich mal schauen ob das Paket in testing/unstable schon die neuere Version enthält und versuchen es zu Backporten.

[marting]

Hi,

danke für Deine Antwort!

Dein Hinweis auf dget erleichtert das Leben auf jeden Fall schonmal. Es werden die drei Dateien heruntergeladen und auch das dpkg-source -x wird automatisch ausgeführt. Ich musste noch quilt, sowie zwei Header Pakete installieren und nun ist mein Build (mittels debian/rules) durchgelaufen und im Repository verfügbar.
Nun stelle ich gerade fest, dass ppp architekturabhängig ist - mein Build Host ein 32bit System und mein Anwendungshost ein 64bit System ist
gcc kann mit -m64 Flag zwar auch für 64bit Systeme kompilieren, aber ich habe noch nicht gefunden, wo ich das im build Prozess angeben kann
Ich mache mich mal weiter auf die Suche.

Viele Grüße
Martin

[marting]

dpkg-buildpackage -aamd64
könnte zwar amd64 Pakete erstellen - ich bräuchte dafür aber auch die amd64 header Pakte libpcap0.8-dev libpam0g-dev zlib1g-dev und die haben Abhängigkeiten jenseits von gut und böse ...

Code: Alles auswählen

aptitude -o APT::Architecture="amd64" update
aptitude -o APT::Architecture="amd64" -o APT::Install-Recommends="false" install zlib1g-dev libpcap0.8-dev libpam0g-dev

-> entweder rund 120 Pake weg oder 190 neue Pakete (darunter Standard Programme wie Perl, make, passwd, sshserver usw.)

Sieht ein wenig nach Sackgasse aus...

[ThorstenS]

Der kürzeste Weg Pakete „mal eben“ neu zu bauen ist meines Erachtens dieser:

Code: Alles auswählen

apt-get install devscripts build-essentials
apt-get build-dep ppp
dget -x -u http://ftp.de.debian.org/debian/pool/main/p/ppp/ppp_2.4.5-5.1.dsc
cd ppp*
# wusel wusel wusel
./debian/rules binary
ls ../*deb

Wenn du für eine andere Architektur bauen willst, nimm pbuilder. Anbei einige interessante links:

http://www.wgdd.de/2013/08/setting-up-n ... ilder.html
https://wiki.debian.org/PbuilderTricks
http://lists.debian.org/debian-mentors/ ... 00672.html
http://michael-prokop.at/blog/2011/07/1 ... ironments/

[marting]

Einen Schritt bin ich nun doch weiter gekommen.

Gemäß https://wiki.debian.org/Multiarch/HOWTO habe ich amd64 aktiviert und die build-dependencies auf amd64 Plattform installiert:
dpkg --add-architecture amd64
aptitude update (vorher deb-src in sources.list eintragen, falls nicht vorhanden)
apt-get build-dep -a amd64 ppp

Mit "CC="gcc -m64 dpkg-buildpackage -a amd64" bin ich dann auch recht weit gekommen, habe dann aber immer das Problem, dass x86_64-linux-gnu-strip aufgerufen wird. Diese Executable habe ich nicht und finde sie auch über die Paketsuche nicht. Ich schätze, dass das ein Wrapper für strip ist, den es bei Debian nicht gibt.

Dann habe ich das nützliche Programm x86_64 entdeckt, welches die Ausgabe von uname manipuliert und somit eine 64bit Umgebung vorgibt. Somit kann ich auch mein eigenes Build Script aufrufen, was gekürzt so aussieht:

Code: Alles auswählen

debian/rules clean
CC="gcc -m64" dpkg-source -b .
CC="gcc -m64" debian/rules build
CC="gcc -m64" fakeroot debian/rules binary

Das läuft auc durch, nur leider purzeln trotz meiner beiden 64-bit Schalter (x86_64 und gcc -m64) am Ende wieder nur 32bit Pakete raus.
Wo kann ich noch etwas tweaken?

==============================================

Danke für Deine Info, Thorsten. Für die gleiche Architektur schaffe ich es mittlerweile - Probleme bereitet mir noch die Fremdarchitektur. Ich werde Deinen Tip mit PBuilder mal verfolgen, danke!

Nachtrag: Ich habe mir PBuilder angesehen und es scheint eine gute Lösung zu sein. Für größere zukünftige Projekte behalte ich das auch im Hinterkopf. Ich stimme zu, dass es die sauberere Lösung ist. Allerdings würde ich auf den Initialaufwand gerne verzichten, wenn bei meinem Problemchen nur noch ein oder zwei Flags irgendwo fehlen.

Nachtrag 2: Wenn ich meine CC Options wie hier beschrieben: http://ubuntuforums.org/showthread.php? ... st12599759 auf folgendes erweitere, hilft das auch nichts: CC="gcc -m64 -Wl,-melf_x86_64". Der Linker findet seine Bibliotheken ja mittlerweile auch. Die Frage ist nur noch, wer anhand welches Kriteriums entscheidet, ob ein 32bit oder ein 64bit Paket gebaut wird.

Nachtrag 3: Versuchsweise habe ich das strip Problem mal durch einen Alias bzw. einen Symnlink auf Strip umgangen.
So werden zumindest mal amd64 Pakete erzeugt - ob die dann auch klappen? Keine Ahnung
Was macht dpkg-buildpackage anders als mein Skript? Ich habe mir mal den Quelltext dazu angesehen - der Parameter -a wird einfach an dpkg-architecture über geben. Was das genau tut, weiß ich noch nicht. Scheinbar wird dort nur Output generiert, der wiederum als Umgebungsvariable zur Skriptausführung genutzt wird. So ganz bin ich aber noch nicht dahinter gestiegen.
Genauso wenig woher der ominöse Strip Aufruf kommt.