Pakete aus einer anderen Architektur installieren

[The Hit-Man]

Ich kann ja ohne weiteres ein Paket unter einer anderen Architektur unter Debian installieren:

Code: Alles auswählen

apt install paket:armhf

Wie kann ich denn mehrere Pakete installieren? Muß ich bei jedem Paket das :armhf mit geben? Oder gibts da vielleicht eine Art Option. Wollte mal bischen cross-compilen. Klar, kann mir auch alles unter deboostrap holen. Oder wäre es eh nicht sinnvoller debootstrap zu nehmen?

[DeletedUserReAsG]

Zum Crosscompilen benötigt man keine Binärpakete für die Zielarchitektur. Würden auch auf dem Host gar nicht funktionieren – weil eben andere Architektur. Die Libs dürften auch nicht so zahlreich sein, dass die paar Tastendrücke problematisch sind, oder?

Hingegen ist debootstrap ein Werkzeug zur Installation eines Debiansystems, nicht für die Installation von Paketen – ist eine ganz andere Baustelle.

Überblick, wie man zu so Toolchains kommt, gibt es unter https://wiki.debian.org/CrossToolchains

[JTH]

Ich benutz meist gerne mk-build-deps aus devscripts, um Build-Depedencies zu installieren. Damit wird man sie im Nachhinein leichter los – wenn man nicht eh gleich pbuilder oder sbuild benutzt.

mk-build-deps kann anscheinend auch ein Metapaket für Cross-Build erzeugen (und mit -i direkt installieren):

Code: Alles auswählen

~# mk-build-deps -ir --host-arch=armhf PAKET

[The Hit-Man]

Naja, wenn man pbuilder oder sbuild nutzt, wird ja über den qemu gebaut ( so weit ich das gelesen hatte ). Genau das wollte ich vermeiden denn das dauert zu mindest bei mir dann übelst lange. Oder vertue ich mich da gerade etwas. Hatte mir aus dem git mal Kodi 20 für bullseye ( raspberry ) gebaut. Mit den besagen Tools dauert das echt sehr lange. Als ich dann, naja, wie schreibt man das, nativ cross kompiliert hatte, dauerte das nur 20 Minuten lang. War zwar bischen doof, das ich daraus kein .deb bauen konnte aber es lief auch so.
Bis jetzt habe ich es immer so gemacht. Per debootstrap mir das bullseye für den Raspberry geholt, per chroot dann alle Abhängigkeiten von Kodi geholt. Dann wieder raus gegangen und Kodi gebaut. Per --sysroot kann man ja schön dann sagen, hey, schau bitte in der chroot-Umgebung nach deinen libs. So in der Art würde ich es gerne machen, ohne qemu.
Hab auch mal versucht einfach aus den Debian Sourcen, Kodi zu bauen. Die kann man ja per apt-get source package holen und dann mit den devscripts bauen. Das hat aber nie geklappt, immer irgendwelche Fehler. Da Kodi ja cmake verwendet kann man sich per cmake ja ein .deb bauen lassen, ist aber auch nicht soooooooo das gelbe vom Ei. Achso, Kodi war jetzt nur ein Beispiel.

Also ich suche einfach einen Weg, schnell und vor allem recht einfach ein Paket für den Raspberry zu bauen auf eben einer großen amd64 Maschine und das nicht über eine qemu Emulation.

[JTH]

Naja, wenn man pbuilder oder sbuild nutzt, wird ja über den qemu gebaut ( so weit ich das gelesen hatte ).

Ne, das stimmt nicht. Beide benutzen chroots als saubere, vom Hostsystem getrennte Buildumgebungen. Und für einen Cross-Build wiederum benutzen sie bei Bedarf die Toolchains, die niemand oben schon verlinkt hat: siehe für sbuild und für pbuilder.

qemu kann da, meine ich, nur involviert sein, wenn man autopkgtests mit ausführen lässt. Das autopkgtest-Paket hängt von qemu* ab, da es zum Installieren und Ausführen der gebauten Pakete eine Umgebung mit der passenden Architektur braucht.

Genau das wollte ich vermeiden denn das dauert zu mindest bei mir dann übelst lange. Oder vertue ich mich da gerade etwas.

Normalerweise installieren pbuilder und sbuild die Buildabhängigkeiten bei jedem Bauen neu. Das ist ja eins ihrer Ziele, eine saubere Buildumgebung anzubieten. Durch das Neuinstallieren dauert das Bauen natürlich länger. Man kann die ständige Neuinstallation, meine ich, auch vermeiden, verliert dann aber einen Vorteil (den man lokal, bei wiederholtem Bauen natürlich nicht immer haben möchte/braucht).

Also ich suche einfach einen Weg, schnell und vor allem recht einfach ein Paket für den Raspberry zu bauen auf eben einer großen amd64 Maschine und das nicht über eine qemu Emulation.

Dann probier doch mal, dir wie oben beschrieben mit mk-build-deps die Abhängigkeiten zu installieren. Im Debian-Wiki findest du noch den notwendigen, hoffentlich direkt funktionierenden Aufruf von dpkg-buildpackage: Cross Compiling#Building with dpkg-buildpackage, letzte Zeile. Die apt-get install- und apt-get build-dep-Schritte brauchst du mit mk-build-deps nicht. Aber Vorsicht, falls dabei wegen Architekturkonflikt irgendwas deinstalliert werden möchte …

Davor sind auch die alternativen Aufrufe mit pbuilder und sbuild aufgelistet. Die sind kürzer, man muss die beiden Werkzeuge aber vorher aufsetzen.

[The Hit-Man]

Alles klar. Dann schaue ich mir die Tools noch mal genauer an. Als ich da chroot gelesen hatte, hatte ich aufgehört zu lesen, da ich gleich an qemu dachte.

Danke für die Tips ...

[The Hit-Man]

so, ich habe mal alles nach dieser Anleitung gemacht.

https://wiki.debian.org/sbuild

Aber, wie ich schon sagte, geht doch alles über den qemu. In der Taskliste wenn ich etwas aus den Sourcen baue, taucht dieser Task auf:
qemu-binfmt

Genau eben das wollte ich ja nicht haben. Hatte wohl dann doch richtig gelesen, das der qemu benutzt wird und ja, wie gesagt, das dauert ja eben sehr sehr lange...

[JTH]

Als ich da chroot gelesen hatte, hatte ich aufgehört zu lesen, da ich gleich an qemu dachte.

Wenn du zum Bauen etwa ein chroot mit einer anderen Architektur benutzt, wird da Qemu im Hintergrund notwendig sein. Aber das wäre auch kein Cross-Kompilieren, sondern eben einfach ein Bauen unter der Zielarchitektur.

Es gibt, alleine durch die Paketabhängigkeiten, keinen Anhalt dafür, dass sbuild irgendwie erzwingen würde, mit Hilfe von Qemu zu bauen.

Ich hab grad aus Interesse mal in einer frischen VM ausprobiert:

1. sbuild + debootstrap + schroot ohne Recommends installiert.
2. chroot anlegen:

   Code: Alles auswählen

   root@vm:~# sbuild-createchroot --command-prefix=eatmydata --include=eatmydata --alias=sid unstable /srv/chroot/unstable-amd64-sbuild http://deb.debian.org/debian
   root@vm:~# sbuild-adduser thehitman
   

   Das chroot wird mit der Architektur des laufenden Systems angelegt, keine Angabe von armhf!
3. Und dann direkt bauen:

   Code: Alles auswählen

   thehitman@vm:~$ sbuild -d unstable --host=armhf --no-run-autopkgtest --no-run-lintian dash
   

   Fertig, dash_0.5.12-2_armhf.deb liegt bereit zum Installieren. Kein Qemu involviert, kein relevantes Qemu-Paket installiert (nur ein irrelevantes, da in einer VM ausgeführt). Weitere Optionen oder Konfiguration(sdateien) von sbuild, um z.B. alle Prozessoren zu benutzen, brauchts, meine ich, auch nicht (mehr).

Die Benennung der Optionen, die eine Architektur als Argument nehmen – --arch, --host, --build – find ich immer etwas verwirrend. --host gibt die Architektur an, für die du bauen willst. Hier also armhf.

so, ich habe mal alles nach dieser Anleitung gemacht.

https://wiki.debian.org/sbuild

Was genau hast du denn gestern ausprobiert? In der verlinkten Anleitung sind ja doch verschiedene Schritte und Vorgehensweisen beschrieben.

Ob sbuild für deine Aufgabenstellung hier das „beste“ Werkzeug ist, ist eine andere Frage. Das chroot und co. muss/möchte man ja im Nachhinein wahrscheinlich wieder entfernen. Das Entfernen ginge bei per mk-build-deps installierten Abhängigkeiten etwas gewohnter über apt, das Bauen wie oben verlinkt mit dpkg-buildpackage.

[The Hit-Man]

@JHT:
Ah. Ich hatte die chroot Umgebung für den armhf gebaut. Dann ist klar, das der qemu startet. Ich werde mal Deinen Weg probieren.

[The Hit-Man]

@JHT:
Vielen Dank ! Hat so geklappt, wie Du geschrieben hattest. Noch mal Danke für die ganze Mühe. Den Beitrag werde ich mir ausdrucken. Ist ja wie ein richtiger Wiki Eintrag. Da finde ich Deinen aber echt besser erklärt als den Link den ich geschickt hatte.
Eine Sache vielleicht noch. Kann man die Abhängigkeiten eigentlich dauerhaft speichern? Um Kodi zu bauen werde ich wohl ein wenig Hand anlegen müssen und dann ist es nicht ganz so doll wenn die Abhängigkeiten jedes Mal neu nachgeladen werden müssen. Das normale Standart-Kodi bekomme ich leider nicht gebaut. Da muß ich dann, wie gesagt wohl selbst mal rein schauen und die rules Datei ein wenig ändern.

[The Hit-Man]

Kann ich eigentlich selbst gebaute Pakete in die chroot Umgebung mit einfügen? Und vielleicht irgendwie die Abhängigkeiten die für ein zu bauendes Paket behalten? So das diese nicht immer neu installiert werden müssen?
Mein Versuch ist gerade aus Debian Testing, das Kodi Paket für Debian Stable zu bauen. Oder ist so etwas erst gar nicht möglich?

[JTH]

@JHT:

Wer ist denn eigentlich dieser JHT?

Mein Versuch ist gerade aus Debian Testing, das Kodi Paket für Debian Stable zu bauen. Oder ist so etwas erst gar nicht möglich?

Das kommt drauf an. Wenn die Kodi-Version aus Testing von Bibliotheken abhängt, die es generell oder in notwendiger neuerer Version noch nicht in Stable gibt, wird das erstmal scheitern. Dann müsstest du z.B. die Abhängigkeiten aus Testing installieren, hast dann aber eine Mischinstallation.

Wenn Kodis Abhängigkeiten in Stable und Testing die noch gleichen oder zumindest kompatibel zueinander sind, sollte dein Vorhaben klappen.

Was ist denn eigentlich dein Ziel? Willst du „nur“ die Kodi-Version 20 aus Testing/Bookworm für Stable/Bullseye paketieren? Oder daran zusätzlich was modifizieren?

Kann ich eigentlich selbst gebaute Pakete in die chroot Umgebung mit einfügen? Und vielleicht irgendwie die Abhängigkeiten die für ein zu bauendes Paket behalten? So das diese nicht immer neu installiert werden müssen?

Ein Ratschlag hängt da auch ein bisschen von deinem Ziel ab:

Willst du was am Code verändern und kompilierst deshalb regelmäßig neu? Dann spar dir dabei erstmal das Paketieren und bau vorerst per make (oder was Kodi benutzt) nur so neu. Geht am schnellsten.

Willst du Kodi in der neueren Version oder mit Modifikationen an der Paketierung paketieren? Dann bau das Paket zu Testzwecken erstmal lokal nativ (für amd64), ohne Crosscompiling, nur mit nacktem dpkg-buildpackage, ohne sbuild. Die dabei notwendigen Abhängigkeiten bekommst du z.B. mit mk-build-deps ohne --host-arch, wie weiter oben vorgeschlagen. Falls sich Kodis Abhängigkeiten zwischen Bullseye und Bookworm relevant unterscheiden, musst du allerdings wohl doch auf den nächsten Weg und ein Testing-chroot zurückgreifen – falls das überhaupt sinnvoll lösbar ist.

Willst du Kodi in der neueren Version oder mit Modifikationen, die nur armhf betreffen, paketieren? Dann benutz tatsächlich sbuild. Damit die Abhängigkeiten nicht immer neu installiert werden (auch wenn man das mit sbuild eigentlich oft will), kannst du dich z.B. per

Code: Alles auswählen

~# sbuild-shell CHROOTNAME

im chroot anmelden und dort – wenn du Glück hast – per

Code: Alles auswählen

apt build-dep --host-architecture=armhf kodi
# das sollte auch gehen, in einem Schritt ohne sbuild-shell:
sbuild-apt CHROOTNAME apt-get build-dep --host-architecture=armhf kodi

die Build-Abhängigkeiten vorinstallieren. Das könnte allerdings auch schiefgehen, denn sbuild benutzt eigentlich noch etwas mehr „Magie“ um die Cross-Build-Abhängigkeiten erfolgreich zu installieren. Wenn es schiefgeht, könntest du für das wiederholte Neupaketieren hier auch erstmal für amd64 statt armhf bauen.

[The Hit-Man]

Wer ist denn eigentlich dieser JHT?

Ups, ja Du

Das kommt drauf an. Wenn die Kodi-Version aus Testing von Bibliotheken abhängt, die es generell oder in notwendiger neuerer Version noch nicht in Stable gibt, wird das erstmal scheitern. Dann müsstest du z.B. die Abhängigkeiten aus Testing installieren, hast dann aber eine Mischinstallation.

So, wie es aussieht passen die Abhängigkeiten aber auch nur dann wenn ich die git Version nehme, direkt aus dem Git von Kodi. Da kann ich es unter bullseye bauen wenn ich die normalen Abhängigkeiten von Kodi aus bullseye installiere.

Code: Alles auswählen

apt-get build-dep kodi

Kodi benutzt cmake und ich kann sogar mit angeben ob ein .deb Paket gebaut werden soll. Das ist aber nicht wirklich das ware vom Ei.
Die Version die man aus den Sourcen von bullseye oder testing bekommt, lassen sich auf dem normalen Weg mit den Debian-Tools nicht bauen. Egal ob sbuild dh build oder debuild -b -uc -us. Dort bricht der Bauvorgang immer ab ... Müßte noch mal genau nachschauen, warum das so war.
Für die armhf Version ( Raspberry 3 ), müßte ich etwas an den cmake Flags ändern. Zum Beispiel neon und GBM, GLES aktivieren und ein, zwei Sachen raus nehmen. Mit Der git Version ist das auch kein Problem und baut auch auf dem Raspberry 3 durch und läßt sich auch starten und funtzt so weit auch ... Es ist dann leider nur kein .deb Paket. Ich gebe schon beim bauen an, das er beim installieren den /opt Pfad nimmt, damit nichts überschrieben wird.
Eigentlich wäre meine Frage ja ganz einfach ... Wie bekomme ich per cross-compile, Kodi für den Raspberry und amd64 gebaut als richtiges Debian Paket?

Als erstes wäre es wichtig, so wie Du schon sagtest, Kodi einfach mal nur nativ zu bauen, an dem Rechner, an dem ich gerade sitze. Die Sourcen aus bullseye ( kodi 19.x ) lassen sich schon nicht mit den herkömmlichen Debian-Tools bauen. Die git Version, per cmake aber schon. Bullseye, nutze ich auf allen Rechnern auch auf dem Raspberry.
Die zweite Frage wäre ja wenn ich den Fehler gefunden habe, warum sich Kodi mit dem Debian-Tools nicht bauen läßt und ich diesen verbessern möchte, wie mache ich das? Denn meine Änderungen in der rules Datei werden immer irgendwie überschrieben.

die Build-Abhängigkeiten vorinstallieren. Das könnte allerdings auch schiefgehen, denn sbuild benutzt eigentlich noch etwas mehr „Magie“ um die Cross-Build-Abhängigkeiten erfolgreich zu installieren. Wenn es schiefgeht, könntest du für das wiederholte Neupaketieren hier auch erstmal für amd64 statt armhf bauen.

Werde ich mal testen ...

[JTH]

Wer ist denn eigentlich dieser JHT?

Ups, ja Du

Aaach so

Der Vorschlag klingt für mich zwar meist nach dem-Problem-ausweichen aber: Schon auf Bookworm, das aktuelle Testing, umzusteigen, ist keine Möglichkeit für dich? Damit würdest du dir einige Bastelei sparen, die, wenn du Pech hast, sogar umsonst sein kann.

Als erstes wäre es wichtig, so wie Du schon sagtest, Kodi einfach mal nur nativ zu bauen, an dem Rechner, an dem ich gerade sitze. Die Sourcen aus bullseye ( kodi 19.x ) lassen sich schon nicht mit den herkömmlichen Debian-Tools bauen.

Bei mir läuft seit Kurzem Bookworm, kann deshalb nicht nachstellen, woran es bei dir anscheinend scheitert. Aber jeweils die Kodi-Version aus dem dazugehörigen Debian-Release (nach) zu bauen, muss grundsätzlich funktionieren. Denn auf dem selben Weg entstehen (per sbuild) auf den Debian-Servern die Pakete, die man aus dem Repository installiert. Und die Debian-Paketierung (alles unter debian/) ist eigentlich so „streng“, dass das nicht von lokalen Gegebenheiten abhängen soll. Ausnahmen bestätigen natürlich die Regel

Hier unter meinem Bookworm bekomme ich mit

Code: Alles auswählen

su -lc 'sbuild-createchroot --command-prefix=eatmydata --include=eatmydata --alias=testing bookworm /srv/chroot/bookworm-amd64-sbuild http://deb.debian.org/debian'
sbuild --no-run-lintian -d bookworm kodi
sbuild --no-run-lintian -d bookworm --host=armhf kodi

und einer guten halben Stunde Warten anschließend alle erwarteten Pakete. Für Kodi 20 und unter Bookworm gebaut dann halt. Vielleicht wären die ja sogar unter Bullseye installierbar, wenn du die Bullseye-Backports hinzufügst (Grund siehe unten)?

Die Version die man aus den Sourcen von bullseye oder testing bekommt, lassen sich auf dem normalen Weg mit den Debian-Tools nicht bauen. Egal ob sbuild dh build oder debuild -b -uc -us. Dort bricht der Bauvorgang immer ab ... Müßte noch mal genau nachschauen, warum das so war.

Was du hier versuchst, ist ja nichts anderes als ein Backport. Der kann wie weiter oben schon angedeutet an nicht verfügbaren Abhängigkeiten scheitern.

Kodi 20 aus Bookworm hängt zum Bauen zum Beispiel neuerdings von libhowardhinnant-date-dev ab. Das gibt es für Bullseye bisher nur über die Backports. Du bräuchtest zum Bauen und evtl. auch späteren Installieren von Kodi 20 also die Bullseye-Backports.

Wenn es nur an obiger Abhängigkeit aus dem Backports scheitert, könntest du sbuild zusätzlich mit

Code: Alles auswählen

--extra-repository 'deb http://deb.debian.org/debian bullseye-backports main'

aufrufen.

Ansonsten: Zeig doch mal, was genau du aufrufst und woran/wann es scheitert.


Noch als Hinweis:

Denn meine Änderungen in der rules Datei werden immer irgendwie überschrieben.

Werden die Änderungen tatsächlich rückgängig gemacht oder nur ignoriert? Als Hinweis falls letzteres: Wenn du Quellcode aus dem aktuellen, lokalen Ordner mit sbuild bauen willst, darfst du am Ende nicht den Paketnamen angeben, also einfach so:

Code: Alles auswählen

~/kodi-20.0+dfsg$ sbuild --no-run-lintian

Und noch ein Hinweis:
Wenn du nichts korrigieren müsstest, könntest du ein Paket (aus Bookworm), dass in deinem Bullseye noch nicht verfügbar ist, übrigens auch ohne den Quellcode von Hand runterzuladen so bauen:

Code: Alles auswählen

sbuild --no-run-lintian -d bullseye http://deb.debian.org/debian/pool/main/k/kodi/kodi_20.0+dfsg-2.dsc

Die .dsc-Dateien sind auf den Paketseiten rechts unter „Download Source Package“ verlinkt: https://packages.debian.org/bookworm/kodi

[The Hit-Man]

Kodi 20 aus Bookworm hängt zum Bauen zum Beispiel neuerdings von Debianlibhowardhinnant-date-dev ab. Das gibt es für Bullseye bisher nur über die Backports. Du bräuchtest zum Bauen und evtl. auch späteren Installieren von Kodi 20 also die Bullseye-Backports.

Hatte ich auch gemerkt und mir dann auch noch das Paket gebaut. Aus dem Grund wollte ich ja gerne wissen ob man selbst gebaute Pakete in die chroot mit einfügen kann. Dann wäre diese Abhängigkeit ja schon mal raus?

Was du hier versuchst, ist ja nichts anderes als ein Backport. Der kann wie weiter oben schon angedeutet an nicht verfügbaren Abhängigkeiten scheitern.

Genau ... es sollte einfach ein Backport werden. Wenn jetzt allerdings Kodi 20 mal in die Backports von bullseye kommen sollte, macht es ja keinen Sinn selbst ein Backport zu erstellen.

und einer guten halben Stunde Warten anschließend alle erwarteten Pakete. Für Kodi 20 und unter Bookworm gebaut dann halt. Vielleicht wären die ja sogar unter Bullseye installierbar, wenn du die Bullseye-Backports hinzufügst (Grund siehe unten)?

Die Git Version, braucht bei mir auch nur 20 Minuten ( d.h. ja auch das Cross-Compiling ). Über qemu dauert es fast Tage.

Der Vorschlag klingt für mich zwar meist nach dem-Problem-ausweichen aber: Schon auf Bookworm, das aktuelle Testing, umzusteigen, ist keine Möglichkeit für dich? Damit würdest du dir einige Bastelei sparen, die, wenn du Pech hast, sogar umsonst sein kann.

Wollte bei stable bleiben weil es ja ordentlich läuft und ich nicht ganz so oft updaten brauche. Außerdem habe ich auf einem uralt Rechner noch diesen komischen alten Nvidia-Treiber drauf, der mich stunden gekostet hatte zu installieren. Allerdings hätte ich auch immer ein Backup. Auf dem Raspberry sah das noch anderes aus. Testing läßt sich installieren aber das Kodi rennt dann echt langsam, weil nur die MesaTreiber genutzt werden und nicht dessen nativen Chip. Das war der große Grund mal ein Backport zu bauen.

Werde mich die Tage dann mal weiter mit beschäftigen und sage Dir weiter bescheid. Werde Deine Tips dann ausprobieren ... und erstmal Danke

[The Hit-Man]

So, ich habe es jetzt erstmal hin bekommen, per sbuild ein Paket ( kodi ), zu rebuilden, mit meinen eigenen Einstellungen. Ich muß sagen, das hat sich echt gelohnt. Konnte die debian/rules Datei dann nach meinen Bedürfnissen anpassen. Eigentlich habe ich nur dieses geändert :

-DAPP_RENDER_SYSTEM=gl in -DAPP_RENDER_SYSTEM=gles

Was jedoch genau der Unterschied ist, weiß ich nicht ganz genau. Auf jeden Fall, läuft dann meine Version etwas besser auf meinem uralt Nettop, mit einer uralt Nvidia ION Karte drin. Vorher ging immer der Lüfter an obwohl Kodi vdpau usw. von der Karte nutzt. Jetzt läuft die Kiste doch wirklich leiser. Klar, ab 720p wirds natürlich haarig. Ich finde aber auch das sich das Menü etwas leichter bedienen läßt.
Allerdings mußte ich die Quelle von:
https://salsa.debian.org/multimedia-tea ... enter/kodi
nehmen. Die Sourcen von bullseye, ließen sich nicht bauen ...

Hab dann auch mal versucht aus dieser Quelle, Kodi 20 zu bauen. Abhängigkeitsprobleme gab es keine, ließ sich aber trotzdem nicht bauen ... Ich bin dann aber weiter dran ...

Achja, wenn ich die salsa Quelle nehme gibts beim bauen mit sbuild immer die Fehlermeldung (quilit 3.0 ect. ). Im Netz bin ich dann drauf gestoßen, einfach die Datei unter debian/source/format zu löschen ... Bin mir nicht sicher ob das so richtig ist aber es wird durch gebaut ...