From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Othacehe Subject: bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd Date: Sat, 25 Apr 2020 14:32:14 +0200 Message-ID: <87sggru4oh.fsf@gmail.com> References: <87imhnuc8a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:41060) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSJzU-0008Hi-PS for bug-guix@gnu.org; Sat, 25 Apr 2020 08:33:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSJzT-0004Ae-7z for bug-guix@gnu.org; Sat, 25 Apr 2020 08:33:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:47441) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSJzS-0004AH-DG for bug-guix@gnu.org; Sat, 25 Apr 2020 08:33:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSJzS-0007Fk-9A for bug-guix@gnu.org; Sat, 25 Apr 2020 08:33:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87imhnuc8a.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Sat, 25 Apr 2020 11:49:09 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Jan Nieuwenhuizen Cc: 40839@debbugs.gnu.org > The wip-hurd-vm branch cross-builds a VM for the Hurd. It uses some > dedicated hacks to build the system packages, services, system profile > and shepherd configuration and cross-build them into a qemu image. > > We did this to avoid too much struggle up front with parameterizing, > working around, or removing Linux-specifics from "guix system > --target=i586-pc-gnu build,vm,..." I have not followed really closely the recent progress on the Hurd, but I think we may need to synchronize at some point :) As you have noticed our image creation is very tied to Linux and Intel x86 compatible machines. I would like in the future that producing images for other architectures/kernels could be less hacky. My idea is to: * Speed up image creation by removing the need to use VM to produce images. * Augment the operating-system record, or provide a new record, that encapsulates information related to image layout (partitions, bootloader location), target architecture (i586-pc-gnu, aarch64-linux, ...). This way, one would just have to run `guix system disk-image my-board.scm' or `guix system disk-image --board=xxx config.scm', and not have to worry about specifying the correct target triplet, kernel and bootloader packages. On the wip-disk-image, I propose the creation of an "image" record in (gnu image), but I'm still not sure how to interface it. Thanks, Mathieu