bauen von Debian Paketen aus den Sourcen

[The Hit-Man]

Ich habe mich jetzt seit längerer Zeit damit beschäftigt, backports zu basteln. Ich nehme jetzt zum Beispiel mal Debian Buster. Um mein System nicht zu zerhauen, verwende ich deboostrap und lege mir ein Debian Buster chroot Umgebung (Raspberry armhf ) an ( Version 1 - cross-compile )

Code: Alles auswählen

debootstrap buster buster.amd64 http://httpredir.debian.org/debian/

dann gehe ich da einfach per chroot rein und installiere folgende Sachen:

Code: Alles auswählen

apt install packaging-dev debian-keyring devscripts equivs

Die Datei die /etc/apt/sources.list passe ich so an, das ich zum Beispiel die Sourcen von Debian Sid nehme. Soll ja ein backport werden.

Code: Alles auswählen

deb http://httpredir.debian.org/debian buster main
deb http://httpredir.debian.org/debian buster-backports main

deb-src http://httpredir.debian.org/debian sid main

Dann wird die armhf Architektur hinzugefügt:

Code: Alles auswählen

dpkg --add-architecture armhf

Jetzt hole ich mir mal eine Source aus Debian sid:

Code: Alles auswählen

apt source ein_programm

Für das cross-compile führe ich ja nun aus:

Code: Alles auswählen

cd ein_programm
mk-build-deps --install --remove --host-arch armhf
debuild --build=binary --unsigned-changes --host-arch armhf

Nun sollten auch alle Abhängigkeiten installiert werden. Klar, wenn eine Abhängigkeit unter buster nicht existiert, knallet es ... ABER nehmen wir mal an, es gibt alle Abhängigkeiten, bekomme ich trotzdem hin und wieder kaputte Pakete.
Nehme ich aber ( Version 2 ) und baue mir direkt eine chroot Umgebung für den raspberry ( armhf ):

Code: Alles auswählen

debootstrap buster buster.armhf http://httpredir.debian.org/debian/ --arch=armhf

brauche ich die Option --host-arch armhf nicht mehr, da es ja kein cross-compile mehr ist. Das bauen läuft dann natürlich wesentlich langsamer, da es über den qemu geht. Allerdings wenn ich dort Abhänigkeiten habe werden sie in dieser chroot Umgebung sehr viel besser aufgelöst und konnte sogar den MidnightComander und diverse andere Programme, locker von sid auf buster bauen ( also backports ).

Meine Frage wäre, wieso gibt es bei der ersten Version so viele Abhängigkeitsprobleme und bei der 2ten Version flüssiger läuft? Würde ja eher Version 1 nutzen von der Geschwindigkeit her ...

[hikaru]

Ich kann leider keine Lösung anbieten.
Vor rund 10 Jahren habe ich armhf-Backports für mein Nokia N900 gebaut. Crosscompiling habe ich ebenfalls nicht hinbekommen, an die Details erinnere ich mich allerdings nicht mehr.

Der Bau in Qemu war furchtbar langsam, auf einem damals schnellen i7-2700k sogar langsamer als direkt auf dem N900. Ich hatte mir dann ein Cubieboard 2 zugelegt um dort armhf-Pakete zu bauen.
Bevor du deine Pakete in Qemu baust, würde ich sie an deiner Stelle eher direkt auf dem RPi bauen.

[The Hit-Man]

Bevor du deine Pakete in Qemu baust, würde ich sie an deiner Stelle eher direkt auf dem RPi bauen.

Werde ich mal schauen ... Hätte nen 3er Raspberry hier ...

Aber trotzdem verstehe ich nicht, das es mit Version 1 nicht so gut klappt aber mit Version 2? Im Endeffekt sollte es ja irgendwie das gleiche sein. Für den qemu nutze ich im Moment diesen Rechner:
CPU: Intel i7-4702MQ (8) @ 3.200GHz

Aber ja, auch da qäulend langsam ... Wie baut Debian denn selbst die backports? Auch mit dem qemu?

Hatte mich mal auf https://build.opensuse.org/ angemeldet. Aber da ist es ja noch schlimmer. Aber Debian schafft es doch auch selbst, backports zu bauen. Wieso haben die nicht diese Probleme?

[schorsch_76]

Bevor du deine Pakete in Qemu baust, würde ich sie an deiner Stelle eher direkt auf dem RPi bauen.

Werde ich mal schauen ... Hätte nen 3er Raspberry hier ...

Aber trotzdem verstehe ich nicht, das es mit Version 1 nicht so gut klappt aber mit Version 2? Im Endeffekt sollte es ja irgendwie das gleiche sein. Für den qemu nutze ich im Moment diesen Rechner:
CPU: Intel i7-4702MQ (8) @ 3.200GHz

Aber ja, auch da qäulend langsam ... Wie baut Debian denn selbst die backports? Auch mit dem qemu?

Hatte mich mal auf https://build.opensuse.org/ angemeldet. Aber da ist es ja noch schlimmer. Aber Debian schafft es doch auch selbst, backports zu bauen. Wieso haben die nicht diese Probleme?

Debian selbst baut die Pakete auf arm64 Hardware.

https://www.debian.org/devel/buildd/
bzw.
https://buildd.debian.org/status/archit ... e=bookworm
https://db.debian.org/machines.cgi?host=arm-ubc-01
etc...

Edit: Das ist ein Hersteller der starke Arm Boards baut und auch Debian sponsert.
https://amperecomputing.com/

EDIT2:
https://db.debian.org/machines.cgi

[The Hit-Man]

Debian selbst baut die Pakete auf arm64 Hardware.

Ah, verstehe ... diese Server kann man aber nicht selbst nutzen um Pakete zu bauen?

[The Hit-Man]

Hab gerade noch mal getestet ... im qemu bekomme ich locker den MidnightComander von trixie auf Buster gebaut ... und der läuft auch. Mit dem cross-compile bekomme ich das so nicht hin ...

unter Buster jetzt die neue Version:

Code: Alles auswählen

GNU Midnight Commander 4.8.30
Gebaut mit GLib 2.58.3
Gebaut mit S-Lang 2.3.2 mit terminfo-Datenbank
Gebaut mit libssh2 1.8.0

[KBDCALLS]

Ich hab mich auch schon länger zwar mit der Thematik nicht befasst. Ich nehme dazu immer pbuilder.

Code: Alles auswählen

pbuilder create 

funktionierte für armhf u. arm64 erst nach dem ich das Paket qemu-user-static installiert habe. Ansonsten brach pbuilder ab.

• Code: Alles auswählen

  chroot: failed to run command '/bin/true': Exec format error

[The Hit-Man]

Ich hab mich auch schon länger zwar mit der Thematik nicht befasst. Ich nehme dazu immer pbuilder.

Dann scheint der pbuilder auch über qemu zu gehen, sprich ist dann recht langsam. Ich nehm lieber eine chroot Umgebung ... Denn es kann ja mal sein ( ist mir auch schon passiert ), das es eine spezielle lib noch nicht gibt, die man auch aus sid oder so bauen muß und diese dann in der chroot Umgebung zu installieren, damit das vorherige Paket gebaut werden kann. Dann muß man halt nur die spezielle lib, mit in die backports packen. Des weiteren zerballer ich mir nicht mein richtiges System ( ist mir auch schon passiert ).
Aber wie gesagt, es MUSS auch per cross-compile gehen ohne diese ganzen Abhängigkeiten denn damit bauste ja 1000 mal schneller ein Paket ...

[The Hit-Man]

Eine andere Sache scheint, die zu sein ...
Wenn ich ein Paket unter dem Lappi baue ( der eben 8 Kerne hat / amd64 ) und dieses fertige Paket dann auf einem anderem amd64 Rechner laufen lassen mag .. Kann da schon mal ein seg fault kommen ...
Schlimmer wird es dann wenn ich unter dem amd64 ein i386 Programm baue ( unter deboostrap / i386 ) ... kann es manchmal ganz viele seg faults geben. Verstehe ich jetzt nicht so ganz ... Baue ich die i386 Pakete aber direkt auf der Maschine, gibts keine Probleme ... Ich habe hier halt nen Rechner, der zwar 64 Bit kann aber zum testen habe ich da nen 32 Bit Debian drauf ... und es läuft ja auch ...