[TKLDev] Include QEMU so as to allow cross compiling of alternative architechures

[JedMeister]

Whilst it would be quite a cool 'nice to have' feature with just 32 and 64 bit architectures, once we start considering additional architectures such as ARM (e.g. for Raspberry Pi) then IMO it becomes crucial.

Most users won't want to compile their custom TKL appliances for their Raspi (when TKL get's to release them) on their Raspi! Besides, for TurnKey devs, requiring a separate host system with the same architecture for each architecture supported becomes a nightmare once additional architectures get added... And it certainly doesn't scale well.

Redeveloping TKLDev to build within QEMU rather than a chroot would allow this. :)

[JedMeister]

After a little more research I have discovered that you can use QEMU to create a non-native chroot so you can essentially have a chroot that can be a different architecture than the host. Although it is still slower than running code natively, it seems that it is quicker and easier than using a fully emulated env.

Refs:
https://wiki.debian.org/QemuUserEmulation
https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap
http://www.hellion.org.uk/blog/posts/foreign-chroots-with-schroot-and-qemu/
http://raspberrypi.stackexchange.com/questions/855/is-it-possible-to-update-upgrade-and-install-software-before-flashing-an-image
http://burstcoding.blogspot.com.au/2012/12/qemu-user-mode-arm-for-raspbian-chroot.html

[JedMeister]

Also perhaps this method could also make it easier to build for alternate target platforms. For example; build Jessie based TKL appliances on current v13.x (i.e. Wheezy based) TKLDev (as mentioned in this thread).