From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@gnu.org>
Subject: Re: Plan for a release!
Date: Thu, 26 Mar 2020 12:55:50 +0100
Message-ID: <87a743ba9l.fsf@gnu.org>
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>
 <87k13bnp38.fsf@gmail.com>
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]:38485)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@gnu.org>) id 1jHR75-0008HG-3T
 for guix-devel@gnu.org; Thu, 26 Mar 2020 07:55:56 -0400
In-Reply-To: <87k13bnp38.fsf@gmail.com> (Mathieu Othacehe's message of "Mon,
 23 Mar 2020 15:05:47 +0100")
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: Mathieu Othacehe <m.othacehe@gmail.com>
Cc: guix-devel@gnu.org

Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> Yes: you need to have =E2=80=98installation-os-for-gui-tests=E2=80=99 (o=
r 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:
>
>>   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=
 we resort to
> VMs is that the Linux kernel doesn=E2=80=99t allow you, for instance, to =
mount 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.)
>
> 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.

Understood.  :-/

Another approach would be to do like =E2=80=98guix system vm=E2=80=99, whic=
h is to share
the store with the host.  But then we would need a way to be able to run
a daemon in the guest and have its build results overlaid on top of the
host-provided store.

Note that system tests other than the installation tests actually use
the equivalent of =E2=80=98guix system vm=E2=80=99 already, so they copy mu=
ch less stuff
around.

Thanks,
Ludo=E2=80=99.