From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mathieu Othacehe <m.othacehe@gmail.com>
Subject: Re: Plan for a release!
Date: Mon, 23 Mar 2020 15:05:47 +0100
Message-ID: <87k13bnp38.fsf@gmail.com>
References: <87pne3d5t6.fsf@gnu.org> <87o8t1smpe.fsf@gnu.org>
 <87k13h7gg3.fsf@gnu.org> <87tv2ld04o.fsf@gmail.com>
 <87k13fjo2i.fsf@gmail.com> <87k13d1zj7.fsf@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org>
Received: from eggs.gnu.org ([2001:470:142:3::10]:36558)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <m.othacehe@gmail.com>) id 1jGNiD-0007a9-9v
 for guix-devel@gnu.org; Mon, 23 Mar 2020 10:05:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <m.othacehe@gmail.com>) id 1jGNiC-0001QK-3O
 for guix-devel@gnu.org; Mon, 23 Mar 2020 10:05:53 -0400
In-reply-to: <87k13d1zj7.fsf@gnu.org>
List-Id: "Development of GNU Guix and the GNU System distribution."
 <guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/guix-devel>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org
Sender: "Guix-devel"
 <guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@gnu.org>
Cc: guix-devel@gnu.org


Hello,

> Yes: you need to have =E2=80=98installation-os-for-gui-tests=E2=80=99 (or=
 preferably a
> variant thereof) include all the services/packages needed for the target
> config.
>
> In the manual installation tests we use =E2=80=98define-os-with-source=E2=
=80=99 to both
> embed the target OS and its references in the installation image *and*
> have the source of the target OS available in /etc/target-config.scm in
> the installation image.

Ok! I'm testing with an installation image containing all desktop
environments. This represents 1200 store items (image around 6GiB).

The disk-image creation takes 2h45 on a powerful machine (with
KVM). I've seen your insights on this topic here:

--8<---------------cut here---------------start------------->8---
>   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?

Unfortunately, I don=E2=80=99t think that=E2=80=99s possible.  The reason w=
e resort to
VMs is that the Linux kernel doesn=E2=80=99t allow you, for instance, to mo=
unt a
file system without being root.  So doing things like running Parted,
mounting a file system, and populating it typically requires root
privileges.  (In some cases, there are tools like mksquashfs that can do
that from user-space, but it=E2=80=99s very ad-hoc.)
--8<---------------cut here---------------end--------------->8---

It makes sense and after some digging, I cannot propose something
better (nix is using the same mechanism). However, I feel very
frustrated by this disk-image thing, loosing a lot of time and
computation time for some copies.

> It=E2=80=99d be IMO clearer, although technically equivalent, to make it:
>
>   (or (marionette-eval exp marionette)
>       (throw 'marionette-eval-failure 'exp))
>
> Perhaps you don=E2=80=99t even need to catch it.

You are right :) I pushed this patch throwing exception as suggested.

Thanks,

Mathieu