Hi, Quoting gustavo panizzo (gfa) (2015-07-21 08:05:47) > On 2015-07-20 16:34, Johannes Schauer wrote: > > crossbuilding is not equal to native building. I think Daniel was looking for a > > way to test if their packages build natively on hurd-i386 or kfreebsd-amd64. > > But crossbuilding from linux (which I'll just assume Daniel runs on their host) > > to hurd or kfreebsd will lead to different results than natively building on > > these kernels in (probably) most cases. > would that make the test useless? I build test using qemu-static-XXXX > before upload to debian to avoid FTBFS when the package reach the buildd > network are you using qemu-static-XXXX to build on linux for hurd or kfreebsd? The *only* 100% sure way to know if your package builds on the buildds is... to upload and build your packages on the buildds. The second best way is to build either on real hardware (your own or a porterbox) or in a virtual machine which emulates a whole machine, including a kernel. The third best way is to only emulate the architecture but not the kernel. This is what qemu-user does. This will probably let you run into kernel specific problems. For example, lets create a chroot for hurd-i386 on my amd64 box. Since my amd64 machine is perfectly able to execute i386 code, we don't even need qemu here: sudo debootstrap --arch=hurd-i386 sid debian-sid-hurd-i386 Trying to execute anything inside there yields a segmentation fault which I do not find surprising. For example, the above debootstrap command, since hurd-i386 a foreign architecture to my amd64 machine, will only execute the first stage (unpacking) of debootstrap. For the second stage to work I'd have to mount /proc but I'd not know how a hurd-i386 system would work with my linux /proc (probably not at all). But even if you are usign qemu-static only with linux-any arches on linux, there are packages for which you'll run into problems. For example lets try the following: $ sudo debootstrap --arch=armhf sid debian-sid-armhf $ sudo apt-get install qemu-user-static binfmt-support $ sudo cp /usr/bin/qemu-arm-static debian-sid-armhf/usr/bin $ sudo chroot debian-sid-armhf uname -a Linux hoothoot 4.0.0-2-amd64 #1 SMP Debian 4.0.5-1 (2015-06-16) armv7l GNU/Linux whoops! So the "emulated" system is able to find out that my kernel actually has an amd64 release number! It becomes worse if, for your build you have to bind mount things from your host into the chroot because then even more will spill from your amd64 host into your armhf system. There are more ways for a program being emulated by qemu-static to find out that it's not running on real hardware. And these differences might break some packages. If it doesn't break yours: cool! But qemu-user will fail for *some* packages, so it is not a general cure. And sure, if your package does noting fancy but just calls cp a couple of times to put everything in the right location, then nothing will go wrong with the qemu-user method. But if your package is that simple, then you probably also don't need to test it. cheers, josch
Attachment:
signature.asc
Description: signature