On Sat, Jan 22, 2011, Roger Leigh wrote: > Having the ability to build packages for any arbitrary architecture > using schroot will be really sweet. Plus, if schroot supports it, > sbuild will automatically be able to make use of it, which means > you'll be able to do stuff like running an m68k buildd (or whatever > arch) on much faster e.g. amd64 hardware.
Yep, I agree it's really sweet! I'd like to warn about using it as a buildd though: * qemu's CPU transparency is sometimes incomplete; there was a very recent effort by Peter Maydell to fix the emulation which was broken on a lot of instructions, but he mostly focused on real-world instructions, the emulation might still not be 100% complete or correct in future occurrences; also his patches did not yet make it entirely upstream, nor in Debian/Ubuntu. I suspect different architectures will have differing quality levels there. * syscall transparency is actually really bad for a buildd: if qemu doesn't translate a syscall, and the build detects that, it might assume the arch doesn't support the syscall while real hardware supports it. Or vice-versa: assume the syscall is supported because qmeu can actually translate it, but real kernels actually don't have support for it (that should not get implemented in qemu, but it might still happen). These are usually qemu bugs or missing features, we'd need some kind of archive wide rebuild to see how many difference in build logs (or something like that) we get between real hardware and qemu-user builds/ * a lot of things are really hard to simulate/emulate/intercept: /proc/cpuinfo will return the host's cpuinfo, and that's true of a lot of file in /proc. /dev and /sys also come to mind. My feeling is that this should mostly work for non-critical pieces of software, like high-level userspace programs. But it's probably not a good idea to build complex/advanced system libs with it, like eglibc, pth, coreutils etc. qemu machine emulation (qemu-system-arm) is however much safer for this (albeit also much slower); it might suffer from emulation bugs, but it's much harder to leak any host environment into it. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110122223539.gb11...@bee.dooz.org