On 1 November 2016 at 10:58, Christian Seiler <christ...@iwakd.de> wrote: > On 11/01/2016 12:22 AM, Andrew Worsley wrote: >> I tried using pbuilder (based off >> https://jodal.no/2015/03/08/building-arm-debs-with-pbuilder/) but -> >> qemu-arm-static has bugs (segmentation faults - possibly >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811087 > > You can use (in your pbuilderrc) > PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-classic" > to make pbuilder use a different (much slower, and in edge cases > possibly problematic) dependency-resolution algorithm. In that > case aptitude will never be invoked and builds in qemu-user > chroots will mostly work - with possibly some exceptions. I've > never tried a kernel build in such a setup though.
Thank-you very much Christian, that variable does indeed avoid the qemu crash. I'm hitting other errors now OS=debian DIST=stretch ARCH=armel pbuilder --build linux_4.7.8-1.dsc .... -> Considering build-dep gcc-5 [alpha amd64 arm64 armel armhf hppa i386 m68k mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el s390x sh4 sparc64]<!stage1 !cross> -> Trying gcc-5 -> Considering build-dep gcc-5-alpha-linux-gnu:native [alpha]<!stage1 cross> -> This package is not for this architecture -> Considering build-dep gcc-5-x86-64-linux-gnu:native [amd64]<!stage1 cross> -> This package is not for this architecture -> Considering build-dep gcc-5-aarch64-linux-gnu:native [arm64]<!stage1 cross> -> This package is not for this architecture -> Considering build-dep gcc-5-arm-linux-gnueabi:native [armel]<!stage1 cross> -> Trying gcc-5-arm-linux-gnueabi:native -> Cannot install gcc-5-arm-linux-gnueabi:native; apt errors follow: ... But stretch has gcc-6 ? - anyway much more managable problem than qemu-arm-static seg fault! But using a different .dsc file: OS=debian DIST=stretch ARCH=armel pbuilder --build linux-latest_75.dsc With this .dsc file It can find gcc-5 ? Get:35 ftp://218.100.43.30/debian stretch/main armel gcc-5 armel 5.4.1-3 [5297 kB] I am guessing there is a ton of extra detail to these .dsc files and kernel building - long learning curve ahead of me but it is actually BUILDING now! > Note that qemu-user chroots are _really_, _really_ slow. Builds > can take anywhere from 3 to 20 times as long as on native > hardware. (For other packages, in my experience building armhf > in qemu-user chroots on amd64 is ~12 times slower. YMMV.) ..... I'll see how far it goes and if my patience will make it. But as a practical scheme it sounds like I will likely need to go another way. > Alternatively, you can actually cross-compile stuff by > employing a real cross compiler that runs natively on your > hardware (hence faster) but generates code for the target > hardware you're looking at. The build system of a package must > support cross compiling explicitly for this to work and be > useful, I've never tried the kernel packages, so I don't know > if that will work. You can get a pointer on how to actually > cross-compile Debian packages under: > https://wiki.debian.org/CrossCompiling .. Thanks for this link - it points to schroot - so perhaps that is the way forward as you suggest it will be *extremely* slow (although for the small random package appears to be quite practical). >> But I see that buildd ( >> https://buildd.debian.org/status/logs.php?pkg=linux&arch=armel ) >> apparently works some how. > > Well, the official Debian buildds for armhf/armel actually run on > ARM hardware, so that's why the "work". ;-) > > Regards, > Christian Ok that explains the current best practices that Debian uses now. I guess in the past they used schroot. Thanks again I am so much happier that I have some options to move forwards. Andrew