Hello,
At Fosdem 2020, I gave a talk about using GNU Guix as an alternative to Yocto, focusing on cross-compiling a Guix System. Here's a status and my personal roadmap on this topic. * On core-updates, since commit d594963856690f1aacf228c8a83e406d33bc44ce, cross-compiling a bare-bones Guix System disk-image for Pine A64 works. This is propably true for other boards too. * On the same commit, the produced disk-image weights 1.9 GiB, which is obviously too big. I'm working on reducing this closure size. See: https://issues.guix.info/issue/39941 and https://issues.guix.info/issue/40071. * While cross-compilation is important, Guix also supports emulated compilation with --system. Producing a Guix System disk-image with --system is currently broken and needs to be fix. See https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00099.html. * Somehow related to the previous point, producing a disk-image, currently means spawning a virtual machine. This can be very slow, and using --system, we currently emulate the execution of a virtual machine for a foreign architecture. I'd like to propose an alternative mechanism which would be faster and not involving virtual machines. Maybe producing the disk-image in a container? * Increase board support catalog, even if it's tricky because many boards need proprietary blobs to boot (such as Raspberry Pis). The effort started by Danny on wip-buildroot could be resumed. * Finally, as we discussed during Guix Days[1], it would be nice to have a webservice, where you could select your board, the packages/services you want to install, and a disk-image, cross-compiled or not, would be generated for you! It implies that all the points listed above are solved, but it could be quite nice :) Feedback welcome! Thanks, Mathieu [1]: http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2020/growing-guix.org
